多数团队都会做“多模型接入”，但真正出现供应商波动时，系统还是会瞬间暴露出两个现实问题：一是备用模型从未在真实压力下跑过，二是大家并不知道什么时候该切、切多少、切完怎么验证。等线上真出问题再讨论这些细节，通常已经晚了。

所以，多模型架构并不等于高可用。高可用来自可重复的故障演练：提前定义触发条件、明确回退路径、验证关键功能在备用链路上能否正常跑完，再用演练结果逼出系统里的脆弱点。

一、先把“故障”定义清楚，不要只盯接口报错

供应商故障不只是一眼能看见的 5xx。对 AI 产品来说，更常见的是“服务没完全挂，但已经不适合继续承载生产流量”。常见故障形态包括：

故障类型	表现	是否需要切流
硬故障	5xx、连接失败、网关超时明显升高	通常需要
软故障	首 token 延迟飙升、流式断流增加	视场景而定
限流故障	429 激增、Retry-After 持续拉长	通常需要
质量故障	结构化输出错乱、工具调用失败率异常	常需要局部切流

如果你的故障定义只有“HTTP 请求失败”，那很多真正影响用户体验的问题都不会触发演练和切换。

二、演练前必须具备的四个前置条件

演练不是临时写脚本压一下备用模型，而是要先确认系统具备基本可切换性。最低要求通常有四个：

1. 主模型和备用模型都有清晰的路由入口
2. 关键任务支持按模型或供应商维度观测成功率
3. 应用层能按功能做局部降级，而不是只能全站切换
4. 业务方知道哪些能力可以牺牲、哪些必须保住

特别是第三点很关键。很多系统的“备用方案”其实只是把全局环境变量从 A 改到 B，这种方式在演练里很难验证真实效果。更稳妥的做法，是像AI Agent Fallback 设计和多模型成本智能路由方案里提到的那样，把路由能力放在调用层，而不是散落在业务代码里。

三、先确定降级优先级，再谈切换动作

一旦主供应商异常，不同功能不应该同等对待。一个实用做法是给功能分级：

级别	示例	故障时策略
P0	核心问答、付费工作流	优先切到备用模型
P1	报告生成、批量分析	可以排队或延迟执行
P2	推荐文案、辅助摘要	可以降质或暂时关闭
P3	内部实验功能	可以直接熔断

这样做的好处是，切换时不会把全部流量一起打向备用供应商，避免“主供应商刚故障，备用供应商也被你自己压垮”。

四、演练脚本要覆盖“探测、切换、验证、回退”

一场完整的故障演练至少包含四段：

1. 探测

验证监控是否真的能发现异常，比如 5 分钟窗口内错误率、首 token 延迟和断流率是否超过阈值。

2. 切换

把一部分或全部流量切到备用链路，观察是否出现新的格式、上下文或工具兼容问题。

3. 验证

跑一组固定的关键任务，确认最重要的用户路径仍可完成。

4. 回退

确认主供应商恢复后，流量如何逐步切回，避免反复抖动。

下面是一个足够实用的路由配置例子：

routes:
  interactive_chat:
    primary: provider_a/main_model
    fallback:
      - provider_b/backup_model
      - provider_c/cheap_model
    trigger:
      error_rate_5m: 0.08
      first_token_p95_ms: 4000
      stream_abort_rate_5m: 0.03
  batch_report:
    primary: provider_a/batch_model
    fallback:
      - provider_b/async_model
    trigger:
      queue_timeout_s: 120
      error_rate_10m: 0.05

关键不是 YAML 长什么样，而是每个功能都有自己的触发条件，而不是共享一套模糊规则。

五、验证阶段不要只跑“能通”的 smoke test

很多演练失败，不是切换失败，而是验证太弱。团队只测“接口返回了 200”，却没有验证真正重要的业务结果。建议把验证集分成三类：

• 结构验证：JSON、工具调用、函数参数是否还合法
• 体验验证：首 token 延迟、整轮完成时间是否在可接受范围
• 业务验证：关键任务是否得到可交付结果

尤其是结构化输出和工具调用，在跨模型切换时最容易出兼容问题。可以把这部分测试和LLM 输出验证：schema + 业务规则双层以及LLM API 错误重试策略设计结合起来做自动校验，而不是靠人盯日志。

六、要故意制造三类常见失效场景

如果演练只模拟“完全不可用”，你会漏掉最常见的灰色故障。更建议主动注入三类失效：

1. 高错误率：模拟 5xx 或连接中断
2. 高延迟：请求能成功，但首 token 明显变慢
3. 部分能力失效：普通对话能跑，工具调用或流式输出异常

这三类失效对应的操作决策完全不同。高错误率往往要快速切流；高延迟可能先做部分降级；能力失效则需要按功能局部切换。把这些情况都演过，值班人才不会把“所有异常都当成同一种事故”。

七、故障演练要和观测系统绑死

没有观测，演练只是表演。至少建议准备下面这几张图：

图表	作用
分供应商成功率	判断是否真的是单供应商故障
首 token P95	发现软故障和长尾抖动
断流率	识别流式输出层异常
回退命中率	看 fallback 是否真的接住流量
关键任务完成率	判断用户体验是否可接受

如果你的系统已经做了AI Agent 可观测性设计或AI 流水线的错误追踪方案，演练阶段就应该直接复用这些 trace 和指标，而不是另起一套临时日志。

八、复盘时一定要记录“切换成本”

多数团队复盘只写“系统恢复用了多少分钟”，但对多模型系统来说，还应该额外记录：

• 备用模型导致的成本上升幅度
• 某些功能因为降级而丢失了哪些能力
• 是否出现了新的重试风暴或队列堆积
• 哪些阈值过于敏感，触发了误切换

这部分很适合和AI Agent 多租户成本归因以及LLM 延迟优化实战放在一起看，因为很多“可用性问题”最终会转化成“成本问题”和“性能问题”。

九、一套可以每月重复的最小演练模板

如果你要把故障演练制度化，可以直接采用下面这个模板：

1. 选 2 个核心功能和 1 个低优先级功能
2. 在低峰期人为注入 10 分钟供应商错误或高延迟
3. 观察监控是否在预期时间内告警
4. 执行自动或人工切流
5. 跑固定验证集，记录成功率、延迟和成本变化
6. 恢复主链路，验证是否平滑回切
7. 24 小时内完成复盘，更新阈值和运行手册

做到这一步，你的“多模型高可用”才算从架构图走进了真实运营。

十、相关阅读

• AI Agent Fallback 设计：如何让 LLM 调用更稳定
• 多模型成本智能路由方案
• LLM API 错误重试策略设计
• AI Agent 可观测性设计

如果你希望先把多模型接入和路由层统一起来，YoTradeApi 可以作为统一 API 接入入口，便于你在上层实现自己的切流、观测和演练机制。