Viele Tokens, lange Wartezeit

Kurzfassung: Eine hohe Gesamt-Tokenrate sagt wenig darüber, wie schnell eine einzelne KI-Anfrage unter Last beantwortet wird. NVIDIA dokumentiert an einem konkreten Dienst, wie die Wartezeit mit der Zahl gleichzeitiger Anfragen steigt. Für IT und Einkauf gehört deshalb eine gemeinsame Leistungszusage in die Bestellung: Wie viele Anfragen erhalten bei welcher Eingabelänge rechtzeitig den ersten Inhalt und anschließend eine ausreichend schnelle Ausgabe?

Die Vorführung läuft mit einer einzigen Anfrage. Der Text erscheint rasch, der Anbieter nennt eine hohe Zahl von Tokens pro Sekunde. Später arbeiten mehrere Teams gleichzeitig mit dem Dienst. Jetzt bleibt das Antwortfeld zunächst leer. Beide Beobachtungen können zu derselben technisch funktionierenden Anlage gehören. Der Unterschied liegt in der Last, unter der ihre Leistung betrachtet wird.

Tokens sind die Textbausteine, die ein Sprachmodell verarbeitet und ausgibt. Wer Inferenzkapazität einkauft, bestellt deshalb nicht bloß eine Menge solcher Bausteine je Sekunde. Bei einer interaktiven Anwendung bezahlt er auch dafür, dass einzelne Anfragen unter vereinbarter Belastung rechtzeitig bedient werden. Diese Eigenschaft lässt sich aus einem Gesamtwert nicht ablesen.

Die Anlage arbeitet, der einzelne Nutzer wartet

NVIDIAs Dokumentation zur Leistung der USD Code API liefert ein anschauliches Beispiel. Die Seite, zuletzt aktualisiert am 6. November 2026, beschreibt einen Benchmark auf vier H100-GPUs. In der Tabelle für Eingabe- und Ausgabelängen von jeweils 1.000 Tokens steigt die durchschnittliche Zeit bis zum ersten Token von 1,26 Sekunden bei einer gleichzeitigen Anfrage auf 14,06 Sekunden bei 25 gleichzeitigen Anfragen. Bei einer Gleichzeitigkeit von 100 nennt die Tabelle 84,61 Sekunden.

Das sind Herstellerangaben zu einem bestimmten Aufbau, keine hier nachgemessenen Werte und kein Vergleich heutiger Modellanbieter. Das Aktualisierungsdatum belegt auch nicht, wann der Versuch durchgeführt wurde. Der Fall zeigt einen engeren, für die Beschaffung brauchbaren Unterschied: Derselbe Dienst hat je nach Belastung eine andere Antwortcharakteristik.

Die NIM-Dokumentation zu Inferenzmetriken erläutert den Zusammenhang. Die Gesamt-Tokenrate erfasst die Ausgaben aller gleichzeitig bearbeiteten Anfragen. Mit steigender Gleichzeitigkeit kann diese Rate zunächst zunehmen, bis die Anlage ihre Sättigung erreicht. Währenddessen kann die Leistung aus Sicht des einzelnen Nutzers sinken. Eine möglichst hohe Gesamtausgabe und eine angenehmere Bedienung sind daher nicht dieselbe Optimierungsaufgabe.

Das rechtfertigt kein pauschales Urteil gegen gemeinschaftlich genutzte Infrastruktur. Für eine nächtliche Stapelverarbeitung kann hoher Gesamtdurchsatz genau die richtige Leistung sein. Wer während eines Kundengesprächs auf eine Auskunft wartet, benötigt dagegen einen rechtzeitigen Antwortbeginn. Beide Anwendungen können dasselbe Modell verwenden und trotzdem unterschiedliche Kapazitätsangebote brauchen.

Drei Angaben beschreiben den Antwortverlauf

Die erste Größe ist die Zeit bis zum ersten Token, häufig TTFT genannt. Sie beschreibt die Wartezeit zwischen dem Absenden der Anfrage und dem ersten ausgegebenen Inhalt, nicht bloß einem leeren Empfangssignal. NVIDIA beschreibt darin üblicherweise auch Warteschlange, Verarbeitung der Eingabe und Netzlaufzeit. Ein langer Prompt kann den Start verzögern, selbst wenn die spätere Ausgabe zügig läuft.

Die zweite Größe betrifft die Ausgabe danach. Wie schnell folgen weitere Tokens, und stockt der Text zwischendurch? Ein früh sichtbares erstes Wort hilft wenig, wenn die eigentliche Auskunft nur langsam wächst. Umgekehrt kann eine hohe Ausgaberate eine lange anfängliche Wartezeit im Erleben des Nutzers nicht einfach aufheben.

