vllm prometheus observability llmops gpu ttft

VLLM-Inferenzmetriken: Von TTFT und TPOT bis KV-Cache und Goodput

Ein Produktionsleitfaden zu den vLLM Prometheus-Metriken – Erfolgsraten, Latenzprozentswerte, Token-I/O-Verhältnis, Unterbrechungen, in Blöcken vorgenommene Vorausbefüllung, DPD sowie Akzeptanz von spekulativer Dekodierung.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 26. Sept. 202613 Min. Lesezeit2973 Wörter

Quellen: A Deep Dive into vLLM Inference Metrics

Das Bereitstellen großer Sprachmodelle stellt nicht dasselbe Problem hinsichtlich der Überwachbarkeit dar wie das Bereitstellen stateloser Microservices. CPU-Auslastung und durchschnittliche Anfragedauer sind unzureichende Indikatoren, wenn Aufmerksamkeitsmechanismen, kontinuierliches Batching sowie die Kapazität von HBM das Verhalten dominieren. Der Fokus in der Produktion hat sich vom reinen Tokendurchsatz hin zu Goodput verschoben – also erfolgreichen Abschlüssen innerhalb strenger SLOs.

Dieser Leitfaden erläutert die wichtigsten Metriken des vLLM-Engines, die auf Grafana-Dashboards dargestellt werden sollten: Zuverlässigkeitszähler, Latenz-Histogramme, Token-Ökonomie, Dynamiken des KV-Caches, Scheduler-Druck sowie Topologieoptionen, die nur dann sichtbar werden, wenn die Telemetriedaten korrekt ausgelesen werden.

Zusammengefasste Statistiken und Systemgesundheit

LLM-Engines versagen oft leise – durch verschlechterte Generierungen und versteckte Abbrüche – anstatt mit klaren HTTP-Fehlern. Daher benötigt die Gesamtgesundheitsprüfung semantische Gründe für das Abschlussverhalten, nicht nur Statuscodes.

Erfolgsrate und Verteilung der Abschlussgründe

Die Erfolgsrate ergibt sich aus den erfolgreich abgeschlossenen Anfragen im gesamten Zeitraum. In vLLM bedeutet das, zu prüfen, wie der Generierungszyklus endete, anstatt lediglich 200 OK zu zählen. Gesunde Systeme weisen in der Regel eine Erfolgsrate von etwa 99,5 % oder mehr auf; anhaltende Abfälle unter 98 % gelten als Notfallsituation.

Der Zähler ist vllm:request_success_total und wird durch finished_reason gekennzeichnet:

Stop – natürlicher Endpunkt oder konfigurierte Stoppschleife. Dies gilt als echter Erfolg.
Length – Abbruch aufgrund maximaler Kontextlänge oder maximaler Generierungsanzahl.
Abort – Trennung durch den Client oder interner Abbruch.

Kronische Beendigungen aufgrund der Length-Beschränkung deuten oft darauf hin, dass das Modell bei der Ausführung des Auftrags ins Stocken gerät, oder dass die Werte für max_model_len bzw. die Generierungsgrenzen für den jeweiligen Prompt-Stil zu streng sind. Eine typische Formulierung in PromQL ist das Verhältnis der Anzahl der Beendigungen aufgrund von Längenbeschränkungen zum Gesamtanzahl der Beendigungen innerhalb eines Fünf-Minuten-Fensters.

Durchsatz versus Erfolgskonvergenz

Zeichnen Sie den Gesamtdurchsatz der Anfragen neben die Anzahl der erfolgreich abgeschlossenen Aufträge. Bei normaler Last sollten sich die Kurven annähern. Eine zunehmende Lücke bedeutet, dass die GPUs Ressourcen für Aufgaben verbrauchen, die nie als erfolgreich gelten – sei es aufgrund von Zeitüberschreitungen (Abbrüchen) oder Überschreitung der Längengrenzen. Bei Lasttests weisen große Lücken auf eine Verschlechterung der Leistung oder auf endlose Generierungsprozesse hin, die gegen die Längengrenzen anlaufen.

Python-Abfallsammlung und Prozessspeicher

Der größte Teil der rechenintensiven Aufgaben findet in CUDA/C++ statt, doch die Orchestrierung erfolgt weiterhin in Python. Verfolgen Sie die Anzahl der Abfallsammlungen zusammen mit dem Prozess-RSS-Wert.

