> https://router.one/zh/blog/llm-fallback-strategies-production 的 Markdown 镜像，供 AI 助手与爬虫使用。Router One 是 OpenAI 兼容的统一 LLM API 网关。
> 发布：2026-06-10 · 修订：2026-09-01 · 作者：Router One Team

# 生产环境的 LLM Fallback 策略：不带惊喜的故障转移

_fallback 的触发条件、切换 provider 或模型的取舍、如何解读请求最终结果，以及如何用 request_id 支撑上游故障的运维排查。_

每家 LLM provider 都有状态不好的时候。新品发布期间限流收紧，区域性故障让 endpoint 下线，负载一上来延迟悄悄翻倍——而状态页往往很久之后才承认。如果你的应用只对接一家 provider，这些全都会变成你的故障。

故障转移是标准答案，但简单粗暴的故障转移会制造自己的问题：对话进行到一半回答突然换了"性格"，重试风暴放大故障，以及发生了也没法证明的故障转移。这篇文章讲的是在生产环境站得住的模式——以及让故障转移值得信任、而不只是看起来很忙的那些约束。

## 什么情况才应该触发故障转移

不是每个错误都值得换条路重试。在网关设计里，通常会评估三类失败：

- **5xx 响应** —— 上游挂了；在同一条路由上重试，多半只是把自己重新排进同一场故障。
- **网络错误和超时** —— 无法完成的连接可能适合尝试另一条可用线路。
- **劣化趋势** —— 持续上升的失败率和延迟，可以在下一次尝试前影响网关对候选的排序。

这条通用规则里刻意缺席的是大多数 4xx（逐状态码的处理见[错误码速查页](https://router.one/zh/llm-api-error-codes)）。畸形请求换到哪里通常都还是畸形的，拿另一家 provider 重试一个 401，只会重复同一个客户端问题。在 Router One 中，符合条件的上游失败可按网关路由策略尝试另一个可用候选；候选路由可使用延迟、成本与可靠性信号，准确的公开边界写在[路由方法论](https://router.one/zh/routing-methodology)里。

## 保持已请求模型不变

实践中最大的决策是故障转移*到哪里去*。替换已请求模型，技术上也许能返回响应，但语气、格式习惯、tool-calling 的怪癖、对 prompt 的敏感度全可能在用户会话进行到一半时变化——这是叠加在可用性事故之上的静默质量事故。

Router One 更窄的合同是**同模型供应商故障转移**：符合条件的重试可使用为应用明确请求的同一个模型提供服务的另一条健康 provider 线路，不会静默替换成其他模型变体。如果该模型没有符合条件的可用线路，请求会返回错误，而不是意外换模。

`model="auto"` 是另一条路径：候选集由 Router One 服务端管理，并可在其中重试。客户端仍发送标准 OpenAI 兼容请求体，不提供自定义 `router` 对象或请求级权重。

## 给切换定预算

让延迟翻倍的故障转移本身就是一种劣化。两个观测值让它保持诚实：

- **失败尝试耗时** —— 网关能转向下一候选前，上游尝试已经运行了多久。
- **重试耗时** —— 下一候选完成或失败用了多久。

端到端故障转移延迟包含两部分，并随上游行为变化。Router One 不承诺统一的 200ms 故障转移时延；对延迟敏感的应用应查看完整 Trace，而不是假设固定切换成本。

## 验证不了的，等于不存在

最常见的故障转移失败是静默的：配置看起来没问题，但谁也说不清实际是哪条线路处理了请求。Router One 的[每请求 Trace](https://router.one/zh/llm-observability)会记录最终模型和 provider 线路，以及用量、成本、延迟与状态；它不承诺展示每一次中间失败尝试的完整链路，因此事故分析应严格使用 Trace 实际暴露的证据。

有合规或评测约束的团队有时需要相反的保证——请求绝不在 provider 之间迁移。Router One 当前公开合同没有项目级故障转移关闭开关；在没有单独文档确认前，不要依赖这一控制能力设计系统。

## 常见问题

**哪些错误才应该触发 LLM 故障转移？**
值得评估故障转移的是 5xx 响应、网络错误与超时，以及可以影响候选排序的劣化趋势。大多数 4xx 不应换路重试：畸形请求换到哪里通常都还是畸形的，拿另一家 provider 重试 401 只会重复同一个客户端问题。准确的公开边界写在[路由方法论](https://router.one/zh/routing-methodology)里。

**故障转移会不会换掉我请求的模型？**
不会。Router One 的合同是同模型供应商故障转移：符合条件的重试可使用为同一个已请求模型提供服务的另一条健康 provider 线路，不会静默替换成其他模型变体。如果该模型没有符合条件的可用线路，请求会返回错误，而不是意外换模。

**`model="auto"` 的重试是怎么处理的？**
`model="auto"` 是另一条路径：候选集由 Router One 服务端管理，并可在其中重试。客户端仍发送标准 OpenAI 兼容请求体，不提供自定义 `router` 对象或请求级权重。

**Router One 承诺 200ms 的故障转移切换时延吗？**
不承诺。端到端故障转移延迟包含失败尝试耗时和重试耗时两部分，并随上游行为变化；对延迟敏感的应用应查看完整 Trace，而不是假设固定切换成本。

**怎么验证实际是哪条 provider 线路处理了请求？**
Router One 的[每请求 Trace](https://router.one/zh/llm-observability)会记录最终模型和 provider 线路，以及用量、成本、延迟与状态。它不承诺展示每一次中间失败尝试的完整链路，因此事故分析应严格使用 Trace 实际暴露的证据。

## 生产 checklist

- 只有符合条件的上游失败才会尝试另一个可用候选；不要假定每种错误都可重试。
- 精确模型的 provider 故障转移保持该模型不变；`model="auto"` 在服务端候选集中重试。
- 把失败尝试和重试一起衡量；没有固定的 200ms 保证。
- Trace 展示最终模型、provider、用量、成本、延迟与状态；不要假定每次中间尝试都会暴露。
- 不要假定公开配置里存在项目级重试上限或故障转移关闭开关。

[LLM 故障转移](https://router.one/zh/llm-fallback)和[智能路由](https://router.one/zh/smart-routing)页面描述了各部分如何协作，[中国延迟基准](https://router.one/zh/benchmarks/china-latency)展示了路由相关主张背后的测量纪律。在 [router.one](https://router.one/zh) 改一行 base-URL，整套模式就站在你现有代码的前面了。

## 相关页面

- 本页规范地址：https://router.one/zh/blog/llm-fallback-strategies-production
- LLM API 网关与路由：https://router.one/zh/llm-api-gateway
- 全部博客文章：https://router.one/zh/blog
- 模型与每模型 token 价格：https://router.one/zh/models （markdown：https://router.one/zh/models.md ）
- 定价：https://router.one/zh/pricing
- API 文档（markdown）：https://router.one/zh/docs.md
- 公司事实（markdown）：https://router.one/zh/facts/company.md