Was LiteLLM nicht sehen kann: Die Überwachung der unter dem Gateway laufenden GPU-Verarbeitung

Der Übergang von einer manuell erstellten FastAPI-Gateway-Lösung zu LiteLLM bedeutet zentrale Anfragenprotokolle, Verwaltung von Tokens und virtuellen Schlüsseln sowie eine Reduzierung des eigenen Gateway-Code. Ein Gateway sieht weiterhin nur den Verkehr, der seine Grenzen überschreitet. Die Produktionserstellung hat eine ganze Reihe von Fragen aufgeworfen, die LiteLLM allein nicht beantworten kann – Fragen zu Warteschlangen, Vorausfüllen versus Dekodieren, Neustarts von Containern sowie Host-Überlastung, die entscheiden, ob ein elf Sekunden dauernder Aufruf erfolgreich war oder hängen geblieben ist.

Hintergrund

LiteLLM befindet sich an der Schnittstelle der Anfragen. Es protokolliert, dass eine Anfrage eingegangen ist, welches Modell sie bearbeitet hat, die Token-Zahl, welcher virtuelle Schlüssel verwendet wurde, sowie Erfolg oder Misserfolg. Für die tägliche Kostenverfolgung reicht das in der Regel aus, was Finanzabteilungen und Produktteams benötigen.

Unterhalb dieser Grenze weicht das Bild ab. Eine Anfrage von elf Sekunden kann bei einer überlasteten GPU zu einem Wartezeit im Queue führen oder zur Erstellung einer langen Antwort. Für das Gateway erscheinen diese Fälle identisch; die Lösungsansätze jedoch nicht. Sie als ein und denselben Metrikenwert zu betrachten, führt die Einsatzkräfte in die falsche Richtung.

Drei Ebenen unterhalb des Gateways benötigen jeweils ihre eigene Messgröße:

• Die Modelllaufzeit, bei der die Latenz bestimmt wird. Die Zeit bis zum ersten Token setzt sich aus Wartezeit im Queue und Vorausbefüllung zusammen, wobei die Vorausbefüllung stärker als die Dekodierung beeinflusst wird. Die Durchsatzraten von Vorausbefüllung und Dekodierung sind unterschiedlich gebremst. Diese Signale stammen vom eigenen /metrics-Endpunkt des Servicemotors (zum Beispiel vLLM), nicht vom Gateway.
• Kontainer, über cAdvisor: Welcher Prozess verbraucht Speicher und welcher Container wurde in der Nacht neu gestartet.
• Hosts, über node-exporter: Gesamter CPU-, Speicher- und Festplattenaufwand auf dem Rechner, der die GPUs beherbergt.

Vier Quellen sind wichtig, weil kein einzelner Sammler alle Ebenen sieht. Gateway-Logs ohne Laufzeitmetriken liefern nur einen unvollständigen Überblick; Laufzeitmetriken ohne Kontext zum Host und Container übersehen den störenden Prozess, der morgens um drei neu gestartet wurde.

Der gesamte Stack

Auf einem lokalen GPU-Server trennen zwei Docker Compose-Projekte bewusst die verschiedenen Aufgaben voneinander.

Gateway-Compose: LiteLLM, PostgreSQL für virtuelle Schlüssel und Ausgaben, Redis für den Rate-Limit-Cache.

Monitoring-Compose: Prometheus, Grafana, node-exporter, cAdvisor. vLLM-Prozesse laufen oft auf dem Host außerhalb beider Stacks – jeweils ein Prozess pro bereitgestelltem Modell. Prometheus sammelt Daten von den vier Zielen, die Metriken sowohl im Zusammenhang mit dem Gateway als auch lokal am Modell erfassen. Diese Trennung dient nicht ästhetischen Gründen – sie sorgt dafür, dass optionale Infrastrukturen weiterhin optional bleiben.

Wichtige Entscheidungen

1. Zwei compose-Dateien, nicht eine. LiteLLM bediente bereits andere Teams, als die Überwachung hinzugefügt wurde. Wenn Prometheus in dieselbe compose-Datei aufgenommen würde, wäre jede Änderung der Scraping-Konfiguration mit der Datei des Produktions-Gateways verknüpft. Die Trennung ermöglicht eine Fehlerisolation: Die Überwachung kann frei neu konfiguriert werden, ohne dass LiteLLM es bemerkt. Die Abhängigkeiten verlaufen in eine Richtung. Das Netzwerk zwischen den Systemen birgt einmalige Kosten im Vergleich zum anhaltenden Risiko. Wenn die Überwachung ausfällt, antworten die Modelle weiterhin; wenn das Gateway ausfällt, protokolliert die Überwachung weiterhin den Zustand des Hosts für die Nachuntersuchung.

