[Bug]: Request Failed Error Code: 500 Message: litellm.APIConnectionError: APIConnectionError: Hosted_vllmException –

问题场景

用户通过 LiteLLM Proxy 调用 hosted_vllm 类型的模型（glm53-fp8），api_base 指向 OpenAI 兼容的 vLLM 服务 http://<ip>:<port>/v1，并启用了流式响应。在高负载或流式传输过程中，请求以 HTTP 500 失败，但客户端收到的错误被包装为 litellm.APIConnectionError: APIConnectionError: Hosted_vllmException -，错误信息中缺少真实的上游状态码与原始消息，导致排查困难。

从 traceback 可见调用链经过 proxy_server.py 的流式生成器、responses_id_security.py 钩子、router.py 的 stream_with_fallbacks，最终在 streaming_handler.py 的 _handle_stream_fallback_error 中进入 exception_mapping_utils.py 的 exception_type → _map_openai_exception，抛出 APIConnectionError。

报错原文

[Bug]: Request Failed Error Code: 500 Message: litellm.APIConnectionError: APIConnectionError: Hosted_vllmException -

"error_code": "500"
"error_class": "APIConnectionError"
"llm_provider": "hosted_vllm"
"error_message": "litellm.APIConnectionError: APIConnectionError: Hosted_vllmException - "

File ".../litellm/litellm_core_utils/streaming_handler.py", line 2271, in _handle_stream_fallback_error
    mapped_exception = exception_type(
File ".../litellm/litellm_core_utils/exception_mapping_utils.py", line 513, in _map_openai_exception
    raise APIConnectionError(

原因分析

根据 Issue 评论中的分析，当流式过程中发生 httpx 连接错误或超时（尤其在高负载下），_handle_stream_fallback_error 会把原始异常传给 exception_type()。由于 hosted_vllm 属于 OpenAI 兼容提供商，异常会进入 _map_openai_exception()，但映射在该函数内失败，原因可能有两点：

• 状态码位置不匹配：映射逻辑检查的是 hasattr(original_exception, "status_code")，而部分 httpx 异常（例如 HTTPStatusError）的状态码位于 original_exception.response.status_code，直接属性上并不存在。
• 类型比较过严：即使取到状态码，代码使用严格的整数相等比较（例如 == 500）；若状态码被提取为字符串 "500"，比较结果为 False。

由于状态码未能匹配，映射跳过 InternalServerError 等具体 HTTP 错误分支，落到最后的 else 分支，统一抛出 APIConnectionError，并拼接上动态的 exception_provider（即 Hosted_vllmException）。

需要说明：以上为 Issue 评论者基于 traceback 提出的“可能原因”，尚未经官方确认与合并验证。

环境排查

• 确认 LiteLLM 实际安装版本，并对照 exception_mapping_utils.py / streaming_handler.py 中相关行号是否与 traceback 一致。
• 确认 Python 版本（traceback 显示为 3.13）与虚拟环境路径是否对应。
• 确认 hosted_vllm 上游服务（vLLM）是否健康：直接调用 http://<ip>:<port>/v1 的接口是否偶发 500 或连接被重置。
• 确认模型配置中的超时设置是否合理：Issue 配置中同时存在 timeout: "1800" 与 stream_timeout: "2"，需确认流式超时是否为触发点。
• 确认代理层（反向代理、负载均衡）是否在上游响应未完成时中断长连接，导致 httpx 侧抛出连接类异常。
• 确认并发与容量：Issue 配置中 max_parallel_requests: 30、tpm 与 rpm 较大，若后端实际吞吐不足，可能在高负载下触发 500。

解决步骤

1. 先区分问题归属：用相同的 api_base 直接请求上游 vLLM 的 OpenAI 兼容接口（可优先尝试非流式与流式各一次），确认是否由上游自身返回 500 或中途断开连接。
2. 若上游确实在高负载下报错，优先处理后端侧：降低 LiteLLM 侧并发（如调低 max_parallel_requests）、确认 vLLM 实例资源与健康检查状态。
3. 检查 LiteLLM 模型中 stream_timeout 与 timeout 的取值，判断流式超时是否过短导致误判为连接异常（该判断为推测，需结合日志验证）。
4. 若排查后确认上游返回的是 500，但 LiteLLM 报成 APIConnectionError，可优先尝试 Issue 评论中提出的代码修复：在 litellm/litellm_core_utils/exception_mapping_utils.py 的 _map_openai_exception() 开头，先安全提取 original_exception.status_code 或 original_exception.response.status_code，转为整数后统一用于后续 if/elif 分支比较（评论给出的是约 422 行附近的修改示例，实际位置需以本地版本为准）。
5. 修改后需在同一环境下复现流式高负载场景，确认 500 被映射为 InternalServerError 而非 APIConnectionError。

验证方法

在压力或同类并发条件下重放原本失败的流式请求：若上游确为 500，修复后错误类型应体现为 InternalServerError，并保留上游状态码与消息，而不是笼统的 APIConnectionError: Hosted_vllmException -；同时观察上游 vLLM 日志是否仍存在 500 或流式中断记录，以区分“错误被正确映射”和“问题真正消失”。若未做代码修改，则验证重点是确认上游是否仍有 500/连接异常发生。

参考来源

BerriAI/litellm #43518

AI 工具推荐

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

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

了解 GamsGo AI

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