微信扫码
添加专属顾问
我要投稿
AI 技术普惠化浪潮来袭,DeepSeek 和 Qwen 如何引领行业变革?核心内容:1. DeepSeek-R1 和 Qwen 引领的 AI 普惠趋势2. 企业面临的成本、模型、安全等挑战3. 未来大语言模型的发展趋势和应用前景
DeepSeek/QWen 普惠 AI 趋势
Cloud Native
随着 DeepSeek-R1 的横空出世,又一次点燃了原本已经有点冷淡的大语言模型市场和话题,并且快速成为了现象级,小到中小学生,大到父母辈都知道了中国出了一个叫 DeepSeek 的大语言模型。各个行业,各个企业又都开启了新一轮的 AI 赋能/改进业务的浪潮。工信部发文力推最新AI技术普惠应用,三家运营商全面接入 DeepSeek。国务院国资委召开中央企业“AI+”专项行动深化部署会。种种现象都表名,在 DeepSeek 引发的“鲶鱼效应”下,AI 热潮持续升温,各个企业都愿意花钱进行尝试,云厂商 GPU 形态,线下一体机形态,云厂商 DS API 形态多种形态并存。
3 月 6 日凌晨,阿里云通义千问发布了最新的 QWQ 32B 模型,在仅有 DeepSeek-R1 约 1/20 参数量的情况下, 用强化学习,实现了性能上的惊人跨越,并且同样是开源开放的。Qwen 团队表示,QwQ-32B 的发布只是他们在强化学习方向上的初步尝试。未来,他们将继续深入探索 RL 的潜力,并将其与更强大的基础模型相结合,利用更大的计算资源,致力于打造下一代 Qwen 模型,并最终迈向通用人工智能 (AGI) 目标。所以可见模型尺寸更小,性能更强是未来的一个趋势,也是大语言模型普惠市场,AI 普惠市场的基石。
LLM 生产项目中必然会遇到的问题
Cloud Native
在AI普惠的过程中,有一个显著的特点就是用户们选择使用 LLM 的方式变多了,自主可控能力变强了。比如可以购买 GPU 资源自己部署模型,可以在线下机房部署,也可以使用阿里云的PAI或者函数计算 FC 来部署。也可以使用各个模型托管平台,通过 API 的方式来使用大语言模型。但无论选择哪种方式,在 LLM 应用上生产项目的过程中,必然都会遇到一系列问题:
云原生 API 网关简述
Cloud Native
阿里云的云原生 API 网关是将流量网关、微服务网关、安全网关和 AI 网关四合一的网关产品,实现碎片化网关的架构统一,提供服务暴露及流量管控、AI 应用流量入口与集成、API 全生命周期管理等能力,具有性能更强劲(高出自建 1~5 倍)、稳定更可靠(技术积淀已久,历经多年双 11 考验 )、多重安全防御(mTLS 双向认证、登录认证、集成应用防火墙、自定义安全插件)、扩展性强(提供丰富的插件,支持热更新),是高性能、安全、AI 友好的统一型网关。
它在整个应用架构中起到链接的核心作用,比如:
云原生 AI 网关简述
Cloud Native
云原生 AI 网关其实并不是一个新的独立的产品,而是属于云原生 API 网关产品内的一部分功能,基于 AI 的场景,设计了更贴合 AI 业务的 AI API 及各个功能。同时也具备云原生 API 网关本身提供的各个通用能力。
目前通义、百炼、PAI 都集成云原生 AI 网关,每天承载亿级别的多模态请求,通过真实生产项目去打磨,践行了 Dog Food 原则。
云原生 AI 网关整体的核心能分为四大块:
云原生 AI 网关代理 LLMs 方案
Cloud Native
从上图架构中可以看出,AI 网关代理 LLM 方案的架构并不复杂,但是在 AI 应用上生产的过程中通常会遇到 9 个核心的问题,然而在上面这个并不复杂的架构下,通过 AI 网关都可以很有效的解决。接下来我们通过用户视角、业务场景视角来逐一分析和说明。
解决用户管理失控的问题
现在大大小小的企业应该都在部署 LLM,想方设法的融入到业务中,或日常工作中,那么站在运维团队或者类似中台团队的视角下,可能会有两个核心的问题:
第一个问题很好解决,OpenAI API 的协议基本已经是标准协议,目前市场面上几乎所有的 LLM 都支持 OpenAI API 协议。所以提供遵循 OpenAI API 协议的 HTTP 接口就可以让企业员工通过各种方式使用 LLM 服务和能力。
对于第二个问题,AI 接口一旦暴露出去,基本上不可能只让一小部分人知道,所以需要对访问 LLM 服务的用户做以限制,只让能访问的人访问,不能访问的人即便知道了接口也无法访问。
所以可以使用 AI 网关具备的消费者认证的能力来解决这个问题。
核心逻辑是将一个人或一组人抽象为消费者的概念,可以对消费者做权限配置,既可以访问哪些接口,消费者下可以生成不同类型的 API Key,请求接口时需要带着 API Key,然后基于权限规则去校验 API Key 的合法性。通过这种就可以精细化的管理访问 AI 接口用户了。
消费者认证的核心价值:
典型鉴权场景与 API Key 应用场景:
解决同一域名访问不同模型的问题
核心问题:公司 GPU 资源有限,部署了满血版 DeepSeek-R1,还有其他一些小模型以及使用百炼的模型服务,现在域名都不统一,分发、管理、集成的成本都很高,如何使用同一个域名来访问不同的模型?
这个问题是本质是满血 DS R1 和其他模型或者闭源 LLM API 服务共存,保持同一个 API 接口,不同业务通过请求中的模型名称,切换不同的模型。因为目前 LLM 的 API 都是遵循了 OpenAI 协议的,所以使用请求 Body 里的模型名称来切换模式是更加通用的。
云原生 AI网关支持一个 AI API 下配置多个模型服务的能力,每个模型服务通过 Glob 语法来匹配模型名称,从而实现上述需求。
再延伸一下模型切换的核心价值:
解决闭源模型&模型托管平台 QPM/TPM 限制的问题
像 ChatGPT,豆包这类闭源 LLM,或者百炼这种托管 LLM 平台,都是以提供 API 的方式供大家使用 LLM 的能力,但是受限底层 GPU 资源的压力,以及整体平台的稳定性,每个用户都有请求 QPS 的最大限制(基于平台的 API Key 的维度),且上调比较困难。所以很多客户都有这个核心问题:如何突破这个限制问题?
这个问题有两类解决方案:
云原生 AI 网关在 AI 服务级别支持多 API Key 管理的能力,每次请求会轮循取一个 API Key 向后端模型服务请求。并且 API Key 可以动态新增和删除,极大减轻了用户自己维护多个 API Key 的问题。
云原生 API 网关提供了扩展点,可以将请求和响应的内容缓存到 Redis,提升推理效率。目前支持按照问题精确匹配,基于向量化检索的匹配也在支持中。
需要注意的是,这个功能建议只在非常垂直类的应用场景下适合使用,在泛业务场景下开启结果缓存可能会降低推理精度或准确性,需要结合业务判断和考量。
解决模型服务高可用的问题
现在 GPU 的资源是昂贵的,所以无论是自购 GPU 部署 LLM 还是模型托管平台都不会基于流量峰值去储备资源,所以才会有上文中的 QPM/TPM 限制的情况。但是站在用户业务健壮性的角度来看,如何在成本、稳定性、健壮性之间找到一个平衡点是更需要考虑的事。比如:我们公司的主力模型是 PAI 上部署的 DS R1 671B,但 GPU 资源并不是基于流量峰值储备的,所以当高峰期时,DS 服务会请求失败,有什么办法可以保证业务健壮性?
这类问题可以有两种做法,并且可以搭配使用:
云原生 AI 网关在 AI API 维度支持 LLM 服务的 Fallback 机制,并且可以配置多个 Fallback LLM 服务。当主 LLM 服务因为各种原因出现异常,不能提供服务时,网关侧可以快速将请求 Fallback 到配置的其他 LLM 服务,虽然可能推理质量有所下降,但是保证了业务的持续性,争取了排查主 LLM 服务的时间。
除了传统的 QPS 限流降级以外,云原生AI网关支持更贴合 LLM 推理场景的 Token 维度的限流能力。可以针对 AI API 级别配置一个下游 LLM 服务可以承载的请求量级,在一定程度上保证了整体业务的健壮性,至于被限流的请求,可以返回一些人性化的信息,比如 DeepSeek 官网的服务器繁忙。
我们可以再延伸一下基于 Token 维度限流的其他核心价值:
解决安全合规问题
AI 应用场景下的内容安全问题是大家都很重视的核心问题,模型托管平台通常都自带好几层内容安全审核机制,但是我们在 IDC 部署或者在 PAI 部署的,如何能方便的接入内容安全审核服务?
AI 网关中的 AI API 集成了阿里云的内容安全防护服务,可以一键开启,支持请求内容检测和响应内容检测。不过安全防护的规则还是要在内容安全服务侧配置。比如“树中两条路径之间的距离”这个可以让 LLM 无限推理的问题,从内容安全的常规规则来看,它是合规的,但是它却能对 LLM 服务的稳定性造成隐患,所以在 AI 网关开启了内容安全防护后,便可以快速的在内容安全防护服务中添加自定义规则来杜绝这类有潜在风险的请求信息。
延伸到内容安全在 AI 领域的核心价值有五类:
解决大语言模型幻觉的问题
有些个人用户或者企业用户可能会发现部署了 DeepSeek R1 671B 的模型,但推理的结果和 DS 官网推理的结果有差距,似乎不满血?
推理的结果和 DeepSeek 官网推理的结果有差距是因为 DeepSeek 官网开启了联网搜索。DeepSeek R1 671B 的模型推理能力是很强,但训练的数据也是有限的,所以要解决幻觉还需是要在推理前先搜索和处理出比较确切的信息后,再由 DeepSeek R1 推理,所以联网搜索是非常关键的。目前模型托管平台提供的 DeepSeek R1 API 和自己部署的 DeepSeek R1 都需要自己实现联网搜索。
其实不只是 DeepSeek,目前除了百炼上的通义千问 Max 以外,其他的模型在 API 层面都不支持联网搜索,即使 ChatGPT 是最早推出联网搜索功能的,但 OpenAI 的 API 协议目前也还没有支持联网搜索。
云原生 AI 网关目前在 AI API 维度支持了夸克和必应的联网搜索能力,提供多种搜索策略,可将搜索结果自动如何进输入 Prompt,无需用户对后端 LLM 服务做额外处理,并且我们对输入的问题也通过 LLM 做了意图识别,避免了很多无效的联网搜索。
解决 AI 领域可观测问题
可观测是任何一个领域都必不可少的需求,但是 AI 场景的可观测和传统场景的可观测是有很大区别的,监控和关注的指标都是不同的,云原生 AI 网关结合阿里云日志服务和可观测产品实现了贴合 AI 应用业务语义的可观测模块和 AI 观测大盘,支持比如 Tokens 消费观测,流式/非流式的 RT,首包 RT,缓存命中等可观指标。同时所有的输入输出 Tokens 也都记录在日志服务 SLS 中,可供用户做更详细的分析。
AI 网关可观测核心能力:
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2025-03-31
大模型时代的视频动静态封面生产方案及业务实践
2025-03-31
AI赋能:大模型创新的模板生成与内容填充
2025-03-31
音频生成技术探索与淘宝域实践
2025-03-31
Agent驱动产品研发管理[续集]:如何用AI大模型打造PRD全流程自动化
2025-03-31
深度解读| GPT4o离干掉套壳AI与Midjourney只差最后一步
2025-03-31
大模型上下文协议 MCP 带来了哪些货币化机会
2025-03-31
智谱发布免费的超级 Agent:像 Manus 一样干活,像 DeepSeek 一样思考
2025-03-31
Cursor + Flux 构建高质量本地运行的文生图 MCP 服务
2024-08-13
2024-06-13
2024-08-21
2024-09-23
2024-07-31
2024-05-28
2024-08-04
2024-04-26
2024-07-09
2024-09-17
2025-03-30
2025-03-30
2025-03-28
2025-03-27
2025-03-27
2025-03-27
2025-03-27
2025-03-26