LLM-Monitoring im Produktivbetrieb: vLLM-Metriken in Prometheus, Alarme zu Warteschlange, KV-Cache und TTFT

Was bei einem selbst gehosteten LLM-Dienst zu überwachen ist

LLM-Monitoring für ein selbst gehostetes Modell beobachtet, was die Serving-Engine über Warteschlange, KV-Cache und Latenz meldet, und löst einen Alarm aus, bevor Nutzer eine Verlangsamung bemerken. In vLLM sind diese Werte Prometheus-Metriken unter /metrics auf dem API-Port, standardmäßig 8000, und das Beispiel von vLLM für Prometheus und Grafana hält fest, dass „das Logging von Prometheus-Metriken im OpenAI-kompatiblen Server standardmäßig aktiviert ist“. Wartende Anfragen, KV-Cache-Belegung, Verdrängungen (Preemptions), die Zeit bis zum ersten Token (TTFT) und die Latenz je Token (Inter-Token-Latenz) liefern die Signale für die wichtigsten Alarme; laufende Anfragen, Token-Zähler und Abschlussgründe ergänzen die Trenddaten für die Kapazitätsplanung.

Das Gateway vor vLLM ergänzt Angaben zu Nutzern und HTTP-Fehlern sowie eine TTFT nahe an dem, was ein Nutzer sieht. Den Zustand der GPUs liefert DCGM; unser Leitfaden zum GPU-Server-Monitoring mit DCGM behandelt ihn und erklärt, warum die GPU-Auslastung wenig über die Last einer GPU im Serving-Betrieb aussagt. TTFT, Latenz je Token und Zeit pro Ausgabe-Token (TPOT) definiert unser Leitfaden dazu, was ein privater KI-Pilot messen sollte, der aus diesen Werten auch die Hardware dimensioniert.

vLLM-Metriken für Prometheus in vLLM 0.31.0

Die Namen unten stammen aus dem Quellcode von vLLM 0.31.0, veröffentlicht am 5. Oktober 2026 und Stand 6. Oktober die aktuelle Version. Die Metriken in der Tabelle haben die Labels model_name und engine, wobei engine bei Daten-Parallelismus die Engine-Cores durchnummeriert. Zähler enden auf _total, und Histogramme ergänzen _bucket, _sum und _count.

Quellcode von vLLM 0.31.0 (Definitionen der Metriken und Abschlussgründe), veröffentlicht am 5. Oktober 2026. Die Alarmwerte sind unsere Beispiele, nicht die von vLLM; testen Sie sie mit Ihrem eigenen Anfrageaufkommen.

Geben Sie jeder Regel eine for-Dauer, mit der Prometheus „eine bestimmte Zeit lang“ wartet, bevor der Alarm feuert, damit kurze Spitzen nicht die Rufbereitschaft alarmieren. Gauges wie die Warteschlange werden nur beim jeweiligen Scrape gelesen, im eigenen Beispiel von vLLM alle 5 s und in der Voreinstellung von Prometheus jede Minute. Ergänzen Sie eine Regel für die Zeitreihe up von Prometheus, die bei einem fehlgeschlagenen Scrape 0 ist, denn ein abgestürzter Server exportiert nichts, und die übrigen Regeln haben dann keine Daten.

NVIDIAs NIM for LLMs stellt die Metriken seines vLLM-Backends unter /v1/metrics bereit, und laut seiner Dokumentation „reicht NIM die nativen Prometheus-Metriken des Inferenz-Backends ohne Änderung durch“. Dashboards und Regeln lassen sich übernehmen, im Rahmen der vLLM-Version, die ein NIM-Release enthält. Andere Engines verwenden eigene Namen; unser Vergleich von vLLM, SGLang, TensorRT-LLM und Ollama zeigt, wie jede ihre Metriken bereitstellt.

Laut dem Sicherheitsleitfaden von vLLM schützt --api-key nur Endpunkte unter /v1, /v2, /inference und /cohere, sodass /metrics, das außerhalb dieser Pfade auf demselben Port liegt, ohne Schlüssel antwortet. Lassen Sie nur das Gateway, Prometheus und auf Kubernetes den Endpoint Picker diesen Port erreichen, wie es unser Leitfaden zu einer privaten LLM-Plattform auf Kubernetes beschreibt; er behandelt auch das Autoscaling nach diesen Metriken.

