16 views
-/https://github.com/berriai/litellm/issues/27954
GitHub · issue

#27954 [Bug]: Heavy RAM usage over some time

  • State: open
  • Author: @Sanady
  • Labels: bug, proxy

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

After some time, from some reason LiteLLM will reach maximum of the RAM capacity for the pods on Kubernetes and application pod will crash eventually. We do not understand what is causing this kind of issue with the memory leaks but it is happening. We as firm saw earlier that users were reporting similar issue and developer were claiming that they fixed the issue but, issue is repeating. LiteLLM application is being run on the two pod configuration in separated namespace. Application has attached Redis as caching service but even with that we are facing an issues. Application has request and limit of 4GB which is more then enough for this kind of application.

<img width="901" height="267" alt="Image" src="https://github.com/user-attachments/assets/3475ea9c-98d8-432c-914e-9316537b9a7e" />

<img width="1168" height="265" alt="Image" src="https://github.com/user-attachments/assets/5962bff2-c9b1-4b24-87ab-302eafe0e92d" />

### Steps to Reproduce

1. Deploy LiteLLM on Kubernetes 2. After day or two, pod memory will be filled (4GB) and eventually a…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (1 events)
#0 of 0 · 31d17h51m33s ago — entered · #import:https:::github.com:berriai:litellm post #3110
#27954 requires broad diagnosis, profiling, lifecycle analysis, reproducible testing, and production-safe validation across proxy, caching, and Kubernetes behavior; #34799 is a localized data correction with straightforward regression coverage.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search