Continuous Batching

Wenn du einem Chatbot eine Frage stellst, landet sie auf einem Server mit spezialisierten Rechenchips. Diese Chips arbeiten am schnellsten, wenn sie viele Anfragen auf einmal verrechnen statt eine nach der anderen. Eine solche Gruppe gleichzeitig bearbeiteter Anfragen nennt man einen Stapel, auf Englisch Batch. Beim klassischen Vorgehen wartet der Server, bis alle Anfragen im Stapel fertig sind, und beginnt erst dann den nächsten. Continuous Batching bricht mit dieser starren Regel: Sobald eine einzelne Anfrage abgeschlossen ist, rückt sofort eine wartende nach. Der Stapel wird also laufend nachgefüllt, statt komplett ausgetauscht zu werden.

Warum Grafikchips sonst Däumchen drehen

Die Rechenchips in KI-Rechenzentren sind extrem teuer. Ein einzelner Beschleuniger kostet leicht so viel wie ein Mittelklassewagen. Jede Sekunde, in der er nicht rechnet, ist verlorenes Geld. Genau dieses Problem entsteht beim starren Stapelverfahren.

Der Grund liegt in den sehr unterschiedlichen Antwortlängen. Eine Anfrage lautet vielleicht nur: Wie spät ist es in Tokio? Die Antwort ist nach zehn Wörtern fertig. Eine andere Anfrage verlangt eine zweiseitige Zusammenfassung eines Textes. Steckt beides im selben Stapel, blockiert die kurze Anfrage einen Platz, obwohl sie längst erledigt ist. Der Chip rechnet dann für einen leeren Platz weiter.

In der Praxis kann das den Durchsatz halbieren oder schlimmer. Betreiber messen ihn in Tokens pro Sekunde, also in Textbausteinen pro Sekunde. Continuous Batching hebt diesen Wert je nach Auslastung um ein Vielfaches. Für die Nutzer heißt das kürzere Wartezeiten, für den Betreiber niedrigere Kosten pro Antwort. Deshalb gehört das Verfahren heute zur Standardausstattung jedes ernsthaften KI-Servers.

Das Nachrücken im Stapel

Ein Sprachmodell erzeugt seine Antwort nicht auf einen Schlag. Es produziert ein Textstück nach dem anderen, jeweils in einem Rechenschritt. Der Server kann deshalb nach jedem einzelnen Schritt neu entscheiden, wer im Stapel sitzt. Genau an dieser Stelle greift Continuous Batching ein.

Ein Verwaltungsprogramm, der Scheduler, führt eine Warteschlange aller offenen Anfragen. Nach jedem Rechenschritt prüft er, welche Anfragen fertig sind, und wirft sie aus dem Stapel. Die frei gewordenen Plätze füllt er sofort mit den nächsten Wartenden. Ein passendes Bild ist ein Sessellift: Wer oben aussteigt, gibt seinen Sitz frei, und unten steigt gleich der Nächste ein. Der Lift hält dafür nie an.

Damit das aufgeht, muss der Server für jede laufende Anfrage Zwischenergebnisse im Speicher halten. Diese Zwischenablage heißt KV-Cache und begrenzt, wie viele Anfragen gleichzeitig laufen können. Reicht der Speicher nicht, muss der Scheduler eine Anfrage pausieren und später fortsetzen. Continuous Batching löst also das Zeitproblem, nicht das Speicherproblem. Verwechseln sollte man es außerdem nicht mit dem einfachen dynamischen Batching, das nur die Stapelgröße vor dem Start anpasst.

Wo die Technik im Einsatz ist

Direkt sehen wirst du Continuous Batching nie, denn es läuft tief im Serverraum. Bemerkbar macht es sich als Antwortgeschwindigkeit. Wenn ein Chatbot zur Stoßzeit trotzdem flüssig Wort für Wort schreibt, steckt meist ein solches Verfahren dahinter. Ohne es würden Antworten bei hoher Last spürbar ruckeln.

In Nachrichten und Fachtexten begegnet der Begriff vor allem bei Software zum Betrieb von Sprachmodellen. Bekannte Beispiele sind vLLM, TensorRT-LLM von Nvidia und Text Generation Inference von Hugging Face. Diese Programme werben ausdrücklich mit Continuous Batching als Hauptmerkmal. Nvidia nennt die eigene Variante In-Flight Batching, gemeint ist dasselbe Prinzip.

Auch bei Preisen von KI-Anbietern spielt das Thema mit. Wer eine Schnittstelle nutzt, zahlt pro Textbaustein, und der Preis hängt an den Betriebskosten. Bessere Auslastung der Chips drückt diese Kosten. Ein Teil der Preisstürze bei KI-Diensten der letzten Jahre geht auf solche Optimierungen zurück, nicht auf neue Modelle.