LLM-Latenz: Ziele für Time to First Token und Token pro Sekunde bei Chat, RAG und Agenten

LLM-Latenz: Kennzahlen TTFT, Inter-Token-Latenz und Durchsatz

Die LLM-Latenz wird mit vier Zahlen beschrieben: der Zeit bis zum ersten Token (Time to First Token, TTFT), dem Abstand zwischen den Ausgabe-Token, genannt Inter-Token-Latenz (ITL) oder Zeit pro Ausgabe-Token (TPOT), der Ende-zu-Ende-Latenz je Anfrage und dem Durchsatz. Die TTFT ist die Zeit, die ein Nutzer wartet, bevor Text erscheint; der Abstand zwischen den Token bestimmt, wie schnell der Text danach fließt. Beide müssen mit einem Perzentil und mit dem Werkzeug angegeben werden, das sie gemessen hat, weil die Werkzeuge sie unterschiedlich berechnen. Für einen Chat-Assistenten sind unsere Beispielziele, unten hergeleitet, 1 s bis zum ersten Token und 100 ms je Token (10 Token pro Sekunde pro Nutzer) im 95. Perzentil.

NVIDIAs Benchmarking-Leitfaden für NIM, gelesen am 10. Oktober 2026, definiert die TTFT als „die Zeit vom Absenden der Anfrage bis zum ersten empfangenen Token, sofern die Antwort nicht leer ist“, und schreibt, dass sie „im Allgemeinen die Wartezeit der Anfrage in der Warteschlange, die Prefill-Zeit und die Netzwerklatenz einschließt“. Die ITL definiert er als „die durchschnittliche Zeit zwischen aufeinanderfolgenden Token“ und ergänzt, dass sie „auch als Zeit pro Ausgabe-Token (TPOT) bekannt ist“. Die Ende-zu-Ende-Latenz ist die TTFT plus die Generierungszeit, also die Zeit vom ersten bis zum letzten empfangenen Token.

NVIDIA NIM LLM Benchmarking Guide, Seite zu den Metriken; CLI-Referenz von vllm bench serve und Quellcode des Benchmarks; alle gelesen am 10. Oktober 2026. Die Spalte „Bestimmt durch“ ist unsere Zusammenfassung von NVIDIAs Blog zur Inferenzoptimierung vom 17. November 2023 und des Optimierungsleitfadens von vLLM.

Durchsatz je Nutzer und Systemdurchsatz beantworten unterschiedliche Fragen. Laut NVIDIAs Leitfaden „steigen die TPS des Gesamtsystems, während die TPS je Nutzer sinken, wenn die Latenz steigt“. Für die Auslegung muss eine Angabe in Token pro Sekunde sagen, welcher der beiden Werte gemeint ist.

TTFT vs. TPOT und ITL: wo vLLM und AIPerf sich unterscheiden

Die Definitionen stimmen bei TTFT und Ende-zu-Ende-Latenz überein und gehen beim Abstand zwischen den Token auseinander. NVIDIAs Leitfaden merkt an, dass sich „Werkzeuge darin unterscheiden, ob die TTFT in den Mittelwert eingeht“, und rät, „Ergebnisse nur zu vergleichen, wenn die Definitionen übereinstimmen“.

AIPerf, das Benchmarking-Werkzeug, auf das NVIDIA inzwischen verweist, berechnet die ITL je Anfrage als Ende-zu-Ende-Latenz minus TTFT, geteilt durch die Zahl der Ausgabe-Token minus eins, und gibt die Abstände zwischen allen gestreamten Chunks gesondert als Inter Chunk Latency aus. Sein Ausgabe-Token-Durchsatz je Nutzer ist 1 geteilt durch diese ITL. vllm bench serve berechnet denselben Mittelwert je Anfrage und nennt ihn TPOT, während seine ITL die Liste aller einzelnen Abstände ist, über alle Anfragen zusammengefasst. Ein ITL-Perzentil aus vLLM zeigt deshalb Stockungen, die ein ITL-Perzentil von AIPerf, aus Mittelwerten gebildet, glättet.

