考察点
这道题出自 Amazon 大模型应用岗的技术面试，DSPrep 标注 Google/Amazon/OpenAI 常考。AWS 出身的公司问可用性工程顺理成章，面试官想验证你把 LLM 当成一个会挂的外部依赖来设计，而不是假设它永远 200。考察重点是：fallback 的触发条件（哪些错误值得切、哪些切了也没用）、主备模型质量差异怎么兜底、fallback 和 retry/ratelimit 的分层关系。追问会往多供应商负载均衡、熔断、成本突增监控走。
参考答案
机制：异常驱动的链条替换
LangChain 的 fallback 用 with_fallbacks 实现：任何 Runnable 都可以挂上备选链，主链抛异常时按顺序尝试下一个：
chain = primary_llm.with_fallbacks([secondary_llm, tertiary_llm])
语义很直白——primary 抛错，整个调用原样转给 secondary 再跑一次，secondary 也挂就走 tertiary，全挂才把异常抛给上层。注意它不是「主模型答得不好就换」，触发条件是异常，不是质量。这一点面试里必须说清楚，很多人含糊过去。
关键设计一：什么错误该切，什么错误不该切
生产上我把错误分三类处理：
| 错误类型 | 例子 | 策略 |
|---|---|---|
| 瞬时错误 | 429 限流、5xx、网络超时 | 先带退避重试（指数退避 + jitter，重试 2-3 次），仍失败再 fallback |
| 持续故障 | 供应商宕机、区域不可用 | 直接 fallback，重试是浪费延迟预算 |
| 业务错误 | 400 参数错误、上下文超长 | 不能 fallback——同样的输入换个模型照样 400，先修输入 |
这个分层很重要：retry 和 fallback 是两级，不是一回事。重试解决抖动，fallback 解决持续不可用。把 429 直接甩给 fallback 会让备用模型的配额也被打穿；把 400 拿去 fallback 纯属自欺。LangChain 允许指定只对特定异常类型触发 fallback（exceptions_to_handle），把 4xx 业务错误排除在触发条件外，这是必须配的参数。
上下文超长值得单独说：如果主模型报 context length exceeded，正确的 fallback 目标往往是一个更长窗口或更便宜的模型，而不是同规格的另一家——fallback 链的设计可以按错误类型分化，不一定是一条线性链。
关键设计二：主备模型的「质量差」要管理
切换成功的代价是行为变化：备用模型的输出风格、格式遵循度、tool calling 能力可能和主模型有差距。几个工程对策：
- 备用模型选型以「能力下限」为准，不是越强越好。主用 GPT-4o，备用选一个指令遵循和 JSON 输出同样稳的模型，哪怕贵一点；用一个格式都守不住的小模型当备胎，切过去等于制造二类故障。
- 输出层加护栏：fallback 之后统一过结构化校验（Pydantic），格式不对触发再生成或降级话术，别让半成品输出直接到用户。
- 埋点区分流量来源：fallback 发生的比例、切后答案质量的抽样评估要单独监控。fallback 率从 1% 跳到 10% 是供应商侧事故的最早信号，也是你自己配额/代码出问题的信号。
关键设计三：fallback 是成本变量
备用模型经常比主模型贵或便宜很多，且重试+fallback 意味着一次用户请求可能产生 2-3 次计费调用。成本控制上两条：一是给整条链设总超时（比如 15s），超时即降级成缓存答案或友好话术，别让多级 fallback 把 P99 拖到不可接受；二是 fallback 期间的单位成本告警——大促或故障窗口内账单可能翻几倍，财务侧要有预期。
更进阶的形态是主动路由替代被动 fallback：按供应商健康度（近 5 分钟错误率、延迟）做加权负载均衡，把流量实时倾向健康的一侧，故障时自然漂移过去，恢复后漂移回来。fallback 是请求级的兜底，健康路由是系统级的常态，生产上两者都该有。
可能的追问
1. fallback 和熔断器（circuit breaker）什么关系？
互补。fallback 是单次请求的兜底；熔断是状态机——某供应商错误率超阈值后直接「开路」，一段时间内请求不再打过去，避免每个请求都白等一次主模型超时才切备用。两者结合：熔断挡流量，fallback 保请求。
2. 流式输出做到一半断了，fallback 怎么办？
这是流式的硬伤：已吐给用户的 token 收不回。做法一是缓冲前 N 个 token 确认连接稳定再开始推流；二是断流后续传而非重头来（把已生成内容作为前缀让备用模型续写）；三是接受断流，前端降级提示。要在延迟和体验间取舍。
3. 自建开源模型和 API 混着做 fallback 有什么坑？
延迟特征完全不同（自托管首 token 可能更慢但稳定）、输出格式差异更大、且自托管实例挂了可能是你自己运维问题。混合 fallback 链里建议自建做主（成本低）、API 做备（弹性好），顺序反过来成本上不划算。