vLLM verkürzt Elastic-EP-Skalierungspause von 100 Sekunden auf 0,82 Sekunden
Das Projekt vLLM hat nach eigenen Angaben die Unterbrechung des Serving-Betriebs bei der Neukonfiguration von Elastic Expert Parallelism auf unter zwei Sekunden gedrückt. Im Benchmark mit DeepSeek V4 Pro steht der Betrieb beim Hochskalieren von 16 auf 20 GPUs nur noch 0,82 Sekunden still, in der früheren Elastic-EP-Version waren es 100 Sekunden.
- Elastic EP von vLLM skaliert DeepSeek V4 Pro laut Projekt von 16 auf 20 GB200-GPUs mit 0,82 Sekunden Ausfallzeit.
- Beim Zurückskalieren von 20 auf 16 GPUs pausiert der Betrieb 1,96 Sekunden, zuvor waren es 56 Sekunden.
- Ein vollständiger Neustart für den Wechsel von 16 auf 20 GPUs legte den Betrieb für 197 Sekunden lahm.
- Die Verbesserungen beruhen auf asynchroner Vorbereitung im Hintergrund und NIXL EP, einer Bibliothek, die die EP-Kommunikation im laufenden Betrieb erweitert.
- Bestehende Worker nutzen ihre CUDA-Graphen nach Hoch- wie Herunterskalierung weiter.
Warum Skalierung bisher teuer war
Wie vLLM erklärt, bedeutete eine Änderung der GPU-Anzahl in einem Dienst bislang, ganze Modellreplikate hinzuzufügen oder zu entfernen oder die Engine mit einer anderen GPU-Zahl neu zu starten. Da Modelle wachsen, braucht jedes Replikat mehr GPUs, sodass die Skalierung pro Replikat in immer größeren Schritten erfolgt.
Das Projekt nennt ein konkretes Beispiel: Beim Neustart von vLLM, um DeepSeek V4 Pro von 16 auf 20 GB200-GPUs zu skalieren, stand der Betrieb 197 Sekunden still. Teure GPUs blieben belegt, ohne Tokens zu erzeugen.
Die erste Elastic-EP-Version erlaubte es vLLM, in einem laufenden DEP-Deployment (datenparalleles Attention mit expertenparalleler MoE) GPUs ohne Neustart hinzuzufügen oder zu entfernen. Der Betrieb pausierte jedoch weiterhin, während neue Worker initialisiert, Kommunikationsgruppen vorbereitet, Gewichte geladen sowie Kernel-Warmup und CUDA-Graph-Capture wiederholt wurden. Im selben Benchmark dauerte diese Pause 100 Sekunden beim Hochskalieren von 16 auf 20 GPUs und 56 Sekunden beim Zurückskalieren auf 16.
Zwei Phasen: Vorbereitung im Hintergrund und kurzer Commit
vLLM hat die Neukonfiguration in eine Vorbereitung im Hintergrund und einen kurzen Commit aufgeteilt. Bestehende Worker nutzen separate Hintergrund-Threads, um die Zielkommunikation vorzubereiten und aufzuwärmen, Modellgewichte zu übertragen und Ausführungsinformationen wie Autotuning-Ergebnisse mit den neu hinzukommenden Workern zu synchronisieren. Währenddessen bearbeiten sie weiter Anfragen mit ihren aktuellen Kommunikationsgruppen und CUDA-Graphen.
Die neuen Worker initialisieren sich parallel dazu, empfangen Gewichte und bereiten ihre Kommunikation und GPU-Ausführung vor. Beim Commit pausiert vLLM kurz seine Scheduler, aktiviert die vorbereitete Topologie und nimmt den Betrieb wieder auf. Die Vorbereitung umfasst vier Aufgaben:
- Neue Worker initialisieren: Prozesse starten und Speicher für Modell und Ausführung reservieren.
- Kommunikation vorbereiten: Ziel-Kommunikationsgruppen einrichten und den EP-Kommunikator erweitern.
- Modellgewichte übertragen: Gewichte von bestehenden Workern über NVLink oder RDMA verschieben.
- Ausführung vorbereiten: Kompilierung, Kernel-Warmup, Tuning-Setup und CUDA-Graph-Aufbau auf den neuen Workern abschließen.
Nach dem Commit sorgt asynchrones Expert Parallel Load Balancing (EPLB) dafür, dass neue Worker die Attention übernehmen können, während bestehende Worker die Expertenberechnung erledigen. Anschließend verteilt EPLB die Experten im Hintergrund auf die erweiterte Gruppe um.
NIXL EP und erhaltene CUDA-Graphen
Asynchrone Vorbereitung allein reichte nicht aus. Frühere EP-Kommunikations-Backends in vLLM arbeiteten mit fester Mitgliedschaft, sodass für das Hinzufügen oder Entfernen von Ranks eine neue Instanz mit eigenen Puffern, Speicherregistrierungen, IPC-Handles und RDMA Queue Pairs nötig war. Der Wechsel des Kommunikators machte zudem aufgezeichnete CUDA-Graphen ungültig. Laut vLLM führte selbst mit asynchroner Vorbereitung das erneute Aufzeichnen der Graphen während des Commits zu Pausen von 58 Sekunden beim Hochskalieren und 44 Sekunden beim Herunterskalieren.
Als Lösung hat vLLM NIXL EP entwickelt, eine für Elastic EP gebaute EP-Kommunikationsbibliothek. Sie fügt Ranks direkt im laufenden Betrieb hinzu oder entfernt sie und nutzt dabei denselben NIXL-Agenten, dieselben Puffer und Verbindungen weiter. Nur neu hinzukommende Peers brauchen neue Verbindungen und Registrierungen. Außerdem bleiben aufgezeichnete EP-Dispatch- und Combine-Einträge gültig, sodass bestehende Worker ihre CUDA-Graphen weiterverwenden können.
Auch am eigenen Code hat vLLM Änderungen vorgenommen, damit die umgebenden Compute-Kernel stabile Argumente, Startkonfigurationen und Tensor-Adressen behalten. Fused-MoE-Ausführungsobjekte werden auf bestehenden Workern wiederverwendet, Adressen und Layouts von Graph-sichtbaren Workspaces und Dispatch-Ausgaben bleiben fest, und der Speicher der Expert-Routing-Tensoren bleibt erhalten, während Zuordnungen direkt aktualisiert werden.
Neue Worker bereiten sich unabhängig voneinander vor. NIXL EP erlaubt es jedem von ihnen, beim Warmup und bei der Graph-Aufzeichnung jeden entfernten EP-Peer zu maskieren, und vLLM lässt diese Durchläufe nicht mehr auf DP-Batch-Informationen anderer Worker warten. Nach der Aufzeichnung lassen sich die Peers reaktivieren, ohne die Graphen ungültig zu machen.
Ergebnisse und Bedeutung
Mit DeepSeek V4 Pro auf GB200-GPUs, TP=1 und DP/EP-Größen von 16 und 20 meldet vLLM eine Ausfallzeit von 0,82 Sekunden beim Hochskalieren von 16 auf 20 GPUs und 1,96 Sekunden beim Zurückskalieren auf 16. Laut Projekt lässt sich damit nahezu ohne Auswirkungen auf die Serving-Leistung hoch- und herunterskalieren.
Für Betreiber großer MoE-Deployments heißt das praktisch: Die Kapazität lässt sich in kleineren GPU-Schritten anpassen, ohne die Token-Erzeugung lange anzuhalten. Die Zahlen stammen aus dem eigenen Benchmark von vLLM mit einem einzelnen Modell und einem Hardware-Setup, weitere Messungen enthält der vorliegende Quelltext nicht.