Umbenannte Metriken und die Grafana-Dashboards von vLLM

vLLM hat seine Metriken mit dem Präfix gpu_ in Release 0.10.0 als veraltet markiert und ab 0.11.0 ausgeblendet. Die Gauge vllm:gpu_cache_usage_perc für den KV-Cache wurde zu vllm:kv_cache_usage_perc, und die Zähler des Prefix-Cache wurden zu vllm:prefix_cache_queries und vllm:prefix_cache_hits, die mit dem Suffix _total erscheinen. Release 0.10.2 markierte die Metrik vllm:time_per_output_token_seconds zugunsten von vllm:inter_token_latency_seconds als veraltet, denn sie maß, in den Worten des Pull Requests, „die Zeit zwischen Iterationen“. In den Metrikdefinitionen von 0.31.0 haben wir keinen dieser alten Namen gefunden; Panels, die auf ihnen aufbauen, zeigen also keine Daten. Nach der Deprecation-Policy von vLLM stellt --show-hidden-metrics-for-version eine veraltete Metrik nur in dem Release wieder her, das sie ausblendet, bevor das nächste Release sie entfernt.

Das Beispiel von vLLM für Prometheus und Grafana enthält grafana.json mit Panels für das 50. bis 99. Perzentil der Latenz, Token-Durchsatz, laufende und wartende Anfragen, KV-Cache-Belegung, Prompt- und Antwortlängen, Abschlussgründe sowie Warte-, Prefill- und Decode-Zeit. Die Observability-Beispiele von vLLM ergänzen die Dashboards Performance Statistics und Query Statistics, als JSON für Grafana und als YAML für Perses. Die Einrichtung umfasst drei Schritte.

1. Tragen Sie jeden vLLM-Server in Prometheus als Scrape-Ziel auf seinem API-Port ein, mit dem Pfad /metrics oder bei NIM /v1/metrics und einem Scrape-Intervall von wenigen Sekunden.
2. Importieren Sie grafana.json, wählen Sie die Prometheus-Datenquelle aus und stellen Sie in der Dashboard-Variable model_name das Modell ein.
3. Ergänzen Sie die Alarmregeln aus der Tabelle, jede mit einer for-Dauer, und prüfen Sie vor jedem vLLM-Upgrade dessen Release Notes auf veraltete Metriken.

Zeit bis zum ersten Token (TTFT) im Produktivbetrieb überwachen

Das TTFT-Histogramm von vLLM misst ab dem Empfang einer Anfrage durch sein Frontend. Steigt die TTFT, zeigen die Wartezeit, vllm:request_queue_time_seconds, und die Prefill-Zeit, vllm:request_prefill_time_seconds, welcher Teil gewachsen ist; ist keiner von beiden gewachsen, sehen Sie sich das Frontend an. Im Design-Dokument von vLLM zu den Metriken reicht die erste vom Einreihen der Anfrage durch den Engine-Core bis zu ihrer jüngsten Einplanung, die zweite von dieser Einplanung bis zum ersten neuen Token. Eine längere Wartezeit bedeutet fehlende Kapazität; eine längere Prefill-Zeit bei unveränderter Warteschlange deutet auf mehr Prefill-Arbeit hin: längere Prompts, die das Histogramm vllm:request_prompt_tokens zeigt, oder weniger Treffer im Prefix-Cache. Die Buckets beider Zeit-Histogramme beginnen bei 0,3 s; nutzen Sie für kürzere Wartezeiten daher den Mittelwert, also die Rate von _sum geteilt durch die Rate von _count.

Richten Sie den Alarm für ein TTFT-Ziel auf den Anteil der Anfragen aus, die es einhalten, statt auf ein Perzentil. Die Prometheus-Dokumentation merkt an, dass Sie bei einem im Voraus bekannten SLO „die festen Bucket-Grenzen eines klassischen Histogramms nutzen könnten, um eine genaue Berechnung zu ermöglichen“. Zu den TTFT-Buckets von vLLM gehören 0,25 s, 0,5 s, 0,75 s, 1 s, 2,5 s und 5 s; legen Sie das Ziel also auf eine dieser Grenzen. Die Rate von vllm:time_to_first_token_seconds_bucket mit le="1.0", geteilt durch die Rate von vllm:time_to_first_token_seconds_count, jeweils nach model_name summiert, ist der Anteil der Anfragen, deren erstes Token innerhalb von 1 s kam. Ohne die Summen bleibt das Ergebnis leer, da PromQL nur Zeitreihen mit identischen Labels einander zuordnet und nur der Bucket das Label le trägt; der Anteil der Antworten, die mit length endeten, braucht dieselben Summen. Ein Ziel von 2 s liegt zwischen zwei Grenzen, und jeder Wert dafür ist interpoliert.

