## Memo ## Memo with LLM ### 論文情報 - **タイトル**: xDeepServe: Model-as-a-Service on Huawei CloudMatrix384 - **著者と所属**: Ao Xiao他127名（Huawei Cloud所属） - **発表先**: arXiv preprint (arXiv:2508.02520) - **発表年**: 2025年8月 ### 論文概要 本論文は、HuaweiのCloudMatrix384 SuperPod上で大規模MoE（Mixture-of-Experts）モデルを効率的に提供するためのLLMサービングシステムxDeepServeを提案している。Transformerlessと呼ばれる分散アーキテクチャを中核とし、Attention、Feedforward、MoEコンポーネントを独立したNPU上で実行することで、計算とメモリの独立したスケーリングを実現している。CloudMatrix384のグローバル共有メモリを活用した通信ライブラリXCCLにより、数百台のNPU間で効率的な推論を可能にしている。 ### 詳細解説 #### 問題設定 **入力**: 大規模[[MoE]]モデル（[[DeepSeek-V3]]/R1、Kimi K2、Qwen等）の推論リクエスト。入力シーケンス長は最大96Kトークン、出力は最大32Kトークン。 **出力**: 低レイテンシ（TTFT < 2秒、TPOT < 35ms）かつ高スループットでの推論結果。 **必要なデータ**: - CloudMatrix384ハードウェア: 384個のAscend 910C NPU（768ダイ）、192個のKunpeng CPU、数百GB/sの高速UB（Unified Bus）ネットワーク - モデルパラメータ: DeepSeek-V3は671B（6710億）パラメータ、256個のルーテッドエキスパート + 32個の共有エキスパート - KVキャッシュ: MLA（Multi-head Latent Attention）による圧縮されたKey-Valueキャッシュ **主要課題**: 1. MoEモデルにおける数百NPU間のエキスパートルーティング、同期、負荷分散 2. 計算バウンドなprefillとメモリバウンドなdecodeフェーズの干渉 3. SuperPodスケールでのグローバル同期によるボトルネック 4. 単一障害点の排除と信頼性の確保 #### 提案手法 ##### 1. Transformerless: 完全分散アーキテクチャ **分散Prefill-Decode (§5.1)** - Prefillインスタンス: TP=4、動的シーケンス長対応、Eager Graph実行 - Decodeインスタンス: TP=1、静的Graph実行、CloudMatrix384専用配置 - 異種配置: PrefillはAscend 910（第2世代）とCloudMatrix384の両方で実行、DecodeはCloudMatrix384のみで実行 - KVキャッシュ転送: DistFlowを用いたpoint-to-point通信（§3.1のsend/recv API） 具体例: 2K入力 + 2K出力のワークロードで、PrefillからDecodeへのKVキャッシュ転送をRoCE/VPC経由で実施。MLA圧縮により転送量を削減。 **分散MoE-Attention (§5.2)** - 768 NPUダイを使用: 288ダイがEP288（Expert Parallelism）、480ダイがMLA実行 - 非対称リソース割り当てに対応する新しい通信プリミティブA2E/E2A（§3.3） - Trampoline Forward機構: 288個のエキスパートNPUのうち160個をトランポリンとして使用し、2段階ルーティングでメタデータオーバーヘッドを削減 数式例（Expert Placement Load Balancing）: 最もホットなエキスパートの選択: $e^*_l = \arg\max_{e \in E_l} \sum_{t=1}^T n_t(e, l)$ 冗長性予算$B$の下での負荷最小化: $\min \sum_{l=1}^L \max_{e \in E_l} \left( \frac{n(e, l)}{r(e, l)} \right)$ ここで、$n(e,l)$はレイヤー$l$のエキスパート$e$に割り当てられたトークン数、$r(e,l)$はレプリカ数。 **DPドメイン抽象化** - 複数のDPグループを1つのDPドメインにカプセル化 - 1つのドメインのみがMoE NPUと通信、マイクロバッチングと組み合わせて効率化 - 具体的構成: 3つのDPドメイン × 160 DPグループ（TP=1）、各グループがバッチサイズ96 ##### 2. XCCL通信ライブラリ（§3） **Point-to-Point通信 (§3.1)** CloudMatrix384のグローバル共有メモリ上に構築された8ステップの分散メモリプロトコル: 1. 送信側でXCCL sendを呼び出し、mtu-inでデータバッファにコピー 2. mtu-outで受信側のマネージドデータ領域に転送 3. tailPtrを更新して転送量を通知 4. ACKをビジーポーリング 5-7. 受信側でポーリング、mtu-in/outでコピー 8. ACK送信で完了 パフォーマンス: 1MB以下のペイロードで20μs以下、9MBで48コア使用時に2.5倍高速化 **All-to-All通信 (§3.2, §3.3)** - Dispatch/Combine（EP用）: EP128構成でバッチサイズ96/ダイ時、Dispatch 234μs（平均）、Combine 312μs（平均） - A2E/E2A（分散MoE-Attention用）: グローバルバッチサイズ15,360（160×96）時、A2E 172μs、E2A 193μs - NPU-Direct URMA: 計算コアからDMAエンジンへ直接リモートメモリアクセス、レイテンシは増加するが高スループット・コア消費削減を実現 ##### 3. FlowServeサービングエンジン（§4） **スケーラブルなDPグループ** - 各DPグループが完全な実行パイプラインを保持: トークナイゼーション、SPMD実行、RTCキャッシュ、DistFlowネットワーキング - TE-shellは最小限の調整のみ: リクエスト分散、エキスパート負荷分散トリガー、ヘルスチェック **DP負荷分散 (§4.3)** - Prefill: シングルレベル協調スケジューラ、リーダースケジューラ（DP-0）がコストモデル（プレフィックスキャッシュヒット率等）でバッチ割り当て - Decode: バッチサイズ制限とKVキャッシュ使用量を考慮、最も低いKVキャッシュ使用率のDPグループを選択 **プロアクティブGC (§4.4)** - CPUコアピンニング、PTAグラフキャッシング、手動Python GC実行 - 最初のDispatch演算子での100ms超のジッター削減 **エキスパート負荷分散 (§4.5)** - データ駆動アプローチ: 定期的にトークンルーティングパターンを分析 - EPLB（Expert Placement Load Balancing）アルゴリズムで冗長エキスパート選択 - 非同期でエキスパート重みをスワップ、フォワードレイテンシを40%以上改善 **Multi-Token Prediction (§4.6)** - DeepSeekのMTPを統合、5ステップループで投機的デコーディング - 1つのMTPレイヤーで70-90%の受理率、TPOTを40%削減 - 2つ目のMTPレイヤーを追加学習: 280K社内サンプルで学習、2.26→2.35トークン/ステップ（9%改善） **INT8量子化 (§4.7)** - SmoothQuant + GPTQを組み合わせたPTQ - MLA、MoE、MLPモジュールをINT8に量子化 - トークンワイズ量子化（アクティベーション）、チャネルワイズ量子化（重み） - npu_quant_matmul (QMM)演算子で高速化 - KVキャッシュの非RoPE成分もINT8に量子化 ##### 4. 信頼性機構（§6） **障害検知 (§6.1)** - 多層ハートビート: 制御プレーン → TE shell → DPマスタープロセス - リンクプローブ機構: KV転送パイプラインの無音ストールを検出 **障害回復 (§6.2)** - Stage 1: Restart-the-World（小規模クラスタ、全体再起動） - Stage 2: Prefill/Decode独立フェイルオーバー（垂直スケーリング対応、各エキスパートに少なくとも1レプリカ保持） - Stage 3: 細粒度エラーハンドリング - トークン再計算: ネットワーク不安定時にロールバックして再実行 - オンチップメモリフォールト: CANNランタイムで仮想メモリ再マッピング、障害領域をマスク #### 新規性 ##### 1. SuperPodスケールでの初の完全分散MoE-Attentionシステム 先行研究（FastDecode、Lamina、InstAttention、MegaScale-Infer）は小規模モデルのみを対象としていたが、本研究は768 NPUダイでDeepSeek-R1/V3を実行し、production環境で1年以上運用している。これはSuperPodスケールでの分散MoE-Attentionの初の実装例である。 ##### 2. CloudMatrix384専用の通信ライブラリXCCL グローバル共有メモリをベースとしたメモリセマンティクス通信を実装。300K以上のNPUペア間でマイクロ秒レベルのレイテンシを実現。従来のRDMA verbs（FaRM、Clover）に類似したプロトコル設計をNPU環境に適用した点が新しい。 ##### 3. Trampoline Forward機構 非対称NPU割り当て（288エキスパートNPU vs 160 attention NPU）の問題を解決。従来のpull-basedメカニズムは高いfan-outとスカラスループット制限により非効率だったが、2段階ルーティング（トランポリンNPU経由）でメタデータオーバーヘッドを削減。 ##### 4. DPドメイン抽象化 マイクロバッチングのみに依存せずinter-DP並列性を実現。複数DPグループをドメイン化し、MoE NPUとの通信を時分割多重化することで、バッチサイズを縮小せずに効率を向上させた。 ##### 5. Persistent Kernelスケジューリング MoE NPU向けゼロオーバーヘッドスケジューリング。3つの並行ストリーム（A2E受信、MoE計算、E2A送信）がビジーポーリングループで実行され、マイクロ秒レベルのMoEカーネル実行時にCPU介入（ミリ秒）を回避。 ##### 6. 異種Prefill-Decode配置 PrefillはAscend 910とCloudMatrix384の両方で実行し、DecodeはCloudMatrix384専用とする異種配置により、コストと性能のバランスを実現。高帯域幅インターコネクトを要するDecodeを最適化した。 #### 実験設定 **データセット**: - ShareGPTから構築した2K+2Kワークロード（2Kプロンプト + 2K出力、固定長） - Production環境: 入力長0-64Kトークン（平均13K）、出力長平均2.1K **評価指標**: - **TTFT (Time To First Token)**: 最初のトークン生成までの時間、SLA < 2秒 - **TPOT (Time Per Output Token)**: 出力トークンあたりの時間、SLA < 35ms（通常）、< 50ms（実験） - **スループット**: トークン/秒/チップ、システム全体のトークン/秒 - **レイテンシ内訳**: Attention、Dispatch、Combine、MLA、Gating、A2E、E2A等のカーネルレベルレイテンシ **ハードウェア構成**: - 実験1（Colocated Prefill-Decode）: 18 Ascendサーバー、288 NPUダイ、DP288+EP288、ローカルバッチサイズ60、グローバルバッチサイズ17,280 - 実験2（分散MoE-Attention）: 1つのCloudMatrix384（768 NPUダイ）、480ダイMLA + 288ダイEP288、ローカルバッチサイズ96、グローバルバッチサイズ15,360 - Production: 16 Ascendサーバー、4 Prefill TE（各DP8+EP32）+ 1 Decode TE（DP128+EP128） **モデル構成**: - DeepSeek-V3/R1: 671Bパラメータ、256ルーテッド + 32共有エキスパート - Kimi K2、Qwen: 同様のMoEアーキテクチャ - MTP: 1-2レイヤー、グリーディサンプリング - 量子化: INT8 PTQ（SmoothQuant + GPTQ） #### 実験結果 **Decode性能（§7.1）**: *Colocated Prefill-Decode構成:* - TPOT: 50ms（MTP受理率90%時） - デコードイテレーション時間: 93ms（MTP forward、サンプリング、メインモデル実行、最終サンプリング含む） - スケジューリングギャップ: 2ms - Per-chipスループット: 2,057トークン/秒（計算式: 2ダイ/チップ × バッチ60 ÷ 50ms × 1000ms） - 全体スループット: 345,000トークン/秒（DP288全体） - カーネルレイテンシ内訳（約3Kシーケンス長）: - Attention: 21.8%（シーケンス長とバッチサイズに依存、長いシーケンスでさらに増加） - Dispatch + Combine: 約36%（グローバル同期カーネル） - Dispatch平均: 234μs（最小185μs、最大1,231μs、最大値は最小値の約6.6倍） - Combine平均: 312μs（最小165μs、最大2,939μs、最大値は最小値の約17.8倍） *分散MoE-Attention構成:* - TPOT: 50ms（MTP受理率90%時） - Per-chipスループット: 2,400トークン/秒 - レイヤーごとのレイテンシ（各約0.7ms）: MLAProlog、MLA、Gating、A2E第1段階 - MoE通信レイテンシ: A2E 0.17ms、MoE計算 0.12ms、E2A 0.19ms - 総フォワード時間: 93ms（内訳: スケジューラオーバーヘッド2ms、MTPレイヤー5ms、レイヤーワイズ計算等） **Production環境性能（§7.2）**: - TTFT: 900ms（目標2秒以下を達成） - 平均TPOT: 34.8ms（目標35ms以下を達成） - 入力長分布: 0-64K（平均13K）、出力長平均2.1K - 長シーケンス対応: 最大96K入力、処理時間最大30分、専用リソース割り当てで短シーケンスとの干渉回避 **通信性能詳細**: *Point-to-Point通信（§3.1）:* - 1MB以下のペイロード: 2コアで20μs以下 - 9MBペイロード: 2コアで約90μs、48コアで約35μs（2.5倍以上の高速化） - ランダムに選択した異なるサーバー上の2つのNPUダイ間で測定 *Dispatch/Combine（§3.2）:* - EP128構成、バッチサイズ96/ダイ、DeepSeek-R1使用 - Dispatch: 平均234μs、量子化有効時は小バッチで若干高レイテンシ、バッチサイズ32超でCombineより高速（データサイズ半減効果） - Combine: 平均312μs - グローバルバッチサイズ: 96 × 128 = 12,288 *A2E/E2A（§3.3）:* - 構成: 3 DPドメイン × 160 DPグループ（TP=1）、288エキスパートNPU - バッチサイズ: 96/ダイ、グローバル15,360（160 × 96） - A2E: 172μs、E2A: 193μs - SuperPodスケール（高並行性）でもマイクロ秒レベルのレイテンシを維持 **最適化効果**: *エキスパート負荷分散（§4.5）:* - 負荷分散前: ホットエキスパートが全体の律速要因 - 負荷分散後: フォワードレイテンシ40%以上改善 - 動的エキスパート重みスワップにより推論を中断せずに最適化 *Multi-Token Prediction（§4.6）:* - 1 MTPレイヤー: 70-90%受理率、固定バッチサイズでTPOTを40%削減 - 2 MTPレイヤー（公開重み再利用）: 2.26トークン/ステップ - 2 MTPレイヤー（2層目を追加学習）: 2.35トークン/ステップ（9%改善） - 学習データ: 280K社内プロンプトサンプル、メインモデルと第1MTPレイヤーを凍結 *INT8量子化（§4.7）:* - SmoothQuant + GPTQによりFP8からINT8へ変換 - 対象モジュール: MLA（Wq_a、Wkv_a、Wq_b、Wo）、MoE（ルーテッド・共有エキスパート）、MLP（up_proj、gate_proj、down_proj） - エキスパートごとに最低40-128サンプルで量子化 - Smoothing操作でアクティベーション/重みの動的範囲を調整（アクティベーションは重みの10-100倍の範囲） - KVキャッシュの非RoPE成分もINT8に量子化 *プロアクティブGC（§4.4）:* - CPUコアピンニング、PTAグラフキャッシング、手動Python GC - 最初のDispatch演算子（第4レイヤー）でのジッターを100ms超から削減 - SuperPodスケール（数百NPU/CPUコア）での同期感度を軽減 **信頼性実績（§6）**: - Production環境で1年以上の安定稼働 - 多層ハートビート + リンクプローブで障害検知 - 細粒度エラーハンドリング（トークン再計算、メモリフォールトマスキング）により可用性維持 - Stage 3（細粒度回復）により個別リクエスト失敗時もシステム継続稼働 **スケーラビリティ検証**: - 数百NPUダイにスケール、単一障害点なし - DPグループ完全分散、TE-shellは最小限の調整のみ（リクエスト分散、EP-LBトリガー、ヘルスチェック） - グローバル同期最小化: Dispatch/Combine最適化（EP-LB、量子化）、DP負荷分散、プロアクティブGC ## Abstract スケールアウトされたLLMとスケールアップされたSuperPodsの台頭は、大規模AIインフラストラクチャにおける新たな時代の到来を示しています。LLMは、DeepSeek、Kimi、Qwenなどの最近のモデルに見られるように、MoE（Mixture-of-Experts）を介してスケールアウトし続けています。一方、AIハードウェアはスケールアップしており、HuaweiのCloudMatrix384 SuperPodは数百GB/sの高速インターコネクトを提供しています。SuperPodスケールのハードウェア上で大規模MoEモデルを実行することは、新たな課題をもたらします。新しい実行モデル、スケーラブルなスケジューリング、効率的なエキスパート負荷分散、および単一障害点の排除が必要となります。 本論文は、SuperPodスケールのインフラストラクチャ向けに設計されたHuawei CloudのLLMサービングシステムであるxDeepServeを提示します。その中核となるのはTransformerlessという分散アーキテクチャであり、トランスフォーマーモデルをモジュラーユニット—attention、feedforward、MoE—に分解し、高速ファブリックで接続されたNPU上で独立して実行します。この設計を2つの形式で実装しています：分散prefill-decodeと分散MoE-attentionです。この完全に分散されたセットアップにより、パフォーマンスを犠牲にすることなく、計算とメモリの独立したスケーリングが可能になります。このアーキテクチャをサポートするため、CloudMatrix384のグローバル共有メモリを活用して効率的なpoint-to-pointおよびall-to-allプリミティブを実装する通信ライブラリXCCLを提案します。また、システムレベルの技術によりサービングエンジンFlowServeを拡張し、数百のNPUにわたるスケーラブルな推論を可能にしています。