记录一下那天晚上的排查过程。LiteLLM 1.44 的 Router 配了 fallbacks，主模型 gpt-4o 返回 429 时没有切到 claude-3-5-sonnet，日志里直接抛 RateLimitError，压测时一半请求失败。
刚开始盯着「retry 次数耗尽后才考虑 fallback，等待时间过长」，折腾了半个多小时，排掉了。
这类报错背后常见的原因有几处，逐个排除就行。fallbacks 默认覆盖的异常类型有限，限流要单独配。还有一种是model_group 名字与 fallbacks 里写的不一致。
少数情况下是没有配 allowed_fails，冷却机制不生效。
动手时先把 Router 的实际配置打出来
python -c "from litellm import Router;r=Router(model_list=[{'model_name':'main','litellm_params':{'model':'gpt-4o'}}]);print(r.get_model_list())"给 429 单独配 context_window_fallbacks
python -c "print('fallbacks for RateLimitError')"然后设置 allowed_fails 与 cooldown_time
python -c "print({'allowed_fails':3,'cooldown_time':30})"剩下的就是用 429 注入压测验证切换
python load_test.py --status 429 --ratio 0.5 --n 200这次没动代码，只在配置和运行环境上找原因。
隔了一天再看，现象没变，说明不是偶发。
改完先别撤，确认这几项。注入 50% 的 429 后，请求全部由备用模型返回，成功率 100%，主模型冷却 30 秒后自动恢复。
fallback 不是万能兜底，它按异常类型匹配，限流、超时、上下文超限三种情况要分别配。这类问题最好一次改到位，反复小改反而容易把原因搅混。