最近两个月在做一个需要对接多个大模型的产品，前前后后踩了不少坑，记录一下，希望对遇到类似问题的朋友有帮助。
## 踩坑记录
### 坑一：Key 管理真是个体力活
项目初期只接了 DeepSeek，一个 Key 搞定。后来发现通义千问的 Qwen 系列在某些任务上表现更好，又去注册了一个。接着测试 GLM、Kimi……两个月下来：
- 浏览器密码管理器里多了七八个 API 平台的账号
- 代码里写死了好几个 base_url，每次切换模型都要改
- 对账的时候要登录各个平台查消费记录
最后实在受不了了。
### 坑二：某个平台的 SLA 不够稳
项目上线后，某个平台偶尔会出现 5xx 错误或者限流，虽然不是大故障，但每次都要手动切 Key、改配置。半夜被报警叫醒过一次之后，决定不能这么干了。
### 坑三：免费额度不够用
很多平台注册送免费额度，看起来很多，但真用起来消耗很快。而且有的免费额度有使用期限，有的只限特定模型，管理起来有点乱。
## 后来怎么解决的
思路很简单：**不要直接对接每个平台，中间加一层统一的调用层**。
做的事情：
1. **统一认证层** — 不管底层用的哪个模型，对外只暴露一个 API Key
2. **统一计费** — 所有模型按同一个计价方式扣费，不用记各平台的费率
3. **自动切换** — 一个渠道出问题，自动切到另一个同类型模型的渠道
实现方案参考了 One API 的开源项目改造而来。
## 实际效果
改完之后：
- 代码里只需要配一个 base_url、一个 Key
- 换模型只需要改参数里的 model 名，不需要改代码
- 某个渠道超时或报错时，自动切到备线，没有再半夜被叫醒
- 注册体验也优化了，用户名+密码就能注册，不用等邮箱验证
另外接入了几个完全免费的模型，用来做日常测试和原型验证，不用心疼额度。
## 小结
大模型 API 越来越多，直接对接各平台的方式在项目初期很灵活，但一旦涉及的模型数量上来了，值得花点精力做一层封装。
几个建议：
- 如果一个团队有多个项目在用 AI，统一管理 Key 和消费很有必要
- 免费模型完全够做原型验证，不要一开始就买大额度
- 容灾不是锦上添花，是关键能力
大家做多模型接入的时候有没有遇到其他坑？欢迎留言交流。