# Silent Data Corruption (SDC)検知 ## 定義 Silent Data Corruption(SDC)は、ハードウェアがなんらのハードウェア/ソフトウェアアラームもトリガーせずに誤った計算結果を生成する障害クラスを指す。[[GPUレジリエンス]] が扱う MTBE(Mean Time Between Errors)ベースの障害特徴づけの多くが「XID 等で観測可能なエラー」を前提とするのに対し、SDC はその定義上**アラームを出さずに訓練の正しさだけを静かに破壊する**という点で異質であり、検出そのものが固有の技術的課題になる。[[@2026__OSDI__Safeguarding LLM Training at Scale - Online SDC Detection and Insights from 35 Million GPU Hours]](AEGIS、ByteDance/Tsinghua、OSDI 2026)は、低精度(bfloat16)訓練において古典的なアルゴリズムベースのチェックサム検知が丸め誤差ノイズに埋もれて機能しなくなるという課題を、Tensor Core 内部の混合精度(float32)アキュムレータを利用することで解決し、訓練フレームワークに内在する再計算の冗長性(activation recomputation・FlashAttention の backward 再計算)を利用した決定論的検知と組み合わせる。同じ OSDI 2026 で発表された [[@2026__OSDI__SDCs in the Wild - Characterizing and Diagnosing SDC-defective GPUs in Production LLM Training]](SDCHunter、ByteDance/Shanghai Jiao Tong University)は、AEGIS とは異なる問題——アラームが上がった**後**にそれが本当にハードウェア由来か判定し欠陥 GPU を物理的に特定する——を、データ並列(DP)レプリカ間の階層的な決定論的リプレイで解く。両者はいずれも決定論的実行を SDC 対策の基盤に据えるが、AEGIS が「常時稼働のオンライン検知」、SDCHunter が「異常発生後のオフライン診断・局在化」という異なる時間軸を担い、ByteDance の本番パイプラインで実際に連携している(SDCHunter 論文 §8 は AEGIS を SDC 検知ツールとして明示的に参照する)。 ## 横断的知見 - **SDC はオフライン診断の"通過"を裏切る——ハードウェアの信頼性の床は、アラームを出さない障害には測れない**: AEGIS は既知故障 8 台の再現実験で、ベンダー提供のオフライン診断ツール(NVIDIA EUD 等、[[GPUレジリエンス]] が特徴づける「XID に現れる急性故障」を検出する仕組み)が 2/8(25%)しか検出できない一方、AEGIS 自身は 8/8(100%)を検出したと報告する。[[GPUレジリエンス]] は本番投入前の厳格なストレステストで「不健全」なマシンを除外することを前提に信頼性の床を論じるが、SDC はその床の設計自体が想定していない「テストは通過するが訓練中にだけ発現する」障害である。AEGIS はこの回収率の低さを pre-screening bias(オフラインで健全と認定されたマシンだけが対象になっている)に帰しており、[[GPUレジリエンス]] の統計的骨格(host-level Pareto 集中、"lemon nodes")がハードウェア一般の弱点分布を捉えるのに対し、SDC 検知はその弱点分布のうち「静かに」発現する部分集合を狙い撃ちする必要があることを示す。(Source: [[@2026__OSDI__Safeguarding LLM Training at Scale - Online SDC Detection and Insights from 35 Million GPU Hours]]) - **低精度訓練は SDC 検知の精度基盤を掘り崩す——解決策はアルゴリズムの外(アクセラレータの内部精度)にある**: 古典的なアルゴリズムベースオンライン検知(チェックサムによる 2 経路比較)は bfloat16 のような低精度データ型では丸め誤差がチェックサム差分を支配し、偽陽性か過剰な検証コストのどちらかを強いる。AEGIS の解決は検知アルゴリズム自体の改良ではなく、Tensor Core が内部で使う float32 アキュムレータからチェックサムを直接取得するという、ハードウェア実装の特性を借用する解決策である。この「アルゴリズムの外側(ハードウェアの内部状態)に解決策を求める」設計判断は、[[耐障害LLM訓練]] の他の障害対応(チェックポイント最適化・冗長計算によるフォールトトレランス)が主にソフトウェア層・スケジューリング層で完結するのと対照的であり、SDC 検知が数値精度という独自の技術的制約を持つことを示す。 - **検知の非対称性(計算・メモリは検出できるが通信は未観測)は、既存の多層防御の効果を裏付ける形で残る**: AEGIS は本番展開で計算・メモリ起因の SDC を確認したが、通信起因の SDC は一件も観測しなかった。著者らはこれを、通信スタックが ECC・リンクレベルチェック等の多層エラー検知・訂正で既に保護されている一方、アクセラレータの計算パスにはエンドツーエンドの組み込み整合性チェックが少ないためと分析する。これは「どこに検知投資すべきか」という設計判断そのものが、既存の防御層の厚みに応じて決まることを示唆し、今後 SDC 検知が他のドメイン(ストレージ・ネットワーク機器)に拡張される際は、その対象領域の既存防御層の有無をまず確認すべきだという教訓になる。(Source: [[@2026__OSDI__Safeguarding LLM Training at Scale - Online SDC Detection and Insights from 35 Million GPU Hours]]) - **独立した2つの計測手法が、合成テストによる SDC 見逃し率について同じ結論に収束する**: AEGIS は既知故障 8 台の再現実験で、ベンダー提供のオフライン診断ツールの検出率が 2/8(25%)にとどまると報告する。同じ ByteDance の SDCHunter は、23 台の SDC 欠陥 GPU の特性調査から「標準的な合成マイクロベンチマークは欠陥デバイスの 60% 超(=検出率 40% 未満)を見逃す」と独立に報告する。測定対象(AEGIS は既知故障 8 台への再現実験、SDCHunter は本番で確認された 23 台の観測)も測定方法も異なる 2 つの研究が、同じ組織の同じ本番環境から出発しながら「オフライン/合成テストは SDC の過半数を見逃す」という同じ定性的結論に達しており、この見逃しが測定誤差ではなく SDC という障害クラスの構造的性質(§3 のトリガー条件依存性——特定のカーネル・データ型・入力値でのみ発現する)に起因することを裏付ける。(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]]) - **SDC は恒久的なハードウェア劣化であり一時的な soft error ではない、という結論に検知アプローチの異なる2論文が独立到達する**: AEGIS は「検出された SDC はすべて対応する GPU で再現可能だった」ことから、大部分が宇宙線等による一時的(transient)故障ではなく持続的なハードウェア障害に起因すると結論づける(あるマシンでは VRAM 障害と診断されリブート後は通過したが 1 か月後に同一障害が再発した事例を報告)。SDCHunter は独立に、SDC の時間的パターンを大規模(23 台)に特性調査し、事前デプロイのバーンイン検出はわずか 25% で、残りはデプロイ後 2 か月〜1 年にわたり段階的に出現し(1 年前後で 40%)、ベンダー分析はこれを計算回路の抵抗ドリフトによる**不可逆な**累積劣化と説明する。オンライン検知(AEGIS の個別インシデント再現)とオフライン特性調査(SDCHunter の集団統計)という異なる粒度の観測が、「SDC は消えない・一度発現したら再発する」という同じ結論に収束しており、これはリブートや再スケジューリングだけでは SDC を解決できず該当 GPU の物理的な隔離・修理が必要だという運用上の含意を強く裏付ける。(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]]) - **「軽量トリガー+高コスト確定検証」という2段階アーキテクチャに、独立設計された2つのシステムが収束する**: AEGIS の cSensor(クリティカルパス上の軽量センシング)→cVerifier(パイプラインバブルを使ったオフパス確定検証)という2段構成と、SDCHunter の Phase 1(DP レプリカ間の軽量シグネチャ比較でクラスタ全体から疑わしいグループへ絞り込み)→Phase 2(絞り込んだグループ内でのみ全テンソル比較を行う精密局在化)という2段構成は、粒度もタイムスケールも異なるにもかかわらず同じ設計原理——安価な粗粒度チェックで全体をふるいにかけ、高コストな細粒度検証は疑わしい部分集合だけに適用する——を体現する。SDCHunter の Table 4(通信境界のみの粗粒度計装はオーバーヘッド 4.3%・カバレッジ 5.65% だがカーネル単位の局在化はできない一方、カーネル単位の細粒度計装はカバレッジ 73.8% だがオーバーヘッド 683.9%)は、この2段階アーキテクチャがなぜ必要かを定量的に裏付ける根拠でもある。(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]]) - **MoE/Expert Parallelism の融合カーネルは、検知手法によらず共通の盲点として残る**: AEGIS はカバレッジを Matmul・FlashAttention という支配的な Transformer カーネルに限定しており、MoE のルーティング演算のような軽量演算子は計装対象外である。SDCHunter も独立に、EP(Expert Parallelism、MoE)の計算・通信カーネルが効率化のため融合されており、通信関連テンソルの内部シグネチャにアクセスできず EP 特有の局在化ができないと報告する(§5.2)。検知アーキテクチャが根本的に異なる 2 つのシステムが同じ盲点(MoE の融合カーネル)を独立に抱えており、これは実装上の見落としというより、カーネルフュージョンによる効率化と可観測性の間のトレードオフが MoE アーキテクチャに構造的に内在することを示唆する。(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]]) - **ゲートレベル故障注入が明かす根本原因は、AEGIS/SDCHunter が本番観測から積み上げた「検知の非対称性」「見逃し率」を構造レベルで説明する**: [[@2026__arXiv__The Anatomy of Silent Data Corruption - GPU Error Pattern Study and Modeling Guidance]](Tung+, NVIDIA/Duke/Rochester)は、production-classデータセンターGPUに対する300万シミュレータ時間規模のゲートレベルstuck-at故障注入により、SDCの600M件の観測破損のうちNaN/±INFはわずか1.01%(nullificationが50.68%で50.17倍多い)、単一ビット反転は非特殊破損の40%未満にとどまると定量化した。この数字は、AEGIS が「古典的なチェックサムベースのSDCスクリーニングはbfloat16の丸め誤差ノイズに埋もれて機能しない」と報告した課題や、[[GPUレジリエンス]]が特徴づける「ソフトウェアによるNaN/±INF監視の限界」を、本番クラスタの外側にあるゲートレベルの物理的根拠から裏付ける——**NaN/±INFのような明示的シグナルに依存する検知は、そもそもSDCの1%程度しか捕捉できない構造になっている**ことが、故障注入という別の手法で独立に示された。(Source: [[@2026__arXiv__The Anatomy of Silent Data Corruption - GPU Error Pattern Study and Modeling Guidance]]) - **故障箇所依存の破損分布は、AEGIS/SDCHunter が扱わない「検知アルゴリズム設計」の新しい軸を提供する**: 同論文は、制御パス故障(CudaCoreControl1/2)がnullification(全ビットゼロ化)に、データバッファ故障(L1$Data・L1$Miss Handler等)が非特殊ビット反転に偏るという、ハードウェアユニット単位の破損型分布を示した。さらに破損アドレスがwarpサイズ(W=32)を法とした空間周期性を持つことも定量化した。AEGIS・SDCHunter はいずれも検知の「タイミング」(オンライン/オフライン)や「粒度」(軽量トリガー+高コスト確定検証の2段階)を軸に設計されているが、この論文が示す構造(故障箇所依存の破損型・warp整列周期性)は、両システムが将来「どこを・どのパターンで疑うか」という第三の軸(パターン認識型のSDC予測器・故障局在化)を検知アルゴリズムに組み込む際の実証的な設計指針になりうる。(Source: [[@2026__arXiv__The Anatomy of Silent Data Corruption - GPU Error Pattern Study and Modeling Guidance]]) - **ストレージ領域の SDC(サイレントなディスク破損)は、GPU 領域の SDC より10年以上早く実務的な対策(継続的スクラビング)に到達しており、その設計はGPU領域の「検証コストと検知網羅性のトレードオフ」という共通課題への先行解になる**: [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]]は、Dropbox のストレージシステムにおいて「ディスク上のブロックは黙って壊れるか消失し、ディスクは通知もせずに故障する」「fsyncは常にファイルを同期させるわけではない」現象を明示的に「SDC」とは呼ばずに記述するが、その定義(ハードウェア/ソフトウェアのアラームなしに誤ったデータが生じる)は本概念の定義と一致する。同章が紹介する Disk Scrubber(全ストレージノード上で全ブロックを継続的に読み取りアプリケーションレベルのチェックサムで検証)は、AEGIS がアクセラレータの内部精度(float32アキュムレータ)を利用する解決策とは異なり、「常時全数走査」という力技でカバレッジを確保する設計であり、GPUのSDC検知が直面する「MoE融合カーネルの盲点」「通信路の非計装」のような部分的カバレッジの問題を、ストレージ領域では検証システム自体に基盤システムと同等規模のリソースを投じる(Dropbox は検証システムの開発に基盤ストレージシステムそのものより多くの時間を要したと明記する)ことで正面から解決している。両ドメインの対比は、SDC対策の設計空間に「軽量な巧妙な検知(AEGIS/SDCHunterの2段階アーキテクチャ)」と「力技の全数検証(Disk Scrubber)」という2つの極があることを示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] §17.5.2, §17.5.2.1) - **SDC は恒久的なハードウェア劣化であり一時的な soft error ではない、という AEGIS/SDCHunter の結論は、ストレージ領域の自動修復ワークフローが暗黙に前提とする設計とも整合する**: 本概念が既に記録する「SDC は再現可能な恒久障害である」という GPU 領域の知見(横断的知見参照)は、[[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] が示す Dropbox の自動ディスク修復ワークフロー(不良セクタ検出時は該当箇所を「不良」とマークして以後回避し、障害が閾値を超えるとディスク全体を不良と判定して物理的にリプレースする、という段階的だが不可逆な判定プロセス)と同じ前提——検出された破損は一時的な偶発事象ではなく、当該ハードウェア箇所固有の再発しうる欠陥として扱うべきだという前提——を共有する。ドメインが GPU(演算)からディスク(記憶媒体)へ変わっても、「SDC の原因は取り除けないので該当ハードウェアを隔離・交換する」という運用上の結論は同型である。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] §17.6.3) ## 未解決の問い - SDC 検知(AEGIS のようなオンライン手法)と [[GPUレジリエンス]] が特徴づけるハードウェア信頼性の統計的モデル(MTBE、host-level Pareto 集中、"lemon nodes")を統合すると、オフライン診断・オンライン SDC 検知・運用層の故障管理(Fine-grained・Guard 等)の間で検知コストと検出率をどう配分するのが最適か。SDCHunter の 2 段階リプレイ(軽量グルーピング→精密局在化)はこの配分問題への1つの回答例だが、AEGIS のオンライン検知層とどう統合すれば全体最適になるかは未解決のまま。 - 通信起因の SDC が本当に存在しないのか、それとも既存の多層防御が単に発現を防いでいるだけで、防御層が薄い他のシステム(推論サービング、あるいは通信ライブラリの実装が異なる環境)では顕在化するのか。 - AEGIS のカバレッジは Matmul・FlashAttention という支配的な Transformer カーネルに限定される。MoE のルーティング演算、正規化層(RMSNorm・GeLU)等、バックボーン外の軽量演算子に対する低オーバーヘッドな SDC 検知手法はどう設計すべきか。SDCHunter も同じ MoE/EP 融合カーネルの盲点を独立に抱えており(横断的知見参照)、両システムに共通するこの盲点をどちらか一方の設計変更で埋められるのか、それとも第三の手法が要るのかは未解決。 - ソフトウェアバグに起因する「SDC 様」の破損(AEGIS が偶発的に捕捉した境界外書き込みの事例、SDCHunter の Case 1 の shape mismatch/out-of-bound 事例)を、ハードウェア起因の SDC と体系的に区別する仕組みは構築できるか。両論文とも個別の事例観察にとどまり、体系的な切り分け手法は示していない。 - AEGIS(オンライン検知)と SDCHunter(オフライン診断・局在化)は ByteDance の本番パイプラインで既に連携している(SDCHunter §8 が AEGIS を参照)が、両者の連携点(AEGIS の検知結果が SDCHunter のどの入力になるか、閾値やトリガー条件をどう受け渡すか)の技術的詳細はどちらの論文にも記述がない。この橋渡し部分の設計は独立した研究対象になりうるか。 - SDCHunter の障害モデルは「診断ウィンドウ内で少なくとも1つのリプレイレプリカは健全」という前提に立つ。AEGIS が報告する SDC の pre-screening bias(オフライン診断が本番投入前に不健全なマシンを除外しきれていない)を踏まえると、この前提が崩れる(全レプリカが同時に破損する)実際の発生確率はどの程度か。 - Tung+ のゲートレベルFI研究が示す故障箇所依存の破損分布(制御パス→nullification、データバッファ→非特殊ビット反転)とwarp整列周期性を、AEGIS のcSensor/cVerifierやSDCHunterの2段階リプレイに実際に組み込んだ場合、検出率や誤検知率はどの程度改善するか。同論文が提案する分布考慮型ソフトウェアFIテンプレート(Fig. 8)は指針にとどまり、実際のML訓練ワークロードでの検証は行われていない。 - Disk Scrubber のような「常時全数走査」型の検知アーキテクチャは、GPU 領域のようにチェックサム計算コスト自体が高価なドメインにどこまで移植可能か。ストレージ領域でこの設計が成立するのは I/O 帯域に比してチェックサム計算コストが相対的に軽いためだと考えられるが、GPU の演算コストとの定量比較は本 wiki 内のいずれのソースにも記述がない。 ## 関連 - 概念: [[GPUレジリエンス]] / [[耐障害LLM訓練]] / [[Fault Localization]] / [[データ耐久性]](ストレージ領域のSDC対策を包含する上位概念) - ソース: [[@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]] / [[@2026__arXiv__The Anatomy of Silent Data Corruption - GPU Error Pattern Study and Modeling Guidance]] / [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]](ストレージ領域のSDC — Disk Scrubber・自動ディスク修復ワークフロー) ## 出典 - [[@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]] - [[@2026__arXiv__The Anatomy of Silent Data Corruption - GPU Error Pattern Study and Modeling Guidance]] - [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] §17.5.2, §17.5.2.1, §17.6.3