Fallback与降级：LLM容错设计

可视化演示

动态演示Fallback与降级的核心机制，通过开始/执行/监控/完成四种模式展示关键概念与交互流程。

容错设计总览

老张的餐厅最怕什么？最怕所有客人点菜时，只有林大厨一个人在灶台前忙活。他一旦生病请假，整家店就得挂上“暂停营业”的牌子。现实里，LLM 应用如果只依赖一家模型 API，就犯了同样的“单点依赖”错误——网络抖动、服务宕机、限流封禁、内容审查拦截，任何一个故障都能让用户看到悲伤的报错页面。

容错（Fault Tolerance）就是系统在部分组件失败时，依然能继续服务的能力。它要回答三个问题：故障从哪来（故障类型）、能做到多稳（可用性目标）、靠什么兜住（多级容错机制）。常见故障类型包括网络错误、限流（HTTP 429）、服务端 5xx、超时，以及模型输出不合格（空回复、格式错误、被安全策略拦截）。

衡量容错效果，最核心的指标是服务可用性。它由“平均无故障时间”和“平均修复时间”两个量共同决定：

99% 可用性听起来不错，但一个月会有 7 个多小时不可用。多级容错设计的价值，就是让每一级故障都被下一级接住：主模型层失败，降级链层接管；降级链全挂，缓存兜底层顶上。就像老张有了二厨、帮厨、预制菜三层救场，林大厨就算歇一个月，顾客也感觉不到店门关过。

Fallback策略

老张救场的第一步，是“换人”的动作：电话里听到林大厨说“今天来不了”，立刻拨给李二厨，绝不干等。这个“当前厨师不行，立刻换下一个”的决策，就是 Fallback——模型调用失败后的即时切换机制。

Fallback 不是简单地写一个 try-except 换个 model 参数。它要解决四个问题：什么情况算失败（触发条件）、换谁（备选模型）、换了以后怎么知道行不行（结果校验）、在哪个环节兜底。典型触发条件有：连接超时、读取超时、429 限流、5xx 服务端错误、返回空内容或 JSON 解析失败。切换后，备用模型的输出同样要过一遍校验，否则可能返回一堆格式错误的内容。

Fallback 带来的收益可以用概率的视角看。假设每个模型单独调用有各自的成功率，那么多级 Fallback 后“最终能成功”的概率是：

所以林大厨成功率 90%、李二厨成功率 85% 时，两人接力后整体成功率 = 1 − 0.1×0.15 = 98.5%。Fallback 的本质，就是用“多一次尝试”换“更高的确定性”。

降级链设计

老张后厨墙上贴着一张救场流程图：林大厨 → 李二厨 → 王帮厨 → 冰箱预制菜。这不是临时抓瞎，而是事先排好的固定梯队。对应到架构里，这串“优先级从高到低、按顺序接替”的模型列表，就是降级链（Degradation Chain）。

设计降级链有四个要点。第一，模型分级排序：按“质量优先、兼顾成本”的原则，把最聪明的模型放最前面，把又慢又贵的排后面。第二，链路自动编排：链路必须配置驱动而非硬编码，改一条链不用重新发版。第三，逐级降级：每次只往下退一级，而不是一步跳到底，避免把廉价模型累垮。第四，动态恢复：主模型恢复后要能自动切回，通常借助熔断器的半开状态试探。

降级链不是免费的——每一级尝试都消耗时间。整体期望延迟，等于每一级的延迟乘上“请求能走到这一级的概率”再累加：

这就是为什么降级链不能无限加长：每多加一级，链尾那几级几乎不会被调用，却让公式里多了一个可能拖慢整体延迟的项。老张的梯队只排了三层加一个冰箱，刚刚好。

超时与重试

老张给每通救场电话定了规矩：响 10 声没人接就挂断，换下一个厨师。他不会让顾客饿着肚子等一个永远不接的电话，更不会疯狂重拨把电话线打爆。这个“等多久挂电话”的边界，就是超时（Timeout）；“挂了以后要不要再打、隔多久打”，就是重试（Retry）。

超时设计要分层：连接超时解决“网络都通不了”的问题，读取超时解决“服务端处理太久”的问题，再设一个总请求预算，比如“整体最多等 10 秒”，超过预算立即触发降级。重试则要配合指数退避：第一次失败等 0.1 秒，第二次等 0.2 秒，第三次 0.4 秒……每次都翻倍，并加上随机抖动，防止大量请求在同一瞬间重试形成“重试风暴”。

指数退避的等待时间通常写作：

当同一模型连续失败达到设定次数（比如 5 次），熔断器打开——接下来一段时间直接跳过它，不再白白等待和花钱。这就像老张发现林大厨这周状态不对，索性暂停派单给他，让二厨直接顶上，等确认他状态恢复（半开状态试探成功）再重新启用。

成本控制

林大厨一道菜收费 1000，李二厨 100，王帮厨 10。要是连倒杯白开水都劳烦林大厨，月底账单能把老张吓哭。模型世界也一样：GPT-4 级别的模型和开源本地模型，单次调用成本能差两个数量级。

成本控制的第一个关键是请求分流：简单任务（翻译一句话、提取关键词）交给便宜模型，复杂任务（写长文、深度推理）才动用贵模型。第二个关键是记住“失败的调用也要付钱”——每次调用 API 都按 token 计费，哪怕返回超时重试，钱已扣掉。所以 Fallback 要克制，不能无脑重试十次。第三个关键是设单请求成本预算：一次用户请求的总花费超过阈值后，直接进入兜底模式，不再继续烧钱尝试。

