多模型聚合 API：一个 Key 调所有大模型

2026-06-13

如果你的应用需要同时调用 GPT-4o、Claude 3.5、Gemini 1.5 Pro，就要维护三套 SDK、三套密钥和三套错误处理——聚合 API 把这一切统一成一个端点：一个 Key，一套接口，所有模型。

聚合 API 是什么，解决什么痛点

聚合 API（也称 AI 网关、多模型代理）是位于你的应用与各大模型服务商之间的中间层。它向上游适配 OpenAI、Anthropic、Google、Mistral、国内百度/阿里/智谱等数十家服务商的原生 API，向下游对外暴露统一的 OpenAI 兼容接口。

没有聚合层时常见的痛点：

多套 SDK 并存：不同服务商 SDK 的认证方式、请求格式、错误码各不相同，代码膨胀难维护。
密钥分散管理：每个服务商一个 key，轮换、审计、权限管控分散。
无法灵活切换：某家模型涨价或故障，改代码成本高，业务中断风险大。
成本不透明：各家计费标准不同，很难统一核算 token 用量与支出。

聚合层把这些全部收归一处。

统一接口与 OpenAI 兼容

大多数聚合 API 网关采用 OpenAI Chat Completions 格式作为统一协议——这是目前事实上的行业标准。

# 只需把 base_url 指向聚合层，其余代码不变
from openai import OpenAI

client = OpenAI(
    api_key="your-gateway-key",
    base_url="https://api.example-gateway.com/v1"
)

response = client.chat.completions.create(
    model="claude-3-5-sonnet",   # 在聚合层路由到 Anthropic
    messages=[{"role": "user", "content": "你好"}]
)

切换模型只需改 model 字段，业务代码零改动。主流聚合方案普遍支持 /v1/chat/completions、/v1/completions、/v1/embeddings 等端点，部分还支持 /v1/images/generations。

这段代码看着简单，但背后干的活不少，值得拆开说说。你的请求打到聚合层的 /v1/chat/completions 之后，网关要做三件事：第一，按 model 字段查路由表，确定这次请求该转发给哪家上游，比如 claude-3-5-sonnet 对应到 Anthropic 的 /v1/messages；第二，做协议翻译——OpenAI 格式和 Anthropic 原生格式不是一回事，字段名不同（messages 结构里 system 提示词的位置就不一样，OpenAI 允许 role: system 混在消息数组里，Anthropic 要求 system 单独作为顶层参数），网关要把你传的 OpenAI 风格请求体转换成上游认的格式，拿到响应后再转换回来；第三，做鉴权转换，把你的网关 Key 换成网关内部保存的、对应上游服务商的真实密钥，你的 Key 从头到尾都不会被转发给上游。

这里有个坑经常被忽略：不是所有 OpenAI 参数在所有上游都有对应实现。比如 presence_penalty、frequency_penalty 这两个采样参数，Anthropic 和 Google 的原生接口根本没有对应机制，聚合层通常的做法是”能映射的映射，不能映射的静默丢弃”——你传了参数，接口不报错，但实际不生效，模型行为跟预期不一致。排查这类问题的思路是：先在聚合层的响应头或用量日志里看这次请求实际打到了哪个上游、传了哪些参数，很多网关会在响应里加一个 x-gateway-upstream 之类的自定义头方便你核对。工具调用（function calling / tool use）也是重灾区，各家的 schema 定义方式差异更大，如果你的应用重度依赖 tool calling，接入前务必用目标模型跑一遍最小可复现用例，别等上线了才发现某个上游不支持你用的调用格式。

路由、负载均衡与容灾

聚合层的核心价值之一是智能路由：

路由策略	说明	典型场景
按模型名映射	`gpt-4o` → OpenAI，`claude-*` → Anthropic	多模型并存
优先级/权重轮询	主路由失败自动切备用	高可用容灾
成本优先	优先选当前最便宜的满足需求的模型	成本优化
延迟感知	实时测速，选响应最快的上游	低延迟要求
地域合规路由	数据只发往特定区域的服务商	数据主权要求

容灾通常包含：上游超时自动重试（不同服务商）、熔断（连续失败后暂停路由到该上游）、fallback 模型（主模型 5xx 时降级到备用模型）。

