Governing Enterprise AI Traffic at Scale: Design and Operation of a Policy-Driven, Multi-Vendor LLM Gateway on Envoy

企业同时用好几家的大模型，每家都有自己的接口格式、密钥、流式协议和价格，如果让每个应用各接各的，很快就会出现密钥满天飞、换模型要改代码、花钱没人管的局面。PayPal 这篇论文介绍了他们的统一大模型网关 Cosmos：基于 Envoy 代理，把认证、预算、策略这类要查外部服务的"慢决策"放到代理外的独立服务里，把格式翻译和计 token 这类逐字节的活放在代理内部，保证流式回复的每一块都不用等外部调用。截至 2026 年 9 月，它服务 1.2 万多名开发者、每天约 2000 亿 token、100 多个模型，压测中只增加 4 毫秒中位延迟。

做模型平台、内部 AI 基础设施或成本治理的工程师值得读，原因是它把一个常被当成"加个代理转发一下"的问题讲透了：网关的难点不在路由，而在身份、预算和策略的治理。核心思想一句话：慢的决策放外面、快的字节处理放里面，模型、价格、策略都写成可校验的数据而不是代码。不过这是一篇生产经验报告，没有和其他网关做对照实验，延迟压测也只覆盖了请求进入阶段，读的时候更适合当架构参考。

它到底在解决什么问题？

用一个场景说明（示意）。一家公司有三个团队：A 团队写代码助手用某家的 Claude，B 团队做客服语音用 Gemini，C 团队做数据分析用 OpenAI。直接对接时：

这说明问题本质上是治理，而不是转发。作者列了十条需求，其中几条决定了架构：客户端继续用熟悉的 OpenAI、Anthropic、Gemini 接口；流式回复不能被缓冲；权限和数据保护出错时要拒绝请求，监控出错时要放行；改模型、改价格、加预算都只是数据变更；几百个已上线的应用不能要求一起迁移。

整体架构

系统由三层组成。数据面是一组自动扩缩的 Envoy 代理，所有请求都从这里进出。控制服务挂在代理外，负责认证调用者、查模型、判权限和预算、换取厂商凭证；它出错时请求直接被拒。代理内部还跑着一个用 Rust 写、编译成 WebAssembly 的过滤器，负责在不同厂商格式之间翻译、并从流里数出用了多少 token。最外层是控制面，管理员在这里登记模型、改价格、写策略，变更会打包成带版本号的"策略包"推给数据面。

为什么要这样拆？因为两类工作的延迟特征完全不同。认证和策略要查数据库、调身份服务，本身就是等 I/O；放在代理外，一次请求只调用一次。翻译和计量要处理流式回复的每一小块，一条回复可能有几千块，如果每块都跨进程走一次网络，延迟会成倍累积。

一条请求怎么走

以一个编码助手用 OpenAI 格式调用 Claude 为例。请求进来后，控制服务先认证调用者是谁，再在注册表里查这个模型名对应哪个厂商部署，用策略引擎判断这个人有没有权限、预算够不够，然后换取厂商凭证、改写请求路径，交回代理。代理把请求体交给翻译模块，转成 Anthropic 格式发出去。回复是流式的，翻译模块每收到一块就转回 OpenAI 格式发给客户端，同时累计 token 数。因为流式阶段不能再改响应头，用量信息放在响应尾部带回，控制服务据此算钱、记账。

翻译用的是"统一中间表示"思路：每种接口格式只写一个编解码器，和一份共同的内部格式互转，而不是每两种格式之间各写一个转换器。5 种格式只需要 5 个编解码器，而不是 20 个两两转换器。如果源格式和目标格式相同，字节原样透传；如果只是同一家换了个外壳（比如同样是 Anthropic 格式、改走谷歌云上的版本），只改外壳字段，内容不动，这样厂商特有的字段不会在转换中丢失。

模型和价格是数据，不是代码

新增一个模型、改一次价格，在很多系统里要发版。Cosmos 把模型、部署、价格、接口能力都写进一个注册表，加载时做严格校验：每个模型声明支持的接口格式，必须至少有一个部署同时具备对应的调用方式和格式转换器，否则整个网关拒绝启动。作者的理由很直接：配置错了就不启动，比启动后把请求路由错安全得多。

价格按每百万 token 记录输入、输出、缓存读写等几档，一次请求的费用就是各类 token 数乘以对应单价再求和。改价格只是一条数据修改，下一个发布周期生效。

