Durchsatz (LLM-Serving)

Ausgabe-Durchsatz vs. Systemdurchsatz

Ein Benchmark, der den Ausgabe-Durchsatz angibt, meint die Token, die nach dem ersten Token zu einem einzelnen Request gestreamt werden. Ein Beispiel sind die 713 tok/s, die wir mit gpt-oss-120b messen. Diese Zahl bestimmt, wie schnell ein Nutzer eine vollständige Antwort erhält. Der Systemdurchsatz ist etwas anderes. Die Fachliteratur definiert ihn als die Zahl der Ausgabe-Token pro Sekunde, die ein Inferenz-Server über alle Nutzer und Requests hinweg erzeugt. Benchmarking-Dokumentationen nennen ihn "TPS pro System", im Gegensatz zu "TPS pro Nutzer". Unter Last bewegen sich beide Werte in entgegengesetzte Richtungen. Mit steigender Parallelität nähert sich der Systemdurchsatz der Sättigung der Hardware, während der Ausgabe-Durchsatz jedes einzelnen Nutzers sinkt.

Warum Batching den Zielkonflikt erzeugt

Die Decode-Phase der Inferenz ist durch die Speicherbandbreite begrenzt: Für jedes erzeugte Token muss die Hardware die Modellgewichte aus dem Speicher lesen. Batching verteilt diesen Aufwand. Die Gewichte werden einmal geladen, und im selben Durchlauf kommen die Requests vieler Nutzer voran. Die Continuous-Batching-Benchmarks von Anyscale zeigten bis zu 23x mehr Durchsatz als die naive Abarbeitung Request für Request.

Der Haken: Alle Requests im Batch teilen sich dieselbe Speicherbandbreite. Ein größerer Batch bedeutet also langsamere Token für jeden Nutzer. Databricks hat diesen Zielkonflikt konkret gemessen: Bei Batch-Größe 64 auf einer A100 stieg der Durchsatz auf das 14-Fache, die Latenz jedes Requests aber auf das 4-Fache. Der Systemdurchsatz ist letztlich Sache des Anbieters. Er bestimmt dessen Kosten pro Token und Kapazitätsplanung. Als Nutzer erleben Sie nur den Ausgabe-Durchsatz Ihres eigenen Requests. Wo dieser landet, entscheidet die Batching-Strategie des Anbieters.

Worauf es in der Praxis ankommt

Orientieren Sie sich beim Vergleich von Anbietern an den Werten pro Request: Ausgabe-Durchsatz und Inter-Token-Latenz unter realistischer Last. Eine plakative Zahl zum Systemdurchsatz sagt nichts darüber, wie schnell Ihre eigenen Requests bedient werden. Auch die Architektur zählt. Hardware, die schon bei kleinen Batch-Größen hoch ausgelastet ist, kann pro Request schnell sein, ohne auf aggressives Batching angewiesen zu sein. Genau das ist der Grundgedanke der Dataflow-Architektur, auf der unsere Plattform läuft.