Die dritte Angabe ist die Belastung, unter der diese Zeiten gelten. Gemeint sind gleichzeitige aktive Anfragen, nicht die Zahl registrierter Beschäftigter. Hundert zugelassene Nutzer können den Dienst nacheinander oder nahezu gleichzeitig aufrufen. Das sind verschiedene Betriebsfälle. Zusätzlich macht es einen Unterschied, ob Anfragen regelmäßig eintreffen oder nach einer Besprechung gebündelt starten.

Auch ähnlich benannte Messwerte sind nicht automatisch identisch. Die GenAI-Perf-Dokumentation beschreibt eine nutzerbezogene Ausgaberate für die Generierungsphase ohne das erste Token. Die ältere NIM-Metrikseite erläutert dagegen auch eine nutzerbezogene Rate über die gesamte Anfragezeit. Wer Angebote vergleicht, muss daher Anfang, Ende und gezählte Tokens der Messung kennen. Der Name „Tokens pro Sekunde und Nutzer“ reicht nicht.

Die Bestellung braucht eine Lastkurve

Eine sinnvolle Leistungsbeschreibung verbindet diese Angaben, statt sie in getrennten Höchstwerten stehen zu lassen. Der Anbieter könnte sonst eine hohe Gleichzeitigkeit für den Gesamtdurchsatz und eine niedrige Gleichzeitigkeit für die beworbene Antwortzeit wählen. Beide Zahlen wären möglicherweise richtig, ihre Kombination aber nie gemessen worden.

Als abgeleitete Empfehlung sollten IT und Einkauf deshalb mehrere Laststufen unter denselben Aufgabenbedingungen prüfen lassen: zunächst wenige gleichzeitige Anfragen, dann die erwartete Normalbelastung und schließlich eine begründete Spitze. Zu jeder Stufe gehören Eingabe- und Ausgabelängen, Modellstand, Betriebsumgebung sowie Angaben dazu, ob wiederkehrende Eingabeteile bereits im Cache liegen. Ein Test mit ständig wiederholter kurzer Eingabe beantwortet nicht dieselbe Frage wie ein wechselnder Bestand langer Kundendokumente.

Der Fachbereich legt fest, welche Wartezeit für die Anwendung noch brauchbar ist. Der technische Test zeigt anschließend, bei welcher Last diese Grenze gehalten wird. Dabei sind die langsamen Fälle wichtig. Das 95. Perzentil der Wartezeit bezeichnet einen Wert, den 95 Prozent der betrachteten Messungen nicht überschreiten. Es sagt nicht, dass jede einzelne Anfrage rechtzeitig fertig wird. Fehler, abgebrochene Anfragen und verworfene Last gehören gesondert in den Bericht, statt aus der Erfolgsstatistik zu verschwinden.

Eine feste Zahl gleichzeitiger Anfragen allein genügt ebenfalls nicht. Bei einem solchen Test kann nach jeder fertigen Antwort sofort eine neue Anfrage folgen. Wird der Dienst langsamer, sinkt dann zugleich die Zahl neu beginnender Anfragen pro Sekunde. Ein zusätzlicher Test mit vorgegebenem Ankunftsmuster kann zeigen, was bei einer realen Anfragewelle geschieht. Welche Prüfung erforderlich ist, folgt aus dem vorgesehenen Betrieb, nicht aus einer universellen Benchmarkvorschrift.

Ein anderes Lastprofil kann die bessere Investition sein

Aus den Messungen kann eine größere Anlage folgen. Sie kann aber auch unnötig sein. Vielleicht lassen sich umfangreiche Hintergrundaufträge zeitlich verschieben, damit interaktive Anfragen nicht mit ihnen konkurrieren. Vielleicht benötigt nur eine kleine Nutzergruppe eine kurze Startzeit. Oder die Anwendung kann den Umfang einzelner Eingaben begrenzen, ohne fachlich notwendige Informationen zu verlieren. Diese Möglichkeiten sind zu prüfen; die NVIDIA-Beispiele belegen ihre Wirkung im eigenen Betrieb nicht.

Auch eine hohe laufende Tokenrate ist nicht für jede Aufgabe gleich wertvoll. Bei einer langen Berichtserstellung zählt möglicherweise vor allem die vollständige Fertigstellungszeit. Bei einer kurzen Rückfrage im Kundentermin kann der Antwortbeginn stärker ins Gewicht fallen. Die passende Beschaffung finanziert die benötigte Kombination, nicht automatisch den höchsten isolierten Messwert.

Der nächste sinnvolle Schritt ist daher eine Lastprobe mit repräsentativen Anfragen und einer vorher festgelegten Wartegrenze. Ihr Ergebnis sollte sich als konkreter Satz bestellen lassen: Unter diesen Eingaben und dieser gleichzeitigen Belastung wird der vereinbarte Antwortverlauf innerhalb der festgelegten statistischen Grenzen erreicht. Erst damit wird aus einer beeindruckenden Gesamt-Tokenzahl eine vergleichbare Kapazitätszusage.