模型服务的降级链路怎么设计？

先这样答

模型服务的降级链路设计需要根据故障分类进行分层响应。触发场景通常包括限流与超时、模型不可用以及生成质量劣化。针对这三类问题，对应的策略分别是退避重试、切换备用厂商以及回滚旧版本。架构上要保证请求的幂等性，使其在不同节点间可安全重放。

具体设计上，首先建立多供应商配置的热切换机制，确保主模型不可用时流量快速路由到备用厂商。这里必须执行降级时的能力对齐检查。不同厂商模型在上下文长度、工具调用格式上往往不一致，切换前需对请求体进行适配。系统要主动截断超长历史对话或过滤不支持的工具调用，避免备用模型因格式不兼容而直接报错。同时，系统需配备降级事件告警与自动恢复探测机制，通过旁路定时向主模型发送心跳请求，确认其响应正常后再将流量切回。

降级链路中最危险的情况是发生连锁故障。当主模型因突发流量停止响应时，若将堆积的重试请求全部压给备用模型，很容易耗尽备用厂商的限流配额，导致主备双挂。因此降级设计必须包含全局限流与熔断机制，在切换时严格控制并发量，结合退避策略分散重试压力，必要时丢弃非核心请求以保全主干业务。

总结来说，模型降级不仅是配置几条备用路由，更核心的是处理好多模型之间的能力对齐，并用熔断机制守住系统的可用性底线。

面试官会怎么追问

• 「如果备用模型的上下文窗口比主模型小，切流时怎么处理？」 需在降级网关层做能力对齐检查与请求裁剪。优先保留系统提示词和最近几轮的对话历史，按备用模型的长度限制丢弃中间较早的上下文。知识库场景可退级为只传递最高权重的检索分块，保证核心请求被成功处理。
• 「主模型恢复后，流量怎么切回来才能避免抖动？」 依赖自动恢复探测机制判断主模型状态。后台确认主模型连续多次响应正常后，不能瞬间切回全量请求，需通过灰度放量分配流量。系统先切回少部分请求观察延迟和成功率，指标稳定后再逐步调大比例。
• 「怎么防止重试风暴把备用模型也打挂？」 限流超时触发降级时，必须引入退避重试机制增加请求的随机时间间隔。同时要在全局设置熔断器，评估备用厂商的并发承载上限。若降级流量超过该上限，直接丢弃低优先级业务的请求，确保核心业务可用。

回答的坑

• 认为降级仅仅是更改接口访问地址，忽略了模型间在工具调用和上下文长度上的硬性差异，正确做法是强调降级前必须执行能力对齐检查。
• 忽视降级过程中的容量规划，只讲重试机制而不提全局限流，正确做法是指出防连锁故障的重要性，用熔断机制保护备用模型。