先说结论：只对符合条件的失败（5xx、超时、网络错误）换路重试，保持已请求的模型不变，把失败尝试和重试的耗时放在一起衡量，并用每请求记录核对每个最终结果。Router One 自己的做法是同模型供应商故障转移——符合条件的重试会走另一条提供同一模型的健康线路，不会换成别的模型。
每家 LLM 供应商都有状态不好的时候。新品发布期间限流收紧，区域性故障让接口下线，负载一上来延迟悄悄翻倍——而状态页往往很久之后才承认。如果你的应用只对接一家供应商，这些全都会变成你的故障。
故障转移是标准答案，但简单粗暴的故障转移会制造自己的问题：对话进行到一半回答突然换了"性格"，重试风暴放大故障，以及发生了也没法证明的故障转移。这篇文章讲的是在生产环境站得住的模式——以及让故障转移值得信任、而不只是看起来很忙的那些约束。
什么情况才应该触发故障转移
不是每个错误都值得换条路重试。在网关设计里，通常会评估三类失败：
- 5xx 响应 —— 上游挂了；在同一条路由上重试，多半只是把自己重新排进同一场故障。
- 网络错误和超时 —— 无法完成的连接可能适合尝试另一条可用线路。
- 劣化趋势 —— 失败率持续走高的线路，可以在下一次尝试前被排到后面。
这条通用规则里刻意缺席的是大多数 4xx（逐状态码的处理见错误码速查页）。畸形请求换到哪里通常都还是畸形的，拿另一家供应商重试一个 401，只会重复同一个客户端问题。在 Router One 中，某条线路出现 429、5xx 或超时时，会换到同一模型的另一条线路重试；持续报上游错误的线路会被自动排到最后，恢复后再回到正常顺序。准确的公开边界写在路由方法论里。
保持已请求模型不变
实践中最大的决策是故障转移到哪里去。替换已请求模型，技术上也许能返回响应，但语气、格式习惯、tool-calling 的怪癖、对 prompt 的敏感度全可能在用户会话进行到一半时变化——这是叠加在可用性事故之上的静默质量事故。
Router One 的承诺更窄：同模型供应商故障转移——符合条件的重试可使用为应用明确请求的同一个模型提供服务的另一条健康供应商线路，不会静默替换成其他模型变体。如果该模型没有符合条件的可用线路，请求会返回错误，而不是意外换模。
model="auto" 是另一条路径：候选集由 Router One 服务端管理，并可在其中重试。客户端仍发送标准 OpenAI 兼容请求体，不提供自定义 router 对象或请求级权重。
给切换定预算
让延迟翻倍的故障转移本身就是一种劣化。要把切换成本算清楚，看两个数：
- 失败尝试耗时 —— 网关能转向下一候选前，上游尝试已经运行了多久。
- 重试耗时 —— 下一候选完成或失败用了多久。
端到端故障转移延迟包含两部分，并随上游行为变化。Router One 不承诺统一的 200ms 故障转移时延；对延迟敏感的应用应查看完整 Trace，而不是假设固定切换成本。
验证不了的，等于不存在
收到响应后仍需验证结果。Router One 的每请求 Trace记录模型、请求 ID、用量、成本、延迟与状态。把日志与客户端收到的最终结果对应起来，HTTP 200 不足以证明流式输出完整结束。控制台请求日志不公开实际上游供应商、渠道或内部路由尝试。
有合规或评测约束的团队有时需要相反的保证——请求绝不在供应商之间迁移。Router One 目前公开的能力范围不含项目级故障转移关闭开关；在没有单独文档确认前，不要依赖这一控制能力设计系统。
常见问题
哪些错误才应该触发 LLM 故障转移？ 值得评估故障转移的是 5xx 响应、网络错误与超时，以及失败率持续偏高、应当排到后面的线路。大多数 4xx 不应换路重试：畸形请求换到哪里通常都还是畸形的，拿另一家供应商重试 401 只会重复同一个客户端问题。准确的公开边界写在路由方法论里。
故障转移会不会换掉我请求的模型？ 不会。Router One 的做法是同模型供应商故障转移：符合条件的重试可使用为同一个已请求模型提供服务的另一条健康供应商线路，不会静默替换成其他模型变体。如果该模型没有符合条件的可用线路，请求会返回错误，而不是意外换模。
model="auto" 的重试是怎么处理的？
model="auto" 是另一条路径：候选集由 Router One 服务端管理，并可在其中重试。客户端仍发送标准 OpenAI 兼容请求体，不提供自定义 router 对象或请求级权重。
Router One 承诺 200ms 的故障转移切换时延吗？ 不承诺。端到端故障转移延迟包含失败尝试耗时和重试耗时两部分，并随上游行为变化；对延迟敏感的应用应查看完整 Trace，而不是假设固定切换成本。
如何验证请求的最终结果？ 在 Router One 的每请求 Trace中核对模型、请求 ID、用量、成本、延迟与状态，再与客户端收到的结果对应。结果不完整或不一致时，请向支持人员提供请求 ID。
上线检查清单
- 只有符合条件的上游失败才会尝试另一个可用候选；不要假定每种错误都可重试。
- 精确模型的供应商故障转移保持该模型不变；
model="auto"在服务端候选集中重试。 - 把失败尝试和重试一起衡量；没有固定的 200ms 保证。
- 用模型、请求 ID、用量、成本、延迟与状态核对最终结果。
- 不要假定公开配置里存在项目级重试上限或故障转移关闭开关。
LLM 故障转移和智能路由页面描述了各部分如何协作，中国延迟基准展示了路由相关主张背后的测量纪律。在 router.one 注册后把 base URL 换过来，现有代码就能用上这一整套模式。