模型降级契约备用模型不是随便切一下一、模型降级不能只看接口是否兼容企业后端接入大模型后通常会准备备用模型。主模型超时、限流或成本过高时切到备用模型。听起来简单实际很容易出问题。备用模型的上下文长度、工具调用能力、输出格式、成本、延迟和安全策略都可能不同。模型降级不是把modelName换掉。它是一套契约哪些场景允许降级降级后能力减少多少输出是否仍符合业务协议用户是否需要感知日志如何记录。二、降级路径要提前设计降级可以发生在路由、调用、生成和后处理多个阶段。flowchart TD A[模型请求] -- B{主模型可用} B --|是| C[调用主模型] B --|否| D[选择备用模型] D -- E[能力适配] E -- F[输出校验] F -- G[返回结果] C -- F备用模型如果不支持工具调用就不能接管需要自动执行工具的任务。能力不等价时要走功能降级而不是假装完全替代。三、契约要写清能力差异下面是一个简化配置结构。public record ModelFallbackRule( String primaryModel, String fallbackModel, boolean supportToolCall, int maxContextTokens, boolean userVisible ) {}降级规则要和业务场景绑定。摘要类任务可能可以切小模型合规审核或结构化输出任务就要谨慎。不同任务的可降级程度不一样。四、降级要可观测、可回放每次降级都要记录原因主模型超时、供应商 429、内容安全失败、成本保护触发还是主动灰度。只记录“用了备用模型”不够后续没法判断问题来源。还要监控降级后的质量。备用模型成功返回不代表业务成功。结构化解析失败率、人工修正率、用户重试率都要单独观察。降级的目标是维持可用不是隐藏质量下降。用户体验也要设计。某些场景可以无感降级某些场景需要提示“当前返回为简化结果”。过度透明会打扰用户完全不提示又可能造成误解。最后降级演练必须定期做。只有主模型真的不可用时才第一次切备用风险太高。演练能发现上下文超长、参数不兼容、输出格式漂移等隐藏问题。降级还要考虑缓存。主模型生成的缓存结果是否可以被备用模型复用如果缓存 key 只包含业务输入不包含模型和模板版本就可能把不同能力层级的结果混在一起。缓存命中看似提高性能实际可能让质量问题更难排查。对结构化输出场景降级后必须做 schema 校验。备用模型只要少一个字段、改一个枚举值后端解析就可能失败。降级链路里应该先校验再返回业务层校验不过就走明确失败而不是把脏结果继续传下去。最后要为降级设置预算。供应商异常时所有请求切到备用模型备用模型也可能很快触发限流。降级不是无限容量要结合队列、限流和优先级一起设计。降级策略还要支持按租户或业务线差异化。核心业务可以优先保留主模型或高质量备用模型低优先级任务可以切小模型甚至暂停。所有请求一视同仁在资源紧张时反而会伤害最关键的场景。对用户可见的内容还要记录降级标签。后续如果要分析满意度、投诉或人工修正率就能区分主模型结果和降级结果。没有标签质量分析会把两类输出混在一起。还有一个容易忽略的点是提示词适配。主模型能理解的复杂系统提示备用模型未必稳定遵守。降级时可以使用更短、更强约束的模板并减少可选输出空间。备用模型不是越像主模型越好而是要在能力范围内稳定完成最低业务目标。五、总结模型降级是一套能力契约不是简单替换模型名。备用模型要明确支持能力、适用场景、质量指标和用户感知策略。可用性要靠提前设计和演练而不是事故时临时切换。
