# Sparing Strategies to Minimize Reliability Impact on Large Training Jobs > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 4 (May 21 / Thu)、Industry Track Oral "LLM Training 4"（14:45 PDT 開始） > - **登壇者:** Ehsan K. Ardestani（Meta Platforms, Inc.、スライド表紙・最終ページで太字強調、連絡先として明記） > - **全著者:** Kevin J. Quirk¹, Matthew Lennie¹, Ehsan K. Ardestani¹, Satyajeet Singh Ahuja¹, Matthew R. Bergeron¹, Andrew Grier¹, Zhaodong Wang¹, Mustafa Ozdal¹, Xu Zhang¹, Abhinav Triguna¹, Ying Zhang¹, Mathew Oldham¹, Chunqiang Tang¹ > - **所属:** ¹Meta Platforms, Inc.（連絡先: [email protected]） > - **関連リンク:** 論文中に Arcadia シミュレータへの参照あり（https://engineering.fb.com/2023/09/07/data-infrastructure/arcadia-end-to-end-ai-system-performance-simulator/） > [!abstract] 概要（論文 PDF アブストラクト・忠実日本語訳） > Meta の AI クラスタ上で大規模言語モデル（LLM）を訓練するには、ハードウェア障害に対して脆弱な長時間の分散ジョブを実行する必要がある。高い可用性と効率を維持するため、本番システムでは障害コンポーネントを置換できる予備計算リソースを事前に確保する「スペアリング」を用いる。しかし、最適なスペアリング戦略の選択 -- コンピュートブロックサイズ、予備ブロック数、予備 GPU トレイ数を含む -- は複雑であり、クラスタ性能に直接影響する。本論文では、閉形式の解析式を用いてスペアリング戦略の意思決定を導く解析フレームワークを提示する。また解析モデルを相互検証するシミュレーションコンポーネントも開発した。Meta のハイパースケールインフラに適用した結果、本モデルはエンジニアが耐障害性を最適化し、ダウンタイムを最小化し、LLM 訓練のグッドプットを最大化することを支援する。実世界のユースケースにより、本フレームワークが Meta の AI 運用にとって不可欠な堅牢かつ費用効果の高い設計選択を導く方法を示す。 ## 問題設定 LLM 訓練クラスタの規模は急速に拡大している。Llama 3 は 16K 基の H100 GPU を用い 15 兆トークンで事前訓練され、Llama 4 Behemoth は 32K 基の H100 GPU で 30 兆トークンに達した（論文 Section 1）。Llama 3 の事前訓練では、GPU・ホストコンポーネントの障害や予期しない保守イベントなどハードウェア障害がジョブ中断の **70% 超** を占めた（Grattafiori et al., 2024）。 LLM 訓練ジョブは主に同期実行であり、**単一障害がジョブ全体を停止させる**。クラスタ規模が拡大すると障害シナリオの頻度と複雑性も増大するため、GPU 可用性を最大化するスペアリング戦略が不可欠である。 スペアリング戦略の設計には以下の変数が絡み合う。 - **コンピュートブロックサイズ** K（ブロック内の GPU トレイ数） - **ブロック間スペア数** R（スペアリングゾーン内の予備コンピュートブロック数） - **ブロック内スペア数** I（コンピュートブロック内の予備 GPU トレイ数） - **障害率と修理時間**（トレイレベル MTBF、ラックレベル MTBF、MTTR） - **障害復旧方式**（同期チェックポイント、半同期チェックポイントなど） - **ジョブ配置制約**（テンソル並列、データ並列、エキスパート並列のコロケーション要件） これらの変数の最適な組合せを求めるため、閉形式の解析モデルが必要とされた。 ## 提案手法（解析フレームワーク） ### グッドプットの定義 クラスタの生産的出力を表すグッドプットを、クラスタサイズ、クラスタ有効訓練時間（CETT）、ハードウェア TPS スケール、LLM TPS スケールの積として定式化する（論文 Eq. 1）。 $\text{Goodput} = \text{Cluster Size} \times \text{CETT} \times \text{TPS Scale(Hardware)} \times \text{TPS Scale(LLM)}$ CETT は、GPU 時間のうち実際に生産的作業に費やされた割合であり、以下の損失を差し引いて算出される（論文 Eq. 2）。 - 予備 GPU のアイドル時間 - 全スペア枯渇時のジョブブロッキング時間 - チェックポイント保存のオーバーヘッド - 障害後の巻き戻しによる無駄な作業 ### 三層のマルコフ連鎖モデル フレームワークは確率論と連続時間マルコフ連鎖を用い、従来の線形レートモデルを超えた確率的障害・修理イベントをモデル化する。 **1. スペアトレイモデル（ブロック内スペア）:** コンピュートブロック内に K 基の GPU トレイがあり、そのうち I 基を予備として保持する。障害・修理サイクルを連続時間マルコフ連鎖でモデル化し、コンピュートブロックの MTBF を閉形式で導出する（論文 Eq. 3）。トレイレベル MTBF（$\text{MTBF}_T$）とラックレベル MTBF（$\text{MTBF}_R$）を階層的に区別することで、障害の空間的・機能的相関を捕捉する。 **2. スペアブロックモデル（ブロック間スペア）:** スペアリングゾーン内の L 個のコンピュートブロックのうち R 個を予備として確保する。全スペアが枯渇しジョブがブロックされる確率を、同様の連続時間マルコフ連鎖から閉形式で算出する（論文 Eq. 4）。 **3. チェックポイント障害復旧モデル:** ジョブの障害復旧効率を離散時間マルコフ連鎖でモデル化する。チェックポイント周期 $T_c$、保存時間 $T_s$、障害検知時間 $T_d$、再起動時間 $T_r$ をパラメータとし、無駄時間の割合 $\gamma$ を閉形式で表現する（論文 Eq. 5）。 ### ジョブ配置制約とストランディング 並列化戦略（テンソル並列、データ並列、エキスパート並列など）はコロケーション制約を課す。例えばテンソル並列はスケールアップネットワーク内の単一コンピュートブロックに収める必要がある。各スペアリングゾーン内の稼働ブロック数 $L - R$ はグループサイズ P の整数倍でなければならない（論文 Eq. 6: $L - R = k \cdot P,\; k \in \mathbb{Z}^+$）。 この制約により、スペアリングに必要な数を超える非稼働ブロックが「ストランドリソース」として生じ、実質的な容量無駄となる。 ### ハードウェア TPS スケール ブロック内スペアが存在する場合、アイドルスペアトレイの電力をラック内の稼働 GPU に再分配でき、GPU あたりの電力上限を引き上げることでパフォーマンスゲインを得る（論文 Eq. 8）。稼働 GPU 数が 64（スペア 8 基）の場合、GPU あたり電力上限が 9% 上昇し、TPS Scale(Hardware) は 1.034 倍となる。 ### LLM TPS スケール より大きなコンピュートブロックサイズはテンソル並列度を高め、スケールアップネットワーク利用によるモデルパフォーマンスゲインをもたらす（論文 Eq. 9, 10）。ブロックサイズ 72 GPU では TPS Scale(LLM) が 1.18 倍に達するのに対し、18 GPU では 1.02 倍にとどまる（Table 1）。 ### CETT 統合モデル 上記の全サブモデルを統合し、スペアリング戦略ごとの CETT を閉形式で記述する（論文 Eq. 7）。 ## 実験・評価 ### 本番構成パラメータ Meta の本番インフラに基づく評価構成（論文 Section 4.1、スライド）。 | パラメータ | 値 | |---|---| | スペアリングゾーン数 (B) | 4 | | ゾーンあたりコンピュートブロック数 (L) | 256 ラック | | ラックあたり GPU 数 | 72（2 GPU/トレイ、36 トレイ） | | トレイ MTBF | 20,000 時間 | | ラックレベル MTBF | 10,000 時間 | | MTTR | 24 時間 | | チェックポイント周期 | 250 秒 | | チェックポイント保存時間 | 50 ミリ秒 | | 障害検知時間 | 60 秒 | | ジョブ再起動時間 | 6 分 | | ジョブ配置グループサイズ | 2,304 GPU | ハードウェアは Meta の Catalina ラック（GB200 cat）を想定。 ### スペアリング戦略の比較（Table 1） クラスタサイズ 73,728 GPU、ジョブサイズ 64,512 GPU での評価結果。 | 構成 | 稼働 GPU | ブロック内スペア | ブロック間スペア | CETT | TPS(HW) | TPS(LLM) | グッドプット (GPU) | |---|---|---|---|---|---|---|---| | 72 GPU, スペアなし | 72 | 0% | 8.6% | 68.8% | 1.000 | 1.18x | 59,821 | | **72 GPU, スペア 8** | **64** | **11.1%** | **1.4%** | **68.5%** | **1.034** | **1.17x** | **61,134** | | 36 GPU, スペアなし | 36 | 0% | 4.7% | 68.0% | 1.000 | 1.12x | 56,110 | | 36 GPU, スペア 4 | 32 | 11.1% | 1.0% | 67.8% | 1.034 | 1.11x | 57,330 | | 18 GPU, スペアなし | 18 | 0% | 2.6% | 66.4% | 1.000 | 1.02x | 49,912 | | 18 GPU, スペア 2 | 16 | 11.1% | 0.9% | 66.0% | 1.034 | 1.00x | 50,307 | **最適構成:** 72 GPU ブロック + ブロック内スペア 8 基（64 稼働 GPU）がグッドプット 61,134 GPU で最大。次点（72 GPU ブロック、スペアなし）に対し **1.024 倍** のグッドプット向上を達成する。 ### MTBF-MTTR 空間での最適戦略の変化 CETT のみの比較（Figure 2）では、小ブロック（36 GPU, スペアなし）が MTBF-MTTR 空間の大部分を支配する。修理時間が極めて短い場合は 72 GPU ブロック、MTBF が極めて低い場合は 72 GPU + ブロック内スペア 8 基が最適となる。 LLM モデルゲインを考慮する（Figure 3）と、大ブロック（72 GPU）が支配領域を劇的に拡大し、小ブロック（36, 18 GPU）は完全に消失する。高信頼性・短修理時間では 72 GPU（スペアなし）、低信頼性・長修理時間では 72 GPU + ブロック内スペア 8 基が優位となる。 配置制約を追加する（Figure 5）と、ストランディングの影響により 72 GPU + ブロック内スペア 8 基が運用空間全体を支配する結果となる。 ### シミュレーション検証 エンドツーエンド AI システムパフォーマンスシミュレータ Arcadia を用いたモンテカルロシミュレーションにより解析モデルを検証した。同一前提条件下で、シミュレータと解析モデルの CETT の相対誤差は **1% 未満** であった（Figure 6）。複合修理プロセスの簡略化仮定（自動復旧障害とチケット修理障害を単一の指数分布で近似）についても、自動復旧比率 $\epsilon$ の値に対してロバストであることが確認された。 ## 結論・Takeaway - **グッドプットの最適化は多面的な課題**である。デバイスの障害率・修理時間だけでなく、障害復旧方式、並列化戦略に応じた LLM パフォーマンス、ジョブ配置制約、電力再分配（TDP 調整）の可否を統合的に考慮する必要がある。 - **ブロック内スペアリング**はアイドルトレイの電力を稼働 GPU に再分配する副次効果をもたらし、そのパフォーマンスゲインがオーバーヘッドコストを上回りうる。 - **配置制約はスペアリング削減の利得を相殺する**。ブロックサイズの半減はブロック間スペアを概ね半減させるが、ストランディングが同量増加するため純利得はゼロに近い。 - **マルコフ連鎖に基づく閉形式モデル**は、一次近似の設計判断において実用的かつ正確であり、シミュレーションとの乖離は 1% 未満である。 - **普遍的に最適な単一のスペアリング戦略は存在しない**。最適解はシステム全体のコンテキスト（MTBF、MTTR、モデルアーキテクチャ、ネットワークトポロジ、電力制約）に依存する。本フレームワークは Meta のハイパースケール AI インフラ設計の基盤として運用されている。