Asynchrones Continuous Batching: So arbeiten CPU und GPU ohne Leerlauf zusammen
đź’ˇ Quellen-Hinweis: Dieser Beitrag ist eine redaktionelle Zusammenfassung basierend auf einem Originalbericht von Hugging Face Blog.
Continuous Batching verbessert die LLM-Inferenz, indem laufende Anfragen dynamisch in kompakte Batches aufgenommen und abgeschlossene Sequenzen sofort ersetzt werden. Dadurch fällt weniger Rechenleistung für Padding an. Dennoch bleibt in einer klassischen synchronen Schleife ein zweiter Verlust: CPU und GPU arbeiten abwechselnd. Während die GPU rechnet, wartet die CPU; während die CPU den nächsten Schritt vorbereitet, bleibt die GPU unbeschäftigt.
Die versteckten LĂĽcken im Inferenzablauf
Ein einzelner Leerlaufabschnitt wirkt klein. In einem Server, der pro Sekunde Hunderte Dekodierschritte ausführt, summieren sich diese Pausen jedoch zu messbarem Durchsatzverlust. Die CPU muss Ergebnisse auswerten, Stop-Kriterien prüfen, neue Anfragen einordnen und den nächsten Batch vorbereiten. Erfolgt all das erst nach vollständigem Abschluss des GPU-Schritts, entsteht zwischen den Kernel-Aufrufen eine regelmässige Lücke.
Die asynchrone Variante überlappt diese Phasen. Während die GPU den aktuellen Batch verarbeitet, bereitet die CPU bereits die nächste Arbeit vor. Dafür braucht es nicht blockierende GPU-Operationen, getrennte Zustände für laufende und kommende Schritte sowie eine saubere Synchronisation an den Punkten, an denen Resultate wirklich benötigt werden. Ziel ist eine Pipeline, in der beide Prozessoren möglichst kontinuierlich beschäftigt bleiben.
Mehr Tempo verlangt klare Zustandsgrenzen
Die technische Schwierigkeit liegt weniger im Starten paralleler Aufgaben als im korrekten Umgang mit gemeinsamem Zustand. KV-Cache, Attention-Masken, neue Tokens und ankommende oder beendete Requests müssen zum richtigen Zeitpunkt konsistent sein. Eine zu frühe Synchronisation zerstört den Performancegewinn; eine zu späte kann falsche Zuordnungen oder Race Conditions verursachen. Hugging Face hat den Ansatz deshalb schrittweise aufgebaut und in die Continuous-Batching-Implementierung von Transformers übertragen.
Einordnung fĂĽr Betreiber von LLM-Diensten
Für produktive Inferenz ist dies eine typische Systemoptimierung: Das Modell bleibt unverändert, aber die Hardware liefert mehr nutzbare Arbeit pro Zeiteinheit. Besonders bei vielen gleichzeitigen Anfragen kann die Überlappung von CPU- und GPU-Arbeit Kosten und Antwortzeiten verbessern. Entscheidend bleibt ein realistisches Benchmarking mit dem eigenen Request-Mix. Asynchronität erhöht die Komplexität, weshalb Tracing von CPU- und GPU-Zeitachsen sowie Korrektheitstests genauso wichtig sind wie reine Tokens-pro-Sekunde-Werte.
Originalquelle: Hugging Face Blog – Unlocking asynchronicity in continuous batching
