作者：付宇轩(计缘)

DeepSeek/QWen普惠AI趋势

随着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生产项目中必然会遇到的问题

在AI普惠的过程中，有一个显著的特点就是用户们选择使用LLM的方式变多了，自主可控能力变强了。比如可以购买GPU资源自己部署模型，可以在线下机房部署，也可以使用阿里云的PAI或者函数计算FC来部署。也可以使用各个模型托管平台，通过API的方式来使用大语言模型。但无论选择哪种方式，在LLM应用上生产项目的过程中，必然都会遇到一系列问题：

• 成本平衡问题：部署DeepSeek R1 671B满血版模型，至少需要2台8卡H20机器，列表价年度超过100W，但2台的TPS有限，无法满足生产部署中多个用户的并发请求，需要有方案找到TPS和成本之间的平衡点。
• 模型幻觉问题：即使是DeepSeek R1 671B满血版模型，如果没有联网搜索，依然有很严重的幻觉问题。
• 多模型切换问题：单一模型服务有较大的风险和局限性，比如稳定性风险，比如无法根据业务（消费者）选择最优模型。目前也没有开源组件和框架解决这类问题。
• 安全合规问题：企业客户需要对问答过程做审计，确保合规，减少使用风险。
• 模型服务高可用问题：自建平台性能达到瓶颈时需要有一个大模型兜底方案，提升客户大模型使用体验。
• 闭源模型QPS/Token限制问题：商业大模型都有基于API Key维度的QPS/Token配额限制，需要一个好的方式能够做到快速扩展配额限制。

以上问题都是实实在在的客户在使用过程中遇到的问题，有些是模型自身问题，有些是部署架构问题，如果要客户一个一个去解决，复杂度和时间成本都是比较高的。所以就需要AI网关的介入来快速的，统一的收敛掉这些核心问题。

云原生API网关简述

阿里云的云原生API网关是将流量网关、微服务网关、安全网关和AI 网关四合一的网关产品，实现碎片化网关的架构统一，提供服务暴露及流量管控、AI应用流量入口与集成、API全生命周期管理等能力，具有性能更强劲（高出自建1～5倍）、稳定更可靠（技术积淀已久，历经多年双11考验 ）、多重安全防御（mTLS 双向认证、登录认证、集成应用防火墙、自定义安全插件）、扩展性强（提供丰富的插件，支持热更新），是高性能、安全、AI友好的统一型网关。

它在整个应用架构中起到链接的核心作用，比如：

• 在整个系统的入口层，作为流量网关，链接各类终端，管控流量。
• 在微服务场景下作为东西向的网关，链接前台服务和后台服务，肩负流量管控、鉴权等职责。
• 在SaaS行业，开发者平台，API平台这类场景下，作为API网关统一管理各个生态的流量，肩负消费者认证、安全、流控等职责。
• 在AI场景下，作为代理LLM服务的AI网关，肩负基于Token限流、模型切换、多API Key管理、安全等职责。

云原生AI网关简述

云原生AI网关其实并不是一个新的独立的产品，而是属于云原生API网关产品内的一部分功能，基于AI的场景，设计了更贴合AI业务的AI API及各个功能。同时也具备云原生API网关本身提供的各个通用能力。

目前通义、百炼、PAI都集成云原生AI网关，每天承载亿级别的多模态请求，通过真实生产项目去打磨，践行了Dog Food原则。

云原生AI网关整体的核心能分为四大块：

• 多模型适配：可以代理市面上所有主流的模型托管服务，以及兼容OpenAI协议的AI服务。在这个模块中包括协议转换、多API Key管理、Fallback、多模型切换等多个核心功能。
• AI安全防护：安全防护分为三个层面，一个是输入输出的内容安全防护，另一个是保护下游LLM服务的稳定，以及管控AI接口消费者。在这个模块中包括内容审核、基于Token的限流降级、消费者认证等多个核心功能。
• AI插件：AI网关的灵活扩展机制我们使用插件的形式来实现，目前有很多预置的插件，用户也可以开发自定义插件来丰富AI场景流量的管控。比如基于AI插件机制我们实现了结果缓存、提示词装饰器、向量检索等能力。
• AI可观测：AI场景的可观测和传统场景的可观测是有很大区别的，监控和关注的指标都是不同的，云原生AI网关结合阿里云日志服务和可观测产品实现了贴合AI应用业务语义的可观测模块和AI观测大盘，支持比如Tokens消费观测，流式/非流式的RT，首包RT，缓存命中等可观指标。同时所有的输入输出Tokens也都记录在日志服务SLS中，可供用户做更详细的分析。

云原生AI网关代理LLMs方案

从上图架构中可以看出，AI网关代理LLM方案的架构并不复杂，但是在AI应用上生产的过程中通常会遇到9个核心的问题，然而在上面这个并不复杂的架构下，通过AI网关都可以很有效的解决。接下来我们通过用户视角、业务场景视角来逐一分析和说明。

解决用户管理失控的问题

