# RaidServe: High-performance Resilient Serving > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 3 (May 20 / Wed)、Grand Ballroom 1、15:15 - 15:30 PDT > - **登壇者:** Ziyi Xu (Shanghai Jiao Tong University)、Zhiqiang Xie (Stanford University)、Swapnil Gandhi (Stanford University)、Christos Kozyrakis (Stanford University / NVIDIA Research) > - **URL:** https://mlsys.org/virtual/2026/oral/3856 > - **OpenReview:** https://openreview.net/forum?id=5pl9fdbEkq > [!abstract] 概要 > テンソル並列（TP）は大規模言語モデル（LLM）の推論を複数 GPU にわたって効率的にスケールさせるが、その密結合によりシステムは脆弱になる。単一 GPU の障害が実行を停止させ、高コストな KVCache の再計算を引き起こし、長期的な計算・メモリの不均衡をもたらす。本論文では、GPU の不規則な可用性のもとで高性能を維持する耐障害 TP サービングシステム RaidServe を提案する。RaidServe は 3 つの手法を導入する。(1) メモリ利用を均等化する巡回 KVCache 配置（Cyclic KVCache Placement）、(2) ストラグラーを排除するためにテンソル並列とデータ並列のアテンションを統合するハイブリッドアテンション（Hybrid Attention）、(3) リクエストを動的に分散する細粒度負荷認識ルーティング（Fine-Grained Load-Aware Routing）である。さらに、プロアクティブな KVCache バックアップとオンデマンド重み復元により、高コストな再計算と冗長なデータ転送を回避する。8 基の H100 DGX システムにおいて実世界の障害トレースと代表的ワークロードで評価した結果、RaidServe は標準的な障害対応手法と比較して最大 2 倍のスループットおよび 2 桁低い復旧レイテンシを達成した。最大 3 基の GPU 障害下でも高スループットと均衡した利用率を維持する。 ## テーゼ テンソル並列 LLM サービングにおいて、GPU 障害時のメモリ・計算の不均衡と復旧コストという二重の課題に対し、巡回 KVCache 配置・ハイブリッドアテンション・負荷認識ルーティングの組み合わせとプロアクティブなバックアップ機構により、性能を大幅に維持したまま高速な障害復旧を実現する。 ## 問題設定 - テンソル並列（TP）は高帯域インターコネクト（NVLink 等）で GPU を密結合するため、単一 GPU の障害がスケールアップドメイン全体を停止させる - GPU 障害は頻発する。Alibaba Cloud では上位 5% のリソース集約ワークロードで異常終了率が最大 44% に達し、Meta・ByteDance・Google でも同様の課題が報告されている - 障害時の課題は 2 つに大別される - **復旧オーバーヘッド（Challenge #1）:** 障害 GPU 上の KVCache が失われ、全処理中リクエストの再計算（プリフィルのやり直し）が必要。モデル重みの再シャーディングも発生し、レイテンシスパイクと SLO 違反を引き起こす - **持続的不均衡（Challenge #2）:** 復旧後は GPU 数が減少（例: 8→7）し、アテンションヘッドの不均等分配により計算負荷が最大 2 倍偏る。KVCache メモリも偏り、実効バッチサイズが制約されスループットが低下する ## 提案手法 ### 非一様テンソル並列（Non-Uniform Tensor Parallelism） - 不規則な GPU 数でもモデルを実行可能にする非一様 TP を推論サービングに適用。TP ワーカー間の同期を調整し、任意の GPU 数での柔軟な TP 構成を実現する ### 巡回 KVCache 配置（Cyclic KVCache Placement） - アテンションヘッドとその KVCache ブロックを GPU 間で巡回的に配置する。TP 度 n の構成で連続 n 層にわたりヘッド割り当てをローテーションすることで、集約 KVCache メモリ利用を均等化する - ナイーブ配置と比較して KVCache 容量を約 50% 改善（Figure 1 の例） - リクエスト分布に依存せず、各リクエストが各 GPU に約 1/n の KVCache を配置する決定的な下限保証を提供する ### ハイブリッドアテンション（Hybrid Attention） - 各 GPU に同数のアテンションヘッドを TP 方式で割り当て、余剰ヘッドを DP（データ並列）方式で複製し異なるリクエストを処理する - GPU 数がヘッド数を下回る場合に発生する層内計算不均衡（ストラグラー）を排除し、GPU のアイドル時間を最小化する - SGLang で採用されている DP アテンション（MLA モデル向け）はハイブリッドアテンションの特殊ケースに相当する - 巡回配置とハイブリッドアテンションは相補的に機能する。巡回配置はメモリ均衡を、ハイブリッドアテンションは計算均衡を保証する ### 細粒度負荷認識ルーティング（Fine-Grained Load-Aware Routing） - **負荷認識 DP ランクルーティング:** 各受信リクエストを推定残ワークロード（トークン単位の待ち行列負荷）が最小の GPU に割り当てるグリーディ戦略。オンラインメイクスパン最小化問題のインスタンスとして定式化 - **適応的チャンクプリフィル:** 従来のチャンクプリフィル（バッチ当たり 1 リクエスト 1 チャンク）と異なり、複数リクエストのチャンクを同一バッチ内で同時実行可能にする。グローバルなプリフィルトークンバジェット N を設定し、最も負荷の小さい GPU にトークンを反復割り当て（Algorithm 1） ### 高速復旧（Lightning Recovery） - **プロアクティブ KVCache バックアップ:** 通常稼働時に KVCache をインクリメンタル・非同期的にホストメモリ（CPU DRAM）へバックアップする。リクエスト完了時にバックアップを破棄するため追加の退避ポリシー不要。バックアップトラフィックは PCIe 5.0 x16（約 50 GB/s）で、例えば LLaMA-3.1-70B・16K コンテキスト・56 リクエストバッチの場合 GPU 当たり約 35 GB、転送時間約 0.7 秒でサービングとオーバーラップ可能 - **オンデマンド重み復旧:** 障害後、各生存 GPU は既に保持している重みを維持し、不足シャードのみをホストメモリからロードして巡回的に再分配する。FFN 層では中間次元を TP 度非依存の固定サイズシャードに分割しておくことで、生存 GPU が 1 つの不足シャードのみをリロードすれば済む（Figure 4）。アテンション層ではホストメモリからの部分ロードと NVLink 経由のピア間交換を組み合わせ、冗長な PCIe 転送を排除する - テストベッド（8 基 H100 ノード）ではホストメモリ 1.5 TB に対し GPU HBM 合計 640 GB であり、重みと KVCache の両方のバックアップを十分に収容できる ## 実験・評価 ### 実験環境 - NVIDIA H100 GPU（80 GB）8 基搭載サーバー、第 4 世代 NVLink 接続、PCIe 5.0 x16 で CPU に接続 - モデル: LLaMA-3.1-70B-Instruct（密モデル）および Mixtral-8x22B-Instruct-v0.1（MoE モデル） - 約 7,000 行の軽量カスタム LLM サービングエンジン上に実装。vLLM・SGLang と同等性能を達成 ### オフラインスループット（障害環境下） - GCP クラウド可用性トレースを用いた 8x8 H100 クラスターシミュレーション（平均 GPU 可用性 58.07） - LLaMA-3.1-70B: RaidServe は Standard TP 比 1.28 倍の平均スループット、Fault-scaled 性能の 95% を達成 - Mixtral-8x22B: スループット向上は 1.71 倍、Fault-scaled 性能の 92% を達成 - Non-Uniform TP 比でも LLaMA で 20%、Mixtral で 17% の追加高速化 ### オンラインスループット-レイテンシ（7 GPU 固定環境） - データセット: 実世界 Mooncake 会話トレース（3,000 リクエスト、平均入力長 13,516 トークン、平均出力長 349 トークン） - プリフィル段階: RaidServe は Standard-TP4 比で最大 2 倍、NonUniform-TP7 比で 1.28 倍のスループット（TTFT 10 秒制約下） - デコード段階: TBT 40 ms 制約下で Standard-TP4 比 2 倍、NonUniform-TP7 比 1.60 倍（LLaMA-70B）、NonUniform-TP7 比 1.85 倍（Mixtral-8x22B） ### GPU 数別性能（TP4-TP8 スケーリング） - TP 度が不規則になる TP5 以上で RaidServe の優位性が顕在化 - プリフィル段階: NonUniform-TP 比で TP5 0%、TP6 16%、TP7 25% の向上 - デコード段階: TP5 16%、TP6 51%、TP7 78% の向上 ### 最適化要素の分解（LLaMA-70B、7 GPU） - メモリ均衡（巡回配置）: プリフィルへの寄与は僅少だがデコードスループットを 34% 向上 - 計算均衡（ハイブリッドアテンション）: プリフィルスループットを 25% 向上、デコードをさらに 43% 追加向上 - 全最適化統合: プリフィル 1.58 倍、デコード 2.06 倍（Standard-TP4 ベースライン比） ### 復旧レイテンシ（LLaMA-70B、Mooncake トレース 500 リクエスト窓） | 手法 | 復旧レイテンシ | 高速化率 | |---|---|---| | Recompute（KVCache 再計算） | 22 秒 | 1.00 倍 | | RaidServe-Host（KVCache バックアップ復元） | 530 ms | 41.5 倍 | | RaidServe-Full（＋オンデマンド重み復旧） | 120 ms | 183 倍 | | RaidServe-Oracle（理想値、メタデータのみ復元） | 15 ms | N/A | - ホスト側 KVCache バックアップにより P90/P99 TBT が 10 秒超から 1 秒未満に低減 - オンデマンド重みロードにより P99 TBT が 572 ms から 229 ms へ低減（2.5 倍改善）、Oracle 下限に接近 ## 結論・オープン課題 - RaidServe は巡回 KVCache 配置・ハイブリッドアテンション・負荷認識ルーティングによりメモリ・計算の不均衡を解消し、プロアクティブバックアップとオンデマンド重み復旧により復旧を 183 倍高速化した - 最大 3 基の GPU 障害（8 基中）でも頑健に動作する - 現行の障害モデルはノード内 GPU レベルの障害のみを対象としており、ドライバー障害やインターコネクト劣化などのより複雑な障害モードは未対応 - 評価はシングルノード構成に限定されており、NUMA 境界を超えたメモリ・計算均衡の拡張は今後の課題 - NVL72 のような大規模マルチ GPU システムへの適用が今後重要になる - パラメーターオフローディングや KVCache オフローディングとは直交する手法であり、メモリ制約環境では相補的に利用可能 - 細粒度リソース共有による並行ジョブ間のリソーススターべーション緩和への応用も将来方向として示唆されている