别再硬编码单一 LLM 厂商：2026 年 API 路由与 fallback 实操指南

这是我之前 2026 LLM API 价格战分析 的实操续篇。那一篇讲的是战略：同等智能在变便宜，没有任何一家厂商在价格上占据绝对主导，真正的赢是构建"厂商可迁移"的工作流。这一篇讲"怎么做"：当 OpenAI、Anthropic、Google 以及 DeepSeek、Z.AI 这类挑战者的价格表每次变动时，如何在不重写代码的前提下，在这些厂商之间路由请求。

我通读了目前能拿到的网关文档与对比资料后，结论很直接：大多数团队并不需要花哨的方案。他们需要一层薄抽象、一条 fallback 链，以及"按任务核算成本而不是按 token"的纪律。网关市场（LiteLLM、OpenRouter、Portkey、Vercel AI Gateway，以及 Bifrost 等新入场者）真实且有用，但很多团队在本该写 50 行包装代码就能解决时却去搬一个网关。下面把两者分开。

路由到底解决了什么核心问题

没有路由时，你的代码长这样：import OpenAI SDK、硬编码一个 model id、调用。当 OpenAI 涨价、或 Anthropic 对你的工作负载更便宜、或你的厂商宕机时，你面对的是一次横跨所有调用点的多周重构。这个重构成本就是厂商锁定的隐性税。

路由解决三个具体问题：

1. 价格机动性。 名次表变动时，你在配置文件里移动流量，而不是改源码。
2. 可靠性。 当一家厂商返回 429（限流）或 5xx 时，你的请求自动重试到第二家，而不是在用户面前直接失败。
3. 能力匹配。 不同任务该用不同模型——分类用便宜快模型、综合用强模型、图像用视觉模型——路由让你把这件事表达成策略，而不是在代码里到处撒 if/else。

第三点被严重低估。大多数团队只把路由当作 failover 想，但一旦你接入了多家，真正省钱的是"按任务路由"。

什么时候该用网关，什么时候一层薄包装就够

两个诚实的档位：

档位 1——一层薄包装就够。 如果你只有一个主厂商 + 一个 fallback，调用量也不大，写一个 50 行的 client，对外暴露一个统一的 complete(prompt, { task, model_hint }) 函数，内部挑厂商。把凭证和路由规则放进环境变量或一个小配置里。这会强制所有调用点走同一个边界——这才是唯一真正重要的结构承诺。你不需要新依赖就拿到了价格机动性和基础 fallback。

档位 2——你想要一个真正的网关。 一旦你需要跨厂商可观测性（按任务的 token 成本、延迟、按厂商的错误率）、跨两家以上的自动负载均衡、协议转换（Anthropic Messages API ↔ OpenAI Chat Completions）、缓存、或一个让非工程师也能改路由的 UI，网关就开始回本。2026 年值得了解的选项：

诚实的提醒：大多数"2026 最佳 LLM 网关"榜单都是厂商关联或内容营销驱动的。LiteLLM 的厂商覆盖和 OpenAI 兼容 API 的说法可以在它的 GitHub 仓库和文档上验证；其他的，在下定决心前请对照各厂商自己的文档验证。把榜单里的排名当营销看，不要当成中立评测。

真正用得上的四种路由模式

不管你选哪个工具，路由逻辑都落在四种模式里。大多数生产配置会组合其中几种。

1. Fallback 链（可靠性）

按顺序排列的厂商列表；第一家失败（429、5xx、超时）就试下一家。这是最低可行路由模式。

fallback: [anthropic-claude, openai-gpt, deepseek-v4]

关键工程细节：精确定义"失败"。429 是清晰的重试信号。200 但答案被截断或被拒绝，不是重试信号——除非你加了输出校验。很多团队只为 HTTP 错误设了 fallback，却忘了厂商可以返回一个"成功"的空答案或拒绝，而它同样需要 fallback 才有用。

2. 基于成本的路由（价格）

挑出在这个任务上跨过你质量门槛的最便宜厂商。这正是"按任务核算成本"回本的地方——如果你不知道在你的真实工作负载上、算上重试后哪家厂商真正最便宜，你做不了基于成本的路由。

task: "summarize"     → 通过 summarize 评测的最便宜模型
task: "code-generate" → 强模型，接受更高成本
task: "classify"      → 最小最快的模型

3. 基于延迟的路由（速度）

把请求路由到对这个请求响应最快的厂商，通常按区域感知。适用于面向用户的聊天场景——那里感知延迟比边际成本更重要。

4. 加权 / 负载均衡（吞吐）

按百分比在厂商之间分流量，以低于限流上限或分摊开销。大规模时有用；对小团队是过度设计。

我会给 2026 年大多数团队的实操建议：从模式 1（fallback 链）起步保可靠性，等有了按任务成本数据再加模式 2（基于成本的路由）；在有具体的延迟或吞吐问题之前，忽略模式 3 和 4。

一个具体的 fallback 配置（Portkey 风格）

为了让它不那么抽象，这里给出一个真实 fallback 配置的形状，改编自 Portkey 文档的模式。字段名因厂商而异，但结构是通用的：

