降级策略：LLM服务的备胎计划

可视化演示

展示多级降级链与熔断机制、降级触发条件与备选模型选择、降级恢复与平滑回切，切换模式掌握AI服务可靠性核心原理。

降级触发条件

开车时什么时候需要换备胎？不一定等轮胎完全爆掉——胎压监测报警、方向盘抖动、轮胎发出异响，这些都是“提前信号”。真正的老司机不会拿生命赌一个“再开几公里”，而是果断靠边检查。LLM服务的降级触发也类似：不是等到主模型彻底宕机才降级，而是通过一系列监控指标发现苗头，提前切换。

这些监控指标就是LLM服务的“胎压报警器”。最常见的触发条件有四类：第一是超时检测，主模型迟迟不返回结果；第二是错误率阈值，失败请求占比超过设定值；第三是成本超限，调用的费用超出预算；第四是健康检查，主动探测主模型是否还“活着”。

它们的实现方式各不相同。超时检测要设定合理的等待时间（如3秒），超过即记为一次失败。错误率阈值则要在滑动时间窗口内统计失败请求数占总请求数的比例。成本超限通常由前端统计消耗的token数与单价乘积，达到预算额度就告警。健康检查则是周期性地发送一个小而全的探测请求，验证主模型连通性。

有了这些“报警器”，系统就能像老司机一样，在轮胎还没完全爆掉时就把备胎换上。触发条件不是靠运气，而是靠可量化的指标。把超时、错误率、成本、健康检查四项都配置好，降级策略才有一个可信的“发令枪”。

备选模型选择

备胎不是随随便便找个轮胎就行。全尺寸备胎能跑高速，非全尺寸备胎只能开80码，补胎液连城市快速路都跑不了。聪明的司机会根据出行路况选择带哪种备胎：常跑长途就带全尺寸，只在市区就带补胎液。LLM服务的备选模型也一样，要按任务场景搭好“备胎梯队”。

备胎梯队是从强到弱排列的一组模型：第一梯队可能是性能接近主模型的替代模型（如Claude Haiku），第二梯队是更便宜更快的小模型（如GPT-3.5-turbo），第三梯队是本地部署的小模型（如Qwen-7B），最后还有一个兜底：模板回答。根据任务的重要性和降级原因，选择不同的梯队。

选择备胎模型时，核心考虑三点：能力匹配（能否完成这一类的任务）、成本（单次调用费用）、延迟（响应时间）。不仅要看模型本身，还要看部署方式——本地模型保障数据安全，云端小模型保障弹性。模型路由组件则根据任务类型、当前降级原因和剩余成本预算，动态选择当前最合适的备胎。

有了成本公式，你就知道每个备胎的“油钱”是多少。备胎梯队不是拍脑袋排的，而是按能力、成本、延迟三个维度综合排序。这样当主模型故障或预算超标时，模型路由能立刻选出最经济、最合适的“应急胎”。

提示词适配

换上非全尺寸备胎后，驾驶方式立刻要变：师傅说“请勿超过80km/h”、别急转弯、别跑太远。备胎模型的“驾驶方式”就是提示词——同样的指令，强模型能听懂，弱模型可能就“懵”。所以降级时不光要换模型，还要“减速”改造提示词。

提示词适配有四个常规动作：指令简化、上下文裁剪、格式归一、任务降级。指令简化是把复杂的多步指令拆成几步简单的子任务；上下文裁剪是把长长的对话历史和参考文档缩短；格式归一是指定一个简单的输出格式（比如纯文本或短JSON）；任务降级则是对任务的完成标准进行降格——比如把“生成营销文案”降为“从模板中选择合适的文案”。

这四件事的目标只有一个：让备胎模型在其能力范围内把事情做对。指令简化可以显著降低模型的理解难度，上下文裁剪直接减少输入token数进而降低成本，格式归一避免模型生成难以解析的内容，任务降级则是在“能不能完成”和“完成得多好”之间做权衡。在实际工程中，这四招往往组合使用。

降级换胎之后，不要拿原来的驾驶习惯去开。提示词适配就像“减速慢行”的交通标志，它提醒系统：备胎模型能力有限，指令要更短、上下文要更精简、格式要更简单。适配做得好，降级后的回答质量才不会断崖式下跌。

效果兜底保障

备胎终究是应急用品，可行驶里程通常不超过100公里，速度也不能快。如果备胎也撑不住呢？出发前，有经验的老司机还会带上工具包、充气泵、救援电话，甚至有队友同行。LLM降级也一样，要预先想好“最坏情况下的最坏情况”，准备好效果兜底。

效果兜底是降级策略的最后一道防线。第一层是缓存兜底：把高频问题的优质回答缓存下来，降级时直接命中缓存；第二层是模板应答：对于无法回答的问题，输出固定的、友好的话术；第三层是人工转接：把复杂问题无缝转交给人工客服；第四层是流式降级：如果备选模型能力足够，就逐步降低服务能力而不是彻底停摆。

这些兜底方案让服务在极端情况下依然“可用”。可用性的定义就是服务正常响应的时间占总时间的比例。降级的目标不是让效果和原来一样好，而是让可用性不归零：用户得不到完美答案时，至少能得到一个及时的、有温度的响应，或者被引导到人工渠道解决。

