> [!abstract] 概要(arXiv abstract の日本語訳) > テンソル並列(TP)は大規模言語モデル(LLM)推論を複数 GPU に効率的にスケールさせることを可能にするが、その密結合ゆえにシステムは脆弱になる。単一の GPU 障害が実行を停止させ、高コストな KVCache 再計算を誘発し、長期的な計算・メモリの不均衡をもたらしうる。本論文では、不規則な GPU 可用性の下でも高性能を維持する耐障害 TP サービングシステム FailSafe を提示する。FailSafe は GPU 間で計算とメモリのバランスを取るために3つの技法を導入する: (1) 均等なメモリ利用のための Cyclic KVCache Placement、(2) ストラグラーを排除するためにテンソル並列アテンションとデータ並列アテンションを組み合わせる Hybrid Attention、(3) リクエストを動的にバランスさせる Fine-Grained Load-Aware Routing。さらに、高コストな再計算と冗長なデータ転送を避けるため、プロアクティブな KVCache バックアップとオンデマンドの重み復旧を採用する。これらの技法を既存の LLM インフラストラクチャと互換性のある軽量なサービングエンジンに実装した。8×H100 DGX システム上で実世界の障害トレースと代表的なワークロードを用いて評価した結果、FailSafe は標準的な障害対応アプローチと比較して最大2倍高いスループットと2桁低い復旧レイテンシを達成する。最大3台の GPU 障害が発生しても、FailSafe は高スループットと均衡した利用率を維持し、動的かつ信頼性の低いハードウェア条件下での頑健かつ効率的な LLM サービングを実証する。 ## 論文情報 - **タイトル**: FailSafe: High-performance Resilient Serving - **著者**: Ziyi Xu([[Shanghai Jiao Tong University]])、[[Zhiqiang Xie]]([[Stanford University]])、[[Swapnil Gandhi]]([[Stanford University]])、[[Christos Kozyrakis]]([[Stanford University]] / NVIDIA Research) - **媒体**: arXiv preprint(2025年11月18日投稿、cs.DC)。本文冒頭に "Under Review" と明記されており、査読中の版。 - **arXiv ID**: 2511.14116 - **連絡先**: Ziyi Xu <[email protected]>、Christos Kozyrakis <[email protected]> > [!note] MLSys との対応関係(2026-07-20 追記で訂正) > 本ソースは MLSys 2026 Oral(https://mlsys.org/virtual/2026/oral/3856、OpenReview ID `5pl9fdbEkq`)として "RaidServe: High-performance Resilient Serving" のタイトルで発表予定と見られる。arXiv 版(本ソース)のタイトルは "FailSafe" であり、著者・技術内容(Cyclic KVCache Placement・Hybrid Attention・Fine-Grained Load-Aware Routing・Lightning Recovery)は完全に一致する。 > > ユーザーが別途入手した PDF(`.raw/papers/80_RaidServe_High_performance_.pdf`)は "RaidServe: High-performance Resilient Serving" のタイトルを持ち、本文はこの arXiv 版と一字一句(著者順・abstract・§1〜§7の構成)一致する ── システム名の置換(RaidServe ↔ FailSafe)以外の差分は組版(1段組 vs. arXiv 2段組)のみ。この PDF の脚注には "Proceedings of the 8 th MLSys Conference, Santa Clara, CA, USA, 2025. Copyright 2025 by the author(s)." と記載されているが、dblp の MLSys 2025(8th MLSys, https://dblp.org/db/conf/mlsys/mlsys2025.html)採択論文リストには本論文(RaidServe・FailSafe いずれのタイトルでも、著者名でも)が見つからない。したがって、この脚注は MLSys 提出テンプレートの決まり文句(著者が更新し忘れた、または別年度のテンプレートを流用した)である可能性が高く、**MLSys 2025 での正式発表を裏付ける証拠にはならない**。実際の発表先は上記の MLSys 2026 Oral 情報の方が信頼できると判断する。査読・発表状況は流動的なため、今後の更新で確定情報が得られ次第、本注記を差し替える。 ## 概要 FailSafe は、テンソル並列(TP)で複数 GPU にまたがる LLM サービングにおいて、GPU 障害が発生しても高いスループットを維持する耐障害サービングシステムである。GPU 障害は (1) KVCache 喪失による再計算コストと (2) 障害後も残り続ける計算・メモリの不均衡という2種類のオーバーヘッドを引き起こすとし、前者に対しては「Lightning Recovery」(プロアクティブバックアップ + オンデマンド重み復旧)、後者に対しては「Memory and Computation Balancer」(Cyclic KVCache Placement + Hybrid Attention + Fine-Grained Load-Aware Router)という2系統の技法で応答する。8×H100 DGX での評価で最大2倍のスループット向上、最大183倍の復旧高速化を報告する。 ## 問題設定 - **入力**: 不規則な数の GPU(例: 8台構成のうち1〜3台が故障し7〜5台稼働)上で稼働する、テンソル並列で分散配置された LLM。 - **前提**: [[Non-uniform Tensor Parallelism]](Arfeen+ 2025、耐障害 LLM 訓練由来)を用いて、GPU 数が不規則でもモデル重みと計算を分散できる。FailSafe はこの上に構築する。 - **課題1: 不均一ハードウェア構成下の負荷不均衡**。FFN 層は中間次元が大きく不均一な GPU 数でも比較的均等に分割できるが、アテンション層はヘッド数(通常数十)単位でしか分割できず、不規則な GPU 数では一部の GPU が2ヘッド、他が1ヘッドを担当するといった不均衡が生じる。LLaMA-3.1-70B(8 KVヘッド)を7 GPU に分割すると、アテンション層の計算が最大2倍遅くなる(Figure 2)。長コンテキストではこの不均衡が KVCache メモリ量にも及び、一部ランクが他の2倍の KVCache メモリを消費しうる。 - **課題2: 状態喪失によるレイテンシスパイク**。GPU が突然故障すると、そこに存在した KVCache(動的な per-request 状態)は失われ、影響を受けたリクエストの prefill フェーズ全体を再計算する必要がある。オンライン実験では、失われた KVCache の再計算だけで20秒超を要し、その間に影響を受けたリクエストは深刻な遅延を被り、サービング パイプライン全体にキューイング遅延が波及する。 ## 提案手法 ### アーキテクチャ: Memory and Computation Balancer + Lightning Recovery FailSafe はまず Arfeen+ 2025 の非均一テンソル並列の素朴な実装を出発点とし、その上に「メモリ・計算バランサ」と「高速復旧機構」の2系統を追加する。 **Cyclic KVCache Placement(§3.1)**: アテンションヘッドと対応する KVCache ブロックを GPU にわたって層ごとに周期的(cyclic)に割り当てる。素朴な配置ではある GPU に KVCache が偏るが、Cyclic Placement は連続する n 層(TPn 構成)にわたって集約 KVCache 割り当てを均等化する。現代の LLM は層数(数十〜数百)が TP world size(通常10未満)を大きく上回るため、この周期割り当てが GPU 間の KVCache メモリ利用を効果的に平滑化する(Figure 1)。この配置だけでは層内の計算不均衡は解消できない——各アテンション層は依然として計算前後に all-reduce を行うため、一部 GPU が他より多く計算する一時的な停滞が残る。 **Figure 1: Cyclic KVCache Placement による均等化** ![[_attachments/arxiv-2511.14116/fig01-cyclic-kvcache-placement.png]] (Figure 1. 4 KVヘッド・非均一 TP3 の例。素朴な配置(上)では GPU0 が KV0 と KV3 の両方を保持し偏るのに対し、Cyclic Placement(下)は層ごとにヘッド-GPU 対応をローテーションさせ、3層平均で KVCache メモリ利用を約50%改善する。Source: Figure 1, arxiv-2511.14116.) **Hybrid Attention(§3.1)**: 層内の計算不均衡をさらに緩和するため、各テンソル並列ワーカーに同数のアテンションヘッドを割り当てつつ、余ったヘッドをデータ並列(DP)で処理する Hybrid Attention を導入する。TP と DP の一般化として捉えられる。例えば LLaMA-3 70B(8ヘッド)を7 GPU で動かす場合、各 GPU が1ヘッドを TP 担当し、残る1ヘッドを7 GPU 全体でレプリケートして DP 担当とすることで、そのヘッドの計算を異なるリクエストに対して並列化する。SGLang の DP Attention(MLA サービングに用いる)は、単一ヘッドを全 GPU に複製する Hybrid Attention の特殊ケースに相当する。ただし DP だけでは完全な均衡は保証されない——入力長がリクエストごとに異なるため、長コンテキストでは素朴な非均一 TP に近い挙動へ一時的に戻ることがある。 **Figure 2: Hybrid Attention によるストラグラー解消** ![[_attachments/arxiv-2511.14116/fig02-hybrid-attention.png]] (Figure 2. 4 KVヘッド・非均一 TP3 の例。素朴な非均一 TP(上)では GPU1・GPU2 が担当ヘッド計算を終えた後、GPU0 の残りヘッド計算(赤破線: GPU idle time)を全 GPU が待つストラグラーが生じる。Hybrid Attention(下)は残りヘッドをリクエスト単位でデータ並列化し、全 GPU が並行して計算を終える。Source: Figure 2, arxiv-2511.14116.) **Fine-Grained Load-Aware Router(§3.1)**: 残る不均衡を緩和するため、DP ランクへのリクエスト振り分け(Load-Aware DP-Rank Routing)と、計算均衡のとれたバッチ形成(Fine-Grained Chunked Prefill)の2つを組み合わせる。DP ランクスケジューリング問題を古典的なオンライン makespan 最小化問題としてモデル化し、各着信リクエストを推定残余ワークロードが最小の GPU へ割り当てる貪欲戦略を採る。さらに Algorithm 1(DP-aware Adaptive Chunked Prefill)により、複数リクエストのチャンクを同一バッチ内で結合実行できるようにし、トークン予算 N のもとで最も負荷の低いランクへトークンを逐次割り当てることでバランスの取れた prefill バッチを構築する。 **Lightning Recovery(§3.2)**: 復旧レイテンシの2大要因(KVCache 再計算、再シャーディングされた重みの再読み込み)にそれぞれ対応する2手法から成る。 - **Proactive KVCache Backup**: GPU サーバーに搭載される潤沢な CPU メモリ(GPU HBM より大容量かつ GPU 障害でも無傷)へ、稼働中に非同期で KVCache をバックアップし続ける。障害発生時、生存 GPU は既存 KVCache を再利用し、各 GPU は必要な部分だけをホストメモリから再読み込みする。Cyclic KV 配置により再読み込み対象も GPU 間で均等分散され、PCIe 転送帯域も均衡する。 - **On-demand Weight Recovery**: FFN 重みの中間次元に沿ったシャーディング順序は行列積の可換性により自由に並べ替えられるという数学的性質を利用する。従来の TP 推論では FFN 重みは中間次元に沿って連続的にシャーディングされるため、TP world size が変化すると(例: 8→7)既存シャードが新しいランクと整合せず、シャード全体の再読み込みを強いられる。FailSafe はこの可換性を利用し、各ランクが失われた重みの必要な部分集合だけを再読み込みできるようにし、データ転送と復旧時間を大幅に削減する。アテンション層については Hybrid Attention のデータ並列配置を用いて各ランクが DP 重みの異なる部分をホストメモリから読み込み、不足セグメントを NVLink 経由でピア間交換する(NVLink は PCIe より高帯域なため同期オーバーヘッドは小さく、進行中の重み読み込みとオーバーラップできる)。 **Figure 4: On-demand Weight Recovery** ![[_attachments/arxiv-2511.14116/fig04-ondemand-recovery.png]] (Figure 4. FFN 重み12シャード・アテンションヘッド4個の TP4 構成で GPU3 が故障した例。素朴な TP3 フォールバック(左端、赤×)は GPU3 が保持していたシャード(FFN9,10,11・Head3)全体をホストメモリからロードし直す必要があるが、FailSafe(右3ブロック)は FFN シャーディング順序の可換性を利用し、生存 GPU 各々が不足分の一部のみを PCIe 経由でロードし、アテンションヘッドの不足セグメントは NVLink 経由でピア間交換することで冗長な PCIe 転送を排除する。Source: Figure 4, arxiv-2511.14116.) ## 新規性 - 既存の耐障害分散推論システム(SpotServe、Llumnix、DejaVu、Medusa)は KVCache と重みのライブマイグレーションを実現するが、非均一テンソル並列に内在する計算・メモリ不均衡による持続的スループット低下には対処していない。FailSafe は Hybrid Attention と動的スケジューラを KVCache マイグレーションと統合し、高性能と頑健な耐障害性を両立させる点で新規性を持つ。 - 耐障害 LLM *訓練* の文脈で提案された Non-uniform Tensor Parallelism(Arfeen+ 2025)を LLM *サービング*に応用した上で、訓練にはない「アテンションヘッド単位の粒度制約」と「レイテンシに敏感な復旧要件」に特化した設計(Cyclic Placement・Hybrid Attention・Lightning Recovery)を追加している。 - 同じ Stanford グループが SOSP '24 で発表した [[ReCycle]](訓練向け耐障害システム、パイプラインバブルとデータ並列ピアの機能的冗長性を活用)とは対象領域(訓練 vs. サービング)も機構(パイプライン適応 vs. テンソル並列内のメモリ・計算バランシング)も異なるが、著者([[Swapnil Gandhi]]・[[Christos Kozyrakis]])と根底の設計思想(冗長性を持つ既存資源の活用による復旧高速化)を共有する。 ## 実験設定 - **ハードウェア**: 8×NVIDIA H100(80GB)を搭載したサーバー1台。GPU 間は第4世代 NVLink、GPU-CPU 間は PCIe 5.0 x16 で接続。 - **モデル**: 密モデル LLaMA-3.1-70B-Instruct、MoE モデル Mixtral-8x22B-Instruct-v0.1。 - **障害シミュレーション**: 8×8=64 GPU に相当するよう時間軸をスケーリングした GCP クラウド可用性トレース(Bamboo・Oobleck・ReCycle が採用した実績あるトレース)を用いて、1台の H100 サーバー(8 GPU)で8ノード分の障害・復旧イベントを再現。障害イベントはランダムに1 GPU を無効化し、復旧イベントはランダムに1 GPU を復旧させる。再構成(切り替え)レイテンシは全システム共通で10秒に固定。 - **オフラインワークロード**: OpenThoughts-114k(114,000件のマルチターン推論・指示追従サンプル)。入力長中央値352トークン、出力長中央値5,583トークン(Table 1)。 - **オンラインワークロード**: Mooncake の実世界会話トレースから3,000リクエストをサンプリングし、タイムスタンプをスケーリングして異なるリクエストレートを走査。入力長中央値8,001トークン、出力長中央値362トークン(Table 2)。 - **比較対象**: - オフライン評価: (1) 非耐障害ベースライン(TP 1/2/4/8 の離散構成のみサポート)、(2) 障害なし想定の Faultless(性能上限)、(3) GPU 可用性に比例してスケーリングした Fault-scaled。 - オンライン評価: (1) Standard-TP4(障害時の既定フォールバック構成)、(2) Standard-TP8(障害なし上限)、(3) Nonuniform-TP7(素朴な非均一 TP、負荷不均衡あり)、(4) FailSafe-TP7(全最適化を統合)。 - 復旧レイテンシ評価: (1) Recompute(再計算)、(2) FailSafe-Host(プロアクティブホストバックアップのみ)、(3) FailSafe-Full(オンデマンド重み復旧も追加)、(4) FailSafe-Oracle(理想化された下限)。 ## 実験結果 ### オフラインスループット(Figure 8) - LLaMA-3.1-70B: FailSafe は平均1.28倍高いスループットを達成し、Fault-scaled 性能の95%に到達。 - Mixtral-8x22B: スループット向上は1.71倍に拡大し、Fault-scaled 性能の92%に到達。モデルのメモリフットプリントが大きく標準 TP4 構成が実行不能になるため、資源逼迫の緩和効果がより顕著になる。 **Figure 8(a): LLaMA-3.1-70B の障害注入下スループット推移** ![[_attachments/arxiv-2511.14116/fig08a-llama70b-fault-throughput.png]] (Figure 8(a). GCP 可用性トレースに基づく14時間超の障害注入シミュレーション。GPU 障害が集中する時間帯(2〜3時間・9時間以降)で Standard(青)は大きくスループットが落ち込み低迷が持続するのに対し、FailSafe(緑)は Fault-scaled(赤実線)に近い水準を維持する。平均スループットは Standard 3.48 req/s に対し FailSafe 4.48 req/s(Fault-scaled 4.73・Faultless 5.20)。Source: Figure 8(a), arxiv-2511.14116。) ### オンラインスループット・レイテンシ(Figure 9) - Prefill 段階: LLaMA-3.1-70B で Standard-TP4 比最大2倍、Nonuniform-TP7 比1.28倍(10秒 TTFT 制約下)。Mixtral-8x22B では Nonuniform-TP7 比1.14倍。 - Decode 段階: LLaMA-3.1-70B で Standard-TP4 比最大2倍・Nonuniform-TP7 比1.60倍(40ms TBT 制約下)。Mixtral-8x22B では Nonuniform-TP7 比1.85倍。低リクエストレート時には障害なし Standard-TP8 に近い性能を達成。 **Figure 9: スループット-レイテンシ曲線(Prefill/Decode × LLaMA-70B/Mixtral-8x22B)** ![[_attachments/arxiv-2511.14116/fig09-throughput-latency.png]] (Figure 9. 4象限とも FailSafe-TP7(緑丸)が Standard-TP4(黄四角)・Nonuniform-TP7(青×)を上回り、Standard-TP8(赤星、障害なし上限)に肉薄する曲線を描く。特に Decode(右列)では低スループット域で FailSafe が Nonuniform-TP7 より大幅に低い TBT を維持しており、負荷不均衡がメモリバウンドな decode 段階でより深刻に効くことを裏づける。Source: Figure 9, arxiv-2511.14116。) ### Hybrid Attention の効果(Figure 10) TP4/TP8(均一構成)では FailSafe と Nonuniform-TP は同一性能に退化するが、TP5〜TP7(不規則構成)では乖離が拡大する。Prefill 段階では Nonuniform-TP 比 TP5: 0%、TP6: 16%、TP7: 25%の向上。TP5 での改善が限定的なのは、この規模での計算不均衡が構造的に緩和しにくいため。Decode 段階(メモリバウンド)ではより顕著で、TP5: 16%、TP6: 51%、TP7: 78%の向上。 ### メモリ・計算バランシングの寄与分解(Figure 11) Standard-TP4 を基準(1.00×)として、+Nonuniform-TP → +Memory-balancing(Cyclic配置) → +Compute-balancing(Hybrid Attention)の順に積み上げると、Prefill 段階は 1.00× → 1.33×(Compute-balancing の寄与が大、メモリ配置の効果は僅少——prefill は主に計算バウンドなため)、Decode 段階は 1.00× → 1.29×(Memory-balancing) → 1.63×(さらに Compute-balancing、decode はメモリバウンドなため)へ到達。最終的に Prefill 1.58倍、Decode 2.06倍の正規化スループットを達成。 **Figure 11: メモリ・計算バランシングの寄与分解** ![[_attachments/arxiv-2511.14116/fig11-balancing-breakdown.png]] (Figure 11. TP4 baseline(黄)を基準に +Non-uniform TP(青)→ +Memory balancing(緑)→ +Compute balancing(赤)の順に積み上げ。Prefill は Compute balancing の寄与(1.00×→1.33×)が支配的、Decode は Memory balancing(1.00×→1.29×)と Compute balancing(1.29×→1.63×)がほぼ同程度の寄与を持つ。Source: Figure 11, arxiv-2511.14116。) ### 復旧レイテンシ(Table 3, Figure 12) LLaMA-3.1-70B の TP8 decode インスタンスにて、500リクエストのウィンドウ中の250番目のリクエスト直後(100ms 後)に GPU 障害を注入した実験: | System | Recompute | Host | Full | Oracle | |---|---|---|---|---| | Latency | 22 s | 530 ms | 120 ms | 15 ms | | Speedup | 1.00× | 41.5× | 183× | N/A(理論下限) | ホスト側 KVCache バックアップからの復元は再計算比41.5倍高速、オンデマンド重み復旧を追加した FailSafe-Full はさらに4.4倍(合計183倍)高速化する。この改善は体感レイテンシに直結し、Max TBT の P90/P99 は再計算なしで10秒超から1秒未満へ、オンデマンド重み復旧の追加で P99 TBT が572ms→229ms(2.5倍改善、Oracle の下限15msに接近)まで低下する。 **Figure 12: 復旧方式別 Max TBT の CDF** ![[_attachments/arxiv-2511.14116/fig12-recovery-latency-cdf.png]] (Figure 12. Recompute(黄)は Full P90/P99 の187ms/229ms を大きく超えて Host P90 の259ms・Host P99 の572msまで裾を引くのに対し、Full(緑破線)は Oracle Recovery(赤実線)にほぼ重なる急峻な立ち上がりを示す。Source: Figure 12, arxiv-2511.14116。) ## 考察 - テンソル並列は GPU をまたぐスケーリングの主流手法であり続けるが、唯一の選択肢ではない。大規模 MoE モデルではエキスパート並列(expert parallelism)が TP に匹敵する性能を発揮しつつ部分 GPU 損失への耐性が高いという知見が近年示されており、モデルアーキテクチャによっては別の並列化戦略の方が本質的に耐障害的である可能性を著者らは指摘する。 - FailSafe の設計は、動的 GPU リソース割り当てによる同時ジョブ間の細粒度リソース共有(rigid gang scheduling による starvation の緩和)にも展開できる可能性がある。 - 評価はシングルノード構成(NVLink 内、8 GPU)に限定されており、NUMA 境界を越えたメモリ・計算バランシングへの拡張は今後の課題として明記されている。NVL72 のような大規模マルチ GPU プラットフォームへの適用も今後の展望として述べられている。 ## 強み / 弱点・課題 **強み** - 障害後の「スループット低下」と「復旧レイテンシスパイク」という2種類の異なるオーバーヘッドを、それぞれ独立した機構(Memory/Computation Balancer と Lightning Recovery)で明確に分離して対処している。 - FFN 重みシャーディングの可換性という数学的性質を利用したオンデマンド重み復旧は、既存の耐障害訓練システムのチェックポイント/再起動アプローチとは異なる、サービング特有の低レイテンシ復旧手法である。 - 実装は約7,000行の軽量サービングエンジンで完結し、vLLM・SGLang 相当の性能を維持しながら耐障害機構を統合できることを示している(§4)。 **弱点・課題** - 評価はシングルノード(8 GPU、NVLink 接続)に限定されており、複数ノードにまたがる TP 構成やノード障害(GPU 単体でなくノード全体の喪失)への適用性は検証されていない。 - 再構成(TP world size の切り替え)レイテンシを全システム共通で10秒に固定しており、この値がシステム間の相対比較に与える感度分析は示されていない。 - 論文自身が "Under Review" と明記しており、査読前のプレプリント段階である。 ## 出典 - arXiv:2511.14116v1 [cs.DC](全文: Abstract, §1 Introduction, §2 Resilient Model Serving, §3 Design and Implementation, §4 Evaluation, §5 Related Work, §6 Discussion, §7 Conclusion)