{
  "strategy": { "mode": "fallback" },
  "targets": [
    { "provider": "anthropic", "model": "claude-sonnet-4-6", "override_params": { "max_tokens": 1024 } },
    { "provider": "openai", "model": "gpt-5-4" },
    { "provider": "deepseek", "model": "deepseek-v4" }
  ]
}

它买到的东西：当 Anthropic 返回 429 或 5xx 时，网关自动重试到 OpenAI，再到 DeepSeek。你的应用代码只调一个端点，剩下交给网关。这就是整个价值主张，一段话讲完。该模式的来源：Portkey 的 Claude Code + Anthropic 集成文档，其中显式记录了 fallback 模式。

协议转换：隐性税

一个不显眼的成本：OpenAI 和 Anthropic 不共享请求/响应结构。OpenAI 用 Chat Completions；Anthropic 用 Messages。如果你在它们之间路由，总得有什么东西做翻译。三个选项：

1. 会翻译的网关（LiteLLM、Portkey、API7、Vercel AI Gateway 都做这件事）。你写一套结构，网关转换。
2. 共享接口的厂商 SDK（Vercel AI SDK 和 LangChain 都做了这层抽象，代价是被限制在它们抽象所暴露的能力里）。
3. 在你的包装层里手动翻译。 简单场景能用，一旦涉及 tool call、图像、流式就会很快变痛苦。

对大多数团队，选项 1（会翻译的网关）或选项 2（SDK 抽象）是对的选择。手动翻译是个维护陷阱。

营销稿里不会写的锋利之处

几个网关厂商会淡化的风险：

• 网关本身是新依赖、也是新故障点。 如果你的网关挂了，它身后的所有厂商都够不着。对自托管的 LiteLLM 来说，你多运营了一个服务；对托管网关来说，你继承了它的宕机面。把网关可用性算进你的可靠性预算。
• 协议转换在边界处是有损的。 tool call、结构化输出、图像输入、流式语义，在不同厂商之间并不能完美对齐。用你真实的 prompt 跑过转换层，而不是只测"hello world"。
• 缓存可能悄悄返回陈旧答案。 很多网关提供语义缓存来降本。一个缓存命中却返回了细微过时的答案，比一次新调用更糟，尤其对任何时间敏感或用户特定的内容。分类和摘要可以激进缓存；个性化或事实问答要谨慎缓存，甚至不缓存。
• 账面更便宜可能因为重试反而更贵。 一个便宜 3 倍但需要 2 倍调用次数才能收敛到可用答案的模型，并不真的更便宜。按任务成本，而不是按 token 成本，才是唯一诚实的指标。
• 区域和账号风险不会因为有了网关就消失。 如果你的网关部署在一个区域，而那个区域对某厂商失去访问，你的 fallback 链只能到达网关能到达的区域。厂商多样 + 部署区域多样，才是真正的可靠性度量。

2026 年到底该怎么落地

我现在会给一个团队的实操落地路径：

1. 先建边界——哪怕你还没上网关。 把每个模型调用重构成走同一个内部函数或模块。这是杠杆最高的单一改动，零成本。
2. 在边界身后加第二家厂商作 fallback。 哪怕只有一个 fallback，对面向用户的功能来说可靠性都会大幅提升。
3. 给每个任务按厂商打点：成本、延迟、错误率。 看不见的东西你优化不了。
4. 只有在这之后再评估网关。 如果可观测性、协议转换、或多厂商负载均衡开始变痛，就上 LiteLLM（自托管）、Portkey（托管）、Vercel AI Gateway（已在 Vercel）、或 OpenRouter（市场最广）。如果不痛，薄包装继续赢。
5. 每季度重评路由。 价格在动，新模型在发，名次表在翻。你的路由配置应当是一份活文档，在重大模型发布或厂商调价时复查。

我的看法

从 2026 价格战里状态最好的团队，不是那些押中"最佳"网关的，而是那些早早建好了边界——一个内部承载厂商选择的单一位置——然后边学边往边界身后填路由、fallback、成本核算的。网关是工具，不是战略。战略是：让厂商选择成为一个可逆的、配置驱动的决策。

如果你想找一个本文涉及厂商的常驻参考表，包括我们站点跟踪的那些，可以看我们的 AI 价格数据页。如果你还没读过，先读姐妹篇 为什么这件事在战略上重要——本指南是"怎么做"，那一篇是"为什么"。本主题集群的第三篇——如何测出每个任务到底花了多少，让你能基于真实数据做路由决策——见 按 token 计费在骗你：2026 年按任务核算 LLM 成本的可观测性指南。

来源

• BerriAI/litellm — 开源 LLM 网关（GitHub）
• Portkey 文档：Claude Code + Anthropic fallback 配置
• Braintrust：2026 最佳 LLM 路由器与模型路由平台
• Maxim AI：2026 最佳 LLM 网关
• API7：把 Anthropic Messages 转换为 OpenAI Chat Completions
• dev.to：用网关实现自动 LLM 厂商 fallback
• theroadtoenterprise：在你的模型消失之前建好 LLM fallback 层
• Vercel AI Gateway
• Anthropic：Claude 平台文档
• OpenAI：API 参考
• 我们的姐妹篇：2026 LLM API 价格战