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