把成本模型写出来，就是最朴素的一句话：

老张的生意经：招牌菜请林大厨，家常菜找王帮厨，救场时后厨不超过三通电话。对应到系统里，就是“简单请求走便宜模型，复杂请求走贵模型，Fallback 不超过两层，超过预算直接兜底”。

体验保障

有一次，顾客点了林大厨的招牌红烧肉，端上来的却是王帮厨的简化版。老张没有假装无事发生，而是主动说：“不好意思，今天主厨请假，这道菜由帮厨制作，口味略减，送您一道甜品。”顾客有预期、有补偿，反而觉得这家店实在。

模型降级也一样——用户是能感知到回答变短、变浅、变模板化的。体验保障的核心原则是“降级要透明，反馈要渐进”。具体手段有：降级透明提示（“当前使用轻量模式回复”），让用户明白为什么答案简单；渐进式反馈（流式输出、进度提示），避免用户面对一片空白；缓存兜底（复用相似的历史答案），保证核心信息不丢失。

衡量体验有没有守住，一个直白的指标是降级率——有多大比例的请求没有走主模型：

老张盯两个数：菜有没有端上来（成功率），端上来的是不是原版（降级率）。两个数都健康，顾客才留得住。降级不是失败，是“在资源受限时优先保证用户有钱可付、饭可吃”的取舍。

监控与运维

老张在厨房挂了一块大白板，记录每桌菜是哪个厨师做的、用了多久、有没有翻车。每周他还搞一次“林大厨失踪演练”——故意让林大厨休息一天，看李二厨和王帮厨能不能扛住客流。这块白板和这次演练，就是降级链的监控与运维。

监控要盯四类核心指标：成功率（请求最终成功的比例）、延迟分位数（P50/P95/P99，看大多数用户感受）、Fallback 触发次数（哪个模型最常掉链子）、降级率与单请求成本（体验和钱包双重警报）。配合 Trace ID，一次请求从主模型一路降级到缓存的完整路径都能串起来追溯。故障演练则像消防演习：定期模拟主模型宕机、限流、网络分区，验证降级链真的能接住。

SLO（服务等级目标）和错误预算给监控划了红线。假设我们承诺 99.9% 的成功率，那么一个月的错误预算就是：

错误预算快用完时，即使主模型“看起来恢复了”，也要谨慎——优先保稳定性，而不是追求回到完美链路。白板上的数据让老张知道“预制菜救了多少次场”“哪个厨子最容易掉链子”，招人、备菜、排班就都有了依据。

AI 应用场景

Python 演示

import randomimport time  class ModelClient:    """模拟一个带成本与失败率的模型客户端"""     def __init__(self, name, fail_rate, cost):        self.name = name        self.fail_rate = fail_rate        self.cost = cost     def chat(self, prompt):        if random.random() < self.fail_rate:            raise RuntimeError("{} 调用失败".format(self.name))        return "[{}] 回答: {}".format(self.name, prompt)  def backoff_wait(attempt):    """指数退避加抖动, 防止重试风暴"""    return min(1.0, 0.05 * (2 ** attempt) + random.random() * 0.05)  def call_with_fallback(prompt, chain, retries=2):    """沿降级链依次尝试, 记录成本, 返回首个成功结果或兜底文案"""    total_cost = 0    for model in chain:        for attempt in range(retries):            total_cost += model.cost            try:                return model.chat(prompt), total_cost            except RuntimeError:                time.sleep(backoff_wait(attempt))        print(">>> {} 重试耗尽, 降级到下一个模型".format(model.name))    print(">>> 全部模型失败, 启用缓存兜底")    return "[兜底] 服务繁忙, 请稍后再试", total_cost  def main():    chain = [        ModelClient("gpt-4", fail_rate=0.6, cost=10),        ModelClient("gpt-3.5", fail_rate=0.4, cost=1),        ModelClient("local-7b", fail_rate=0.2, cost=0),    ]    for prompt in ["总结今日新闻", "生成产品文案", "翻译用户评论"]:        print("请求:", prompt)        answer, total_cost = call_with_fallback(prompt, chain)        print("返回:", answer)        print("本次成本: {} 元".format(total_cost))        print("---")  if __name__ == "__main__":    main()

1. def call_with_fallback(prompt, chain, retries=2):降级链的主入口，chain 是有序模型列表，retries 是每级重试次数。
2. for model in chain:按优先级遍历降级链，主模型先试，失败依次下探。
3. total_cost += model.cost无论成功还是失败，每次调用都计入成本，还原“失败的 token 也收费”。
4. raise RuntimeError("{} 调用失败".format(self.name))模拟模型调用异常，真实场景对应 API 超时、限流、5xx 等。
5. time.sleep(backoff_wait(attempt))重试前按指数退避等待，避免瞬间重试压垮服务。
6. return min(1.0, 0.05 * (2 ** attempt) + random.random() * 0.05)等待时间封顶 1 秒并加随机抖动，防止重试风暴。
7. print(">>> {} 重试耗尽, 降级到下一个模型".format(model.name))输出降级事件，真实系统会写日志并上报监控指标。
8. return "[兜底] 服务繁忙, 请稍后再试", total_cost全链失败后的最终兜底，保证请求永远有响应。

常见误区

面试题