前阵子有个朋友找我吐槽他们的产品为了降本增效陆续接了三家不同的大模型厂商结果代码库乱成一锅粥。每个模型一套 SDK、一套错误码、一套重试策略产品经理今天想换更便宜的模型明天想让复杂问题走“高智商”模型排查问题时根本分不清某次报错到底来自哪家。这个场景我相信这两年做 AI 应用的人多少都会遇到。说到底就是缺了一层AI 网关——夹在业务应用和大模型之间的“中间层”把“调用模型”这件事从业务代码里彻底剥离出去。这篇我会用实际项目里的经验拆解 AI 网关的职责边界、核心功能、选型对比和踩坑记录。适合正在做多模型集成、想治理成本和提升稳定性的开发者、架构师参考。不管你是刚起步的独立开发者还是已经在维护微服务体系的团队理解这一层“中间件”到底解决什么问题都会让你的架构决策更清晰。1. 多模型时代你的代码怎么突然就“绑死”了1.1 一个典型场景从单模型到多模型的痛苦迁移最早的 AI 应用大多只接一个模型代码里直接调用官方 SDK简单直接。可一旦业务跑起来问题就接踵而至模型供应商高峰期限流用户体验断崖式下降账单不好控制一个失误可能烧掉不少预算更关键的是把全部业务押在一家模型厂商身上总有一种“命门握在别人手里”的不安感。于是大多数团队会走上同一条路接入第二家、第三家模型作为备用或分流。这时候痛苦才真正开始。每家 SDK 的 API 完全不同参数名不一样返回结构不一致有的返回choices[0].message.content有的返回content或text错误码更是五花八门429、rate_limit_exceeded、quota_exceeded换着花样出现流式响应 SSE 的 chunk 格式也各有一套。代码里很快就铺满了if provider A这种分支维护成本直线上升。更麻烦的是同一个 prompt 在不同模型上的效果差异远比你想象的大。有的模型你给它几个示例就学得会有的模型必须写满一整页规则才不跑偏。于是你又不得不在应用层维护好几份 prompt 模板每份还要跟着模型迭代调参。这种事一旦出了生产事故排查链路长得让人崩溃。1.2 问题本质你缺的是“代理”而不是“SDK”很多人遇到这种情况第一反应是自己写一个 util 类把各家 SDK 包一层。我一度也这么干过但很快发现这只是“语法糖”解决不了根本问题。因为“调用模型”背后真正需要的能力远远不止一个统一方法签名这么简单协议转换、智能路由、重试熔断、限流配额、计量计费、权限审计、缓存加速、可观测性……这些东西全是基础设施层面的能力而不是业务逻辑。这就好比微服务时代你不会让每个服务自己实现限流、熔断和认证而是交给一层统一的 API 网关去处理。大模型调用也一样既然你的服务可能同时调用多个模型那就必须有一层统一的流量治理中间件。所谓的 AI 网关本质上就是LLM 调用的 API 网关它把分散在各处的模型接入、治理逻辑收拢到一个地方让业务代码只关心“我要什么能力”而不关心“底层到底是谁在提供服务”。顺带说一句网关不是缓存代理升级也不是简单加一层转发就完事它承载的是完整的流量治理语义。1.3 多模态模型进一步放大了这个需求前两年大家主要接的是文本模型场景相对单一。现在不一样了视觉理解、语音转写、视频分析这类模型陆续成熟一个应用里可能同时调用文本模型做对话、视觉模型做图像识别、语音模型做会议转写。模态越多SDK 之间的差异就越大。多模态模型的输入格式千奇百怪有的要求图片 base64 编码有的要传 URL有的要求视频先抽帧有的直接把视频文件丢过去。输出也是天差地别有的返回强结构化 JSON有的直接给你一段自然语言描述。如果你在业务代码里逐个适配这些差异那这个项目的可维护性迟早归零。我在参与一些多模态模型相关项目的落地时感受最深的就是没有中间层做统一归口光是把各种模态的请求格式翻来覆去地适配就能耗掉团队大半精力。这进一步说明多模型时代“应用直连模型”的架构是撑不了多久的中间层不是可有可无而是早晚要有。2. AI网关的真实职责不只是转发请求那么简单2.1 统一协议层把十个SDK变成一个网关干的第一个核心活儿是对外暴露一个稳定、统一的 API对内自动把请求翻译成各个厂商的协议。目前业界事实上的统一标准是 OpenAI 兼容格式所以你会发现很多网关产品都默认这条路业务侧用 OpenAI SDK 的写法直接连网关网关再根据你配置的模型清单把请求转换成 Claude、Gemini、国内各家模型各自的格式。这样做的好处显而易见业务代码只依赖一种协议模型厂商切换不影响业务代码新接一个模型时只需要在网关侧加一个 provider 适配器不用改任何业务逻辑。我实际跑过一个 Java 服务接 LiteLLM 代理的工程业务侧就是配一个base-url指向网关地址模型名写成网关里定义的别名剩下的全部交给网关处理。一个最小化的网关配置大概是这样的思路以 LiteLLM 为例model_list: - model_name: qa-model litellm_params: model: anthropic/claude-sonnet-4 api_key: os.environ/ANTHROPIC_API_KEY - model_name: qa-model litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY priority: 1业务侧不管底层是哪家只请求qa-model这个逻辑名。网关内部会按配置把请求路由到对应的供应商返回前再统一格式。这套机制让“业务代码零感知换模型”成为可能这才是协议层的真正价值。2.2 请求路由按任务类型、成本、质量动态分发统一协议只是第一步真正体现网关价值的是请求路由。最基础的路由策略是权重分配同一个逻辑模型名挂在多个实际模型上每个模型配一个权重或优先级。比如高优先级是 GPT-4o-mini低优先级是备用模型主模型挂了流量自动切到备用。更实用的路由是按任务类型分发轻量的分类、抽取、客服问答这类任务走快而便宜的小模型复杂推理、长文档摘要、多轮规划这类任务走能力更强的大模型。实现方式有两种一种是调用方在请求 metadata 里打上任务标签网关按标签路由另一种是网关内部用 embedding 对 query 做语义分类再按分类结果路由。我自己的建议是团队初期别急着搞太复杂的自动语义路由。先把任务类型分清楚比如chat、extract、summarize几个大类在请求里显式带上网关按规则转发。这套机制已经能帮你省下可观的成本而且日志可溯源性远远好于“玄学路由”。等积累了足够多的流量数据再考虑上模型自动选择也不迟。2.3 高可用三板斧重试、超时、熔断与降级直连模型时代供应商的一个小抖动就会传导到你的用户侧。某家大模型偶尔抽风半小时你的应用就跟着抖动半小时。网关的价值就在于把这些稳定性问题全部拦截在这一层。关于重试最常见的触发条件是429限流和瞬时5xx。网关会采用指数退避加重试抖动避免同时重试把供应商打爆。但这里有一条重要的红线生成类任务不是幂等的自动重试会导致重复计费同一段文字可能被生成两遍。所以网关的重试策略必须可以按业务场景独立配置比如“只对网络层错误重试不对应用层错误重试”。熔断和降级要一起说。网关会统计每个上游模型的连续失败数和错误率一旦超过阈值自动触发熔断把流量临时切到备用模型上等上游恢复正常后再“半开”试探逐步恢复主模型流量。这会比业务侧收到错误再手动切模型靠谱得多。我遇到过某主力模型出现长尾错误网关配置的 fallback 自动把流量切走业务侧完全无感直到事后看成本曲线和延迟曲线才发现切换发生过。这种“出了事你甚至不用知道”的体验就是网关该有的样子。超时设置也要分模型、分场景。快速分类模型给 3 秒超时大模型对话给 20 秒语音转写任务给 30 秒以上。流式请求还要区分“首 token 延迟”和“总时长”防止模型一直不吐字但连接还耗着。2.4 成本与限流让账单不再失控模型之间的价格差距非常大同一类任务的成本差 5 到 10 倍很正常。没有治理的情况下几个默默无闻的内部工具调用可能比你的核心业务还烧钱。网关在这一块能做的事情很多。首先是配额管理。你可以给每个内部团队、每个应用、甚至每个用户分配独立的密钥虚拟 Key设置日配额、月配额、最大预算。超了配额之后有两种策略拒绝调用或者自动降级到更便宜的模型。我见过一个很经典的用法某团队超了预算之后网关自动把他们的请求从 GPT-4 级别降到 mini 级别核心功能还能用只是答案质量略降预算瞬间控住了。其次是计量计费。网关要在这一层统一统计 token 数和费用。不同模型的 tokenizer 不同输入输出价格也不同。网关会把每一条日志里的 token 数按模型单价折算成金额集中透视展示。这里要提醒一点网关算出来的是“估算值”对账时最终要以供应商账单为准但只要误差控制在可接受范围这个数据的价值已经足够大。3. 网关带来的三个“隐藏实惠”可观测、缓存与提示词治理3.1 全链路追踪出了事你能查到哪里出了问题直连模型时排查“用户说 AI 回答变怪了”这种问题非常痛苦。你只知道应用调了一次模型但具体 prompt 是什么、用的哪个模型、花了多少钱、延迟多久统统没有。有了网关之后所有请求都有唯一request_id并且可以跟业务侧的 trace ID 关联起来。网关日志里能完整重现用户 ID、会话 ID、模型名、prompt、响应摘要、token 数、延迟、费用。我做过一次典型排查用户反馈答案质量突然下降翻网关日志发现他的请求走的是备用便宜模型原因是主模型最近偶发超时触发熔断切流了。前后半小时定位到根因这要放在以前光找日志就得折腾一天。不过我要多说一句网关日志别全量落盘大模型响应内容可能很大全存既费存储又费查询。通常是存请求参数、响应摘要、元数据完整响应按需异步归档。3.2 语义缓存同样的提问别付两份钱大模型成本的大头在于重复计算。很多问答场景比如企业 FAQ、规章咨询、产品介绍同一类问题会被不同用户反复问答案在短期内基本一样。网关可以做语义缓存先把 query 转成 embedding跟已有缓存做相似度比较超过阈值就直接返回缓存结果不再调用模型。实现时要注意几个细节。相似度阈值设太高命中率低缓存形同虚设设太低容易把相近但不该复用的问题误判成同一个答非所问。建议从 0.92 到 0.95 起步根据业务场景慢慢调。还要处理时效性政策类、价格类的结果缓存时间要短或者直接不缓存带用户个性化信息的请求绝不能用公共缓存。我实测过一个 FAQ 型应用接入语义缓存后命中率在 35% 到 50% 之间成本直接降了三分之一左右响应延迟也从秒级降到毫秒级。这个投资回报率在所有网关功能里是最高的。3.3 提示词版本管理提示词也是正经要上线的以前我总觉得 prompt 不就是在代码里改个字符串吗哪值得专门管理。直到团队两个人同时改了线上提示词差点把一个生产事故推上线我才意识到提示词已经变成了业务逻辑的一部分它需要版本控制、灰度、回滚这些工程化手段。网关可以把提示词模板集中管理按版本发布。模型切换、A/B 测试都不用动业务代码网关一侧配置版本号切流比例就行。比如 v1 给 10% 流量v2 给 90% 流量在线观察效果再慢慢放开。这种事直接在代码里做成本高、风险大放在网关层就是一行的配置改动。当然也不是所有团队都需要这个能力如果你的提示词迭代不频繁、团队就一个人那代码里管理也够用。但只要 prompt 开始变成多人协作、多模型共用的东西网关就是比代码字符串更好的治理位置。4. 选型实战自研、开源还是商业服务4.1 三种方案的本质差异先说结论我不推荐大多数团队从零自研。从零做一个全功能网关的工作量远超很多人的预估。协议转换、重试策略、熔断设计、计费口径、缓存实现、可观测、管理界面……每一块都是深坑。更重要的是这些能力属于“基础但复杂”的范畴做好它需要长期专业投入对业务团队来说性价比很低。开源自托管是大多数技术团队最舒服的落点。功能齐全、数据在自己手里、没有额外授权费代价是你得自己承担部署、升级、调优和故障处理。商业托管则是开箱即用、有 SLA、有客服但会把你的请求流量全部过一遍第三方需要认真评估数据合规和隐私风险。这三条路没有绝对的优劣只看你的团队规模、运维能力和数据敏感度。维度自研开源自托管商业托管功能完整度低需要长期投入高社区持续迭代高且迭代快部署成本极高人力中等运维低定制能力最强较强受限于供应商数据合规控制完全自控数据在自己手里数据外发须评估适合团队平台型团队、有专门人力大多数技术团队少运维、快速起步的团队4.2 我实际部署过的网关工具按场景给建议LiteLLM是我入门最早用的。它支持 100 多家 provider一套 API 统一访问Python 生态很友好配置文件简单社区活跃。缺点是它是应用层网关性能上限没有特别高适合中小规模团队和实验项目。我个人的第一个多模型代理服务就是用它搭的前后不到半天就跑通了。OneAPI是国内社区很活跃的开源项目核心思路是“OpenAI 格式统一管理渠道”。它的管理界面用来发 Key、配配额非常方便适合国内模型聚合场景也就是把通义、智谱、DeepSeek、讯飞这些厂商统一成一个出口。要留意的是它把所有模型都统一成 OpenAI 格式部分模型的特色能力可能被“削平”如果你的业务重度依赖某些厂商专有能力要提前测试。Higress是云原生方向的代表基于 Envoy 内核性能和稳定性很扎实AI 网关能力通过插件扩展。如果你的团队已经有 Kubernetes 和微服务网关基础设施那它几乎是最自然的选择。我在一个大规模项目里评估过它插件机制确实成熟适合长期演进。Cloudflare AI Gateway是托管方案里的典型带重试、缓存、限流、资金保护等功能跑在全球边缘网络上。如果你不介意请求经过第三方且想省掉所有运维这是很省心的选择。选型建议很直白小团队先用 LiteLLM 或 OneAPI 把业务跑通规模上去了或者团队已有网关基础设施再往 Higress 这类正式网关演进对运维零容忍、合规允许外发的团队直接用托管服务。5. 部署 AI 网关时最容易踩的四个坑5.1 坑一以为加了网关必然变慢——其实大坑在流式转发很多人一听说中间层第一反应就是“多一跳延迟得爆表”。实测下来同一区域、同一网络环境下直连与走网关的额外延迟通常在 1 到 10 毫秒之间这点开销放在模型推理的几百毫秒到几秒面前基本可以忽略。真正的大坑是流式响应SSE处理。有些自研网关图省事把完整的 SSE 流接收到内存里等上游全部生成完再一次性返回给前端。这会带来毁灭性的体验你原本想要的打字机逐字输出效果变成了“等十几秒没反应然后整段文字突然糊脸”。网关必须做 SSD 透传也就是上游每吐一个 token 块网关就立刻转发给客户端。这块做不好应用层的长连接延迟一定会被放大。顺带说网关在流式透传时还要想办法边缘计数否则流式响应的 usage 数据大概率对不上。5.2 坑二网关成了单点挂了全站跟着瘫痪网关是个集中节点好处是流量治理能力集中坏处是它一旦挂了全站都跟着完蛋。高可用设计不能省多实例部署 无状态设计网关本身不保存会话状态session 放外部存储前面挂负载均衡数据库和配置中心选可靠的服务别用本地文件硬扛。另外强烈建议多做一条策略性兜底网关不可用时业务侧可以直连 Provider 的静态开关。虽然绕过了治理但至少别让业务全挂。这个开关要在架构设计时提前做好别等真出了故障再手忙脚乱地加。如果你用的是 LiteLLM 这类还支持进程内嵌入模式的网关小项目里也可以直接用嵌入模式少一个独立运维节点。5.3 坑三模型返回格式不统一解析逻辑写到你崩溃统一了入口不代表统一了解析。很多团队以为用了网关就万事大吉结果发现不同供应商返回的 JSON 结构、错误码、流式 chunk 格式还是千奇百怪。字段有的是choices[0].message.content有的是content或text报错有的是429 rate_limit_exceeded有的是quota_exceeded加网络状态码 200。网关层必须做响应 normalize把这些差异全部转成统一 schema错误码也要映射成标准错误比如429、5xx、timeout、context_length_exceeded。还有一个更隐蔽的坑同款模型出新版本后输出格式可能微调加了字段、改了两个字段的类型。所以网关的 schema 解析逻辑必须有兜底不能因为多了一个字段就直接抛异常。建议把各模型的响应样本写成适配器单测用例每次升级模型或更新 SDK 先跑一遍测试集比线上踩雷划算多了。5.4 坑四成本统计口径对不上经常有人问为什么网关显示的费用和供应商后台的账单对不上我实测总结下来主要有几个原因重试请求多次计费但网关只按成功响应记录了缓存命中不计费但账单里没有体现不同模型的 tokenizer 存在差异token 数估算和实际用量偏了几个百分点协议转换过程中 token 被重算精度进一步被稀释。解决办法是网关统计要同时记录尝试次数和成功次数保留原始 usage 字段不自己做二次估算对账周期固定比如每周拉一次供应商账单和网关账单做比较把误差目标定在 5% 以内不要盲目追求精确到每一分钱。亲身经历里有一次对账发现网关少计了 15% 的费用追了半天发现是流式请求的 usage 字段在转发链路上丢了。升级网关版本、补上 usage 解析逻辑数据才对得上。这类问题很隐蔽但影响的是财务信任值得认真对待。6. 什么情况下真的不需要 AI 网关6.1 单模型、调用量小不需要如果业务只用一家模型、调用量也很低没有成本压力那网关基本是多余的。多一层就多一个维护点多一条排查链路出了问题还要两头查完全不划算。判断条件很简单模型数量小于等于一、不需要按团队分 Key、不需要熔断切换、不需要语义缓存、不接受请求走第三方这些条件全都满足的话真不必折腾。6.2 还在原型验证阶段先别加产品想法还没验证清楚笔直调用官方 SDK 才是最短路径。先把业务跑通、把价值做出来等要上生产、有多个用户同时使用、成本开始敏感了再引入网关不迟。过早引入网关只会额外增加学习成本和部署复杂度对验证方向没有任何帮助。但这里我建议留一手业务侧不要直接把各家 SDK 散落在代码各处而是包一层简化的调用接口。以后接网关时只需要改这一个接口的实现不用伤筋动骨改全盘。这个抽象成本极小却能让后续演进顺畅很多。6.3 已有统一入口的团队先合并而不是再造如果团队已经有成熟的 API 网关比如 Kong、APISIX、Envoy那加一层独立的 AI 网关组件不一定是好主意。更好的做法是复用现有网关的 AI 能力或者把模型供应商当作普通 upstream 路由的一种在现有网关上扩展。这样避免了“两套门神”并存的局面运维心智也简单很多。6.4 四道自测题是否要同时稳定使用两个及以上模型是否有成本治理和配额诉求是否需要统一的监控审计是否愿意承担中间件运维成本如果前三个里有一个“是”并且最后一个你也能接受“是”那 AI 网关值得上。如果前三个全是“否”就再掂量掂量别为了用而用。最后说点个人体会。AI 网关不是银弹它解决的是“多模型时代应用被模型绑架”的架构问题。真正用好的关键是想清楚自己最需要哪个能力——是路由、成本、可观测还是缓存想清楚了选型就顺畅了一半。一个小技巧在网关里维护一套“能力标签”而不是“厂商名”。业务只认能力比如 QA 能力、写作能力、OCR 能力由网关决定底层用哪家模型。后来我再接新供应商时只需要加一个适配器和路由配置业务侧完全没感知整个接入过程平静得像一次普通升级。