降级时的小模型是怎么顶上的？机制细节全梳理

大模型服务扛不住洪峰或突发故障时，让小模型先顶上一阵，这叫降级。它像发电站的备用机组，平时安静，启动时必须可靠。小模型怎么被选中、怎么接流量、怎么让位，有一整套工序。

什么信号触发降级

触发信号常见三类：队列持续超长、错误率越过红线、响应延迟全面变慢。进来的是监控指标，发生的是阈值与持续时长判定，出去的是降级开关的合上动作。

判定要防误伤：一次网络抖动不该触发全量降级，通常要求指标连续多个周期越线，或者人工按钮兜底。触发线还要分层看：轻度拥塞只降部分功能，重度才换模型，一步到位式的降级最容易用力过猛。降级是保命的非常手段，越谨慎越好。指标取哪个窗口也有讲究：取太短容易被抖动骗到，取太长反应迟钝，降级判定通常用分钟级窗口，再加连续越线次数做双确认。

降级对象也不止小模型一种：缓存过的旧答案、固定话术、功能裁剪都在工具箱里，按影响面从小到大排着用，换模型是最后一档，能不用就不用。

小模型顶上的三道工序

第一道是预热：小模型常驻但平时不接流量，触发后先热身，把参数加载到位、跑几条测试请求。第二道是切流：负载均衡把新请求改路由到小模型实例，比例从一成到全量分步走，防止小模型也被打懵。第三道是标记：这批回答由降级通道产出，日志里单独记账，方便事后回溯。

小模型顶上后，回答质量会有落差，产品端往往配合调整：缩短默认回答长度、关闭复杂功能、在界面上提示当前为极速模式。你在豆包、文心一言遇到高峰期的极速回答，体验有变化但功能不断，背后就是这套切换。切流期间的一致性要处理好：同一会话前一句大模型答的、后一句小模型答的，语气和能力差异要靠提示词调校拉平，至少别让用户觉得换了个人。标记还能反哺调度：降级产出的回答不参与难例收集，避免低质量样本混进后续的训练数据。小模型的选型要提前定：能力档位、窗口大小、资源占用都测过，预案里写清楚用哪个，临时挑模型最容易翻车。

降级前后两档模型的差别，落在质量、资源、窗口三处。

什么时候切回大模型

恢复要更稳：指标回到安全水位并保持一段时间，先放一成流量回大模型试探，观察无异常再逐级放开，全程小模型待命，随时可以再切。进来的是恢复信号，发生的是灰度回切，出去的是回到常态的服务。回切窗口避开流量高峰更稳，低谷期是常见选择。

切回太急是常见事故源：大模型刚恢复就接全量，余震一来又得降级，来回横跳最伤体验。回切节奏宁可保守，慢一点总比反复横跳强。降级期间的容量账要重算：小模型更省资源，同样的机器反而能接更多请求，这段冗余是恢复期的缓冲垫，别急着回收。

• 速查：三类信号触发降级；预热、切流、标记三道工序；小模型也限流；回切要灰度要缓慢；日志单独记账。

降级并非孤立的开关，超时后的部分结果怎么处理？半截答案收拾切换期间的残局，异步调用是怎么通知完成的？回调与轮询把扛不住的任务挪到后台，上下文超限的报错是怎么触发的？提示小模型窗口更小要注意，推理结果的日志怎么记？排查的第一手资料负责把全程记下来。

换个问法再问降级切换三句

• 降级期间回答会变差多少？：看小模型能力落差，简单问答几乎无感，复杂推理明显下降。
• 用户能察觉被降级了吗？：产品通常会提示极速模式，也有不提示只靠日志记录的。
• 小模型也要限流吗？：要，降级只是换挡，容量依然有限，配额跟着一起切，超了照样拒绝。