LiteLLM memory keeps growing after OOM restart, with no apparent reclamation

[ZombieBlue]

Problem description

LiteLLM continuously consumes a high amount of memory over time and eventually triggers OOM. After the OOM restart, memory drops but then keeps increasing instead of stabilizing or being reclaimed.

From the attached monitoring graph:

• WSS stayed around 23-24 GiB before the OOM event.
• Around 12:30, usage peaked at approximately 40 GiB and OOM/restart occurred.
• After restart, memory dropped to about 16 GiB, then steadily increased and approached 20 GiB again.

Environment

• Deployment: Kubernetes
• Metric: Memory Usage (WSS)
• LiteLLM version: to be provided
• Python version: to be provided
• Proxy/Router, streaming, cache, logging/tracing integrations: to be provided

Questions

1. Could this indicate a memory leak, or could it be caused by connection pools, async clients, cache retention, logging/tracing integrations, or unreleased request/streaming contexts?
2. What configuration parameters or operational optimizations are recommended to prevent continued growth after restart (for example worker count, client connection pools, cache TTL/capacity, concurrency limits, or request/response retention)?
3. What profiling data should be collected to distinguish Python heap memory from native memory and identify the objects or request types responsible for the growth?
4. If this is a known issue, please provide the fixed version, configuration, or related issue/PR.

The attached graph shows WSS continuing to rise after the OOM restart.