[Bug]: GET /v1/models pegs proxy CPU for minutes / proxy hangs, health checks fail (v1.92.0 regression: per-model get_model_group_info + dee

[Bug]: GET /v1/models pegs proxy CPU for minutes / proxy hangs, health checks fail (v1.92.0 regression: per-model get_model_group_info + deepcopy of full deployment on wildcard routes)

快速结论：该问题在 LiteLLM v1.92.0 及之后版本中出现，由 GET /v1/models 端点对每个模型同步调用 Router.get_model_group_info() 并深度拷贝完整 deployment 字典引起。优先排查是否使用了通配符路由（如 bedrock/*, openai/*）且 model_info 中包含大体积的 access_via_team_ids 字段。解决方案已在 v1.93.0-rc.2 和 v1.94.0-dev.2 版本中验证，需要在 _return_pattern_matched_deployments 中共享 deployment 字典和 model_info，仅拷贝 litellm_params。

问题场景

在 LiteLLM 代理（LiteLLM proxy）中，当使用通配符模型路由（如 bedrock/*, openai/*）时，发起 GET /v1/models 或 GET /models 请求会导致代理挂起数分钟，CPU 单核 100% 占用，健康检查超时，负载均衡器将节点标记为不健康。该问题在 v1.83.14-stable 版本中不存在，从 v1.92.0 开始出现并持续到 v1.93.0-rc.2 和 v1.94.0-dev.2。

报错原文

# py-spy dump showing event loop stuck in deepcopy under
# _return_pattern_matched_deployments / get_model_group_info / create_model_info_response

deepcopy (copy.py:135)
_deepcopy_list (copy.py:197)
_deepcopy_dict (copy.py:222)  x2
deepcopy (copy.py:137)
_return_pattern_matched_deployments (pattern_match_deployments.py:103)
route (pattern_match_deployments.py:139)
...

# Symptoms:
- /v1/models or /models is extremely slow, times out, or takes minutes to respond
- LiteLLM proxy hangs / becomes unresponsive / all requests stall at the same time
- litellm process pinned at 100% CPU on one core for minutes
- /health/liveliness / /health/readiness timeouts, Kubernetes or ALB/ELB health checks flapping, 504s from the load balancer

原因分析

根本原因在于 v1.92.0 中的三个回归点叠加：

新增未缓存的 get_model_group_info 调用：在 litellm/proxy/utils.py::create_model_info_response（第 6113 行）中，现在对每个列出的模型调用 llm_router.get_model_group_info(model_id)，以附加 max_input_tokens / max_output_tokens。该调用在 v1.83.14 中不存在。
未使用 LRU 缓存：Router.get_model_group_info（router.py:8792）直接调用 _set_model_group_info，没有使用现有的 _cached_get_model_group_info LRU 包装器。该包装器本来就是为了避免在请求路径上频繁调用而添加的。
通配符匹配时的深度拷贝：每个 get_model_group_info(name) 调用，对于通配符匹配的名称，会执行 _return_pattern_matched_deployments（pattern_match_deployments.py:100-110），其中对匹配模式下的每个 deployment 都执行 copy.deepcopy(deployment)，尽管只需要修改 litellm_params["model"]。拷贝包括完整的 model_info，对于 DB 存储的模型，这可能达到数十 KB。
大体积 access_via_team_ids 字段：model_info 中约 66KB 的体积来自 access_via_team_ids 字段，该字段由 LiteLLM 自身生成（用于仪表盘的团队访问控制展示），在管理员保存模型时会被持久化到 DB 中。当有 1,438 个团队时，该字段约 66KB。5 个通配符模型行通过 UI 编辑后，每个请求的延迟就逐级从 0.7s 增长到数分钟。

净成本模型为：listing_length × D × deepcopy(model_info)，其中 D 是匹配模式下的 deployment 数量。全部同步在事件循环上执行，没有 await 点。

环境排查

LiteLLM 版本：确认是否为 v1.92.0 或更新版本（v1.93.0-rc.2, v1.94.0-dev.2）。v1.83.14-stable 不受影响。
模型路由配置：是否使用了通配符路由，如 bedrock/*, openai/* 等？
团队数量：是否有大量团队产生了大体积的 access_via_team_ids 字段？
Python 版本：在 Python 3.13.14 中重现，但理论上所有版本均受影响。
数据库模型存储：是否通过仪表盘 UI 保存过模型配置，导致 model_info 被持久化？

解决步骤

立即缓解：降级到 v1.83.14-stable 版本，直到补丁发布。
应用修复（如果使用 v1.92.0+ 源码）：修改 _return_pattern_matched_deployments 函数（在 pattern_match_deployments.py 中），共享 deployment 字典和 model_info，仅拷贝 litellm_params（这是唯一被重写的部分）。该修复将每个模型的延迟从 8.0ms 降至 0.3ms（在一个 66KB model_info 的工作负载上测试）。模拟的 548 个模型列表从 4.3s 降至 0.1s。
清除已持久化的大体积 model_info：参见单独报告的 Issue #33722，用于剥离在写入时计算得到的字段（如 access_via_team_ids）。可以通过数据库直接更新或使用 LiteLLM API 清除这些字段。
注意另一个未修复的性能问题：/model/info 通配符扩展（model_checks.py:367）会为每个扩展名称深度拷贝完整 deployment，即使此 Issue 修复后，如果持久化的大体积 blob 仍然存在，该路径仍然昂贵。需要与修复 #33701 和 #33722 一起应用。

验证方法

验证修复是否生效：

在相同配置下发起 GET /v1/models 请求，确认响应时间恢复到正常水平（毫秒级而非分钟级）。
检查 CPU 使用率是否不再被单个请求拉满到 100%。
确认健康检查端点（/health/liveliness, /health/readiness）不再超时。
运行现有测试套件：tests/test_litellm/test_router.py, tests/test_litellm/proxy/test_proxy_utils.py, tests/local_testing/test_router_pattern_matching.py。
运行新增的回归测试：tests/test_litellm/router_utils/test_pattern_match_deployments.py，确认 model_info 身份断言通过。