备胎撑不住的时候，工具包和救援电话就是你的第二条命。缓存、模板、人工、流式降级，这四样东西会在最极端的情况下兜住服务的底线。记住：降级的最终目标不是“效果不打折”，而是“服务不断线”。

降级日志记录

还记得上次爆胎是什么时候？换的是哪个备胎？胎压后面恢复了吗？如果这些都没记录，到了维修站，维修师傅只能从头排查。行车记录仪和维修日志，能在关键时刻省下大量时间。LLM服务的降级也一样，每一次降级都要留下清晰的“黑匣子”日志。

降级日志要回答四个问题：什么请求（ID）、用的什么模型、是否降级、耗时和成本多少。为此，日志要以结构化格式（如JSON）记录，字段包括request_id、model、degraded、latency、cost、timestamp等。其中degraded布尔字段标记本次请求是否走了降级链路，是后续统计的关键。

单条日志能看一次请求，还要把日志串起来才能看清全貌。链路追踪把一次用户请求经过的所有环节（网关、模型路由、缓存、备胎模型）串成一条流水线，哪一环拖慢了一目了然。性能分析则用日志数据统计降级比例、平均延迟变化、成本节省情况，为优化降级策略提供依据。

日志就是LLM服务的“行车记录仪”。有了结构化日志、降级标记和链路追踪，运维人员才能在故障发生后快速回答“发生了什么、为什么发生、下次怎么预防”。没有日志的降级，就是一场看不见过程的救援。

告警通知机制

爆胎后换好备胎，难道就默默开走？不，第一件事是打开双闪、放好警示牌，打电话告诉家人“我这边爆胎了，会晚点到”，同时联系维修站准备新轮胎。LLM服务降级后也不能“默默进行”——必须通知到该知道的人。

告警通知机制要解决三个问题：通知谁、怎么通知、什么时候升级。通知谁由分级决定：P1表示主模型完全不可用，需要值班人员立刻介入；P2表示部分请求降级，影响面较大；P3表示少量请求超时降级，可观察处理。怎么通知由多渠道完成：紧急走电话或短信，重要走钉钉/企业微信，一般走邮件汇总。

告警的触发时机也很讲究，不能等降级持续半小时才通知。通常会在降级发生时实时告警，并在降级持续超过设定时间（如15分钟）时升级告警级别。同时，告警系统要支持“自动复位”：主模型恢复健康后，系统自动把流量切回主模型，并通知相关人员“故障已恢复”，让巡检闭环。

换好备胎之后的那通电话，决定了家人是干等还是提前准备。告警通知机制就是LLM服务的“那通电话”：分级、多渠道、值班响应、自动复位，一套完整的通知闭环，确保故障有人知道、有人处理、有人确认恢复。降级不是终点，而是运维流程的一个起点。

AI 应用场景

Python 演示

import jsonimport randomimport time  class LLMFallbackClient:    """LLM 降级客户端:主模型故障时自动切换到备选模型"""     def __init__(self, primary="gpt-4", fallbacks=None):        self.primary = primary        self.fallbacks = fallbacks or ["gpt-3.5-turbo", "local-mini"]        self.current = primary        self.fail_count = 0        self.switch_count = 0        self.threshold = 3        self.logs = []     def request(self, prompt):        try:            result = self._invoke(self.current, prompt)            self.fail_count = 0            return result        except Exception:            self.fail_count += 1            if self.fail_count >= self.threshold:                self._fallback()                self._record(prompt, degraded=True)            raise     def _invoke(self, model, prompt):        if random.random() < 0.3:            raise TimeoutError("simulated timeout")        return "[{}] {}".format(model, prompt[:12])     def _fallback(self):        if self.current in self.fallbacks:            idx = self.fallbacks.index(self.current)            if idx < len(self.fallbacks) - 1:                self.current = self.fallbacks[idx + 1]        elif self.current == self.primary:            self.current = self.fallbacks[0]        self.switch_count += 1        self.fail_count = 0     def _record(self, prompt, degraded):        self.logs.append({            "time": time.time(),            "prompt": prompt,            "model": self.current,            "degraded": degraded        })     def status(self):        return {            "current": self.current,            "primary": self.primary,            "switch_count": self.switch_count,            "threshold": self.threshold        }  if __name__ == "__main__":    client = LLMFallbackClient()    for i in range(20):        try:            resp = client.request("问题{}".format(i))            print("OK:", resp)        except Exception:            print("FAIL: 当前模型 =", client.current)    print("状态:", json.dumps(client.status(), ensure_ascii=False))

1. self.current = primary初始时使用主模型发出请求，一切正常时无需降级。
2. self.threshold = 3连续失败三次就触发降级，相当于是“三次确认”避免误判。
3. result = self._invoke(self.current, prompt)真正调用模型的地方，放在try块里以便捕获异常。
4. self.fail_count += 1每次失败就让计数器加一，这是错误率阈值的简化版实现。
5. if self.fail_count >= self.threshold:连续失败次数达到阈值，触发降级逻辑。
6. self._fallback()把当前模型切换到备胎梯队中的下一个模型。
7. self.current = self.fallbacks[idx + 1]在当前备胎列表中向后移动一格，用更强的备胎优先。
8. self.switch_count += 1记录降级切换的次数，用于后续性能分析。
9. self._record(prompt, degraded=True)写入结构化日志，标记这次请求走了降级链路。
10. raise重新抛出异常，让上层调用方知道本次请求确实失败了。

常见误区

面试题