备用模型听起来像一个很自然的方案：主模型慢了、贵了、限流了，就切到另一个模型。可真正上线时，问题会变得没那么轻松。客服回复可以降级吗？合同条款解释可以降级吗？代码生成可以只返回简单版本吗？如果备用模型答错，用户是否能分辨这是降级结果？
模型降级的核心不是“有没有第二个模型”，而是每个业务场景能接受什么质量下限。
先把任务分成不同风险层
同样是大模型调用，风险差别很大。闲聊、标题润色、摘要生成，允许一定表达差异；企业知识问答、合规解释、财务口径，就不能只追求能返回。还有一些任务看起来是文本生成，实际会影响真实系统动作，比如生成 SQL、调用工具、修改配置，这类场景的降级边界更窄。
所以模型降级前，要先给任务分层：哪些任务可以直接切小模型，哪些任务只能返回“稍后再试”，哪些任务需要人工确认，哪些任务必须保持主模型或更高质量模型。没有这个分层，fallback 只是把错误从“失败”改成“看似成功”。
降级结果要让系统知道自己在降级
一个常见问题是：系统切到备用模型后，后续链路完全不知道。前端照常展示，日志只记一次成功，用户也看不出质量承诺变了。这样短期指标好看，长期很危险，因为坏结果会混进正常样本，排查时也不知道它来自哪条模型路径。
更稳的设计是把模型版本、降级原因、输入长度、输出长度、命中策略写进调用记录。必要时，返回结果也要带内部标记，告诉业务层这是降级结果。用户不一定要看到技术细节，但系统必须知道自己用了哪种承诺。
不是所有失败都应该 fallback
如果主模型超时，切备用模型可能有意义；如果输入本身缺少关键资料，换模型并不会让答案变可靠；如果权限校验失败，更不能通过另一个模型绕过去。fallback 只适合处理模型服务不可用、延迟过高、成本策略变化这类问题，不适合掩盖业务前置条件不满足。
这也是面试里容易拉开差距的地方。一个成熟回答会说：先判断失败类型，再决定是否降级。模型错误、资料不足、权限不足、参数校验失败，应当进入不同处理路径。
质量评估要覆盖降级链路
很多团队只评估主模型效果，备用模型只是“能跑”。这会让降级在真正发生时变成盲飞。备用模型至少要经过核心场景评测：常见问题、边界问题、拒答问题、格式要求、长上下文压力、敏感内容处理。
评测不一定追求备用模型和主模型完全一样。更现实的目标是定义可接受范围：能不能少答一点但不乱答；能不能给出保守结论；能不能在资料不足时拒答；能不能保持结构化输出可解析。
一段更像项目里的回答
如果我设计模型降级，不会只配一个备用模型地址。我会按业务风险给任务分级：低风险内容可以切小模型，中风险任务切换后降低回答范围，高风险任务宁可失败或进入人工确认。每次调用记录模型、策略、降级原因和评测标签。上线前用坏例集验证备用模型不会在关键边界上乱答。
这样讲，模型降级就不是“省钱技巧”，而是一个可观测、可解释、可回滚的质量策略。大模型应用真正难的地方，经常就在这些看起来不酷的边界上。
如果面试继续追问“怎么证明降级有效”，不要只回答成功率。成功率只能说明接口返回了，不能说明回答值得信任。更有价值的指标是关键问题正确率、拒答准确率、结构化解析失败率、人工接管率和用户追问率。备用模型可以答得更保守，但不能把不确定包装成确定。