Erzielung von Skalierung mit nahezu null Ausfallzeit in Elastic Expert Parallelism

Bisher erforderte die Änderung der Anzahl der GPUs in einem vLLM-Dienst das Hinzufügen oder Entfernen kompletter Modellreplikate oder einen Neustart der Engine mit einer anderen GPU-Anzahl. Da Modelle immer größer werden, benötigt jedes Replikat mehr GPUs, sodass die Skalierung per Replikat GPUs in immer größeren Schritten hinzufügt oder entfernt. Der Neustart von vLLM zur Skalierung von DeepSeek V4 Pro von 16 auf 20 GB200-GPUs stoppte den Dienst für 197 Sekunden (siehe den Performance-Abschnitt für Details) und ließ diese teuren GPUs zugewiesen, ohne Tokens zu generieren.

In unserem ersten Elastic-EP-Beitrag, zeigten wir, wie vLLM GPUs aus einer laufenden DEP-Bereitstellung (datenparallele Aufmerksamkeit mit expertenparallelem MoE) hinzufügen oder entfernen konnte, ohne sie neu zu starten. Obwohl wir einen Neustart vermieden, wurde der Dienst während der gesamten Rekonfiguration nonetheless unterbrochen, während wir neue Worker initialisierten, die erweiterten Kommunikationsgruppen vorbereiteten, Modellgewichte luden und Kernel-Warmup sowie CUDA-Graph-Capture wiederholten. In unserem DeepSeek-V4-Pro-Benchmark betrug diese Pause 100 Sekunden beim Skalieren von 16 auf 20 GPUs und 56 Sekunden beim Zurückskalieren auf 16 GPUs (volle Details im Performance-Abschnitt).

In diesem Beitrag beschreiben wir, wie asynchrone Vorbereitung und NIXL EP eine Elastic-EP-Rekonfiguration mit nahezu null Ausfallzeit ermöglichten. Im selben Benchmark reduzierten wir die Ausfallzeit auf 0,82 Sekunden beim Skalieren von 16 auf 20 GPUs und 1,96 Sekunden beim Zurückskalieren auf 16 GPUs, sodass wir fast ohne Auswirkung auf die Dienstleistung hoch- und runterskalieren konnten.

Überlappung der Topologie-Vorbereitung mit dem Dienstbetrieb

Wir haben den Rekonfigurationsablauf von vLLM in zwei Phasen neu organisiert: Hintergrundvorbereitung und ein kurzer Commit. Bestehende Worker nutzen separate Hintergrund-Threads, um die Zielkommunikation vorzubereiten und aufzuwärmen, Modellgewichte zu übertragen und ausführungsbezogene Informationen (wie Autotuning-Ergebnisse) mit beitretenden Workern zu synchronisieren, während sie weiterhin Anfragen mit ihren aktuellen Kommunikationsgruppen und CUDA-Graphen bedienen. Parallel dazu initialisieren sich beitretende Worker, empfangen Modellgewichte und bereiten ihre Kommunikation und GPU-Ausführung vor. Während der Commit-Phase pausiert vLLM kurz seine Scheduler, aktiviert die vorbereitete Topologie und nimmt den Dienstbetrieb wieder auf. Diese Änderungen wurden in asynchroner Vorbereitung und Prepare-/Commit-Optimierungen.

Die Vorbereitung umfasst vier Hauptaufgaben:

1. Initialisierung der beitretenden Worker. Starten ihrer Prozesse und Zuweisen von Speicher für Modell und Ausführung.
2. Vorbereitung der Kommunikation. Richten Sie die Ziel-Kommunikationsgruppen ein und erweitern Sie den EP-Kommunikator.
3. Modellgewichte übertragen. Übertragen Sie die erforderlichen Gewichte über NVLink oder RDMA von bestehenden Workern zu hinzukommenden Workern.
4. Ausführung vorbereiten. Schließen Sie die erforderliche Kompilierung, das Kernel-Warmup, das Tuning-Setup und den Aufbau der CUDA-Graphen auf den hinzukommenden Workern ab.

Nach der Commit-Phase ermöglicht asynchrones Expert Parallel Load Balancing (EPLB), dass neue Worker beginnen, Attention zu verarbeiten, während bestehende Worker die Expert-Berechnung übernehmen. Anschließend verteilt EPLB die Experten im Hintergrund über die erweiterte Gruppe neu.

Die Haupt­herausforderung besteht darin, die Kommunikation und die GPU-Ausführung vorzubereiten, ohne die Worker einzubeziehen oder zu stören, die Anfragen bedienen.

EP-Kommunikation in-place erweitern

