vLLM Batching: Wie Continuous Batching den Durchsatz erhöht

Beim vLLM Batching sorgt Continuous Batching dafür, dass eine gemeinsam genutzte GPU zwischen den Generierungsschritten neue Anfragen aufnehmen kann. So bleibt nach dem Ende kurzer Aufgaben keine Kapazität ungenutzt, während lange Aufgaben noch laufen. Die grundlegende Orca-Veröffentlichung von Yu et al., erschienen 2022 auf der OSDI, beschreibt diese Änderung der Ablaufplanung. Bei gleichzeitig eintreffenden Anfragen kann sie die Gesamtzahl der erzeugten Tokens pro Sekunde erhöhen. Ein stärker ausgelasteter Server garantiert allerdings nicht jedem Nutzer eine schnellere Antwort.

Für einen gemeinsam genutzten Modellserver zählt vor allem eines: mehr erledigte Arbeit innerhalb der vorgegebenen Antwortzeiten. Ein Durchsatzdiagramm ohne Latenzziel verrät nicht, wie viele Kunden der Server mit angenehmen Antwortzeiten bedienen kann.

Die unten aufgeführten Serverfunktionen und Einstellmöglichkeiten wurden am 25. Oktober 2026 anhand der aktuellen Herstellerdokumentation geprüft. Das Ablaufbeispiel veranschaulicht das Prinzip; es ist kein Hardwarebenchmark.

Wie funktioniert Continuous Batching?

Continuous Batching verändert die aktive Gruppe, während die Textgenerierung weiterläuft. Eine abgeschlossene Anfrage scheidet aus; eine wartende kann nachrücken, sobald der Scheduler Kapazität dafür hat. Das Verfahren wird auch als In-flight Batching oder Iteration-level Batching bezeichnet.

Ein großes Sprachmodell, kurz LLM, verarbeitet zunächst den Prompt in der Prefill-Phase und erzeugt anschließend in der Decode-Phase die Fortsetzung. Beim üblichen autoregressiven Decoding erzeugt jede aktive Anfrage pro Generierungsschritt ihr nächstes Token, also ein Textstück. Der Scheduler legt fest, welche Anfragen am nächsten Schritt teilnehmen. Der Leitfaden zur LLM-Inferenz erklärt diese Phasen genauer.

Als Bild hilft ein großer Tisch im Restaurant. Bei festen Gruppen darf die nächste erst Platz nehmen, wenn die vorherige vollständig fertig ist. Bei laufender Nachbesetzung kann ein neuer Gast einen freien Stuhl nutzen, während andere noch essen. Alle teilen sich den Tisch, aber jede Mahlzeit bleibt eigenständig.

Das Bild hat eine Grenze: Ein GPU-Scheduler muss zusätzlich die Prompt-Verarbeitung und die Speicherzuweisung einplanen. Ein freier Stuhl bedeutet deshalb nicht, dass jede wartende Anfrage sofort nachrücken kann.

Was hat Orca beigetragen?

Orca verlegte die Planungsgrenze von der vollständigen Anfrage auf eine einzelne Iteration. Die OSDI-Veröffentlichung von Gyeong-In Yu und Kollegen aus dem Jahr 2022 beschreibt, wie die Ausführungsengine jeweils für eine Modelliteration aufgerufen wird und der Scheduler die Zusammensetzung des Batches danach erneut prüft.

Das ergänzende Verfahren „Selective Batching“ bündelt ausgewählte Modelloperationen. Gleichzeitig berücksichtigt es die unterschiedlichen bisherigen Tokenfolgen, die Attention benötigt – jene Operation, die ein Token mit seinem vorangegangenen Kontext verknüpft. Zusammen ermöglichen die beiden Verfahren, Anfragen unterschiedlicher Länge verschachtelt zu verarbeiten. Auch die Batchgröße und der verfügbare Key-Value-Speicher gehen in der Veröffentlichung als Grenzen der Ablaufplanung ein. Zur Orca-Veröffentlichung.

