直接对接多家模型API干了半年之后我做的第一件事就是在应用和模型之间加了一层网关。不是赶时髦是疼够了。手里的Key从一把变成三把每个模型厂商的请求格式都长得不一样参数名一会儿是max_tokens一会儿是max_new_tokenslimit一会儿是请求次数一会儿是token额度光是维护这些适配代码就让人崩溃。更别提模型本身还会更新版本、调整价格、偶尔抽风宕机。今天这篇就是把我这半年折腾AI网关的经验彻底摊开来讲——它到底是什么、解决了哪些问题、哪些问题它其实管不了以及从选型到落地的完整路径适合正在把多个模型接进生产环境的开发者、技术负责人读。1. 多模型时代直接调API的日子是怎么失控的1.1 你手上不知不觉多出来的那一堆Key先说一个我自己身上的真实变化。2023年我做的应用只用一家模型代码里就一个API Key一个SDK一份文档调不通就看那一家文档问题很清晰。到了2024年需求变了用户想要更聪明的推理想要更快的响应想要多模态图片理解甚至部分场景想用本地私有化模型保证数据不出内网。结果就是同一个应用里你得同时接OpenAI的GPT系列、Anthropic的Claude系列、Google的Gemini系列可能还有国内厂商的模型和本地部署的开源模型。每个厂商给你一把Key每个Key对应不同的计费口径、不同的速率限制、不同的上下文窗口。我当时的代码长这样async function chat(messages, model) { if (model.startsWith(gpt)) { // OpenAI格式messages, max_tokens, temperature... } else if (model.startsWith(claude)) { // Anthropic格式直接把system拆成独立字段max_tokens是必填... } else if (model.startsWith(gemini)) { // Google格式contents[{role, parts}], generationConfig... } }这种代码写起来很快但后续每个模型厂商更新一次API我就要跟着改一遍。更麻烦的是SDK版本冲突——同一个Node项目里装三个不同厂商的SDK底层依赖偶尔打架升级一个库得连带测试另外两个功能。这种痛苦不是技术难点是纯纯的维护债。1.2 各家模型API的方言问题模型API之间的差异比想象中大得多。普通人以为大家都是输入文字输出文字无非换个地址换个Key。实际用起来方言问题处处都是消息结构不同。OpenAI用messages数组统一搞定system和userAnthropic把system独立成顶层参数Google Gemini的contents里每个角色字段写法又不一样。参数语义不同。同一个随机性控制OpenAI叫temperature某些模型叫temperature但支持的取值范围不同另一些模型干脆只支持top_p还有的模型同时有top_k。你要让上层应用切换模型这些参数映射谁来做返回格式不同。有的返回JSON有的返回纯文本工具调用的返回结构各家也完全不同流式输出的协议格式更是各写各的。错误码含义不同。A厂商的rate_limit_exceededB厂商可能叫RESOURCE_EXHAUSTEDC厂商干脆返回429配一段HTML错误页。这些方言问题是典型的中间层可以解决的网关在上游统一接收一种协议格式然后在下游为不同厂商做翻译适配。业务代码永远只面对一种请求格式、一种返回格式模型换了一家业务代码一行都不用改。1.3 单一厂商依赖出了故障就只能干等还有一件让我坚定要上网关的事——2024年某次大模型服务大面积故障。那天我的应用台里一片飘红用户端消息发不出去客服工单炸了。我能做什么除了等厂商恢复什么都做不了。因为代码里所有调用都写死了那一个地址、那一把Key根本没有备用通道。如果有网关情况完全不一样。网关层可以配置故障转移策略主模型超时或者返回5xx的时候自动把请求切换到备用模型。用户可能感知不到任何变化顶多觉得响应慢了几百毫秒。这在生产环境是救命级别的能力。2. AI网关站在中间到底做了什么五个核心能力逐个拆解2.1 统一接口层把N种协议翻译成一种网关最基础也最重要的能力就是协议适配。它在业务应用面前伪装成一个标准的模型API服务——业务代码按照一套约定好的格式发请求网关负责把这份请求翻译成OpenAI的格式发给GPT翻译成Anthropic的格式发给Claude翻译成Google的格式发给Gemini。这个设计借鉴的是企业软件里非常成熟的API网关思想后端可以有无数个服务前端统一走一个入口。模型网关不过把服务替换成了模型。实践中很多开源网关直接把OpenAI的API协议当作标准协议因为它事实上的生态最完善。你的业务代码可以用OpenAI SDK只改一下baseURL指向网关就能调通其他模型。这个技巧实测非常方便基本零学习成本接入。2.2 智能路由与故障转移不是所有请求都要走最强模型多模型时代出现了一个新问题最强模型往往最贵、最慢而你的应用里并不是每个请求都需要最强模型。复杂推理/代码生成走最强模型质量优先简单问答/摘要走中等模型平衡成本和速度意图识别/分类走小模型甚至本地模型追求低延迟。网关的路由能力就是做这个事——根据请求的特征来源、用户、提示词长度、话题分类、自定义标签分配合适的模型。这不仅是省钱的思路也是提升用户体验的思路因为小模型的响应速度肉眼可见地快。故障转移也是路由的一部分。我在网关里配置了三种粒度的容错规则网络层超时——连接超过建连超时时间直接切换备胎模型业务层错误——收到特定错误码比如限流429、负载过高503切换模型内容层异常——返回为空、前后不一致、触发了拒答交给下一逻辑。要注意的是故障转移不是越灵敏越好。设得太灵敏上游厂商一秒钟的抖动就会触发大规模切换反而造成更多不稳定设得太迟钝用户早就感知到卡顿了你才切换。我自己的经验是超时时间设在调用方容忍阈值的一半左右并且切换动作要有次数限制避免两个模型互相甩锅导致请求无限重试。2.3 成本管控与用量观测钱花在哪清清楚楚直接拿各家模型官网的控制台看你只能看到某一家的消耗。但你的应用同时用了三家每一家还拆了不同项目、不同模型版本月底算账的时候根本对不上。尤其当业务量上来之后一个部门说我调用了很多次另一个部门说我传的token特别大没有一个统一账单成本优化就无从谈起。网关天然坐落在所有请求的必经之路上所以它是做用量统计和成本核算的最佳位置。它能看到每一次请求的模型、token数、延迟、成功/失败状态然后汇总成统一的观测面板。我落地的时候重点看了几个指标指标我关心的原因每模型的平均请求延迟判断模型选的合不合理是不是杀的鸡有点多每模型的token费用消耗钱预警设月预算阈值按用户/按部门的用量分布内部成本分摊和异常调用排查缓存命中率评估缓存配置有没有真正生效错误率分布快速发现某一上游不稳定的苗头这些数据还有一个额外用途给老板汇报。之前我说模型费用涨了老板问涨在哪我答不上来。现在直接截图网关的用量面板哪个模型涨了多少、哪个业务线贡献了大头一目了然。2.4 安全与合规密钥、审计、内容策略把密钥直接写在业务代码里是很多早期项目不自知的隐患。前端代码里嵌Key更是灾难——抓包就能拿走。网关把密钥统一收编到服务端业务应用不需要接触任何模型厂商的密钥它只需要跟网关之间维持一个内部凭据。这样即使应用被拖库、被调试注入也不会泄露上游模型密钥。审计日志是合规上很值钱的能力。哪些人/系统、在什么时间、调用了什么模型、传了哪些内容网关全部记录下来。等以后出了数据泄露问题或者需要配合审计直接按时间轴拉日志就行不用去各家后台零散翻找。除此之外还可以在网关层做内容策略的集中管控。比如某些业务场景不允许输出特定类型的内容你可以在模型返回后做一道后置内容检查某些情况下希望给最终回答套一层格式包装也可以在这里统一做。2.5 Prompt和模型配置的集中管理最后一个很多人容易忽略但实际体验极好用的能力Prompt模板和模型配置的集中管理。没有网关的时候Prompt可能散落在各个服务的代码里。今天产品经理说把这个话术微调一下你得发版明天想换一个模型看效果你得改代码。有了网关Prompt模板放到网关配置中心业务调用时指定模板ID网关自动填充变量后发给模型。改Prompt不用发版改模型参数不用发版甚至可以做A/B对比——同一份Prompt百分之多少流量走模型A百分之多少走模型B效果数据看板上一目了然。3. 网关不是银弹边界、误区和场景判断3.1 网关管不了的事讲完了网关的能力必须泼一盆冷水它管不了所有事。第一它管不了模型本身的质量。模型答错了、幻觉了、逻辑崩了网关不会帮你改答案。它只负责把请求送过去、把响应传回来智能不智能是模型自己的事。第二它管不了网络链路的质量。如果你的应用和目标模型服务之间的国际链路本来就慢网关只是不背这个锅也不能变出更好的网络。它能在超时后帮你切换但切换本身有代价第一次请求的延迟该多高还是多高。第三它管不了业务层面的复杂编排。一个请求需要先检索知识库再拼上下文或者需要多个模型协同推理这种编排逻辑应该放在业务代码或独立的Agent框架里而不是塞进网关。网关是给单个模型调用做寻址和调度不是给你跑业务流程的。我见过最离谱的用法是想在网关里塞一套复杂的Agent规划逻辑结果配置变得巨难维护出问题都找不到是网关的问题还是业务的问题。这个边界一定要划清楚网关做通用能力业务做个性化逻辑。3.2 什么时候真的不需要网关也不是所有项目都需要网关别被中间层焦虑带偏。如果你只用一个模型厂商、只有一个Key、用户量不大、也不打算切换厂商——直接调API即可加一层网关纯属过度设计。如果你的团队只有你一个人写代码一切配置都了然于心换模型也就改几行——可以等痛苦出现了再上网关。如果你的需求只是给前端加个AI聊天入口根本碰不到生产级的要求——先跑通再说。我的判断方式是当你的模型调用出现以下任意两条时就该考虑网关了——多个模型厂商、多个服务/团队调用模型、需要精细的成本核算、需要故障转移、需要集中管控Prompt与密钥。3.3 部署位置客户端直连还是网关中继网关应该放在哪一层有一种做法是让客户端直接连网关网关再连模型。这样做的好处是客户端体验可控坏处是网关直接暴露公网安全要求更高而且每次客户端发版都要跟着改。更稳妥的通用做法是业务后端连网关客户端只跟业务后端通信。网关作为内部基础设施不暴露在公网密钥、审计都在内网完成。但有一个例外——如果你在做纯客户端应用比如桌面工具或移动App并且真的不想维护自己的后端那么用托管形态的网关服务会合理一些它自带鉴权和配额控制。但即便如此我仍然建议至少有一层自己的后端做业务控制客户端直连模型网关只适合Demo和低安全要求的场景。4. 落地实践从选型到跑通的完整路径4.1 先想清楚要解决什么再谈选型做技术选型之前先把你自己的需求列表写下来。我是按照下面这几个问题梳理的我目前用了几家模型未来半年想不想再加我有没有成本核算的刚需是不是被财务/老板追着问过我能不能接受依赖一家模型厂商如果它挂了业务就停摆吗我的密钥目前存在哪里是否已经暴露过我的团队有多大的运维能力能伺候多复杂的中间件这些问题回答完之后选型方向基本就定了。如果你们团队后端能力很强愿意折腾开源网关自己部署最灵活如果就想快速用起来托管网关优先。4.2 开源网关的选型参考这个领域目前已经有不少成熟的开源网关项目我按自己的使用体验做个对比仅供参考网关项目核心特点适合场景LiteLLM100模型统一OpenAI格式轻量Python生态配置简单快速接入多家模型、内部工具、数据科学团队Portkey观测能力强网关控制台一体免费额度够用需要开箱即用的观测面板和路由策略One API国内社区活跃渠道管理方便需要管理多个渠道、做API转发的团队Kong / APISIX AI插件通用API网关加AI能力插件已有API网关基础设施的大团队我自己的项目最后选了LiteLLM作为主力原因有三一是它天然以OpenAI协议作为标准业务代码改动最小二是它的配置是纯YAML版本管理方便三是它同时也提供代理模式可以作为一个独立服务部署在K8s里。团队里不是没有人劝我上更重的企业网关但对我这种两三个人的后端小组来说LiteLLM的复杂度刚好。4.3 最小可用方案用网关统一三家模型这里给你一个可以直接抄作业的最简落地路径。假设你有一个Node.js后端现在要统一接入OpenAI、Claude和Gemini。第一步部署网关。我用Docker起一个LiteLLM代理docker run -d \ --name litellm-proxy \ -p 4000:4000 \ -v $(pwd)/config.yaml:/app/config.yaml \ ghcr.io/berriai/litellm:main-latest \ --config /app/config.yaml第二步写网关配置。把三家模型的Key配进来给每个模型起一个逻辑别名model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: sk-xxx - model_name: claude-3-5-sonnet litellm_params: model: anthropic/claude-3-5-sonnet api_key: sk-ant-xxx - model_name: gemini-1.5-pro litellm_params: model: gemini/gemini-1.5-pro api_key: AIza-xxx router_settings: routing_strategy: usage-based-routing fallbacks: claude-3-5-sonnet: - gpt-4o第三步业务代码改用OpenAI SDK但指向网关。核心改动就一个baseURLimport OpenAI from openai; const client new OpenAI({ apiKey: 你的网关内部Key, baseURL: http://网关地址:4000/v1, }); // 上层想换模型只改模型名其他代码不动 const resp await client.chat.completions.create({ model: claude-3-5-sonnet, messages: [{ role: user, content: 帮我总结一下这份周报 }], });第四步设路由策略。我把简单摘要流量指向gemini复杂推理指向claude并把gpt-4o作为全局兜底。跑了一个星期之后对比之前的账单成本下降了大约四成——因为大量简单请求不再走最贵的模型了。4.4 验证与上线别一上来就切全量流量。我的顺序是先让网关和直连模式并行跑拿测试流量做对比先验证单模型调用同一个问题直连和走网关的返回内容是否一致模型相同的前提下应该一致。再验证流式输出确认SSE流式返回格式没有被网关破坏。接着验证工具调用如果业务里有function calling这个最容易出问题必须逐个测。最后验证错误码故意用错误的Key、超限的请求确认网关的报错对上层业务是友好的。全部通过之后把流量按10%灰度切过来观察延迟、错误率、成本三个指标稳定24小时后再放大比例。5. 生产环境里的真实坑路由、限流和成本失控的复盘5.1 路由策略写得太粗导致体验劣化我第一次配路由就配了所有请求平均分到三个模型。结果用户很快就反馈有的回答特别啰嗦有的回答又过于简洁。因为我把不同任务混在一起了有些请求明显需要强推理被路由到了小模型回答质量自然崩。后来改成基于请求分类的路由——业务方在请求里带一个task_type字段网关根据这个字段决定模型。比如带reasoning标签的走Claude带summary标签的走Gemini带chat标签的走GPT。分层清晰之后质量问题基本消失。这里提醒一句路由规则别写得太死。模型能力和价格每季度都在变半年后你觉得这个模型最能打的那个可能已经被另一个替代。路由配置一定要做成可动态修改的别编译进代码里。5.2 限流和熔断参数拍脑袋就完蛋网关的上游有速率限制你内部还有各业务线的配额。我第一次设限流阈值随便填了每分钟1000次结果高峰时段业务方直接报错——我看后台被打爆的其实是某一个重度用户脚本在循环调用正常业务也被连坐了。正确的做法分两层第一层是上游厂商的速率限制网关要正确读取错误码并做退避重试而不是无脑重试加重对方压力第二层是内部业务配额按业务线、按用户维度分别设限之间互相隔离。熔断参数也要谨慎。熔断的本质是快速失败保护下游但如果阈值设得太低一次小波动就会熔断然后流量全部压到备胎备胎也跟着熔断造成雪崩。我现在的做法是连续失败率达到30%且最小请求量超过20次才触发熔断熔断后30秒半开探测一次。这个参数不一定适合所有人但方向是对的——把最小请求量卡住避免小样本噪音触发误判。5.3 成本失控日志里有真相还有一次月底账单突然比上个月翻了三倍。我打开网关的用量数据一看发现罪魁祸首是一个定时任务它把一整本几十万字的文档每页单独调了一次模型摘要而我的路由配置里这个任务走了最贵的模型。这个场景要是没有网关的日志我可能要去各家后台分别拉数据慢慢对还不一定对得出来。从此我把按业务线成本预算设成了硬指标网关里给每个业务线配月度上限超过就告警超过80%就通知。省钱这件事得先看得见钱花在哪。5.4 缓存带来的意外收益最后聊一个偏门但很实用的点模型网关可以做语义缓存。对于重复性很高的业务比如客服场景里如何退货改地址这类常见问题如果每次都去找大模型要一遍回答费用和延迟都是浪费。我在网关层加了语义缓存请求先做embedding与历史问题做相似度匹配命中就直接返回缓存答案。实测客服场景的缓存命中率能到30%左右对应节省的成本非常可观。唯一的坑是缓存的内容要带时效性——比如促销规则变了老答案就不能再用了所以缓存TTL千万别设成永久。这半年用下来我的整体感受是AI网关不是一个加了就一定好的组件但在你同时面对多个模型、多个业务方、复杂的成本诉求时它几乎是我能想到的最优解。它不解决模型的智商问题它解决的是工程问题——让上层业务专心写逻辑让模型厂商的差异收敛在一个可控的点上。如果你现在也正在被多模型维护、密钥管理、成本对账折磨从一个小众的网关配置和10%灰度开始会比想象中快得多。