LLM Fallback 降级策略：给你的应用上保险

做过 LLM 应用上生产的都知道一个真相：API 一定会出问题。 超时、429 限流、偶发 500、甚至整个服务商宕机。如果你的应用死死绑在一个模型上，它一打喷嚏，你就全挂。

Fallback（降级）策略就是给应用上的保险。

会遇到的故障

超时：请求发出去，迟迟不回。

限流（429）：调太快，被服务商挡了。

服务错误（5xx）：服务商那边抽风。

整体宕机：OpenAI / Anthropic 偶尔会有大面积故障。

内容拒答：模型以安全为由拒绝回答。

每一种，你都得想好「然后呢」。

降级策略分层

从轻到重，一层层兜：

第一层：重试（Retry） 偶发错误，等一下重试往往就好了。用指数退避，别傻等也别猛冲：

python
import time
def call_with_retry(fn, max_retries=3):
    for i in range(max_retries):
        try:
            return fn()
        except (TimeoutError, RateLimitError) as e:
            if i == max_retries - 1: raise
            time.sleep(2 ** i)  # 1s, 2s, 4s

第二层：换模型（Model Fallback） 主模型不行，自动切备用模型。常见组合：主用 GPT-4o，挂了切 Claude，再不行切个便宜快的小模型保底。

python
MODELS = ["gpt-4o", "claude-3-5-sonnet", "gpt-4o-mini"]
def chat_with_fallback(messages):
    for model in MODELS:
        try:
            return call_model(model, messages)
        except Exception:
            continue  # 换下一个
    return DEFAULT_REPLY  # 全挂了走兜底

这也是为什么生产应用最好用一个统一的网关层（如 LiteLLM）来抽象多家模型——切换只改配置，不动业务代码。

第三层：缓存（Cache） 常见问题的答案缓存起来。模型全挂时，至少高频问题还能用缓存答。语义缓存还能命中「意思相近」的问题。

第四层：兜底回复（Graceful Degradation） 全部都不行了，也不能给用户甩一个 500。返回一个体面的兜底：「AI 助手暂时繁忙，您可以稍后再试，或联系人工客服。」

设计要点

超时一定要设，而且要短。 别用默认的几十秒超时——用户等 30 秒早跑了。根据场景设 5-15 秒，超了就走 fallback。

fallback 链要考虑质量落差。 从 GPT-4o 降到小模型，回答质量会掉。关键场景宁可返回「稍后再试」，也别用一个明显变差的答案糊弄，反而砸口碑。

别把 fallback 写死在业务逻辑里。 抽一个统一的调用层，把重试、切换、缓存、兜底都收口在一处。业务代码只管「我要个回答」，怎么容错是底层的事。

监控 fallback 触发率。 如果备用模型经常被触发，说明主模型有问题，这是个信号，要去查。可以接 LLM 可观测性工具 盯着。

一个完整的降级链

用户请求
  → 查缓存（命中直接返回）
  → 主模型 + 重试
  → 备用模型 + 重试
  → 兜底回复

小结

LLM 应用的健壮性，不看它顺利时多强，看它出问题时多稳。上生产前，先问自己一句：模型现在挂了，我的用户会看到什么？ 答不上来，就该补 fallback 了。