Verändert wird damit das System, das das Modell bereitstellt. Das Modell muss dafür nicht darauf trainiert werden, mehreren Personen innerhalb eines einzigen Gesprächs zu antworten.

Statisches, dynamisches und kontinuierliches Batching im Vergleich

Entscheidend ist, wann eine neue Anfrage in die laufende Verarbeitung einsteigen kann. Dass ein Server gleichzeitige HTTP-Verbindungen annimmt, belegt noch kein Continuous Batching bei der Modellausführung.

NVIDIAs Triton-Dokumentation zum Batching beschreibt herkömmliches dynamisches Batching samt Einstellungen für Batchgröße und Wartezeit in der Warteschlange. Dabei geht es um eine andere Planungsentscheidung als beim Austausch von Anfragen während der Textgenerierung eines LLM.

Dynamisches Batching bei vLLM: Der Zeitpunkt entscheidet

vLLM, eine Engine zur Bereitstellung von LLMs, dokumentiert Continuous Batching. „Dynamic Batching“ ist die weniger eindeutige Bezeichnung. Auch Hugging Face spricht in seiner Erklärung zu Continuous Batching von Dynamic Scheduling oder Dynamic Batching, wenn abgeschlossene Prompts während der Generierung ersetzt werden. Maßgeblich ist deshalb, ob die Engine zwischen Generierungsschritten neue Arbeit aufnimmt; die Bezeichnung allein reicht nicht.

Streaming ist wiederum eine eigene Eigenschaft. Ein Server kann Tokens an einen Client streamen und dabei die Zusammensetzung des ausgeführten Batches unverändert lassen. Der hier beschriebene Vorteil besteht darin, dass neue Anfragen die Kapazität abgeschlossener Anfragen nutzen können.

Ein Ablaufbeispiel

Eine kurze Aufgabe kann nutzbare Kapazität freigeben, während eine längere weiterläuft. Angenommen, ein Server hat zwei Decode-Plätze. Anfrage A benötigt noch 2 Schritte, B noch 4, und C wartet mit einem Arbeitsumfang von 2 Schritten. Prefill, Planungsaufwand und unterschiedliche Schrittdauern bleiben in diesem Beispiel außen vor.

Bei fester Zusammensetzung starten A und B gemeinsam. A wird fertig, doch C wartet bis zum Abschluss von B, bevor die nächste Gruppe beginnt. Mit Continuous Batching kann C nach dem Ende von A deren Platz übernehmen und parallel zu B weiterarbeiten.

Das Beispiel zeigt eine frühere Aufnahme in die Verarbeitung, keinen gemessenen Geschwindigkeitsgewinn. Ein Support-Chatbot, der kurze Antworten und lange Zusammenfassungen verarbeitet, bietet dieselbe Gelegenheit zur besseren Planung. Wie groß der tatsächliche Gewinn ausfällt, hängt von den Anfragen, der Hardware und der Serverkonfiguration ab.

Warum steigt der LLM-Durchsatz – und wo setzt der KV-Cache Grenzen?

Batching holt mehr nutzbare Arbeit aus derselben Übertragung der Modellgewichte heraus. Modellgewichte sind die gelernten numerischen Parameter, mit denen eine Antwort berechnet wird. Mehrere Anfragen an dasselbe Modell können sich den Aufwand teilen, diese Gewichte durch den GPU-Speicher zu bewegen. Dadurch lässt sich die verfügbare Rechenleistung besser nutzen. Die kontinuierliche Planung hält einen solchen produktiven Batch aufrecht, wenn einzelne Anfragen fertig werden. NVIDIA erläutert den Zusammenhang zwischen Batching, Speichertransfers und GPU-Auslastung.

Eine GPU kann auch mit einem ineffizienten Batch beschäftigt bleiben. Entscheidend ist, wie viel nutzbare Arbeit an Anfragen dabei herauskommt, nicht ob die Auslastungskurve am Anschlag liegt.

