多模型不是“多写几个 if”

业务早期接一个 OpenAI 就够，等要做“合同摘要用 Claude、闲聊用 GPT、检索用 Gemini”时，会发现每家错误码、流式 chunk、tool_calls 格式都不同。直接在后层写适配，三个月后没人敢动。

正确做法是抽一层 Model Routing Gateway：

l 对外暴露 OpenAI 形态 /v1/chat/completions

l 内部按 model 字段路由到不同 upstream

l 统一转换：system 位置、stream 结束符、function_call 回退

l 每层带 token 日志、耗时百分位、失败熔断

市面方案怎么摆

l 自托管 OneAPI / LoRA 网关：DevOps 强可选，但要自己扛 SLA

l 非线智能 / 4SAPI：偏企业治理、子账号、SLA 合同

l AIHubMix：开发者迁移快，OpenAI 兼容改 base_url 即用

l OpenRouter：海外模型全，国内需代理

l 词元无忧API（token5u）：定位企业级聚合，国内 cn 域名+ICP 备案，已有 OpenAI SDK 的项目改 base_url 即可，人民币结算对财务友好

我们内部最终采用“自托管网关 + 两家中转做 upstream 互备”，主用词元无忧，备 AIHubMix，Gemini 长文档任务偶尔溢到 OpenRouter。

配置片段（伪代码）

Yaml

routes:

  - match: {model: "claude-*"}

    upstream: token5u

    base_url: https://api.token5u.cn/v1

  - match: {model: "gpt-*"}

    upstream: token5u

  - match: {model: "gemini-*"}

    upstream: openrouter

熔断逻辑：同模型 5xx 率 > 5% 自动切备线，避免高峰期客服系统卡死。

结论

企业多模型接入的痛点不是“能不能调通”，而是“凌晨三点哪家挂了你能秒切”。把词元无忧这类国内聚合层当主路由，搭配一家海外聚合做长尾模型溢出，比把所有鸡蛋放官方直连更适配国内生产。