vLLM Elastic Expert Parallelism がほぼゼロダウンタイムのスケーリングを実現

従来の大規模言語モデルのスケーリングでは、サービスの再起動やモデルレプリカ全体の追加・削除が必要であり、その結果、大きなサービスのダウンタイムが発生していました。NIXL EP を搭載した vLLM の新しい Elastic Expert Parallelism（Elastic EP）アーキテクチャは、実行中のデプロイメントで GPU を追加または削除することを最小限の中断で可能にし、スケーリングのダウンタイムを 2 秒未満に短縮します。

スケーリングアーキテクチャ: 非同期準備とコミット

ほぼゼロダウンタイム機能の中核は、vLLM の再構成フローを、バックグラウンド準備と短いコミットという 2 つの明確なフェーズに再編成することです。バックグラウンド準備フェーズでは、既存のワーカーがリクエストの処理を継続している間に、別のスレッドがターゲットトポロジの準備、モデルウェイトの転送、新しいワーカーのウォームアップを行います。コミットフェーズは短い一時停止であり、vLLM は準備されたトポロジをアクティブ化してから、サービスの提供を再開します。

準備には、以下の 4 つの主要なタスクが非同期で実行されます。

参加ワーカーの初期化: 新しいワーカープロセスを開始し、必要なモデルおよび実行ストレージを割り当てます。
通信の準備: ターゲット通信グループを設定し、Expert Parallel（EP）コミュニケータを拡張します。
モデルウェイトの転送: 必要なモデルウェイトを既存のワーカーから参加ワーカーに NVLink または RDMA 経由で転送します。
実行の準備: 参加ワーカーでカーネルコンパイル、ウォームアップ、チューニングセットアップ、CUDA グラフ構築を完了します。

コミットフェーズの後、Asynchronous Expert Parallel Load Balancing（EPLB）が引き継ぎ、新しいワーカーがアテンションを処理し、既存のワーカーがエキスパート計算を管理し、その後、エキスパートのバックグラウンド再分散が行われます。

NIXL EP がインプレース通信拡張を可能にする

NIXL EP は、固定メンバーシップの通信バックエンドの制限を解決するために設計された、専門的な EP 通信ライブラリです。以前は、ランクを追加または削除するには、まったく新しい通信インスタンスを作成する必要があり、メモリ使用量の増加と既存の CUDA グラフの無効化につながっていました。

NIXL EP は、同じ NIXL エージェント、バッファ、接続を再利用しながら、ランクをその場で追加または削除することで、これらの問題を解決します。これにより、既存のワーカーがサービスの提供を継続している間に、新しいピアが接続できるようになります。重要なのは、NIXL EP は、キャプチャされた EP ディスパッチおよびコンバインエントリを再構成全体で有効に保つため、維持されたワーカーは、ウォームアップとグラフ構築を繰り返すことなく、既存の CUDA グラフを再利用できることです。

準備中、vLLM のバックグラウンドスレッドは、参加ピアをアクティブ化せずに接続します。コミットフェーズでは、コアコミュニケータを置き換えることなく、準備されたピアをアクティブ化します。

既存ワーカーでの CUDA グラフの保持

CUDA グラフは GPU 操作を記録するため、vLLM は CPU 側の起動を繰り返すことなくフォワードパスを再生できます。スケーリング中にこれらのグラフを保持するには、再構成プロセス全体で安定性を維持する必要があります。NIXL EP は、カーネル起動構成、グラフ可視の通信引数、および入出力テンソルのアドレスがスケーリングイベント全体で安定したままであることを保証します。

vLLM でこれらのグラフを保持するために実装された具体的な変更は次のとおりです。

保持されたワーカーの fused-MoE 実行オブジェクトを、異なるアクティブ EP サイズ用に再構築する代わりに再利用します。
グラフ可視のワークスペースとディスパッチ出力のアドレスとレイアウトを安定させ、EP サイズが変更されても、キャプチャされたエキスパートカーネルが正しいポインタを使用するようにします。
エキスパートルーティングテンソルのバッキングストレージを保持し、マッピングをその場で更新することで、EPLB がキャプチャされたカーネルで使用されるテンソルを移動せずにマッピングを変更できるようにします。

これらの対策により、保持されたワーカーは、スケールアップとスケールダウンの両方の後に、既存の CUDA グラフを再利用できます。

参加ワーカーの独立した準備

参加ワーカーは、実行を準備して CUDA グラフをキャプチャする必要がありますが、実際のリクエストを処理している既存のワーカーに依存することはできません。NIXL EP は、ウォームアップとグラフ準備中に各参加ワーカーがリモートの EP ピアを一時的にマスクできるようにすることで、独立した準備を容易にします。これにより、EP 通信のためにワーカーのローカルランクが分離されます。

さらに、vLLM は、これらの準備パスが他のワーカーからの Data Parallel（DP）バッチ情報を待たないように変更されました。これにより、参加ワーカーは、既存のワーカーが準備プロセスに参加することを要求せずに、ダミーバッチを実行して CUDA グラフをキャプチャできます。

DeepSeek V4 Pro でのパフォーマンスベンチマーク

実験は GB200 GPU 上の DeepSeek V4 Pro を使用して実施され、Blocking（A）、Async preparation（B）、Async preparation + graph reuse（C）の 3 つの構成を比較しました。NIXL EP でのみサポートされる構成 C は、大幅なパフォーマンス向上を示しました。

ダウンタイムの削減

メトリクス	A: Blocking	B: Async preparation	C: Async preparation + graph reuse
16 から 20 GPU: ダウンタイム	99.62 秒	58.04 秒	0.82 秒
20 から 16 GPU: ダウンタイム	56.25 秒	44.07 秒	1.96 秒

16 から 20 GPU へのスケーリングでは、観測されたサービスの中断（ダウンタイム）が 99.62 秒から 0.82 秒に短縮されました。20 から 16 GPU へのスケールバックでは、ダウンタイムが 56.25 秒から 1.96 秒に短縮されました。

サービスレベル目標（SLO）の維持

リクエスト負荷が上昇するエンドツーエンドのサービングシナリオにおいて、Elastic EP はスケーリングプロセス全体を通じて、ローリング p95 の Time to First Token を 5 秒未満に保つというサービスレベル目標（SLO）を維持しました。準備中、Elastic EP は静的 16 GPU デプロイメントのサービングパフォーマンスに一致し、スケーリング後は、回復した 20 GPU デプロイメントのパフォーマンスに一致しました。

将来の方向性

今後の開発は、ワーカーの起動の高速化と通信パフォーマンスの向上という 2 つの主要な領域に焦点を当てています。

Dynamo Snapshot によるウォームワーカーの復元: 次の課題は、新しいキャパシティが準備完了になるまでの時間を短縮することです。チームは、Dynamo Snapshot を統合して、参加ワーカーがコンパイル、カーネルウォームアップ、グラフ構築を繰り返す代わりに、初期化されたプロセスと CUDA 状態を復元できるようにすることを計画しています。
最先端の EP 通信: 目標は、Elastic EP とフォールトトレランスの完全なサポートを維持しながら、NIXL EP で最先端のディスパッチおよびコンバイン性能を達成することです。

SUMMARY: vLLM は NIXL EP を使用した Elastic Expert Parallelism（Elastic EP）を導入し、大規模な MoE モデルのシームレスなスケーリングをほぼゼロダウンタイムで可能にし、スケーリングの一時停止を数百秒から 2 秒未満に短縮しました。

TITLE: vLLM Elastic Expert Parallelism がほぼゼロダウンタイムのスケーリングを実現