vLLM Elastic Expert Parallelism

vLLM Elastic Expert Parallelism

vLLMはElastic Expert Parallelism (Elastic EP)を導入しました。これにより、Mixture-of-Experts (MoE) デプロイメントにおいて、実行時にワーカー数を増減させることが可能になります。これにより、サービング容量を調整するためにサーバーを完全に再起動する必要がなくなり、需要の変動時におけるトラフィックの低下や運用オーバーヘッドが軽減されます。

MoEデプロイメントにおける実行時のスケーリング

Elastic EPにより、vLLMは実行時にデータ並列 (DP) ワーカーの数を再構成できます。エキスパート並列 (EP) グループのサイズはDPとテンソル並列 (TP) の積であるため、DPサイズを変更することで、実質的にEPグループをスケールさせ、新しいワーカーセットにエキスパートを再分配できます。

オペレーターは、単一のAPIコールでリサイズをトリガーできます：

curl -X POST http://localhost:8000/scale_elastic_ep \
  -H "Content-Type: application/json" \
  -d '{"new_data_parallel_size": 8}'

技術的実装と状態管理

実行時にDPをスケールさせるには、無効化を避けるためにいくつかの重要な実行時状態を更新する必要があります。vLLMは、スケーリングプロセスを明示的な同期ポイントを持つ調整された状態マシンとして扱います：

  • 分散通信グループ: 新しいランクセットを反映するために、EP、DP、およびworldグループを更新する必要があります。
  • エキスパートの割り当て: EPサイズに基づいて、特定ランクへのエキスパートのマッピングが再計算されます。
  • モデルの重み: 新しいランクは必要な重みを受け取る必要があり、既存のランクは更新されたエキスパートの重みが必要になる場合があります。
  • コンパイルされた状態: CUDAグラフと torch.compile の状態は、新しいトポロジーに合わせてリセットおよび再ウォームアップされます。

スケールアップのワークフロー

DP=N から DP=M (M > N) へスケールする場合、vLLMは6段階のプロセスに従います：

  1. トリガーとリクエスト処理: プロセスは /scale_elastic_ep で開始されます。VLLM_ELASTIC_EP_DRAIN_REQUESTS=1 が有効な場合、vLLMは処理を進める前に、実行中のワークが完了するのを待ちます（デフォルトのタイムアウトは120秒）。
  2. 新しいエンジンコアの初期化: Ray DPバックエンドを使用して、vLLMは追加のDPワーカーを起動します。これらのランクはプレースホルダーの重みでモデルを初期化し、再構成信号を待ちます。
  3. スタンバイ通信グループ: 既存のランクは StatelessGroupCoordinator を使用してスタンバイグループを作成します。これにより、古い構成がフォワードパスを実行し続けながら、新しい構成を準備することができます。
  4. エキスパートのマッピングと重みの転送: 非エキスパートの重み（アテンション層、正規化層、埋め込み層）は、高速インターコネクト（NVLinkまたはRDMA）を介して既存のランクから新しいランクへブロードキャストされます。エキスパートの重みは、EPLBリシャッフル段階まで保留されます。
  5. 切り替え (The Switch): vLLMはCUDAグラフを解放し、スタンバイグループをアクティブ状態に昇格させ、古いグループを破棄し、コンパイルされたパスを新しいセットアップに合わせるためにモデルを再ウォームアップします。
  6. EPLBリシャッフル: Expert Parallel Load Balancing (EPLB) が、すべての M ランクにエキスパートを再分配し、必要なエキスパート重みの移動を実行します。

スケールダウンのワークフロー

DP=M から DP=N へのスケーリングも同様のパターンに従いますが、EPLBリシャッフルが最初に行われます。これにより、削除予定のランクが終了する前に、そのランクが所有するエキスパートが生存する N ランクに移行されることが保証されます。

2段階バリアによる同期

非同期なDPエンジンコアによって引き起こされるデッドロックを防ぐため、vLLMは2段階のバリアを採用しています。最初のバリアにはタイムアウトが設定されています。失敗した場合、ランクは一部のピアがまだフォワードステップを実行中であると判断し、1イテレーション分エンジンループに戻ります。すべてのランクが整列したら、タイムアウトのない2番目のバリアにより、一斉に再構成ステージに入ることができます。

フォールトトレランスへの影響

Elastic EPは、vLLMのフォールトトレランス戦略の基礎となるコンポーネントとして機能します。実行時の再構成パスを提供することで、vLLMは完全な再起動なしにランクの故障から回復できます：

  1. 検知: ヘルスチェックまたはバックエンドの信号を介して故障を特定します。

  2. スケールダウン: 故障したランクを削除し、そのエキスパートを再分配します。

  3. スケールアップ: 利用可能になったら代替容量を追加します。

NIXL EPは、このフローにおいて特に重要な通信バックエンドとして挙げられます。これは、EP側の故障を検知、報告、および回復することができ、connect_ranks() および disconnect_ranks() APIを介してランクをインクリメンタルに追加または削除できるためです。

現在の制限と今後の課題

Elastic EPはコアとなる再構成パスを提供していますが、現在のサポートは tensor_parallel_size=1、単一のAPIサーバー、およびDBOなしのRay DPデプロイメントに限定されています。今後の開発領域には以下が含まれます：

  • tensor_parallel_size > 1 およびより豊かな並列構成のサポート。
  • DBOやMoEドラフト/ドラフターモデルを含む、より多くのサービング機能との統合。
  • オーバーラップの改善とウォームアップコストの削減による、再構成ウィンドウの短縮。
  • オートスケーリングポリシー（例：Dynamo, llm-d）との接続。
  • Ray以外の追加のDPバックエンドのサポート。

Sources