Häufige GC-Einsätze verursachen Schwankungen in der Zeit zwischen den Tokens. Ein stetig ansteigender RSS deutet auf Lecks in den Bindings hin und führt letztendlich zum OOM-Killer. Pods können sowohl im Leerlauf als auch bei hoher Belastung hinsichtlich der CPU „in Ordnung“ erscheinen; erst in unverwalteten Speicherpools tritt der stillen Zerstörung ein.

Quantifizierung von Latenz und Benutzererfahrung

Die generative Latenz weist ein langgestrecktes Verteilungsmuster auf. Durchschnittswerte verbergen die Probleme; P50/P90/P99 (und ähnliche Werte) sind unerlässlich.

End-to-End-Anfragenlatenz

Die E2E-Latenz umfasst den Zeitraum von der Ankunft bis zum letzten Token und dessen Abschluss. vLLM stellt vllm:e2e_request_latency_seconds als Histogramm zur Verfügung. Für Quantile wird histogram_quantile() mit linearer Interpolation innerhalb der Intervalle verwendet. Unregelmäßige Anstiege bei P99 deuten oft darauf hin, dass der kontinuierliche Batcher die Ankünfte nicht sauber mischen kann – es ist an der Zeit, den Scheduler und den Cache-Druck zu überprüfen.

Zeit bis zum ersten Token (TTFT) P99

TTFT ist die Interaktivitätsmetrik. Die Leitlinien der HCI legen ein Ziel von etwa einer Sekunde fest, bevor Frustration aufkommt.

TTFT wird hauptsächlich durch prefill bestimmt: Es werden die Anweisungen gelesen, die Aufmerksamkeit gelenkt und der anfängliche KV-Cache erstellt. Die Kosten steigen in etwa mit dem Quadrat der Sequenzlänge multipliziert mit der Breite – es handelt sich dabei um rechenintensive TFLOPS-Arbeiten. Beispiel: Ein 512-Token-Prefill bei einem Modell mit etwa 70 Milliarden Parametern erfordert mehrere Dutzend TFLOPs.

PromQL für TTFT P99:

histogram_quantile(0.99, sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le))

In Chat-UIs ist TTFT P99 oft die entscheidende Beschränkung. Sehr große versteckte Speichermengen bei Mittelklasse-GPUs (zum Beispiel der L40S-Klasse) können TTFT unzumutbar machen – unabhängig von der Batching-Strategie – und zwingen Teams dazu, kleinere Modelle oder Prozessoren mit höherer TFLOPS-Leistung (H100-Klasse) zu verwenden.

Zeit pro Ausgabetoken (TPOT) und Aufschlüsselung der Inferenzphase

Nach dem ersten Token übernimmt decode. TPOT (Inter-Token-Latenz) misst das Tempo bei den nachfolgenden Tokenen.

Die Dekodierung ist in der Regel durch die Speicherbreite begrenzt: Jeder Schritt lädt Gewichte sowie die KV-Historie vom HBM in den Recheneinheit mit geringer arithmetischer Intensität hoch (~1 FLOP/Byte für dichte, nicht-MoE-Pfade).

Eine nützliche Aufteilung:

E2E ≈ TTFT + (N_output − 1) × TPOT

Darstellungen der einzelnen Phasen zeigen den Anteil des Vorausladevorgangs im Verhältnis zum Dekodierungsanteil:

Hoher Vorausladezeitbedarf → lange Prompts oder geringe TFLOPS-Werte.
Hohe Dekodierzeit → lange Ausgabeergebnisse oder ausgelastete HBM-Breite.

Den Engpass zu identifizieren, besteht darin, TTFT im Vergleich zu TPOT bei steigender Last zu betrachten.

Token-Throughput und Arbeitslastcharakterisierung

Ohne Volumenangaben lässt sich die Hardware nicht richtig bewerten.

Token-Throughput und das IO-Verhältnis

Teilt den Throughput in Prompt-Token pro Sekunde und Generierung-Token pro Sekunde auf. Höhere, anhaltende Werte ermöglichen eine bessere Amortisierung der GPU-Kosten.

Das Token-IO-Verhältnis (Prompt-Tokens im Verhältnis zu Generierungstokens) beschreibt die Arbeitslast:

