Issue Station
Sign In
Tools hereToolbox

litellm - 💡(How to fix) Fix [Bug]: Deleted model reappears in /v2/model/info across multiple LiteLLM instances

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Code Example

POST /model/delete

---

GET /v2/model/info

---
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

When running multiple LiteLLM instances with a shared database and store_model_in_db: true, deleting a model via POST /model/delete is not synchronized correctly across instances.

The model is deleted successfully in the instance that handled the delete request, but it still appears in GET /v2/model/info responses when the request is served by another LiteLLM instance.

Environment

  • Multiple LiteLLM instances running
  • Shared database
  • general_settings.store_model_in_db: true
  • Same configuration across all instances

Steps to Reproduce

  1. Run 2 LiteLLM instances connected to the same database.
  2. Create a model deployment.
  3. Call:
POST /model/delete

against Instance A. 4. Verify deletion succeeds. 5. Call:

GET /v2/model/info

against Instance B.

Expected Behavior

Deleted model should no longer appear in /v2/model/info responses from any instance.

Actual Behavior

The deleted model still appears in /v2/model/info when the request is served by another LiteLLM instance.

Additional Notes

  • GET /model/{id} correctly reflects deletion.
  • Credentials and virtual keys sync correctly across instances.
  • Problem appears isolated to model list/info caching across instances.
  • Restarting the stale instance fixes the issue temporarily.

This looks like an in-memory cache invalidation issue for model registry synchronization across LiteLLM instances.

Relevant log output

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on ?

v1.73.6

Twitter / LinkedIn details

No response

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING