# MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism Navigation: [[index]] | [[overview]] > [!abstract] 概要 > Mixture-of-Experts(MoE)は、性能向上と計算複雑性の低減を伴いつつ大規模言語モデル(LLM)をスケールする大きな可能性を示す。しかし、その疎に活性化されるアーキテクチャは、推論時に feed-forward network(FFN)を計算集約型からメモリ集約型へと変化させ、GPU 使用率を大幅に低下させ運用コストを増大させる。本論文では、大規模 MoE モデルを効率的かつ費用対効果良く提供するシステムである MegaScale-Infer を提示する。MegaScale-Infer は各モデル層内で attention モジュールと FFN モジュールを分離し、両モジュールの独立したスケーリング・専用の並列化戦略・異種混在デプロイを可能にする。MoE の疎性が存在する下で disaggregation を十分に活用するため、MegaScale-Infer は ping-pong pipeline parallelism を導入し、リクエストバッチをマイクロバッチに分割して attention と FFN の間で往復させながら推論する。各モジュールに固有のモデル並列化と組み合わせることで、MegaScale-Infer は通信オーバーヘッドを効果的に隠蔽し GPU 使用率を最大化する。分離された attention・FFN モジュールに適応しデータ転送オーバーヘッド(例:トークンディスパッチ)を最小化するため、MegaScale-Infer は不要な GPU-to-CPU データコピー・グループ初期化オーバーヘッド・GPU 同期を排除する高性能な M2N 通信ライブラリを提供する。実験結果は、MegaScale-Infer が最先端の解に対し per-GPU スループットで最大 1.90 倍を達成することを示す。 ## 論文情報 - **著者**: Ruidong Zhu, Ziheng Jiang, Chao Jin, Peng Wu, Cesar A. Stuardo, Dongyang Wang, Xinlei Zhang, Huaping Zhou, Haoran Wei, Yang Cheng, Jianzhe Xiao, Xinyi Zhang, Lingjun Liu, Haibin Lin, Li-Wen Chang, Jianxi Ye, Xiao Yu, Xuanzhe Liu, Xin Jin, Xin Liu - **所属**: [[ByteDance Seed]]、Peking University - **公開**: arXiv:2504.02263(2025-04-03 初版、v4 2025-07-26)、[arxiv.org/abs/2504.02263](https://arxiv.org/abs/2504.02263) - **査読**: 学会発表情報は arXiv 版に記載なし(cs.DC) ## 概要 MoE モデルは、疎な活性化によりパラメータ数を増やしても計算量の増加を抑えられる一方、デコード時に各エキスパートへ割り当てられるトークン数が小さくなるため FFN の GPU 使用率が低下する。本論文は、attention モジュールと FFN(エキスパート)モジュールを別々の GPU ノードへ分離してデプロイする **disaggregated expert parallelism** を提案し、複数の attention レプリカからのリクエストを 1 つの FFN(エキスパート)ノードに集約することでバッチサイズを拡大し、GPU 使用率とコスト効率を改善する。 ## 問題設定 - デコードフェーズでは attention はメモリ集約的(各リクエストが個別の KV キャッシュへアクセスする必要がある)、FFN はバッチ化により計算集約的になりやすい。 - しかし MoE では、gate network が top-k のエキスパートのみにトークンを割り当てるため、同じグローバルバッチサイズでも各エキスパートが受け取るトークン数は 1/(#expert/top-k) に縮小する。Mixtral 8x22B(8 エキスパート・top-2)を A100(312 TFLOPS、2TB/s)上で bfloat16 で動かす場合、roofline モデル([[Rooflineモデル]])から必要バッチサイズは 156 トークンだが、そのうち各エキスパートに配分されるのは 156×2/8=39 トークンにとどまり、理論 MFU は 25% に低下する。 ![[fig01-gpu-utilization.png]] *図1: dense モデル・MoE・MegaScale-Infer における attention/FFN の GPU 使用率とバッチサイズの関係。MoE では疎性により FFN の使用率が最大バッチサイズ到達前に頭打ちになる。* ![[fig02-moe-expert-parallelism.png]] *図2: MoE 層(gate + 複数エキスパート)と、エキスパートをノード間に分散するエキスパート並列(EP)。EP では All2All 通信でトークンをエキスパートへ送り、結果を回収する。* - GPU メモリ制約(KV キャッシュ)や低遅延制約がバッチサイズの拡大を妨げるため、この非効率は単純な増バッチでは解消できない。 - disaggregation 自体は 2 つの新たな課題を生む。(1) attention と FFN が交互に計算するため、互いの計算・通信待ちで idle time が発生する。(2) 元々 MoE 層内で完結していた All2All 通信が、M 個の attention ノードと N 個の FFN(エキスパート)ノード間の **M2N 通信**に変わり、既存の集団通信ライブラリ(NCCL 等)の group operation 前提と噛み合わない。 ## 提案手法 MegaScale-Infer は、prefill/decoding を別クラスタに分離する既存のプラクティスを踏襲した上で、デコードフェーズに焦点を当てる。以下 3 つの要素からなる。 1. **Disaggregated Expert Parallelism**([[Disaggregated Expert Parallelism]]): 各層の attention パラメータと KV キャッシュを Attention Node にデータ並列で複製し、各 Expert Node が 1 エキスパートのパラメータを保持してエキスパート並列(EP)グループを構成する。両ノード内ではテンソル並列(TP)を用いて NVLink 等の高帯域接続を活用する。これにより attention と FFN を独立にスケール・異種 GPU へデプロイできる。 ![[fig03-runtime-architecture.png]] *図3: MegaScale-Infer のランタイムインスタンス構成。Attention Node(複製・データ並列)と Expert Node(エキスパート並列)を M2N/N2M 通信で結び、両者の間に ping-pong pipeline parallel を構築する。* 2. **Ping-Pong Pipeline Parallelism**: グローバルバッチを m 個のマイクロバッチへ分割し、attention ノードと Expert ノードの間で往復させることで、通信中も計算を進行させ GPU の idle time を隠蔽する。Ta ≈ Te(制約 1)・Tc < Tf(制約 2)・m×Tf ≥ 2×(Tf+Tc)(制約 3)という 3 条件のもとで、通信を計算に完全にオーバーラップさせる最小マイクロバッチ数を導出する。ネットワーク帯域の速い環境では 3 マイクロバッチ、遅い環境では 4 マイクロバッチが必要になる。 ![[fig04-ping-pong-pipeline.png]] *図4: ping-pong pipeline parallelism の模式図。m=4 マイクロバッチ・L=2 層の例で、attention と Expert が交互にマイクロバッチを処理し、層をまたぐ依存関係(赤矢印)を保ちながら通信時間 Tc を計算で隠蔽する。* 3. **デプロイメントプラン探索(Algorithm 1)**: tensor parallel サイズ(tpa, tpe)・attention ノード数(na)・マイクロバッチ数(m)・グローバルバッチサイズ(B)を、GPU メモリ制約と SLO(time-between-tokens、TBT)制約の下で列挙し、throughput-per-cost を最大化する構成を二分探索で求める。計算量は O(M²Nm) に抑えられる(M は 1 サーバあたりの GPU 数の選択肢、Nm はマイクロバッチ数上限、実装では Nm=4)。 4. **高性能 M2N 通信ライブラリ**: NCCL のような汎用集団通信ライブラリが (a) GPU-to-CPU 中間コピー、(b) 8 個単位でバッチ化される peer-to-peer group operation、(c) 汎用 group operation のセットアップオーバーヘッドを抱えることを指摘し、これらを排除した専用ライブラリを実装した(PyTorch 拡張、C/C++ 約4900行 + Python 約5000行)。 ![[fig05-m2n-motivation-latency.png]] *図5: 1対N のレイテンシ比較(128KB を N={8,16,32} 受信者へ送信)。NCCL は perftest(CPU クライアントによる下限ベースライン)に比べ中央値・P99 とも大幅に劣化し、受信者数の増加とともに不安定性が拡大する。* CUDA イベント・CUDA driver 操作で GPU ストリームをブロック/アンブロックし、CPU 側の Core Sender/Receiver が RDMA write with immediate と completion queue のポーリングで転送する。GPUDirect・GDRCopy を用い GPU-to-GPU コピーと複雑な GPU 同期を回避する。さらに ACK パケットの高優先度キュー分離と輻輳制御のチューニングというトラフィック指向の最適化を加える。 ![[fig06-m2n-sender.png]] *図6: M2N Sender の構成。GPU ストリームは CUDA イベントで待機・ブロックし、Host 側の Core Sender が複数の Queue Pair(QP)を介して RDMA 送信と completion queue のポーリングを行い、完了後にストリームをアンブロックする。* 5. **異種混在(ヘテロジニアス)デプロイ**: attention ノードにはメモリ帯域・容量あたりのコストパフォーマンスが良い GPU(例: H20)、Expert ノードには計算あたりのコストパフォーマンスが良い GPU(例: L40S)を割り当てる。 比較対象の [[DeepEP]](DeepSeek 開発)は GPU-to-GPU の直接通信を採用するのに対し、MegaScale-Infer の M2N ライブラリは CPU-to-CPU 通信を用いる点が主な違いである。DeepEP は GPU の Streaming Multiprocessor を通信に割り当てカスタム PTX 命令で L2 キャッシュ使用量を抑えるが、その分計算カーネルと通信カーネルの間で GPU 資源の競合を管理する必要がある。MegaScale-Infer のシナリオ(sender-receiver ペアあたり数百 KB のデータ量)では単一スレッドの CPU で帯域を飽和させられるため、GPU 資源を計算に専有させられるとしている。 ## 新規性 - MoE のデコード非効率の原因を「疎性が FFN のバッチサイズを縮小させる」という定量的な roofline 分析(理論 MFU 25% の導出)で明確化した点。 - attention・FFN の disaggregation を MoE のエキスパート並列と組み合わせた **Disaggregated Expert Parallelism** という設計、および disaggregation で生じる idle time を隠蔽する **ping-pong pipeline parallelism** の導入。 - M2N という新しい通信パターン(All2All の分離版)を定式化し、既存の NCCL の設計選択(GPU-to-CPU コピー・8 個単位の group operation・汎用オーバーヘッド)がこのパターンに適さないことを実測で示した上で、専用ライブラリを設計・実装した点。 ## 実験設定 - **テストベッド**: (1) 均質クラスタ: 8 ノード×8 NVIDIA 80GB Ampere GPU、128 CPU、2TB ホストメモリ、200Gbps InfiniBand NIC×8、ノード内 400GB/s NVLink。(2) 異種混在クラスタ: NVIDIA H20(900GB/s NVLink、400Gbps NIC×4)と L40S(PCIe intra-node、400Gbps NIC×2)。 - **モデル**: Mixtral 8x22B(56層、8エキスパート、top-2、141B パラメータ)、DBRX(40層、16エキスパート、top-4、132B パラメータ)、Scaled-MoE(48層、32エキスパート、top-4、317B パラメータ)。全て bfloat16。 - **ワークロード**: 本番トラフィックから得たデータセット(入力長中央値571トークン、出力長中央値159トークン)。 - **ベースライン**: [[vLLM]]、[[TensorRT-LLM]](いずれも FlashAttention・PagedAttention・continuous batching を実装。TensorRT-LLM はエキスパート並列も一部サポート)。 - **メトリクス**: 均質デプロイでは per-GPU デコードスループット(1秒あたり生成トークン数 ÷ GPU 数)、異種混在デプロイでは per-cost デコードスループット。TBT(time-between-tokens)を 150ms に制約。 ## 実験結果 - **均質デプロイ(Ampere)**: MegaScale-Infer は Scaled-MoE で vLLM 比 7.11 倍、TensorRT-LLM 比 1.90 倍の per-GPU デコードスループットを達成した。時間あたりトークン間隔(TBT)はベースラインと同等水準を維持した。prefill を含む end-to-end スループットでは最大 1.18 倍の改善にとどまる(prefill は計算集約的で disaggregation の恩恵が小さいため)。 ![[fig08-e2e-ampere.png]] *図8: NVIDIA Ampere GPU 上での性能比較(vLLM・TensorRT-LLM・MegaScale-Infer)。(a) 正規化デコードスループット、(b) トークン間時間、(c) prefill を含む正規化 end-to-end スループット。* - **異種混在デプロイ(H20 + L40S)**: H20 を attention、L40S を FFN に割り当てることで、per-cost デコードスループットで vLLM(H20)比 3.24 倍、TensorRT-LLM(H20)比 1.86 倍を達成。prefill を含めた end-to-end では per-cost スループットで最大 1.66 倍。per-unit-power スループットでもデコード 1.80 倍・end-to-end 1.72 倍を達成した。 - **M2N 通信性能**: 8 sender×8 receiver・データサイズ 2K〜8M バイトの範囲で、NCCL 比で中央値レイテンシ最大 80.8% 削減、P99 レイテンシ最大 96.2% 削減、スループット最大 9.9 倍。典型的なデータサイズ(256KB)では中央値レイテンシ 68.2% 削減、テールレイテンシ 92.9% 削減、スループット 4.2 倍向上。 ![[fig11-m2n-perf-datasize.png]] *図11: データサイズ別の M2N 通信性能(sender/receiver 各8)。NCCL に比べ中央値・P99 レイテンシとも小〜中データサイズで大きく改善し、スループットも一貫して上回る。* sender/receiver 数(M, N)を 4〜32 まで変化させても M2N ライブラリは安定した性能を維持し、テールレイテンシを 54.7〜96.9% 削減、スループットを 3.3〜5.8 倍改善した(図12、埋め込み省略。図11と同一構図のため代表として図11のみ収録)。 - **アブレーション**: vLLM(コロケート)を基準に、disaggregated expert parallelism 単体(通信は NCCL のまま)で最大 4.66 倍のスループット改善、さらに M2N ライブラリへ切り替えることで追加 1.53 倍の改善が得られた。 ![[fig13-ablation.png]] *図13: disaggregated expert parallelism と M2N 最適化の効果分解。Colocated(vLLM 相当)→ Dist.+NCCL → Dist.+M2N の順に per-GPU スループットが段階的に向上する。* マイクロバッチ数 m を 1→2 に増やすと 1.9 倍、m=3 まで増やすとモデルにより 1.10〜1.38 倍の追加改善(モデルが大きいほど通信オーバーヘッドが大きく恩恵も大きい。図14、埋め込み省略)。DBRX の attention データ並列度(DP)を 1→16 まで変化させる実験では、DP が小さいと attention がボトルネックとなり、DP=8 で attention と FFN の計算時間がほぼ均衡してスループットがピークに達し、DP をさらに増やすとボトルネックが Expert 側へ移ってスループットが低下することを確認した(図15、埋め込み省略。図13・図14と類似構図のバーグラフのため数値のみ記載)。 - **本番デプロイ**: MegaScale-Infer は約 10,000 GPU 規模のクラスタで本番提供されており、異種混在デプロイ下でワークロード特性に応じて 1.5〜2.0 倍のコスト削減を達成している。本番トラフィックの分析では、デコード時のエキスパート負荷分布はバッチ間で比較的安定する一方、prefill 時は変動が大きいことが観測され、デコードでは静的・周期的な負荷分散、prefill ではより頻繁な調整が推奨される。 ![[fig16-expert-load.png]] *図16: 実トラフィックにおけるエキスパート負荷分布。(a) 単一バッチ・複数層でのエキスパートごとの受信トークン数、(b) デコード時・(c) prefill 時のエキスパートごとの受信トークン比率(4バッチ)。エキスパート間の負荷は顕著に不均衡で、prefill の方がバッチ間の変動が大きい。* attention 側でもシーケンス長のばらつきによる負荷不均衡が観測され、演算子のプロファイリングに基づくバッチ編成で緩和している。 ## 考察 - disaggregation の恩恵は主に decoding フェーズに現れ、compute-bound な prefill フェーズでは限定的であるため、既存の prefill/decoding disaggregation とは相補的な最適化軸として位置づけられる。 - M2N という通信パターンの識別自体が、既存の集団通信ライブラリ(NCCL)がカバーしない設計空間を明らかにした点で、disaggregated MoE serving 特有の通信最適化ニーズを提起している。 - CPU-to-CPU 通信を選んだ設計判断は、本論文が想定するデータサイズ(数百 KB オーダー)で GPU 資源を計算に専有させられるという前提に強く依存しており、エキスパート数がさらに増えて 1 接続あたりの転送量が小さくなる場合には GPU 主導の通信([[DeepEP]] 型)が有利になりうるとの見解を著者ら自身が述べている。 ## 強み / 弱点・課題 - 強み: roofline モデルによる問題の定量化から、disaggregation・ping-pong pipeline・専用通信ライブラリまで一貫した設計を提示し、本番 10,000 GPU 規模での運用実績(コスト 1.5〜2.0 倍削減)を伴う点。 - 強み: 均質・異種混在の両デプロイメントで評価し、GPU の特性差(メモリ帯域 vs 計算能力)を活かすコスト最適化の道筋を具体的に示した点。 - 弱点・課題: 評価対象モデルは 3 種(Mixtral 8x22B・DBRX・Scaled-MoE)にとどまり、超多数エキスパート(例: DeepSeek-V3/R1 の 256 エキスパート級)での挙動は評価されていない。 - 弱点・課題: prefill フェーズについては均質デプロイでの改善が乏しく、本手法は decoding 特化の解であることが示唆される。 - 弱点・課題: M2N ライブラリの CPU-to-CPU 設計の優位性は、想定データサイズ(数百 KB)に強く依存する前提付きの結論であり、著者ら自身がその適用限界(小データサイズ・多エキスパート化時の GPU 主導方式の優位可能性)を認めている。