背景
事情要从一个闲聊机器人说起。 几个月前想做一个多功能 AI 助手，集成对话、翻译、代码生成等能力。调研后发现一件事——没有一个大模型能在所有维度上做到最好：
- 代码生成 → DeepSeek 系列强
- 通用对话 → GLM、Qwen 各有千秋
- 翻译 → 某些专用模型效果更好
- 推理链 → R1 系列 于是不可避免要接入多个模型。
第一阶段：原始方案
一开始的思路很直接——需要哪个模型就调哪个平台的 API。
client_a = OpenAI(api_key=KEY_A, base_url="https://api.deepseek.com")
client_b = OpenAI(api_key=KEY_B, base_url="https://dashscope.aliyuncs.com/compatible-mode/v1")
client_c = OpenAI(api_key=KEY_C, base_url="https://open.bigmodel.cn/api/paas/v4")
一个月后，问题开始暴露： Key 管理混乱。 代码里散落着七八个 API Key 配置，同事交接时要同步一堆敏感信息。安全性先不说，查个消费都要登录各平台。 错误处理重复。 每个平台的重试逻辑、超时设置、错误码含义都不一样，要分别处理。 没有容灾。 某个上午某平台出现大面积 5xx，服务也跟着瘫了一上午。
第二阶段：统一网关
重构的思路其实不复杂——加一层反向代理。 架构变成：
客户端 → 统一网关（认证 + 路由 + 计费）→ 各模型 API
网关负责三件事：
1. 认证统一
不管底层调的是哪个模型，客户端只需要一个 Key。网关根据请求参数中的 model 字段决定路由到哪个渠道。
2. 计费统一
各平台的计费方式不同。网关内部抽象一层额度配额（quota），所有模型统一按 quota 扣费： 模型单价 = 基础单价 × ModelRatio 这样用户不用理解各平台的计价差异。
3. 自动容灾
对同类型的模型配置多个渠道，网关检测到一条线路出错时自动切换到备线。核心就两个参数：重试次数和渠道优先级。
落地效果
改完后几个直观变化： Key 从 7 个变成 1 个。 同事只需要保存一个 Key。 模型切换只需要改一个参数。 前端可以随意切换模型做 A/B 测试。 免费模型的价值被释放。 很多平台有免费模型（如 glm-4-flash），之前一直没好好用。统一网关接入后，这些免费资源可以当作测试和生产验证的常备资源。 日维成本趋近于零。 不再需要登录各平台查看 Key 是否过期。
技术选型参考
如果自己动手实现，可以参考 One API 这个开源项目（Go 语言）。它已经封装了 50+ 渠道的适配。 如果不想自己维护，也可以用现成的聚合 API 服务。
一些经验教训
- 不要过早抽象。如果只用到两三个模型，直接调官方 API 完全够用。
- 容灾的触发条件要仔细设。太敏感导致频繁切换，太迟钝失去意义。
- 免费额度是双刃剑。用得好能大幅降低初期成本。
最后
多模型接入是很多 AI 应用必然要面对的问题。从早期规划好 API 层的抽象，能省去后面不少麻烦。 以上是两个月实战中摸索出的一些做法，欢迎讨论和指正。
