AI 网关代理 LLMs 最佳实践

随着 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 普惠市场的基石。

在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 配额限制，需要一个好的方式能够做到快速扩展配额限制。

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

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

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

云原生 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 网关代理 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 语法来匹配模型名称，从而实现上述需求。

再延伸一下模型切换的核心价值：

• 业务需求适配：根据业务复杂性或性能要求选择不同模型。
• 数据隐私与合规性：在处理敏感数据时，可能需要切换到符合特定法规的模型，确保数据处理的安全性。
• 性能优化：根据实时性能需求，可能会切换到更快的模型以减少延迟。
• 成本与性能平衡：根据预算动态选择性价比最优的模型
• 领域特定需求：针对特定领域（如法律、医学），可能需要切换到在相关领域微调过的模型，以提高推理准确性。
• 容灾与故障转移：主模型服务异常时快速切换备用模型。

像 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 观测大盘，支持比如 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 消耗统计。
•  限流指标: 每单位时间内有多少次请求因为限流被拦截; 限流消费者统计（是哪些消费者在被限流）。
•  缓存命中情况。
•  安全统计：风险类型统计、风险消费者统计。