AI Gateway 与 Provider 抽象：策略和配额该放在哪一层

比较 In-app Provider SDK、Central AI Gateway、Federated Gateways 与 Provider-managed Aggregator 四种拓扑：格式翻译和策略在哪个节点执行、凭证和配额归谁所有、一个组件挂了波及多少消费者，以及配错或选错 provider 时怎么收住。

多个应用调用多家 provider，每家都有自己的请求格式、凭证、每分钟 token 配额、区域和故障行为。总得有人翻译格式、保管凭证、在消费者之间分配配额、绕开故障、记下谁花了多少钱。AI gateway 设计只有一个问题：这个「有人」在哪一层？ 展开是四问：在每个应用里、在一个共享网关里、在一组受同一份策略约束的网关里，还是在第三方的服务里；策略状态归谁；一次故障或一次配错波及多远。

想亲手走一遍四种拓扑、注入故障再恢复，打开互动 Lab：/system-design-lab/ai-gateway-provider-abstraction-architectures。

有约束的设计问题

一家公司先后遇到四种局面：一个团队做一个应用，接两三家 provider，配额不和任何人共享，想尽快上线；十几个应用调用同样的 provider，要按应用限额和分摊成本，凭证不能散落在各个应用里；多个团队各自发版、各自的故障不能互相波及，但允许的模型、预算和区域要全组织统一；一个很小的团队要试很多模型，没有精力运维网关，数据处理条款可以接受。每一种该用哪个拓扑？

四种 topology signature

架构	翻译和策略在哪执行	State owner	故障域	适合	主要代价
In-app Provider SDK	每个应用内部	每个应用自己的配置（key、provider 选择）	那一个应用	一个应用、一个团队、少数 provider	key 每个应用一份；没有共享配额；重试各写各的；能力差异不被抹平
Central AI Gateway	一个共享网关	网关的 policy store（key、按消费者配额、路由）	所有消费者	多个应用共用 provider 和配额	单点；多一跳延迟和攻击面；一处配错全体受影响
Federated Gateways	每个团队一个网关，规则来自共享目录	policy catalogue（组织规则）+ 各网关本地状态	每个网关一个团队	需要隔离和自主的大型组织	多个网关要运维；网关之间漂移；目录成为新的协调点
Provider-managed Aggregator	第三方服务内部	应用的 routing preferences（顺序、回退、数据政策）	所有用聚合器的应用	小团队想要很多模型、零基础设施	数据经过第三方；provider 有差异；聚合器挂了全停

1. In-app Provider SDK：抽象层是应用里的一个库

应用链接一个库，用同一套接口调用多家 provider，库把调用翻译成各家的格式；key、重试、选哪家都写在这个应用自己的配置里。Vercel AI SDK 的说法是提供「一个语言模型规范」来「抽象 provider 之间的差异」，于是「这个统一接口让你可以轻松切换 provider，同时对所有 provider 使用同一套 API」，规范本身「作为开源包发布，你可以用它创建自定义 provider」。同一份文档也说清了抽象没有做到的事：「AI provider 支持的语言模型能力各不相同」，图片输入、结构化输出、工具调用都要按模型逐个确认。

代价在应用一多就暴露。Microsoft 的网关指南写明，没有网关时「你需要自己实现重试机制、熔断器和退避策略」，而且「把配置变更推到多个客户端会引入部署风险」。具体的坑有三个：一次调试把带 key 的请求头打进日志，key 泄露，拿到它的人就是这个 provider 账号；第二个应用复制了第一个应用的配置，两个应用打同一把 key，高峰时一起收到 429，谁也不知道是谁用光的；为了省钱把 provider 从 A 改成 B，B 上的模型不支持工具调用，所有依赖工具的功能开始返回「看起来正常其实什么都没做」的回答。key 放密钥管理器、每个应用一把、切换前跑能力测试——然后在第二个应用出现的那天上网关。

2. Central AI Gateway：一个共享网关，按消费者限额、转格式、托管凭证

所有应用调用同一个网关，拿的是网关发的虚拟 key。网关先按这把 key 查策略仓库里的配额，扣掉这次的 token，再把请求翻译成 provider 的格式、带上网关托管的真实凭证发出去；provider 返回 429 就按 Retry-After 熔断换另一家；每次调用的 token 和成本按消费者记进遥测。

