一、背景
随着 LLM 训练规模迈向万亿参数，硬件不再被视为绝对可靠的基石。静默数据损坏（Silent Data Corruption, SDC）已成为当前 AI 基础设施面临的最严峻威胁之一，本文中，我们简单梳理 SDC 相关工作，以便能更好理解 AI Infra 中的 SDC。
更多内容可以参考我们之前的文章：
二、摘要
随着 LLM 训练规模的扩大，SDC 的影响也逐渐凸显。[2502.12340] Understanding Silent Data Corruption in LLM Training [1] 中，作者首次通过对比健康节点与存在 SDC 的异常节点，探究真实场景中 SDC 对语言模型训练的影响。
借助云计算平台，作者获得了被自动化集群管理系统从生产环境中剔除的异常节点的访问权限。作者在三个层面隔离并分析了 SDC 对这些节点的影响：子模块计算层面、单次优化器迭代层面以及训练周期层面。研究结果表明，SDC 对计算的影响因异常节点而异。在多数情况下，SDC 对子模块计算和梯度的干扰相对较小，但它会导致模型收敛至具有不同权重的不同最优解，甚至引发训练损失骤增。
三、引言
3.1 SDC 定义
在硬件可靠性领域，可以按照下述方式对系统内硬件故障的可能结果进行分类。如下图所示，当发生单比特故障时（比如由宇宙射线或 α 粒子引发的故障），可能产生以下几种结果：
良性故障（Benign fault）：由 ECC 等硬件机制静默修复，不影响结果。
故障已纠正（Fault corrected）：故障被错误检测/纠正机制（如 ECC）发现，系统在未影响程序结果的前提下完成纠错。
可检测不可恢复错误（Detected unrecoverable error，DUE）：由奇偶校验等发现但无法修正，导致系统停机。需区分伪 DUE（不影响结果）与真实 DUE。
静默数据损坏（Silent data corruption，SDC）：逃避所有检测机制导致错误输出，是 LLM 训练中最隐蔽且致命的故障。
在 NVIDIA GPU 上有 Xid 相关错误码对应 ECC Error：
Xid 94：Contained ECC Error，表示 ECC Error 抑制成功，只影响当前触发 ECC Error 的程序，不应 GPU 上的其他程序。
Xid 95：Uncontained ECC Error，表示 ECC Error 抑制失败，影响当前 GPU 上的所有程序。
3.2 SDC 根因
现代硬件中有两种典型故障模型：永久性故障（Permanent Faults）与瞬态故障（Transient Faults），常常因错误检测机制不足或初始表现形式未能触发常规警报而被忽略。
3.2.1 永久性故障（Permanent Faults）
永久性故障源于硅片物理缺陷（如固定型故障、小延迟缺陷）。在 AI 加速器中，由于追求极致吞吐量，系统常采用激进的电压/频率调节，这进一步压缩了安全阈值，使得原本在出厂测试中“逃逸”的小延迟缺陷在特定负载或环境下被触发：
固定型故障模型：即信号被永久钳位在逻辑“1”或“0”状态，相对比较容易检测。
间歇性故障：仅在特定工作条件（如电压骤降、温度波动或高频切换操作）下显现的故障。故障激活可能依赖于具体情境而非持续存在，因此检测难度显著增加。
小延迟缺陷（Small-delay defect）：制造缺陷、工艺偏差或渐进性老化等，晶体管或互连线偶尔无法在预期时序窗口内完成翻转，可能导致单比特错误。
3.2.2 瞬时故障（Transient Faults）
瞬态故障可能由宇宙射线引发的中子撞击、α 粒子或其他环境因素导致。这类单粒子翻转事件通常具有非破坏性，但会悄然改变数据值或逻辑状态。
尽管在传统 CPU 中，ALU 等计算单元受瞬态故障影响较小，但 AI 加速器往往将更大比例的芯片面积分配给这些密集型算术单元，以最大化矩阵密集型运算的吞吐量。这种架构特性与激进的性能优化策略相结合，使得寄存器文件和中间缓冲区等组件可能成为新的故障点。
此外，AI 加速器往往采用更低 Bit 的计算（比如 16Bit、8Bit）来提升性能和能效，这也对故障恢复产生新的挑战，对容错能力的影响也是亟待深入研究的领域：
一些研究表明，低 Bit 可能增加对特定类型位级损坏的敏感性。
还有一些研究表明，低 Bit 可限制误差的绝对量级，在特定故障场景下提升系统的恢复能力。
3.3 对 AI 场景的影响
AI 执行流水线跨越多个抽象层次——从用 Python 编写的高级模型代码，到机器学习框架，再到编译工具链，最终延伸至硬件驱动程序和运行时环境。每个层级都引入了优化的可能，例如算子融合、图变换和量化可能改变模型在更高层级的运行时行为，从而增加调试和故障归因的复杂性。
由于这种分层执行模型，硬件层级引入的故障可能需要经过多次转换传播才会显现。例如，融合算子中的低级数值误差可能仅在多次迭代后才表现为训练损失的偏离，或导致推理输出的细微偏移，从而躲避标准正确性检查。
随着 AI 框架的持续优化，AI 加速器的不断迭代，SDC 未被检测的可能性也随之增加。在软件栈每个层级部署 SDC 感知工具与测试策略也就更加必要，同时需要通过接口级检查实现跨抽象边界的故障隔离。
此外，大多数工作研究 SDC 对模型 Inference 的影响，而很少有工作研究 SDC 对模型 Training 的动态影响。尤其是当前 LLM 训练场景，往往需要几千甚至数万的 AI 加速器，任何单一设备故障都可能导致故障扩散到整个任务，导致大量的资源浪费。
3.4 AI 场景的 SDC 案例
Google 在 Gemini 训练期间，每隔一两周就会发生一次影响训练的 SDC 事件 ( [2312.11805] Gemini: A Family of Highly Capable Multimodal Models [3])。如下图所示：
Meta 在 LLaMA 3 模型训练中，54 天的预训练中 SDC 导致了 6 次任务中断，如下图所示：
字节也在（[2509.16293] Robust LLM Training Infrastructure at ByteDance [4]）中反复提到了 SDC 的问题，比如训练中的一个 SDC 故障，通过 8 小时的离线压测才识别到故障机器。如下图 Figure 7 所示，也提到了 SDC 导致通信 Hang 的问题，非常隐蔽，排查也很困难：
美团在 Longcat 大模型训练中也多次提到 SDC 检测（[2509.01322] LongCat-Flash Technical Report [5]），比如其发现 FlashAttention 梯度的 Backward 计算对 SDC 很敏感，因此添加了相应的 SDC 探测机制：
NVIDIA 也在 （Version 535.288.01(Linux) :: NVIDIA Data Center GPU Driver Documentation [6]）中提到过，H100 曾因 mma.sp (Sparsity) 指令缺陷导致间歇性 SDC，已通过驱动更新修复。
3.5 最佳实践
缓解 SDC 需采用包含检测与恢复技术的多层次策略。这些容错机制根据其采用的冗余类型可分为三大类别：
空间冗余：通过复制硬件或计算过程进行结果交叉验证。
时间冗余：随时间重复操作以检测瞬态异常。
信息冗余：在数据流与硬件结构中嵌入附加信息（如校验和、纠错码），用于故障检测和/或纠正。
这些机制可应用于错误检测或系统恢复。恢复过程本身可呈现两种形式：
后向错误恢复：指系统回滚至先前已知的良好状态（例如检查点恢复）。
前向错误恢复：指系统在检测到错误后原地修正并继续执行。
四、方案
4.1 概览
为了研究生成环境中 SDC 的影响，作者从真实环境收集了一些不健康节点，然后通过 3 个粒度进行了相应研究。
4.1.1 节点收集
大规模 AI 集群交付时都会进行一系列的交付测试，包括所有节点的集合通信压力测试、计算单元压力测试，以及一系列真实模型的压力和基准测试，其中的训练输出也会与预先计算的 Golden Truth 进行对比。与 Golden Truth 的差异或非确定性行为都表明节点可能存在 SDC。为了防止硬件随时间而退化，也可能在节点存在可疑问题或者周期性的进行上述测试。
如下图 Figure 1 所示，经过该流程可以筛选出一系列疑似存在 SDC 的不健康节点和健康节点，每个类别包含 15 个节点，其中不健康节点被分配了唯一的标识（Node 1 到 Node 15）。
4.1.2 关键研究问题
为了更好地理解 SDC 的影响，作者主要研究了 3 个 问题（RQ）：
RQ1：SDC 对 Transformer 子模块计算结果有什么影响？
RQ2：SDC 对单个优化器 Step 中模型权重梯度的影响是什么？
RQ3：在多个训练 Step 中，SDC 对模型质量的累积影响是什么？
为了将 SDC 引起的不正确计算结果与 Ground Truth 进行比较，作者将不健康节点和一个健康节点一一配对，并使用完全相同的训练配置在每个节点上训练相同的模型。此外，还采用 XLA 编译器来确保完全确定性的指令排序，从而隔离非 SDC 带来的非确定性误差。比如使用 PyTorch 训练时可以从如下几方面保证：
随机种子：random 库、numpy 库，torch，torch.cuda 的随机种子等。
CUDNN 确定性：torch.backends.cudnn.deterministic = True 和 torch.backends.cudnn.benchmark = False。
PyTorch 的确定性算法：torch.use_deterministic_algorithms(True)。
环境的一致：不同的硬件，GPU Driver，CUDA Version 也可能引入误差。
DataLoader：DataLoader 也可能引入顺序的不一致，需要保证分布式场景 DataLoader 的不一致性。
NCCL 通信： NCCL 中的 AllReduce 可以通过指定算法、协议、拓扑等最大程度降低不确定性，但是依然无法严格保证。
由于 SDC 误差可能会随计算累积，需要用健康节点上的真实结果修正不健康节点上的误差，以隔离不同层面的 SDC 影响。具体来说，作者为 RQ1 和 RQ2 设计了两种同步机制。
计算同步（Computation Synchronization）。针对 RQ1， 采用 lock-step 并行模式，如下图 Figure 2 所示。对于不健康节点和健康节点上每一对相同的 TP Rank：
Forward 中，在每个子模块（自注意力或 FFN）的前向计算之后、序列并行的 reduce-scatter 操作之前，进行通信并比较输出值。避免了某些 Rank 上的错误值在通信后扩散到其他 Rank 的 Tensor 分片上。然后，用健康节点的值覆盖不健康节点上的值（红箭头），以防止 SDC 误差累积到下一个子模块。
Backward 中，在每个子模块的反向计算之后、reduce-scatter 操作之前，比较输入梯度（蓝箭头），并覆盖梯度值，以防止误差通过反向传播累积。
参数同步（Parameter Synchronization）。针对 RQ2，在每个训练步骤结束时进行参数同步。在执行一个优化器步骤后，将更新后的模型参数从健康节点广播出去，覆盖不健康节点上的参数。通过这种方式，两个节点在下一个优化器步骤开始时都拥有相同的参数。
除此之外，作者假设在不健康节点和健康节点之间传输 Tensor 时不会发生 SDC。
首先，实验中使用的所有节点都一致通过了集合通信的压力测试。
其次，同步机制中使用的通信原语不涉及任何计算单元。
最后，跨网络通信使用了奇偶校验或纠错码。
为了避免在健康节点和不健康节点之间进行 Tensor 比较的算术运算期间发生 SDC，总是在健康节点上进行比较计算。
4.2 RQ1 实验
4.2.1 实验配置
模型为类似 LLaMA3 8B 的 Decoder Only Transformer 模型，16 层，Hidden 维度 H=4096，使用 TP 将其放在一个节点内。主要关注 4 中类型的子模块计算：
SelfAttention 模块的前向计算 (FWD/ATTN)
FFN 模块的前向计算 (FWD/FFN)
SelfAttention 模块的反向计算 (BWD/ATTN)
FFN 模块的反向计算 (BWD/FFN)
对于模型中的子模块计算 f，将 f’i(xt,j) 定义为 Microstep j 时不健康节点 i 的 TP Rank t 上计算出的 Tensor，fi(xt,j) 则为对应的健康节点的对应输出。为了量化 f’i(xt,j) 和 fi(xt,j) 之间的差异，定义了两个指标：
不匹配率：在 Microstep j 时计算不健康节点 i 上子模块 f 的不匹配频率，如下图公式（1）所示
在上述基础上对 Transformer Layer 进行平均，并报告每种子模块 F 的聚合不匹配率，如下图公式（2）所示；
不匹配严重程度：相对差异中非零元素的平均值。在所有 TP Rank 上取最大值来计算不匹配严重程度，如下图公式（3）所示：
在上述基础上，通过在 Transformer Layer 之间取最大值来报告每种类型子模块计算 F 的不匹配严重程度，如下图公式（4）所示：
4.2.2 结果
如下图 Table 1 展示了不同子模块计算的不匹配频率。可以看出，SDC 对子模块计算的影响在不同的不健康节点差异很大，例如，Node 10 和 Node 11 具有很高的不匹配频率，而 Node 2 和 Node 3 在此设置中未显示任何 SDC 发生：
如下图 Figure 3 所示，为 Node 7 和 Node 14 在 SelfAttention 模块 Forward 计算的不匹配频率，可以看出 SDC 在时间上并非均匀发生，不匹配频率在各个 Step 之间通常具有非常大的方差。
如下图 Figure 4 所示，Node 10 和 Node 11 在最初的几个 Step 不匹配频率比较高，在后续训练 Step 中频率有所降低：
如下图 Table 2 所示，展示了不同不健康节点上子模块计算在优化器 Step 中的最大不匹配严重程度，可以看出，SDC 会导致计算结果中某些 Tensor 值产生巨大的差异。例如，在 Node 9 中，不匹配严重程度超过 100，意味着 SDC 可能导致退化的 TP Rank 在某些 Microstep 上产生完全截然不同的结果：
4.3 RQ2 实验
4.3.1 实验配置
使用之前介绍的参数同步机制，在 Step j 的 Forward 和 Backward 完成后，计算第 i 个不健康节点上的模型权重梯度 g’i,j 与健康节点上对应 gj 之间的元素级差异的 L2 范数。在优化器 Step 后，使用参数同步机制覆盖不健康节点上的模型参数，对应模型层数换为 32 层。使用最坏情况噪声信噪比（Worst Case Noise-to-Signal, WCNTS）来衡量 SDC 引起的梯度噪声有多显著，如下图公式（5）所示。
4.3.2 结果
如下图 Figure 5 展示了不健康节点的梯度差异的 L2 范数和梯度的 WCNTS 比率。可以看出，在不健康节点上计算的梯度与在健康节点上计算出的梯度偏差极小。在 Node 11 上的最坏情况下，梯度差异的 L2 范数是真实梯度的 5.1%，表明 SDC 在梯度中引入的噪声相对于真实梯度来说还是比较小的。
4.4 RQ3 实验
4.2.1 实验配置
为了更好理解不健康节点上学习到的表示和模型决策边界会有如何不同，作者设计了从头预训练和 SFT 模型的实验：
实验 I：评估预训练期间，累积的 SDC 误差导致学习到的模型与真实情况有多大差异？主要评估训练损失和参数差异。
实验 II：模型在下游任务 SFT 时，SDC 将如何影响模型效果。通过 SFT，在 6 个多项选择问答任务（CosmosQA，MathQA，ScienceQA，OpenbookQA，BoolQ 和 RACE）上微调 Mistral-7B-v0.3。每个任务上都使用固定的随机种子混洗训练数据集，主要报告分歧百分比（Disagreement Percentage, DP），评估在测试集上预测差异的百分比。
4.2.2 结果
实验 I 结果：如下图 Figure 6 所示，展示了预训练期间不健康节点上的参数差异、梯度范数和训练损失。尽管每个不健康节点上的训练损失与健康节点几乎完全相同，但不健康节点上的模型权重逐渐偏离健康节点，表明 SDC 在推动模型走向不同的局部最小值。需要说明的是：
Node 13 在第 450 步之前没有显示出参数差异，这表明在此期间没有发生 SDC，与之前现象相互印证。
尽管不健康节点产生的 SDC 频率和严重程度不同，但大多数不健康节点上的参数差异增加率是相似的。这表明参数漂移的速率更可能由尖锐的损失曲面（sharp loss surface）驱动，而不仅仅是 SDC。
实验 II 结果：如下图 Table 3 所示，可以看出，在大多数不健康节点上 SFT 的模型明显优于未 SFT 的基础模型，并且与在健康节点上 SFT 的模型性能相似。与实验 I 的发现一致，这再次肯定了不健康节点上的 SDC 会推动模型走向不同的局部最小值。
不过 SDC 不一定对模型 SFT 无害，如下图 Figure 7 展示了在 CosmosQA 上 SFT 期间的训练损失。可以看出，某些不健康节点上可能会出现显著的损失尖峰（loss spikes）。在 Node 4、Node 6 和 Node 7 上，损失尖峰发生在微调中间，之后训练又稳定下来，使得最终模型仍具有良好性能。但在 Node 6 上，损失尖峰发生在微调即将结束时，导致结果模型在 CosmosQA 上的测试准确率为零（如上图 Table 3 红框所示）。
五、参考链接
https://arxiv.org/abs/2502.12340
https://www.opencompute.org/documents/sdc-in-ai-ocp-whitepaper-final-pdf
https://arxiv.org/abs/2312.11805
https://arxiv.org/abs/2509.16293
https://arxiv.org/abs/2509.01322
https://docs.nvidia.com/datacenter/tesla/tesla-release-notes-535-288-01/index.html