SGLangにおけるElastic EP：DeepSeek MoEデプロイメントの部分故障耐性

2026年3月27日 411 約9分 LMSYS

LMSYS SGLang Elastic EP MoE 故障容忍 DeepSeek

1. 問題：広EPの必要性と脆弱性

大規模なMixture-of-Experts (MoE)モデルを効率的にサービングするため、「広い」Expert Parallelism (EP)戦略の展開——各推論インスタンスが32個以上のGPUにまたがることが多い——はもはやオプションではなく、必須となっている。これには2つの重要な理由がある：

バッチサイズを最大化してコストを削減：広EPは膨大なVRAMを集約し、超大規模バッチサイズをサポートする。これは本番環境でトークンあたりの総コストを削減する中核的な推進力となる。
TPOTを最小化して速度を向上：多数のGPUにわたって集約メモリ帯域幅を拡張することで、Time Per Output Token (TPOT)を直接削減し、高速なレスポンス生成を確保する。

しかし、EP規模の拡大は深刻な信頼性のボトルネックをもたらす。従来のEPアーキテクチャでは、「blast radius」（故障直径）はEPグループサイズに比例する。エキスパートが特定のハードウェアに厳密にバインドされているため、EPが大きいほど、単一のハードウェア故障やプロセスクラッシュが全インスタンスのダウンにつながる確率が高くなる。従来の解決策では全サーバーの再起動が必要で、通常数分かかり、リソースの無駄、壊滅的なダウンタイム、ユーザー体験の中断を引き起こす。SGLangの以前のMoEモードは単一インスタンス内での部分故障耐性を欠いており、最小限の混乱で済む解決策が緊急に必要だった。

2. 解決策の概要：Elastic EPとその効果

大規模MoE推論の脆弱性を解決するため、我々はElastic EPをSGLangフレームワークに統合した。その核心は、エキスパートと特定GPUの剛性マッピングを分離し、クラスター内に冗長エキスパートを維持し、故障検出後に即座にエキスパートの重みを再配分し、トークンを生存エキスパートに再ルーティングすることで、推論プロセスを中断することなく部分故障耐性を確保することにある。（注：動的プロセス復旧もPR #15771で積極的に開発中。）

効果

Elastic EPはシステムの信頼性を大幅に向上させ、同時に速度を犠牲にしない。

サービスの秒単位の復旧：4ノード（合計32 GPU、ep_size=dp_size=32）でDeepSeek V3.2を実行し、256個の冗長エキスパートを設定すると、最大16個のランク故障に耐えることができる。プロセスの終了をシミュレートした後、sglang.bench_servingベンチマークテストを使用し、EPLBManagerログに基づいて重み再配分とサービス復旧時間を測定した。復旧後、システムは正しく推論を継続し、リソース減少によりスループットは低下するものの、中断時間はすべて10秒以下——従来の2-3分の再起動と比べて90%削減された。

故障ランク数	Elastic EP中断時間（秒）	残存ランクスループット（tokens/sec）
1	6.8	5552.41
2	6.5	5431.50
4	6.8	5265.12
8	6.4	4479.84
16	6.2	2825.44

ゼロ静的性能損失：4ノード（2 prefillノード、2 decodeノード、各8 GPU）でDeepSeek V3.2を評価。Elastic EP（Mooncake EP）の主要指標は標準DeepEPと完全に一致。

システム	スループット（tokens/sec）	平均TTFT（ms）	平均TPOT（ms）
Elastic EP	3560.21	19399.24	54.25
Standard	3626.38	21227.86	52.88

3. 詳細な構造変更

この機能を実現するため、SGLangアーキテクチャに2つの重要な変更を導入した：

Scheduler Layer（上位層、スケジューリング指向）：システムのゲートキーパーとして、Data Parallel (DP)ランクの健全性を継続的に監視する。ランクが故障した場合、即座にフィルタリングして除外し、新しいバッチとリクエストが健全なリソースにのみ割り当てられるようにする。スケジューリング層から部分故障耐性を提供し、混乱ゼロを実現。（対応PR: #11657）
Expert Parallel Layer（下位層、実行指向）：EPグループ内の動的フォールトトレランスを処理する。エキスパートからGPUへのマッピングをリアルタイムで調整し、故障時には生存メンバー間でエキスパートを即座に再配分し、MoE推論の数学的正確性を確保し、リソースにマッチさせ、実行の中断を回避する。（対応PRs: #10423, #10606, #17374, #12068）

これら2つの層が協力して、脆弱なMoEパイプラインを高弾性エンジンに変換する。

図：Elastic EPシステム図（4 GPUのケース）。

4. Mooncakeの役割：Elastic EPを支援

Elastic EPの効果的な実装には、動的トポロジー変更をサポートし、部分故障下でもMoE推論の数学的正確性を確保する高弾性通信ライブラリが必要である。Mooncake EPはまさにこのために設計され、フォールトトレラントバックエンドおよびEP通信コアとして、PyTorchエコシステムで広く認知されている。その主要な機能には以下が含まれる：

弾性汎用Collective：broadcast、allgatherなどの標準プリミティブが厳密にフォールトトレラントであることを保証。
専用EPプリミティブ：MoEスパース活性化を管理するdispatchやcombineなど、EP必須プリミティブに対してフォールトトレランスを提供。
高性能RDMAと高速故障検出：GPU Direct RDMAを最大限に活用し、高スループット・低遅延のトークン分散を実現し、ネットワーク制御のタイムアウトメカニズムに基づいて故障を迅速に検出。
シームレスなSGLang統合：基盤となるネットワークは複雑だが、SGLangの実行フローとスケジューリングロジックとプラグアンドプレイで統合でき、大規模な再構築なしに部分故障耐性を解除。

5. Elastic EPの有効化

SGLangサーバーを起動する際、以下のパラメータを使用してElastic EPを有効化する：

--elastic-ep-backend mooncake：フォールトトレラントtorch distributedバックエンドとしてMooncakeを有効化。
--moe-a2a-backend mooncake：EP通信バックエンドとしてMooncakeを有効化。
--mooncake-ib-device <comma-separated-ib-device-list>：Mooncake通信用のIBデバイスを指定。
--ep-num-redundant-experts <num>：冗長エキスパート数を設定、値が高いほどより多くの故障に耐える。
--disable-custom-all-reduce：デフォルトのカスタムall-reduceを無効化。
--enable-elastic-expert-backup：メモリ内エキスパート重みバックアップを有効化し、故障シナリオでの高速復旧をサポート。

注：NIXL EPはNVIDIA Dynamo TeamによるElastic EPフレームワーク下での最近の実装で、--moe-a2a-backend nixlで試用可能。

謝辞

コミュニティ貢献者に感謝：SGLangコアチーム（Shangming Cai等）、Mooncakeチーム（Xun Sun等）、Volcano Engine、Approaching AI、JD.com、Aliyun、およびNVIDIA Dynamo Team。