策略与预算：判断和动作分开

权限和预算用 OPA（开源策略引擎）写成声明式规则，引擎只负责"判断"，查数据和执行动作都由网关做。这样同一条规则可以先离线测试、先预览"如果现在上线会拦住谁"。

预算设计很巧：网关只按"人 × 模型 × 时间"记最细粒度的用量计数，每个预算都是在这些计数上的一个"视图"。举个例子：某部门月中新设一个 5 万美元的月度上限，网关不需要迁移任何数据，直接把本月已经记下的用量加总，就知道还剩多少。规则还按组织架构里的负责人来写，而不是写团队名单，组织调整后规则不用改。

新规则上线走"影子模式"：先只记录会拦住谁、不真的拦，确认无误再切成强制执行；接近上限时先发提醒，再拦截。

数据保护与长连接语音

数据防泄漏（DLP，即在数据离开公司前检测并处理敏感信息）按用例开启：如果某个业务的数据分级要求做检测，控制服务会在提示词发往外部厂商前检测个人信息和支付信息，按策略选择拦截、打码或替换成假名。这一步失败时请求被拒，而不是带着敏感数据放行。举例来说，客服工单里出现一串银行卡号，发出去之前会被替换成占位符。

实时语音是另一个难点：一通电话可以持续 30 分钟，用的是长连接，而网关每天都可能发版、扩缩容或升级节点。作者在设计时优先考虑"连接怎么建立、保持和收尾"，而不只是单个请求：旧实例收到下线信号后先停止接新连接，留出足够长的排空时间让现有通话自然结束，控制服务则先报告"不可用"再优雅退出。这样设计意味着发版不必挑时间窗口，用户也感知不到。

实验结果

作者对核心请求路径做了延迟压测。上游用一个固定延迟的模拟服务，这样测出来的额外耗时只来自网关本身；分别用 2 台和 4 台 4 核机器，在两档负载下各跑 5 分钟，目的是看负载和机器数翻倍时开销会不会变。

这说明在测试范围内，负载翻倍延迟不变，加机器延迟也不变，开销是固定的单请求成本，而不是排队造成的。生产数据方面，网关可用性 99.999%，单个业务峰值每分钟 6 万请求，支撑 2000 多路并发语音通话，在线上语音流量期间发版 10 多次、零掉线。缓存方面，编码助手每一轮都会重发很长且几乎不变的前缀：系统提示词、工具定义、历史对话。厂商允许在提示词里标记最多 4 个缓存断点，断点之前的内容会被厂商缓存，下一轮前缀完全相同时直接复用、不再重新计算。网关自动在最后一个工具定义、系统提示词和最新一段对话末尾各打一个断点，并申请 1 小时的缓存有效期。在最适合的业务上缓存命中率最高达 96%，因为缓存读取按折扣计费，这直接降低了输入成本，而且客户端不用改代码。

我认为它的局限

1. 延迟压测只测了一半。 指标是"上游开始回复前"的额外耗时，不含流式翻译；所有虚拟用户共用一个凭证，认证结果一直命中缓存；压测机和网关在同一集群。真实业务开启更多策略和数据防泄漏检测后，开销会更高，作者也说明没有测超过每秒 2262 个请求的饱和行为。
2. 没有对照实验。 2000 亿 token、99.999% 等都是生产统计，没有和其他开源网关或托管网关在同一负载下比较，很难判断这套架构相对别的方案好多少。96% 的缓存命中率也只是最好的业务。
3. 集中化也集中了风险。 网关替所有厂商保管凭证，本身就是高价值攻击目标；它的权限管理、密钥处理和变更控制都必须达到最敏感业务的标准，这部分成本在文中只有原则性描述。

一个团队可以怎么借鉴

1. 先套壳，不重写。 在现有调用路径前加一层代理，所有流量先经过它，再把认证、凭证、计费逐项挪进去，不要求业务方改代码。
2. 按延迟特征拆分。 把要查外部服务的决策放到代理外，逐字节的处理放在代理内，并在两者之间写清楚接口契约和测试。
3. 用量记最细粒度。 按人、模型、时间记原始计数，预算做成视图，新规则先跑影子模式再强制执行。
4. 配置严格校验。 模型、价格、策略都做成数据，加载时校验失败就拒绝启动。

一句话结论

Cosmos 给出了一份很完整的企业大模型网关设计清单，最值得借鉴的是"慢决策放外面、快处理放里面"和"预算即视图"两条。