Vor NIXL EP verwendeten die in vLLM verfügbaren EP-Kommunikations-Backends eine feste Mitgliedschaft: Jede Instanz wurde für eine bestimmte Menge von Ranks erstellt. Das Hinzufügen oder Entfernen von Ranks erfordert eine neue Instanz. Selbst wenn diese Instanz im Hintergrund erstellt werden kann, bleiben zwei Probleme bestehen.

Erstens benötigen die alte und die neue Instanz separate Kommunikationspuffer und andere Ressourcen, einschließlich Speicherregistrierungen, IPC-Handles und RDMA Queue Pairs (QPs). Das gleichzeitige Halten beider Instanzen erhöht den Kommunikationsspeicherverbrauch und erfordert eine Wiederholung des Setups, anstatt vorhandene Ressourcen wiederzuverwenden.

Zweitens ändert der Wechsel des EP-Kommunikators die Puffer und den Kommunikationszustand, die von den EP-Kommunikationskernels verwendet werden. Dadurch werden zuvor aufgezeichnete CUDA-Graphen ungültig, die vor der Wiederaufnahme des Diensts neu aufgezeichnet werden müssen. Das erfordert die Wiederholung von Warmup und Graph-Erstellung für viele Batch-Formen auf allen verbleibenden Workern. In unserem DeepSeek V4 Pro Benchmark führte die Durchführung von Warmup und Graph-Neuaufzeichnung während der Commit-Phase – selbst mit asynchroner Vorbereitung – zu Dienstpausen von 58 Sekunden beim Hochskalieren und 44 Sekunden beim Herunterskalieren.

Um diese Probleme zu lösen, haben wir NIXL EPentworfen, eine EP-Kommunikationsbibliothek, die maßgeschneidert für Elastic EP ist. Sie fügt Ranks in-place hinzu oder entfernt sie und verwendet dabei denselben NIXL-Agenten, dieselben Puffer und dieselben Verbindungen wieder. Neue Peers können verbunden werden, während bestehende Worker den Dienst weiterhin ausführen, und nur hinzukommende Peers benötigen neue Verbindungen und Registrierungen. NIXL EP hält außerdem die aufgezeichneten EP-Dispatch- und Combine-Einträge über Rekonfigurationen hinweg gültig, sodass verbleibende Worker ihre vorhandenen CUDA-Graphen weiterverwenden können.

Während der Vorbereitung verbindet vLLMs Hintergrundthread beitretende Peers, ohne sie zu aktivieren. Die Commit-Phase aktiviert dann die vorbereiteten Peers, ohne den Kommunikator zu ersetzen.

Abbildung 1. Verbinden und Aktivieren neuer EP-Peers. Grüne Ranks sind aktiv; graue Ranks sind verbunden, aber maskiert. Während der Commit-Phase werden neue Peers aktiviert, ohne den Agenten oder die Puffer zu ersetzen.

vLLM erstellt weiterhin neue DP-Koordinierungsgruppen und EPLB-Gruppen für die Zieltopologie, aber ihre Kommunikation läuft außerhalb des erfassten Modell-Forward-Passes, sodass der Wechsel zu ihnen CUDA-Graphen nicht ungültig macht.

CUDA-Graphen auf bestehenden Workern erhalten

Ein CUDA-Graph zeichnet GPU-Operationen auf, sodass vLLM einen Forward-Pass wiedergeben kann, ohne jede Operation wiederholt von der CPU aus zu starten. Ein erfasster Kernel-Knoten enthält seine Startkonfiguration und Argumentwerte, einschließlich Zeigern auf Eingabe- und Ausgabetensoren. Speicherinhalte können zwischen Wiedergaben wechseln, aber die aufgezeichneten Zeiger müssen gültig bleiben. Diese Anforderungen sind Teil des CUDA-Graph-Ausführungsvertrags.

vLLM erfasst separate Graphen für verschiedene Batch-Formen und Ausführungsmodi und führt Warmup-Forward-Pässe vor jeder Erfassung aus.

Die Bewahrung erfasster CUDA-Graphen erfordert mehr, als das Kommunikatorobjekt am Leben zu halten. NIXL EP hält auch Kernel-Startkonfigurationen, graph-sichtbare Kommunikationsargumente sowie Ein- und Ausgabetensoradressen über die Rekonfiguration hinweg stabil. Seine Kernels lesen die aktive Gruppenmitgliedschaft aus dem Gerätezustand, der direkt an Ort und Stelle aktualisiert werden kann.

Wir haben auch vLLM geändert, damit die erfassten Argumente, Startkonfigurationen sowie Ein- und Ausgabetensoradressen der umgebenden Compute-Kernels über die Rekonfiguration hinweg stabil bleiben:

