[Bug]: Heavy RAM Usage over time

快速结论：该问题通常出现在 LiteLLM Proxy 长时间运行、每天持续处理较大量请求（包括 proxy 与 pass-through 端点）的场景，表现为内存占用持续上升且不释放，直到重启容器。优先排查 pass-through endpoints 的重复路由注册导致的累积，并确认是否运行在包含修复的版本上。

适用环境：Issue 中确认的环境为 LiteLLM v1.73.6-stable.patch.1（另有用户运行 1.74.15），通过 Docker 部署在 Almalinux 9 上；其余用户的部署方式为 Docker Compose / Portainer 栈。Python、CUDA、显卡信息在讨论中未明确。

最快修复方案：Issue 中明确验证有效的方案是升级/切换到包含 pass-through endpoints 内存泄漏修复的镜像：ghcr.io/berriai/litellm:litellm_dev_memory_fix-litellm_v1.73.0-dev_memory_fix_2。报告者确认该镜像解决了 pass-through endpoints 的内存泄漏问题。

注意事项：这是 Issue 中报告者实测确认的修复镜像，但讨论中并未给出该修复对应的稳定版版本号，因此正式生产使用时需要确认你所采用的版本已合入同类修复。此外，环境中提到的 MAX_IN_MEMORY_QUEUE_FLUSH_COUNT / MAX_SIZE_IN_MEMORY_QUEUE 仅为其他用户“类似问题”的处理经验，并非本 Issue 已验证的最终修复。

问题场景

用户通过 LiteLLM Proxy 同时使用 proxy 与 pass-through 方式，在测试应用中每天发出大量请求。运行数天后 LiteLLM 的内存占用变得非常显著，并且不会自行释放，直到手动重启容器。监控软件会因达到内存阈值而告警。讨论中有用户反馈即使空闲状态内存也会涨到约 20GB 并拖垮服务器；也有用户每天约 2 万次调用，8GB 内存的服务器需要一周重启一次 Docker。另有用户通过 Docker Compose 的 mem limit 将单服务限制在 14G，但仍会在约 12 小时内从 2GB 涨到 14GB 并保持不降，遇到突发 proxy 调用还会进入 unhealthy 状态。

报错原文

Traceback (most recent call last):
  File "/usr/lib/python3.13/site-packages/litellm/proxy/hooks/proxy_track_cost_callback.py", line 178, in _PROXY_track_cost_callback
    raise Exception(
        "User API key and team id and user id missing from custom callback."
    )
Exception: User API key and team id and user id missing from custom callback.
LiteLLM Proxy:ERROR: proxy_track_cost_callback.py:215 - Error in tracking cost callback - User API key and team id and user id missing from custom callback.

原因分析

根据 Issue 讨论，内存持续增长的主要定位点在 litellm/proxy/pass_through_endpoints/pass_through_endpoints.py 的 initialize_pass_through_endpoints 函数：当该函数被多次调用（例如动态更新 endpoint）时，相同路由会被重复注册到 FastAPI 的内部路由表中，且没有检查路由是否已存在，从而造成内存累积。这属于可能原因中已被报告者确认的一项。

另外，日志中反复出现的 User API key and team id and user id missing from custom callback. 来自 cost tracking callback，可能与内存问题无直接因果关系，讨论中也没有明确将其认定为内存泄漏的原因，仅作为伴随的重复报错存在。

环境排查

确认正在运行的 LiteLLM 版本/镜像标签（原 Issue 为 v1.73.6-stable.patch.1，另有用户运行 1.74.15）。
确认容器部署方式（Docker / Docker Compose / Portainer），以及是否设置了内存 limit/reservation。
确认是否使用 pass-through endpoints，以及是否存在动态更新 endpoint 的行为。
确认是否配置了额外 callback（如 Langfuse），因为个别用户提到配置了相关 callback。
若日志中持续出现 proxy_track_cost_callback.py 相关异常，则确认 cost callback 所需的 API key / team id / user id 是否齐全。

解决步骤

先确认当前内存增长是否与 pass-through endpoints 使用相关，回顾是否在运行期间动态更新或重复初始化过 endpoint 配置。
切换到 Issue 中已验证的修复镜像：ghcr.io/berriai/litellm:litellm_dev_memory_fix-litellm_v1.73.0-dev_memory_fix_2，该镜像针对 proxy pass-through endpoints 增加了修复。
重启容器并持续观察内存曲线，确认是否仍然持续上升到需要重启的程度。
如暂时无法升级镜像，可参考讨论中对类似问题的缓解方式（非本 Issue 最终验证方案）：在 config.yaml 中设置 MAX_IN_MEMORY_QUEUE_FLUSH_COUNT: "5000" 与 MAX_SIZE_IN_MEMORY_QUEUE: "500"。
如仍无法解决，可按讨论中维护者的请求提供 profiler logs，以便进一步定位。也有用户以 cron 每 12 小时重启容器作为临时兜底。

验证方法

在切换到 litellm_dev_memory_fix-litellm_v1.73.0-dev_memory_fix_2 后，持续运行并观察内存占用曲线：若不再出现数天内持续攀升、需要重启才能释放的情况，即可认为 pass-through endpoints 相关的内存泄漏已解决（Issue 中报告者已确认这一结果）。若升级后仍持续上涨，则说明可能存在其他内存累积路径，需要按维护者要求补充 profiler logs 继续排查。