vLLM は NIXL EP により Elastic Expert Parallelism でほぼゼロダウンタイムのスケーリングを実現
vLLM は、NIXL EP と 2 フェーズの再構成フローを実装することで、ほぼゼロダウンタイムの Elastic Expert Parallelism (EP) を導入しました。これにより、大規模言語モデルはサービスのパフォーマンスを中断することなく GPU リソースをスケーリングできます。
Expert Parallelism における従来のスケーリングの課題
従来、vLLM サービスをスケーリングするには、モデルレプリカ全体を追加または削除するか、異なる GPU 数でエンジンを再起動する必要がありました。このプロセスでは、サービスに大きなダウンタイムが発生し、本番環境の推論ワークロードでは許容できません。
たとえば、DeepSeek V4 Pro を 16 台から 20 台の GB200 GPU にスケーリングするために vLLM を再起動すると、197 秒間のサービス停止が発生しました。完全な再起動を回避するこれまでの取り組みでも、依然としてかなりの一時停止が発生していました。16 台から 20 台へのスケーリングには 100 秒、16 台へのスケールダウンには 56 秒かかりました。
Elastic EP 再構成アーキテクチャ
新しい Elastic EP システムは、再構成フローをバックグラウンド準備と短いコミットの 2 つの明確なフェーズに再編成します。このアーキテクチャにより、必要な変更がバックグラウンドで準備されている間、既存のワーカーはリクエストの処理を継続できます。
バックグラウンド準備: 既存のワーカーは、専用のバックグラウンドスレッドを使用して、ターゲットの通信を準備してウォームアップし、モデルの重みを転送し、実行の詳細 (オートチューニング結果など) を参加するワーカーと同期します。同時に、参加するワーカーは初期化し、モデルの重みを受け取り、通信と GPU 実行を準備します。
短いコミットフェーズ: コミットフェーズ中、vLLM はスケジューラを一時的に一時停止し、準備されたトポロジをアクティブ化して、サービスの提供を再開します。この一時停止は、以下で詳述する技術的革新により最小限に抑えられます。
NIXL EP: インプレースでの通信拡張
vLLM の以前の EP 通信バックエンドは固定メンバーシップを使用していたため、ランクを追加または削除するには、まったく新しい通信インスタンスを作成する必要がありました。これにより、古いインスタンスと新しいインスタンスを維持するための通信メモリ使用量の増加と、以前にキャプチャされた CUDA グラフの無効化という 2 つの大きな問題が発生しました。
NIXL EP は、これらの問題を解決するために Elastic EP 専用に設計され、同じ NIXL エージェント、バッファ、接続を再利用しながら、ランクをその場で追加または削除します。これにより、既存のワーカーがサービスを継続している間に、新しいピアが接続できます。
重要なのは、NIXL EP により、EP ディスパッチとコンバインのエントリが再構成後も有効に保たれることです。これにより、CUDA グラフの無効化が防止されます。従来は、非同期準備を行っても、コミットフェーズ中にウォームアップとグラフ構築を繰り返す必要があり、スケールアップ時に 58 秒、スケールダウン時に 44 秒の一時停止が発生していました。
既存ワーカーでの CUDA グラフの保持
CUDA グラフは GPU 操作を記録するため、vLLM は CPU から操作を繰り返し起動することなくフォワードパスを再生できます。スケーリング全体でこれらのグラフを維持するには、コミュニケータオブジェクトを超えた安定性の維持が必要です。
これを実現するために、vLLM は再構成中にキャプチャされた引数、起動構成、入力および出力テンソルのアドレスを安定に保つためのいくつかの変更を実装しました。
- 維持されるワーカーは、異なるアクティブな EP サイズ用に再構築する代わりに、融合 MoE 実行オブジェクトを再利用します。
- グラフから参照されるワークスペースとディスパッチ出力のアドレスとレイアウトは安定しており、キャプチャされたエキスパートカーネルが正しいポインタとオフセットを使用することが保証されます。
- エキスパートルーティングテンソルのバッキングストレージが保持されるため、Expert Parallel Load Balancing (EPLB) は、キャプチャされたカーネルで使用されるテンソルを移動せずにマッピングの内容を変更できます。
これらの変更により、保持されたワーカーは、スケールアップとスケールダウンの両方の後に既存の CUDA グラフを再利用できます。
参加ワーカーの独立した準備
参加するワーカーは、通常、準備のために他のワーカーがモデルのフォワードパスに参加する必要があります。NIXL EP により、各参加ワーカーは、ウォームアップとグラフ準備中にすべてのリモート EP ピアを一時的にマスクできます。この分離により、参加ワーカーは、EP 通信にローカルランクのみをアクティブにして、ダミーバッチを実行し、CUDA グラフをキャプチャできます。
この変更により、参加ワーカーは、既存のワーカーが実際のリクエストを処理している間に、既存のワーカーが準備プロセスに参加する必要なく CUDA グラフをキャプチャできます。
DeepSeek V4 Pro でのパフォーマンスベンチマーク
GB200 GPU (TP=1、DP/EP サイズ 16 および 20) で DeepSeek V4 Pro を使用した実験では、NIXL EP によってサービスダウンタイムが劇的に短縮されることが実証されました。
| メトリクス | A: ブロッキング | B: 非同期準備 | C: 非同期準備 + グラフ再利用 |
|---|---|---|---|
| 16 から 20 GPU: ダウンタイム | 99.62 秒 | 58.04 秒 | 0.82 秒 |
| 20 から 16 GPU: ダウンタイム | 56.25 秒 | 44.07 秒 | 1.96 秒 |
| 16 から 20 GPU: 合計時間 | 99.72 秒 | 97.27 秒 | 92.34 秒 |
| 20 から 16 GPU: 合計時間 | 56.21 秒 | 51.46 秒 | 9.32 秒 |
NIXL EP を利用する構成 C は、ほぼゼロダウンタイムを達成し、スケールアップの一時停止を 58.04 秒から 0.82 秒に、スケールダウンの一時停止を 44.07 秒から 1.96 秒に短縮しました。
さらに、リクエスト負荷が増加するエンドツーエンドのサービングシナリオでは、Elastic EP はスケーリングプロセス全体を通じて、ローリング p95 の Time to First Token が 5 秒未満というサービスレベル目標 (SLO) を下回り続けました。準備中、Elastic EP は静的 16 GPU デプロイメントのサービングパフォーマンスに一致し、スケーリング後は回復した 20 GPU デプロイメントのパフォーマンスに一致しました。
今後の方向性
vLLM チームは、Elastic EP 機能をさらに強化するためのいくつかの次のステップを概説しています。
- Dynamo Snapshot によるウォームワーカーの復元: Dynamo Snapshot を統合することで、参加するワーカーが初期化されたプロセスと CUDA 状態を復元できるようになり、コンパイル、カーネルのウォームアップ、グラフ構築を繰り返す必要がなくなります。
- 最先端の EP 通信: チームは、Elastic EP とフォールトトレランスの完全なサポートを維持しながら、NIXL EP で最先端のディスパッチおよびコンバインのパフォーマンスを達成することを目指しています。
- オーケストレーター統合: 次のステップは、Elastic EP をオーケストレーターのオートスケーラーに接続し、vLLM を Dynamo や llm-d などのシステムと統合することです。
NIXL EP: インプレースでの通信拡張
vLLM の従来の EP 通信バックエンドは固定メンバーシップを使用していたため、ランクを追加または削除するには、まったく新しい通信インスタンスを作成する必要がありました。これにより、古いインスタンスと新しいインスタンスを維持するための通信メモリ使用量の増加と、以前にキャプチャされた CUDA グラフの無効化という 2 つの大きな問題が発生しました。
NIXL EP は、これらの問題を解決するために Elastic EP 専用に設計され、同じ NIXL エージェント、バッファ、接続を再利用して、ランクをその場で追加または削除します。これにより、既存のワーカーがサービスを継続している間に、新しいピアが接続できます。
重要なのは、NIXL EP により、キャプチャされた EP ディスパッチとコンバインのエントリが再構成後も有効に保たれることです。これにより、CUDA グラフの無効化が防止されます。従来は、非同期準備を行っても、コミットフェーズ中にウォームアップとグラフ構築を繰り返す必要があり、スケールアップ時に 58 秒、スケールダウン時に 44 秒の一時停止が発生していました。
既存ワーカーでの CUDA グラフの保持
CUDA グラフは GPU 操作を記録するため、vLLM は CPU から操作を繰り返し起動することなくフォワードパスを再生できます。スケーリング全体でこれらのグラフを維持するには、コミュニケータオブジェクトだけでなく、安定性を維持する必要があります。
これを実現するために、vLLM は再構成中にキャプチャされた引数、起動構成、入力および出力テンソルのアドレスを安定に保つためのいくつかの変更を実装しました。
- 維持されるワーカーは、異なるアクティブな EP サイズ用に再構築する代わりに、融合 MoE 実行オブジェクトを再利用します。
- グラフから参照されるワークスペースとディスパッチ出力のアドレスとレイアウトは安定しており、キャプチャされたエキスパートカーネルが正しいポインタとオフセットを使用することが保証されます。
- エキスパートルーティングテンソルのバッキングストレージが保持され、Expert Parallel Load Balancing (EPLB) がキャプチャされたカーネルで使用されるテンソルを移動せずにマッピング内容を変更できるようになります。
これらの変更により、保持されたワーカーは、スケールアップとスケールダウンの両方の後に既存の CUDA グラフを再利用できます。
参加ワーカーの独立した準備
参加するワーカーは通常、準備のために他のワーカーがモデルのフォワードパスに参加する必要があります。NIXL EP により、各参加ワーカーは、ウォームアップとグラフ準備中にすべてのリモート EP ピアを一時的にマスクできます。この分離により、参加ワーカーは、EP 通信にローカルランクのみをアクティブにして、ダミーバッチを実行し、CUDA グラフをキャプチャできます。
この変更により、参加ワーカーは、既存のワーカーが実際のリクエストを処理している間に、既存のワーカーの参加を必要とせずに CUDA グラフをキャプチャできます。
DeepSeek V4 Pro でのパフォーマンスベンチマーク
GB200 GPU (TP=1、DP/EP サイズ 16 および 20) で DeepSeek V4 Pro を使用した実験では、NIXL EP によってサービスダウンタイムが劇的に短縮されることが実証されました。
| メトリクス | A: ブロッキング | B: 非同期準備 | C: 非同期準備 + グラフ再利用 |
|---|---|---|---|
| 16 から 20 GPU: ダウンタイム | 99.62 秒 | 58.04 秒 | 0.82 秒 |
| 20 から 16 GPU: ダウンタイム | 56.25 秒 | 44.07 秒 | 1.96 秒 |
| 16 から 20 GPU: 合計時間 | 99.72 秒 | 97.27 秒 | 92.34 秒 |
| 20 から 16 GPU: 合計時間 | 56.21 秒 | 51.46 秒 | 9.32 秒 |
NIXL EP を利用する構成 C は、ほぼゼロダウンタイムを達成し、スケールアップの一時停止を 58.04 秒から 0.82 秒に、スケールダウンの一時停止を 44.07 秒から 1.96 秒に短縮しました。
さらに、リクエスト負荷が増加するエンドツーエンドのサービングシナリオでは、Elastic EP はスケーリングプロセス全体を通じて、ローリング p95 の Time to First Token が 5 秒未満というサービスレベル目標 (SLO) を下回り続けました。準備中、Elastic EP は静的 16 GPU デプロイメントのサービングパフォーマンスに一致し、スケーリング後は回復した 20 GPU デプロイメントのパフォーマンスに一致しました。
今後の方向性
vLLM チームは、Elastic EP 機能をさらに強化するためのいくつかの次のステップを概説しています。
- Dynamo Snapshot によるウォームワーカーの復元: Dynamo Snapshot の統合により、参加するワーカーが初期化済みのプロセスと CUDA 状態を復元できるようになり、コンパイル、カーネルのウォームアップ、グラフ構築を繰り返す必要がなくなります。
- 最先端の EP 通信: チームは、Elastic EP とフォールトトレランスの完全なサポートを維持しながら、NIXL EP で最先端のディスパッチおよびコンバインのパフォーマンスを達成することを目指しています。
- オーケストレーター統合: 次のステップは、Elastic EP をオーケストレーターのオートスケーラーに接続し、vLLM を Dynamo や llm-d などのシステムと統合することです。
SUMMARY: vLLM は、NIXL EP と非同期準備を導入することで、Elastic Expert Parallelism (EP) のほぼゼロダウンタイムのスケーリングを実現し、スケーリングの一時停止を数分から 2 秒未満に短縮しました。
TITLE: vLLM は NIXL EP により Elastic Expert Parallelism でほぼゼロダウンタイムのスケーリングを実現