Jede aktive Anfrage benötigt allerdings zusätzlich Arbeitsspeicher. Ihr KV-Cache, kurz für Key-Value-Cache, hält den Attention-Zustand bereits verarbeiteter Tokens fest. Mehr gleichzeitige Anfragen und längere Verläufe beanspruchen diesen Speicher stärker. Die Erklärung zum KV-Cache grenzt diesen Zustand vom wiederverwendbaren Prompt-Caching ab.

PagedAttention nutzt den Speicher besser aus

Continuous Batching entscheidet, was ausgeführt wird; PagedAttention verändert die Speicherung des Attention-Zustands. Die vLLM-Veröffentlichung von Woosuk Kwon und Kollegen aus dem Jahr 2023 beschreibt, wie der KV-Zustand in Blöcke fester Größe aufgeteilt wird, die im physischen Speicher nicht nebeneinanderliegen müssen. Eine Blockzuordnung bewahrt die logische Reihenfolge der Sequenz.

So geht weniger Speicher durch Fragmentierung und unnötige Duplizierung verloren. Die dichtere Belegung schafft Platz für die Arbeitsdaten weiterer Anfragen und gibt dem Scheduler mehr nutzbare Arbeit zur Auswahl. Die Veröffentlichung bezeichnet diesen Ansatz zur Speicherverwaltung ausdrücklich als Ergänzung zu Orcas Ablaufplanung.

Die physische Kapazität bleibt die Grenze. Auch mit besserer Belegung passen nicht beliebig viele lange Gespräche in den Speicher. In vLLM kann zu wenig KV-Speicher zu Preemption führen: Eine Anfrage wird unterbrochen, ihr Zustand später neu berechnet. Das kann die Zeit bis zum Abschluss verlängern. Die Dokumentation zur Optimierung erläutert dieses Verhalten.

Wie verändert sich die Latenz?

Continuous Batching kann die Wartezeit in der Schlange verkürzen. Größere oder stärker belegte Batches können die Verarbeitung danach jedoch verlangsamen. Die einzelnen Phasen sollten deshalb getrennt erfasst werden:

• Time to First Token, kurz TTFT: die Wartezeit, bis die Ausgabe beginnt.
• Inter-Token-Latenz: die Abstände zwischen Tokens, sobald das Streaming läuft.
• Ende-zu-Ende-Latenz: die Gesamtdauer einer Anfrage.

Eine neu eintreffende Anfrage muss nicht mehr warten, bis ein kompletter fester Batch abgearbeitet ist. Die Verarbeitung eines großen neuen Prompts kann allerdings mit bereits laufenden Decode-Vorgängen um Ressourcen konkurrieren. Chunked Prefill zerlegt die Prompt-Verarbeitung in kleinere Abschnitte, die der Scheduler mit der laufenden Generierung verschachteln kann.

vLLM dokumentiert beispielsweise einen Zielkonflikt beim Tokenbudget pro Iteration: Kleinere Werte können die Inter-Token-Latenz schützen, während größere Werte mehr Prefill-Arbeit ermöglichen und die TTFT verbessern können. Das Budget muss deshalb zur Arbeitslast passen; es sollte nicht blind maximiert werden. Hinweise zur Abstimmung von vLLM.

Continuous Batching bei geringer und hoher LLM-Last

Bei geringer Last gibt es womöglich kaum etwas zu bündeln; bei dauerhafter Überlast bleibt eine Warteschlange bestehen. Wer in der Entwicklung immer nur eine Anfrage nach der anderen abschickt, sollte nicht denselben Nutzen erwarten wie bei einem Kundendienst mit überlappenden Anfragen. Am anderen Ende des Spektrums verschlechtern sich die Wartezeiten irgendwann, wenn mehr Arbeit angenommen wird, als die GPU dauerhaft bewältigen kann.

Bei interaktiven Anwendungen zählt neben dem Median auch p95, das 95. Perzentil. Ein guter Durchschnitt kann verdecken, dass eine Minderheit der Sitzungen langsam ist. Welche TTFT und welche Pausen im Tokenstrom akzeptabel sind, ergibt sich aus der gewünschten Produkterfahrung. Die Kapazität wird anschließend innerhalb dieser Grenzen gemessen.

