要点
- 静默数据损坏是硬件算出一个看起来合理、却是错的结果，常见于张量核乘法，它不报错，却可能进入每一份副本的权重。
- 在最长使用 16000 张 H100、历时 54 天的 Llama 3 405B 预训练中，Meta 把 419 次意外作业中断里的 6 次归到静默数据损坏，而且只统计了中断作业并被追溯到这一原因的情况。
- SageMaker HyperPod 已经会替换报告 GPU 错误或未通过深度健康检查的节点。这类工具仍会漏掉静默损坏，因为硬件什么也不上报。
- AWS 在训练循环内加了三项检查：对 NaN 和 Inf 梯度的检查；环形重放，即重算另一节点的微批次并比较损失和梯度指纹；以及优化器更新后的权重量指纹。
- 在 4 台、随后 3 台 ml.p5.48xlarge 实例上，15320 次无故障审计步里报警次数为 0，按 95% 置信度上界约为每 5100 步不超过 1 次。大多数注入故障被抓住。但用默认内核审计的权重梯度故障，50 步内没有报警，通过检查的检查点仍被标为干净。
2026年11月11日，Amazon Web Services 的工程师介绍了如何在 SageMaker HyperPod 上的训练中发现静默数据损坏。集群本来就会换掉报告 GPU 故障的节点。更难的情况是，一张 GPU 返回略有偏差的数字，并不报错，训练还能继续数小时，模型却已经受损。作者的判断是：检测必须来自训练作业本身。
[1][2]什么是静默损坏，常见检查为什么看不见
静默数据损坏发生在计算单元算出一个看起来合理、却是错的值时。常见嫌疑是张量核里的乘加通路，也就是大规模训练最频繁使用的那类运算。与内存不同，这条算术路径通常没有纠错码或奇偶校验。错误数字可以进入激活和梯度，再在全归约、也就是各 GPU 平均梯度的那一步之后，写进每一份副本的权重。损失曲线看起来仍可能长时间正常。
AWS 博文引用了 Meta 的 Llama 3 报告，编号为 arXiv 2407.21783。在最长使用 16000 张 H100、历时 54 天的 405B 预训练中，Meta 把 419 次意外作业中断里的 6 次归到静默数据损坏。那只包括已经中断作业、并被追溯到这一原因的情况。若损坏悄悄削弱了检查点却没有停掉作业，就不会出现在这个计数里。
HyperPod 已经会监视 GPU 错误、运行深度健康检查，并替换不良节点。博文把缺口写得很清楚。ECC 保护的是内存，不是算错的张量核结果。Xid 错误只在 GPU 自己发现故障时才会触发。类似 NVIDIA DCGM 的深度健康检查是在空闲节点上跑的，可能漏掉只在当前作业的操作数、温度或时序下才会出现的缺陷。
[1][2]三项检查，以及一次受控试验
作者在 PyTorch DistributedDataParallel 循环里加入三项检查。其中一项触发后，他们把可疑的进程序号映射到节点，并让 HyperPod 替换该节点。
第一项检查在优化器运行之前，于出错的当步查看每个进程的梯度以及归约后的梯度，寻找 NaN、Inf 和溢出。
第二项是环形重放。在审计步上，每张 GPU 重算来自另一节点的一个微批次，也就是一小批训练样本。它按比特比较损失，并用指纹比较梯度。指纹是对比特的一种简短签名。这项检查针对的是有限的错误数值。博文提醒，如果负责重放的 GPU 本身有故障，单次重放可能误伤健康的进程。他们的配对方式就是为了发现这种情形。
第三项在优化器更新之后、写入检查点之前比较权重量指纹，以免把损坏的存储或一次错误更新写成干净的快照。
这些证据来自受控的故障注入研究，并不是在前沿大模型训练中抓到静默损坏的实录。他们使用由 Amazon EKS 编排的 SageMaker HyperPod 集群，先是 4 台、随后 3 台 ml.p5.48xlarge 实例，每台有 8 张 80GB 的 NVIDIA H100。模型是一个 9.53 亿参数的 Llama 风格解码器，训练数据是可重建任意微批次的合成拷贝任务。运行环境是 PyTorch 2.9.0 和 CUDA 13.0，权重和优化器状态为 32 位浮点，计算使用 16 位 brain-float 自动混合精度。
故障被注入 16 个解码块中第 8 块的 MLP 下投影。在 4 实例集群上，前向输出里一次性出现的 NaN 被第一项检查在当步抓住，即使该步不是审计步，这一步也没有被应用。重复出现的有限前向故障，包括某个 16 位元素的比特翻转，以及对一列输出乘以 1.1，都在下一次审计时被第二项检查点名。权重中的比特翻转和相互抵消的成对改动被第三项检查抓住，包括张量的普通比特求和并未变化的情况。在 3 实例的试验中，报警、步数和被点名的进程都相同。
他们还测量了误报。六种无故障日程合计 15320 次审计步和 3080 次权重检查，报警次数为 0。在一次事件都没有发生时，常用统计上界给出每审计步误报率在 95% 置信度下约为不超过 1/5100。
[1][2]必须和成功放在一起看的漏检
有一项结果应当和上述抓住故障的记录放在一起看。当一个把某元素乘以 1000 的权重梯度故障改用默认内核、而不是确定性内核来审计时，50 步内没有报警。第 20 步和第 40 步的检查点仍被标为审计和权重检查通过，因为损失未受影响，而且每一份副本都应用了同一次被损坏的更新。如果损坏在各副本之间是一致的，彼此同意并不等于安全。
博文对其他限制也很直白。这些检查是为数据并行训练写的。作者讨论了如何推广到其他设置，但表中的数字只属于这一设置。数据是合成的。模型不到 10 亿参数。故障是软件注入的，不是 16000 张 GPU 负荷下老化的硅片。在 150 分钟无故障运行上得到较低的误报上界是有用的，但它不是大型预训练作业的寿命失效率。
[1][2]一个公平的反对意见
公平的读法是：这是一套仪器化做得很好的工程办法，并不能证明生产训练中的静默损坏已经被解决。已经在比较校验和、重跑微批次，或使用确定性内核的实验室，会认出这些想法。真正的贡献在于把三项检查和 HyperPod 的换节点流程包在一起，公开了一个漏检案例，并把代码放进 AWS Labs 示例。配套仓库在 GitHub 的 awslabs/awsome-distributed-ai 下，路径是 examples/use-cases/pytorch-ddp-sdc-detection。
[1][2]未来六个月该看什么
能说服怀疑者的，不是再给 9.53 亿参数拷贝任务补一张注入故障表。而是一次真实的、持续数周的训练公开漏检与检出记录，并写明审计频率、内核模式，以及环形重放的代价，用浪费的步数或额外的 GPU 小时来计量。如果默认内核下的审计仍然漏掉各副本一致的反向路径故障，团队就需要在审计步上使用确定性内核，或再加一项不依赖副本之间出现分歧的检查。值得观察的是，这些设置会不会变成 HyperPod 训练配方里的默认项，还是停留在一篇博文的配套仓库里。
[1][2]