• Wir verwenden die Fused-MoE-Ausführungsobjekte der beibehaltenen Worker wieder, anstatt sie für eine andere aktive EP-Größe neu zu erstellen.
• Wir halten die Adressen und Layouts graph-sichtbarer Workspaces und Dispatch-Ausgaben über die Rekonfiguration hinweg stabil, damit erfasste Expert-Kernels sie weiter verwenden können. Dispatch-Ausgaben dienen auch als Eingaben für die Expert-Berechnung. Würden sich ihre Adressen oder Layouts mit der EP-Größe ändern, würden erfasste Expert-Kernels weiterhin die alten Zeiger und Offsets verwenden.
• Wir bewahren den zugrunde liegenden Speicher der Expert-Routing-Tensoren und aktualisieren die Zuordnungen an Ort und Stelle. Dies ermöglicht es EPLB, die Zuordnungsinhalte zu ändern, ohne die von erfassten Kernels verwendeten Tensoren zu verschieben.

Zusammen ermöglichen diese Änderungen den beibehaltenen Workern, ihre vorhandenen CUDA-Graphen wiederzuverwenden sowohl nach Skalierung nach oben als auch nach unten.

Beitretende Worker unabhängig vorbereiten

Bestehende Worker haben Graphen zu erhalten. Beitretende Worker haben keine.

Beitretende Worker bereiten sich normalerweise vor, indem sie Modell-Forward-Pässe mit EP-Dispatch und Combine ausführen sowie Batch-Informationen mit anderen Workern austauschen. Diese Schritte erfordern die Teilnahme anderer Worker, aber bestehende Worker bedienen bereits echte Anfragen auf der aktuellen Topologie.

NIXL EP ermöglicht es jedem beitretenden Worker, während des Warmups und der Graphenvorbereitung vorübergehend jeden entfernten EP-Peer zu maskieren. Nur der lokale Rank dieses Workers ist für die EP-Kommunikation aktiv. Wir haben auch vLLM so geändert, dass diese Vorbereitungspässe nicht auf DP-Batch-Informationen von anderen Workern warten. Dies ermöglicht es beitretenden Workern, ihre Dummy-Batches auszuführen und CUDA-Graphen zu erfassen, ohne dass bestehende Worker teilnehmen müssen.

Abbildung 2. Grüne Ranks sind für die EP-Kommunikation aktiv; graue Ranks sind maskiert. Bestehende Worker dienen zusammen, während jeder beitretende Worker alle entfernten EP-Peers zur Vorbereitung maskiert.

Nach der Erfassung kann NIXL EP Peers reaktivieren, ohne die Graphen ungültig zu machen. Beitretende Worker verwenden ihre lokal erfassten Graphen wieder, wenn sie als Teil der erweiterten Gruppe mit der Bedienung beginnen.

Leistung auf DeepSeek V4 Pro

Alle Experimente in diesem Abschnitt verwendeten DeepSeek V4 Pro auf GB200-GPUs mit TP=1 und DP/EP-Größen von 16 und 20. Die Modellgewichte wurden im safetensors-Format vorgeladen auf gemeinsam genutztem Lustre-Speicher gespeichert und mit dem Standard- --load-format autogeladen. Die Messungen verwendeten warme Kernel-Kompilierungscaches (Triton, TileLang und FlashInfer).

Hoch- und Herunterskalierungs-Zeitpunkte

Die Tabelle zeigt, welche Stufen ausgeführt werden, während die Bedienung pausiert ist, und welche im Hintergrund ausgeführt werden, während bestehende Worker weiter bedienen.

Konfiguration C wird unterstützt nur von NIXL EP.

• Ausfallzeit: die beobachtete Unterbrechung des Servings, wenn laufende Anfragen nicht mehr voranschreiten und neue Anfragen nicht angenommen werden.
• Gesamtzeit: die Dauer des gesamten Skalierungsvorgangs, einschließlich der Vorbereitung.

Die beiden Zeiträume werden separat gemessen.

Alle Konfigurationen bestanden die numerischen Korrektheitsprüfungen, einschließlich Prüfungen auf jedem beitretenden Worker.

Einhaltung des SLO beim Hinzufügen von GPUs

Wir bedienten DeepSeek V4 Pro auf 16 GPUs und erhöhten dann schrittweise die eingehende AnfragRate von etwa 8 auf 16 Anfragen pro Sekunde. Wir spielten dasselbe Szenario mit 11,391 Anfragen gegen drei Deployments ab: eines blieb bei 16 GPUs, eines startete mit 20 GPUs neu, und eines skalierte mit Elastic EP und NIXL EP auf 20 GPUs. Das Service-Level-Ziel (SLO) war ein rollierender p95 Time-to-First-Token unter 5 Sekunden.

