最近好几个朋友问同一个问题项目里想接多个大模型API结果每家接口风格都不一样代码里东一个SDK西一个SDK想换模型得动半天新增供应商更是要重读一叠文档。这其实就是多模型混合调用架构要解决的典型场景也是这篇文章想聊透的事——如何统一管理多个大模型API让上层业务像在调用一个模型。我前后在不同项目里折腾过三套方案从最早硬编码适配到中间接开源网关再到后来自己写了一个带路由和熔断的最小实现踩过不少坑。这篇文章直接把我觉得最靠谱的思路拆开讲包括统一抽象层设计、路由与降级策略、现成方案与自研的取舍、一份可以跑通的最小网关代码以及只有上线后被真实流量打脸才能发现的细节。适合正在做AI应用落地的后端和架构师也适合想给自己项目留一条后路的独立开发者。1. 为什么所有多模型应用最终都要过“网关”这一关如果只接一个模型确实不需要网关官方SDK直接用就行。但真实业务很难永远只用同一个模型。模型市场半年一个大变样今天这家便宜明天那家更强后天某个供应商突然限流数据要脱敏的场景得走私有化模型实时聊天要低延迟得用快速小模型大批量抽取要省成本得用廉价模型。一旦你的应用需要考虑“同一个Prompt交给不同模型”就会立刻发现一件麻烦事每个大模型API的请求体、鉴权方式、模型命名、限流策略、价格单位全都不一样。把这些差异直接散写在业务代码里等于把项目稳定性埋进一堆if else里。网关注存在的意义不是让代码看起来整洁而是把模型市场的变化挡在核心业务之外。业务侧只发一个标准请求网关负责决定用哪个供应商、构造对应格式、处理失败、记录成本。这个模式不是我发明的任何重度依赖外部服务的系统最终都会长出这样一层只是大模型API的粒度更细、变化更快这一层几乎变成了刚需。1.1 单一模型绑定的三个现实痛点第一个痛点是供应商故障与限流。大模型API不是传统接口那种“稳定可用性”一个爆款应用涌入大量用户谁都可能被限流供应商也会维护、升级、出故障。我之前就遇到过某天下午核心模型突然无法访问的情况当时如果没有备用模型整个功能就是瘫痪的。而备用模型绝对不可能等到故障发生那几天才临时去接必须提前就在体系里。第二个痛点是成本不可控。不同模型的价格差可以到十倍以上同一个模型在不同时段、不同输入输出比例下实际花费也完全不一样。如果没有一个统一的数据出口你根本不知道一个月跑下来钱到底花在了哪里。很多人在抱怨模型太贵其实真正的问题是没有预算控制机制。网关层做统一的Token计量和费用估算是成本治理的前提。第三个痛点是效果被锁死。一旦业务代码大量使用某个供应商的特定字段、特定工具调用格式迁移成本会高到让人放弃更换。我见过一个项目最早接入的模型没有工具调用能力团队用字符串解析硬扛后来终于换了个支持Function Call的模型结果原来的解析逻辑反而成了新包袱最后不得不重写一版。统一抽象层能让你只动网关配置而不是重构业务流程。1.2 统一管理到底统一了哪些东西统一管理至少包含五个维度缺一个都不完整。协议统一是最基本的把各家请求和响应转成一套内部标准格式业务不再关心对面是Chat接口还是Generate接口。模型目录统一也关键全公司或全项目只认一套模型名比如main-chat映射到某个供应商的实际模型名底层换版本时业务无感。密钥统一要求不让业务侧直接持有各家API Key密钥集中放在网关服务端再通过项目、用户、IP等维度做访问控制。可观测统一则是把每个请求的耗时、费用、成败、供应商、模型名统一落日志或指标这是后续做成本归因和路由优化的数据基础。配额统一是对不同业务线设置独立的每日Token预算和调用次数上限超了就走降级而不是等到月底看账单才反应过来。这五个维度听上去像大公司才需要的实际上个人项目也有价值。哪怕只有两个模型统一一下也能省掉大量切换成本。后面的章节我会一点点拆开讲。2. 统一抽象层把五家API的差异关在门里统一管理的第一步不是写路由而是先定一套内部标准格式。我把这一步叫做抽象层设计。没有它路由逻辑会变成一张蜘蛛网每接一家新模型就要改一堆业务代码。2.1 对话格式统一从messages到messages现在绝大多数模型的聊天接口无论底层架构怎么变对外都收敛成“消息列表加参数”的形态。OpenAI系是messagesClaude是messages但内容块结构不同Gemini原生接口是contents国产模型有的直接兼容OpenAI格式有的还保留自己的一套。网关内部需要定义一个标准请求体例如{ messages: [ {role: user, content: 帮我总结这段日志} ], tools: [ {type: function, function: {name: get_weather, description: ..., parameters: {}}} ], temperature: 0.3, max_tokens: 1024 }然后为每家供应商写一个轻量转换器标准请求体映射到该供应商请求体供应商响应体映射到标准响应体。这个转换器往往只有几十行但它能把所有供应商差异收编到一个目录里业务侧永远只认标准格式。工具调用是格式差异的重灾区。OpenAI的tool_calls、Claude的tool_use内容块、Gemini的functionCall字段名和嵌套结构都不一样。如果你的业务要支持工具调用标准化更要提前做。我的建议是内部保留一套宽松的OpenAI风格格式因为开发者熟悉、生态工具多非OpenAI系的供应商在这个标准上做额外映射就好。2.2 错误码与限流语义对齐这个问题平时不显眼一压测就爆。各家API的错误码设计差异很大有的限流返回429有的返回400加一行JSON说明超限有的令牌失效返回401有的返回403有的模型过载返回500有的返回503。如果你直接在业务代码里根据HTTP状态码判断很快就会被各种边缘情况逼疯。网关内部应该定义自己的错误枚举比如RateLimitExceeded、AuthFailed、InvalidPayload、UpstreamUnavailable、ContextTooLong然后统一把供应商错误映射进来。这样上层只面对一套错误语义重试、降级、告警都有统一入口。限流头部也一样。OpenAI的响应头里有x-ratelimit-limit-requests和x-ratelimit-remaining-tokens其他家的字段五花八门。网关要把这些读取出来换算成内部统一的“剩余额度”指标才能真正按供应商的实时余量做动态路由。只依赖失败后重试而不读这些头部信息很容易把已经被限流的接口调到雪崩。2.3 密钥管理与安全边界密钥集中放在网关侧是统一管理里最容易被低估的一环。很多团队早期图方便把各个API Key直接写在每个后端服务的环境变量里结果就是人员变动后到处都是可能泄露的凭据审计根本没法做。网关统一管理后业务调用时不需要也不应该知道真实Key网关按租户或应用维度下发放号密钥或者用短期Token。我见过一个很干净的做法网关对外暴露一个OpenAI兼容端点内部服务用网关分配的Key调用网关收到请求后从自己的密钥库里取出对应供应商的真实Key在服务端完成鉴权和参数注入。这样至少形成两层隔离第一层是业务与模型供应商之间的隔离第二层是真实密钥与内部服务之间的隔离。万一某个内部服务Key泄露影响范围也只限于它被授权的模型组合而不是整个模型池。3. 路由与降级让请求自己找最合适的模型抽象层解决“能不能调”路由层解决“调哪个最合适”。多模型混合调用价值最大的一块就在这里。3.1 路由维度拆解我把路由策略分成五种常用维度实际落地几乎都是组合使用路由维度典型场景选择逻辑能力代码生成、数学推理、长文档优先专用模型其次通用模型成本大批量摘要、数据清洗低价模型优先免费额度优先延迟聊天助手、实时翻译响应快的小模型优先稳定性核心链路、涉及支付的内容生产经验多、SLA有保障的模型优先合规数据敏感场景固定走私有化或指定区域模型权重也不是一锤子买卖。简单做法是给每个模型配一个weight按权重随机选进阶做法是让网关根据最近几十分钟的平均延迟、错误率、成本实时打分把流量切到更健康的模型上。免费额度模型可以参与打分但它们并发和频率限制往往更严格权重不能给得太高。3.2 免费额度模型在路由里的好用位置不少模型服务商都提供免费调用额度比如大厂的限时免费模型、新用户赠送Token、低规格模型常年放在免费档。对独立开发者和小团队来说这是实实在在的节流手段。我的建议是把它们放在两个位置一是低优先级兜底主模型不可用时切过去二是对响应质量要求不高但量大的场景比如内容标签、标题生成、日志分类让免费模型先跑。但要注意免费额度的边界经常藏在说明文档的角落里。有的按Token限有的按每分钟请求限有的限制返回频率还有的可能不允许商用。网关在配置这类模型时我建议单独打个free_tier: true标记并严格控制并发和单用户权重避免因为一次运营活动把免费额度瞬间打爆反而拖累正常请求。3.3 失败重试与熔断多模型网关里的重试不能是“同一个请求发三次”这么简单而应该配合路由做迭代式降级。第一优先级的模型失败后换到第二优先级再失败再换。这里有几个关键参数需要注意单次超时时间、最大重试次数、熔断阈值。我常用的初始值是单次超时15秒流式场景以首包时间为准最多换3个模型连续错误超过5次就把该模型临时熔断半分钟半分钟后再放少量探测流量。熔断状态机用最简单的三态就够Closed正常、Open熔断、Half-Open探测。不必一开始就上复杂算法先把状态记在内存里等流量大了再换Redis或分布式版本。熔断的价值不仅是保业务还能防止无限重试把已经过载的供应商彻底压垮。4. “抄作业”方案盘点现成网关和自研怎么选看到这里有人会说这些功能不是现成项目都有吗为什么还自己造轮子确实多模型网关在圈子里已经是成熟品类了关键看你处在什么阶段。4.1 主流网关类方案横向对比我实际用过三类LiteLLM、new-api以及托管聚合服务自己也搭过Gateway。LiteLLM是我比较推荐的起点。它提供OpenAI兼容接口支持上百个供应商接入自带虚拟Key、预算限制、成本追踪能力。代码成熟文档齐全适合中小团队直接部署或二次开发。它的代理模式就是把路由、密钥、计费逻辑以配置文件为中心和我后面要讲的自研思路一致只是细节比我写的示例完整得多。new-api和它的前身one-api在国内社区用得多。它们更偏对外分发先把各种渠道配进去再给内部或外部用户发额度号很多AI应用的工具站、公众号机器人都是这么搭的。优点是上手快、管理面板友好缺点也很明显它是围绕“用户-渠道-令牌”设计的和业务系统深度集成时需要额外写一层适配。托管聚合服务则是直接拿一个OpenAI兼容接口由平台帮你路由到不同模型、统一计费。适合不想自己维护基础设施的个人项目或早期产品但遇到合规、私有化、数据出境约束时会受限。4.2 什么规模该自研我给一个简单判断标准如果只是个人用或者内部工具链直接部署LiteLLM或new-api别折腾。如果业务需要特殊路由策略、要与内部账号体系深度整合、要对数据落地做审计或者有私有化交付要求那就必须自研或在开源项目上二次开发。自研成本没有很多人想的高一个最小网关核心也就几百行难的是后续维护和积累踩坑经验。别把自研和开源完全对立。很多团队最终是“自研业务层网关加开源核心依赖”的组合。比如用某个成熟项目做底层供应商适配和计费自己在上层加一套业务路由既省事又灵活。4.3 我踩过的选型坑有一个坑必须说开源网关项目版本更新速度普遍很快接口也经常变。有段时间我依赖某项目的旧版本接口写了不少代码结果它升级后把配置格式改了一半最后花两个晚上迁移。所以如果用开源方案第一不要过度自定义第二要在固定版本号上使用第三把配置和代码版本一起纳入管理。另一个坑是“看起来支持很多模型实际细节粗糙”。有些聚合方案宣传支持几十个供应商但个别模型的长上下文、视觉输入、工具调用只是“能转”没做到“转对”。选型时一定要拿自己的真实场景压测特别是多模态和Function Call不能只看支持列表。5. 从零实现一个最小可用LLM Gateway下面我用Python演示一个最小实现。核心思路是配置驱动、适配器模式、路由与重试解耦。这个版本能跑通多模型混合调用的基本盘生产使用再补观测和持久化即可。5.1 配置即策略一份YAML描述所有模型我习惯把可变的东西都放配置里。一个供应商一个小节模型挂在供应商下面每个模型标注上下文窗口、单价、权重、是否免费额度。示意配置如下providers: zhipu: base_url: https://open.bigmodel.cn/api/paas/v4/chat/completions api_key_env: ZHIPU_API_KEY models: glm-4-flash: context_window: 128000 max_output: 4096 price_per_m_in: 0 price_per_m_out: 0 weight: 1 free_tier: true dashscope: base_url: https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions api_key_env: DASHSCOPE_API_KEY models: qwen-turbo: context_window: 128000 max_output: 8192 price_per_m_in: 3 price_per_m_out: 6 weight: 2free_tier标记让路由时知道这个模型能省钱但限流更严price_per_m_in/out是每百万Token价格用来做成本估算。不要把这些数据写死在代码里否则供应商每次调价都要发版本。5.2 核心代理代码与供应商无关的调用核心核心逻辑可以分成三层路由层找候选清单适配层做格式转换调用层负责网络请求和超时。下面是一段高度简化的示意代码import os import httpx class Gateway: def __init__(self, config): self.providers config[providers] self.client httpx.AsyncClient(timeouthttpx.Timeout(30.0)) async def chat(self, messages, route_hintNone): candidates self._build_candidates(route_hint) last_error None for provider_name, model_name, meta in candidates: provider self.providers[provider_name] headers { Authorization: fBearer {os.environ.get(provider[api_key_env])}, Content-Type: application/json, } body self._adapt_request(provider, model_name, messages) try: resp await self.client.post(provider[base_url], headersheaders, jsonbody) if resp.status_code 400: raise RuntimeError(fupstream error: {resp.status_code} {resp.text[:200]}) data resp.json() return self._adapt_response(provider_name, model_name, data) except Exception as exc: last_error exc continue # 换下一个候选模型 raise RuntimeError(fall upstreams failed: {last_error}) def _build_candidates(self, route_hint): candidates [] for pname, pconf in self.providers.items(): for mname, mconf in pconf[models].items(): if route_hint and route_hint in mconf.get(tags, []): candidates.append((pname, mname, mconf)) else: candidates.append((pname, mname, mconf)) return candidates我把失败后的处理落在continue上因为多模型混合调用的核心理念是请求失败不是终点换一个模型继续才是重点。实际生产里_adapt_request和_adapt_response会按供应商做分支转换代码量不大但必须把每家差异记录清楚。5.3 响应规范化与流式处理注意事项响应规范化要做三件事把回复内容抽成统一字段把用量统计统一把流式事件转成标准SSE格式。很多团队规范了普通响应流式却忘了处理结果前端拿到的格式仍然五花八门。非流式响应至少要对齐三个字段text、input_tokens、output_tokens。OpenAI系返回choices[0].message.content和usage.prompt_tokens/completion_tokensClaude返回content[0].text和usage.input_tokens/output_tokens映射时千万别搞混。流式更麻烦每家SSE事件名都不一样OpenAI是data: {...}一行一个JSON国产模型很多沿用这个格式Claude则按内容块增量推进。网关最好统一转成OpenAI SSE风格再对外提供因为前端生态对它的支持最成熟。流式过程中如果发生错误前面已经吐出去的内容没法撤回。网关能做的是在日志里记录“本次流中有中断”并在后续请求中降低该模型权重。这个细节我会在下一章专门说。5.4 把免费额度API接入网关的配置示例免费额度模型的接入方式和普通模型没有本质区别但我会多加两层保护。第一层是配置里标记free_tier: true路由时默认把它们压低并发第二层是给它们单独设置“预算为0”的告警线一旦异常增长立刻通知或切回付费模型。route_policy: priority: - tags: [paid, low_latency] weight: 8 - tags: [free_tier] weight: 2 max_concurrency: 10 cost_guard: monthly_budget: 200 alert_when: 150 hard_stop_when: 200把免费模型当备胎而不是主力它不稳定是常态活动结束、余额清零、限流收紧都可能发生网关侧留有开关才算真正接入。6. 上线后被真实流量教育过的六个细节网关搭好只是开始真实流量会教你重新认识每家API。这六条每一条都是我和身边团队付过时间成本换来的。6.1 限流口径TPM/RPM/并发根本不是一回事有的供应商按每分钟请求数限有的按每分钟Token数限还有的按并发连接数限。你在网关里如果只设一个“每秒10次”的限流等于什么都没设置。正确做法是按供应商分别配置三层限制并发数、每分钟请求数、每分钟Token预算。Token预算可以通过输入长度和max_tokens做估算。宁可把限流阈值调低一点也不要让网关因为无限重试叠加限流风暴。6.2 计费单位不统一成本报表会骗人有的供应商按Token计费有的按字符计费价格有的按每百万Token有的按每千Token币种还不一样。如果网关不统一换算成本报表看起来便宜账单出来完全不是一回事。我建议网关内部统一用“每百万Token的人民币价格”作为计价单位响应里记录input_tokens和output_tokens再由独立模块算费用。免费额度也要纳入统一计费口径否则容易产生“没花钱”的错觉。实际是用了限时免费额度一旦过期同样调用量都会变成账单。6.3 流式模式的错误被吞掉平时代码里一个HTTP 500很容易抓住但流式请求的错误经常表现为“收到两行后突然断开”没有状态码没有错误JSON。前端如果没有兜底用户看到的就是回答到一半。网关在流式模式下要在内存里维护“最近N条SSE事件”的环形缓冲一旦连接中断告警里至少能带出上下文。断流后立刻把这个模型在路由里的评分拉低比事后看监控更有效。6.4 输出长度和上下文窗口经常被忽略不同模型对max_tokens的语义不一样有的是“本次最多输出多少”有的是“上下文加输出总共多少”。同一个Prompt换个模型很可能因为超长直接拒答。我遇到过最郁闷的案例某家模型把对话历史也计入了输出上限前端一旦长聊就开始报错排查两天才发现是参数语义理解错了。网关要对每个模型配置context_window和max_output并在请求前做一次预计Token数检查超了就截断或换更大窗口的模型。6.5 模型版本漂移防不胜防模型服务商经常把同名模型背后的实际版本静默更新尤其是不带日期后缀的名字。你在线评估时输出还正常两周后发现稳定性下降格式也变了。网关可以加一层运行时指纹校验定时跑一组固定Prompt把输出摘要、延迟、Token用量记录下来和基线对比偏差超过阈值就自动告警或切换固定版本。这个机制不复杂但能避免很多线上怪问题。6.6 网关要能回答“这次请求到底用了谁家模型”审计能力是统一管理多模型最后一块拼图也是最容易被忽略的。业务问“为什么同一个问题两次回答不一样”你至少要能查到这两次分别路由到了哪个供应商、哪个模型、花了多少Token、延迟多少。我在日志里固定记录provider_name、model_name、request_id、prompt_length、latency_ms、cost_estimate不管是做成本分析还是排查问题都有迹可循。这些细节比我当初把网关搭出来所花的时间还多。大模型API的协作方式还很年轻任何一层变化都可能打穿原有假设网关的价值就在于让你用最低成本应对这些变化。我现在的体会是统一管理多模型不是一次性工程模型列表会变、价格会变、免费额度会消失、限流策略会调整网关本身必须跟着持续演进。如果你也在做类似的事不妨先从一个配置优先的最小网关开始让路由策略长在真实数据上而不是长在对某个模型的依赖上。每次模型市场有变动你都能少被动一点。