Ein gesetztes litellm_settings.max_budget kann im LiteLLM Proxy sichtbar sein, obwohl Anfragen nach Überschreiten des Grenzwerts weiterlaufen. Ein Budget ist erst dann als Sperre belegt, wenn der Proxy eine Anfrage auf genau dieser Budgetebene wegen des ausgeschöpften Betrags ablehnt. Der Konfigurationseintrag zeigt weder eine funktionierende Kostenverbuchung noch die getroffene Entscheidung.
Warum greift LiteLLM max_budget ohne Datenbank nicht?
Der LiteLLM Proxy braucht für litellm_settings.max_budget eine nutzbare Datenbank, um erfasste Ausgaben mit dem globalen Limit abzugleichen. Fehlt sie, warnt der Proxy beim Start, verarbeitet Anfragen aber weiter. Ein erfolgreicher Start bestätigt deshalb nur, dass der Proxy läuft, nicht die Budgetdurchsetzung.
Eine gesetzte DATABASE_URL beweist noch keine Verbindung: Ein falsches Passwort oder ein nicht erreichbarer Server verhindert sie ebenfalls. Im Startprotokoll sind die Budgetwarnung und der Verbindungsstatus deshalb wichtiger als der Konfigurationseintrag allein. Fehlt die Verbindung, betrifft das im DevOps- und KI-Plattformbetrieb alle Budgetprüfungen, die diese Datenbank benötigen. Nach dem Verbindungscheck entscheidet die Zuordnung des Schlüssels, welches Limit überhaupt getestet wird.
Welches Budget trifft die Testanfrage?
Ein Team-Schlüssel wird nicht allein deshalb dem persönlichen Budget seines Erstellers zugeordnet. Maßgeblich sind der verwendete Schlüssel und die Budgetregeln, denen die konkrete Anfrage zugeordnet ist. Die Ebenen lassen sich vor dem ersten Test getrennt erfassen:
| Budgetebene | Prüffrage |
|---|---|
| Proxy-weit | Ist litellm_settings.max_budget gesetzt und die Datenbank verbunden? |
| Virtueller API-Schlüssel | Hat der verwendete Schlüssel ein eigenes max_budget? |
| Team | Ist der Schlüssel einem Team mit Budget zugeordnet? |
| Teammitglied | Ist die Anfrage dem Mitglied mit eigenem Budget zugeordnet? |
Beim Test eines Team-Schlüssels belegt der Verbrauch im persönlichen Konto seines Erstellers keine Budgetdurchsetzung für diesen Schlüssel. Auch ein Modellfehler ist kein Budgetbefund: Virtuelle Schlüssel können auf bestimmte Modellnamen beschränkt sein. Im KI-Engineering mit LLMs müssen Modellfreigabe und Budget daher getrennt geprüft werden. Mit einem freigegebenen Modell lässt sich die Ablehnung dem richtigen Limit zuordnen.
Wie lässt sich eine Budgetablehnung nachweisen?
Das Beispiel verwendet einen isolierten Proxy mit PostgreSQL und einem Modell, dessen Aufrufen LiteLLM Kosten zuordnet. Die Zugangsdaten liegen in Umgebungsvariablen. Das globale Budget ist vom niedrigeren Budget des später erzeugten Testschlüssels getrennt:
model_list:
- model_name: budget-test
litellm_params:
model: openai/gpt-4o-mini
api_key: os.environ/OPENAI_API_KEY
litellm_settings:
max_budget: 1.00
general_settings:
master_key: os.environ/LITELLM_MASTER_KEY
database_url: os.environ/DATABASE_URLDie folgenden Aufrufe setzen einen lokal laufenden Proxy auf Port 4000, gültige Zugangsdaten für das Modell und eine bestätigte Datenbankverbindung voraus. Bleibt PostgreSQL unerreichbar, hat ein Budgettest noch keine Aussagekraft.
Das Schlüssellimit prüfen
Der Master-Key wird nur zum Erzeugen des virtuellen Schlüssels verwendet. Dessen Modellfreigabe ist auf budget-test begrenzt:
curl -sS -X POST http://localhost:4000/key/generate -H "Authorization: Bearer $LITELLM_MASTER_KEY" -H "Content-Type: application/json" -d '{"models":["budget-test"],"max_budget":0.0001}'Das Budget von 0.0001 US-Dollar ist nur ein Testwert. Wie viele Aufrufe es ausschöpfen, hängt vom Modell, den verbrauchten Token und der Kostenberechnung ab. Für die nächsten Aufrufe steht der ausgegebene virtuelle Schlüssel in der lokalen Umgebungsvariable TEST_KEY; der Master-Key wird dafür nicht verwendet.
curl -sS -X POST http://localhost:4000/chat/completions -H "Authorization: Bearer $TEST_KEY" -H "Content-Type: application/json" -d '{"model":"budget-test","messages":[{"role":"user","content":"Antworte mit OK."}],"max_tokens":12}'Der Aufruf wird mit demselben Schlüssel wiederholt, bis der verbuchte Verbrauch das Schlüssellimit erreicht oder überschreitet. Nach sichtbarer Kostenverbuchung folgt eine weitere Anfrage. Nur eine Zurückweisung wegen des ausgeschöpften Budgets zählt; ein Provider-Fehler, ein ungültiger Schlüssel oder eine fehlende Modellfreigabe belegt etwas anderes.
Für den Vergleich nach Konfigurationsänderungen enthält das Testprotokoll:
- Die verwendete Proxy-Version und Konfiguration
- Den Status der Datenbankverbindung
- Einen Alias des Testschlüssels ohne dessen Geheimwert
- Das Modell und den Zeitpunkt der Aufrufe
- Den verbuchten Verbrauch und die budgetbedingte Ablehnung
Das globale Limit separat prüfen
Die Ablehnung des Testschlüssels belegt nur dessen eigenes max_budget, nicht das globale litellm_settings.max_budget. Für den globalen Test dient eine getrennte Testinstanz mit eigener Datenbank und einem Schlüssel ohne eigenes Budget oder weitere zugeordnete Limits. Erst eine budgetbedingte Ablehnung nach Überschreiten des global verbuchten Verbrauchs belegt diese zweite Regel. Beide Normaltests setzen verfügbare Kostendaten voraus; deren Ausfall ist ein eigener Fall.
Was passiert bei Ausfall der Kostenerfassung?
Bei einem ausgeschöpften Budget liegt ein erfasster Verbrauch vor, gegen den der Proxy das Limit prüfen kann. Fällt die Datenbank aus oder liefert ein eingesetzter Kostenzähler veraltete Werte, fehlt womöglich genau dieser Stand. Eine erfolgreiche Ablehnung im Normalbetrieb sagt deshalb nichts darüber aus, wie der Proxy bei fehlenden Kostendaten reagiert.
Die Option fail_closed_budget_enforcement ist für strengere Budgetprüfungen bei fehlenden oder veralteten Budgetdaten vorgesehen. Bei einem eingesetzten Redis-Kostenzähler können verzögerte Aktualisierungen den angezeigten Verbrauch hinter den tatsächlichen Aufrufen zurücklassen. Ob die Option in der installierten LiteLLM-Version einen bestimmten Redis- oder PostgreSQL-Ausfall abfängt, muss ein Ausfalltest zeigen; sie garantiert keinen exakten Stopp am Grenzwert.
Für diesen Test bleibt der Schlüssel gleich, während jeweils nur eine Abhängigkeit ausfällt. Ein gestörter Redis-Zähler und eine unterbrochene PostgreSQL-Verbindung gehören in getrennte Durchläufe. Proxy-Meldung und Antwort auf eine neue Anfrage zeigen, ob Aufrufe bei fehlenden Kostendaten weiterlaufen oder abgewiesen werden. Nach einem Ausfall lohnt sich derselbe Blick auf Änderungen an den Budgetregeln.
Wann ist ein neuer Budgettest nötig?
Eine neue Teamzuordnung oder ein geändertes Schlüssellimit kann bestimmen, welche Regel eine Anfrage trifft. Auch nach einem Versionswechsel belegt das alte Protokoll nur das Verhalten der zuvor getesteten Kombination aus Proxy, Konfiguration und Schlüssel. Der erneute Test verwendet deshalb die aktuelle Zuordnung und hält die abgelehnte Anfrage fest.
Access-Group-Budgets gehören nur dann dazu, wenn die installierte LiteLLM-Version diese Ebene unterstützt und sie konfiguriert ist. Ein Hinweis in Versionsinformationen belegt noch nicht, dass ein bestimmter Schlüssel dieser Regel unterliegt. Für jede neu verwendete Budgetebene braucht es einen zugeordneten Testaufruf. Erst dann lässt sich das Verhalten vor und nach der Änderung vergleichen.
Fazit: Eine Ablehnung statt eines Konfigurationswerts
Ein abgewiesener Aufruf macht die Budgetregel des laufenden Proxys beobachtbar, sofern Schlüssel und Budgetebene feststehen. Dokumentiere bei der nächsten Proxy-Änderung die erste wegen Budgetüberschreitung abgelehnte Anfrage samt Schlüsselalias und verbuchtem Verbrauch.