Konzeptkarte

Continuous Batching — wie vLLM den 10-fachen Durchsatz erreicht

Stand 2026-07-24T14:00:00Z

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist Continuous Batching — wie vLLM den 10-fachen Durchsatz erreicht?

Statisches Batching verschwendet 60-90 % der GPU-Rechenleistung, weil eine einzelne lange Anfrage in einem Batch die GPU dazu zwingt, aufgefüllte Slots für bereits abgeschlossene Anfragen weiterlaufen zu lassen — Continuous Batching gibt jeden Slot in dem Moment frei, in dem seine Anfrage endet.

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.
Continuous Batching — wie vLLM den 10-fachen Durchsatz erreicht ist erst beherrscht, wenn es eine benannte Käuferentscheidung verändert.
Beginnen Sie mit dem semantischen Vertrag und dem Kontrollmodell, bevor Sie das Tool vorführen.
Nutzen Sie aktuelle SAP-, Analysten-, Studien-, KG- und News-Signale als Beleg, nicht als Dekoration.
Trennen Sie verifizierte Fakten von richtungsweisenden Trends und modellierten Annahmen.

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.
Entscheidungsverantwortlicher: Die verantwortliche Person, die den Trade-off akzeptiert und die nächste Maßnahme finanziert.
Semantischer Vertrag: Die gemeinsame Definition von Geschäftsbegriffen, Kennzahlen, Entitäten und Zugriffsregeln, die von Tools und Teams verwendet wird.
Kontrollebene: Die Ebene, die Richtlinien, Zugriff, Herkunftsnachweis (Lineage), Monitoring und Eskalation über das Betriebsmodell hinweg durchsetzt.
Evidenzgrad: Eine Kennzeichnung, die verifizierte Fakten, richtungsweisende Signale, modellierte Annahmen und Feldbeobachtungen voneinander unterscheidet.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →