Asynchrone Batch-Verarbeitung zur Optimierung der Inferenzleistung von Sprachmodellen

Asynchrone Batch-Verarbeitung: Effizienzsteigerung in der LLM-Inferenz

Die kontinuierliche Weiterentwicklung von Large Language Models (LLMs) hat die Anforderungen an deren Inferenzleistung massiv erhöht. Insbesondere im B2B-Bereich, wo Effizienz und Skalierbarkeit von größter Bedeutung sind, ist die Optimierung jedes einzelnen Schritts im Inferenzprozess unerlässlich. Die asynchrone Batch-Verarbeitung stellt hierbei eine Schlüsseltechnologie dar, um die Auslastung von Hardware-Ressourcen zu maximieren und somit Durchsatz und Latenz signifikant zu verbessern. Dieser Artikel beleuchtet die technischen Grundlagen und die praktischen Vorteile dieser Methode, die es ermöglicht, die CPU- und GPU-Arbeitslasten zu entkoppeln und parallel auszuführen.

Die Herausforderung synchroner Batch-Verarbeitung

Traditionelle Ansätze zur Batch-Verarbeitung, auch als synchrone Batch-Verarbeitung bekannt, sind durch eine sequenzielle Ausführung von CPU- und GPU-Operationen gekennzeichnet. Während die GPU Berechnungen durchführt, wartet die CPU im Leerlauf. Umgekehrt verweilt die GPU im Leerlauf, während die CPU die Daten für den nächsten Batch vorbereitet. Diese abwechselnden Leerlaufzeiten, die als "Idle Gaps" bezeichnet werden, summieren sich bei den Hunderten von Schritten pro Sekunde, die in einer kontinuierlichen Batch-Schleife auftreten können, und führen zu einer erheblichen Verschwendung von Rechenzeit. Analysen zeigen, dass in solchen Szenarien bis zu einem Viertel der gesamten Laufzeit durch GPU-Leerlaufzeiten aufgrund von CPU-Vorbereitungen verloren gehen kann. Das Eliminieren dieser Leerlaufzeiten kann die Inferenzgeschwindigkeit um einen vergleichbaren Prozentsatz steigern, ohne dass Änderungen am Modell oder den Kern-Kerneln erforderlich sind.

Schlüsselkonzepte zur Erzielung von Asynchronität

Um die synchronen Engpässe zu überwinden, müssen CPU- und GPU-Operationen entkoppelt werden. Dies erfordert den Einsatz spezifischer Technologien und Mechanismen:

CUDA-Streams: Parallelität auf der GPU

CUDA-Streams bilden die Grundlage für die parallele Ausführung von GPU-Operationen. Ein Stream ist eine geordnete Warteschlange von GPU-Operationen wie Kernel-Starts, Speicherkopien und Synchronisationsbarrieren, die in der Reihenfolge ihrer Übermittlung ausgeführt werden. Operationen innerhalb desselben Streams sind sequenziell. Der entscheidende Punkt ist jedoch, dass Operationen in verschiedenen Streams voneinander unabhängig sind und gleichzeitig ausgeführt werden können.

Die Standardpraxis in PyTorch, bei der keine expliziten Streams angegeben werden, führt dazu, dass alle Operationen im "Default Stream" landen. Dieser Stream hat die besondere Eigenschaft, synchronisierend zu wirken: Bevor eine Operation im Default Stream beginnen kann, müssen alle anderen Streams abgeschlossen sein. Dies verhindert effektiv jede Form von Parallelität zwischen CPU und GPU. Daher ist es unerlässlich, für asynchrone Batch-Verarbeitung "Non-Default Streams" zu verwenden. Diese erlauben es der CPU, die Kontrolle sofort nach dem Start einer GPU-Operation zurückzugewinnen, während die GPU die Operation im Hintergrund ausführt.

Für die asynchrone Batch-Verarbeitung werden typischerweise drei dedizierte Streams eingesetzt:

• Ein Host-to-Device (H2D) Stream für die Datenübertragung von der CPU zur GPU.
• Ein Compute Stream für die eigentlichen Berechnungen auf der GPU.
• Ein Device-to-Host (D2H) Stream für die Datenübertragung von der GPU zurück zur CPU.

CUDA-Events: Präzise Synchronisation

Das alleinige Nutzen von Non-Default Streams reicht nicht aus, da die Unabhängigkeit der Streams zu Race Conditions führen würde. CUDA-Events ermöglichen eine präzise Synchronisation über Stream-Grenzen hinweg. Ein Event ist ein Marker, der in einen Stream eingefügt werden kann. Wenn die GPU diesen Marker erreicht, wird das Event als abgeschlossen markiert. Andere Streams können dann angewiesen werden, auf dieses Event zu warten, bevor sie ihre nächste Operation starten. Dies gewährleistet die korrekte Reihenfolge der Operationen, beispielsweise dass die Berechnung erst nach dem Abschluss der Datenübertragung beginnt und die Ausgabeübertragung erst nach Abschluss der Berechnung.

Durch den Einsatz von Events kann die CPU alle GPU-Aufgaben sequenziell anstoßen, ohne selbst blockiert zu werden. Die Synchronisation erfolgt vollständig auf der GPU-Seite. Erst am Ende des gesamten Batch-Prozesses blockiert die CPU kurz, um die finalen Ergebnisse des Batches von der GPU zu lesen.

Herausforderungen und Lösungen in der asynchronen Batch-Verarbeitung

Die Implementierung einer vollständig asynchronen Batch-Verarbeitung birgt spezifische Herausforderungen, die sorgfältige Lösungen erfordern:

Race Conditions und Double Buffering

Eine zentrale Herausforderung ist die Vermeidung von Race Conditions, bei denen die CPU und GPU gleichzeitig auf dieselben Speicherbereiche zugreifen und diese modifizieren könnten. Dies würde zu Datenkorruption führen. Die Lösung hierfür ist das "Double Buffering": Es werden zwei Sätze von Tensoren verwendet, zwischen denen abgewechselt wird. Während die GPU Batch N aus Slot A verarbeitet, bereitet die CPU Batch N+1 in Slot B vor. Dies verdoppelt zwar den benötigten Speicher für Input- und Output-Tensoren, ist jedoch ein akzeptabler Kompromiss angesichts der signifikanten Leistungssteigerung. Insbesondere bei der Verwendung von FlashAttention, das keine großen Attention Masks benötigt, ist dieser Mehraufwand überschaubar.

Für CUDA-Graphen, die zur Reduzierung der Latenz dienen und an spezifische Speicheradressen gebunden sind, wird ein "Memory Pool" eingesetzt. Dieser gemeinsame Speicherbereich ermöglicht es, mehrere Graphen zu erfassen, ohne den VRAM-Verbrauch signifikant zu erhöhen, da Batch N und Batch N+1 niemals gleichzeitig ausgeführt werden.

Carry-over: Datenkonsistenz über Batches hinweg

Eine weitere Herausforderung besteht darin, die Konsistenz der Daten zwischen aufeinanderfolgenden Batches zu gewährleisten. Wenn eine Anfrage sowohl in Batch N als auch in Batch N+1 vorhanden ist und in Batch N ein neues Token generiert, muss dieses Token als Eingabe für Batch N+1 dienen. Da Batch N+1 vorbereitet wird, während Batch N noch läuft, ist das neue Token noch nicht verfügbar. Die Lösung ist ein "Carry-over"-Mechanismus: Beim Aufbau von Batch N+1 wird ein Platzhalter-Token verwendet. Nach Abschluss der Berechnungen von Batch N und vor dem Start des Forward Pass von Batch N+1 wird dieses Platzhalter-Token durch das tatsächlich generierte Token ersetzt. Dieser Prozess ist recheneffizient und kann in den CUDA-Graphen integriert werden.

Der vollständige asynchrone Zyklus

Der asynchrone Zyklus beginnt mit einem kalten Start, bei dem der erste Batch synchron verarbeitet wird. Anschließend tritt der asynchrone Loop in Aktion: Während die GPU Batch N verarbeitet, bereitet die CPU Batch N+1 vor. Sobald die Inputs für Batch N+1 bereit sind, reiht die CPU die GPU-Arbeiten ein (H2D-Transfer, Compute, D2H-Transfer) und fährt fort. Die GPU führt die Aufgaben parallel aus, wobei CUDA-Events die korrekte Reihenfolge sicherstellen. Die CPU wartet nur kurz auf die Ergebnisse von Batch N, um den Zustand der Anfragen zu aktualisieren und Batch N+2 zu planen. Solange die CPU ihre Arbeit schneller erledigt, als die GPU die Berechnungen abschließt, läuft die GPU ununterbrochen, was zu einer maximalen Auslastung und erheblichen Leistungssteigerungen führt.

Praktische Auswirkungen und zukünftige Entwicklungen

Die Anwendung der asynchronen Batch-Verarbeitung in realen Szenarien, wie beispielsweise bei der Generierung von 8.000 Tokens mit einem 8B-Modell und einer Batch-Größe von 32, zeigt eindrucksvolle Ergebnisse. Die GPU-Auslastung steigt von etwa 76% auf über 99%, und die Gesamtgenerierungszeit reduziert sich um etwa 22%. Dies entspricht einer Effizienzsteigerung, die ohne grundlegende Änderungen an den Modellen oder Kerneln erreicht wird, allein durch eine intelligentere Koordination der Hardware-Ressourcen.

Die Implementierung dieser Techniken, wie sie beispielsweise in der Hugging Face Transformers-Bibliothek zu finden ist, ebnet den Weg für weitere Optimierungen. Zukünftige Entwicklungen könnten die Auslagerung von Anfragen, decode-spezifische Kernel oder fein granulare Kompilierungsstrategien umfassen, um den Durchsatz für sehr lange Generierungssequenzen (z.B. 16K+ Tokens) weiter zu maximieren. Asynchrone Batch-Verarbeitung ist somit ein entscheidender Schritt auf dem Weg zu noch effizienteren und leistungsfähigeren LLM-Inferenzsystemen.

Wir von Mindverse sind bestrebt, Ihnen stets die neuesten und relevantesten Informationen aus dem Bereich der Künstlichen Intelligenz bereitzustellen. Bleiben Sie informiert über weitere Entwicklungen, die die Zukunft der KI-Anwendungen gestalten.

Bibliographie:

- Ouazan, R. (2026, May 14). Unlocking asynchronicity in continuous batching. Hugging Face Blog. - Ouazan, R. (2025, November 25). Continuous batching from first principles. Hugging Face Blog. - Ouazan, R. (2026, February 12). [CB] [Major] Asynchronous batching. Pull Request #43960, huggingface/transformers. - Hugging Face. (n.d.). Continuous batching. Hugging Face Documentation. - Hugging Face. (n.d.). Continuous batching architecture. Hugging Face Documentation. - AKDEMİR, B. (2025, October 1). Continuous Batching in LLM Inference. Medium. - k4i. (2026, April 22). Continuous Batching: Scheduling at Iteration Granularity. k4i's blog. - Daniel, C., Shen, C., Liang, E., & Liaw, R. (2022, June 15). Achieve 23x LLM Inference Throughput & Reduce p50 Latency. Anyscale Blog. - Nautiyal, A. (n.d.). Continuous Batching. EngineersOfAI. - Belfer, Y. (2026, March 25). What is Continuous Batching? AI21 Glossary.