[Bug]: aiohttp per-host pool exhaustion is silent, requests just time out with no diagnostic

快速结论：该问题通常发生在 LiteLLM Proxy 通过 aiohttp 访问同一上游主机（例如 Ollama 或其他 OpenAI 兼容推理服务）时，默认每主机连接池被占满；此时请求只会一直等待直到请求超时，并以普通超时错误结束，日志中不会提示连接池已耗尽。优先排查上游真实并发、代理进程到上游的 ESTAB 连接数是否长期顶在 AIOHTTP_CONNECTOR_LIMIT_PER_HOST 默认值（500），以及是否存在客户端提前放弃并重试导致连接占用堆积。

适用环境：Issue 已确认的环境为 LiteLLM Proxy v1.103.0（Docker 部署），并阅读确认 v1.105.1 的传输层行为相同；上游为通过 ollama/some-27b 接入的自托管 OpenAI 兼容推理服务器（27B 模型，单请求约 150 秒）。作者自述未覆盖 general_settings，且 AIOHTTP_CONNECTOR_LIMIT_PER_HOST 保持默认值。其他操作系统与 Python 版本在 Issue 中没有明确证据。

最快修复方案：暂无确认的一步修复方案。Issue 讨论中确认修复已随 PR #49499 合并，但评论摘要没有给出具体版本号、配置项或操作步骤；可优先尝试升级到包含该 PR 的 LiteLLM 版本，并关注该 PR 引入的连接池饱和诊断信息。

注意事项：Issue 明确说明并不确认存在特定的连接生命周期缺陷，500 个连接槽位也可能确实在等待极慢的上游。仅调大连接池或重启代理属于两种方向相反的处置，在无法区分“连接池耗尽”和“上游过慢”时不要贸然操作；升级前建议先确认目标版本确实包含 PR #49499。

问题场景

用户在 LiteLLM Proxy 中配置了一个指向自托管 Ollama 推理服务的模型组 local-27b（api_base: http://inference-host:11434，timeout: 180，stream_timeout: 300，num_retries: 0），通过代理调用该模型。上游单次请求约需 150 秒。客户端在自身较短的截止时间（127 秒）放弃请求并最多重试 4 次，导致连接获取速度超过上游释放速度。当代理到该上游主机的连接数达到 AIOHTTP_CONNECTOR_LIMIT_PER_HOST 默认值 500 后，所有发往该模型组的请求都会挂满请求超时并返回 http 408。同一代理发往其他主机的 embeddings 请求不受影响，说明问题局限在单个上游主机。

报错原文

Response after 180.4s: http 408
litellm.Timeout: ... Timeout passed=180.0, time taken=180.373 seconds
Deployment Info: request_timeout: None / timeout: 180.0 ... Available Model Group Fallbacks=None

Issue 标题中的核心描述：

[Bug]: aiohttp per-host pool exhaustion is silent, requests just time out with no diagnostic

原因分析

最可能的原因是：在 LiteLLM Proxy 进程内，aiohttp 针对单一上游主机的连接池已被占满。Issue 观察到代理到上游的 ESTAB 套接字数量在 20 分钟以上的采样中始终固定在 500，其中 418 个（84%）在超过 15 分钟内未收到任何字节；而真实上游并发仅约 40 个在途请求，说明大量连接没有对应的有效请求在等待。与此同时，错误路径只表现为普通请求超时，日志、异常和指标中都没有任何信息说明瓶颈是连接池而非上游。Issue 作者也谨慎指出，不能排除这 500 个槽位确实在等待极慢上游的可能性，因此“连接池耗尽”与“上游响应过慢”在实际表现上难以区分。

环境排查

确认 LiteLLM 版本是否为 v1.103.0 或 v1.105.1 等受影响的传输层版本，是否已包含 PR #49499 的修复。
确认部署方式为 Docker 代理，并核对模型配置中的 api_base、timeout、stream_timeout、num_retries。
确认是否覆盖了 general_settings，以及 AIOHTTP_CONNECTOR_LIMIT_PER_HOST 是否仍为默认值 500。
确认上游推理服务的健康状态和真实并发（Issue 中约为 40 个在途请求），并对比代理侧统计的连接数。
检查调用客户端是否会在自身截止时间提前放弃并重试，这可能是连接槽位堆积的诱因。
Issue 未提供 Python、CUDA、显卡和依赖版本信息，这些项目暂无确认证据，不建议据此下结论。

解决步骤

在现象发生时，从宿主机统计代理进程到上游端口的已建立连接数，例如 ss -tn state established '( dport = :11434 )' | wc -l，对比是否长期固定在 500。
同时直接请求上游的轻量端点，确认上游本身仍在正常响应，以缩小问题范围。
检查调用该模型组的客户端是否在较短截止时间放弃请求并重试，导致连接获取速度超过上游释放速度；如有，先调整客户端重试策略以减少堆积（可优先尝试）。
确认当前 LiteLLM 版本，并升级到包含 PR #49499 的版本，以获得连接池饱和时的诊断信息。
如确认为连接池耗尽而非上游过慢，再考虑调大 AIOHTTP_CONNECTOR_LIMIT_PER_HOST；Issue 中该连接池默认值由 litellm/constants.py 定义。此操作未在 Issue 中直接验证，且会与“上游过慢”的处置方向相反，需先确认原因。
作为临时恢复手段，作者通过移除驱动该模型组的客户端并重启代理容器，使连接数回落到 30 至 50，请求恢复正常；但这只是临时措施，不能解决根因。

验证方法

修复或调整后，重新发起 curl 请求到该模型组，确认不再在 180 秒左右返回 http 408，而是正常得到响应。同时在运行期间持续采样代理到上游的 ESTAB 连接数，确认其跟随真实在途并发变化，而不是固定钉在 AIOHTTP_CONNECTOR_LIMIT_PER_HOST。如果使用包含 PR #49499 的版本，还应确认在连接池被占满时能出现明确指向主机和连接池的诊断信息，而不是只有裸超时。