Auch der Startpunkt der Messung zählt. Beide Werkzeuge messen vom Client aus, ihre TTFT enthält also das Netzwerk und, wenn der Test darüber läuft, das Gateway vor dem Server. Das eigene Histogramm von vLLM im Server beginnt innerhalb des Servers und lässt beides weg, wie unser Leitfaden zu den Serving-Metriken von vLLM in Prometheus erklärt; ein Ziel, das für die eine Messung formuliert ist, lässt sich nicht an der anderen prüfen. Für Reasoning-Modelle ergänzt AIPerf die Zeit bis zum ersten Ausgabe-Token (Time to First Output Token), die es als Zeit „vom Beginn der Anfrage bis zum ersten Ausgabe-Token, das kein Reasoning-Token ist“ berechnet, also bis zu dem Punkt, an dem der Nutzer die Antwort sieht und nicht das Denken des Modells.

Was die Zeit bis zum ersten Token und die Token pro Sekunde bestimmt

Die TTFT besteht aus zwei Teilen: dem Warten in der Warteschlange und dem Prefill, der Verarbeitung des gesamten Prompts vor dem ersten Token. NVIDIAs Blog zur Inferenzoptimierung beschreibt das Prefill als „eine Matrix-Matrix-Operation, die hochgradig parallelisiert ist“ und „die GPU-Auslastung effektiv sättigt“; seine Dauer wächst also mit der Prompt-Länge und sinkt mit der Rechenleistung. NVIDIAs Benchmarking-Leitfaden ergänzt, dass „die Zeit bis zum ersten Token durch Verzögerung in der Warteschlange steigen kann“ und dass längere Eingabesequenzen die TTFT erhöhen. Ein RAG-Prompt mit mehreren abgerufenen Abschnitten kostet mehr Prefill als eine Chat-Frage, und ein Agent, der seinen wachsenden Kontext erneut sendet, trägt diese Kosten bei jedem Schritt erneut.

Der Abstand zwischen den Token entsteht im Decode, bei dem jeder Schritt die Gewichte und den KV-Cache liest. Derselbe NVIDIA-Blog nennt das „eine speichergebundene Operation“, deren Latenz von der Geschwindigkeit bestimmt wird, mit der Daten aus dem Speicher übertragen werden. Für einen einzelnen Nutzer sind die Token pro Sekunde durch die Speicherbandbreite geteilt durch die je Token gelesenen Bytes begrenzt. Nach dieser Rechnung erreicht Llama 3.3 70B in FP8 höchstens etwa 23 Token pro Sekunde auf einer RTX PRO 6000 Server Edition und etwa 68 auf einer H200 NVL, wie unser Vergleich von RTX PRO 6000 und H200 NVL für LLM-Inferenz zeigt; das sind Obergrenzen, die kein System erreicht.

Prefill und Decode teilen sich die GPU, also wägt der Scheduler das eine gegen das andere ab. In vLLM ist Chunked Prefill, wo möglich, standardmäßig aktiv, und der Scheduler „priorisiert Decode-Anfragen“. Der Optimierungsleitfaden von vLLM schreibt, dass kleinere Werte von max_num_batched_tokens „eine bessere ITL erreichen, weil weniger Prefills die Decodes verlangsamen“, während „höhere Werte eine bessere Zeit bis zum ersten Token erreichen“. Ein Server, der auf RAG-Prompts abgestimmt ist, und ein Server, der auf schnelles Streaming abgestimmt ist, werden unterschiedlich konfiguriert.

Latenz und gleichzeitige Nutzer auf einer GPU

Parallelität erhöht den Gesamtdurchsatz und senkt die Geschwindigkeit je Nutzer, bis die GPU sättigt. NVIDIAs Seite zu den Parametern hält fest, dass „der Durchsatz im Allgemeinen nahe der maximalen Batch-Größe sättigt, während die Latenz stetig steigt“. Jenseits dieses Punkts fügen weitere gleichzeitige Anfragen der TTFT Wartezeit hinzu und bringen keinen zusätzlichen Durchsatz.

