LLM 回退链：生产模式（2026）

在生产环境中，模型提供商会出问题——速率限制、超时、区域故障、偶尔的500错误。回退链能在主模型失败时自动将请求重试到备用模型或提供商，从而保持应用可用。这是LLM应用最重要的可靠性模式。

模式

定义一个有序的模型列表。尝试第一个；如果失败（错误或超时），则依次尝试下一个。结合每次尝试的超时和有限重试，防止慢速提供商挂起请求。

python
pip install litellm
from litellm import completion
resp = completion(
    model="gpt-4o",
    messages=[{"role": "user", "content": "总结这个工单。"}],
    fallbacks=["claude-3-5-sonnet-latest", "gpt-4o-mini"],
    timeout=20,
    num_retries=2,
)
print(resp.choices[0].message.content)

LiteLLM 通过一个兼容 OpenAI 的调用，免费提供与提供商无关的回退——比较网关请参考 LiteLLM vs Portkey。

设计要点

按能力 *和* 成本排序。 常见的链是“主要前沿模型 → 其他厂商的同类模型 → 廉价模型”，这样能优雅降级而非直接失败。

每次尝试设置超时。 没有超时，一个卡住的提供商会阻塞整个链。每次尝试时间要短。

区分错误类型。 对 429/5xx/超时进行重试；不要重试 400（错误请求）——那会每次都失败。

跨提供商，而非仅跨模型。 同一提供商内的回退在提供商整体故障时无济于事；要跨越不同厂商。参见 GPT-4o vs Claude 了解如何选择可比较的配对。

注意提示词不兼容。 针对一个模型调优的提示词在回退模型上可能表现不同；保持提示词可移植。

超越回退：负载均衡

当你有多个密钥/区域时，还要在健康端点之间进行负载均衡，以分散速率限制并降低延迟——这是回退的互补模式。结合重试、熔断和可观测性，构建健壮的堆栈。

常见问题

应该重试哪些错误？ 瞬时错误：429、5xx、超时。永远不要重试 400 类错误。 回退会不会隐藏问题？ 记录每次回退事件——回退率上升是早期预警，不应默默忽略。 不同模型使用相同提示词？ 保持提示词可移植；测试回退模型，确保故障切换时质量不会骤降。 用库还是自己实现？ LiteLLM/Portkey 开箱即用；自己实现也可以，但会重复相同的逻辑。

总结

回退链是廉价的保险：一个跨提供商的模型有序列表、每次尝试的超时、仅对瞬时错误重试、以及每次故障切换的日志记录。再加上健康端点间的负载均衡，你的LLM应用就能在不可避免的故障中存活。

---

*最后更新：2026年6月。请对照 LiteLLM 文档验证 API。*