Wie misst man Qualität, Antwortzeit und Auslastung eines LLM-Servers?

Ein Dashboard ersetzt keinen fachlichen Test

Ein produktiver LLM-Dienst braucht technische und fachliche Messwerte. Für die Qualität entsteht ein fester, versionierter Testsatz aus realen Aufgaben, unbeantwortbaren Fragen, Sicherheitsfällen und erwarteten Quellen. Je nach Aufgabe eignen sich Exact Match, F1 oder Klassifikationsgenauigkeit; offene Antworten benötigen zusätzlich ein dokumentiertes menschliches Bewertungsraster, etwa für Faktentreue, Vollständigkeit und Belegtreue. Das lm-evaluation-harness unterstützt reproduzierbare Aufgaben und verschiedene Metriken, ersetzt aber keine unternehmensspezifischen Testfälle.

Für das Nutzererlebnis werden Time to First Token und Ende-zu-Ende-Latenz getrennt erfasst. Die erste Kennzahl beschreibt, wann eine sichtbare Antwort beginnt; die zweite, wann sie vollständig ist. p50 zeigt den typischen Fall, p95 und p99 die langsameren Randfälle. Mittelwerte allein verdecken Warteschlangen und Lastspitzen.

Im Betrieb gehören Ausgabe- und Eingabetokens, Anfragen pro Sekunde, laufende und wartende Anfragen, Fehlerquote, GPU-Auslastung, GPU-Speicher sowie KV-Cache-Nutzung zusammen. vLLM stellt dafür einen Prometheus-Endpunkt unter /metrics bereit und dokumentiert unter anderem Histogramme für Ende-zu-Ende-Latenz und Time to First Token. Alarme werden an vereinbarte SLOs geknüpft, nicht an beliebige Standardwerte.

Jeder Messlauf speichert Modell-ID und Revision, Quantisierung, Prompt-Version, RAG-Datenstand, Hardware, Kontext- und Ausgabelängen sowie Parallelität. Dadurch lässt sich eine Veränderung zuordnen. Vor einem Rollout werden Schwellen definiert, danach folgt ein begrenzter Canary-Betrieb. Ein schnelleres Modell wird nicht freigegeben, wenn fachliche Qualität oder Berechtigungstests schlechter werden. Ebenso ist ein qualitativ gutes Modell nicht produktionsreif, wenn p95-Latenz und Fehlerrate das Betriebsziel verfehlen.