Azure API Management 把理由说得很直接：「当你的应用组合增长，可能有多个应用调用一个或多个 AI 服务端点……你需要确保一个应用不会用光整个 TPM 配额而阻塞其他应用」。它的 token 限额策略按计数键（订阅 key、来源 IP 或任意表达式）设「TPM 上限或某个周期内的 token 配额」，并「在 API Management 侧预先计算 prompt token」，prompt 本身超限的请求不再打后端；后端熔断器「应用后端返回的 Retry-After 头里的值」；用托管身份调用后端，「不需要 API key 做认证」；统一模型 API「通过一个 OpenAI 兼容端点暴露多个后端，自动处理格式转换，让你对所有模型一次性应用治理策略」。Kong AI Gateway 的表述是「通过一个一致的 API 连接任何主流 LLM provider，切换或组合 provider 而不用重写集成」，凭证集中管理后「轮换它们不用碰每个团队的配置」。LiteLLM Proxy 是「调用 100+ LLM 的统一接口，跟踪花费、按虚拟 key / 用户设预算」。Cloudflare AI Gateway 提供「请求数、token 数和运行成本」的分析、缓存、限流、「请求重试和模型回退」，接入「只要改一行代码」。

代价同样来自 Microsoft 的清单：「网关方案可能引入单点故障」，「扩大了工作负载的攻击面」，「每次 API 调用都增加延迟」，流式响应要求网关「支持长连接而不过早超时或缓冲」，有状态 API 要求会话亲和；一句话总结是「如果网关危及工作负载达成既定 SLO 的能力，就不要实现网关」。三个具体的故障：网关只有一个实例，一次配置部署把它打挂，所有应用一起停；App B 上线时忘了配限额，它的批处理一分钟发了几万次请求，Provider 的配额被它一家用完，App A 开始收到 429；有人把默认路由指向了一个还没开通的后端，一次发布所有应用同时报错。修法对应三条：跨可用区多实例、健康检查、纳入故障模式分析，关键消费者保留降级的直连路径；每把虚拟 key 必须有每分钟 token 上限，调用前估算 prompt token；策略版本化，先对金丝雀消费者生效再全量，出问题回滚。

3. Federated Gateways：每个团队一个网关，规则来自同一本目录

每个团队或工作负载运行自己的网关，故障和配置错误只影响这个团队；组织级的规则（哪些模型可用、每个团队的预算、数据能去哪个区域）写在一本共享的策略目录里，每个网关按版本同步并执行。

Azure API Management 把「联邦网关」列为超出单一集成网关的高级场景，它与 Foundry 集成的网关「设计为支持单个 Foundry 资源的入口，不跨多个资源」，需要更多的工作负载「自己实现网关」。Microsoft 要求把网关「纳入工作负载的故障模式分析」，并指出没有网关时「客户端必须各自表现良好、在有限容量面前对其他客户端公平」——联邦回答的正是这两件事：团队内的公平由团队网关执行，团队间的公平由目录执行。Kong 的「托管控制平面 + 运行在用户环境里的数据平面」是同一种拆分：规则在一处，执行贴近每个工作负载。Agent Router（原 Envoy AI Gateway）给出的适用条件也一样：「多个应用或团队共享模型或工具」，以及「provider 凭证不应该存在于应用工作负载里」。

代价是要运维多个网关，网关之间会漂移，目录成了新的协调点。目录在 v13 下线了一个模型，团队 B 的网关同步任务因为网络故障停在了 v12，团队 B 的应用继续调用一个组织已经禁用的模型。同步带版本戳，每个网关上报自己执行的版本，落后超过阈值就报警，关键下线可以强制推送并要求确认。另一个坑是静态划分：配额按团队五五分，团队 A 的大促流量把自己的份额打满，团队 B 那一半整晚没人用，团队 A 的用户收到 429 而 provider 的总配额一半是空的。用共享遥测看实时用量，做动态份额或有上限的借用——借用要有上限和优先级，别让它把隔离又变回共享故障。

4. Provider-managed Aggregator：网关是别人的，你只拥有路由偏好

应用不接任何 provider，只接一个第三方的统一入口。OpenRouter 的默认路由「优先选择最近 30 秒内没有明显故障的 provider」，再按价格加权；请求里可以指定 order（provider 顺序）、allow_fallbacks: false（禁止回退到别家）、only 和 ignore、require_parameters、量化精度过滤、data_collection 数据政策，甚至「只路由到零数据保留（ZDR）端点」；费用「因 provider 和模型而异」，按实际路由到的那家计费。Portkey 提供「通用 API」、「provider 和模型之间的回退」、「在多个 API key 之间负载均衡以对抗限流」、条件路由、预算和护栏，托管或自建都可以。

