[Bug]: No fallbacks configured + 429 mid-stream causes 100% CPU hang (process unresponsive)

快速结论：该报错发生在 LiteLLM 代理（proxy）处理流式请求时，若收到 429 错误（资源耗尽）且未配置 fallback 模型组，进程会陷入无限异步生成器循环，导致 CPU 占用 100% 且无法响应新请求。优先排查：确认 router_settings 中是否配置了 fallbacks，或检查 streaming_handler.py 中 != 429 豁免逻辑是否导致异常无法正确抛出。

问题场景

用户运行 LiteLLM 代理（版本 1.83.9），后端使用 Vertex AI 模型（vertex_ai/gemini-3.1-pro-preview，vertex_location: global），且 router_settings 中未配置 fallbacks。当发起的流式请求在生成中途触发 Vertex AI 的 QPM（每分钟请求数）限制（返回 429 状态码）时，代理进程无响应。

报错原文

# 日志中出现的核心错误
litellm.exceptions.MidStreamFallbackError ... Received Model Group=gemini-3.1-pro
Available Model Group Fallbacks=None Original exception: RateLimitError (or APIConnectionError in some cases)
proxy_server.async_data_generator(): Exception occured ... MidStreamFallbackError ...

# 无 fallback 配置时，异常在流处理链中循环，CPU 100%
Fallback also failed: MidStreamFallbackError(...)

原因分析

可能原因：在 streaming_handler.py 中，PR #22375 引入了 != 429 豁免逻辑，使得 429 错误不会被直接抛出为 RateLimitError，而是被包装为 MidStreamFallbackError。在 router.py 的 stream_with_fallbacks 方法中，当 fallbacks=None 时，此异常被重新抛出，但该异常在后续的异步生成器链（_wrap_streaming_iterator_with_enrichment / async_post_call_streaming_iterator_hook）中无法被正确关闭或耗尽，导致事件循环无限旋转。此外，评论中补充了此问题不仅限于 429，对于上游连接错误（如 APIConnectionError）也可能出现类似行为。

环境排查

LiteLLM 版本：1.83.9 及可能受影响的版本（PR #22375 引入后）
后端模型：Vertex AI（vertex_ai/gemini-3.1-pro-preview）或其他可能返回 429 的模型
代理配置：router_settings 中 num_retries: 0，且 fallbacks 未配置或为 None
网络环境：可能遇到 APIConnectionError（如连接重置、OAuth Token 刷新失败等）

解决步骤

优先尝试：临时绕过 — 根据 Issue 中提供的本地工作方案，移除 streaming_handler.py 中 != 429 的豁免条件（约第 2303 行），使 429 被直接抛出为 RateLimitError：
```
# 修改前
if (
    mapped_status_code is not None
    and 400 <= mapped_status_code < 500
    and mapped_status_code != 429
):
    raise mapped_exception
# 修改后
if (
    mapped_status_code is not None
    and 400 <= mapped_status_code < 500
):
    raise mapped_exception
```
注意：此修改会禁用已配置 fallback 的用户对 429 的中流 fallback 功能。
根本修复（等待上游合并） — 官方建议的改进方向：在 router.py 中，当 fallbacks=None 或 fallback 也返回 429 时，直接抛出原始异常而非重新抛出 MidStreamFallbackError。
生产环境缓解措施 — 在 router_settings 中显式配置 fallback 模型组（即使只是一个简单的备用模型），以避免进入无 fallback 的异常循环。
检查其他错误类型 — 如果遇到 APIConnectionError（如连接重置、SSL EOF），同样可能触发此问题。评论中建议检查 GitHub Issue #26015 中关于非 429 错误的更新，并考虑在 streaming_handler.py 或 router.py 中为无 fallback 模式添加快速失败逻辑。

验证方法

修改代码或配置后，重新发送一个预计会触发 429 的流式请求（例如通过连续快速发送多个请求以达到 QPM 限制）。观察 LiteLLM 代理进程的 CPU 占用是否恢复正常，且客户端能否收到明确的错误响应（如 RateLimitError）而非进程无响应。

参考来源

BerriAI/litellm #26015

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

[Bug]: No fallbacks configured + 429 mid-stream causes 100% CPU hang (process unresponsive)