Die Zahl der Nutzer, die eine Karte bedient, hängt daher vom Latenzziel ebenso ab wie vom Speicher. Der Speicher entscheidet, wie viele Sitzungen in den KV-Cache passen; unser Leitfaden dazu, wie viele Nutzer eine RTX PRO 6000 bedient, enthält diese Rechnung und die Messreihe über Batch-Größen aus NVIDIAs Tuning-Leitfaden für TensorRT-LLM. Das Latenzziel entscheidet, wie viele dieser Sitzungen gleichzeitig laufen können und es trotzdem einhalten. Liegt das Ziel je Nutzer über der Obergrenze für einen einzelnen Stream, hilft keine Batch-Größe: Ein Ziel von 40 ms entspricht 25 Token pro Sekunde, mehr als die Obergrenze von etwa 23 für ein 70B-Modell in FP8 auf einer RTX PRO 6000 Server Edition. NVFP4-Gewichte, ein kleineres Modell, eine Karte mit mehr Bandbreite, Tensor-Parallelismus über zwei Karten oder spekulatives Dekodieren ändern diese Zahl; mehr Parallelität ändert sie nicht.

Beispielziele für die Latenz bei Chat, RAG, Agenten und Batch-Jobs

Ziele ergeben sich aus dem Anwendungsfall, und die Werte unten sind unsere Beispiele, keine Empfehlungen von Herstellern. Wir haben sie auf Bucket-Grenzen der Histogramme von vLLM gelegt, damit das Monitoring im Produktivbetrieb genau zählen kann, wie viele Anfragen sie einhalten. Unser Leitfaden zu den Nutzern je RTX PRO 6000 setzt das mittlere stille Lesen nach einer Meta-Analyse von 2019 bei etwa 5,3 Token pro Sekunde an; ein Stream mit 10 Token pro Sekunde ist also schneller als ein durchschnittlicher Leser. Die Ziele je Token geben wir als TPOT an, den Mittelwert je Anfrage, den die Goodput-Prüfung von vLLM verwendet und den AIPerf als ITL ausgibt.

Beispielziele und Formen der Anfragen sind unsere, gelegt auf die TTFT-Bucket-Grenzen von vLLM bei 1 und 2,5 s und seine Bucket-Grenzen für Inter-Token-Latenz und TPOT bei 50 und 100 ms; testen Sie sie mit Ihren Nutzern. NVIDIAs Benchmarking-Leitfaden für NIM führt Retrieval unter Zusammenfassung, mit einer ISL um 1.000 und einer OSL um 100 Token.

Rechnen Sie die Ziele in Ende-zu-Ende-Zeiten um, bevor Sie sie vereinbaren. Eine Chat-Antwort von 400 Token mit 1 s bis zum ersten Token und 100 ms je Token dauert 1 + 399 × 0,1, also etwa 41 s, wobei der Nutzer ab der ersten Sekunde mitliest. Eine Agentenaufgabe mit 8 Schritten, jeder mit 1 s bis zum ersten Token und 150 Ausgabe-Token zu je 50 ms, dauert 8 × (1 + 149 × 0,05), etwa 68 s vor den Tool-Aufrufen; bei 100 ms je Token sind es etwa 127 s. Ein Reasoning-Modell, das 1.500 Token lang bei 50 ms nachdenkt, zeigt sein erstes Antwort-Token nach etwa 75 s plus TTFT. Für Agenten und Reasoning-Modelle wiegt der Abstand zwischen den Token schwerer als für Chat, weil die Zwischen-Token ungelesen bleiben und jedes davon die Wartezeit verlängert. Unser Leitfaden zur GPU-Auslegung für KI-Agenten zählt die Aufrufe und Token je Aufgabe.

Wir legen Inferenzserver nach Modellgröße und gleichzeitigen Nutzern aus, mit Konfiguration und Angebot innerhalb eines Werktages. Schicken Sie uns Ihre Beispielziele, das Modell und die Spitzenzahl der Anfragen in Bearbeitung über das Formular unten.