Die Ausgabegeschwindigkeit je Token überwachen Sie auf dieselbe Weise mit dem Histogramm je Anfrage vllm:request_time_per_output_token_seconds, dessen Bucket bei 0,1 s die Anfragen zählt, die nach dem ersten Token im Mittel mindestens 10 Token pro Sekunde erreichten. Das Gateway sollte außerdem eine eigene TTFT erfassen, Netzwerk und Proxys eingeschlossen, die in den GenAI-Konventionen von OpenTelemetry gen_ai.client.operation.time_to_first_chunk heißt; dieser Wert liegt näher an dem, was Nutzer bemerken.

Kapazitätssignale für eine weitere GPU

Lesen Sie vor einem Kauf dieselben Metriken in der Spitzenstunde jedes Arbeitstages ab, nicht als Tagesmittel, und ordnen Sie das Muster zu: Nur zwei der fünf Muster unten verlangen mehr GPU-Speicher oder Rechenleistung.

Unsere Lesart der Metrikdefinitionen von vLLM 0.31.0 und des Optimierungsleitfadens von vLLM; die Maßnahmen sind Vorschläge zum Testen, keine Anweisungen von vLLM.

Bei häufigen Verdrängungen nennt der Optimierungsleitfaden von vLLM Abhilfen von einem höheren Wert für gpu_memory_utilization (standardmäßig 0,92) bis zu mehr Tensor- oder Pipeline-Parallelismus und warnt, dass Verdrängung und Neuberechnung „sich nachteilig auf die Ende-zu-Ende-Latenz auswirken können“. Ein FP8-KV-Cache (--kv-cache-dtype fp8) speichert ein Byte je Wert, wo ein 16-Bit-Cache zwei speichert, sodass derselbe Speicher doppelt so viele Token fasst; führen Sie vorher Ihren Evaluationssatz aus. Wir schlagen vor, die nächste GPU einzuplanen, wenn das erste oder vierte Muster an den meisten Arbeitstagen eines Monats in der Spitzenstunde auftritt, und sie nach dem Token-Durchsatz in der Spitze und der Spitzenzahl laufender plus wartender Anfragen zu dimensionieren.

Deuten die Signale auf mehr Hardware hin, wählen wir die GPU-Server aus, liefern sie und erstellen vor dem Kauf eine TCO-Rechnung gegen Cloud-GPUs. Schicken Sie uns über das Formular unten die Werte für Warteschlange, KV-Cache und Latenz aus Ihren Spitzenstunden.

Prompts und Antworten protokollieren, ohne dass sie abfließen

Serving-Metriken enthalten keine Inhalte von Anfragen, und eigene Labels sollten auch keine hinzufügen. Die Labels von vLLM benennen das Modell, die Engine und Gründe wie den Abschlussgrund, nicht Nutzer, und Prometheus warnt, dass „jede eindeutige Kombination von Schlüssel-Wert-Paaren der Labels eine neue Zeitreihe darstellt“, und rät von Labels wie Nutzer-IDs ab. Die Nutzung je Nutzer oder Abteilung kommt ins Query-Log.

Führen Sie das Query-Log im Gateway oder im Chat-Frontend, der einzigen Komponente, die weiß, wer gefragt hat. Erfassen Sie Nutzer, Zeitpunkt, Modell, Token-Zahlen, Abschlussgrund und eine Request-ID sowie, wo Ihre Richtlinie es verlangt, den Text der Prompts und Antworten, und zwar in einem Speicher, den nur die in Ihrer Richtlinie genannten Personen lesen können, mit einer Aufbewahrungsfrist, die vor dem ersten Eintrag festgelegt ist. Ein Modellserver, der zur Fehlersuche Anfragen protokolliert, kann Prompts in sein Anwendungslog schreiben und in jede Log-Plattform, die dieses Log einsammelt; beschränken Sie das auf Testsysteme. Wie lange der Text aufbewahrt werden darf, ist eine rechtliche Bewertung für Ihre Rechtsabteilung. Unser Leitfaden zu einer privaten ChatGPT-Alternative zeigt, wo das eigene Audit-Log eines Chat-Frontends nicht ausreicht.

