DeepSeekおよびその他のMoEモデル向けvLLM Expert Parallelデプロイメント
vLLM expert parallelは、MoEモデルのエキスパート層を1つの大規模なテンソル並列グループとして処理するのではなく、GPU間で分割すべき場合に使用するデプロイメントモードです。現在のvLLMでは、切り替え用のフラグは--enable-expert-parallelです。エキスパート並列性のサイズは、テンソル並列（TP）とデータ並列（DP）の設定を通じて間接的に決定します。vLLMではEP_SIZE = TP_SIZE × DP_SIZEと記載されています。
この詳細は重要です。多くの運用手順書では、独立した「vLLM expert parallel size flag」を探し、固定したビルドに含まれていないフラグを無理に指定しようとします。サポート対象の切り替えフラグから始め、実際にデプロイするイメージでvllm serve --helpを確認し、測定済みのキャパシティプランに基づいてTP/DPを選択してください。
このプレイブックでは、単一ノードのDeepSeek MoEデプロイメントからマルチノードvLLM expert parallelへ安全に移行する手順を取り上げます。バックエンドの選択、エキスパート負荷分散、受け入れテスト、障害切り分けを含みます。これはワンコマンドのデモではなく、MLおよびAIインフラストラクチャエンジニア向けに書かれています。
バージョンに関する注意: vLLMのMoEカーネル、依存関係、CLIのインターフェースは急速に進化しています。以下に記載する動作とコマンドは、2026年10月16日に公式vLLMドキュメントに照らして確認しました。本番環境へのロールアウト前にvLLMイメージを固定し、その固定バージョンでフラグを検証してください。
要点
| 質問 | 実践的な回答 |
|---|---|
| vLLM expert parallelを有効にするには？ | サポート対象のMoEデプロイメントに--enable-expert-parallelを追加します。 |
| EPサイズはどのように選択する？ | 現在のvLLM expert-parallelドキュメントでは、TP × DPとして計算されます。推測したEPサイズ用フラグではなく、--tensor-parallel-sizeと--data-parallel-sizeを設定してください。 |
| 何が変わる？ | MoEのエキスパート層はEPランク間でシャーディングされます。アテンション層は、ドキュメントに記載されたTP/DPの動作に引き続き従います。 |
| いつ使用すべき？ | MoEモデル、GPUトポロジー、通信ファブリック、リクエスト量が、エキスパート処理を分散することを正当化する場合です。密なモデル向けの汎用的な高速化スイッチではありません。 |
| どこから始めるべき？ | 単一ノード、固定されたモデルリビジョン、固定されたトラフィックトレース、EPを使用しないベースラインから始めます。 |
公式vLLM expert parallel deployment guideが、この機能に関する信頼できる情報源です。このガイドでは、expert parallelismを、通常はデータ並列と組み合わせてMoEエキスパートをGPUに分散するものとして説明しています。
vLLM expert parallelで実際に変わること
MoEモデルは、各トークンを多数のエキスパートネットワークのうち少数のサブセットへルーティングします。expert parallelismを使用しない場合、vLLMで文書化されているMoEの動作では、DP × TPにまたがるテンソル並列グループを形成します。--enable-expert-parallelを使用すると、エキスパート層は代わりにexpert parallelismを使用し、アテンション層は独自のTP/DP動作を維持します。
具体的なトポロジーとして、TP=2およびDP=4を考えてみましょう。
| コンポーネント | EP有効時の並列動作 |
|---|---|
| エキスパート層 | 8ランクにまたがるEPグループ。エキスパートはこれらのGPUに分散されます。 |
| アテンション層 | 4つのDPグループそれぞれ内にある、サイズ2のテンソル並列グループ。 |
| 実効EPサイズ | 2 × 4 = 8。 |
このため、vLLM expert parallelは、アテンション、KVキャッシュ容量、リクエストの同時実行性、ネットワークトポロジーをどのように組み合わせるかという判断の代替にはなりません。これは分散サービング設計の一部です。
ワークロードに適したマルチGPUパターンに関するより広い入門については、vLLM multi-GPU inference: tensor and pipeline parallel setupを参照してください。
vLLM expert parallelフラグと「サイズフラグ」の問題
現在の公開ドキュメントには、標準的な有効化フラグが示されています。
--enable-expert-parallel
また、expert-parallelサイズはテンソル並列サイズとデータ並列サイズから計算されると記載されています。
EP_SIZE = TP_SIZE × DP_SIZE
したがって、vLLM expert parallel deployment docsのパターンは次のとおりです。
vllm serve <MODEL> --tensor-parallel-size <TP> --data-parallel-size <DP> --enable-expert-parallel
古いissue、内部ラッパー、別のサービングスタックにある--expert-parallel-sizeオプションをコピーして、それが自分のvLLMビルドにも適用されると想定しないでください。「自分のEPサイズはいくつか？」という問いは、トポロジーの問題として扱ってください。
- 1つのサービンググループで利用できるGPUとノードの数を選択します。
- アテンション層のシャーディングとローカルモデルの動作に応じてTPを選択します。
- 独立したエンジン容量とリクエスト分散に応じてDPを選択します。
- MoE層に対してEPを有効にします。
- 起動ログで計算されたプロセストポロジーを確認し、負荷テストを実行します。
特定リリースにおけるフラグの最終的な根拠は、vLLMのserve CLI referenceです。
デプロイ前: 準備状況の確認
起動やスループットの問題をexpert parallelismのせいにする前に、以下のチェックを実施してください。
| チェック項目 | 確認内容 | 重要な理由 |
|---|---|---|
| バージョン | すべてのワーカーで、vLLMコンテナ、CUDAスタック、モデルリビジョンを固定します。 | イメージが混在していたりwheelが不一致だったりすると、トポロジーの問題が原因不明のカーネルエラーに変わる可能性があります。 |
| モデルの収まり | GPU数を選ぶ前に、モデル重み、KVキャッシュ、ランタイムワークスペース、冗長なエキスパートを考慮します。 | EPを使用しても、メモリ計画が不要になるわけではありません。 |
| 依存関係 | ドキュメントで要求されている場合はDeepEPおよびDeepGEMMを含め、最新のvLLM EPカーネルの前提条件に従います。 | エキスパート並列のドキュメントでは、これらが前提条件として明記されています。 |
| ファブリック | 1ノード上のGPUトポロジーを確認し、最初の本番リクエスト前にノード間GPU通信を検証します。 | EPでは、MoEの各フォワードパスに通信が追加されます。 |
| 制御ネットワーク | プライマリノードのアドレス、ポート到達性、NICの選択を明示します。 | コントロールプレーンの検出が誤ったインターフェースを参照している場合、健全なデータプレーンは役に立ちません。 |
| ベースライン | EPなしでレイテンシー、スループット、エラー率、GPUメモリの余裕を記録します。 | 「EPは役に立ったか？」に比較可能な答えが必要です。 |
このチェック項目のメモリ面については、より大規模なクラスターを予約する前に、LLM GPUメモリ要件ガイドを使用して容量計画ワークシートを作成してください。
最初の実験はシンプルにする
1つのモデルリビジョン、既知の1つのトークナイザー、1つのリクエスト構成、1つの同時実行数の範囲、および1組の固定された起動フラグを使用します。同じテスト内で、量子化、キャッシュ設定、ハードウェア、all-to-allバックエンドを変更しないでください。クリーンなベースラインがあれば、vLLM expert parallelによって有効スループットが変化したのか、単にボトルネックが移動しただけなのかを判断できます。
単一ノードでのDeepSeek MoEデプロイメント
現在のvLLMガイドでは、単一ノードの例としてDeepSeek-V3-0324を使用し、TPを1方向、DPを8方向に設定してEPを有効化しています。
vllm serve deepseek-ai/DeepSeek-V3-0324 --tensor-parallel-size 1 --data-parallel-size 8 --enable-expert-parallel
ドキュメントでは、意図する効果について次のように説明しています。アテンション重みはDPランク間で複製され、エキスパート重みはGPU間で分割されます。8 GPUのH200またはH20ノードをトポロジー例として使用しており、異なるハードウェアを使用するチームには、この例を普遍的なサイジングの保証と見なすのではなく、独自の構成で適合性を検証するよう推奨しています。
このコマンドは、本番構成としてそのままコピー＆ペーストするのではなく、トポロジーの出発点として使用してください。エンドポイントを公開する前に、以下を実施します。
- 異なるカーネルパスへの隠れたフォールバックなしに、サーバーが正常なready状態に到達することを確認します。
- 既知のプロンプトと、期待されるスキーマまたはツール呼び出しの動作を用いて正確性テストを実行します。
- 小規模な定常負荷をかけ、その後にバースト負荷と長コンテキストのサンプルを実行します。
- p50およびp99の初回トークン生成時間、トークン間レイテンシー、出力スループット、メモリの余裕、エラーを、非EPベースラインと比較します。
- ベンチマーク結果とともに、起動コマンド、イメージダイジェスト、モデルリビジョン、ドライバーバージョン、メトリクスのスナップショットを保存します。
周辺のAPIレイヤーをまだ構築している場合は、このvLLMデプロイメントガイドで、MoE並列化の判断とは別にOpenAI互換サーバーのパスを扱っています。
慣習ではなくワークロードに基づいてall-to-allバックエンドを選択する
vLLMは、エキスパート並列通信向けに--all2all-backendを提供しています。公式ガイドでは現在、汎用デフォルトと特化したDeepEPモードについて説明しています。実際に測定したトラフィックに合わせてバックエンドを選択してください。
| バックエンド | ドキュメントで示される適合性 | デプロイメント上の意味 |
|---|---|---|
allgather_reducescatter |
汎用的なEP + DPデプロイメント | 特化したチューニングを行う前の、妥当な制御用構成です。 |
deepep_high_throughput |
マルチノード、プリフィル主体のワークロード | 長いプロンプトと集約スループットがサービス目標を支配する場合に評価します。 |
deepep_low_latency |
マルチノード、デコード主体のワークロード | 最大プリフィルスループットよりも生成トークンのレイテンシーが重要な場合に評価します。 |
| FlashInfer NVLinkモード | MNNVL / NVLink固有のシステム | ハードウェアおよび最新のvLLMドキュメントがバックエンドの要件に適合する場合にのみ使用します。 |
重要なのは、最も速そうに見えるラベルを選ぶことではありません。プロンプト長の構成、同時実行性、ファブリック、SLOに対して、一度に1つのバックエンドをテストすることです。秒あたりのトークン数だけでなく、テールレイテンシーへの影響も測定してください。
マルチノードvLLM expert parallel：2ノード構成パターン
マルチノードデプロイメントでは、vLLMドキュメントはAPIトラフィックを処理するプライマリノードと、セカンダリの--headlessワーカーノードを使用します。以下は、そのドキュメント化されたパターンをパラメーター化した形式です。アドレスと数値は、実際にテストしたクラスターに一致する値に置き換えてください。
プライマリノード上で：
export GLOO_SOCKET_IFNAME=eth0
vllm serve deepseek-ai/DeepSeek-V3-0324 --all2all-backend deepep_low_latency --tensor-parallel-size 1 --enable-expert-parallel --data-parallel-size 16 --data-parallel-size-local 8 --data-parallel-address <PRIMARY_NODE_IP> --data-parallel-rpc-port 13345 --api-server-count 8
2台目のノード上で：
export GLOO_SOCKET_IFNAME=eth0
vllm serve deepseek-ai/DeepSeek-V3-0324 --all2all-backend deepep_low_latency --tensor-parallel-size 1 --enable-expert-parallel --data-parallel-size 16 --data-parallel-size-local 8 --data-parallel-start-rank 8 --data-parallel-address <PRIMARY_NODE_IP> --data-parallel-rpc-port 13345 --headless
これらの数値は重要です。
--data-parallel-sizeは、サービンググループ全体の合計DPサイズです。--data-parallel-size-localは、そのノードで起動されるDPランクの数です。--data-parallel-start-rankは、先行するノードのローカルDPサイズの累積値です。- プライマリがクライアントリクエストを処理するため、セカンダリノードはヘッドレスです。
InfiniBandクラスターの場合、現在のvLLMガイドでは、分散グループの検出を選択したEthernet制御インターフェース上に維持するために、GLOO_SOCKET_IFNAME=eth0 が特に挙げられています。これは、ノード間のNCCLおよびGPU間通信を検証する代わりにはなりません。
マルチノード受け入れチェックリスト
顧客トラフィックをマルチノードvLLMエキスパート並列グループに送る前に、以下のすべてを確認してください。
- すべてのワーカーが同じモデルリビジョンを解決し、意図したランクで起動する。
- プライマリノードが、すべてのピアから設定済みのRPCアドレスとポートに到達できる。
- クリーンな再起動後に分散グループが繰り返し初期化される。
- 低コンカレンシーでリクエストが完了し、その後、継続的なトレース下でも完了する。
- 意図的に偏らせたリクエストミックスでも、サイレントハングやテールレイテンシの急激な悪化が発生しない。
- テストワーカーを1台再起動すると、リクエストが無期限にキューイングされるのではなく、観測可能で対処可能な障害シグナルが生成される。
vLLM分散トラブルシューティングガイドでは、ノード間GPU通信を検証し、通信環境変数をすべてのノードで利用可能にすることを推奨しています。Rayを使用する場合は、vLLMとRayのホストIP設定を一致させる方法も説明されています。
不均衡を確認してからExpert Parallel Load Balancingを追加する
本番環境では、MoEルーティングが常に均等に分散されるとは限りません。vLLMのExpert Parallel Load Balancer（EPLB）は負荷データを収集し、EPランク間でエキスパートマッピングを定期的に再分散します。この機能は --enable-eplb で有効化します。
vllm serve Qwen/Qwen3-30B-A3B --enable-expert-parallel --enable-eplb --eplb-config '{"window_size":1000,"step_interval":3000,"num_redundant_experts":2,"log_balancedness":true}'
ホットエキスパート、ランクごとの不均一な処理量、またはルーティングの偏りに連動する持続的なテールレイテンシの証拠がない限り、EPLBなしで開始してください。EPLBは冗長エキスパートを使用でき、それらの追加エキスパートコピーはGPUメモリを消費します。必須のvLLMエキスパート並列フラグではなく、容量コストを伴う最適化として扱ってください。
初回の実験では、次のようにします。
- EPLBなしでランクごとの使用率とリクエストレイテンシを記録する。
- 制御された期間にわたってバランス度のロギングを有効にする。
- メモリ予算に収まる最小の冗長性設定を追加する。
- 同じトレースで、テールレイテンシ、スループット、メモリ余裕、リバランスによる中断を比較する。
- ロールバックコマンドと非EPLBのデプロイメント設定を用意しておく。
適切な問いに答えるベンチマーク計画
プロセスが起動したというだけでEPロールアウトを成功と判断しないでください。すべての比較で、同じモデルリビジョン、プロンプト、出力上限、コンカレンシー、量子化、キャッシュ設定、ハードウェア予約を使用してください。
| テスト | 明らかになること | 判断シグナル |
|---|---|---|
| 短いプロンプト、高コンカレンシーのデコード | デコード側のcollectiveおよびキューの挙動 | p99トークン間レイテンシと生成トークンのスループット |
| 長いプロンプトのプリフィル | プリフィルおよびall-to-allのオーバーヘッド | p99の最初のトークンまでの時間と総プリフィルスループット |
| エキスパート偏りトレース | 少数のエキスパートがホットランクを生み出すかどうか | ランク不均衡、キューの増加、およびEPLBの必要性 |
| 長コンテキスト容量テスト | 現実的なキャッシュ負荷時のメモリ余裕 | OOM率、受け入れ失敗、安全なコンカレンシー |
| 再起動／パーティション訓練 | ピア障害またはポート遮断時の運用上の挙動 | 検出までの時間、エラーの可視性、復旧パス |
平均スループット以上のものを記録してください。平均値を改善しても、p99レイテンシを悪化させたり、復旧を不透明にしたりするデプロイメントは、本番環境での明確な成功とは言えません。
vLLMエキスパート並列デプロイメントのトラブルシューティング
| 症状 | 考えられる原因の分類 | 最初に行うこと |
|---|---|---|
不明な --expert-parallel-size 引数 |
ランブックとインストールされている vLLM が一致していない | vllm serve --help を実行し、ビルドを固定して、そのビルドで文書化されている TP/DP サイジングを使用します。 |
| EP カーネルまたは all-to-all バックエンド周辺で起動に失敗する | EP 依存関係またはコンテナスタックが不足している、あるいは互換性がない | 複数の起動フラグを一度に変更するのではなく、現在の EP 前提条件とコンテナイメージを再確認します。 |
| マルチノードワーカーが初期化中にハングする | コントロールプレーンのアドレス、ポート、NIC、またはプロセスグループの設定 | カーネルを調整する前に、到達可能性、選択されたインターフェース、ランク計算、分散通信を確認します。 |
| ワーカーが準備完了と表示された後、最初のリクエストがハングする | ノード間 GPU 通信が正常ではない | ベンダー/vLLM の通信チェックを実行してから、NCCL とインターフェースの設定を調査します。 |
| スループットが改善しない | トラフィック構成、ファブリック、バッチの挙動、またはアテンション側の設定が依然としてボトルネックになっている | プロンプト長と同時実行数ごとにベースラインと比較し、一度に変更するトポロジー変数は 1 つだけにします。 |
| EPLB を有効にした後にメモリ不足になる | 冗長エキスパート用メモリが安全マージンを消費した | 冗長性を減らすか、より多くのメモリヘッドルームを確保して、容量テストを繰り返します。 |
| 1 つのランクが継続的に遅い | エキスパートルーティングの偏り、またはホスト/ファブリック性能の不均一性 | まずランクレベルの負荷を測定し、証拠がそれを裏付ける場合にのみ EPLB を検討します。 |
重要なのは、診断を狭く絞る習慣です。1 つの要因を変更する間は、モデル、イメージ、トラフィックトレース、トポロジーを固定してください。これにより、曖昧な「EP が遅い」という報告を、実行可能な観測結果へと変えられます。
本番展開の手順
- ベースラインを確立する。 EP なしで対象の MoE モデルを実行し、メトリクス、ログ、起動マニフェストを保持します。
- 1 ノードで EP を有効にする。 明示的に選択した TP/DP トポロジーで
--enable-expert-parallelを使用します。 - 品質と容量を検証する。 出力の挙動、メモリヘッドルーム、p50/p99 レイテンシ、持続スループットを確認します。
- トラフィック形状に応じてバックエンドを選択する。 同一のトレースでのみ、汎用バックエンドと該当する特化バックエンドを比較します。
- 証拠がある場合にのみ EPLB を追加する。 冗長エキスパートを正当化するために、バランス性データとメモリヘッドルームを使用します。
- マルチノードへ拡張する。 トラフィックを増やす前に、ランク割り当て、コントロールネットワーク、ノード間 GPU 通信を検証します。
- 障害訓練を実施する。 本番トラフィックによって問題が発見される前に、再起動、ポート損失、不健全なワーカーをテストします。
- 固定して文書化する。 バージョン、起動フラグ、トポロジー、メトリクス、ロールバック手順をデプロイメントとともに保存します。
MoE サービングレイヤーをセルフホストすべきでない場合
モデル配置、データパス、ハードウェア予約、サービングの挙動に対する制御が製品要件の一部である場合、vLLM expert parallel は適切な投資です。一方で、チームが主にモデルへのアクセスを必要としており、GPU 使用率、分散ネットワーク、アップグレードテスト、オンコールでの復旧を担えない場合には適していません。
より大規模なクラスターを予約する前に、GPU cloud vs. model API: when self-hosting actually saves money で運用モデルとマネージド API パスを比較してください。適切な答えはハイブリッドになる場合があります。つまり、インフラストラクチャ制御が必要なワークロードはセルフホストし、それ以外には API レイヤーを使用します。
FAQ
--enable-expert-parallel は vLLM expert parallel を有効にしますか？
はい。現在の vLLM CLI ドキュメントでは、--enable-expert-parallel は MoE レイヤーにおいてテンソル並列ではなくエキスパート並列を使用するものとして説明されています。
vLLM の expert parallel size フラグとは何ですか？
現在文書化されているデプロイメントフローでは、EP サイズは --tensor-parallel-size と --data-parallel-size から導出されます: EP_SIZE = TP × DP。個別のサイズフラグがあると仮定せず、固定した vLLM リリースで正確な CLI インターフェースを確認してください。
expert parallel はあらゆる場所で tensor parallelism を置き換えますか？
いいえ。EP は MoE エキスパートレイヤーの戦略を変更します。アテンションレイヤーの挙動は、選択した TP と DP の値に引き続き依存します。
すべての DeepSeek デプロイメントで EPLB を有効にすべきですか？
いいえ。まず代表的なトラフィックでエキスパート負荷の不均衡を示し、冗長エキスパートのメモリコストがクラスターに収まることを確認してください。EPLB は最適化であり、デフォルト要件ではありません。
どの all-to-all バックエンドを使用すべきですか？
まず現在の vLLM ガイダンスを確認し、その後ワークロード形状に合うバックエンドをテストします。幅広い互換性には汎用オプション、prefill 主体のトラフィックには高スループットの DeepEP モード、decode 主体のトラフィックには低レイテンシの DeepEP モードを使用します。
参考文献
- vLLM Expert Parallel Deploymentドキュメント
- vLLM Data Parallel Deploymentドキュメント
- vLLM serve CLIリファレンス
- vLLM分散デプロイメントのトラブルシューティング
次のステップ: 単一ノードのコマンドを管理された検証環境として使用し、ベースラインを取得して、実際に重視するSLOを改善するトポロジーのみを本番環境へ昇格させてください。そうすることで、vLLM expert parallelは、速くなることを期待するだけのフラグではなく、本番運用上の意思決定になります。
