Konzeptillustration: Wartezeit bis zur ersten Ausgabe, Rhythmus der Streaming-Ausgabe und Gesamtdurchsatz beschreiben unterschiedliche Aspekte eines Dienstes. Die Darstellung zeigt keine Messdaten.
Ein Server kann mehr Tokens pro Sekunde erzeugen, während im Chatfenster länger keine Antwort erscheint. Vor der Freigabe eines Inferenz-Upgrades stellt sich deshalb eine praktische Frage: Welchen Teil der Wartezeit wollen wir für die Nutzer verkürzen?
Zwei Arten von „schneller“ in derselben Auswertung
Der am 6. Oktober zusammengeführte vLLM-PR #60140 enthält Ergebnisse für GLM-5.3 nach der Umstellung auf einen FP8-KV-Cache. Bei TP4, 8.000 Eingabe-Tokens, 1.000 Ausgabe-Tokens und 1, 4 oder 16 gleichzeitigen Anfragen zeigt die Tabelle einen Durchsatzgewinn von 2,3 % bis 5,5 %. Die mediane Zeit bis zum ersten Token (TTFT) stieg jedoch um 6,9 % bis 11,1 %. Die mediane Gesamtlatenz sank um 3,1 % bis 6,3 %: Die Antwort begann später, war aber früher fertig. Quelle: PR #60140
Diese Ergebnisse wurden von einem Mitwirkenden berichtet; wir haben sie nicht reproduziert. Sie umfassen auch keine systematische Testreihe mit längeren Eingaben. Ein nachfolgender Patch beschränkte das Standardverhalten auf NVIDIA SM100. Diese Ergebnisse auf jede GLM-Bereitstellung zu übertragen, würde über die vorliegenden Belege hinausgehen. Quelle: PR #60281
Die einzelnen Wartephasen auseinanderhalten
Nutzer warten zunächst auf die erste Ausgabe, dann auf weitere Inhalte und schließlich auf die vollständige Antwort. Der Serverdurchsatz misst die gesamte Ausgabemenge; TTFT erfasst die Anlaufzeit; die Inter-Token-Latenz (ITL) beschreibt die Abstände zwischen aufeinanderfolgenden Streaming-Ausgaben; die Gesamtbearbeitungszeit umfasst die gesamte Anfrage. Die serverseitige TTFT von vLLM schließt die Eingabeverarbeitung ein und misst daher nicht allein die GPU-Rechenzeit. Auch der Zeitaufwand für Netzwerk, Gateway und Darstellung sollte auf Client-Seite beobachtet werden. Quelle: Metrikdesign
Bei der Ablaufplanung sind Abwägungen nötig. Das „Chunked Prefill“ von vLLM zerlegt lange Eingaben in Abschnitte und plant deren Verarbeitung zusammen mit Anfragen ein, für die bereits Ausgaben erzeugt werden. Laut Dokumentation begünstigen kleinere Token-Budgets pro Batch die ITL, größere Budgets dagegen die TTFT. Das ist eine allgemeine Erklärung dafür, warum sich Latenzmetriken unterschiedlich entwickeln können. Der oben genannte PR belegt damit nicht, dass dies die Ursache für die verschlechterte TTFT bei jener FP8-Umstellung war. Quelle: Optimierungsleitfaden
Auch Caching spart Arbeit in einer bestimmten Phase. Prefix Caching nutzt Berechnungen für ein gemeinsames Eingabepräfix erneut und hilft so beim Prefill. Die Decode-Arbeit zur Erzeugung neuer Tokens wird dadurch nicht unmittelbar verkürzt. Wiederholte Fragen zu demselben langen Dokument können deshalb anders profitieren als Arbeitslasten, bei denen überwiegend lange Antworten erzeugt werden. Quelle: Prefix Caching und seine Grenzen
Abnahmekriterien vor dem Upgrade festlegen
Der folgende Testplan ist unser Vorschlag, keine Sammlung bereits durchgeführter Experimente.
-
Vergleichsbedingungen konstant halten. GPU, Modellversion, Commit des Inferenz-Frameworks, Quantisierung, Parallelisierung, spekulatives Decoding und Sampling-Einstellungen dokumentieren. Jeweils nur den zu prüfenden Bestandteil ändern, damit sich ein Gewinn seiner Ursache zuordnen lässt.
-
Eine kleine Testmatrix aufbauen. Drei reale Aufgabentypen auswählen: kurze Dialoge, kurze Antworten zu langen Dokumenten und lange Ausgaben. Jeden Typ mit neuen und wiederverwendbaren Präfixen bei niedriger, normaler und nahezu maximaler Auslastung testen. Das ergibt 18 Felder. Eingaben müssen innerhalb des vom Modell unterstützten Bereichs liegen; die Laststufen sollten aus dem eigenen Anfrageaufkommen abgeleitet werden.
-
Eine Lastspitze ergänzen. Tatsächliche Ankunftsrate, tatsächliche Anzahl gleichzeitiger Anfragen, Warteschlangen und fehlgeschlagene Anfragen erfassen. Ein Test mit einer festen Anzahl gleichzeitiger Anfragen und ein plötzlicher Nutzeransturm erzeugen unterschiedliche Belastungen; eine Begrenzung kann Wartezeit außerdem auf den Client verlagern. Das Benchmark-Werkzeug von vLLM trennt die Anfragerate von der maximalen Anzahl gleichzeitiger Anfragen und stellt Metriken für die clientseitige Warteschlange bereit. Quelle: Benchmark-Parameter
-
Für jedes Feld die vollständige Auswertung festhalten. Mindestens p50/p95/p99 für TTFT, ITL und Gesamtlatenz erfassen, außerdem Durchsatz, Cache-Treffer, Präemptionen, Zeitüberschreitungen und Fehlerrate. Tests unabhängig voneinander wiederholen und Aufwärmverfahren sowie Stichprobengrößen offenlegen. Hohe Perzentile bei kleinen Stichproben besonders vorsichtig interpretieren. Änderungen an der Quantisierung erfordern zudem eine gesonderte Prüfung der Ergebnisqualität bei den jeweiligen Aufgaben: Geschwindigkeit belegt keine Korrektheit.
-
Grenzwerte festlegen, bevor Gewinne verglichen werden. Für einen interaktiven Assistenten können die erste Ausgabe und Pausen im Streaming Vorrang haben; bei einem Offline-Batch-Job kann die abgearbeitete Menge wichtiger sein. Die konkreten Grenzwerte sollten sich aus den Produktanforderungen ergeben. Wer nur erfolgreiche Anfragen zählt, die zugleich die Latenzziele erfüllen, erhält ein aussagekräftigeres Maß für die Dienstkapazität. vLLM unterstützt Goodput-Grenzwerte für TTFT, Zeit pro Ausgabe-Token und Ende-zu-Ende-Latenz. Quelle: Goodput-Option
Das Ergebnis mit der Nutzererfahrung verbinden
Ein hilfreicher Abnahmebericht sollte eine konkrete Frage beantworten: „Wie viele Anfragen mehr können wir bei unserem Anfrageaufkommen und unseren Qualitätsanforderungen pro Stunde abschließen, und wie lange warten die Nutzer mit den längsten Bearbeitungszeiten?“
Ein höherer Durchsatz ist willkommen. Zusammen mit Wartezeiten, Qualität und Fehlern zeigt er, was ein Upgrade tatsächlich verbessert.
Quellen geprüft am 19. Oktober 2026. Diese technische Analyse stützt sich auf öffentliche Benchmarks von Mitwirkenden und die offizielle Dokumentation. Die Testmatrix ist unser Vorschlag; wir haben keine unabhängigen Leistungs- oder Qualitätstests durchgeführt. Die „latest“-Seiten der Dokumentation können sich ändern. Prüfen Sie die tatsächlich eingesetzte Version.