Hoch (~20:1) — lange Eingaben, kurze Ausgaben: RAG, Zusammenfassung, Klassifizierung. Starke Vorausbelegung.
Niedrig — kurze Prompts, lange Generierungen: offener Chat, Codeerstellung. Starke Dekodierung/HBM-Nutzung.

Eine nicht passende Topologie zum Verhältnis führt zu Geldverschwendung: RAG auf für Dekodierung optimierten Pools oder langer Chat auf Boards mit geringer Vorausbelegung.

Heatmap zur Anfragelänge (Prompt)

Heatmaps zur Promptlänge zeigen an, ob der Datenverkehr eine ruhige, einmodale Verteilung aufweist oder eine Mischung aus sehr kurzen und sehr langen Prompts. Starke Schwänze in der Promptlänge erklären plötzliche TTFT-Anstiege, selbst wenn die QPS moderat erscheint.

Interne Mechanismen des Engines und Cache-Dynamik

Externe Latenz hängt von der KV-Cache und dem Scheduler-Zustand ab.

Nutzung der GPU-KV-Cache

Überwachen Sie, wie voll der KV-Pool ist. Mit steigender Auslastung werden durch kontinuierliches Batching weniger Sequenzen aufgenommen; sobald ein Schwellenwert überschritten wird, greift das System ein.

Vorzeichenkürzel-Cache-Hit-Rate und Ersparnisse

Durch das Caching von Vorzeichenkürzeln werden KV-Einträge für gemeinsame Prompt-Vorzeichen wiederverwendet (System-Prompts, RAG-Header). Die Hit-Rate sowie die eingesparten Vorabdaten zeigen an, ob die Prompt-Struktur und der Routing-Prozess tatsächlich Vorzeichenkürzel teilen – oder versehentlich jede Anfrage eindeutig machen.

Scheduler-Zustand und Systemeffizienz

Achten Sie auf die Zahlen für laufende und wartende Prozesse. Steigende Wartezeiten bei konstantem Laufvolumen deuten in der Regel auf Grenzen beim KV-Pool oder bei max_num_seqs hin, nicht auf eine beschäftigte CPU.

Scheduler-Zustand und Einmischungsrate

Falls KV die Vektoren des nächsten Tokens nicht speichern kann, greift vLLM zur Vorbeugung. vllm:num_preemptions_total ist ein Zähler für solche Vorbeugungsmaßnahmen: Ein nicht-nuller Wert bedeutet, dass weitere Vorbeugungen mehr VRAM, mehr Kopien oder eine niedrigere Obergrenze für max_num_seqs erfordern.

Systemeffizienz und Wartezeit in der Anfragenwarteschlange

Die Systemeffizienz vergleicht das Verarbeitungstempo mit dem Eintreffertempo der Anfragen. Ein Wert nahe 1,0 bedeutet, dass die Anfragen schnell bearbeitet werden; Werte unter etwa 0,7 deuten darauf hin, dass sich die Warteschlange schneller füllt, als die GPUs sie leeren können.

Dieser Problembereich zeigt sich in vllm:request_queue_time_seconds – der Zeit, die man mit Warten verbringt, bevor nützliche Berechnungen durchgeführt werden. Die Wartezeit erhöht die Gesamtlaufzeit, obwohl keine Tokens erzeugt werden.

Klassische HPA-Lösungen, die auf der CPU basieren, versagen hier. Verbinden Sie vllm:num_requests_waiting sowie die Metriken zur Wartezeit über einen Prometheus-Adapter, damit die HPA je nach Länge der Warteschlange skaliert – beispielsweise, wenn mehr als nur wenige Anfragen warten – anstatt auf Illusionen bezüglich der CPU-Leistung zu reagieren.

Infrastruktur, Lastverteilung und fortgeschrittene Topologien

Software-Signale müssen der Realität der Hardware entsprechen.

Lastverteilung und Hardware-Nutzung

Die Dauer der LLM-Anfragen variiert stark – Minuten für lange Generierungen gegenüber sofortigen, kurzen Antworten. Round-Robin führt daher zu einer ungleichen Verteilung der Ressourcen. Es sind Lastverteilungsmechanismen vorzuziehen, die den aktuellen Bearbeitungszustand berücksichtigen.

Kontrollen mit DCGM:

GPU-Nutzung – ein hoher Nutzungsgrad bei geringen Warteschlangen weist auf eine gute Rentabilität hin; ein hoher Nutzungsgrad bei langen Warteschlangen deutet auf Saturation hin.
Verwendete VRAM – bestätigt, dass vLLM zu Beginn den gewünschten Anteil reserviert hat.

Lösung des Konflikts zwischen Vorausfüllen und Dekodieren

Ein umfangreiches, rechenintensives Vorausfüllverfahren innerhalb einer gemischten Batch-Verarbeitung kann die Tensor-Kerne monopolisieren und jeden laufenden Dekodierprozess blockieren – was zu starken Schwankungen im TPOT und stockenden Datenströmen führt.

Zwei Maßnahmen spielen eine dominante Rolle: gebündelte Vorausbefüllung und getrennte Vorausbefüllung/Decodierung.

Gebündelte Vorausbefüllung

Enorme Eingabetexte werden in feste Blöcke aufgeteilt (zum Beispiel 512 Token) und diese Blöcke mit den Decodierungs Schritten anderer Anfragen abgewechselt. Der TTFT für Neulinge steigt leicht an, während der TPOT bei allen anderen stabil bleibt. Metriken zeigen glattere ITL-Histogramme, einen moderaten P50-TTFT-Kostenwert sowie erhebliche Verbesserungen in der Stabilität des P99-Streams.

Getrennte Vorausbefüllung und Decodierung (DPD)

In größeren Skalen werden die verschiedenen Phasen auf unterschiedlichen Rechenressourcen durchgeführt: Die Vorausbefüllung erfolgt auf GPUs mit hoher TFLOPS-Leistung, die Decodierung auf GPUs mit viel HBM-Speicher; nach der Vorausbefüllung werden die KV-Daten über das Netzwerk übertragen. Beobachten Sie dazu die Übertragungstimer und -datenmengen von NIXL (oder ähnlichen Tools) – beispielsweise vllm:nixl_xfer_time_seconds_sum und vllm:nixl_bytes_transferred_sum. DPD ist nur dann vorteilhaft, wenn die Übertragungszeit geringer ist als die durch sie beseitigte Störung; dabei entscheidet die Qualität von RDMA/NCCL über diesen Vergleich.

Spekulative Dekodierungsmathematik

Durch spekulative Dekodierung wird die auf den Speicher beschränkte Dekodierungsleistung beschleunigt, indem ein kleines Entwurfsmodell Token vorschlägt und ein Zielmodell diese in einem Durchlauf überprüft. Die Überprüfung mehrerer Token kostet in der Regel nur einen Rechenschritt, wodurch die Grenzen von HBM überschritten werden können, sofern die Entwürfe gut sind.

Wichtiger Indikator: Entwurfsakzeptanzrate (vllm:spec_decode_draft_acceptance_rate). Die erwarteten angenommenen Token pro Schritt folgen einer geometrischen Reihe mit der Akzeptanzwahrscheinlichkeit α. Sinkt α unter etwa 0,5, kann der Aufwand für Entwürfe die Einsparungen übersteigen und das System verlangsamen.

Entwürfe sollten bei Produktionstemperatur bewertet werden. Bei gieriger Strategie (T=0) kann α etwa 0,8 betragen, während bei kreativer Strategie (T=1,0) derselbe Vergleich auf α etwa 0,4 sinkt – wodurch eine Optimierung zu einer Verschlechterung wird.

Prometheus-Multi-Prozess-Telemetrie-Architektur

vLLMs OpenAI-kompatibler Server nutzt Multiprocessing. Naive Prometheus-Cliente funktionieren nicht über verschiedene Worker hinweg (aufgrund von GIL und geteilter Speicherung).

Die Lösung ist prometheus_client.multiprocess in Kombination mit PROMETHEUS_MULTIPROC_DIR: Jeder Worker fügt Delta-Werte zu memortierten Dateien hinzu; die Scraping-Tools wenden sich an einen MultiProcessCollector, der die OpenMetrics-Ausgaben zusammenführt. Aufwändige PromQL-Funktionen (histogram_quantile, rate) bleiben bei Prometheus und nicht auf dem Inferenzpfad – dadurch wird die Messung der Latenz selbst nicht zur Latenz.

