従来、vLLMサービスのGPU数を変更するには、モデルレプリカ全体を追加または削除するか、異なるGPU数でエンジンを再起動する必要がありました。モデルが大きくなるほど各レプリカにより多くのGPUが必要となるため、レプリカ単位のスケーリングでは、ますます大きな単位でGPUが追加・削除されることになります。DeepSeek V4 Proを16基から20基のGB200 GPUへスケールさせるためにvLLMを再起動すると、 197秒 間サービスが停止し（詳細は パフォーマンスセクション を参照）、高価なGPUが割り当てられたままトークンを生成しない状態が続きました。
最初のElastic EPの投稿 では、実行中のDEPデプロイメント（データ並列アテンションとエキスパート並列MoE）に対し、再起動なしでvLLMがGPUを追加・削除できることを示しました。再起動は避けられましたが、新しいワーカーの初期化、拡張された通信グループの準備、モデル重みのロード、カーネルのウォームアップとCUDAグラフキャプチャの再実行を行う間、再構成中はサービスが停止していました。DeepSeek V4 Proのベンチマークでは、この停止は、稼働中のDEPデプロイメント（データ並列アテンションとエキスパート並列MoEの組み合わせ）に対して、vLLMが再起動なしでGPUを追加・削除できる仕組みを紹介しました。再起動は避けられたものの、新しいワーカーの初期化、拡張された通信グループの準備、モデルウェイトのロード、そしてカーネルウォームアップとCUDAグラフキャプチャの再実行の間、再構成の間はサービングが停止していました。DeepSeek V4 Proのベンチマークでは、この停止は 16基から20基へスケールする際には100秒 16基へのスケールバック時には56秒 16基へ戻してスケールダウンする際には56秒 パフォーマンスセクション を参照）。本投稿では、非同期準備と).
NIXL EP によってほぼゼロダウンタイムのElastic EP再構成を実現した方法について説明します。同じベンチマークにおいて、ダウンタイムを 16基から20基へのスケール時には0.82秒 16基から20基へスケールする際には0.82秒 16基へのスケールバック時には1.96秒 16基へ戻してスケールダウンする際には1.96秒トポロジー準備とサービス提供のオーバーラップ
私たちはvLLMの再構成フローを、バックグラウンド準備と短いコミットの2つのフェーズに再編しました。既存のワーカーは個別のバックグラウンドスレッドを使用して、ターゲット通信の準備とウォームアップ、モデル重みの転送、実行関連情報（autotuningの結果など）の参加ワーカーとの同期を行い、その間も現在の通信グループとCUDAグラフでリクエストの処理を継続します。並行して、参加ワーカーは初期化を行い、モデル重みを受け取り、通信とGPU実行の準備をします。コミットフェーズでは、vLLMはスケジューラを短時間一時停止し、準備済みのトポロジーを有効化して、サービスを再開します。これらの変更は
我々はvLLMの再構成フローを、バックグラウンドでの準備と短いコミットという2つのフェーズに再編しました。既存のワーカーは独立したバックグラウンドスレッドを使って、ターゲットとなる通信の準備とウォームアップ、モデルウェイトの転送、実行関連情報（自動チューニング結果など）の参加するワーカーとの同期を行いながら、現在の通信グループとCUDAグラフを使ってリクエストの処理を継続します。並行して、参加するワーカーは初期化を行い、モデルウェイトを受け取り、通信とGPU実行の準備を整えます。コミットフェーズでは、vLLMはスケジューラを短時間一時停止し、準備済みのトポロジを有効化して、サービングを再開します。これらの変更は と prepare/commit optimizations で導入されました。.
準備は次の4つの主要タスクをカバーします：
- 参加ワーカーを初期化する。 プロセスを開始し、モデルと実行のためのストレージを割り当てる。
- 通信を準備する。 対象の通信グループを設定し、EP コミュニケーターを拡張します。
- モデルの重みを転送します。 既存のワーカーから参加するワーカーへ、必要な重みを NVLink または RDMA 経由で転送します。
- 実行の準備。 参加するワーカー上で、必要なコンパイル、カーネルのウォームアップ、チューニングのセットアップ、CUDAグラフの構築を完了します。
コミットフェーズの後、非同期のExpert Parallel Load Balancing（EPLB）により、新しいワーカーがアテンションの処理を開始し、既存のワーカーがエキスパート計算を処理できるようになります。その後、EPLBは拡張されたグループ全体に対してエキスパートの再分散をバックグラウンドで行います。
主な課題は、リクエストを処理しているワーカーに関与したり中断したりすることなく、通信とGPU実行を準備することです。
その場でEP通信を拡張する
NIXL EP以前、vLLMで利用可能だったEP通信バックエンドは固定メンバーシップを使用していました。つまり、各インスタンスは特定のランクのセットのために作成されるものでした。ランクの追加や削除には新しいインスタンスが必要です。そのインスタンスをバックグラウンドで作成できる場合でも、2つの問題が残ります。
まず、旧インスタンスと新インスタンスには、メモリ登録、IPCハンドル、RDMAキュー Pair(QP)を含む通信バッファやその他のリソースがそれぞれ別個に必要です。両方のインスタンスを稼働させ続けると、通信用メモリの使用量が増加し、既存のリソースを再利用するのではなく、セットアップを繰り返す必要が生じます。
第二に、EPコミュニケータの切り替えは、EP通信カーネルが使用するバッファおよび通信状態を変更します。これにより、以前キャプチャされたCUDAグラフが無効化され、提供を再開する前に再キャプチャが必要になります。そのため、保持されている全ワーカーにわたって、多くのバッチ形状についてウォームアップとグラフ構築を繰り返す必要があります。私たちのDeepSeek V4 Proベンチマークでは、非同期準備を行った場合であっても、コミットフェーズ中にウォームアップとグラフの再キャプチャを実行すると、提供の停止が発生しました。 スケールアップ時に58秒 および スケールダウン中の44秒.
これらの問題を解決するために、我々は設計しました NIXL EPElastic EP 向けに特別に作られた EP 通信ライブラリです。同じ NIXL エージェント、バッファ、接続を再利用しながら、ランクをその場で追加・削除します。既存のワーカーがサービスを継続している間に新しいピアを接続でき、新規参加ピアのみが新しい接続と登録を必要とします。NIXL EP はまた、再構成の際もキャプチャされた EP の dispatch および combine エントリを有効なまま維持するため、残存するワーカーは既存の CUDA グラフを再利用できます。
準備段階では、vLLMのバックグラウンドスレッドが参加するピアに接続しますが、ピアはまだアクティブ化しません。その後、コミット段階で準備済みのピアを、コミュニケーターを置き換えることなくアクティブ化します。
図1。新しいEPピアの接続とアクティベーション。緑のランクはアクティブ、灰色のランクは接続済みだがマスクされています。コミットフェーズでは、エージェントやバッファを置き換えることなく新しいピアがアクティブ化されます。
vLLM は依然として、対象トポロジに向けて新たな DP 調整グループと EPLB グループを作成します。 ただし、その通信はキャプチャされたモデルのフォワードパスの外側で行われるそのため、これらに切り替えてもCUDAグラフが無効になることはありません。
既存のワーカー上のCUDAグラフを保持する
CUDAグラフはGPU操作を記録することで、vLLMがCPUから各操作を繰り返し起動することなくフォワードパスを再生できるようにします。キャプチャされたカーネルノードには、起動設定と引数の値、入力テンソルと出力テンソルへのポインタが含まれます。再生の間にメモリの内容は変化しうりますが、記録されたポインタは有効なままでなければなりません。これらの要件は以下の一部です。 CUDA グラフ実行契約.
vLLM 異なるバッチ形状および実行モードごとに個別のグラフをキャプチャします 各キャプチャの前にウォームアップのフォワードパスを実行します。
キャプチャしたCUDAグラフを保持するには、コミュニケータオブジェクトを生存させ続けるだけでは不十分です。NIXL EPは、再設定を跨いでもカーネル起動構成、グラフから見える通信引数、入出力テンソルのアドレスを安定に保ちます。そのカーネルは、インプレースで更新可能なデバイス状態からアクティブなグループのメンバーシップを読み取ります。
reconfigure時にも、周囲のcomputeカーネルの取得済み引数、launch設定、入出力テンソルのアドレスを安定に保つよう、vLLMも変更しました:
- 保持されたワーカーのfused-MoE実行オブジェクトを再利用し、異なるアクティブEPサイズ向けに再構築することはしません。
- グラフ可視のワークスペースおよびディスパッチ出力のアドレスとレイアウトは、再構成を跨いで安定させています。これは、キャプチャされたエキスパートカーネルがそれらを使い続けられるようにするためです。ディスパッチ出力はエキスパート計算の入力としても機能します。そのアドレスやレイアウトが EP サイズに応じて変わってしまうと、キャプチャされたエキスパートカーネルが依然として古いポインタとオフセットを使い続けることになります。
- エキスパートルーティングテンソルのバッキングストレージを保持し、マッピングをインプレースで更新します。これにより、EPLBはキャプチャされたカーネルが使用するテンソルを移動することなく、マッピングの内容を変更できます。
これらの変更が相まって、雇用され残った労働者は 既存のCUDAグラフを再利用する スケールアップとスケールダウンの両方の後。
独立して参入する労働者を準備する
既存のワーカーには維持すべきグラフがあります。新しく参加するワーカーにはそれがありません。
参加するワーカーは、通常、EP dispatchおよびcombineを用いたモデルのforward passを実行し、他のワーカーとバッチ情報を交換することで準備を行います。これらのステップには他のワーカーの参加が必要ですが、既存のワーカーは現在のトポロジー上で実際のリクエストを処理中です。
NIXL EPでは、参加する各ワーカーがウォームアップおよびグラフ準備の間、一時的にすべてのリモートEPピアをマスクできるようにしています。EP通信にはそのワーカーのローカルランクのみがアクティブになります。さらに、これらの準備パスが他のワーカーからのDPバッチ情報を待機しないようvLLMを修正しました。これにより、既存のワーカーの参加を必要とせずに、参加するワーカーがダミーバッチを実行し、CUDAグラフをキャプチャできます。
Figure 2. 緑のランクはEP通信に有効な状態を示し、灰色のランクはマスクされた状態を示します。既存のワーカーは共同で処理を続け、新たに参加する各ワーカーは準備のためにすべてのリモートEPピアをマスクします。
キャプチャ後、NIXL EPはグラフを無効化することなくピアを再アクティブ化できます。参加するワーカーは、拡張されたグループの一員としてサービスを開始する際に、ローカルでキャプチャ済みのグラフを再利用します。
DeepSeek V4 Proでのパフォーマンス
本セクションのすべての実験では DeepSeek V4 Pro GB200 GPU上で、TP=1、DP/EPサイズ16および20で実行した。モデルの重みはsafetensors形式で共有Lustreストレージに事前ダウンロードされ、デフォルトの設定で読み込まれた。 --load-format auto. 測定にはウォームなカーネルコンパイルキャッシュ(Triton、TileLang、FlashInfer)を使用した。
スケールアップとスケールダウンの所要時間
この表は、どのステージが提供（サービング）の一時停止中に実行され、どのステージが既存のワーカーが提供を継続する間にバックグラウンドで実行されるかを示しています。
| ステージ | A: ブロッキング | B: 非同期準備 | C: 非同期準備 + グラフ再利用 |
|---|---|---|---|
| 参加するワーカーの初期化 | 提供の一時停止中 | バックグラウンド | バックグラウンド |
| ターゲットとの通信を準備 | サービング一時停止 | バックグラウンド | バックグラウンド |
| モデルの重みを転送 | サービング一時停止 | バックグラウンド | バックグラウンド |
| 参加するワーカーでのウォームアップとグラフキャプチャ | サービング一時停止 | サービング一時停止 | バックグラウンド |
| 既存のワーカーでのウォームアップとグラフキャプチャ | サービング一時停止 | サービング一時停止 | 不要（既存のグラフは有効のまま） |
| ターゲットのトポロジーを有効化 | サービング一時停止 | サービング一時停止 | サービング一時停止 |
構成 C がサポートされるのは NIXL EP のみ.
- ダウンタイム： 処理中のリクエストが進行を停止し、新しいリクエストが受け付けられない、観測されたサービング中断のこと。
- 合計時間： 準備を含むスケーリング操作全体の所要時間のこと。
この 2 つの時間は別々に測定されます。
| 指標 | A: ブロッキング | B: 非同期準備 | C: 非同期準備 + グラフ再利用 |
|---|---|---|---|
| 16 ～ 20 GPU の場合のダウンタイム | 99.62 秒 | 58.04 秒 | 0.82 秒 |
| GPU 20基〜16基：ダウンタイム | 56.25 秒 | 44.07秒 | 1.96秒 |
| 16〜20基のGPU:合計時間 | 99.72 秒 | 97.27秒 | 92.34秒 |
| 20〜16基のGPU：合計時間 | 56.21秒 | 51.46秒 | 9.32秒 |
すべての構成が数値の正確性チェックに合格しました。これには各 joining worker に対するチェックも含まれます。
GPUを追加しながらSLOを維持する
私たちはDeepSeek V4 Proを16基のGPUで運用し、その後、着信リクエスト率を毎秒約8から16リクエストへと段階的に引き上げました。同じ11,391リクエストのシナリオを3つのデプロイメントに対して再生しました。1つは16基のGPUのまま維持し、1つは20基のGPUで再起動し、もう1つはElastic EPとNIXL EPを使用して20基のGPUへスケールしました。サービスレベル目標(SLO)は、ローリングp95の最初のトークンまでの時間を5秒未満とすることでした。
図3：リクエスト負荷の増加に伴うエンドツーエンドの提供。曲線は30秒のローリングp95の結果を示し、失敗したリクエストには測定されたTTFTではなく30秒のペナルティが割り当てられています。
- Elastic EPは11,391件のリクエストをすべて完了し、シナリオ全体を通じてSLOを下回り続けました。
- 準備中、Elastic EPは静的な16 GPU構成のサービング性能と同等であり、バックグラウンドでの準備による目立った性能低下は見られませんでした。
- スケーリング後、Elastic EPは復旧した20 GPU構成と同等のパフォーマンスを達成し、スケール後の性能低下は見られませんでした。
Elastic EPを試す
バックグラウンド準備、CUDAグラフの再利用、および合流するワーカー上での独立したグラフキャプチャは、すべて最新の vLLM および NIXL pipでインストールし、Elastic EPを使い始めましょう。
完全な使用例については、以下をご覧ください: cuda_graphs_heavy_nixl_ep vLLMのElastic EPテストにおけるケース。この例には、サーバー構成とスケーリングAPI呼び出しが含まれています。リクエストの送信中に2基のGPUから4基へ、そして再び2基へとスケールし、各リサイズの前後にサービングの状況とモデルの精度を確認します。
次に何が来るか
Dynamo Snapshotでウォームなワーカーを復元
私たちは長時間のサービング中断を事実上解決しました。次の課題は、新しいキャパシティをより早く準備できるようにすることです。私たちは統合を計画しています Dynamo スナップショット これにより、追加で参加するワーカーは初期化済みのプロセスと CUDA 状態を復元でき、コンパイル、カーネルのウォームアップ、グラフ構築などの起動作業を繰り返さずに済みます。
ターゲットトポロジ向けの通信は、スナップショットから復元されないため、別途準備する必要があります。チェックポイントストレージからの大規模モデルの重みの復元は復元時間の大半を占める可能性があるため、既存のワーカーからの Elastic EP の GPU 間重み転送を維持する計画です。
NIXL EP で最先端の EP 通信を実現する
私たちは、Elastic EP とフォールトトレランスの完全なサポートを維持しながら、NIXL EP で最先端の dispatch と combine のパフォーマンスを目指しています。今後予定されている NIXL EP のパフォーマンス更新は、その目標に向けた次のステップです（詳しくは NIXL EP ロードマップ RFC).
Elastic EP を Dynamo と llm-d のオーケストレーションに接続する
エンジンレベルの機能が整ったところで、次のステップはオーケストレーターのオートスケーラーから Elastic EP を利用できるようにすることです。この統合に向けた取り組みは、すでに vLLM、Dynamo、llm-d の各コミュニティを横断して進められています。
これらの取り組みには、 vLLM の外部ロードバランサーに関する取り組み や Dynamo の Elastic EP 提案.
大規模に推論を実行している場合は、Elastic EP を試し、ワークロードと運用要件を共有していただけることをお勧めします。推論インフラを構築されている場合は、vLLM Elastic EP および NIXL EP への貢献を歓迎します。Elastic EP を本番環境で動かしましょう。
謝辞
- Red Hat の Tyler Michael Smith 氏と Sage Moore 氏に、この作業を通じて貴重なフィードバックと綿密なレビューをいただきました。
- Linoy Geva 氏(NVIDIA)に、準備中のサービング性能に関する取り組みをいただきました。
- NIXL EP における取り組みに対し、NIXL チームの皆様に感謝します。
- Tzu-Ling Kan 氏、Julien Mancuso 氏、および Dynamo チームの皆様に、Dynamo における Elastic EP のサポートへの取り組みをいただきました。