LLM-Latenz messen mit vllm bench serve und AIPerf

Ein Lasttest zeigt, ob eine GPU die Ziele bei einer bestimmten Parallelität einhält. vllm bench serve wird mit vLLM ausgeliefert; --percentile-metrics steht standardmäßig auf ttft, tpot und itl, und --metric-percentiles standardmäßig nur auf dem 99. Perzentil. --goodput nimmt Ziele als Paare aus Metrik und Wert in Millisekunden entgegen und zählt die Anfragen pro Sekunde, die alle davon einhalten. AIPerf wird mit pip install aiperf installiert, Release 0.13.0 vom 24. September 2026, und läuft als aiperf profile mit --streaming für TTFT und ITL und --concurrency für eine feste Zahl an Anfragen in Bearbeitung. Die Dokumentation von GenAI-Perf hält fest, dass es „schrittweise eingestellt wird“, und schreibt: „Für neue Performance-Benchmarks verwenden Sie bitte stattdessen AIPerf“. Unser Leitfaden dazu, was ein privater KI-Pilot messen sollte, behandelt die Datensätze und Flags, mit denen Sie Ihre eigenen Prompts erneut abspielen.

1. Schreiben Sie jedes Ziel als Metrik, Perzentil und Wert, und geben Sie an, ob es am Client oder im Server gemessen wird.
2. Spielen Sie Prompts mit den Eingabe- und Ausgabelängen Ihres Anwendungsfalls ab; zufällige Prompts mit 1.024 Token und Antworten mit 128 Token, die Voreinstellung von vLLM, passen zu keinem der Anwendungsfälle oben.
3. Legen Sie die Zahl der Anfragen in Bearbeitung mit --max-concurrency fest und erhöhen Sie sie schrittweise, 1, 2, 4, 8 und so weiter; ohne diese Option sendet vLLM mit seiner Standard-Anfragerate inf alle Anfragen zum Zeitpunkt 0.
4. Ergänzen Sie --goodput ttft:1000 tpot:100 und --percentile-metrics ttft,tpot,itl,e2el mit --metric-percentiles 50,95,99.
5. Nehmen Sie die höchste Parallelität, bei der die 95. Perzentile die Ziele einhalten und der Goodput nahe am Anfragedurchsatz bleibt, und halten Sie dazu GPU, Engine-Version und Einstellungen fest.

Der Goodput von vLLM prüft die TPOT, also den Mittelwert je Anfrage, sodass eine Anfrage mit einer langen Stockung trotzdem als gut zählen kann; lesen Sie die ITL-Perzentile daneben. NVIDIAs Leitfaden rät, „für die meisten Benchmarks Parallelität zu bevorzugen“, weil bei einer festen Anfragerate offene Anfragen „unbegrenzt wachsen können“, sobald mehr Anfragen eintreffen, als das System bedient. Ergebnisse lassen sich nur auf denselben GPU-Typ und dieselben Engine-Einstellungen übertragen.

In unserer Leistung Private AI/ML liefert das technische Assessment einen Pilotplan mit Metriken; der Preis steht vor Beginn fest. Beschreiben Sie im Formular unten den Anwendungsfall, den Sie zuerst messen würden, und die Ziele, die Sie im Blick haben.

Was wir liefern

Wir bauen KI-Server auf Bestellung für Inferenz und RAG, mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern, und wir liefern die Karten auch separat für Server, die Sie bereits betreiben. Für Latenzziele fällt die Wahl zwischen Bandbreite und Speicher: die H200 NVL mit 141 GB HBM3e bei 4,8 TB/s, die RTX PRO 6000 Blackwell in allen drei Editionen mit 96 GB sowie die L40S und die L4 für kleinere Modelle. Karten und Server liefern wir mit Herstellergarantie, Lizenzen für NVIDIA AI Enterprise auf derselben Rechnung wie die Hardware, unter einem EU-Vertrag. Wenn Sie die Ziele und einen Pilotplan mit Metriken für sich ausarbeiten lassen wollen, ist das unsere Leistung Private AI/ML, mit dem Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