Continuous Batching plant aktive Sequenzen bei jeder Decodierungsiteration ein. Dadurch können neue Anfragen hinzukommen und abgeschlossene Anfragen entfernt werden, ohne auf einen festen Batch warten zu müssen.
Eine Familie kann innerhalb weniger Sekunden eine Sprachanfrage, eine Frage zu einem Dokument und eine Programmieranweisung an ein lokales Modell senden. Die Eingaben und Ausgabelängen unterscheiden sich, sodass ein fester Batch Slots verschwendet, während kürzere Antworten auf die längste warten. Continuous Batching baut die nützliche Arbeitslast rund um das Modell fortlaufend neu auf. Das ist jedoch nur dann relevant, wenn sich Anfragen überschneiden und der Server über genügend Speicher- und Scheduling-Reserven verfügt.
Scheduling auf Iterationsebene ist die entscheidende Idee
Die autoregressive Decodierung führt jede aktive Sequenz pro Modelliteration um ungefähr ein Token weiter. Ein kontinuierlicher Scheduler wählt die ausführbaren Sequenzen für die nächste Iteration aus, nimmt neue Anfragen auf, sobald Kapazität frei wird, und entfernt Sequenzen unmittelbar nach ihrem Abschluss.
Das Orca-Paper führte Scheduling auf Iterationsebene ein - auf der Granularität von Modelliterationen statt vollständigen Anfragen. Selektives Batching gruppiert anschließend kompatible Operationen, während anfragespezifische Arbeit getrennt bleibt. Dieser Unterschied wird auch bei späteren Tests im Haushalt sichtbar.
Das ist nicht dasselbe wie das Streamen von Tokens an einen Benutzer. Streaming verändert den Zeitpunkt der Ausgabe, während Continuous Batching die interne gemeinsame Ausführung mehrerer Anfragen durch das Modell verändert. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung fortgesetzt wird.
Es unterscheidet sich von statischem Batching und Batching innerhalb eines Ankunftsfensters
Statisches Batching bindet eine feste Gruppe zusammen und füllt kürzere Sequenzen häufig auf, bis die längste abgeschlossen ist. Beim Batching innerhalb eines Ankunftsfensters oder dynamischen Batching wird kurz gewartet, um Anfragen zu sammeln, doch die daraus entstehende Gruppe kann weiterhin als eine Einheit ausgeführt werden. Continuous Batching überprüft die Zusammensetzung bei jeder Iteration neu.
Das vLLM-Paper kombiniert Scheduling auf Iterationsebene mit Paged-KV-Cache-Management, sodass wechselnde Sequenzmengen keine starren zusammenhängenden Reservierungen erfordern. Scheduling und Speichermanagement ergänzen sich, sind jedoch keine austauschbaren Funktionen. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.
Mehr aktive Sequenzen können das Lesen der Gewichte amortisieren und den Durchsatz verbessern. Gleichzeitig konkurriert jede Anfrage um KV-Speicher und Rechenleistung. Ein größerer aktiver Batch ist daher nicht automatisch besser für Latenz oder Fairness. Die praktischen Auswirkungen zeigen sich, wenn mehrere Quellen um einen begrenzten Kontext konkurrieren.
Nicht allein die Modellgröße, sondern die Nebenläufigkeit erzeugt den Vorteil
Ein einzelner interaktiver Benutzer bemerkt möglicherweise kaum einen Vorteil, weil keine zweite Anfrage verfügbar ist, um ungenutzte Kapazität auszulasten. Vorteile entstehen bei mehreren gleichzeitig aktiven Benutzern im Haushalt, Agenten-Zweigen, Hintergrundzusammenfassungen oder mehreren Anwendungen, die dasselbe im Speicher befindliche Modell gemeinsam nutzen.
Sarathi-Serve untersucht, wie Prefill-Interferenzen die Decodierungslatenz beeinträchtigen können, und verwendet in Blöcke aufgeteilte Prefills, um eine besser vorhersehbare gemischte Planung zu ermöglichen. Das Ergebnis zeigt, dass die Zulassungsstrategie neben der Bezeichnung Continuous Batching eine Rolle spielt. Diese Abhängigkeit sollte in der endgültigen Benutzeroberfläche ausdrücklich erkennbar bleiben.
Die Grenze des Scheiterns liegt bei Speicherdruck oder einer aggressiven Zulassung, die die Zeit pro Ausgabetoken und die Tail-Latenz erhöht. Wenn sich der KV-Cache füllt, können Verdrängung, Auslagerung oder Neuberechnung die Durchsatzgewinne zunichtemachen und den interaktiven Dienst instabil machen.
Ermitteln Sie, ob die gleichzeitige Nachfrage den Einsatz rechtfertigt
Spielen Sie ein, zwei, vier und acht sich überschneidende Anfragen mit realistischen Eingabe- und Ausgabelängen erneut ab. Erfassen Sie Durchsatz, Zeit bis zum ersten Token, Zeit pro Ausgabetoken, Abschlusszeit im 95. Perzentil, KV-Auslastung, Verdrängungen und Fairness nach Anfrageklasse.
Vergleichen Sie das Verhalten mit Lücken beim Continuous Batching. Wiederholen Sie den Test mit deaktiviertem Continuous Batching oder einer Fixed-Batch-Baseline, während Modell, Quantisierung, Kontextgrenzen und Hardware konstant bleiben. Das Ergebnis muss daher mit den ursprünglichen Belegen abgeglichen werden.
Verwenden Sie Continuous Batching, wenn sich überschneidende Anfragen einen deutlichen Durchsatz- oder Kapazitätsgewinn ermöglichen, ohne die interaktive Tail-Latenz zu verletzen. Wenn sich Anfragen nur selten überschneiden, sollten Sie der Modellresidenz und der Startlatenz Priorität geben, bevor Sie zusätzliche Scheduler-Komplexität einführen. Dieser Unterschied wird auch bei späteren Tests im Haushalt sichtbar.
Tech- & KI-Zentrum
Mehr zum Lesen

Was ist Embedding-Drift, und wann muss ein privater Suchindex neu erstellt werden?
Entschlüsseln Sie Modell-, Vorverarbeitungs-, Korpus- und Abfragedrift, unterscheiden Sie zwischen Überwachung und Inkompatibilität und entscheiden Sie, wann ein privater Index neu erstellt werden muss.

Was ist Tokenizer-Kompatibilität, und warum kann sie den Modellwechsel beeinträchtigen?
Entschlüsseln Sie Vokabularidentität, die Semantik spezieller Token, Chatvorlagen, zwischengespeicherte Token, Adapter und Kompatibilitätsprüfungen für den Wechsel lokaler Modelle.

Was ist Modellresidenz, und wann sollte ein lokaler KI-Dienst die Gewichte geladen lassen?
Entschlüsseln Sie Gewichtsspeicherort, Cache-Ebenen, Kaltstarts, Verdrängung, Multiplexing, Speicherdruck und wann ein KI-Dienst zu Hause warm bleiben sollte.

