从上周处理线上故障到现在我一直对着一组日志发呆。两条超时记录来自两个不同的大模型供应商分别打在我们两个后端服务的调用链路上。表面上看是供应商侧不稳定但真正麻烦的是我为了追这两个问题得同时打开两套完全不同风格的控制台用两套不同的请求ID格式去查链路然后把这半年来团队架构上所有临时补丁都过一遍——某个服务直接写了OpenAI SDK另一个服务自己封装了一套阿里云兼容协议还有一个服务干脆用HTTP call直连国外模型。那一瞬间我特别清醒业务代码早就被多模型接入的差异绑架了而这正是AI网关存在的理由。这篇文章我想把我们从原型验证到生产落地AI网关的完整过程复盘一遍。会讲到多模型管理的痛点到底在哪里、原型阶段该验证哪几条链路、生产落地时有哪些配置是一开始没做后面哭着补的以及一些测试环境完全暴露不出来的坑。适合后端工程师、AI平台负责人以及正在纠结要不要引入AI网关的团队。1. 多模型管理混乱的根源不只是多接一个API很多团队最初的想法都一样多个模型供应商不就是多写几个适配器的事吗真不是。随着接入的模型越来越多你会发现差异散布在每个层面而每个层面的差异都在消耗研发时间。1.1 协议、鉴权、限流、计费这四个维度各不相同先说一个最基础的表格对比这是当时我整理给团队看的拿来对齐认知特别有用。维度供应商AOpenAI兼容供应商B国内云厂商供应商C开源模型自建协议格式OpenAI Chat Completions风格自定义JSON结构字段名都不同OpenAI兼容但有额外参数鉴权方式Bearer Token请求头固定AK/SK签名还要计算时间戳私有Token有时还带IP白名单限流维度RPM每分钟请求数TPM每分钟Token数并发数限制计费口径按Token区分输入输出按Token但Prompt缓存有折扣只算GPU资源不按Token流式返回SSE字段是choices[0].deltaSSE字段是output.choices[0].delta且多一层事件类型普通流式分块大小不固定这还只是表层差异。真正麻烦的是这些差异不是静态的——供应商会升级模型会改协议字段会在某个下午把限流阈值调低一半。你的业务代码如果到处散落着对某个供应商SDK的直接调用每一次上游变更都会变成一次全链路改动。1.2 自己写个转发层为什么半年后一定会后悔一定有人会说我不上网关我自己在服务里写一个统一转发层不也一样吗我见过不少团队这么干早期跑得也挺顺。但坚持半年到一年通常会碰到这几件事第一协议转换越来越复杂。最开始你只需要把OpenAI协议的请求转成供应商B的格式后来要处理流式字段映射、Tool Call差异、多模态输入格式差异、Embedding接口的批量限制。这些逻辑全部堆在一个服务里很快就变得没人敢动。第二密钥管理和安全容易出漏洞。自己写的转发层最偷懒的做法是把所有供应商的API Key写在配置中心甚至环境变量里。等到要轮换密钥、按业务线隔离权限的时候发现当时的实现根本没留接口。第三可观测性和成本分摊是你自己写的代码里最少考虑的部分。生产上你迟早需要回答这个月每个业务线各花了多少模型调用费哪个模型的中位延迟在恶化哪个供应商的限流报错导致了多少次线上告警这些需求自己写工程量不比写一个网关小。所以我的结论很直接只要你的业务打算长期依赖两个以上模型供应商并且调用方不止一个服务AI网关就不是可选项而是个迟早要补的基础设施债。早补债少。2. 先想清楚AI网关的边界再做选型很多团队在选型AI网关时容易走两个极端一端是把网关当成万能中间件恨不得把RAG、向量检索、Prompt模板都塞进去另一端是只把网关当成HTTP反代加了个Key完全没发挥它在AI场景下的作用。2.1 网关不是业务编排平台别什么逻辑都往里塞我见过有人试图在网关上直接做知识库检索、做多轮对话状态管理甚至把业务权限判断写进网关路由规则里。这都越界了。AI网关的核心价值是通道治理不是业务计算。打个比方网关是机场的安检口和登机口它负责验证证件、分配登机通道、控制人流、记录航班状态但它不负责帮你决定飞哪个城市。业务编排、Prompt组装、上下文管理这些应该留在你的业务服务里。这个边界画清楚之后选型就会变得简单很多——你只需要评估网关在协议转换、路由、鉴权、限流、可观测性这几个维度上的能力而不是被各种花哨的AI插件带偏。2.2 原型阶段和生产阶段对网关的要求完全不同我在这件事上踩过坑原型阶段花了大把时间研究生产级的高可用架构结果核心功能验证拖了很久后来换了个思路先用一个轻量方案把链路跑通再补生产能力效率反而高。关注点原型验证阶段生产落地阶段核心目标最快速度跑通一个入口转发多个模型稳定、安全、可观测、可治理路由策略静态路由按路径前缀区分按业务线、按用户、按条件动态路由密钥管理明文配置能跑通就行动态轮换、细粒度权限隔离可观测性看访问日志指标、追踪、成本计量、告警高可用单实例多副本、优雅滚动、熔断降级这里我特别想强调一点不要因为原型阶段用了某个看起来很简陋的方案就否定它。我在原型验证时直接用了开源网关的基础版连数据库都没接路由写死在配置里。但正是这种简陋帮我快速确认了最关键的问题协议转换是否可靠、流式转发是否有性能损耗、降级切换是否顺滑。这几个问题的答案直接影响后面的选型和架构决策。2.3 我建议的最小功能清单参与过几次选型之后我总结了一个AI网关的最小功能清单供参考支持OpenAI兼容协议作为普通话能把非OpenAI协议的供应商转换成统一协议格式支持按模型、按路由、按请求特征做转发至少能配置多上游支持API Key的托管和按上游隔离不能把密钥打到业务调用方那一侧支持基本的限流和熔断至少RPM和并发两个维度有流量指标输出能区分模型名称和供应商上报指标支持流式转发最好能兼容SSE其他像Prompt注入检测、内容审核、成本配额、多级路由这些可以后续按需加不必一开始就追求大而全。3. 原型验证用最小闭环打通转发、鉴权、降级三条链路原型阶段我没做复杂架构就一个网关实例加三个上游模型供应商。但这个阶段我刻意把重点放在了三条最重要的链路上因为它们决定了生产落地的可行性。3.1 链路一统一入口与协议转换第一条链路是验证一个入口能不能吃下所有模型请求。我们的做法是在网关里配置统一的provider概念每一个上游对应一个provider每个provider内部定义自己的协议适配。看一段简化的配置更直观一些providers: - name: vendor-a protocol: openai baseUrl: https://api.vendor-a.example.com apiKeyRef: secret/vendor-a-key - name: vendor-b protocol: vendor-b-native baseUrl: https://open.vendor-b.example.com/api/v1 apiKeyRef: secret/vendor-b-key routes: - name: llm-unified match: prefix: /v1/chat/completions plugins: ai-proxy: provider: vendor-a modelMapping: enabled: true这里的modelMapping很关键。它让客户端可以统一使用OpenAI风格的模型名比如gpt-3.5-turbo网关在转发到vendor-b之前把模型名映射成vendor-b自己的模型标识。这样做的好处是业务层完全感知不到供应商切换模型名变成了一个逻辑名。原型阶段我验证的关键指标是协议转换在非流式和流式两种场景下是否都正确。尤其是流式响应vendor-b返回的事件类型、字段层级、done标志和OpenAI的规范差异很大需要在网关层做字段重写。这一步如果做不好到了生产就是灾难。3.2 链路二密钥托管与按路由分发第二条链路是一定要在原型阶段验证密钥托管机制。生产环境里研发人员会通过SDK直连各个模型厂商密钥散落在代码和配置里是最常见的安全隐患。通过网关收敛后业务侧只需要知道网关自己的Key由网关去缓存和下发各家供应商的真实密钥。我在原型阶段做了这样一组测试业务侧用一个网关签发的API Key调用/v1/chat/completions网关校验这个Key的权限范围比如只能访问vendor-a然后把请求转发到vendor-avendor-a返回后网关把响应返回给业务侧全程业务侧碰不到vendor-a的原始密钥验证通过之后我心里就有底了。因为在生产环境里密钥轮换、按业务线隔离权限都只需要改网关配置不用再推动各个服务发版。原型阶段密钥可以先存在本地配置文件里但架构上一定要按密钥服务化来设计给后面接KMS或密钥管理系统留好接口。3.3 链路三失败降级与超时控制第三条链路我建议放在原型阶段就测因为它是多模型管理里价值最直接体现的一个点主模型挂了能不能自动切到备用模型以我们当时的配置为例做了一个最基本的fallbackroutes: - name: llm-with-fallback match: prefix: /v1/chat/completions plugins: ai-proxy: provider: vendor-a fallback: - provider: vendor-b conditions: - type: timeout value: 30s - type: http_status value: [429, 500, 502, 503, 504]这里的逻辑是vendor-a如果超时超过30秒或者返回429/5xx状态码网关自动把同样的请求转发给vendor-b。我特别强调同样的请求——如果vendor-a已经部分生成了内容才报错直接重放到vendor-b会浪费token这时候应该做截断或走新的会话这取决于你的网关对半截响应的处理策略。这个阶段我还做了个小实验把vendor-a的测试Key故意改错观察请求是否在预期时间内切到vendor-b。结果发现超时设置太短会导致误切太长又会让用户等太久。最后我们把连接超时设为5秒读超时设为30秒整体降级切换延迟控制在3秒以内体感上基本无感。3.4 原型阶段不建议做的事原型阶段有几件事我劝你别做省得把简单问题搞复杂不要急着做完善的成本计量系统先用访问日志里的token数字凑合着看不要一上来就接KMS、Vault这类复杂密钥系统等生产落地再接不迟不要花大量时间调优限流算法原型阶段能限就行不要搞多级路由和条件路由规则越少越容易定位问题原型的目标是回答可行性问题不是完备性问题。只有把最核心的转发、鉴权、降级验证完你才有底气推生产落地的排期。4. 生产落地路由编排、成本观测与安全治理原型跑通之后我们大概花了两周时间做生产落地。这个阶段的主要工作分四块路由策略设计、成本观测体系、密钥与审计、安全能力接入。4.1 模型路由策略按业务线、按用户、按条件生产环境里不同业务线对模型的需求差距很大。有的业务要低延迟我们就路由到国内节点有的业务要高质量推理我们就路由到更大参数的模型还有些内部测试流量直接路由到最便宜的模型就行。我们的路由配置大概长这样routes: - name: chat-high-qos match: prefix: /v1/chat/completions headers: X-Business-Line: customer-service plugins: ai-proxy: provider: vendor-a model: model-large - name: chat-cheap match: prefix: /v1/chat/completions headers: X-Business-Line: internal-tool plugins: ai-proxy: provider: vendor-b model: model-small这个策略的好处是业务方只需要在自己的请求里带一个业务线Header网关自动决定用哪家供应商、哪个模型。生产环境里这个维度还不够我强烈建议你至少留三个标签business_line业务线、app_name应用名、environment环境。后面做成本和性能分析时这三个标签能帮你快速过滤数据。4.2 成本观测标签、计量、配额、告警成本观测是最容易被忽略、但上了生产之后所有人都会追着你要的东西。一个月下来老板问这个月模型花了多少钱如果回答不上来那基本宣告网关落地项目失败了。我们接入的指标至少包括这几个ai_gateway_requests_total按 provider、model、route、status 打标签ai_gateway_tokens_total分 input_token、output_token 累计ai_gateway_latency_seconds分 provider、model 的直方图ai_gateway_limit_hits_total限流命中的计数我的经验是所有计费逻辑都按网关日志里记录的token数来计算而不是按供应商账单。供应商账单通常延迟一天才出而且不同供应商的计费规则不一样直接用账单做实时成本控制根本来不及。网关在请求结束时记录输入输出token乘以单价就是准实时的成本。如果业务线多建议再做一层配额控制。比如某个内部工具线每月预算5000元网关侧设置对应的token配额达到门限后返回特定错误码并告警。这比事后看账单再补救高效得多。4.3 密钥管理与审计动态轮换、敏感Header脱敏生产落地的安全性要求比原型高出一个量级。密钥这一块我们做了三件事密钥接入中心化管理网关启动时从密钥管理系统拉取各供应商的API Key内存中解密不支持明文落盘动态轮换支持在不重启网关的前提下定期或定时重新拉取密钥敏感Header脱敏网关的访问日志里Authorization头、供应商返回的敏感字段都要做脱敏处理避免日志平台泄露凭证这里我补充一个细节很多网关在生成下游请求时会自动把上游请求里的Authorization头透传下去。如果你没做脱敏日志里就会明文出现供应商的API Key。我们曾经在日志平台里搜到过自己的Key当时就出了一身冷汗。所以生产级网关一定要有一个敏感字段过滤器在写入访问日志之前把所有密钥类字段处理掉。4.4 安全能力接入Prompt注入检测和内容审核的位置模型接入生产后Prompt注入和违规内容输出是绕不开的话题。这类能力我建议放在网关层而不是业务层。原因是网关是流量的唯一入口在这里做一次集中过滤比在每个业务服务里各做一遍高效得多而且后续更新策略只需要动网关。网关可以扩展两类插件输入侧Prompt注入检测检查用户输入是否包含恶意指令比如试图让模型忽略系统提示的句子输出侧内容审核对模型返回的内容做合规性检查命中风险就拦截或打标但我要提醒一句网关层的内容审核是兜底不是全部。涉及核心业务的高风险品线仍然建议在业务层做更精细的内容策略。网关的安全能力做第一层粗过滤业务层做第二层精过滤双保险。5. 灰度切换与降级演练从试点业务到全量流量生产落地的最后一步不是配置完成而是流量真实切过来之后依然稳。这一步我们花了比想象中更长的时间主要卡在灰度策略上。5.1 试点业务怎么选第一批接入的业务最好满足三个条件对模型延迟不敏感即使降级也不至于影响核心体验调用量适中方便观察问题和对比成本业务方配合度高愿意陪着你一起排查我们当时选了一个内部辅助工具和一个人工智能客服的灰度环境。这两个业务的特点就是调用方是我们自己的团队出了问题可以第一时间改配置调试不会直接波及外部用户。5.2 灰度策略权重灰度和路由维度灰度灰度切换分两步走第一步是按比例切。网关支持按流量比例选择不同的上游。我们的做法是先把10%的请求指向新接入的供应商A90%继续走老模型观察延迟、成功率和成本指标两到三天。第二步是按维度切。比例灰度稳定后再通过Header里的业务标签做定向切换。比如所有游客用户的会话走模型B登录用户走模型A。这种灰度方式更精细适合验证特定场景下的真实效果。这里有个容易被忽略的细节比例灰度和维度灰度同时存在时路由规则的优先级一定要理清楚。我们在配置时发现如果先匹配到按Header的路由后面的比例权重就不会生效。所以最好把特殊维度的路由写在前面全量默认的路由写在后面这样流量分配才不会乱。5.3 降级演练两种典型场景必须练我在生产落地前安排了两场降级演练。第一场是主供应商全挂我把供应商A的地址改成不可达的地址观察网关是否能在预期时间内切到供应商B以及业务方是否有感知。结果表明连接超时设置是最大的变数如果配置的是30秒业务方早就超时中断了我们把连接超时收敛到3秒后切换体验明显好转。第二场是限流风暴人为把供应商A的RPM阈值调低到一个极小的值触发大量限流观察网关的熔断逻辑是否触发。这场演练暴露了一个问题我们的网关初始配置只在HTTP 429时触发熔断但某些供应商在限流时会返回200但内容里携带错误信息。这导致网关以为请求成功了业务层却拿到了一段异常JSON。后来我们不得不增加一层响应体检测规则专门处理这种200但报错的情况。5.4 回滚预案灰度过程中一定要准备回滚预案。我们的做法很简单在网关配置中心保存一组上一个稳定版本的配置快照一旦灰度指标恶化一键回滚。回滚的操作顺序也很重要先回滚网关路由配置再回滚业务侧调用参数最后才是处理数据补偿。我在生产操作时犯过一个错先让业务侧改了请求参数导致和网关的路由规则不匹配反而引发了更大的混乱。6. 踩坑实录测试环境永远发现不了的几个问题最后这部分是纯干货都是我们上了生产之后才暴露的问题。如果你正在准备上线我希望你能少走这几个弯路。6.1 限流维度不一致高峰期互相拖累测试环境流量小限流差异根本不明显。一上生产问题立刻来了供应商A限RPM供应商B限TPM两个维度的消耗速度完全不同。我们曾经因为某个业务线的一个批量任务打爆了供应商A的RPM导致同一条路由下其他正常请求也被限流整个业务都有抖动。解决办法是在网关层做两级限流一级是网关自身的并发数和RPM兜底另一级是针对每个供应商的模型层级配额。这样即使某一个上游先被限制其他上游还能分摊流量不会全局崩。6.2 流式响应走了网关的缓冲首字延迟飙升这个问题非常隐蔽。网关如果默认开响应缓冲会把供应商返回的内容先攒一部分再发给客户端。对于普通HTTP请求影响不大但SSE流式请求对首字延迟极其敏感——攒的那几百毫秒直接体现在用户看到打字机效果的等待时长上。我们的修复方式是给流式路由单独配置关闭缓冲并调整网关的流式转发逻辑让它逐块转发而不是攒包。上线前一定要用真实的大模型流式请求测首字延迟建议控制在500毫秒以内。6.3 供应商升级模型悄悄改了响应结构某个供应商在模型升级后把响应里content字段从字符串改成了数组下游解析直接炸了。这种问题在测试环境抽测时根本发现不了因为测试通常用的是固定版本模型而生产侧模型是持续更新的。对策是网关层做响应结构的兼容快照每次供应商发版或模型升级时先在网关里保存旧版响应结构再对新结构做适配防止业务代码被上游变更打措手不及。更理想的做法是给响应体加一层schema校验但这对流式响应比较难实现建议优先做非流式的校验。6.4 证书和SNI的坑最后说一个基础设施层的坑。在测试环境直连内网mock服务没暴露证书问题。一站到生产连接国内某供应商公网endpoint时网关和后端服务之间的TLS握手一直出错排查半天发现是网关的SNI配置没有匹配供应商证书的域名。如果你的网关需要代理到多个云厂商的模型API一定在原型阶段就测一下公网TLS握手特别是SNI是否自动带了目标域名。有些网关默认SNI用的是本地配置的域名而不是上游域名这种错位在测试内网环境根本看不出来。总的来说AI网关这套东西落到地上其实不复杂但它把多模型管理的复杂度从每个服务都要处理集中到了一个点。这个点做得好后面接再多的模型也只是加配置的事做不好它就是团队新的瓶颈。我的核心建议就一句话先画清楚边界再用最小闭环验证三条链路最后带着灰度、成本和安全的视角上生产。这条路走通之后模型切换、配额控制、成本分摊这些问题都会变得清爽很多。