Was ist Batching bei LLM-Inferenz?
Wenn ein einzelner Nutzer einen Prompt an ein LLM sendet, verarbeitet die GPU nur eine Anfrage — und nutzt nur einen Bruchteil ihrer Rechenkapazität. Batching kombiniert mehrere Anfragen und verarbeitet sie gleichzeitig auf derselben GPU, was den Durchsatz dramatisch erhöht.
Statisches Batching
Alle Anfragen im Batch starten und enden zusammen. Die GPU wartet auf die langsamste Anfrage, bevor neue beitreten können. Einfach, aber verschwenderisch — kürzere Anfragen sitzen untätig.
Dynamisches / Continuous Batching
Anfragen können jederzeit dem Batch beitreten und ihn verlassen. Wenn eine Anfrage fertig ist, nimmt sofort eine neue ihren Platz ein. Dieser „Orca-Stil"-Ansatz maximiert die GPU-Auslastung.
Warum Einzelanfragen-Inferenz Ressourcen verschwendet
Eine moderne GPU wie die A100 hat 312 TFLOPS Rechenleistung und 2 TB/s Speicherbandbreite. Ein einzelner Decode-Schritt für eine Anfrage kratzt kaum an der Oberfläche — die GPU verbringt die meiste Zeit mit Warten auf Speicher, nicht mit Berechnen. Batching füllt diese Lücke, indem die Speichertransferkosten über viele Anfragen geteilt werden.
Durchsatz vs. Batch-Größe
Ziehe den Slider, um zu sehen, wie Batching die Leistung beeinflusst
Mit steigender Batch-Größe steigt der Gesamtdurchsatz zunächst steil an — flacht dann ab — und KOLLABIERT schließlich. Der Anstieg kommt vom Amortisieren der Gewichtsladekosten. Der Kollaps passiert, wenn der Speicher erschöpft ist: KV-Caches überfluten den VRAM, das System beginnt zu swappen, und alles bricht zusammen.
Das Plateau entsteht durch DRAM-Bandbreitensättigung — nicht Rechensättigung. Selbst bei Batch 256 sind die GPU-Recheneinheiten noch unterausgelastet. Der Engpass ist, wie schnell Gewichte aus dem Speicher geladen werden können.
Prefill- vs. Decode-Phase
Zwei grundlegend verschiedene Workloads in jeder LLM-Anfrage
Jede LLM-Anfrage hat zwei Phasen. Prefill verarbeitet alle Input-Token parallel — blitzschnell, weil es die Recheneinheiten der GPU sättigt. Decode generiert Token einzeln — quälend langsam, weil es durch Speicherbandbreite begrenzt ist, nicht durch Rechenleistung. Prefill kann ~1000 Token verarbeiten, während Decode ~20 generiert.
Geschwindigkeitsrennen: Prefill vs Decode
Sieh zu, wie Prefill 1000 Token verarbeitet, während Decode kaum beginnt. Prefill verarbeitet ~50 Token pro Tick; Decode verarbeitet 1 Token pro Tick.
Warum der Geschwindigkeitsunterschied?
Arithmetische Intensität = FLOPS pro Byte aus dem Speicher. Prefill hat hohe arithmetische Intensität (viele Operationen pro Gewichtsladevorgang, da viele Token verarbeitet werden). Decode hat extrem niedrige arithmetische Intensität (lädt dieselben Gewichte, berechnet aber nur für 1 Token). Die GPU ist ein Supercomputer, der von einem strohhalmdünnen Speicherrohr als Geisel gehalten wird.
Prefill-Phase
Wie ein Fließband, das alle Teile auf einmal verarbeitet
Decode-Phase
Wie ein einzelner Handwerker, der Stück für Stück fertigt
💡 Prefill ist 1000× schneller pro Token als Decode. Beim Prefill sind die GPU-Tensor-Cores der Engpass (rechengebunden). Beim Decode ist die DRAM-Bandbreite der Engpass (speichergebunden) — die GPU sitzt >80% der Zeit untätig und wartet auf Gewichtsdaten. Genau deshalb hilft Batching: Es füllt diese Leerlaufzyklen mit nützlicher Arbeit anderer Anfragen.
Der Durchsatz-Latenz-Kompromiss
Batching ist kein Gratismittagessen. Mehr Batching bedeutet mehr Token pro Sekunde insgesamt, aber jeder einzelne Nutzer wartet länger auf seine Antwort. Betreiber müssen Servereffizienz gegen Nutzererlebnis abwägen.
Kleine Batch-Größe
Niedriger Gesamtdurchsatz, aber jeder Nutzer bekommt schnelle Antworten (45 Tok/s pro Nutzer)
Große Batch-Größe
Hoher Gesamtdurchsatz, aber jeder Nutzer wartet viel länger (9 Tok/s pro Nutzer)
💡 Der Sweet Spot hängt vom Anwendungsfall ab: Echtzeit-Chat braucht niedrige Latenz (kleine Batches), während Batch-Verarbeitungsjobs den Durchsatz maximieren können (große Batches). Die meisten Produktionssysteme zielen auf Batch-Größen von 32-128.
Continuous Batching
Wie moderne Serving-Engines GPU-Leerlauf eliminieren
Statisches Batching verschwendet GPU-Zeit, weil alle Anfragen auf die längste warten müssen. Continuous Batching (auch „Orca-Stil") lässt Anfragen unabhängig beitreten und verlassen. Wenn eine Anfrage fertig ist, wird ihr Slot sofort mit einer neuen gefüllt. Probiere die interaktive Timeline unten — wechsle zwischen statisch und kontinuierlich, um den Unterschied in der GPU-Auslastung zu sehen.
💡 Mit Continuous Batching werden fertige Slots sofort nachgefüllt. Die GPU-Auslastung bleibt nahe 100%, solange es wartende Anfragen gibt. So funktionieren vLLM, TGI und andere moderne Engines.
Pro-Nutzer vs. Systemdurchsatz
Was mit jedem Nutzer passiert, wenn das System skaliert
Je mehr gleichzeitige Nutzer hinzukommen, desto mehr Token pro Sekunde liefert das System insgesamt — aber jeder einzelne Nutzer bekommt einen kleineren Anteil der Bandbreite. Ab einem kritischen Punkt kollabiert das System komplett: Speichererschöpfung, Swapping und kaskadierende Fehler zerstören den Durchsatz für alle.
Wichtige Erkenntnisse
- 1Batching amortisiert die Kosten des Ladens von Modellgewichten über mehrere Anfragen und erhöht den Gesamtdurchsatz dramatisch
- 2Aber es gibt ein Limit: Zu viele gebatchte Anfragen verursachen Speichererschöpfung und Durchsatzkollaps (OOM)
- 3Prefill ist rechengebunden und 1000× schneller pro Token als Decode, das speicherbandbreitenbegrenzt ist
- 4Continuous Batching eliminiert GPU-Leerlauf, indem Slots dynamisch gefüllt werden, sobald Anfragen abgeschlossen sind
- 5Die Pro-Nutzer-Geschwindigkeit sinkt immer mit mehr gleichzeitigen Nutzern — das System tauscht individülle Geschwindigkeit gegen Gesamtkapazität