Welche Metriken solltest du in einem LLM-Serving-System überwachen?
Automatische Übersetzung
Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
Überwache die clientseitig sichtbaren Werte für TTFT, TPOT, gesamte Latency, Fehler und Goodput zusammen mit serverseitigen Warteschlangen, Token-Längen, KV-Cache-Auslastung und Preemptions. Die GPU-Auslastung allein unterscheidet nicht zwischen sinnvoller Verarbeitung und Überlastung. Bewerte die Antwortqualität getrennt; ein schneller Dienst kann trotzdem falsche Antworten liefern.
Beginne mit dem für Nutzer sichtbaren Ergebnis
TTFT misst die Zeit vom Absenden der Anfrage bis zum ersten ausgegebenen Token. TPOT misst das durchschnittliche Intervall zwischen den folgenden ausgegebenen Tokens. Für mindestens zwei ausgegebene Tokens gilt:
Miss diese Zeitpunkte bei der Zustellung des ersten und letzten ausgegebenen Tokens. Erfasse die Latency bis zum Abschluss der Anfrage separat; abschließende Metadaten oder das Bereinigen der Verbindung können nach dem letzten Token erfolgen. Erfasse auch einzelne Unterbrechungen bei der Zustellung. Der durchschnittliche TPOT einer Anfrage kann eine Pause verbergen. SSE-Chunks können mehrere Tokens enthalten, daher sind Chunk-Intervalle und Token-Intervalle unterschiedliche Messgrößen.
Berichte Latency-Perzentile für relevante Gruppen der Arbeitslast, etwa nach Prompt-Länge und Model. Halte die Zeitgrenzen der Messung konsistent: Servermetriken schließen einen Teil der Netzwerk- und Client-Verarbeitungszeit aus.
Goodput zählt die Anfragen pro Sekunde, die alle definierten Serving-SLOs erfüllen. Wenn der Dienst 100 Anfragen pro Sekunde abschließt und 40 mindestens einen erforderlichen Schwellenwert verfehlen, beträgt der Goodput 60 Anfragen pro Sekunde. Dies misst die Serving-Leistung, nicht die sachliche Antwortqualität. DistServe verwendet Goodput unter Latency-Vorgaben zur Bewertung von Serving-Designs.
Ergänze die Metriken, die Fehler erklären
Die Metrikdokumentation von vLLM beschreibt laufende und wartende Anfragen, Latency-Histogramme, Token-Zahlen, KV-Auslastung und Preemptions. Stimme Dashboards auf die eingesetzte Version ab.
| Messgröße | Was bei einem Anstieg zu untersuchen ist |
|---|---|
| Wartende Anfragen und Wartezeit | Ankunftsrate im Verhältnis zur zugelassenen Verarbeitungskapazität |
| KV-Cache-Auslastung und Preemptions | Lange Sequenzen, aktive Batches und Speicherzuweisung |
| TTFT bei stabilem TPOT | Warteschlangen, Tokenization, Prefill oder Netzwerkverzögerung |
| TPOT und Unterbrechungen bei der Zustellung | Decode-Scheduling, Speicherverkehr oder clientseitige Pufferung |
| Tokens und Wiederholungsversuche pro abgeschlossener Anfrage | Längere Ausgaben oder wiederholte Verarbeitung |
Die vLLM-Metrik vom Typ Gauge vllm:kv_cache_usage_perc verwendet trotz ihres Namens einen Anteil von 0 bis 1. Leite Alarmschwellen aus Load Tests und der erforderlichen Wiederherstellungszeit ab. Verknüpfe eine kleine Auswahl von Qualitätsbewertungen und Fehler-Traces mit den Serving-Metriken.
Mehr zum übergeordneten Design findest du unter Überwachung von LLM-Systemen im Leitfaden.