# 耐障害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]]) - **LLM を訓練ログ診断の主役に据える設計が 2024 年の Acme で本番投入される**: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]] は、Log Agent(LLM)がリアルタイムログから Filter Rules(正規表現)を動的に書き起こし、ルール不一致のエラーログを埋め込みでベクトル化して Vector Store に蓄え、Failure Agent(GPT-4)が Query Engine で原因種別(user/infra)と緩和示唆を生成、診断結果を逆に正規表現として Rule-based Diagnosis へ追加する閉ループを提案する。同論文は手動介入を約 90% 削減すると報告するが、評価は粗く偽陽性/陰性の定量がない。後続の L4・LLMPrism・ByteRobust の LLM 援用ログ分析の最も初期の本番事例。(Source: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]]) - **2 段階 NCCL allgather テストは「迅速隔離より精密箇所特定」を、通信集合の対称性で達成する具体例**: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]] は NVLinkError 時に、全ノードを 2 ノード一組のワールドへ分割し allgather を走らせ、失敗ペアを正常ノードと再ペアして犯人を最大 2 ホップで特定する。これは ByteRobust の「並列グループ単位の過剰排除」(8 台中 6〜7 台巻き込み)とは反対の方向、Minder/Pulse の「メトリクスのパターン検出による単独機特定」とも違う第三の系統で、集合通信プリミティブ自体を診断器に転用する。検査のコストは O(N) で、迅速隔離を選ぶか精密特定を選ぶかの均衡点を低い検査コストで動かしうる。(Source: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) - **非同期チェックポイントの効果が「ホストメモリの余剰」という観測と直結する**: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]] は Acme で CPU メモリ利用率が <50%・GPU メモリは ≥75% に張り付くという二極化を計測し、その余剰 CPU メモリに非同期でモデル状態を保管して別スレッドが永続ストレージへフラッシュする。これにより 7B・123B モデルの checkpoint オーバーヘッドを 3.6〜58.7× 削減した(interval=30 分)。LLM クラスタの「資源利用の偏り」が、耐障害設計の余地として直接活用される例で、後続の ByteRobust の毎ステップチェックポイントや MegaScale の 2 段階チェックポイントの設計動機を裏づける。(Source: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **復旧の律速は「障害検知」だけでなく、セッション再確保・チェックポイントロード・予備ノード可用性へ分散する**: [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] や [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]] は障害検知・隔離・モデル状態復元を高速化する。一方 [[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]] は 504 B200 GPU の本番で、checkpoint load 中央値 31 分、60 ノードのギャングスケジューリング、3 予備ノードの不足、単一ノードセッションによる意図的隔離、GPU ライセンス更新漏れが復旧成否を支配しうることを示す。耐障害 LLM 訓練は「プロセスを再起動できるか」だけでなく、ジョブ単位のセッション抽象・ストレージ経路・資源プール運用を含む復旧パイプライン全体の問題である。(Source: [[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]]) - **ユーザ側の自動診断レイヤーが ETTR ロスを構成する「報告 - 解決ループ」の TTM 軸を圧縮する**: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] は Microsoft Azure の本番 AI ワークロードインシデント 1 年分(778 件)で median TTM 52.5 時間 / mean 83.0 時間という長期遅延を実証し、これがプロバイダ集中の手動トラブルシューティングと知識ギャップから生じると示す。Meta の Llama3.1 405B 訓練が 54 日間に 466 件の job interruption で 2.12M H100 時間($18M 相当)を浪費したという事実(本論文 §1, [16])は、訓練 ETTR の毀損が「インフラ層の物理障害」だけでなく「報告 - 診断 - 解決のオペレーション層」でも生じることを示す。ByteRobust が ETTR 97% を達成する自動隔離・復旧と並んで、TSGuard の user-centric pre-ticket interception は「障害発生から原因確定までの人間プロセス」の TTM を AI ワークロード向けに圧縮する第二の補完軸を提供する。(Source: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **FFTrainer が示す「MTBF 向上より MTTR 短縮」という方針転換**: [[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]](FFTrainer、Tsinghua University)は、3 時間 MTBF という短い故障間隔への対応策として「MTBF を上げる」のではなく「MTTR を秒単位(≤ 29 秒)に下げる」方向に設計目標を設定した。これは ByteRobust の warm standby + 迅速隔離と同じ思想だが、チェックポイントサイズの 90% 削減(Checkpoint Razor)・毎イテレーションのインスタントチェックポイント・LCCL によるロールとランクの分離(モデルロードと通信初期化の並列化)を組み合わせることで、既存比 97% の MTTR 削減(~1,000 秒 → 29 秒)を 128 GPU 規模で実証した。「MTTR を小さくすることで短い MTBF を許容する」という設計の逆転は、10 万 GPU 級で 2 分チェックポイントが必要という HPCA 2025 の ETTR 要件分析と整合する——MFU 損失を 0.27% 以下に維持しながら毎イテレーションのチェックポイントが可能になる。(Source: [[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]], [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **CCL 層が NIC 障害を完全透過的に吸収する——ジョブ再起動なしの耐障害層**: [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]](VCCL)のプライマリバックアップ QP 機構は、NIC ポート障害発生時に receiver 側がバックアップ QP への切り替えを主導し(受信側起動の QP 切り替え)、ブレークポイント再送を組み合わせてジョブ再起動・チェックポイントを一切必要とせず GPU 待機時間を約 90% 削減する。これは ByteRobust の「ジョブ単位の過剰排除→再起動で ETTR を守る」とも、FlashRecovery の「データ並列複製でチェックポイントフリー復旧」とも異なる第四の系統——CCL がハードウェア障害を自律吸収し、訓練フレームワークを障害から完全に隔離するパターンだ。耐障害設計における「ジョブ層」「CCL 層」「ネットワークファブリック層(適応ルーティング)」の役割分担に新たな層が加わる。(Source: [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **AI ワークロード障害の recurrence rate 8.78 という高頻度反復は、knowledge base ベース診断の有効性を裏付ける**: TSGuard は Microsoft Azure 1 年データで GPU 関連障害の recurrence rate(同種障害の繰り返し度)を 8.78、Networking 3.15、System Software 2.34 と計測した(Table 1)。これは「同じ故障パターンが何度も再発する」AI ワークロード環境では、過去事例の埋め込み類似検索による quick path(TSGuard Pipeline #1 が 51.4% 解決)が高い有効性を持つことを意味する。本 wiki が記録してきた ByteRobust の「迅速隔離 + 並列グループ過剰排除」、Aegis の「CCL カウンタ同期ずれ検知」、Minder の「machine-level 類似度」と並んで、TSGuard は「過去事例マッチング + 反復検証」を AI ワークロード診断の第三の主軸として確立する。Section 5.2 のアブレーション(quick 51.4% + slow +32.6 + deep +2.3)は、recurrence 高ドメインで類似検索が dominant component になることを実証する。(Source: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]], [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]]) - **「再起動・チェックポイントなしに障害をその場で吸収する」という第五の系統——パイプラインバブルを復旧資源に転用**: [[@2024__SOSP__ReCycle - Resilient Training of Large DNNs using Pipeline Adaptation]](ReCycle、Stanford、SOSP '24)は、スペアサーバも再起動もチェックポイントも要らない第五の耐障害系統を示す。ハイブリッド並列の機能的冗長性(同一ステージのデータ並列ピアが同一パラメータを保持)とパイプラインバブル(1F1B スケジュールのウォームアップ・クールダウンの空きスロット)を組み合わせ、障害ワーカーのマイクロバッチをピアへ再ルーティングしてバブルに詰め込む。分割逆伝播(B_weight を遅延)とストラグラーオプティマイザ(ステージ別オプティマイザステップのずらし)でオーバーヘッドを実質ゼロに近づける。Oobleck(パイプラインテンプレート切り替え)とも VCCL の CCL 層吸収とも異なり、「訓練スケジュールの未活用余白」を耐障害資源として活用する設計思想だ。GPT-3 6.7B で Oobleck 対比 1.46×、Bamboo 対比 1.64×。ただし ZeRO スタイルの DP(パラメータ分散)には機能的冗長性がなく適用不可。(Source: [[@2024__SOSP__ReCycle - Resilient Training of Large DNNs using Pipeline Adaptation]]) - **同じ著者チームが「訓練の冗長性活用」から「サービングの負荷分配均等化」へ焦点を移した——耐障害設計はドメインごとに異なる資源を武器にする**: ReCycle(Gandhi・Kozyrakis、Stanford、SOSP '24)はパイプライン並列訓練における機能的冗長性とパイプラインバブルという「訓練スケジュールの未活用余白」を復旧資源に転用した。同じ Gandhi・Kozyrakis が [[Zhiqiang Xie]]・[[Ziyi Xu]] と発表した [[@2025__arXiv__FailSafe - High-performance Resilient Serving]](→ [[耐障害LLMサービング]])は、対象をサービングへ移し、冗長な余白の活用ではなく「不規則な GPU 数でのテンソル並列内の負荷分配そのものを均等化する」方向へ設計思想を転換した。訓練はパイプラインステージ間の冗長性を武器にできるが、サービングのテンソル並列は全ヘッド・全シャードが常時稼働し冗長な余白がないため、Cyclic KVCache Placement・Hybrid Attention という「配置と分割の粒度を細かくする」アプローチが必要になる。両者は「同じ著者・同じ GPU 障害という前提・異なる資源を武器にする」好対照の事例対を成す。(Source: [[@2024__SOSP__ReCycle - Resilient Training of Large DNNs using Pipeline Adaptation]], [[@2025__arXiv__FailSafe - High-performance Resilient Serving]]) - **「クラスタ全体の複数タスク最適化」という視点が、単一タスクダウンタイム最小化の代替目標になる**: [[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]](Unicron、Alibaba)は、従来の耐障害設計が「個別タスクの中断を最小化」に焦点を当てていた問題を指摘する。Alibaba Cloud の障害分析で最もリソース集約的なタスク(上位 5%)の異常終了率 43.4%・NCCL タイムアウト 10.1% という実態に対し、WAF(Weighted Achieved aggregate FLOP/s)を目標関数に置いてクラスタ内 m タスク × n ワーカーの最適配分を動的計画法($O(mn^2)$、事前計算で $O(1)$)で解く。Oobleck・Bamboo・Varuna のような弾性訓練系が Megatron との訓練効率差(スループット 60〜80% 程度)をコストとして支払う一方、Unicron は Megatron の最適化をそのまま継承した上でワークロードマネージャ層に自己修復を置き、128 GPU クラスタで Megatron 比 1.9×(高頻度障害トレース)の累積 WAF 改善を達成した。(Source: [[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]]) - **ToR 単一障害点はネットワーク層の重大 ETTR 毀損要因であり、トポロジ設計で根本解決できる**: [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]] は、本番で NIC–ToR リンクの 0.057%/月、ToR の 0.051%/月が致命的に障害し、3K GPU 訓練では月 1〜2 回のクラッシュ（1 回あたり最大 3 万ドル損失、チェックポイント 2〜4 時間間隔）が発生すると報告した。HPN の非スタック型デュアル ToR は、ToR 障害を訓練停止ではなく 6.25% の性能劣化にとどめ、8 ヶ月本番運用で ToR 起因の単一障害点ゼロを達成した。ByteRobust・MegaScale が対処するジョブ層（ソフトウェア・GPU 障害）とは異なる「ネットワーク層での ETTR 保護」であり、ネットワーク起因クラッシュをジョブ層に到達させる前にトポロジで吸収するアプローチだ。(Source: [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]]) ## 未解決の問い - 過剰排除(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 ログ・物理メンテナンス系のシグナルと、ステップ時間・通信遅延行列という症状シグナルを統合すると検知の精度・先回り性は上がるか。 - 自動リトライはどこまで構造的障害を識別して止まるべきか。[[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]] では 12 チェーン中 8 チェーンが最終失敗し、同条件の 30 連続失敗で GPU 時間を消費する例がある。XID 分岐、指数バックオフ、予備ノードの優先プリエンプションをどう組み合わせれば、一過性障害への速い復旧と構造的障害への無駄な再試行停止を両立できるか。 - TSGuard の user-centric incident diagnosis(ユーザ側でチケット提出前に自動診断)は、ETTR を最大化するインフラ層自動復旧(ByteRobust・MegaScale)とどう統合すべきか。インフラ層の自動隔離が完了した後、user が原因の subset(misconfiguration・library mismatch)を自動診断するパス、また逆に user 側診断が infrastructure 起因と判定した場合に provider 側 ETTR 復旧パイプラインを起動するハイブリッドフローは設計可能か。([[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]]) - CCL 層での透過的 NIC 障害吸収(VCCL のプライマリバックアップ QP)と、ジョブ層での過剰排除・再起動(ByteRobust)の適切な分業点はどこか。両者が同一 NIC 障害を重複処理する場合、VCCL が先行吸収してジョブ層に障害を隠蔽することで ByteRobust の偽陽性率が増えるか。また適応ルーティングがネットワーク側で同じ障害を回避した場合、三層(CCL・ジョブ・ファブリック)がそれぞれ独立対処することで再送ループや帯域浪費が生じないか。([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - ReCycle のパイプラインバブル活用は ZeRO スタイルの DP と相容れないが、ZeRO を用いた大規模訓練(例: DeepSpeed ZeRO-3)での耐障害は別の機構が必要か。ZeRO では各ノードがパラメータの一部しか持たないため、機能的冗長性が存在しない。ReCycle のアプローチと VCCL・FlashRecovery を組み合わせて ZeRO + パイプライン並列に対応できるか。([[@2024__SOSP__ReCycle - Resilient Training of Large DNNs using Pipeline Adaptation]]) - ReCycle の Planner(MILP)は DP×PP 次元で事前計算するが、訓練中の DP 次元・PP 次元の動的変更(ノード追加・再参加)へのオンライン対応が可能か。また MoE モデルでは expert 並列という第四の並列次元が加わるが、ReCycle の機能的冗長性の定義はどう拡張されるか。([[@2024__SOSP__ReCycle - Resilient Training of Large DNNs using Pipeline Adaptation]]) - Unicron の WAF 最適化は 128 GPU(16 ノード)規模で評価されているが、1,000 GPU 超クラスタでは動的計画法の事前ルックアップテーブルのサイズが組合せ爆発するか。タスク数 m・クラスタ規模 n のスケーラビリティ限界はどこか。また Unicron の WAF 目標関数(クラスタ全体の複数タスク最適化)と ByteRobust の「ETTR 最大化(単一大規模ジョブ)」は、単一大規模タスクと複数中小タスク混在という前提の違いで別解に収束するか。([[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]]) - ReCycle のパイプラインバブル活用(訓練)と FailSafe の Hybrid Attention/Cyclic Placement(サービング)は、パイプライン並列 + テンソル並列のハイブリッド構成において統合できるか。同一 GPU 障害に対して訓練ジョブとサービングインスタンスが同一ノードに混在する場合(推論と訓練の混在クラスタ)、両者の復旧責任はどう分業すべきか。→ [[耐障害LLMサービング]] ## 関連 - ソース: [[@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]] / [[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]] / [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]] / [[@2024__SOSP__ReCycle - Resilient Training of Large DNNs using Pipeline Adaptation]] / [[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]] / [[@2025__arXiv__FailSafe - High-performance Resilient Serving]] - 概念: [[LLM分散学習]](Reliability 軸) / [[LLM学習モニタリング]](検知・局所化) / [[GPUレジリエンス]](ハードウェアの床) / [[GPUクラスタ運用]] / [[Fault Localization]] / [[障害緩和]] / [[ストラグラー]] / [[集合通信]] / [[チェックポイント]] / [[べき等性]] / [[根本原因分析]] / [[パイプライン並列化]] / [[弾性LLM訓練]] / [[耐障害LLMサービング]] - エンティティ: [[ByteRobust]] / [[MegaScale]] / [[ByteDance]] / [[Minder]] / [[NCCL]] / [[NCCLX]] / [[PICKER]] / [[Jim Gray]] / [[Tandem Computers]] / [[NonStop]] / [[FFTrainer]] / [[Bohan Zhao]] / [[Wei Xu]] / [[ReCycle]] / [[Swapnil Gandhi]] / [[Christos Kozyrakis]] / [[Stanford University]] / [[Unicron]] / [[Alibaba Group]] / [[Ziyi Xu]] / [[Zhiqiang Xie]] - 関連 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二分法) - [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]](§5 Failure Analysis: Infrastructure 件数 11%・GPU 時間 82%超、NVLinkError 30.25%・CUDAError 15.77%・NodeFailure 14.30%・ECCError 11.00%、2023 年 7 月の気温起因 NVLinkError 集中。§6.1 Fault-tolerant Pretraining: async checkpointing 3.6〜58.7× 削減、Log Agent + Failure Agent + Vector Store + 2-round NCCL allgather test、手動介入 ~90% 削減) - [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]](§1 motivation=Meta Llama3.1 405B 訓練の 466 job interruptions・2.12M H100 時間 / $18M ロス、§2.1 GPU 障害分布 + recurrence rate 表、§3 階層タクソノミー + 多段パイプライン、§5 本番 208 件 Micro F1=0.854・Macro F1=0.816) - [[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]](Checkpoint Razor: チェックポイントサイズ 90% 削減・FCR=毎イテレーション無料化条件・LCCL によるロールとランク分離・MTTR ~1,000 秒→29 秒(97% 削減)・MFU 損失 0.27% 以下・128 GPU 実証) - [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]](VCCL プライマリバックアップ QP: receiver 側起動の QP 切り替え + ブレークポイント再送でジョブ再起動不要・GPU 待機時間 ~90% 削減。24K GPU 本番運用) - [[@2024__SOSP__ReCycle - Resilient Training of Large DNNs using Pipeline Adaptation]](適応的パイプライン + 分割逆伝播 + ストラグラーオプティマイザ。Oobleck 対比最大 1.46×・Bamboo 対比最大 1.64×。10% 障害率でも Fault-Scaled の 0.5〜11.5% 低下以内。ZeRO スタイル DP には非適用) - [[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]](§2 障害統計: 上位 5% タスクの異常終了 43.4%・NCCL タイムアウト 10.1%。§3 アーキテクチャ: Agent + Coordinator、etcd KV。§4 誤り検知: 4 手法、3× D_iter 検知閾値。§5 WAF 目標関数 + DP 解法 O(mn²)。§6 遷移戦略: 部分結果再利用 + 近傍原則。§7 評価: trace-a Megatron 比 1.2×・trace-b 1.9×、Varuna 比 5.8×、128 GPU Alibaba Cloud) - [[@2025__arXiv__FailSafe - High-performance Resilient Serving]](訓練向け耐障害設計〈ReCycle〉と同一著者チームによるサービング向け耐障害設計。Non-uniform TP・Cyclic KVCache Placement・Hybrid Attention・Lightning Recovery。→ [[耐障害LLMサービング]] に主要な取り込み先)