Batch-Inferenz-Durchsatz-Rechner
Eingaben
| Batchgröße | 32 |
|---|---|
| Ausgabe-Tokens pro Anfrage | 256 |
| Batch-Abschlusszeit | 5 s |
Batch-Inferenz-Durchsatz-Rechner
Wandelt eine gemessene Batch-Abschlusszeit in den Gesamtdurchsatz in Tokens pro Sekunde, die Geschwindigkeit pro Anfrage und Anfragen pro Sekunde um — der Kompromiss zwischen Durchsatz und Latenz beim gebatchten LLM-Serving.
Eingaben
Batch
Ergebnisse
Geben Sie einen Wert ein, um die Ergebnisse zu sehen.
Details
Batch-Inferenz-Durchsatz
Gebatchte Inferenz ist die Methode, mit der produktive Sprachmodell-Server eine hohe Auslastung erreichen: Statt eine Anfrage nach der anderen zu decodieren, verarbeiten sie viele gemeinsam. Da die Gewichte des Modells einmal gelesen und für die gesamte Gruppe wiederverwendet werden, steigt die Gesamtausgabe des Servers mit der Batchgröße stark an — doch jede einzelne Anfrage wartet auf den Abschluss des Batches. Dieser Rechner trennt diese beiden Sichtweisen und wandelt eine gemessene Batch-Abschlusszeit in den Gesamtdurchsatz, die Geschwindigkeit pro Anfrage und eine Anfragerate um.
Der Kompromiss beim Batching
Das autoregressive Decodieren ist speichergebunden: Jeder Schritt liest jedes Gewicht, um ein Token zu erzeugen. Wenn nur eine einzelne Anfrage bearbeitet wird, dient fast der gesamte Speicherverkehr nur einem Nutzer. Fasst man mehrere Anfragen zu einem Batch zusammen, erzeugt dasselbe Lesen eines Gewichts gleichzeitig ein Token für jede Anfrage, sodass die Gesamt-Token-Rate mit der Batchgröße steigt, während die Bandbreitenkosten kaum zunehmen. Der Haken ist die Latenz — eine Anfrage kann den Batch erst verlassen, wenn der Batch-Schritt abgeschlossen ist, der sie enthält, sodass sich die Geschwindigkeit pro Anfrage nicht verbessert und mit wachsenden Batches leicht sinken kann.
Die Formeln
Aus der Batchgröße , den Ausgabe-Tokens pro Anfrage und der gemessenen Batch-Abschlusszeit :
vaggvreqR=tbB×Nout=tbNout=tbBDabei ist der Gesamtdurchsatz, der Durchsatz pro Anfrage und die Anzahl der abgeschlossenen Anfragen pro Sekunde. Der Gesamtdurchsatz ist schlicht die Geschwindigkeit pro Anfrage multipliziert mit der Batchgröße.
Rechenbeispiel
Ein Server decodiert einen Batch von 32 Anfragen, die jeweils 256 Tokens erzeugen, und der Batch ist nach 5 Sekunden abgeschlossen:
vaggvreqR=532×256=1638.4 tokens/s=5256=51.2 tokens/s=532=6.4 requests/sDer Betreiber sieht mehr als 1.600 Tokens pro Sekunde aus dem Server fließen, doch jeder Nutzer liest mit etwa 51 Tokens pro Sekunde. Eine Verdopplung des Batches auf 64 — sofern der Speicher es zulässt und die Abschlusszeit nahe bei 5 Sekunden bleibt — würde den Gesamtdurchsatz etwa verdoppeln, während der Wert pro Anfrage unverändert bliebe.
Die Wahl der Batchgröße
Der Gesamtdurchsatz steigt mit der Batchgröße nur, solange die Arbeit speichergebunden bleibt. Sobald der Batch die Rechenleistung sättigt oder der Key-Value-Cache den Gerätespeicher erschöpft, wächst die Abschlusszeit schneller als der Batch und die Latenz pro Anfrage verschlechtert sich. Das praktische Ziel ist der größte Batch, der die Latenz pro Anfrage akzeptabel hält, solange der Speicher noch ausreicht — gefunden durch Messung der Abschlusszeit bei mehreren Batchgrößen. Reale Server verwenden zudem kontinuierliches Batching, bei dem Anfragen in jedem Schritt statt als feste Gruppe hinzukommen und ausscheiden, was den dauerhaften Durchsatz weiter erhöht. Für die Single-Stream-Obergrenze, die festlegt, siehe den Inferenz-Durchsatz-Rechner; für die Kapazität auf Flottenebene über viele Replikate hinweg siehe den Rechner für effektive Tokens pro Sekunde.
Häufig gestellte Fragen (FAQ)
Warum ist der Gesamtdurchsatz so viel höher als der Durchsatz pro Anfrage?
Der Gesamtdurchsatz zählt jedes Token, das der Server über alle Anfragen im Batch hinweg ausgibt, während der Durchsatz pro Anfrage das ist, was ein einzelner Nutzer erfährt. Batching liest jedes Modellgewicht einmal und nutzt es für die gesamte Gruppe wieder, sodass die insgesamt bedienten Tokens etwa proportional zur Batchgröße steigen.
Die einzelne Anfrage muss jedoch weiterhin auf den Abschluss des Batches warten, sodass sich ihre wahrgenommene Geschwindigkeit nicht verbessert — und mit wachsendem Batch sogar leicht sinken kann. Dies ist der zentrale Kompromiss des gebatchten Servings: Durchsatz für den Betreiber gegen Latenz für den Nutzer.
Ist ein größerer Batch immer besser?
Nur bis zu einem gewissen Punkt. Der Gesamtdurchsatz steigt mit der Batchgröße, solange die Arbeit speichergebunden bleibt; sobald der Batch jedoch die Rechenleistung sättigt oder der Key-Value-Cache den Speicher erschöpft, wächst die Abschlusszeit schneller als der Batch und die Latenz pro Anfrage leidet.
Der praktische optimale Punkt ist der größte Batch, der die Latenz pro Anfrage innerhalb des Ziels hält, solange der Speicher noch ausreicht — er wird durch Messung der Abschlusszeit bei mehreren Batchgrößen gefunden.
Wie verändert kontinuierliches Batching dies?
Dieser Rechner modelliert einen festen Batch, der gemeinsam beginnt und endet. Moderne Server verwenden kontinuierliches (In-Flight-)Batching, bei dem neue Anfragen in jedem Schritt hinzukommen und fertige den Batch verlassen, sodass der Beschleuniger auch bei unterschiedlichen Sequenzlängen ausgelastet bleibt.
Das hebt den dauerhaften Gesamtdurchsatz über die Schätzung für den festen Batch, doch derselbe Kompromiss gilt: Die Gesamtzahl der Tokens pro Sekunde verbessert sich, während jede einzelne Anfrage durch die Decodiergeschwindigkeit begrenzt bleibt.
Haftungsausschluss
Die Schätzungen setzen voraus, dass alle Anfragen im Batch die gleiche Anzahl von Tokens erzeugen und gemeinsam beginnen. Reale Arbeitslasten mischen Sequenzlängen und verwenden kontinuierliches Batching, sodass der gemessene Gesamtdurchsatz abweichen wird. Führen Sie vor der Kapazitätsplanung Benchmarks bei mehreren Batchgrößen auf der Zielhardware durch.