vLLM Batching und andere Implementierungen im Überblick

Alle vier folgenden Server dokumentieren Continuous Batching oder In-flight Batching. Diese gemeinsame Fähigkeit macht ihre Scheduler, Speicherbudgets und unterstützten Modelle jedoch nicht austauschbar.

vLLM Batching: Anfragen und KV-Cache gemeinsam planen

vLLM verbindet kontinuierliche Anfrageplanung mit seitenweiser KV-Cache-Verwaltung. Die Dokumentation führt beide Funktionen ausdrücklich auf. Für den Betrieb sind die maximale Anzahl von Sequenzen und die pro Iteration eingeplanten Tokens die relevanten Stellgrößen – nicht allein eine gewünschte Zahl gleichzeitiger API-Verbindungen.

Die Grenze setzt der Speicherdruck: Mehr gleichzeitige Anfragen können zu Unterbrechungen und Neuberechnungen führen, statt die nutzbare Kapazität zu erhöhen. Die Einstellungen müssen zum Anfragemix und zum Latenzziel passen. Beim Vergleich bleiben Modell und Hardware unverändert.

SGLang

SGLang unterstützt Continuous Batching und bietet ausdrückliche Einstellungen für die Aufnahme neuer Anfragen. Die Dokumentation der Serverparameter beschreibt --max-running-requests, --chunked-prefill-size und das über --mem-fraction-static gesteuerte Budget für Modellgewichte und KV-Speicherpool.

Diese Einstellungen beantworten unterschiedliche Fragen: Wie viele Anfragen dürfen laufen, wie viel Prompt-Arbeit passt in einen Abschnitt, und wie wird der Speicher aufgeteilt? Eine höhere Anfragegrenze hebt die anderen Grenzen nicht auf. Für die grundsätzliche Wahl der Engine hilft der Vergleich von vLLM und SGLang. Anschließend kommt es auf die Prüfung mit genau dem Modell und Anfragemix an, die später bedient werden sollen.

NVIDIA TensorRT-LLM

NVIDIA TensorRT-LLM setzt In-flight Batching ausdrücklich mit Continuous Batching und Iteration-level Batching gleich. Die Funktionsdokumentation beschreibt die gemeinsame Verarbeitung von Sequenzen in der Kontext- und der Generierungsphase. Die dokumentierte Implementierung nutzt dafür gepackte Eingabetensoren.

Die Anfragegrenze und das Tokenbudget sind eigenständige Beschränkungen. Auch die Dokumentation des PyTorch-Schedulers trennt die Reservierung von Ressourcen einschließlich KV-Kapazität von der Auswahl jener passenden Anfragen, die tatsächlich ausgeführt werden. Ein In-flight-Scheduler kann keine Arbeit aufnehmen, die diese Kapazitätsprüfungen nicht besteht.

Hugging Face Text Generation Inference

Hugging Face Text Generation Inference unterstützt Continuous Batching. Der Wartungsstatus des Projekts verändert allerdings die Abwägung bei einer neuen Bereitstellung. Laut Dokumentation nimmt das Projekt inzwischen kleinere Fehlerkorrekturen, Verbesserungen der Dokumentation und begrenzte Wartungsarbeiten an. Für künftige Implementierungen empfiehlt es Engines wie vLLM und SGLang.

Eine bestehende TGI-Installation verliert durch diesen Status nicht ihre Batching-Funktion. Für eine neue Infrastruktur zur Modellbereitstellung würde ich die Prüfung bei aktiv weiterentwickelten Alternativen beginnen. Bei einer etablierten Installation, die ihre Ziele erfüllt, sollte ein konkreter Bedarf an Unterstützung oder Funktionen den Anlass für eine Migration geben.

Welche Versprechen gehen zu weit?