代价是你的系统里只剩一份路由偏好，而 Microsoft 关于网关「处在能看到原始请求数据和模型响应的独特位置」的提醒在这里更重：聚合器在你的合规边界之外。偏好里忘了写数据政策，聚合器按价格把一个零保留用例的请求送到了会保留 prompt 的 provider C，产品对用户的承诺在这一次调用里就被打破了；在偏好里钉死数据政策和 provider 顺序，每个回答记录实际 provider 并定期审计。聚合器整体故障时，各家 provider 都好好的，你的产品一次模型调用都发不出去；保留一条用自己的 key 直连某家 provider 的后备路径，把聚合器纳入故障模式分析并演练降级。

四种拓扑共同的底线

provider 的 Retry-After 和配额是事实，不是猜测。 熔断按它驱动，重试按它退避。
抽象层只改格式和凭证，不改模型能力。 切换前按模型跑能力测试。
消费者永远不持有真实 provider 凭证。 虚拟 key 映射到网关托管的凭证，轮换不碰消费者。
限额按消费者，在调用前执行。 没有按消费者限额的共享配额，就是共享的故障。
每次调用记下消费者、网关实例、实际 provider 和后端、token、成本、生效的策略决定。 成本分摊和「谁用光了配额」只有这里能答。

故障与恢复

架构	故障	用户看到什么	恢复
In-app Provider SDK	一个应用配置里的 provider key 泄露	账单和配额被冒用	key 放密钥管理器、每个应用一把、轮换；应用多了移进网关
In-app Provider SDK	两个应用用同一把 key 把配额抢光	两个产品同时收到 429	每个应用自己的 key 和份额，或上按消费者限额的网关
In-app Provider SDK	换 provider 后工具调用悄悄失效	回答看起来正常其实没做	切换前按模型跑能力测试；能力要求写进配置
Central AI Gateway	网关宕机	所有应用一起停	跨可用区多实例、健康检查、故障模式分析；关键消费者降级直连
Central AI Gateway	一个没配限额的消费者用光配额	别的应用收到 429	每把虚拟 key 必须有 TPM 上限；调用前估算 prompt token；优先级留配额
Central AI Gateway	一次策略修改改坏所有路由	所有应用同时报错	策略版本化 + 金丝雀消费者 + 回滚；发布前测试路由
Federated Gateways	团队网关和目录漂移	继续调用已禁用的模型	同步带版本戳，网关上报版本，落后报警；关键下线强制推送
Federated Gateways	静态份额一边闲一边限流	一个团队收到 429 而总配额有空	共享遥测做动态份额或有上限的借用
Provider-managed Aggregator	请求路由到会保留数据的 provider	零保留承诺被打破	偏好钉死数据政策和顺序；记录实际 provider；审计

怎么选

一个团队一个应用，配额不共享：In-app Provider SDK，key 进密钥管理器，切换前跑能力测试；第二个应用出现就上网关。
多个应用共用 provider 和配额：Central AI Gateway，虚拟 key、按消费者限额、Retry-After 熔断、托管凭证、按消费者遥测；多实例并纳入故障模式分析。
团队要隔离、组织要一本规则：Federated Gateways，每个故障域一个网关，一本策略目录按版本同步，共享遥测跨团队看预算。
小团队想要很多模型、零运维、数据条款可接受：Provider-managed Aggregator，偏好里钉死数据政策和顺序，记录实际 provider，保留直连后备。
无论哪种，抽象层只改格式和凭证，不改能力；Retry-After 和配额按事实处理。

回到开头的四种局面：单应用走 SDK；十几个应用走 Central AI Gateway；多团队走 Federated Gateways；小团队试模型走 Aggregator。

面试时这样回答

先复述约束：几个应用、共不共享配额、团队要不要隔离、能不能运维、数据条款。
说调用路径：点名图上的边，例如「SDK 读应用配置后直连 provider」「网关按虚拟 key 查配额扣 token，转格式带托管凭证，429 按 Retry-After 熔断」「目录同步规则到团队网关」「后端读偏好，聚合器按可用性和价格选」。
说策略和凭证归谁：应用配置、策略仓库、策略目录，还是路由偏好。
说代价与一个故障：例如一个没配限额的消费者用光配额会让别的应用收到 429，修法是每把虚拟 key 必须有 TPM 上限并在调用前估算 prompt token。