上个月我们团队扩到 14 个人后端在用 GPT-4o 做代码产品侧用 Claude Opus 4 写文档和需求拆解数据组用 DeepSeek V3 跑批量分析。三个模型各有各的 Key各有各的计费面板。月底财务找我对账我打开三个后台导出了三份 CSV手动合并花了快两小时。那天我就决定必须搞一个统一的 API 网关把这些 Key 收拢起来。折腾了大概一周半踩了不少坑最终方案跑通了。这篇把整个过程写下来包含自建方案和聚合平台方案的对比给有类似需求的团队一个参考。这篇适合谁团队 5 人以上同时调用 2 个以上模型厂商 API 的技术负责人每月 AI API 开支超过 ¥3000需要按项目/成员拆分成本的团队被 Key 泄露、429 限流、对公发票搞烦了的工程师在纠结自建网关还是用现成聚合平台的决策者整体流程盘点现有 Key 和用量分布半天确定方案自建 One-API 还是用聚合平台1 天评估配置网关 分发子 Token半天到 1 天接入监控和告警2-3 小时建立 Key 轮换和项目隔离规则持续迭代graph TD A[盘点现有 Key] -- B{自建 or 聚合平台?} B --|自建| C[部署 One-API] B --|聚合平台| D[注册 OpenRouter 等聚合平台] C -- E[配置渠道 分发子 Token] D -- E E -- F[接入监控告警] F -- G[Key 轮换 项目隔离]先说结论维度自建 One-API聚合平台如 OpenRouter初始部署半天~1天10 分钟注册即用运维人力需专人值守升级/扩容自己来零运维模型覆盖需手动添加每个渠道100 模型开箱即用用量审计有但 UI 比较粗按 Model/User/Key 多维度可视化对公发票不支持各厂商分别开部分平台支持统一开票适合谁有运维能力、对数据主权要求极高中小团队、不想养基础设施的我们最终选了混合方案核心业务用聚合平台改 base_url 就行内部实验性项目跑自建 One-API。第一步盘点你的 Key 散落在哪里这步看起来简单实际上最容易被忽略。我花了半天时间在公司 Vault 和各种 .env 文件里翻最后发现——我们居然有 7 个 OpenAI Key其中 3 个是离职同事申请的个人账号。建议做一张表Key 编号厂商绑定项目持有人月均消耗到期时间sk-proj-xxx1OpenAI代码服务张三¥1,200无sk-ant-xxx2Anthropic文档生成李四¥800无sk-ds-xxx3DeepSeek数据分析王五¥400无这张表就是你后续所有操作的基础。没有它后面配什么都是瞎搞。第二步选方案——自建网关还是用聚合平台方案 A自建 One-APIOne-APIsongquanpeng/one-api是中文社区用得最多的开源网关。部署很快# 镜像名称可能随版本变化建议以官方 README 为准 # https://github.com/songquanpeng/one-api docker run -d --name one-api \ -p 3000:3000 -v /data/one-api:/data \ ghcr.io/songquanpeng/one-api跑起来之后在 Web 面板里添加渠道把各家 Key 填进去然后给团队成员分发子 Token。但说实话我们跑了两周就遇到问题了。4 月 15 号凌晨 3 点One-API 进程 OOM 挂了第二天早上产品同事告诉我API 全挂了。我一个人维护这东西没有 on-call 机制压力不小。One-API 的用量面板也比较粗糙只能看到总调用量没法按成员维度精确到每笔 Token 消耗多少钱。财务要的按项目拆成本还是得手动算。方案 B用聚合平台后来我们把生产环境切到了聚合平台。目前市面上常见的选项有 OpenRouter、ofox.io 等各平台的收费结构和加价比例不尽相同建议直接查阅各平台官网定价页面以官方公示为准。选平台时重点关注定价透明度、模型覆盖范围、SLA 保障、以及是否支持对公开票。切换成本极低——改一行 base_urlfrom openai import OpenAI client OpenAI( api_keyyour-team-key, base_urlhttps://openrouter.ai/api/v1 # 替换为你选用的平台地址 )原来的代码一行不用动model 参数照写对应的模型名称就行。第三步配置项目隔离和子 Key 分发不管你选哪个方案核心思路一样原始 Key 只有管理员持有团队成员拿到的是子 Token。我们的隔离策略Team Key管理员持有绑定计费账户 ├── Project: code-review后端组 │ ├── member-key-zhangsan │ └── member-key-lisi ├── Project: doc-gen产品组 │ └── member-key-wangwu └── Project:>第四步Key 轮换策略我们的规则原始 Key 每 90 天轮换一次旧 Key 保留 7 天观察期后废弃子 Token 跟随项目生命周期项目结束即回收离职当天回收所有关联子 Token这个之前没做吃过亏轮换时的操作流程# 前置步骤先在上游厂商控制台OpenAI / Anthropic / DeepSeek 等生成新 Key # 1. 在网关后台新增渠道填入新 Key # 2. 设置权重新渠道 weight10旧渠道 weight1 # 3. 观察 24h 无异常后禁用旧渠道 # 4. 7 天后删除旧渠道并在上游厂商控制台同步吊销旧 Key这套流程不复杂但如果没有网关层你得挨个通知 14 个人换 Key。第五步监控和告警最基本的三个告警必须配429 限流告警——上游返回429 Too Many Requests超过 5 次/分钟时通知余额告警——账户余额低于 ¥500 时通知我们吃过余额耗尽导致全线挂掉的亏异常消耗告警——单个 Key 日消耗超过均值 3 倍时通知真实报错长这样上游渠道全部不可用时网关会返回{ error: { message: No available channel. (all channels are disabled or quota is exhausted), type: one_api_error, code: no_available_channel } }第一次见到这个报错是周一早上 9 点全组 14 个人同时找过来。那天之后我就把告警接到了企业微信机器人做到提前预警。不同场景怎么选10 人以下、月消耗 ¥5000 的小团队直接用聚合平台别折腾自建。改个 base_url 十分钟搞定把精力放在业务上。10-50 人、有专职运维的中型团队混合方案。生产环境走聚合平台保证 SLA内部实验/测试环境跑自建 One-API 省成本。50 人以上、有合规要求的大团队考虑 Kong AI Gateway 或 AWS Bedrock 这种企业级方案或者跟聚合平台谈 Enterprise SLA99.99% 专属通道。对发票有硬需求的各家厂商分别开票较为繁琐OpenAI 还是美元账单部分聚合平台支持统一对公开票选型时可重点确认这一能力。常见问题 FAQQ: 走网关会不会增加延迟A: 自建 One-API 部署在同机房的话几乎无感增加 5ms。聚合平台的延迟取决于平台节点位置、所用模型及当时网络状况建议在正式接入前针对自己的目标模型实测不同模型、不同时段的响应时间差异较大。Q: 原始 Key 放在网关里安全吗A: 恰恰相反。原始 Key 只存在一个地方网关配置比散落在 14 个人的 .env 文件里安全多了。自建方案记得加密存储 限制 Web 面板的访问 IP。Q: 团队成员能看到原始 Key 吗A: 不能。成员拿到的是网关签发的子 Token通过子 Token 调用时网关自动路由到对应渠道。子 Token 的格式由网关管理员配置决定具体以你所用网关的文档为准。Q: 切了网关之后代码要改多少A: 如果你用的是 OpenAI SDK只改base_url一行。model 参数、messages 格式、streaming 写法全都不用动。我们 14 个人的项目改完总共花了不到 20 分钟。Q: 多个模型怎么做 fallback比如 Claude 挂了自动切 GPTA: One-API 支持渠道优先级和权重配置聚合平台一般也有自动 fallback 机制。以我们实际在用的模型为例可以配置 Claude Opus 4 → GPT-4o → DeepSeek V3 的降级顺序按优先级依次切换。小结多模型 Key 管理这事技术上不难难的是建立规范并且让团队执行。核心就三点原始 Key 集中管控、子 Token 按项目分发、用量可视化到人。我们从14 个人各管各的 Key到统一网关 自动告警前后花了大概一周半。现在每月底财务那边直接导出一份报表就行不用再手动对账了。这套方案也不一定是最优解特别是 Key 轮换周期到底 90 天合不合适、子 Token 的权限粒度要不要更细我还在观察。如果你们团队有更好的做法欢迎在评论区交流。