vLLM sendet OpenTelemetry-Traces, wenn --otlp-traces-endpoint gesetzt ist; in seinem Beispiel enthält der Span von vLLM „Metadaten über die Anfrage“, und der Prompt-Text steht im Span des Clients. Die GenAI-Konventionen von OpenTelemetry stufen die Attribute für Prompts, Antworten und Systemanweisungen als Opt-In ein und merken an, dass Prompts und Antworten „wahrscheinlich sensible Informationen enthalten, einschließlich Nutzer-/PII-Daten“. Traces, die an einen externen Dienst gehen, tragen jeden aufgezeichneten Inhalt aus dem Unternehmen hinaus. NIM akzeptiert einen Header X-Request-Id als Korrelationskennung und reicht den W3C-Header traceparent weiter, aus dem sein Backend Spans erzeugt, wenn OTEL_EXPORTER_OTLP_TRACES_ENDPOINT gesetzt ist, sodass ein Eintrag im Query-Log und sein Trace dieselbe ID tragen können.

Im Rahmen unserer Leistung Private AI/ML werden Anfragen und Antworten protokolliert, sodass Security und Legal sehen, wer worauf und wie zugreift. Beschreiben Sie im Formular unten, wer dieses Log lesen soll und wie lange Sie es aufbewahren wollen.

OpenTelemetry-GenAI-Konventionen für LLM-Observability

Observability ergänzt die Traces und Logs, die eine einzelne langsame oder falsche Antwort erklären, und die semantischen Konventionen von OpenTelemetry für generative KI geben ihnen einheitliche Namen. Spans tragen gen_ai.operation.name und gen_ai.provider.name als Pflichtattribute und Token-Zahlen in gen_ai.usage.input_tokens und gen_ai.usage.output_tokens. Zu den Metriken gehören gen_ai.client.operation.duration und gen_ai.client.token.usage für Clients und gen_ai.server.time_to_first_token für Server. Stand Oktober 2026 haben sie den Status Development, und opentelemetry.io schreibt auf dem Stand der Semantic Conventions 1.44.0, dass sie in ein eigenes Repository „umgezogen sind“.

vLLM behält seine eigenen Prometheus-Namen und nutzt OpenTelemetry für das Tracing. Sein Request-Span, llm_request, zählt Token in gen_ai.usage.prompt_tokens und gen_ai.usage.completion_tokens statt in den Input- und Output-Namen der Konventionen. Die Option --collect-detailed-traces sammelt detaillierte Traces für die Module model, worker oder all, was, wie ihr Hilfetext warnt, „Auswirkungen auf die Performance haben könnte“. Erfassen Sie die Client-Metriken im Gateway; ihre empfohlenen Buckets für die Zeit bis zum ersten Chunk verdoppeln sich ab 10 ms und passen nicht zu denen von vLLM, setzen Sie dort also explizite Bucket-Grenzen, die Ihr TTFT-Ziel auf eine Grenze legen.

Was wir tun

Unsere Leistung Private AI/ML übernimmt das Deployment von Modellen on-premise mit vLLM, Ollama oder NVIDIA AI Enterprise und baut die Plattform um sie herum. Sie erhalten ein Query-Log, Daten- und Berechtigungsverwaltung und ein für den Betrieb der Plattform geschultes Team, auf Wunsch mit laufendem Support unter einem vereinbarten SLA, und wir liefern die GPU-Server, wenn die Metriken mehr Kapazität verlangen. Eurokommerz hält den Vertrag, das Engineering kommt von unserem Engineering-Partner Vixen.UNO; das erste Gespräch ist kostenlos, und der Preis des technischen Assessments steht vor Beginn fest. Wie wir während eines Projekts mit Daten umgehen, beschreibt unsere Seite Sicherheit & Compliance.

FAQ