Continuous Batching liefert keinen universell übertragbaren Beschleunigungsfaktor. Die Veröffentlichungen zu Orca und PagedAttention untersuchen bestimmte Systeme und Arbeitslasten. Ihre Ergebnisse ergeben keinen allgemeingültigen Gewinn, der sich auf ein beliebiges Modell, eine beliebige GPU oder den Endpunkt eines Anbieters übertragen ließe.

Auch Wartezeiten verschwinden nicht. Eine wartende Anfrage braucht weiterhin Prompt-Verarbeitung, Speicher und einen Ausführungsplatz nach den Regeln des Schedulers. Lange Prompts, viele gleichzeitige Anfragen und Speicherdruck im Cache bleiben begrenzende Faktoren.

Schließlich beweist eine höhere Gesamtrate an Tokens noch nicht, dass ein Chatprodukt besser geworden ist. Wenn Nutzer länger auf das erste Token warten oder störende Pausen im Stream erleben, liegt der zusätzliche Serverdurchsatz womöglich außerhalb dessen, was für das Produkt akzeptabel ist.

Was lässt sich ab Montag konkret ändern?

Entwicklungsteams sollten bei überlappenden Anfragen die gemeinsame Modellbereitstellung prüfen; Betriebsteams sollten innerhalb ihrer Latenzgrenzen optimieren; bei der Anbieterauswahl zählen Messungen unter konkurrierender Last. Ein allein genutztes Tool mit gelegentlichen Anfragen kann warten. Ein Dienst mit wartenden Kunden und unterschiedlich langen Antworten hat dagegen einen konkreten Anlass zu handeln. Der Vergleich von Ollama und vLLM behandelt den Übergang von lokaler Nutzung zu gemeinsam genutzter Modellbereitstellung.

1. 1

   Erst die gewünschte Nutzungserfahrung festlegen, dann mehr Anfragen gleichzeitig zulassen

   Für den tatsächlichen Arbeitsablauf werden akzeptable Werte für die Zeit bis zum ersten Token, Pausen im Stream und die Gesamtdauer festgehalten. Ein Zusammenfassungsdienst im Hintergrund braucht andere Abnahmegrenzen als ein Live-Support-Assistent.

2. 2

   Einen repräsentativen Anfragemix nachspielen

   Modell, Hardware, Prompt-Längen, Ausgabelimits und Cache-Bedingungen müssen vergleichbar bleiben. Kurze Antworten, lange Prompts und lange Ausgaben gehören gleichermaßen in den Test. Realistische Ankunftsmuster verhindern, dass ein ruhiger Einzeltest stellvertretend für einen stark genutzten Dienst steht.

3. 3

   Durchsatz gemeinsam mit Warteschlange und Latenz erfassen

   Gemessen werden die gesamten Ausgabetokens pro Sekunde, abgeschlossene und wartende Anfragen, Fehler, TTFT und Tokenabstände. vLLM stellt entsprechende Metriken bereit, darunter vllm:num_requests_waiting, vllm:time_to_first_token_seconds und vllm:inter_token_latency_seconds. Sie sind in der Dokumentation der Betriebsmetriken beschrieben.

4. 4

   Die höchste Last beibehalten, die alle Ziele noch erfüllt

   Jeweils nur eine Einstellung für Ablaufplanung oder Speicher verändern. Die Anzahl gleichzeitiger Anfragen nicht weiter erhöhen, sobald die Latenzgrenzen überschritten werden oder Speicherdruck wiederholte Neuberechnungen auslöst. Von einem Anbieter dieselbe gemeinsame Betrachtung von Durchsatz und Latenz bei der erwarteten Anzahl gleichzeitiger Anfragen verlangen – einschließlich der Auskunft, ob die Kapazität geteilt oder reserviert ist.

Das Ergebnis ist eine gemessene Betriebsgrenze: jene Arbeitslast, die der Endpunkt dauerhaft bewältigt, während die vorgesehene Nutzungserfahrung erhalten bleibt. Erst damit wird aus einer Batching-Funktion eine belastbare Entscheidung für die Bereitstellung.

Praktische Erklärungen zur KI-Infrastruktur und konkrete Ansatzpunkte für den eigenen Stack gibt es im Newsletter.