Continuous Batching — wie vLLM den 10-fachen Durchsatz erreicht

Worum es geht

Continuous Batching — auch als Iteration-Level- oder In-Flight-Batching bezeichnet — ist die Scheduling-Technik, die es einer LLM-Inference-Engine erlaubt, mit der Verarbeitung einer neuen Anfrage in dem Moment zu beginnen, in dem eine ältere Anfrage abgeschlossen ist, statt zu warten, bis ein ganzer Batch gemeinsam fertig ist. Es ist der mit Abstand wichtigste Grund, warum Engines wie vLLM und TensorRT-LLM auf derselben GPU-Hardware einen etwa zehn- bis vierundzwanzigfach höheren Durchsatz erreichen als eine naive Text-Generation-Schleife, und es lohnt sich, dies auch als Nicht-Ingenieur bei der Bewertung eines SAP-AI-Deployments zu verstehen, denn es bestimmt unmittelbar die Kosten pro Token und die Antwortlatenz, die ein Berater einem Kunden erklären muss.

Warum es zählt

• Der Scheduler denkt in Iterationen, nicht in Anfragen: Er packt den Batch bei jedem Forward Pass neu und nimmt eine neue wartende Anfrage auf, sobald ein Slot frei wird.
• In Kombination mit PagedAttention hält Continuous Batching die GPU-Auslastung bei Anfragen mit stark unterschiedlichen Längen auf 60-90 %, gegenüber der massiven Verschwendung beim Static Batching.
• Der Durchsatz verbessert sich beim gleichen Hardware-Budget um das 5- bis 10-Fache, wobei sich die P99-Tail-Latenz noch stärker verbessert, da kurze Anfragen nicht mehr hinter langen warten müssen.

Kernpunkte

• Iteration-Level Scheduling — neue Anfragen werden in den Batch aufgenommen, sobald ältere abgeschlossen sind, nicht erst an Batch-Grenzen.
• Naives Static Batching verschwendet bei realen Workloads mit variabler Ausgabelänge 60-90 % der GPU-Rechenleistung.
• In Kombination mit PagedAttention (C246) hält Continuous Batching die effektive GPU-Auslastung bei Anfragen unterschiedlicher Länge auf 60-90 %.
• 10- bis 24-fache Durchsatzverbesserung gegenüber der HuggingFace-generate()-Baseline auf derselben Hardware.
• Die P99-Tail-Latenz verbessert sich, weil kurze Anfragen nicht hinter langen warten müssen.
• Die Implementierungskomplexität ist der Grund, warum die meisten Teams vLLM oder TensorRT-LLM übernehmen, statt einen eigenen Scheduler zu bauen.
• Ergänzend zum spekulativen Decoding: Continuous Batching dient dem Durchsatz (hoher Traffic); spekulatives Decoding dient der Latenz (Einzelnutzer).
• Praktischer Benchmark: HuggingFace generate() mit 20-50 Token/s gegenüber vLLM mit 800-2 000 Token/s auf derselben H100 bei 32 gleichzeitigen Anfragen.
• Umstellung der nächtlichen SAP-Dokumentenverarbeitung auf vLLM: GPU-Stunden um bis zu 10× reduziert — von 3,10 $/h auf 0,31 $/h für denselben Job.
• Konversationelles Joule für Einzelnutzer profitiert kaum von Continuous Batching — spekulatives Decoding oder eine schnellere Modellstufe sind die richtigen Hebel.

Begriffe auf dieser Seite

Continuous batching

Planung der LLM-Inferenz auf Iterationsebene, sodass neue Anfragen in den Batch aufgenommen werden, sobald ältere Anfragen abgeschlossen sind, statt auf den Abschluss des gesamten Batches zu warten.

Static batching

Der naive Ansatz, bei dem ein Batch von Anfragen zum Zeitpunkt der Aufnahme fest steht und alle gemeinsam Forward Passes durchlaufen, bis die längste Anfrage abgeschlossen ist.

Iteration-level scheduling

Synonym für Continuous Batching; betont, dass Scheduling-Entscheidungen bei jeder Forward-Pass-Iteration getroffen werden, nicht an Anfragegrenzen.

Head-of-line blocking

Das Latenzproblem beim Static Batching, bei dem kurze Anfragen warten müssen, bis die längste Anfrage ihres Batches abgeschlossen ist; wird durch Continuous Batching beseitigt.

Speculative decoding

Eine ergänzende Latenzoptimierung, bei der ein kleines Draft-Modell mehrere Tokens im Voraus vorschlägt und das große Modell sie in einem einzigen Forward Pass verifiziert; senkt die Pro-Token-Latenz für eine einzelne Anfrage, während Continuous Batching den aggregierten Durchsatz über gleichzeitige Anfragen erhöht — produktive Engines wenden meist beides an.

Max batch size (max_num_seqs)

Der Scheduler-Konfigurationsparameter, der begrenzt, wie viele Sequenzen die Engine pro Iteration gleichzeitig verarbeiten kann; zu niedrig gesetzt, verschwendet er verfügbare GPU-Kapazität; zu hoch relativ zum KV-Cache-Speicher gesetzt, riskiert er Page Eviction und Latenzspitzen.

Quellen

1. Yu et al. — Orca: A Distributed Serving System for Transformer-Based Generative Models (OSDI 2022, the iteration-batching paper)
2. Kwon et al. — Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023)
3. NVIDIA TensorRT-LLM in-flight batching documentation
4. Anyscale — How continuous batching enables 23x throughput in LLM inference
5. Databricks — LLM inference performance engineering best practices
6. NVIDIA Docs — TensorRT-LLM
7. vLLM Docs — Scheduler configuration reference
8. vLLM Documentation — project home
9. NVIDIA Technical Blog — TensorRT-LLM accelerates encoder-decoder models with in-flight batching
10. NVIDIA Triton Inference Server — TensorRT-LLM backend documentation
11. arXiv — SGLang: Efficient Execution of Structured Language Model Programs (2312.07104)
12. LMSYS Org — Fast and Expressive LLM Inference with RadixAttention and SGLang