多模型 fallback 与容灾策略

很多 AI 产品默认绑死一个模型（"我们用 GPT"或"我们用 Claude"）。这看起来省事，其实是把命门交给了别人：模型 API 故障、限流、key 被误封、政策变动、价格上调——任何一个发生，你的产品当场下线或成本翻倍。

生产级 AI 应用，必须有多模型容灾。这篇讲怎么做。

一、单点的风险有哪些

把"只能调一家"当常态，至少四类风险：

1. 故障/限流：模型 API 自己会挂、会限流，高峰期 429/5xx 不罕见。
2. 封号：key 被误判滥用封禁（或团队人员变更），瞬间没模型用。
3. 政策/合规：某模型在某地区被禁、或你的内容触发它的策略被拒。
4. 商业：涨价、降配额、条款变更——你没议价权。

任一发生，单点架构就是事故。多模型不是"奢侈"，是风控必需。

二、三种容灾模式

1. 主备 fallback（最常用）。主模型正常时用它，失败/超时自动切备用模型。最简单、收益最大。

请求 → 主模型(Claude)
        ├ 成功 → 返回
        └ 失败/超时/限流 → 备模型(GPT) → 返回

适合：绝大多数场景。主备选能力相近的模型（Claude ↔ GPT ↔ Gemini），切了体验差不多。

2. 智能路由。按请求特征选模型，而非固定主备：

请求 → 路由判断
        ├ 简单任务 → 小模型(便宜快)
        ├ 复杂推理 → 大模型(强)
        └ 代码任务 → 代码优化模型

除了容灾，还能降本（简单活用便宜模型）。详见专门的成本控制文章。

3. 降级链。一条优先级链，前一个失败顺次下一个：

Claude → GPT → Gemini → 开源自部署(最后兜底)

关键：最后兜底用自部署开源模型——它不受 API 供应商影响，是真正的"最后防线"。对可用性要求高的场景，这条链能扛住所有商业 API 同时挂掉的极端情况。

三、什么时候触发 fallback

不是所有失败都该切，否则正常抖动也切来切去反而乱。触发 fallback 的条件：

• 明确错误：5xx、连接失败、超时——切。
• 限流 429：切（短暂限流可以重试，持续限流切备用）。
• 内容被拒：某模型策略拒了你的合法内容——切备用（不同模型策略不同）。
• 质量异常：输出格式错（JSON 解析失败）、明显异常——切。

不该切的：模型正常返回但内容你不满意（那是 prompt 问题，不是模型故障）。

四、工程实现：统一接口 + 重试 + 熔断

1. 统一接口抽象。 各家 API 协议不同，你的业务代码不该直接调某家 SDK。抽象一层：

interface LLMProvider {
  chat(messages, opts): Promise<Response>;
}

class ClaudeProvider implements LLMProvider { ... }
class OpenAIProvider implements LLMProvider { ... }

// 业务代码只依赖 LLMProvider,不知道具体哪家

这样换/加模型只改适配层，业务零改动。AI SDK（Vercel）这类库已经帮你做了这层抽象，一个 model 参数切换。

2. 重试 + 退避。 瞬时故障先重试（带指数退避），别一次失败就 fallback。比如：重试 2 次还失败再切备用——避免对正常抖动过度反应。

3. 熔断（circuit breaker）。 某模型连续失败（如 1 分钟失败 10 次），暂时标记它"不健康"，后续请求直接走备用，不再尝试它——直到它恢复。没有熔断，一个挂掉的模型会让每个请求都等超时才切，体感崩坏。

4. 超时设置。 每个模型调用设超时（如 30s），超时即切。LLM 偶尔会卡住（生成中途挂），不设超时会无限等。

五、状态管理：fallback 的隐藏难点

主备模型切了之后，多轮对话有个坑：上下文是哪家模型生成的格式。多数情况各家的 message 格式能兼容（role/content），但工具调用、系统消息细节有差异。

对策：

• 用统一的消息中间格式（你的抽象层负责和各家格式互转）。
• 工具调用结果尽量用通用格式存。
• 别在会话中途频繁切模型（同一会话尽量固定一个，故障切了之后整会话跟着切）。

六、成本与可靠性的权衡

多模型 fallback 不是免费的：

• 备用模型的 key 也要钱（即便不常用，调用时计费）。
• 多供应商管理（账号、key、账单、合规）复杂度上升。
• 自部署兜底要 GPU/运维。

权衡：按可用性要求分级。内部工具单点够（挂了等恢复），面向用户的产品必须主备，关键业务加自部署兜底。不是所有功能都要全链容灾，按风险定价。

七、可观测：知道切了、为什么切

fallback 要可观测：

• 每个模型的调用量、成功率、延迟：知道谁在扛流量。
• fallback 触发次数/原因：主模型频繁挂，要排查/换主。
• 告警：fallback 率突升（主模型可能出事了）。

没有可观测的 fallback 是黑盒——你以为在容灾，实际可能在主模型故障时才发现备用也没配好。

小结

多模型容灾是生产 AI 应用的风控必需，不是"以后再说"：

• 主备 fallback 是基础（主挂切备，能力相近的模型互备）。
• 智能路由 顺带降本（按任务选模型）。
• 降级链 + 自部署兜底 抗极端故障。
• 统一接口 + 重试 + 熔断 + 超时 是工程实现四件套。
• 可观测 知道切了、为什么。

记住一句：任何让你产品当场下线的单点，都是架构缺陷。 多模型容灾的投入，买的是"不把命门交给别人"——在 AI 供应商频出变故的当下，这份保险值得每个面向用户的产品标配。