2. Standardmäßig kein postgres-exporter oder redis-exporter. Der Host könnte sie problemlos ausführen. Dennoch wurden sie aufgeschoben:

• Solange LiteLLM ordnungsgemäß funktioniert, benötigen die internen Strukturen der Datenbank und des Caches selten eine Kontrollleiste; Fehler treten zunächst am Gateway auf.

node-exporter, cAdvisor sowie die /metrics-Endpunkte decken bereits die kritischen Schichten ab.

Zusätzliche Exporter bedeuten zusätzliche Versionen und Betriebsmemorie.

Nicht genutzte Dashboards verursachen Wartungskosten ohne Nutzen. Überprüfen Sie sie erneut, wenn Verbindungsfehler zu PostgreSQL häufig auftreten, die Authentifizierung mit virtuellen Schlüsseln aufgrund von Abfragenchancen langsamer wird oder der Speicherdruck in Redis eine reale Gefahr darstellt – fügen Sie dann in derselben Woche weitere Exporter hinzu. Schreiben Sie die Kriterien für das Aussetzen auf, damit diese Entscheidung bleibt und nicht zu Vergesslichkeit führt.

3. Langfuse beibehalten. LiteLLM bündelt die Überwachung von Anfragen, doch eine Produktaktion umfasst oft mehrere Modellaufrufe: Abrufen, Zusammenfassen, Nachverfolgen. Gemeinsame Sitzungs IDs können die Aufrufe in LiteLLM gruppieren, doch die Erfassung der Benutzererfahrung und der Nutzerbindung unterscheidet sich. Gateway-Logs dienen nicht als dauerhafte Archivierung. Ältere Protokolle liefern Daten für die Bewertung von Modellwechseln und unterstützen bei der Fehlerbehebung anhand von Berichten aus früheren Wochen. Metriken aggregieren Daten; Protokolle rekonstruieren Abläufe. Keine Menge an Metriken deckt vollständig die Informationen aus den Protokollen ab – deshalb werden beide beibehalten.

In der Praxis einsetzen

1. Die Deklaration von Modellen ausschließlich in config.yaml war umständlich. Modelle, die einer Datei zugeordnet sind, zeigen ein Konfigurations-Symbol in der Benutzeroberfläche und lassen sich nur durch Bearbeitung des Mounts sowie Neuladen eines aktiven Proxys ändern oder löschen. Über die Admin API registrierte Modelle befinden sich in PostgreSQL und überstehen Neustarts:

curl -X POST <http://localhost:4000/model/new> \
  -H "Authorization: Bearer$LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model_name": "CHAT_MODEL",
    "litellm_params": {
      "model": "openai/CHAT_MODEL",
      "api_base": "<http://host.docker.internal:8001/v1>",
      "api_key": "dummy"
    }
  }'

Es wird empfohlen, die Einstellungen über eine Konfiguration und den Modellkatalog über eine Datenbank zu verwalten. Diese Trennung ermöglicht es den Betreibern, experimentelle Modelle hinzuzufügen, ohne den von anderen Teams genutzten Gateway-Prozess zu beeinflussen.

2. Das Dashboard des Node-Exporters wurde kaum genutzt. Nachdem sich die Arbeitslasten stabilisiert und die Bereitstellungen verlangsamt hatten, lieferten die Gesamtzahlen der Hosts keine weiteren interessanten Erkenntnisse mehr. Beibehalten Sie die Datenerfassung, investieren Sie aber nicht übermäßig in ungenutzte Anzeigen. Die cAdvisor- und vLLM-Anzeigen erhielten mehr tägliche Aufmerksamkeit, da sie eine für den Benutzer sichtbare Latenz darstellen.

3. Nützliche Grafana-Startvorlagen

• vLLM-Community-Dashboards (zum Beispiel das öffentliche Dashboard auf grafana.com mit der Nummer 23991)
• cAdvisor (14282)
• Node Exporter Full (1860)

Importieren Sie diese als Baselines und löschen Sie anschließend die Anzeigen, die niemals geöffnet werden.

Zusammenfassung

Die Warnfunktion stellt die offensichtliche Lücke dar: Es gibt zwar Metriken, doch es wird keine Seite ausgelöst, wenn Schwellenwerte überschritten werden. Das Verbinden von E-Mail-APIs der Anwendung mit GPU-Hosts mischt verschiedene Aufgaben miteinander; wählen Sie beim nächsten Mal einen sichereren Benachrichtigungsweg. Konzeptionell beantworten Prometheus und Grafana bereits bekannte Fragen; Langfuse hingegen rekonstruiert, was eine Benutzeraktion durch mehrfache Aufrufe bewirkt hat. Aggregation und Rekonstruktion ergänzen sich gegenseitig. Eine Migration eines Gateways ohne Überwachungsplan verschiebt den Blindpunkt lediglich um eine Ebene nach unten.