# 耐障害LLM訓練 ## 定義 耐障害 LLM 訓練は、数千〜数万 GPU の長期訓練ジョブを、頻発する障害(CUDA エラー・NaN・ジョブハング・ECC・fail-slow 等)の中でも中断を最小化して走らせ続けるための、検知→隔離→復旧のライフサイクルとそれを支える仕組みの総体。[[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] は **ETTR(Effective Training Time Ratio = 生産的実行時間 / 壁時計時間)** を定義し、障害率・チェックポイント間隔・再起動オーバーヘッドから期待 ETTR を見積もる解析式を与える。[[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] は同じ ETTR を到達目標に置き、9,600 GPU・3 か月の密モデル訓練で最大 97% を達成する(§8.1.3)。[[LLM分散学習]] の SER 3 軸のうち Reliability 軸を、訓練ジョブ単位の運用問題として具体化した下位領域に当たる。中心の難所は、エラーメッセージで起因が分かる**明示的障害**ではなく、ハング・SDC・fail-slow といった明確な信号のない**暗黙的障害**(ByteRobust では全インシデントの 9.9% がハング、§1・表1)。 ## 横断的知見 - **ETTR/有効訓練時間率という共通の物差しが、研究クラスタ分析から本番 LLM 訓練システムへつながる**: [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] は ETTR を `R/W` と定義し、チェックポイント間隔・再起動オーバーヘッド・キュー待ち・障害率で期待値を推定する。これに対し [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] は ETTR 97%(9,600 GPU・3 か月)を、[[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] は「検知+診断が平均 10 分未満・追いつき 15 分以内で有効訓練時間率 90% 超」(§6.2/§6.3)を本番実測として報告する。Reliability は「落ちたか」でなく「どれだけ生産的に走ったか」の連続量で測られる。(Source: [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **10 万 GPU 級では、チェックポイントと再起動の目標が分単位になる**: Kokolis 2025 は、RSC-1 全体を 16,000 GPU の単一訓練に使う仮想シナリオで、60 分チェックポイントなら ETTR 0.7、5 分チェックポイントなら 0.93 と推定する。さらに 10 万 GPU 級では、RSC-2 並みの障害率でも ETTR 0.9 のために約 2 分チェックポイントと約 2 分再起動が必要になる。これは ByteRobust の warm standby/hot-update、FlashRecovery のスケール非依存再起動、MegaScale の 2 段階チェックポイントが狙う「非生産時間を分単位以下へ押し込む」方向を、要件側から裏づける。(Source: [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **「正確な箇所特定」と「迅速な隔離」はトレードオフで、耐障害設計はしばしば後者を選ぶ**: ByteRobust は設計哲学を「正確な箇所特定より迅速な隔離」と明言し、起因が解けないときはランタイムスタックトレースのデータ駆動クラスタリングで並列グループ単位に**過剰排除**して訓練継続を優先する(8 台中 6〜7 台を巻き込む偽陽性を許容、§9)。これは [[Minder]]/[[Pulse]] が machine-level の精密な箇所特定を追う方向([[Fault Localization]])と対照的で、耐障害性の文脈では「どこが悪いか」を厳密に当てるより「疑わしい範囲を素早く切って復旧する」方が ETTR に効く、という設計判断がある。(Source: [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) - **復旧機構は「チェックポイント高速化」と「予備機の常備」の二系統で高速化される**: ByteRobust は warm standby(予備機の事前準備)で最大 10.87×、集約ホット更新(障害機の迅速交換)で 11.04× 復旧を高速化し、毎ステップのチェックポイントをブロッキング削減 99.69%・MFU 損失 0.71% で実現する(§8.2)。MegaScale は 2 段階チェックポイント(ホストメモリへ数秒書き込み + 非同期 HDFS 転送)で reactive な復旧を高速化する(§4)。両者とも「チェックポイントのオーバーヘッドを下げる」と「障害機を待たずに差し替える」を組み合わせ、復旧の律速を分解して攻める。(Source: [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **ハードウェアのレジリエンスが床を決め、耐障害ソフトウェアがその上を埋める**: [[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]] は、MMU/NVLink 以外の GPU エラーがほぼ 100% ジョブ失敗につながり、99.9% のジョブ可用性には 5% のオーバープロビジョニング(1,000 ノードで月 100 万ドル超)が要ると示す——アプリ層の頑健な復旧機構が不足する限り GPU エラーは直接ジョブ失敗になる。ByteRobust はまさにこの「アプリ層の robust recovery」を実装し、インフラ障害が件数 11% でも GPU 時間の 82% を食う([[GPUクラスタ運用]])現実に対して自動隔離・復旧で応える。ハードウェア特性(GPU レジリエンス)が要求する冗長度を、耐障害ソフトウェアが ETTR として回収する構図。(Source: [[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **暗黙的障害の検知が「集合通信の可観測化」へ降りていく**: ByteRobust が最難所とする暗黙的障害(ハング・SDC・fail-slow)は、しばしば[[集合通信]]が見かけ上ハングする形で現れる。[[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] は同じ [[ByteDance]] の本番で、ブラックボックスな CCL の内部状態(フロー単位・チャンク単位)をトレースして[[papers/2017__HotOS__Gray Failure - The Achilles Heel of Cloud Scale Systems|Gray Failure]](silent timeout でハング)とフェイルスローを 15 秒以内に検知する。ByteRobust が訓練ジョブ全体の検知→隔離→復旧を統括するのに対し、Mycroft は通信層の「見えない障害」を可視化する専門レイヤーで、過剰排除([[Fault Localization]] を犠牲に迅速隔離)に必要な「どのランクが原因か」の情報を供給しうる。耐障害性は層ごとの可観測化の積み重ねで床上げされる。(Source: [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **復旧コストの第三の攻め方——「再実行で結果が変わらないなら保存しない」**: 復旧は warm standby と高速チェックポイント([[チェックポイント]])で攻められてきたが、[[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]](PICKER)は[[べき等性]]を持つ GPU カーネルインスタンスのチェックポイントを省くことで、耐障害システムのチェックポイントコストを 4% 未満に下げる。「速く保存する/予備機で待たない」に加えて「そもそも保存対象を減らす」という軸を開く。ただし PICKER の評価は DNN 推論中心で、LLM 訓練の高頻度チェックポイントへの直接適用は未検証。(Source: [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **復旧の高速化は「速く保存/予備機で待たない/そもそも保存しない」の三系統に分岐する**: ByteRobust と MegaScale は高頻度チェックポイントの高速化と warm standby を併用し([[チェックポイント]]の I/O 削減 + 予備機の事前準備)、[[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]](PICKER)はべき等カーネルのチェックポイントそのものを省く。これらに対し [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]] は第三の系統を採り、データ並列の複製(データ並列度 N のとき各デバイスに N−1 個の複製)を冗長として使う**チェックポイントフリー 1 ステップ復旧**で、復旧時の損失を最大 1 ステップに限定し定期チェックポイントの I/O を原理的に消す(k0 = 0)。FlashRecovery 自身、同一データ並列グループの全デバイス同時故障(確率 $0.001^N$)が起きたときのみチェックポイントが必要と認めており、複製冗長は同時故障耐性とのトレードオフで成り立つ。復旧の律速を「保存頻度・予備機の待機・保存対象の有無」のどこで切るかが系統を分ける。(Source: [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]]) - **検知の入口データがドメインで分かれる——HPC は物理位置とログ、LLM 訓練は集合通信の症状**: [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]](Aurora 63,744 GPU)は RAS ログ・メンテナンスログを駆動シグナルとし、集中型メタデータベースで「同じ場所で繰り返されるエラー」=物理位置の反復相関を統計判断の土台に置く。これに対し [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] は学習ステップ時間を一次シグナルに据え、[[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]](C4D)は BSP 同期点で構築する通信遅延行列の行・列の偏りから slow connection を特定する。同じ GPU 故障でも、HPC 運用は物理メンテナンス系のログから、LLM 訓練は[[集合通信]]の同期点の症状(ステップ時間・通信遅延・透過リルートによる帯域半減)から検知を起こす。(Source: [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]], [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]], [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]]) - **「ソフトウェアと運用が障害の主因」という構造は 40 年間変わらない**: [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]] は 1985 年の Tandem [[NonStop]] 2,000 台超の障害統計で、管理 42%・ソフトウェア 25%・ハードウェア 18% と報告した。40 年後の LLM 訓練クラスタでも、[[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] はインフラ障害が件数 11% でも GPU 時間の 82% を食い、ソフトウェアバグ・構成ミス・暗黙的障害(ハング・SDC)が実質的な停止時間の主因であると示す。ハードウェア耐障害設計は成功しているが、ソフトウェアと運用の障害が支配するという Gray の洞察は規模と技術世代を超えて不変である。(Source: [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **Gray の永続プロセスペア + トランザクションは、チェックポイント + 再起動の原型**: Gray 1985 は永続[[プロセスペア]](主プロセス障害時にバックアップが健忘状態で起動)とトランザクション機構(未完了トランザクションの UNDO で整合状態に復帰)の組合せを提案した。現代の LLM 訓練における[[チェックポイント]] + 再起動(最新チェックポイントへロールバックしジョブを再開)は、この設計パターンの直系であり、「状態を保存点に巻き戻して再実行する」という原理を共有する。Gray がロックステップ方式を「[[Heisenbug]] を許容しない」と棄却したのと同様に、決定的再実行に基づく耐障害手法は非決定的な大規模並列訓練では採用されない。(Source: [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **「過剰排除/過剰ドレインの抑制」が箇所特定の精度と迅速隔離の同一トレードオフを別ドメインで具体化する**: [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]] の multi-strike ポリシーは、障害の頻度(ストライク制)で判定して過剰なノードドレインを防ぎつつ真の故障を特定する。一方 ByteRobust は起因が解けないとき並列グループ単位で過剰排除し(8 台中 6〜7 台の巻き込みを許容)、迅速隔離を優先する。両者はいずれも「どこが悪いかを厳密に当てる([[Fault Localization]])か、疑わしい範囲を素早く切るか」という同一トレードオフを、HPC 運用(頻度ベースで過剰ドレイン抑制)と LLM 訓練(過剰排除を許容)という別ドメインで反対方向に具体化している。(Source: [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **fail-slow(暗黙的障害)の検知が一級市民化し、連続量で測られる**: [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] のグレーノード(標準ヘルスチェックを通過しつつ性能を暗黙に劣化させるノード、2% の速度低下でスループット 20〜30% 損失)、[[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]] の slow connection、ByteRobust の fail-slow/SDC は、いずれも「クラッシュしないが遅い」を検知対象の中心に据える([[ストラグラー]])。落ちたか否かの二値ではなく、MFU・ステップ時間分散・ETTR/MTTF といった連続量で測る点も共通する(Guard はステップ時間分散 20%→1%・MFU 最大 1.7 倍、C4D はエラー誘発ダウンタイム 31.19%→1.16%)。(Source: [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]], [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) ## 未解決の問い - 過剰排除(ByteRobust)の偽陽性(8 台中 6〜7 台)を抑えつつ早期隔離する均衡点はどこか。精密な箇所特定([[Minder]]/[[Pulse]])を隔離判断の事前情報として組み合わせると、巻き込み台数を減らしつつ ETTR を保てるか。 - SDC・gray failure(NVIDIA EUD の recall は 70%、ByteRobust §9)は決定的に再現しにくい。検知漏れの残り 30% をオンライン監視([[LLM学習モニタリング]])や先回り型検証(SuperBench 型)でどこまで詰められるか。 - チェックポイント不要の復旧(ライブマイグレーション・モジュール冗長・弾力的訓練)は、チェックポイントに基づく復旧をどこまで置換できるか。本番採用例はまだ乏しい(→ [[LLM分散学習]] の未解決の問い)。べき等性に基づくチェックポイント省略([[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]])は、LLM 訓練の巨大カーネル群でも µs スケールで判定でき、ETTR を底上げするか。 - 集合通信層の専門診断([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])が出す「原因ランク」は、ジョブ統括の隔離判断(ByteRobust の過剰排除)へどう引き渡せば巻き込み台数を減らせるか。フォールトトレラント AllReduce(NCCLX の FTAR, [[@2025__arXiv__Collective Communication for 100k+ GPUs]])のような通信スタック側の耐障害機構と、ジョブ層の復旧はどう分業するか。 - ETTR を最大化する設計が、ハードウェアのオーバープロビジョニング(GPU レジリエンス由来の 5%)とどう分業すべきか。冗長機の常備コストと耐障害ソフトの開発・運用コストの最適点は規模でどう動くか。 - ETTR 推定式はキュー待ちや障害率を集約値として扱うが、研究クラスタでは大規模ジョブの再キューが小規模ジョブをプリエンプトし、二次的な goodput 損失を生む。ジョブ単体の ETTR とクラスタ全体の goodput を同時最大化するスケジューリング目標はどう定式化すべきか。 - チェックポイントフリー復旧(FlashRecovery のデータ並列複製、[[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]])は、warm standby やべき等チェックポイント省略(PICKER)とメモリコスト・同時故障耐性でどう使い分けるべきか。複製冗長は同一データ並列グループの全デバイス同時故障($0.001^N$)時にチェックポイントへ退避せざるを得ず、データ並列度・故障率・複製のメモリコストが切り替え点を決める。 - グレーノードの段階的緩和(Guard の 10%/20% しきい・チェックポイント到達まで待機する中程度緩和、[[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]])と、ジョブ単位の過剰排除(ByteRobust)は、どちらが ETTR/MTTF を高く保つか。Guard の偽陽性率 12.4% は「緩和が軽量・可逆」という前提に依存しており、過剰排除のように不可逆な隔離を行う設計とは均衡点が異なるはずである。 - HPC の物理位置相関([[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]] が集中型メタデータベースで捉える「同じ場所で繰り返されるエラー」)を、集合通信の症状駆動で検知する LLM 訓練(Guard/C4D)へ移植できるか。RAS ログ・物理メンテナンス系のシグナルと、ステップ時間・通信遅延行列という症状シグナルを統合すると検知の精度・先回り性は上がるか。 ## 関連 - ソース: [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] / [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] / [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] / [[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]] / [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] / [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]] / [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] / [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]] / [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]] - 概念: [[LLM分散学習]](Reliability 軸) / [[LLM学習モニタリング]](検知・局所化) / [[GPUレジリエンス]](ハードウェアの床) / [[GPUクラスタ運用]] / [[Fault Localization]] / [[障害緩和]] / [[ストラグラー]] / [[集合通信]] / [[チェックポイント]] / [[べき等性]] / [[根本原因分析]] - エンティティ: [[ByteRobust]] / [[MegaScale]] / [[ByteDance]] / [[Minder]] / [[NCCL]] / [[NCCLX]] / [[PICKER]] / [[Jim Gray]] / [[Tandem Computers]] / [[NonStop]] - 関連 MOC: [[分散深層学習 - MOC]] / [[HPC - MOC]] ## 出典 - [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]](§1 Introduction, §2.2 障害分布, §4 復旧経路, §8.1/§8.2 評価, §9 限界) - [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]](ETTR 定義・期待値推定式・MTTF スケーリング・10 万 GPU 級の checkpoint/restart 要件) - [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]](§4 Fault Tolerance, §6 Experience) - [[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]](§5 ジョブ影響・オーバープロビジョニング) - [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]](§3 監視・障害診断) - [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]](集合通信層の暗黙的障害の可観測化・依存駆動 RCA) - [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]](べき等性によるチェックポイント省略・コスト 4% 未満) - [[@2025__arXiv__Collective Communication for 100k+ GPUs]](フォールトトレラント AllReduce=FTAR) - [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]](Aurora 63,744 GPU・集中型メタデータベース・multi-strike 修復ポリシー・MTTR 手動比 最大84倍短縮) - [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]](グレーノード=fail-slow・オンライン監視+オフラインノードスイープの閉ループ・MFU 1.7倍・ステップ時間分散 20%→1%・MTTF 2.5倍) - [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]](チェックポイントフリー 1 ステップ復旧=データ並列複製の冗長利用・スケール非依存タスク再起動・4,800 デバイス 150秒) - [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]](C4D=BSP 同期点での異常検知・エラー誘発ダウンタイム 31.19%→1.16%・システム効率 30%→45%) - [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]](管理42%・ソフトウェア25%・ハードウェア18%の障害統計、永続プロセスペア+トランザクション、Bohrbug/Heisenbug二分法)