备用模型

它是什么

备用模型是在主模型不可用、受限流、超时或触发明确不可接受条件时，由系统切换使用的预先评测过的替代模型或配置。它服务于故障恢复和优雅降级，不是日常按任务择优的模型路由，也不是遇到任何失败就随机换一个供应商再试。[S1][S2]

为什么需要它

外部模型服务会出现区域故障、容量不足、限流和延迟尖峰。没有备用路径时，一个供应商问题可能让整个功能停止；设计良好的回退可以保留核心能力或给出可理解的降级结果。不过，可用不等于正确，未经验证的替换可能把服务故障变成更隐蔽的质量或安全故障。

它如何工作

团队先定义哪些错误可重试、重试次数和总截止时间，再为每类任务指定契约兼容且通过评测的备用路径。连续失败越过阈值时，熔断器暂停主路径并转向备用模型；响应要标记实际模型和降级状态，监控错误率、延迟与质量。主服务恢复后，通过健康探测和小流量试探逐步切回，而不是瞬间把全部请求压回去。[S1][S2]

必须澄清的误会

备用模型 ≠ 模型路由。 路由按请求特征主动选模型；备用模型是主路径失败后的兜底，触发条件是故障而不是任务类型。

备用模型 ≠ 回滚。 回滚把系统退回上一个已知可用的版本；备用模型是在同一版本内换一个模型继续服务，不涉及版本变更。

真实例子

企业知识助手的主模型连续三次返回可重试的服务错误，或单次调用超过 6 秒，就打开 30 秒熔断并使用已评测的小模型。备用模型只回答检索证据充分的常见问题，关闭复杂工具动作，并向用户显示“当前使用简化回答”。若备用模型也超时，系统停止级联调用，保留问题并提供人工渠道；主模型通过探测后才逐步恢复。

什么时候适合与不适合

对连续性有明确要求、调用量足以支持双路径测试的产品适合设计备用模型。高风险决策若不同模型无法满足同一安全和输出契约，宁可停止自动处理并转人工。模型之间可能在工具支持、上下文、语言、安全策略、成本和延迟上不同；回退还可能把流量集中到容量较小的次级服务，造成级联过载。[S1][S2]

亲自试一下

为一个生产调用写回退表，列出限流、服务错误、超时、结构错误和低质量五类触发器。每类明确是否重试、最大次数、备用路径、用户提示和停止条件，再设计“主服务恢复”和“备用服务也失败”两个演练。若任何分支可以无限重试，或切换后不记录实际模型，方案不合格。

接下来学什么

先回到AI 应用确定必须保留的核心任务，再学习模型路由区分正常选择与异常回退；工程上继续学习重试策略和错误恢复。

来源与修订

可靠性目标、错误和延迟阈值、简化模型回退、监控与优雅降级参考 Google Cloud AI/ML 可靠性指南 [S1]；自动故障转移、备用模型测试及一致性与负载边界参考 AWS 的 LLM 网关韧性实践 [S2]。供应商、模型、配额、错误类别和响应语义会变化，回退清单需随版本和容量持续演练。