每家 LLM provider 都有状态不好的时候。新品发布期间限流收紧，区域性故障让 endpoint 下线，负载一上来延迟悄悄翻倍——而状态页往往很久之后才承认。如果你的应用只对接一家 provider，这些全都会变成你的故障。
fallback 是标准答案，但简单粗暴的 fallback 会制造自己的问题：对话进行到一半回答突然换了"性格"，重试风暴放大故障，以及发生了也没法证明的故障转移。这篇文章讲的是在生产环境站得住的模式——以及让 fallback 值得信任、而不只是看起来很忙的那些约束。
什么情况才应该触发 fallback
不是每个错误都值得换条路重试。值得行动的信号有三类：
- 5xx 响应 —— 上游挂了；在同一条路由上重试，多半只是把自己重新排进同一场故障。
- 网络错误和超时 —— 超过 per-model 时间预算的请求已经没救了，再等下去很少能等回来。
- 劣化趋势 —— 滚动窗口内错误率和延迟持续上升，足以支持在单条请求失败之前就绕开这家 provider。
刻意缺席的是：4xx。畸形请求换到哪里都是畸形的，拿另一家 provider 重试一个 401，只是在为同一个 bug 多花一次钱。Router One 的网关在 5xx、网络错误和 per-model 超时预算上触发 fallback，并用滚动错误率窗口在劣化路由彻底失败之前给它降权——具体信号写在路由方法论里。
留在同一个模型系列
实践中最大的决策是 fallback 到哪里去。把一条 Claude 请求切到 GPT 模型，技术上确实返回了响应，但语气、格式习惯、tool-calling 的怪癖、对 prompt 的敏感度全在用户会话进行到一半时变了——这是叠加在可用性事故之上的一场静默的质量事故。
更安全的契约是同系列故障转移：GPT 请求转移到另一条 GPT 系列路由，Claude 请求转移到另一条 Claude 系列路由。能力保持一致，prompt 继续有效，上层应用完全不用操心。这正是 Router One 强制执行的契约——fallback 永远不跨模型系列，实际作答的具体变体逐请求记录在案。如果同系列内没有健康路由，你拿到的是一个干净的报错，而不是一次意外换模。
给切换定预算
让延迟翻倍的 fallback 本身就是一种劣化。两个数字让它保持诚实：
- 单次尝试超时 —— 一条路由在网关放弃它之前能占用多久。
- 切换开销 —— 换路的额外成本；经 Router One 的一次端到端 fallback，在失败尝试之上额外增加的时间通常在 200ms 以内。
对延迟敏感的 endpoint 来说，这笔开销预算就是"用户毫无感知"和"fallback 本身成了事故"的分界线。
验证不了的，等于不存在
最常见的 fallback 失败是静默的：配置看起来没问题，但谁也证明不了它触发过。每次 fallback 都应该留下记录——哪条路由失败了、错误码和延迟是什么、最后是哪条路由完成了请求。经过网关，这份记录就是每请求 trace：两次尝试都在里面，你可以统计每天、每个模型系列、每家 provider 的 fallback 次数，在真实故障里验证这套机制，而不是选择相信它。
有合规或评测约束的团队有时需要相反的保证——请求绝不静默迁移。这应该是受支持的配置项，而不是 hack：企业合同可以按项目关闭 fallback，同时保留同样的 trace。
生产 checklist
- fallback 在 5xx、网络错误和超时预算上触发——不在 4xx 上触发。
- 故障转移留在同一模型系列内；没有静默的"性格切换"。
- 切换开销有界且已知（经网关在 200ms 以内）。
- 每次 fallback 都出现在事后可审计的每请求 trace 里。
- 绝不允许故障转移的项目可以显式关闭它。
LLM fallback 和智能路由页面描述了各部分如何协作，中国延迟基准展示了路由相关主张背后的测量纪律。在 router.one 改一行 base-URL，整套模式就站在你现有代码的前面了。