Insgesamt liefern diese Informationen – Erfolgs- und Abschlussgründe, TTFT/TPOT/E2E-Quantile, Token-I/O-Muster, KV-Besetzungszustand, Unterbrechungen, Wartezeiten sowie topologiebezogene Übertragungs- und spekulative Statistiken – einen geschlossenen Kreislauf von den Benutzer-SLOs bis hin zur GPU-Physik. Genau dieser Kreislauf verwandelt vLLM von einem Demo-Server in eine nutzbare Inferenzplattform.

Bewahren Sie ein schriftliches Handbuch auf, in dem jede kritische Kennzahl einer ersten Maßnahme zugeordnet wird: steigende Preemptions → Verringerung von max_num_seqs oder Hinzufügen von VRAM; nur TTFT P99 → Verkürzung der Prompts, Erhöhung der TFLOPS oder Aktivierung des Prefix-Caches; Anstiege von TPOT bei voller KV → Reduzierung des Dekodierdrucks oder Beseitigung von Interferenzen durch Vorausfüllung; spekulativer α-Kollaps → Anpassung von Draft- und Temperatureinstellungen. Verknüpfen Sie jede Kapazitätsänderung mit einem Before/After-Chart zum Goodput auf derselben Darstellung, damit die Hardwareausgaben mit Erfüllung der SLOs verbunden sind und nicht nur mit scheinbaren Tokens pro Sekunde. Überprüfen Sie die IO-Ratio-Dashboards stets, wenn sich das Produktportfolio ändert – mit dem Start neuer RAG-Funktionen und langformatiger Features verschieben sich die Engpässe zwischen Vorausfüllung und Dekodierung über Nacht, und die gestrigen Autoscaling-Schwellwerte werden zu den heutigen stillen Warteschlangen. Schließlich sollten die Verzeichnisse für Multiprozess-Kennzahlen als Teil des Pod-Lebenszyklus betrachtet werden: leere oder aufgrund von Berechtigungsproblemen fehlerhafte PROMETHEUS_MULTIPROC_DIR-Pfade erscheinen wie „gesunde“ Datensammlungen mit Nullwerten, obwohl die Nutzer dies bereits spüren.

der Ausfall.

Beim Einbinden eines neuen Modell-Checkpoints sollte man ein Lastprofil (Mischung der Prompt-Länge, Mischung der Ausgabe-Länge, Konkurrenzgrad) einfrieren und vor dem Freigeben des Traffics dieselben PromQL-Tabellen vergleichen. Ein Checkpoint, der bei der Anzahl der Tokens pro Sekunde gut abschneidet, aber bei TTFT P99 oder dem Preemption-Rate schlecht abschneidet, eignet sich nicht für interaktive APIs.

Beim Einbinden eines neuen Modell-Checkpoints sollte man ein Lastprofil (Mischung der Prompt-Längen, Mischung der Ausgabe-Längen, Konkurrenzgrad) einfrieren und vor dem Freigeben des Traffics dieselben PromQL-Tabellen vergleichen. Ein Checkpoint, der bei der Anzahl der Tokens pro Sekunde gut abschneidet, aber bei TTFT P99 oder dem Preemption-Rate schlecht abschneidet, eignet sich nicht für interaktive APIs.

Beim Einbinden eines neuen Modell-Checkpoints sollte man ein Lastprofil (Mischung der Prompt-Längen, Mischung der Ausgabe-Längen, Konkurrenzgrad) festlegen und vor dem Freigeben des Traffics dieselben PromQL-Tabellen vergleichen. Ein Checkpoint, der bei der Anzahl der Tokens pro Sekunde gut abschneidet, aber bei TTFT P99 oder dem Preemption-Rate schlecht abschneidet, eignet sich nicht für die Nutzung in interaktiven APIs.

Beim Einbinden eines neuen Modell-Checkpoints sollte man ein Lastprofil (Mischung der Prompt-Länge, Mischung der Ausgabe-Länge, Konkurrenzgrad) festlegen und vor dem Freigeben des Traffics dieselben PromQL-Tabellen vergleichen. Ein Checkpoint, der bei der Anzahl der Tokens pro Sekunde besser abschneidet, aber bei TTFT P99 oder dem Preemption-Rate schlechter abschneidet, eignet sich nicht für die Nutzung in interaktiven APIs.

← Alle Artikel Brief senden