这个坑值得记一笔。LiteLLM 1.50 配了三个 deployment 做负载均衡，其中一个上游已经 500 了两小时，router 仍然按轮询把三分之一的流量打过去，fallback 也没触发。
刚开始盯着「fallbacks 配置里没把该模型写进降级链」，折腾了半个多小时，排掉了。
原因不止一个，得分开看。没有开启健康检查，router 不知道上游已挂；num_retries 只在超时和连接错误时生效；cooldown 时间设得太短，刚标记可用又被选中。
先看各 deployment 的失败计数
curl -s http://127.0.0.1:4000/health -H "Authorization: Bearer $LITELLM_KEY" | jq再往下开启后台健康检查并设置冷却
python -c "print({'health_check': True, 'cooldown_time': 60, 'allowed_fails': 2})"接着把降级链补上同能力模型
python -c "print({'fallbacks': [{'gpt-4o': ['gpt-4o-mini']}]})"人为停掉一个上游压测流量分布
python router_test.py --kill 1 --rounds 30 --show-target排查用的命令都是临时敲的，没有写成脚本，事后才整理。
别只看报错消失，验证要多做一步。上游挂掉后一小时内该 deployment 的流量占比降到 0，请求全部由健康节点承接。
轮询本身不看健康状态，没有健康检查和冷却，负载均衡会把故障放大成三分之一失败率。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。