# 耐障害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)。 ## 子概念 - [[GPUレジリエンス]] - [[Heisenbug]] - [[LLM分散学習]] - [[ML訓練システムの信頼性原則]] - [[RL重み差分配信]] - [[Silent Data Corruption (SDC)検知]] - [[ソフトウェア耐障害性]] - [[プロセスペア]] - [[耐障害LLMサービング]] ## 横断的知見 - **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]]) - **RL 訓練では trainer と推論(rollout)の障害コストが構造的に非対称——耐障害設計が事前学習と質的に異なる**: [[@2026__Cognition__SWE-1.7 - Frontier Intelligence at a Fraction of the Cost]] は 3 大陸 4 データセンターにまたがる非同期 RL 訓練で、推論側の故障は「自己完結・無状態」ゆえに安価(落ちたレプリカの分だけ損失、[[NVIDIA Dynamo]] が別ワーカーへ即座に再ルーティング)とし、trainer 側の故障のみが「単一のタイトに結合されたコンポーネント」として高コストになるという非対称性を明示する。これは本 concept が集めてきた事前学習(pretraining)の耐障害設計(ByteRobust・MegaScale 等、全 GPU が対等に貴重で全故障が高コスト)とは前提が異なり、RL の「trainer 1 箇所+自己完結な推論エンジン群」という分業構造が耐障害設計を単純化する好例だ。復旧手段も、非同期チェックポイント+ピア複製(trainer 側、秒単位復元)と、object storage 上のチェックポイント+差分リプレイ(推論側、Dynamo 再スケジュール時)に分業されている。(Source: [[@2026__Cognition__SWE-1.7 - Frontier Intelligence at a Fraction of the Cost]]) - **圧縮重み差分のオブジェクトストレージ配信は、チェックポイント配布問題と重み更新配信問題を同一の「単一真実源」パターンで解く**: SWE-1.7 は毎回全モデルをブロードキャストする代わりに K 勾配ステップごとの圧縮重み差分(転送量 99% 超削減)をクラウドオブジェクトストレージへ書き込み、各クラスタの weight controller がマニフェストをポーリングして pull する設計を取る。これはトレーニング側チェックポイントの「非同期フラッシュ+ピア複製」と同じ「単一真実源+非同期プル」パターンを、推論エンジンへの重み配信という別の問題に適用したものであり、1T パラメータモデルの大陸間更新をエンドツーエンドで 1〜2 分・推論停止 3〜4 秒に抑える。(Source: [[@2026__Cognition__SWE-1.7 - Frontier Intelligence at a Fraction of the Cost]]) - **重み差分配信の定量的根拠が、耐障害性とは独立の文脈(コスト効率)から示された**: [[@2026__Fireworks AI__Frontier RL Is Cheaper Than You Think]] は、SWE-1.7・Composer 2 が採用する圧縮重み差分配信パターンの背後にあるメカニズムを一般化し、bf16 チェックポイント間で 98% 超の重みがビット等価という実測(1TB チェックポイントの平均差分 20.3 GiB)を報告する。同じアーキテクチャ解が、本 concept が扱う耐障害性の文脈(SWE-1.7)と、帯域コスト最適化の文脈(Fireworks AI)という異なる動機から独立に到達されている点は、このパターンの一般性を裏付ける(→ [[RL重み差分配信]] に詳細を分離)。(Source: [[@2026__Fireworks AI__Frontier RL Is Cheaper Than You Think]], [[@2026__Cognition__SWE-1.7 - Frontier Intelligence at a Fraction of the Cost]]) - **2023 年時点で既に「プロセスレベルの検知→隔離→復旧」「ハイブリッド異常検知」「非同期+RDMA チェックポイント」の三本柱が出そろっていた**: [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]](SenseTime、GPT3-175B・512 GPU)は、ByteRobust・MegaScale(いずれも 2024〜2025 年)に先立ち、①プロセス単位(ジョブ単位でなく)の状態機械ベース自動フォールトトレランス、②ログベース+メトリックベース(LOF・KNN Matrix Profile・DTW クラスタリング)のハイブリッド異常検知、③インメモリキャッシュ+非同期永続化+RDMA バックアップのチェックポイントエンジンという設計を統合していた。GPT3-175B の訓練期間を 28% 短縮、チェックポイント読み書きを最大 27 倍高速化(実運用値、255秒→16秒相当)と、本 concept が集める後続システムと同じ桁の改善を報告する。「プロセスレベルの検知→隔離→復旧」という設計方針自体は目新しくなく、2023 年の TRANSOM から 2025 年の ByteRobust/MegaScale まで一貫している——変化しているのは規模(数百 GPU → 数万 GPU)と検知の対象(明示的エラー中心 → 暗黙的障害・fail-slow 中心)である。(Source: [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **RDMA によるチェックポイントキャッシュのピア間バックアップは、ByteRobust の warm standby 以前から存在した復旧高速化パターン**: TRANSOM の TCE は、各ノードの TCE サーバが次ノードランクへ RDMA 経由でチェックポイントキャッシュを非同期・耐久的にバックアップする設計を採り、「実際にはほぼすべてのインフラ障害は単一ノード規模の事象」という前提のもとで近接ノード同時障害の低確率性に依拠する。これは ByteRobust の warm standby(予備機の事前準備)や FlashRecovery のデータ並列複製冗長と同じ「冗長性を先に準備しておき障害時に即座に切り替える」思想の初期実装であり、TRANSOM の理論的性能解析式(式1〜3、メモリ帯域対ネットワークアタッチトストレージ帯域の比)は、後続システムが暗黙のうちに前提とする「メモリ/RDMA がディスク I/O よりも桁違いに速い」という定量的根拠を明示的に導出している。(Source: [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]]) - **ジョブレベル対プロセスレベルという分業の粒度が、商用プラットフォームと専用システムを分ける軸になっている**: TRANSOM の著者らは Huawei ModelArts のフォールトトレランスをジョブレベル(異常検知結果がフォールトトレランス機能と非統合)、TRANSOM 自身をプロセスレベル(検知結果を直接フォールトトレランスツールへ連携)と位置づける。この「ジョブレベル vs プロセスレベル」の対比は、後年 ByteRobust が「並列グループ単位の過剰排除」という中間的な粒度(プロセス個別でもジョブ全体でもない)を選んだこととあわせて読むと、耐障害設計の粒度選択が「精密さ(プロセス単位)」「実装単純さ(ジョブ単位)」「巻き込み許容度(グループ単位)」の三者間トレードオフであることを示す。(Source: [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **TRANSOM と同じ 2023 年、Gemini は「CPU メモリ + 遊休帯域」という第三の初期系統を確立していた**: [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]](TRANSOM、SenseTime)が RDMA 経由の非同期ピア間バックアップで攻めたのと同じ 2023 年、[[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]](Rice University・AWS)は「GPU 間ネットワークの遊休時間帯にチェックポイント通信をパイプライン化して割り込ませる」という設計で、CPU メモリへの毎イテレーションチェックポイントを実現した。TRANSOM が「近接ノード同時障害の低確率性」に依拠する RDMA バックアップだったのに対し、Gemini はチェックポイント配置の復旧確率を確率論的に証明する理論(Theorem 1・Corollary 1)を最初から備えていた点で異なる。この「訓練ネットワークの遊休帯域を保存経路として使う」という設計は、2 年後の FFTrainer(2025)が独立に(あるいは継承的に)再定式化し、Checkpoint Razor + LCCL によって MTTR を秒単位までさらに短縮する土台となった。2023 年時点で「RDMA ピア間バックアップ」(TRANSOM)と「遊休帯域パイプライニング」(Gemini)という 2 つの独立した高速チェックポイント系統がすでに存在しており、いずれも「メモリ/ネットワークの遊休余地をチェックポイント経路に転用する」という共通原理に基づく。(Source: [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]], [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]], [[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]]) - **「再起動するか、進み続けるか」を定量閾値で判定する第一の定式化——ReCCL のフェイルオーバー条件式**: これまで本 concept が集めてきた耐障害設計(ByteRobust・MegaScale・FlashRecovery 等)は「いかに速く検知・復旧するか」を競うが、[[@2026__EuroSys__Handling Network Faults in Distributed AI Training]](ReCCL)は last-hop ネットワーク障害に限り「そもそも再起動すべきか」を問い直す。チェックポイント間隔 $T_{interval}$・経過時間 $t_{elapsed}$・検知時間 $T_{detect}$・フェイルオーバー時スローダウン率 $k$ から $t_{elapsed} > (T_{interval}(k-1) - T_{detect})/k$ という閾値式を導出し、これを満たすときのみフェイルオーバー(進行継続)を選び、満たさなければ通常どおり restart する。ByteRobust の「過剰排除で迅速に隔離する」・FlashRecovery の「データ並列複製で復旧を高速化する」がいずれも「復旧をどう速くするか」の軸で競うのに対し、ReCCL は「復旧不要な選択肢(フェイルオーバー)がいつ有利になるか」を定量化した点で異なる軸を開く。ただし対象は last-hop ネットワーク障害(CCL がスタックするが状態は壊れない障害)に限定され、GPU 故障やソフトウェアクラッシュには適用できない。(Source: [[@2026__EuroSys__Handling Network Faults in Distributed AI Training]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]]) - **CCL 層の透過的フェイルオーバーに、フェイルオーバー後の性能劣化を埋め戻す最適化が対になって初めて実用になる**: VCCL([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]])が NIC 障害を receiver 主導の QP 切り替えで吸収し GPU 待機時間を約90%削減するのに対し、ReCCL は sender 起点の in-band 同期に加え、フェイルオーバー後に残る性能劣化そのものを Dynamic Channel Rebalancing(straggler channel の無効化)と Transit GPU over NVLink(PCIe ボトルネック回避)で積極的に埋める。テストベッド実測でフェイルオーバー時のスローダウンを k<1.1(多くのケースで1.004〜1.0215)に抑えており、「落ちない」だけでなく「落ちても速度がほぼ落ちない」ことまでを CCL 層の責務に含める点が、VCCL や NCCLX の Fault-Tolerant AllReduce(FTAR)とは異なる強度の耐障害設計になっている。(Source: [[@2026__EuroSys__Handling Network Faults in Distributed AI Training]], [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]]) - **「復旧を速くする」から「復旧しても勾配分布を変えない」へ——計算等価性を単一不変条件として定式化した第一の系統**: これまで本 concept が集めてきた前方復旧系(ByteRobust の warm standby・FlashRecovery のデータ並列複製・FFTrainer の MTTR 短縮)は、いずれも「いかに速く生存者だけで訓練を再開するか」を競う。しかし障害後に生存レプリカだけで継続する drop-and-go は、グローバルバッチに含まれるマイクロバッチ数を減らして勾配ノイズスケールをシフトさせ、損失スパイクを誘発しうる——[[@2026__arXiv__ReCoVer - Resilient LLM Pre-Training System via Fault-Tolerant Collective and Versatile Workload]] はこれを FTAR(Salpekar+, arXiv:2602.00277)の限界として名指しし、「各反復が常に同じ数のマイクロバッチ B を確定させる」という単一不変条件(Σ C_r(t) = W_init・G_init = B)を提案する。ULFM ベースの障害耐性集合通信(通信層)・反復内のバケット単位勾配復元(反復層)・Major/Minor/Spare の 4 ロールによる動的マイクロバッチ再配分(ワークロード層)という 3 層構成で、512 GPU・256 GPU 喪失下で無故障参照実行と視覚的に区別不能な損失曲線を実証した。これは「復旧の速さ」という単一軸だけでなく「復旧後も分布的に統計的等価であり続けるか」という第二の軸を前方復旧系に導入する、初めて数学的証明(Appendix F の分布等価性証明)を伴う定式化である。(Source: [[@2026__arXiv__ReCoVer - Resilient LLM Pre-Training System via Fault-Tolerant Collective and Versatile Workload]]) - **ホットスペアの「常時アイドル」という浪費を、役割の動的再定義で解消する——SPARE のシミュレーションのみの冗長計算に対する実装ずみの代替**: 前方復旧の先行研究には、ホットスペア(予備レプリカ常備、C4 的なコスト)と SPARE([[@2026__arXiv__ReCoVer - Resilient LLM Pre-Training System via Fault-Tolerant Collective and Versatile Workload]] が言及する Lee+, arXiv:2603.00357、データシャード複製による前方復旧だがシミュレーション検証のみで障害時に大きな冗長計算係数を要する)という 2 つの極があった。ReCoVer の Major-spare/Minor-spare は「対応する Major/Minor と同じフォワード・バックワード計算を実行しつつ all-reduce 時に勾配をゼロ化する」設計により、スペアが常にウォームで即座に昇格可能でありながら、通常時は計算資源としてグローバルバッチに寄与しない(=冗長ではなく単に「未使用」)という中間点を実機実装で示した。ホットスペアの「静的な予備」と SPARE の「動的だが冗長計算コスト大」の間に、「動的かつゼロ冗長」という第三の設計点があることを示唆する。(Source: [[@2026__arXiv__ReCoVer - Resilient LLM Pre-Training System via Fault-Tolerant Collective and Versatile Workload]]) - **HSDP レプリカを耐障害性の単位に据えることで、CPU-GPU ハイブリッド AllReduce と非ブロッキング catch-up の両方が同時に成立する**: [[@2026__arXiv__Training LLMs with Fault Tolerant HSDP on 100,000 GPUs]](FT-HSDP、Meta)は、ByteRobust の「並列グループ単位の過剰排除」・ReCoVer の「マイクロバッチ単位の動的再配分」とは異なる第六の系統として、HSDP のデータ並列レプリカそのものを耐障害性の単位に選ぶ。この選択により、レプリカを跨ぐ集団通信が「AllReduce 1 種類のみ」に単純化され、CPU が制御ロジック(コネクション再構築・輻輳制御・エラー種別判定)を、GPU がデータ転送を担う [[FT-HSDP]] のハイブリッド設計(FTAR)が可能になる。ByteRobust・MegaScale が既存の集団通信ライブラリ(NCCL)を所与として周辺の検知・隔離・チェックポイントを最適化するのに対し、FT-HSDP は集団通信プロトコル自体を耐障害目的で作り直す点で異なる層に切り込む。98K GPU 実測でスタール時間 10 分→3 分、有効訓練時間 44%→80% を達成し、FTAR は native NCCL AllReduce より少ない SM(2 対 4)で比較可能なスループットを出す。(Source: [[@2026__arXiv__Training LLMs with Fault Tolerant HSDP on 100,000 GPUs]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2026__arXiv__ReCoVer - Resilient LLM Pre-Training System via Fault-Tolerant Collective and Versatile Workload]]) - **非ブロッキング catch-up は「ゼロ勾配」という最小限のシグナルで、遅延レプリカを健全レプリカと数学的に等価な状態へ揃える**: FT-HSDP の非ブロッキング catch-up プロトコルは、遅れたレプリカがチェックポイントをピアツーピアで取得しつつステップ終了時にゼロ勾配を送信することで、通常の勾配交換(AllReduce)の仕組みを一切変更せずに全レプリカを同一状態へ揃える。これは ReCoVer の「Σ C_r(t) = B という単一不変条件を通信・反復・ワークロードの 3 層で維持する」設計や、FlashRecovery の「データ並列複製を冗長として使い切ってしまう」設計とも異なる第七の系統で、「遅れたレプリカに何もさせず、勾配の総和という不変量だけを保つ」という最小侵襲的な設計思想を持つ。ただしこれは「健全レプリカがチェックポイント取得より遅くない」という前提(§4.3)に依存しており、取得がステップより遅い稀なケースではブロッキングに戻る。(Source: [[@2026__arXiv__Training LLMs with Fault Tolerant HSDP on 100,000 GPUs]], [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2026__arXiv__ReCoVer - Resilient LLM Pre-Training System via Fault-Tolerant Collective and Versatile Workload]]) - **同一組織(Meta)による 2 世代の障害内訳の変化——ハードウェア支配的という骨格は保たれるが、内訳の重心は世代で動く**: FT-HSDP の 32K GPU 本番データ(678 件の中断、Network Switch/Cable は 36 件・5.3%)は、GPU HBM3 Memory(22.9%)が最多要因、PCIe Device(18.0%、うち SSD の致命的 NVMe ファームウェアバグに起因する部分を含む)が僅差で続き、Faulty GPU Compute はかつて最多だったが積極的隔離により第 4 位(7.4%)へ後退したと報告する。既存 wiki が記録する Meta Llama 3.1 405B 訓練の 466 件のジョブ中断(2.12M H100 時間・$18M 相当の損失、[[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] 経由)と並べると、同一組織の異なる訓練クラスタ・時期でも「ハードウェア起因が支配的」という骨格自体は一貫する一方、内訳の重心(GPU Compute → HBM/PCIe)は障害対応の進展とともに動くことを示す。ただし本 wiki には Llama 3 論文([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] や TSGuard が引用する 405B 訓練の統計そのもの)を独立ソースとして収めた source ページが存在しないため、件数・カテゴリ単位での直接対比はできず、この対比は暫定的な観察にとどまる。(Source: [[@2026__arXiv__Training LLMs with Fault Tolerant HSDP on 100,000 GPUs]], [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]]) - **障害分類の粒度が粗いと、光モジュール起因の障害はネットワークカテゴリへ暗黙的に丸め込まれる**: FT-HSDP の Table 1 は "Network Switch/Cable"(36 件・5.3%)という単一カテゴリでネットワーク障害をまとめており、本文中に "optical"・"transceiver"・"BER"・"FEC" のいずれの語も現れない。これは [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]](OptProphet)が光トランシーバー故障を独立カテゴリとして扱い平均 1.11 日前に予測する設計や、[[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]] が Pre-FEC/Post-FEC の BER で劣化リンクを事後的に切り分ける実務と対照的である。「ハードウェア障害の内訳を粗い部品カテゴリで公開する」研究(FT-HSDP・SAKURAONE・Minder)と、「光レイヤーだけを深掘りする」専門研究(OptProphet)は補完関係にあり、前者の粗い分類だけでは光起因障害の実際の比率は分からないという限界がある。(Source: [[@2026__arXiv__Training LLMs with Fault Tolerant HSDP on 100,000 GPUs]], [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) - **サイレントな破損(SDC)は「検知しないと復旧すら始まらない」という点で、本 concept の他の耐障害機構(復旧の速さ・分布的等価性)とは異なる前段階の課題である**: これまでの横断的知見は主に「障害検知後にいかに速く・正しく復旧するか」(ByteRobust の warm standby、ReCoVer の計算等価性、FT-HSDP の非ブロッキング catch-up)を扱ってきたが、[[@2026__OSDI__Safeguarding LLM Training at Scale - Online SDC Detection and Insights from 35 Million GPU Hours]](AEGIS)が扱う SDC はそもそもアラームが上がらないため、これらの復旧機構が一切発動しない。AEGIS は cSensor-cVerifier という 2 段階抽象でこの「検知の空白」を埋め、Tensor Core の float32 アキュムレータと訓練フレームワークの再計算冗長性(activation recomputation・FlashAttention backward)を利用して、パイプラインバブルを使った低オーバーヘッド(0.86%)な確定検証を実現する。検知された SDC が非決定論的に発現する一方で根本原因は恒久的なハードウェア故障だったという知見(§8 Permanent vs. Transient)は、[[GPUレジリエンス]] の「信頼性の床」の議論とも接続する。「検知の空白」を埋めた後の課題——検知されたシグナルから実際に欠陥デバイスを特定し訓練を再開する——は [[@2026__OSDI__SDCs in the Wild - Characterizing and Diagnosing SDC-defective GPUs in Production LLM Training]](SDCHunter)が担う。SDCHunter は DP レプリカ間の階層的リプレイでオンラインジョブの復旧を 1 時間未満でブロック解除し、オフラインでの GPU 局在化も 1 時間以内に完了させる点で、本 concept の他の耐障害機構(復旧の速さ)と SDC 検知(前段階の課題)を橋渡しする。詳細な技術的知見は [[Silent Data Corruption (SDC)検知]] に集約する。(Source: [[@2026__OSDI__Safeguarding LLM Training at Scale - Online SDC Detection and Insights from 35 Million GPU Hours]], [[@2026__OSDI__SDCs in the Wild - Characterizing and Diagnosing SDC-defective GPUs in Production LLM Training]]) - **汎用ML訓練の定性原則が、規模が上がるにつれて分単位の定量目標へ先鋭化する**: 『信頼性の高い機械学習』7章は、規模を問わない汎用ML訓練システムを対象に「利用可能なリソースに比べて再訓練のヘッドルームが多いほど障害停止からの回復力が高まる」(§7.3.9)、「機能停止には検知時間と再訓練時間の両方を合算して考えるべきだ」(§7.3.11)と定性的に述べるにとどまる。本 concept が集約する数万〜10万GPU級のLLM事前学習の文献群は、同じ発想をETTR(有効訓練時間率)という連続量に定量化し、10万GPU級では約2分のチェックポイント間隔と約2分の再起動が必要になるという具体的な数値要件にまで落とし込む。また同書が原則1として述べる「ほとんどの障害はMLに特有ではない」という経験則は、[[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]](1985年)や ByteRobust の実測(インフラ障害は件数11%でもGPU時間の82%を占める)とも規模・時代を超えて一致する。汎用書が示す原則の枠組みと、大規模LLM訓練文献が示す定量的な実装が、同じ現象の異なる解像度の記述であることが両者の突き合わせで見える。詳細な原則の一覧は [[ML訓練システムの信頼性原則]] に集約した。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 7 MLモデル訓練システム]] §7.3.1, §7.3.9, §7.3.11, [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]], [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]]) ## 未解決の問い - 過剰排除(ByteRobust)の偽陽性(8 台中 6〜7 台)を抑えつつ早期隔離する均衡点はどこか。精密な箇所特定([[Minder]]/[[Pulse]])を隔離判断の事前情報として組み合わせると、巻き込み台数を減らしつつ ETTR を保てるか。 - SDC・gray failure(NVIDIA EUD の recall は 70%、ByteRobust §9)は決定的に再現しにくい。[[@2026__OSDI__Safeguarding LLM Training at Scale - Online SDC Detection and Insights from 35 Million GPU Hours]](AEGIS)は既知故障 8 台の再現実験で自身が 8/8 検出・オフライン診断が 2/8 という具体的な数字でこの問いに部分的に答えたが、これは AEGIS が計装した Matmul・FlashAttention に限った話であり、バックボーン外の軽量演算子(RMSNorm・GeLU 等)や通信起因の SDC は依然カバー外(→ [[Silent Data Corruption (SDC)検知]])。オンライン監視([[LLM学習モニタリング]])や先回り型検証(SuperBench 型)と AEGIS 型のオンライン確定検証を統合すれば、検知漏れの残りをどこまで詰められるか。 - チェックポイント不要の復旧(ライブマイグレーション・モジュール冗長・弾力的訓練)は、チェックポイントに基づく復旧をどこまで置換できるか。本番採用例はまだ乏しい(→ [[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]]) - TRANSOM の TEE は評価データセットが小規模(正常13件・異常11件)で、GPU 使用率・ネットワークトラフィックが高いタスクにしか適用できないという限界を著者ら自身が認める。2023 年から 2025〜2026 年の後続システム(Guard・C4D・TSGuard)は、この限界(小規模評価・適用範囲の狭さ)をどう解消したのか、あるいは同種の限界を別の形で引き継いでいるのか。([[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]]) - 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サービング]] - ReCoVer の計算等価性保証(単一不変条件)と ByteRobust/MegaScale の「速さ優先」の前方復旧を、同一システムで両立できるか。ReCoVer は 512 GPU 規模での実証にとどまり、100k GPU 級で ULFM ベースの集合通信修復(`MPIX_Comm_shrink` によるコミュニケータ再構築)がスケールするかは未検証。通信器修復のコストは生存者数にどう依存し、頻繁な障害下で復旧そのものがボトルネックになる閾値はどこか。([[@2026__arXiv__ReCoVer - Resilient LLM Pre-Training System via Fault-Tolerant Collective and Versatile Workload]]) - ReCoVer は失われたレプリカの生存ランク(例えば 3D 並列で TP/PP 次元の一部だけが生き残った場合)を現状破棄しており、著者ら自身がこれを Future Work として明示する。この「部分生存ランクの再利用」は、ReCycle のパイプラインバブル活用や ByteRobust の warm standby とどう組み合わせれば、破棄コストをさらに削減できるか。([[@2026__arXiv__ReCoVer - Resilient LLM Pre-Training System via Fault-Tolerant Collective and Versatile Workload]]) - FT-HSDP の非ブロッキング catch-up は「健全レプリカがチェックポイント取得より遅くない」ことを前提とする。データ並列度・レプリカ数・チェックポイントサイズがこの前提を破る規模(例えば 100K GPU をさらに超える、あるいはレプリカ数を極端に増やす場合)では、ブロッキングが再発するか。ReCoVer の計算等価性保証や FlashRecovery の複製冗長と組み合わせれば、この前提への依存を減らせるか。([[@2026__arXiv__Training LLMs with Fault Tolerant HSDP on 100,000 GPUs]]) - FT-HSDP の障害検知は 60 秒タイムアウトに依存し、著者ら自身が §2.3 の高速根本原因分析(RCA)ツールとの統合で障害検知〜復旧のスタールをさらに削減できる可能性を明言するが、本論文ではその統合を実証していない。Mycroft のような集団通信層の専門診断([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])と FTAR のエラー分類(回復可能/回復不能)を統合すると、タイムアウト依存の検知よりどれだけ速く障害を判定できるか。 - 光モジュール・光リンク起因の障害は、FT-HSDP を含む多くの本番障害統計で "Network Switch/Cable" のような粗いカテゴリへ丸め込まれている。OptProphet のような光レイヤー専門の検知・予測手法を、FT-HSDP のような粗粒度の障害分類システムへ統合すると、Network 起因の 5.3%(36 件)のうちどの程度が光トランシーバー起因と再分類されるか。 ## 関連 - ソース: [[@2026__OSDI__Safeguarding LLM Training at Scale - Online SDC Detection and Insights from 35 Million GPU Hours]] / [[@2026__EuroSys__Handling Network Faults in Distributed AI Training]] / [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]] / [[@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]] / [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]] / [[@2026__arXiv__ReCoVer - Resilient LLM Pre-Training System via Fault-Tolerant Collective and Versatile Workload]] / [[@2026__arXiv__Training LLMs with Fault Tolerant HSDP on 100,000 GPUs]] - 概念: [[Silent Data Corruption (SDC)検知]](検知そのものの前段階課題) / [[LLM分散学習]](Reliability 軸) / [[LLM学習モニタリング]](検知・局所化) / [[GPUレジリエンス]](ハードウェアの床) / [[GPUクラスタ運用]] / [[Fault Localization]] / [[障害緩和]] / [[ストラグラー]] / [[集合通信]] / [[チェックポイント]] / [[べき等性]] / [[根本原因分析]] / [[パイプライン並列化]] / [[弾性LLM訓練]] / [[耐障害LLMサービング]] / [[RL重み差分配信]] / [[異常検知]] / [[データセンターネットワーク信頼性]] / [[ML訓練システムの信頼性原則]](規模を問わない汎用ML訓練の定性原則) - エンティティ: [[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]] / [[SenseTime Research|SenseTime]] / [[Shigang Li]] / [[Zhuang Wang]] / [[T. S. Eugene Ng]] / [[Rice University]] / [[Amazon Web Services]] / [[Ziyue Liu]] / [[Zheng Zhang]] / [[Bogdan Nicolae]] / [[UC Santa Barbara]] / [[Argonne National Laboratory]] / [[FT-HSDP]] / [[Meta]] / [[Omkar Salpekar]] / [[Rohan Varma]] / [[Chunqiang Tang]] / [[Maxim Naumov]] - 関連 MOC: [[分散深層学習 - MOC]] / [[HPC - MOC]] ## 出典 - [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 7 MLモデル訓練システム]](§7.3.1 ほとんどの障害はMLの障害ではない、§7.3.9 リソースの活用と回復力、§7.3.11 機能停止には復旧も含まれる——汎用ML訓練を対象にした定性的な信頼性原則) - [[@2026__OSDI__Safeguarding LLM Training at Scale - Online SDC Detection and Insights from 35 Million GPU Hours]](AEGIS: cSensor-cVerifier 抽象、§7.3 既知故障8台の検出能力比較、§8 恒久vs一時的SDC・ソフトウェア起因SDC) - [[@2026__OSDI__SDCs in the Wild - Characterizing and Diagnosing SDC-defective GPUs in Production LLM Training]](SDCHunter: §2-3 23台の SDC 欠陥 GPU 特性調査、§5 Phase1/Phase2 の階層的決定論的リプレイ、§6 評価=検出カバレッジ100%・局在化精度100%・オーバーヘッド4%未満、40件の本番SDC緩和実績) - [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]](GPU マシン CPU メモリへのチェックポイント配置戦略の最適性証明・遊休ネットワーク帯域を用いたトラフィックパイプライニング・障害復旧 13 倍超高速化) - [[@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__Cognition__SWE-1.7 - Frontier Intelligence at a Fraction of the Cost]](非同期 RL 訓練の 3 大陸マルチクラスタ構成、trainer/推論間の障害コスト非対称性、圧縮重み差分のオブジェクトストレージ配信) - [[@2026__Fireworks AI__Frontier RL Is Cheaper Than You Think]](bf16 重みスパース性 98% 超の実測、20.3 GiB 平均差分、圧縮重み差分配信パターンの一般化) - [[@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サービング]] に主要な取り込み先) - [[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]](TOL=プロセスレベル自動フォールトトレランス、TEE=ログ+メトリクスのハイブリッド異常検知〈LOF・KNN Matrix Profile・DTW〉、TCE=インメモリキャッシュ+非同期永続化+RDMA バックアップのチェックポイントエンジン。GPT3-175B・512 A800 GPU で訓練期間 28% 短縮、チェックポイント読み書き最大 27 倍高速化) - [[@2026__arXiv__Training LLMs with Fault Tolerant HSDP on 100,000 GPUs]](FT-HSDP:HSDP レプリカを耐障害性の単位とする非同期復旧・CPU-GPU ハイブリッド AllReduce〈FTAR〉・非ブロッキング catch-up。98K GPU 実測でスタール 10分→3分・有効訓練時間 44%→80%。32K GPU 本番障害内訳〈678件、ハードウェア起因 78%、Network Switch/Cable 5.3%〉)