Abbildung 3. End-to-End-Serving unter steigender Anfragelast. Die Kurven zeigen 30-Sekunden-rollierende p95-Ergebnisse, wobei fehlgeschlagene Anfragen mit einer 30-Sekunden-Strafe statt eines gemessenen TTFT belegt wurden.

• Elastic EP schloss alle 11,391 Anfragen ab und blieb während des gesamten Szenarios unter dem SLO.
• Während der Vorbereitung entsprach Elastic EP der Serving-Leistung des statischen 16-GPU-Deployments, ohne sichtbare Beeinträchtigung durch die Hintergrundvorbereitung.
• Nach der Skalierung entsprach Elastic EP der Leistung des wiederhergestellten 20-GPU-Deployments, ohne sichtbare Beeinträchtigung nach der Skalierung.

Elastic EP ausprobieren

Hintergrundvorbereitung, CUDA-Graph-Wiederverwendung und unabhängige Grapherfassung auf beitretenden Workern sind heute in den neuesten vLLM - und NIXL -Releases verfügbar. Installieren Sie sie mit pip und beginnen Sie, Elastic EP zu verwenden.

Ein vollständiges Verwendungsbeispiel finden Sie im cuda_graphs_heavy_nixl_ep Fall in vLLMs Elastic-EP-Test. Das Beispiel enthält die Serverkonfiguration und die Skalierungs-API-Aufrufe. Es skaliert von zwei auf vier GPUs und zurück, während Anfragen gesendet werden, und prüft das Serving während der Vorbereitung sowie die Modellgenauigkeit um jede Größenänderung.

Was kommt als Nächstes

Warme Worker mit Dynamo Snapshot wiederherstellen

Wir haben die lange Serving-Unterbrechung effektiv gelöst. Die nächste Herausforderung ist, neue Kapazität schneller bereitstellen zu können. Wir planen, zu integrieren Dynamo Snapshot sodass beitretende Worker den initialisierten Prozess- und CUDA-Zustand wiederherstellen können, statt Kompilierung, Kernel-Warmup, Graph-Erstellung und andere Startarbeiten zu wiederholen.

Die Kommunikation für die Ziel-Topologie muss separat vorbereitet werden, da sie nicht aus dem Snapshot wiederhergestellt wird. Die Wiederherstellung großer Modellgewichte aus dem Checkpoint-Speicher kann die Wiederherstellungszeit dominieren, daher planen wir, Elastic EPs GPU-zu-GPU-Gewichtsübertragung von bestehenden Workern beizubehalten.

State-of-the-art-EP-Kommunikation mit NIXL EP erreichen

Wir streben mit NIXL EP eine State-of-the-art-Leistung bei Dispatch und Combine an und behalten dabei die volle Unterstützung für Elastic EP und Fehlertoleranz bei. Ein bevorstehendes NIXL-EP-Leistungsupdate ist der nächste Schritt in Richtung dieses Ziels (siehe die NIXL EP roadmap RFC).

Elastic EP mit Dynamo- und llm-d-Orchestrierung verbinden

Mit der vorhandenen Fähigkeit auf Engine-Ebene besteht der nächste Schritt darin, Elastic EP aus Orchestrator-Autoscalern zu nutzen. Die Arbeit an dieser Integration läuft bereits in den Communities von vLLM, Dynamo und llm-d.

Zu diesen Bemühungen gehören vLLMs Arbeit am External-Load-Balancer und Dynamos Elastic-EP-Vorschlag.

Wenn Sie Inferenz im großen Maßstab betreiben, empfehlen wir Ihnen, Elastic EP auszuprobieren und uns Ihre Workloads und betrieblichen Anforderungen mitzuteilen. Wenn Sie Inferenz-Infrastruktur aufbauen, freuen wir uns über Beiträge zu vLLM Elastic EP und NIXL EP. Bringen wir Elastic EP in den Produktiveinsatz.

Danksagungen

• Tyler Michael Smith und Sage Moore von Red Hat für ihr unschätzbares Feedback und ihre gründlichen Reviews während dieser Arbeit.
• Linoy Geva (NVIDIA) für ihre Arbeit an der Serving-Performance während der Vorbereitung.
• Das gesamte NIXL-Team für seine Bemühungen rund um NIXL EP.
• Tzu-Ling Kan, Julien Mancuso und das gesamte Dynamo-Team für ihre Bemühungen, Elastic EP in Dynamo zu unterstützen.