这三种机制不是并列关系，是有先后顺序的一套组合拳，理解顺序才知道该配哪个。请求先看重试：网关发现上游返回 502/503 或者连接超时，会在毫秒级内换一条链路重发，这一步对你的应用完全透明，业务代码感知不到。如果同一个上游在短时间窗口内（比如 60 秒）连续失败超过阈值（比如 5 次），熔断器就会跳闸，接下来一段时间（通常几十秒到几分钟）直接不再往这个上游发请求，避免在对方本来就故障的时候还拿大量请求去”落井下石”，这段冷却期过后网关会试探性放行少量请求，确认恢复了才重新全量导流。fallback 则是最后一道保险——如果主模型这条链路重试也失败、熔断也没恢复，网关会自动把请求转发到你预先配置好的备用模型，比如主力 gpt-4o 打不通就退到 gpt-4o-mini 或者 claude-3-5-haiku，保证业务至少有响应，而不是直接给用户返回一个 500。

配置的时候有个容易踩的坑：fallback 模型的能力边界要和主模型对齐，别拿一个上下文窗口小得多、或者不支持你正在用的工具调用能力的模型去兜底，否则表面上”容灾成功”了，实际上返回的结果质量断崖式下跌，用户投诉排队而来，你排查半天才发现是走了 fallback 分支。建议 fallback 链路上线前，用同一批真实业务请求跑一遍主模型和备用模型的输出对比，心里有数再上生产。

统一计费与用量追踪

聚合层还解决了多服务商计费分散的难题：

Token 归一化计量：不同服务商 token 定义略有差异，聚合层做统一换算。
按项目/API Key 拆分：对外发不同 key 给不同团队，实现内部成本分摊。
预算限额：设置日/月 token 或金额上限，超限自动拒绝请求，防止账单失控。
明细日志：每次调用记录模型、token 数、延迟、费用，可导出分析。

自建 vs 托管：两条路的本质区别

这是最常见的决策节点。详细对比见自建聚合 vs 用托管服务怎么选，这里先给核心结论：

自建方案（OneAPI、NewAPI、LiteLLM 等开源项目）：你拥有完整控制权，数据不经第三方，但需要自己运维服务器、处理升级、排查上游兼容性问题。适合有 DevOps 能力、对数据留存有强要求的团队。

托管方案（OpenRouter、力达云聚合 API 等）：开箱即用，无需运维，服务商持续维护上游模型接入。适合希望专注产品、把精力放在业务而非基础设施的团队。力达云聚合 API 目前开放内测，针对中国大陆接入做了专线优化，感兴趣可申请力达云聚合 API 内测。

怎么选：决策路径

是否有 DevOps 资源长期维护？
├─ 否 → 托管方案（省运维）
└─ 是 → 数据是否需要完全自持？
         ├─ 是 → 自建（OneAPI/NewAPI/LiteLLM）
         └─ 否 → 对比自建运维成本 vs 托管月费，选更划算的

还需考虑以下因素：

上游模型覆盖：需要的模型是否都支持？尤其是国内模型（百度文心、阿里通义、智谱 GLM）。
计费透明度：是否有详细的 token 用量报表？
SLA 与支持：故障时有没有人响应？
合规要求：数据是否必须留在境内？

常见问题

聚合 API 会增加延迟吗？ 好的聚合层增加的额外延迟通常在 5–20ms 以内（网络层转发开销），相对于模型推理本身的延迟（通常 500ms 以上）可以忽略不计。容灾和负载均衡带来的稳定性收益远大于这点开销。

聚合层安全吗？密钥会泄露吗？ 正规聚合服务对上游密钥做加密存储，流量走 HTTPS，不持久化请求内容。自建方案完全自控，安全边界更清晰。核心是选可信赖的服务商并定期轮换密钥。

能同时调用多个模型做 ensemble（集成）吗？ 大多数聚合层本身不做 ensemble，但你可以在应用层发多个并发请求、自行合并结果。部分高级网关支持配置”多模型投票”策略。

现有代码要改多少才能接入聚合层？ 如果你已经用 OpenAI SDK，只需改 base_url 和 api_key，其余代码零改动。如果用的是原生 HTTP 请求，只需更新 URL 和 Authorization 头。