LiteLLM失败重试策略，指数退避
生产环境调用大模型接口时，上游经常因为限流（429）、服务端异常（5xx）或响应超时导致请求失败。
LiteLLM 作为统一网关，如果不配置失败重试策略，一次抖动就会让业务直接报错。
本文以 config.yaml 为例，演示怎么设置 LiteLLM 的重试次数、指数退避和超时参数，并给出验证方法，照着做就能让网关在故障时自动恢复。
先搞懂这几个参数再动手
LiteLLM 的重试主要靠 Router 层控制，你需要先认识三个核心参数：
num_retries：请求失败后最多重试几次。生产环境建议设 2 到 3，太低不够稳，太高会拖垮下游。request_timeout：单次请求最长等待时间。如果模型正常需要 1 分钟才能出结果，这个值就不能小于 60 秒，否则会误判超时。cooldown_time：某个上游连续失败后进入冷却状态的时间。冷却期内新请求会转发到其他可用模型，而不是继续打向故障节点。
指数退避在 LiteLLM 内部默认启用，重试间隔会按 1s、2s、4s 逐步拉长，避免集中重试压垮上游。
你不需要自己实现退避算法，但可以通过调整重试次数来间接控制总等待时长。
生产可用的 config.yaml 配置示例
打开 LiteLLM 启动时使用的 config.yaml，在 router_settings 中加入重试相关配置。
下面是一个适合线上环境的模板：
model_list:
- model_name: gpt-4o
litellm_params:
model: openai/gpt-4o
api_key: sk-xxxx
api_base: https://api.openai.com
router_settings:
num_retries: 3
request_timeout: 600
cooldown_time: 30
allowed_fails: 2保存后重启 LiteLLM，让它读取新配置：
litellm --config config.yaml --port 4000如果你不想改配置文件，也可以临时用环境变量覆盖：
export LITELLM_NUM_RETRIES=3
export LITELLM_REQUEST_TIMEOUT=600注意：不同 LiteLLM 版本的参数名可能略有差异，建议以你安装版本的官方文档为准。
上面的配置在实际项目里已经能稳定工作。
如何验证重试策略真的生效
启动服务后，用 curl 模拟一次会失败的请求。
先故意把上游地址改成一个不存在的端口，观察 LiteLLM 是否自动重试：
curl http://localhost:4000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-4o",
"messages": [{"role": "user", "content": "你好"}]
}'在 LiteLLM 的控制台日志里，你会看到类似 Retrying request... attempt 2 的记录。
记录时间戳，对比两次重试的间隔，如果间隔依次变大，说明指数退避生效。
也可以使用下面命令直接查看日志：
litellm --logs如果希望验证超时重试，可以把 request_timeout 临时改成 1 秒，再请求一个正常需要 10 秒的模型。
看到请求在 1 秒后被判定超时并进入重试流程，就说明超时参数起作用了。
测试完记得把值改回来。
避坑指南与高频疑问
重试参数虽小，但配置不当反而会引发新问题。
这里整理了几个最容易踩的坑：
- 重试次数别设太高。 3 次足够应对大多数瞬时故障。超过 5 次会让用户在接口恢复前等很久，还会造成重复扣费。
- 超时时间要覆盖模型最大响应时长。 大模型流式输出可能持续几分钟，超时设置太短会导致明明在正常生成却被拦腰截断。
- 不要只重试不冷却。 如果上游已经 5xx 持续 1 分钟，继续重试只会加重故障。配合
cooldown_time让流量自动切换可用节点更稳妥。 - 429 限流优先看 Retry-After 响应头。 LiteLLM 对部分上游会解析该响应头并自动等待，建议不要把
num_retries设得比上游限流窗口还大。
有读者常问：重试会不会导致同一笔请求重复扣费？
会。
如果上游已经处理成功但响应超时，客户端重试可能产生两次费用。
所以 request_timeout 要根据模型实际耗时合理设置，不要为了追求快而盲目调小。
还有读者问：是不是所有错误都值得重试？
不是。
参数错误、鉴权失败这类 4xx 错误重试多少次都一样，建议只在网络抖动、5xx、429 等场景让 LiteLLM 自动重试。
上线前的最后检查
配置改完后，按下面清单确认一遍再投入使用：
num_retries是否在 2 到 3 之间。request_timeout大于最慢模型的平均响应时间。cooldown_time已设置，避免故障节点被反复请求。- 用异常流量测试过重试日志，确认退避间隔递增。
如果你正在处理 LiteLLM 失败重试策略、指数退避或超时重试的生产参数调整，建议先按本文的配置跑通流程，再根据自己模型的实际耗时微调。
遇到日志里看不出重试次数时，优先检查 LiteLLM 版本是否支持当前参数名，然后在控制台观察响应时间分布，重试策略是否生效一眼就能看出来。
