Silent Data Corruption (SDC)
硬件静默错误的根因、检测方法及对 AI 训练的威胁
核心要点：
- SDC 根因分两类：永久故障 （制造逃逸/老化） 和瞬态故障 （辐射/热），永久故障尤其是制造测试逃逸最主导，发生率约 1/1000 器件
- GPU SDC 99% 产出合法浮点数值 （非 NaN/INF），标准异常监控完全失效；多 bit flip (>60%) 而非单 bit flip 是主要模式
- AI 训练比传统 HPC 更脆弱：梯度累积放大、Adam 动量保留腐败信号、分布式 AllReduce 使单点 SDC 污染全局
- 检测方案从硬件 ECC 到软件冗余再到学术新方案 (Orthrus 87% / Dr. DNA 95%)，趋势是"检测 → 选择性重算"替代全面冗余
- FP16 训练最脆弱 （PPL 偏离可达 600%），FP8 崩溃率 41.9%; 57-76% 运行表面正常但隐藏参数漂移
SDC 的硬件根因是什么
核心问题：SDC 的硬件根因有哪些类别，各类的特征和严重程度如何？
SDC 的硬件根因分为两大类：永久故障和瞬态故障[^george-mi]。永久故障 （尤其是制造测试逃逸） 是现代 GPU 集群最主导的 SDC 来源。
永久故障指硬件缺陷持续存在、可重复触发。包含三个子类：
- 制造缺陷逃逸 (test escape)：芯片通过生产测试但内含隐性缺陷，在特定工作负载下间歇性产出错误结果。Mitra et al. 量化显示制造测试逃逸率至少超工业目标 10×，约每 1000 个硅器件就有 1 个会产生 SDC[^mitra]。
- 工艺变异与边际性：先进制程下器件参数离散度增大，部分器件处于功能边界，对电压/频率/温度敏感。
- 老化退化：BTI (Bias Temperature Instability)、HCI (Hot Carrier Injection)、EM (Electromigration) 随运行时间累积，将原本健康的硅推向边际。
瞬态故障指非持久、间歇性的单次或偶发错误。包含宇宙射线粒子翻转 (SEU, Single Event Upset)、热效应引发时序违例、电压毛刺。瞬态故障不可预测、不可复现，检测难度高于永久故障。
George et al. 的综述进一步指出：永久故障 （制造测试逃逸） 的威胁远超瞬态故障，因为其持续性和可重复触发特性使同一缺陷在训练过程中反复污染梯度[^george-mi]。
Mercurial core：静默产错但不崩溃的处理器核心
Mercurial core 是 Hochschild et al. (HotOS 2021) 引入的概念，与 CEE (Corrupt Execution Error) 同义[^hochschild]。指 CPU/GPU core 功能表面正常，但在特定条件下间歇性产出不正确的计算结果，不引发任何硬件异常或崩溃。
核心特征：
- 间歇性：同一 core 不一定每次都出错；错误取决于工作负载上下文 （指令序列 / 缓存状态 / 微架构调度）
- 不崩溃：RAS (Reliability, Availability, Serviceability) 机制完全无感知；没有 MCE (Machine Check Exception) / ECC (Error Correction Code) 报警
- 上下文依赖：ITHICA 发现指令序列上下文是故障的主要预测因子，不是执行频率；短测试几乎无法触发[^ithica]
- 非确定性：24% 的检出案例中原始和重复操作产出不同的错误结果；"不一致"是常态而非特例[^ithica]
阿里云在百万级 CPU 上的研究 (Wang et al., SOSP 2023) 给出了精确量化：约 17% 的 CPU 相关故障源自 SDC[^wang-sosp]。同一物理 core 的所有逻辑 core 通常同时受影响；但另一半故障处理器中缺陷影响整个 CPU 所有 core。
Google HotOS'21 首次系统报告了超大规模集群中的 mercurial core 问题，每数千台机器中有几个 mercurial core[^hochschild]。Meta 在数十万台机器中检出数百颗 SDC CPU，认定为"跨代际的系统性问题"[^dixit]。
AI 训练为什么比传统 HPC 更怕 SDC
核心问题：AI 训练场景的 SDC 脆弱性在哪些方面超越传统 HPC?
AI 训练对 SDC 的脆弱性来自三条仅在训练中存在的放大路径，以及低精度计算带来的独特风险。
三条训练特有的 SDC 放大路径
梯度裁剪坍塌：SDC 导致 pre-clipping 梯度 norm 为无穷时，裁剪缩放因子 τ/∞ = 0，所有梯度坍塌至零[^sdc-llm-train]。该步的有效更新仅剩优化器动量——动量方向可能已过时，等于丢弃一次完整的全局 mini-batch。
Adam 动量保留与放大：腐败梯度被 Adam 的一阶动量 (m) 和二阶动量 (v) 缓存，后续多步持续放大其影响[^sdc-llm-train]。极端情况下第二矩 (squared gradient) 可发散至无穷，驱动自适应学习率至零，冻结对应参数不再更新。
分布式聚合单点污染：数据并行中，单 worker 的极端梯度通过 AllReduce 传播，使全局 gradient norm 变无穷。裁剪后所有 worker 的梯度全部为零，数千设备的完整 mini-batch 被丢弃[^sdc-llm-train]。传统 HPC 的 MPI Reduce 操作有中间验证，PyTorch 的 AllReduce 没有。
GPU bit flip 的真实模式：不是单 bit 随机翻转
2026 之前业界 SDC 建模普遍假设"均匀随机单 bit flip"，但 Tung et al. (DSN 2026) 在商业数据中心 GPU 上执行超过 300 万仿真小时的门级 stuck-at fault campaign 后推翻了这一假设[^gpu-error-pattern]:
| 数据点 | 值 |
|---|---|
| 单 bit flip 占比 | <40% (non-special corruptions) |
| 多 bit flip 占比 | >60% |
| NaN/+INF/-INF 占 SDC 结果 | 1.01% (0.39% NaN + 0.49% +INF + 0.13% -INF) |
| 输出被零化 (zeroed output) | 50.68% |
| 合法数值偏移 (silent value shift) | 48.31% |
@tbl-sdc-gpu-bitflip-pattern GPU SDC 的 bit flip 模式与数值表现 (Tung et al., DSN 2026)
99% 的 GPU SDC 产出合法浮点数值，不触发 NaN 检查[^gpu-error-pattern]。标准异常监控 （NaN/INF 检测） 几乎完全无法捕获 SDC。
腐败内存地址还呈现与 GPU warp 执行边界 （32 线程） 对齐的空间相关性：地址腐败以 16/8/4/2 为周期重复，源于并行执行组在上游共享通路的数据排布。正确的建模应放弃均匀随机假设，改用 warp 对齐的分布感知模型。
前向 vs 反向传播：严重度差 10-100×
Ma et al. (ACL 2025) 在真实生产环境中对比健康节点与 SDC 节点，采用 XLA 编译器保证确定性指令排序[^sdc-acl]:
| 度量 | 结果 |
|---|---|
| 梯度噪声-信号比 （最差） | 5.1% |
| 反向 attention mismatch 严重度 | 3.79×10^11 |
| 反向 FFN mismatch 严重度 | 9.63×10^12 |
@tbl-sdc-fwd-bwd-severity 前向与反向传播 SDC 影响严重度对比 (Ma et al., ACL 2025)
反向传播的 mismatch 严重度比前向传播高 10-100×（前向 attention mismatch 仅约 119）。前向传播 SDC 仅产生瞬时 loss spike，反向传播 SDC 造成持久参数漂移——差异的根源在于反向传播将单点 bit flip 沿计算图展开到所有上游参数。
精度格式与 SDC 脆弱性
LLM-PRISM 在 GPT-2 上执行 7,664 次实验，对比不同精度格式的 SDC 行为[^llm-prism]:
| 精度 | SDC 行为模式 | PPL 偏离 | 崩溃率 |
|---|---|---|---|
| FP16 | 静默降级为主 | 最高 600% | 低 |
| FP8 | 二元崩溃或恢复，无中间态 | 崩溃时无法训练 | 41.9% |
| bfloat16 | 指数位更宽，指数翻转概率更高 | 中等 | 中等 |
@tbl-sdc-precision-vulnerability 不同精度格式的 SDC 脆弱性 (LLM-PRISM, arXiv:2604.10390)
FP16 训练最脆弱：PPL 偏离可达 600%，且表面 loss 可能完全正常。LLM-PRISM 实验中有 57% 的运行最终 PPL 偏离不超过 2%, 76% 的运行偏离不超过 20%——大量运行表面可接受的背后存在不同程度的参数漂移[^llm-prism]。FP8 表现为二元行为——要么崩溃要么完全恢复，无中间态，崩溃率 41.9%。
Bit 位敏感性分析进一步揭示：只有指数位 (exponent bits 10-14, 26-30) 的翻转产生可观测影响，尾数位和符号位翻转无可观测差异[^sdc-llm-train]。位 12/13/14/28/29/30 的翻转直接产生 NaN，位 10/11/26/27 的翻转导致 loss 上升但不崩溃，位 10-13 在 attention 计算中可产生 3×10^20 级的极端 logits 值。
训练 vs 推理：本质差异
| 维度 | 推理 | 训练 |
|---|---|---|
| 腐败对象 | 单次前向输出 | 梯度 → 参数更新 → 持久权重漂移 |
| 影响范围 | 单次预测 | 所有后续推理 （腐败写入参数） |
| 检测难度 | 极难 （无梯度信号可监控） | 可通过梯度 norm / RMS spike / attention logits 检测 |
| 恢复方式 | 重跑推理即可 | 回滚 checkpoint 或重算当前步 |
@tbl-sdc-inference-vs-training 推理与训练场景 SDC 影响对比
训练 SDC 比推理危险得多：推理只污染单次输出，训练将腐败写入持久参数，影响后续所有服务请求。
与传统 HPC 的本质差异
AI 训练有三类 HPC 不存在的脆弱性，也缺乏 HPC 的三类检测手段：
| 维度 | 传统 HPC | AI/ML 训练 |
|---|---|---|
| 计算主体 | 线性代数为主 (matmul/FFT) | matmul + 大量非线性 (softmax/GELU/LayerNorm) |
| SDC 检测手段 | ABFT checksum 对 matmul 有效 | ABFT 对非线性操作无效；bfloat16 使 ABFT checksum 失效[^sdc-acl] |
| 精度格式 | FP64，单 bit 权重极小 | bfloat16/FP16/FP8，单 bit 权重极大 |
| 输出评判 | 有解析解或高精度参考 | 无参考解，loss curve 是唯一评判 |
| 分布式验证 | MPI Reduce 有中间验证 | AllReduce 无中间验证，单 worker 腐败污染全局 |
@tbl-sdc-hpc-vs-ai HPC 与 AI 训练 SDC 脆弱性对比
HPC 的 ABFT (Algorithm-Based Fault Tolerance) 在低精度下失效——Ma et al. 实测 ABFT （在 float32 下测试） 仅在 15 个 SDC 节点中的 1 个上可靠检出[^sdc-acl]。原因：bfloat16 的尾数位更少，ABFT checksum 的数值精度不足以区分 SDC 噪声和浮点舍入误差。
大规模集群 SDC 实测数据
核心问题：Google / Meta / 阿里 等超大规模集群的 SDC 实测发生率是多少？
Meta：从 2016 到 2025 的检测体系演进
Meta 的 SDC 研究覆盖数十万台机器。Dixit et al. (2021) 在 18 个月监测期内检出数百颗 SDC CPU，认定 SDC 是"跨代际的系统性问题"[^dixit]。Meta 2025 年 Blog 披露：SDC 发生率已达约 1/1000 器件，远超宇宙射线软错误的历史水平；硬件故障造成了 超过 66% 的训练中断[^meta-blog]。
Meta 构建了三层检测架构[^meta-blog]:
| 层级 | 工具 | 机制 | 覆盖周期 |
|---|---|---|---|
| 离线扫描 | Fleetscanner | 微基准测试在全 fleet 定期排查硬件缺陷 | 每 45-60 天 |
| 在线伴随 | Ripple | 与工作负载 co-locate，毫秒到秒级完成测试 | 数天内覆盖全 fleet |
| 内核级免测试 | Hardware Sentinel | 在内核空间评估应用异常模式，无需主动测试 | 实时 |
@tbl-sdc-meta-detection-layers Meta 三层 SDC 检测架构
Hardware Sentinel 的检测效能比测试类方法高 41%[^meta-blog]。缓解策略涵盖：二分法隔离故障节点、确定性训练验证计算正确性、超频 checkpoint 限制错误传播、梯度裁剪限制数值边界、PVF (Parameter Vulnerability Factor) 评估模型层安全性。
Google: Mercurial core 的首次系统报告
Google HotOS'21 首次系统报告了超大规模集群中的 mercurial core 问题[^hochschild]。关键发现：
- 每数千台机器中有几个 mercurial core
- 反直觉的 DVFS 行为：降低频率有时反而增加故障率，说明电压/频率切换可暴露边际硅
- CEE (Corrupt Execution Error) 率与频率强相关但非单调
- Google 贡献了 CPU 侧 SDC 的奠基性认知，但 GPU 侧数据较少
阿里云：百万 CPU 的精确量化
Wang et al. (SOSP 2023) 在阿里云百万级 CPU 集群上的研究是目前最大规模的 SDC 实证[^wang-sosp]:
- 约 17% 的 CPU 相关故障源自 SDC
- 同一物理 core 的所有逻辑 core 通常同时受影响
- 开发的检测方案比基线开销降低 90%
发生率量级共识
| 来源 | 规模 | SDC 发生率 |
|---|---|---|
| Google HotOS'21 | 超大规模 CPU fleet | 每数千台机器中有几个 mercurial core |
| Meta Dixit et al. 2021 | 数十万台机器 | 数百颗 SDC CPU （跨代际） |
| Meta 2025 Blog | GPU fleet | 约 1/1000 器件 |
| 阿里云 Wang SOSP'23 | 百万 CPU | 17% CPU 故障源自 SDC, 361 DPPM |
| PinDrop HPCA'26 | 超大规模 fleet | 生命周期 SDC 率 0.035% |
| Mitra et al. 2025 | 跨厂商综合 | 约 1/1000 硅器件；测试逃逸率超目标 10× |
@tbl-sdc-fleet-rates 各厂 SDC 发生率数据对比
公开数据的核心局限：各家 SDC 绝对频率 (per device per hour) 为内部数据，公开论文只给相对比较或粗估量级。跨厂商直接对比不可行。
如何检测 SDC
核心问题：现有的 SDC 检测方案有哪些，各自的覆盖率、开销和适用场景如何？
SDC 检测的核心难题：没有硬件异常信号 （不触发 MCE/ECC/parity），且 99% 的 GPU SDC 产出合法浮点数值[^gpu-error-pattern]。检测必须从"看计算结果是否异常"而非"看硬件是否报错"入手。
硬件级：ECC 与局限
ECC (Error Correction Code) 保护存储和传输中的数据，但不覆盖：
- 计算单元内的 bit flip：ALU/FPU 内部的瞬态错误在产生时就已错，ECC 在写入寄存器前无法检测
- 多 bit flip：3+ bit flip 超出 SECDED (Single Error Correction, Double Error Detection) 能力
- bfloat16 计算路径：部分 GPU 的 bfloat16 数据路径不经过 ECC
ECC 是必要但不充分的第一道防线。
学术检测方案对比
| 方案 | 会议/年 | 检测率 | 开销 | 机制 |
|---|---|---|---|---|
| Orthrus | SOSP'25 | 87% （单核） | 1 core/机器 | 资源适配计算验证，首个在线检测系统[^orthrus] |
| ITHICA | 2026 | vs 基线 +39%, vs SiliFuzz +69% | 1.17-1.52× perf | LLVM IR 指令级检查，上下文驱动[^ithica] |
| Dr. DNA | HotInfra'24 | 95% （多数 100%） | <1% 内存，<2.5% 延迟 | 神经元激活分布签名 + PVF[^hotinfra] |
| 轻量检测 | ICLR'26 提交 | 未给具体率 | "低时间开销" | 集合通信前梯度统计 + 散度判据[^lightweight] |
| PinDrop | HPCA'26 | 超大规模特征化方法 | 连续高频测试 | 方法论而非检测方案[^pindrop] |
@tbl-sdc-detection-academic 学术 SDC 检测方案对比
Orthrus (SOSP'25) 是首个面向处理器静默错误的在线检测系统。机制：用可变数量的 core 重新执行计算并比较结果，在检测精度与资源开销之间动态平衡。局限：87% 不是 100%；对瞬态故障 (SEU) 的覆盖率不明确。
ITHICA (Intra-THread Instruction Checking Approach, 2026) 的核心假设是"缺陷产生上下文依赖的非确定性错误，而非可重复错误"[^ithica]。通过 LLVM IR 编译 pass 插入指令复制、输出比较和错误上报，将任意软件转化为功能硬件测试。比 SiliFuzz （Google 的生产 SDC 检测工具） 多检出 69% 的缺陷服务器。
Dr. DNA (Meta, HotInfra'24) 从神经元激活分布 (Distribution of Neuron Activations) 提取 SDC 签名[^hotinfra]。配合 PVF 指标定位最脆弱参数：上层 MLP 最脆弱 （单 bit flip 造成 0.4% 错误率），稀疏嵌入矩阵最安全。在 10 个模型上平均检测率 95%，内存开销 <1%，延迟开销 <2.5%。
AI 训练专用：梯度异常检测
SDC 在训练中的症状可通过四个度量诊断[^sdc-llm-train]:
| 度量 | SDC 特征 | 检测灵敏度 |
|---|---|---|
| attention logits 最大值 | 突然跳至 3×10^20 （正常时平滑演化） | 最高 — SDC 强信号 |
| pre-clipping gradient norm | 无穷 → 裁剪坍塌至零 | 高 — 但需区分超参数问题 |
| RMS 更新峰值 | 尖锐 spike 后 loss bump 持续 30-40 步 | 高 — 可用统计阈值自动检测 |
| 参数差异 L2 norm | 延迟发散 （step 450+ 才偏离） | 低 — 滞后指标 |
@tbl-sdc-gradient-symptoms 训练中 SDC 的四度量诊断体系
RMS 更新峰值检测的公式[^sdc-llm-train]:
$$R_t = \max_{\text{groups}} \left(\text{mean}(U_{t,p}^2)\right)^{1/2} \label{eq:sdc-rms-update} \end{equation}$$ 异常判定： $$\begin{equation} \Delta R_t > \frac{\mu}{\alpha \times \sqrt{\Delta G_t}} \label{eq:sdc-detection-threshold} \end{equation}$$ 其中 μ 为 warmup 期 ΔR 的经验均值，α ∈ (0,1] 为灵敏度参数，ΔG_t 捕获正梯度 norm 跳变作为辅助信号。α = 0.05 在灵敏度和重算开销间取得最佳平衡[^sdc-llm-train]。 检测到异常后的恢复路径：重算当前训练步。由于硬件调度非确定性，重算值与腐败值不同则确认 SDC 存在。重算后 eval loss 恢复至无故障基线，每次未缓解 SDC 损失约 30-40 训练步[^sdc-llm-train]。检测加重算的吞吐开销约 1%。 ### OCP 行业标准检测框架 OCP (Open Compute Project) v1.1 白皮书 （2025-08, AMD/ARM/Google 等 7 家联合） 提出了行业标准的两阶段检测框架[^ocp]: - **第一阶段 （制造端）**：基于 ML 的异常检测，在 foundry/制造阶段筛选可疑器件 - **第二阶段 （部署端）**：实时健康监控 (Real-Time Health Monitoring)，在 fleet 运行中持续检测 ProteanTecs 等厂商已提供该框架的商业实现，通过片上 telemetry + ML 异常检测实现从制造到部署的全生命周期覆盖[^proteantecs]。 ## 如何缓解 SDC **核心问题**：检测到 SDC 后怎么恢复，以及如何从系统层面降低 SDC 的影响？ ### 恢复路径：重算 > 回滚 checkpoint 回滚的粒度问题：回滚到上一个 checkpoint 丢弃了 checkpoint 到故障时刻之间的所有有效训练。相比重算 （仅丢弃当前步），回滚的期望损失 = checkpoint 周期的一半。 SDC 检测 + 选择性重算比 checkpoint 回滚更优：检测到异常后只重算当前步 （损失 1 步），不触发全量 checkpoint 加载。RMS 检测 + 重算方案在 LLaMA 60M/350M/1.3B 上验证：重算后 eval loss 完全恢复至无故障基线，吞吐开销约 1%[^sdc-llm-train]。 ### Lemon node 主动屏蔽 Lemon node 指故障率显著高于群体的"问题节点"。Kokolis et al. 发现 lemon node 是训练中断的主要贡献者。应对策略： - **离线检测 + 隔离**：Fleetscanner 定期扫描发现 SDC 节点，从训练资源池移除 - **在线伴随检测 + 降级**：Ripple 在数天内覆盖全 fleet，检出后标记为"不可调度" - **确定性训练验证**：同一计算在多个设备上执行并比对结果，不一致则标记可疑节点[^meta-blog] ### 容错训练 SPARETRAIN (ICLR 2026) 复用 activation checkpointing 的中间结果实现低成本 DMR (Dual Modular Redundancy)，开销 3-14%，比 naive DMR 吞吐提升 12-35%[^sparetrain]。但这个开销仍然不适合默认开启，更适合对 SDC 已知敏感的特定训练阶段。 ### 检测与缓解的选择逻辑 | 场景 | 推荐策略 | 理由 | |------|---------|------| | 大规模 pretraining （100B+ 模型） | 梯度异常检测 + 选择性重算 | 1% 开销，30-40 步恢复；训练周期长，SDC 几乎必然发生 | | 中小规模 finetuning | 两级检测：在线粗筛 + 离线精查 | 开销更低；SDC 影响因任务而异 | | 推理部署 | 周期性离线检测 + 多副本投票 | 无梯度信号可监控；推理重跑开销低 | | SDC 高发硬件代际 | DMR 或容错训练 | 硬件发生率压倒检测覆盖率 | @tbl-sdc-strategy-selection 不同场景的 SDC 检测与缓解策略选择 ## 开放问题与 Limitations **核心问题**：当前 SDC 研究的盲区在哪里，本文覆盖范围有哪些约束？ ### 开放问题 - **网络层 SDC 数据稀薄**：IB/RoCE/NIC 的 SDC （静默包损坏 / CRC 漏检 / 路由表 bit flip） 公开研究和实测数据极少，本文无法系统分析 - **推理阶段 SDC 影响几乎空白**：已有资料几乎全集中在训练；推理 SDC 的长尾影响 （如单个腐败输出对下游决策链的级联效应） 无系统研究 - **检测方案的 false positive/negative 率系统性对比缺失**：现有论文各用自己的评估集和 SDC 注入模型，直接对比不可靠 - **具体检测代码基本不开源**：Orthrus / ITHICA / Dr. DNA 的论文描述层之上缺少可复现的实现 - **跨硬件代际 SDC 模式演化**：从 7nm → 3nm 制程，SDC 的发生率和模式如何变化，无公开追踪数据 ### Limitations - **绝对发生率不可得**：各家硬件 SDC 频率 (per device per hour) 为内部数据，正文用"相对比较"代替"绝对数字" - **工业实测数据集中于 Meta**：训练场景 70% 的公开实测案例来自 Meta （blog + 论文）；Google 贡献 CPU 侧奠基论文但 GPU 侧数据较少；阿里云数据为 CPU 视角。跨厂商 GPU SDC 对比受限于数据可用性 - **GPU 数据 vs CPU 数据**：CPU 侧 SDC 研究更成熟 （Google/阿里/Intel），GPU 侧 SDC 研究 2025-2026 才密集出现，部分结论可能随数据积累修正 ## 与其它章节关系 - **[01-总览.md](./01-总览.md)**: SDC 是集群可靠性的横切维度，与 GPU/网络/软件故障并列。MTBF 和 ETTR 公式在此定义 - **[02-straggler.md](./02-straggler.md)**: Straggler 是"慢但正确"的软故障，SDC 是"快但错误"的硬故障——检测方法完全不同 - **[03-async-checkpoint.md](./03-async-checkpoint.md)**: SDC 检测 + 重算比 checkpoint 回滚更优 （损失 1 步 vs P/2 步）；但 checkpoint 仍是 SDC 污染的最终防线 （腐败写入参数后回滚是唯一恢复手段） ## Takeaway | 知识点 | 核心结论 | |--------|---------| | SDC 根因 | 永久故障 （制造逃逸/老化） 主导，约 1/1000 器件；瞬态故障不可预测 | | Mercurial core | 间歇性静默产错、不崩溃、上下文依赖；阿里云百万 CPU 中 17% CPU 故障源自 SDC | | GPU SDC 模式 | 99% 产出合法浮点值；多 bit flip >60%; warp 对齐空间相关性；NaN 检查完全无效 | | AI 训练放大路径 | 梯度裁剪坍塌 + Adam 动量放大 + 分布式聚合单点污染；ABFT 在低精度下失效 | | 训练脆弱性量化 | 反向传播严重度 10-100× 于前向；FP16 PPL 偏离 600%; FP8 崩溃率 41.9%；指数位翻转最关键 | | 检测与恢复路径 | ECC → Orthrus 87% → Dr. DNA 95% → 梯度 RMS spike （~1% 开销）；检测+重算 > checkpoint 回滚 （每次 SDC 损失 30-40 步） | | 数据局限 | 网络 SDC 稀薄；推理 SDC 空白；绝对值不可得；工业数据 Meta 单源集中 | | 趋势 | "检测 → 选择性重算"替代全面冗余；OCP 两级框架 （粗筛 + 精查） 降低常态开销 | ## 参考资料 [^george-mi]: George et al., *Silent Data Corruption in AI: A Growing Challenge*, IEEE Micro vol.46 no.1, 2026. https://www.computer.org/csdl/magazine/mi/2026/01/11311359/2cEUqE5eDsY [^hochschild]: Hochschild et al., *Cores that don't count*, HotOS 2021. https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s01-hochschild.pdf [^dixit]: Dixit et al., *Silent Data Corruptions at Scale*, arXiv:2102.11245, 2021. https://arxiv.org/abs/2102.11245 [^wang-sosp]: Wang et al., *Understanding Silent Data Corruptions in a Large Production CPU Population*, SOSP 2023. https://yangwang83.github.io/papers/sosp2023-Wang.pdf [^mitra]: Mitra et al., *Silent Data Corruption by 10x Test Escapes Threatens Reliable Computing*, arXiv:2508.01786, 2025. https://arxiv.org/abs/2508.01786 [^orthrus]: Qiao et al., *Orthrus: Efficient and Timely Detection of Silent User Data Corruption*, SOSP 2025. https://dl.acm.org/doi/10.1145/3731569.3764832 [^ithica]: *ITHICA: Intra-Thread Instruction Checking Approach for SDC Detection*, arXiv:2605.15638, 2026. https://arxiv.org/html/2605.15638v1 [^hotinfra]: Jiao et al., *Silent Data Corruptions in AI Systems: Evaluation and Mitigation*, HotInfra 2024. https://hotinfra24.github.io/ [^lightweight]: Li et al., *Lightweight Detection of Silent Data Corruption in Distributed Deep Learning*, ICLR 2026 submission. https://openreview.net/forum?id=66Xvcc6N0b [^pindrop]: *PinDrop: Breaking the Silence on SDCs in a Large-Scale Fleet*, HPCA 2026. https://2026.hpca-conf.org/details/hpca-2026-main-conference/74/PinDrop-Breaking-the-Silence-on-SDCs-in-a-Large-Scale-Fleet [^sdc-llm-train]: *Exploring SDC as a Reliability Challenge in LLM Training*, arXiv:2604.00726, 2026 (TU Berlin / CCGrid 2026). https://arxiv.org/abs/2604.00726 [^sdc-acl]: Ma et al., *Understanding Silent Data Corruption in LLM Training*, ACL 2025 (arXiv:2502.12340). https://arxiv.org/abs/2502.12340 [^gpu-error-pattern]: Tung et al., *The Anatomy of Silent Data Corruption: GPU Error Pattern Study*, DSN 2026 (arXiv:2605.04213). https://arxiv.org/abs/2605.04213 [^llm-prism]: *LLM-PRISM: Characterizing SDC from Permanent GPU Faults in LLM Training*, arXiv:2604.10390, 2026. https://arxiv.org/html/2604.10390v1 [^meta-blog]: Meta Engineering, *How Meta keeps its AI hardware reliable*, 2025-07-22. https://engineering.fb.com/2025/07/22/data-infrastructure/how-meta-keeps-its-ai-hardware-reliable/ [^ocp]: OCP, *Silent Data Corruption in AI*, v1.1, 2025-08. https://www.opencompute.org/documents/sdc-in-ai-ocp-whitepaper-ver-1-1-final-pdf [^sparetrain]: *SpareTrain: Fault-Tolerant LLM Training via Low-Cost DMR*, ICLR 2026. https://openreview.net/forum?id=kDeS8jpeiZ [^proteantecs]: ProteanTecs, *Outsmarting SDC with Two-Stage Detection*. https://www.proteantecs.com/resources/whitepaper-outsmarting-silent-data-corruption-in-ai-processors-with-two-stage-detection ## 延伸阅读 - EDN, *Addressing hardware failures and SDC in AI chips*, 2025-04. https://www.edn.com/addressing-hardware-failures-and-silent-data-corruption-in-ai-chips/ - ProteanTecs, *Outsmarting SDC with Two-Stage Detection*. https://www.proteantecs.com/resources/whitepaper-outsmarting-silent-data-corruption-in-ai-processors-with-two-stage-detection - Adept AI, *The Adventure of the Errant Hardware*, 2024. https://www.adept.ai/blog/sherlock-sdc/ — SDC 致训练 loss spike 的诊断实战 - Meta, *Parameter Vulnerability Factor (PVF) for AI SDC*, 2024. https://engineering.fb.com/2024/06/19/data-infrastructure/parameter-vulnerability-factor-pvf-ai-silent-data-corruption/$$