现在大大小小的企业应该都在部署LLM，想方设法的融入到业务中，或日常工作中，那么站在运维团队或者类似中台团队的视角下，可能会有两个核心的问题：

• 核心问题1：我以什么样的方式将LLM服务和能力暴露给大家呢？
• 核心问题2：企业内部部署DeepSeek R1 满血版，公司好几千人，但GPU资源有限，如何限制用户？

第一个问题很好解决，OpenAI API的协议基本已经是标准协议，目前市场面上几乎所有的LLM都支持OpenAI API协议。所以提供遵循OpenAI API协议的HTTP接口就可以让企业员工通过各种方式使用LLM服务和能力。

对于第二个问题，AI 接口一旦暴露出去，基本上不可能只让一小部分人知道，所以需要对访问LLM服务的用户做以限制，只让能访问的人访问，不能访问的人即便知道了接口也无法访问。

所以可以使用AI网关具备的消费者认证的能力来解决这个问题。

核心逻辑是将一个人或一组人抽象为消费者的概念，可以对消费者做权限配置，既可以访问哪些接口，消费者下可以生成不同类型的API Key，请求接口时需要带着API Key，然后基于权限规则去校验API Key的合法性。通过这种就可以精细化的管理访问AI接口用户了。

消费者认证的核心价值：

• 身份可信：确保请求方为注册/授权用户或系统。
• 风险拦截：防止恶意攻击、非法调用与资源滥用。
• 合规保障：满足数据安全法规及企业审计要求。
• 成本控制：基于鉴权实现精准计费与API配额管理。

典型鉴权场景与API Key应用场景：

• 第三方应用接入：
  • 挑战：开发者身份混杂，权限难隔离。
  • 解决方案：为每个应用分配独立API Key，绑定细粒度权限策略。
• 企业内部服务调用：
  • 挑战：内网环境仍需防越权访问。
  • 解决方案：API Key + IP白名单双重验证，限制访问范围。
• 付费用户API访问：
  • 挑战：防止Key泄露导致超额调用。
  • 解决方案：针对API Key限流。
• 跨云/混合部署：
  • 挑战：异构环境统一身份管理。
  • 解决方案：集中式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的维度），且上调比较困难。所以很多客户都有这个核心问题：如何突破这个限制问题？

这个问题有两类解决方案：

• 我们知道这些平台上调限制额度比较困难，那么就用曲线救国的方式，既多申请一些帐号，来变相的把限制额度撑大，但是又会带来新的问题，那就是这些帐号的API Key如何管理的问题。
• 另一个方法就是对输入/输出内容做缓存，减少对模型服务的请求次数以及Token消耗，从而提升业务侧的请求性能，相当于变相增加了限制额度。

多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服务会请求失败，有什么办法可以保证业务健壮性？

这类问题可以有两种做法，并且可以搭配使用：

• 可以构建多个个兜底模型服务，如果要保证模型一致，可以主力使用PAI上部署的，兜底使用百炼平台提供的。实现当PAI上部署的DS服务请求失败时，Fallback到百炼平台托管的DS R1 服务。从而保证业务的连续性和健壮性。
• 通过基于Tokens的限流策略，解决Burst流量，保护后端模型服务。

LLM服务Fallback

云原生AI网关在AI API维度支持LLM服务的Fallback机制，并且可以配置多个Fallback LLM服务。当主LLM服务因为各种原因出现异常，不能提供服务时，网关侧可以快速将请求Fallback到配置的其他LLM服务，虽然可能推理质量有所下降，但是保证了业务的持续性，争取了排查主LLM服务的时间。

Token维度限流

除了传统的QPS限流降级以外，云原生AI网关支持更贴合LLM推理场景的Token维度的限流能力。可以针对AI API级别配置一个下游LLM服务可以承载的请求量级，在一定程度上保证了整体业务的健壮性，至于被限流的请求，可以返回一些人性化的信息，比如DeepSeek官网的服务器繁忙。

我们可以再延伸一下基于Token维度限流的其他核心价值：

• 成本管理：LLM的费用通常基于Token数量计算，限流帮助用户避免超支。例如，服务提供商可能按Token使用量提供不同定价层。
• 资源管理：LLM需要大量计算资源，限流防止系统过载，确保所有用户都能获得稳定性能，尤其在高峰期。
• 用户分层：可以基于ConsumerId或者API Key进行Token限流。
• 防止恶意使用：通过限制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 网关可观测核心能力：

• 访问日志，其中的ai_log字段可以自动打印大语言模型的输入、输出。
• 大语言模型的metrics信息： 首字延时（TTFT-Time To First Token）, tokens per second。
• 传统指标： QPS( request per second), RT(延时），错误率。
• 网关功能指标：
  • 基于consumer的token消耗统计(需要把consumer的header信息加到sls的日志里）
  • 基于模型的token消耗统计。
  • 限流指标: 每单位时间内有多少次请求因为限流被拦截; 限流消费者统计（是哪些消费者在被限流）。
  • 缓存命中情况。
  • 安全统计：风险类型统计、风险消费者统计。