1. 我一开始是拒绝的为什么最终又上了 AI API 网关先说个背景。我们团队做的是 AI Agent 类产品底层会同时调用 OpenAI、Anthropic 以及国内几家大模型厂商的 API。早期模型调用量不大代码里直接写 SDK、配几个 environment variable 就完事了根本没有任何中间层。那时候我的态度很明确谁要跟我提API 网关四个字我就觉得谁在给架构加戏。为什么会有这种抵触心理说白了经历过传统微服务网关的人都有类似的痛。Kong、APISIX、Spring Cloud Gateway 那一套配置复杂、升级要谨慎、出了问题排查链路特别长。AI 调用本来就是一个外部依赖只要它稳定能用就行我不想为了它再维护一套高可用的中间件。但是后来接入的模型越来越多问题就来了而且是很低级、很具体的问题。最典型的场景是不同厂商的 API 风格完全不同。OpenAI 的 chat completion 是这种写法Anthropic 的 messages API 是另一种 schema国内某厂商的接口看起来是 OpenAI 兼容格式但 text/event-stream 的流式响应用户名的字段命名又有出入还时不时会在 HTTP header 里塞一些自定义字段。代码层就出现了一大堆if (provider xxx)的分支判断。最开始还好只维护两家到第三家、第四家接入的时候我意识到这已经不是多写几个函数能解决的事了。另外一个让我崩溃的点是密钥管理。当时 API key 直接存在后端服务的环境变量里调用方一多key 就在各个服务里滚来滚去。前端测试环境要一个内部工具要一个数据分析脚本还要一个。改一次密钥所有部署过的服务都得跟着改。更麻烦的是没法做按项目、按团队粒度的权限控制和配额限制。说白了谁拿到 key谁就能把预算烧穿。于是我开始重新评估 API 网关这个方案。我的结论是AI API 网关和我以前抗拒的传统 API 网关虽然共享一套理念但面向的对象和关注的重点差别很大。传统网关管的是东西向和南北向流量核心是服务发现、负载均衡、路由、限流而 AI API 网关管的核心是对外部模型服务的统一接入它更像是一个模型适配层 密钥保险箱 流量调度器的组合体。想清楚这一点我对它的接受度提高了很多。后来我们还是上了。不是一步到位上了全家桶而是从最小可行方案开始先解决最痛的点再逐步扩展。这篇文章就是用了几个月之后的完整复盘哪些问题真被解决了哪些问题压根没动甚至新引入了一些麻烦我都会一一说清楚。2. 它真正解决的问题接口混乱、密钥失控与流量治理2.1 统一入口后业务代码终于不用关心厂商差异了我们最终选型时考虑到自建成本决定先从开源方案入手选了基于 Java 实现的开源 AI 网关项目。选它的主要原因是支持 OpenAI 协议兼容转发而且可以自定义模型路由规则社区也比较活跃。这只是我们团队的选型决策不是唯一答案。你可以根据自己的语言栈和场景去选关键是它得具备统一入口、路由转发、密钥托管、可观测这四个基础能力。在没有网关之前业务代码里的调用逻辑大概是这样的# 伪代码改造前的多厂商调用 async def chat(messages, providerNone): if provider openai: return await openai_chat(messages) elif provider anthropic: return await anthropic_chat(transform_messages_for_anthropic(messages)) elif provider deepseek: return await deepseek_chat(messages) else: raise ValueError(fUnknown provider: {provider})每接一个厂商就要新增一个分支还要保证各家参数temperature、max_tokens、top_p 这些的语义一致。有的厂商不支持top_p有的把max_tokens命名为max_output_tokens你都得默默吞掉差异。零散调用一旦多起来这种适配代码会越来越脏而且很不容易测试。网关引入之后业务侧只需要连一个固定的 endpoint统一用 OpenAI 格式发请求。网关内部做协议转换和参数映射该去掉的参数去掉该翻译的字段翻译。伪代码就变成这样async def chat(messages, modelpublic-model): # 调用网关的统一接口model 是业务侧可见的逻辑模型名 return await gateway_chat(messages, model)这个感受是很直观的。代码变干净了新接入一个模型厂商时不再需要改业务代码只是跑到网关管理台加一个上游模型和路由规则的事。团队里的新同学上手成本也低不用再理解为什么这段逻辑要针对某家厂商单独写适配。2.2 密钥集中托管老板再也不用担心我把 key 写在代码里密钥管理的改变是明显且立竿见影的。以前各个服务的环境变量里存着各家厂商的 key时间一长你根本想不起来哪个 key 用了哪张账单。现在我们只在网关那里配置真实的供应商 key业务侧通过网关分配的虚拟 key 去调用。虚拟 key 这个设计非常好理解它就像你公司门禁卡不直接暴露总钥匙每个人拿的是一张独立登记的卡哪天离职/转岗了单独吊销那张卡就行。类似的业务侧和内部工具各拿一个 token哪个项目的用量异常按 token 一查就查出来了。同时还解决了配额管理的问题。以前给多个团队共用同一把 key根本不知道每个团队烧了多少钱成本归因完全靠猜。现在可以在网关给不同业务分配合适的限额超了就自动告警或熔断。这在多团队协作的工程环境里价值非常大。2.3 流量治理限流、重试、熔断不再是每家厂商各搞一套AI 模型供应商的接口并不总是稳定。有些厂商在高负载时段会大量返回 429限流或 5xx服务端错误。以前这些错误处理逻辑散落在业务代码里每个调用方都得自己写重试、退避backoff和降级策略。实测下来经常出现 2 个服务同时在重试同一家厂商的情况导致限流更严重雪球效应特别明显。网关把这个统一接管了。我在网关层做了全局的限流配额比如对某家厂商的 QPS 上限控制在它文档承诺的合理范围内同时在网关层配置了指数退避重试。如果上游连续报错网关还能触发熔断自动把请求切到候选模型或返回降级提示。这种集中管理还有一个意外的好处变更不那么吓人了。以前业务代码里想改个重试策略需要改代码、发布、等生效。现在是改配置几秒钟就生效。试错成本低大家也就更愿意把参数调优而不会因为改代码又要发布而凑合着用一套不合理的重试策略。2.4 可观测性从不知道谁在调模型到谁在什么时候调了哪个模型花了多少钱日志和指标这个问题是我前期最低估的。人工调用模型的时候总觉得自己对调用量心里有数。直到上了网关看了一周数据才发现真实调用量比我想象的要高出一倍不止。原因是有个内部定时任务在跑批处理每次循环都会调用模型量大且低频日常监控完全没注意到。网关天然适合做这层记录。每个请求进来是哪个应用调用的、走的哪个模型、生成了多少 token、耗时多少、费用是多少、上游是否重试过这些信息全都有。网关侧再把这些指标接到 Prometheus/Grafana或者直接看管理面板里的汇总统计整个成本分布一目了然。支付层面看得见之后意外的价值是省钱。我们统计了每天的 token 消耗发现有一类场景大家都在用贵的旗舰模型但实际上任务难度并不高换个小参数模型完全够用。后来直接加了路由规则把这类请求转发到便宜模型月账单肉眼可见地下降了。这种东西没有网关数据支撑基本靠拍脑袋。3. 没解决的那部分模型能力焦虑、业务侵入与成本降不下来的真相3.1 网关不改变模型本身的能力答案质量该差还是差这一点是我特别想说的。好多人容易产生一个错觉上了 AI 网关模型调用变稳定和智能了。网关说白了只是一个API 入口 路由 治理的中间层它不包含任何模型能力。你原来用某个模型得到的结果质量是什么样的换了网关之后还是什么样。它不会帮你把 prompt 变得更聪明也不会减少模型幻觉。在实践中遇到的具体问题是我们需要模型输出做结构化抽取和 JSON 格式化。并不是所有模型都支持严格的输出格式约束。网关能做的是把请求转发过去如果模型输出了非法 JSON网关可以做一次轻量修正或者返回错误但它不会自动为你设计更好的 prompt 或抽取方案。所谓能力增强的诉求网关完全不负责。所以如果你的痛点本质上是模型回复质量差、逻辑不对、幻觉太多那解决方案不是折腾网关而是换模型、调 prompt、做 RAG、做 post-processing。把网关当成模型能力增强器方向就错了。3.2 业务与模型粘得太深时统一路由也救不了你网关解决的统一接口前提是不同厂商的模型能力差异可以被一个抽象接口屏蔽掉。但现实是很多业务场景跟模型的某些特定能力深度耦合。比如你依赖某家模型的 function calling 格式换成另一家之后格式完全变了又比如你针对某家的系统提示词做了大量调优同样的话术在另一家模型上效果可能一塌糊涂。这些差异网关只解决到协议层解决不了语义层。而且有些模型有自己特殊的参数比如 reasoning models推理模型会有reasoning_effort这样的控制项。OpenAI 兼容格式当然可以定义这类扩展字段但每个厂商的参数覆盖范围不一致。网关在做参数透传和模型路由的时候经常会遇到请求里的某个参数只有某家模型支持的情况。你要么在网关做参数治理要么就只能针对特殊模型走直连。这两种方案都不完美前者增加配置复杂度后者又把统一入口打折扣了。3.3 成本只是可观测了不等于降低了刚才我说网关帮我们砍了一部分不必要的模型调用费用但必须承认成本的最大头仍然来自那些真正需要大模型出力的核心链路。这部分成本网关是真降不了。你不能指望路由到便宜模型就能带来数量级的降本因为便宜模型的输出质量和准确率往往与核心业务要求不匹配。这里需要区分成本优化和成本显性化两个概念。网关做的事情主要是后者。它把成本从一个黑盒变成一个精确的数字让你知道钱花在哪了能找出明显浪费的点。但如果你试下来确实需要跑那么多量、那么多 token那么成本的总体水平是刚性的能不能降下来取决于你对业务链路的优化和模型选型而不是网关本身。坦白说我后来一度期待网关能够自动帮我做模型选择比如根据请求的复杂度和预算自动切换。但现实是目前主流的网关在这块还是以人工配置规则 按比例分流为主真正的动态模型路由和自动调度还在很初级的阶段。别神话它。3.4 引入新层必然引入新的故障点这个话可能不太中听但确实是我们实际遇到的情况网关引入之后线上故障拓扑多了一层排查链路也多了一个环节。有一次某个模型厂商的接口返回了一种特殊的重定向状态码网关没有正确处理导致请求失败。而以前直连的时候SDK 会自动跟随重定向根本不会出问题。排查到最后发现是网关的 HTTP client 配置过于严格。这种例子虽然不多但说明一个问题中间层引入的任何行为偏差都会成为新的异常来源。网关本身是高可用组件但它在请求链路上就一定有单点风险即使做了多副本也会有配置同步、网络超时等新的问题。我们在用了一段时间之后专门给网关服务配了独立的监控告警确保它不会成为静默故障的黑洞。4. 什么样的情况建议别上我从教训里总结的选型边界4.1 只有一家模型供应商、调用量也不大的阶段这是我最想说的一条。如果你的项目还处在模型供应商很固定比如基本只用 OpenAI 一家且调用量很低的阶段那完全没有必要引入网关。所谓统一入口的优势只有在你的上游和下游都比较多样时才有意义。否则你只是在为一个本来很简单的问题增加不必要的抽象。有个朋友问我我们想接一个开源 AI 网关为了以后扩展方便应该什么时候开始搞我的回答是等你真的需要接第二家、第三家厂商或者你的业务侧已经有多个服务在并发调用模型、导致密钥和限额管理失控的时候再考虑。太早引入你会花很多精力去配置、维护一个没有发挥出价值的中间层团队内部还会有这层有必要吗的质疑。4.2 业务与某一家模型深度绑定模型切换成本很高如果你的业务重度使用某些厂商特有的能力比如自定义的 function calling 格式、特殊的 embedding 维度、独有的多模态接口而且这些能力一时半会儿没替代方案那网关的多模型路由对你来说基本是纸面能力。因为你根本切不动路不路由无所谓。这种情况你更需要的是一个稳定的专线转发者而不是模型路由器。你要做的是:确保这一条链路稳定、可观测、安全。网关确实能提供这些但你要清醒地认识到它能为你的业务带来的灵活性红利其实很小。4.3 团队没有专职的基建/平台开发同学网关一旦引入就变成了基础设施的一部分。它不是配置好一次就万事大吉的。你需要有人去维护它的版本升级、证书轮换、上游模型配置、监控告警以及排障。如果你所在的团队只有两三个后端而且平时已经忙得不可开交那再加一个网关除了增加维护负担可能还会挤占你真正写业务功能的时间。我个人觉得更合理的方案是在这个阶段使用云厂商提供的托管 API 网关服务或者干脆使用那些专门做 AI Gateway 的 SaaS 产品把维护这个最大的隐性成本外包出去。等团队规模大了、有专门的平台工程师了再考虑深入自建。4.4 对延迟有极致要求的时候多一跳都是不能忍的虽然一个设计良好的网关引入的额外延迟通常在几毫秒到十几毫秒之间在绝大多数业务场景里可以忽略不计。但如果你的产品线对首 token 延迟有极高的要求或者需要把大模型调用嵌入到最低延迟链路里比如实时交互场景那么每多一个网络跳转都是不可接受的。这种情况我的建议是网关只做旁路而不是主路径。什么意思可以保留直连方式给那些核心低延迟场景网关则主要服务于普通业务和内部工具。当然这就需要你在架构设计上提前做好双通道的抽象不要把所有调用都绑死在一个中间层上。5. 落地过程中的几个坑以及我用到的补救方案5.1 授权与鉴权的归属问题差点让我栽了跟头开始搭建网关时我以为网关的鉴权可以包办一切。其实不是。网关管的是谁是合法的调用方但调用方是否有权限调用某个模型这个层面的鉴权需要你自己去设计。举例来说两个内部服务都用了同一个虚拟 key但其中一个服务不应该访问某些费用较高的模型。这个控制很多网关默认并没有做“模型级”的细粒度授权。我们的处理方式是在网关前面再套一层内部服务认证一个轻量 sidecar专门校验 JWT然后把用户身份信息通过请求头传给网关网关再结合身份信息做模型级的路由白名单校验。听起来有点绕但实际操作下来是可行的而且安全性好了很多。你现在如果准备上网关我建议把服务对模型的授权模型提前设计好不要指望网关默认满足你。5.2 SDK 的重试逻辑和网关的重试策略互相叠加结果雪上加霜这就是我前面提到的一个细节以前直连 API 时OpenAI SDK 默认会有几次重试。上了网关之后SDK 会把请求发给网关而不是直接发给厂商。这时候如果 SDK 自带重试网关也配置了重试那一个 429 错误就可能引发多次请求放大。我们曾经有一次上游模型服务抖动结果网关和 SDK 双重重试导致请求洪峰直接打到厂商反而把上游打得更崩了。补救方案有两个一是把 SDK 自带的重试关闭或降到最小重试逻辑统一由网关来管二是在网关回给客户端的响应里尽量透传上游的 Retry-After 头让调用方做更精准的退避等待。实测下来第一种方案更省心逻辑更集中。5.3 模型路由的灰度比想象中粗糙按比例分流不等于真实灰度很多 AI 网关都支持按权重把流量转发到不同模型。我最初做新模型测试时以为有了权重分流就够了于是直接把 5% 的生产流量切到了新模型上。结果新模型在某些场景上的输出格式和旧模型差异很大这 5% 的流量直接导致了线上兼容性问题。这件事给我的教训是你先要在离线评测集上跑一遍再放到预发环境人工验证最后才轮到所谓灰度。网关的按比例分流适合的是已经通过基础验证、只需要小流量监控资源消耗和错误率的阶段而不是用来做模型能力评估的。如果你的新模型在某些边界case上有问题5% 的线上流量也能让你很难看。5.4 观测数据的口径漂移网关侧指标和厂商侧账单对不上网关会统计 request 数、token 数、费用预估但如果你拿着网关的统计去跟厂商账单核对经常会对不上。原因有几个供应商 token 计费有 Cache 和 Prompt/Completion 的拆分差异部分失败请求不收费但网关可能也统计了还有日期时区边界、配额单位千 token 或百万 token等细节。我们后来不追求数字完全一致而是把网关的统计定位为趋势和异常发现厂商账单作为最终成本确认。两边差异允许存在 5% 以内的偏差超过这个范围就会去排查是不是网关漏配或供应商变更了计费规则。不然为了核对几行数字你会消耗掉大量时间而这些时间本可以花在更有价值的事上。6. 后续演进我们从网关走向模型接入平台的几点设想说完了问题和坑还是得分享一下我接下来打算怎么用它。毕竟复盘的目的不是嘲笑自己当初怎么没想到而是找到下一步的改进方向。第一个方向是把模型路由从静态规则升级为动态策略。例如用一个评分器来对请求内容做简单分类是简单摘要还是复杂推理再根据分类和当前各模型的负载、成本、质量分数动态决定转发到哪个模型。这个短期内更多还是基于规则与人工权重但可以在网关的开放接口之上做一层自定义策略引擎思路是通的。第二个方向是增强供应链韧性。以前的架构是我直接依赖某个模型厂商现在是我通过网关依赖一组可能互相替换的模型供应商。未来我想把网关的fallback做得再精细一点比如请求失败后自动降级处理不只是换模型还自动切换不同的 prompt 模板或模板版本。因为不同模型的指令遵循能力不一样一套 prompt 往往不够用需要为 fallback 目标模型准备单独的 prompt 变体。这项能力网关目前不内置但可以通过扩展点来自定义。第三个方向是把计量和成本控制的权力下放到业务团队。以前成本统计只能由基建同学看现在利用网关的租户和配额能力可以把本月各业务线消耗了多少 token、预算还剩多少通过面板开放给各团队自己查看。这让业务同学自己就会动脑筋优化调用方式而不是由基建同学追着他们砍需求。这几个方向都还在设计和验证阶段未必都能落地但至少让我看到了 AI API 网关这个组件的延展边界。它不是终局方案更像是一个可以持续生长的基座。最后分享一个针对模型调用配置管理的个人技巧不管用不用网关把模型供应商的 API 能力差异整理成一份表格放进项目文档里。比如哪家支持 logprobs、哪家的最大输出是多少、哪家的 embedding 维度是多少、哪家的限流策略是什么。这份表格比任何网关维护手册都值钱平时排障、做容量规划都会用到。我们团队现在每次新接入一家厂商第一步就是更新这份表格。这是个笨办法但实际用下来比什么工具都好使。
