AWS 提出三项代码级检查，检测绕过硬件监控的 GPU 静默数据损坏

静默数据损坏之所以难以检测，根本原因在于它发生在计算路径内部。GPU 的乘加单元返回一个错误但合理的数值——比如 4.0001 而不是 4.0000——不触发任何错误信号。现有的每一项完整性检查守护的是另一个边界：ECC 保护内存，Xid 捕获驱动和硬件故障，DCGM 深度健康检查在空闲节点上运行，NVLink 和 PCIe 校验和验证传输字节是否完整送达，检查点校验和确认存储往返一致。没有任何一项检查算术逻辑路径的输出是否正确，因为那条路径上根本没有 ECC 或奇偶校验。

这意味着检测只能来自训练任务本身。AWS 在 PyTorch 分布式数据并行训练循环中加入三项检查，按故障可能落点的位置排列。第一项是非有限梯度检查：在梯度聚合之前，标记局部梯度范数为 NaN 或 Inf 的 GPU；聚合之后，再检查归约梯度是否包含 NaN 或 Inf。第二项是环形重放审计：在优化器步进之前，每个 GPU 重新计算另一个节点上某个 GPU 的微批次，逐位比较损失值，在确定性内核下还比较梯度指纹。这能捕获有限但错误的计算值。第三项是权重指纹比较：优化器步进之后，比较所有副本的权重指纹，捕获更新步骤或存储权重中的损坏。

三项检查的执行顺序和时机有严格逻辑。计算路径中的故障必须在优化器步进之前捕获，因为一旦错误梯度通过聚合传播到所有副本，所有权重仍然一致，事后无法区分。而优化器步进中的故障只有在那之后才能看到。环形重放之所以可行，是因为在反向传播和优化器步进之间，所有副本持有相同的权重，任何 GPU 都可以重算另一个 GPU 的微批次并期望得到完全相同的位。

在 32 块 H100 上训练一个 9.53 亿参数模型的实测中，仅运行梯度钩子和 NaN/Inf 检查（不含审计）使每步时间增加约 7.4%；每 100 步运行一次确定性审计增加约 10.1%；每 10 步审计一次增加约 34.7%。在 15,320 次无故障审计步骤和 3,080 次权重检查中未触发任何告警，按三分法则给出约五千分之一的误报率上界（95% 置信度）。

这一方案有明确边界。它仅在 DDP 布局上测试，张量并行、流水线并行和 FSDP 分片需要另行适配。一次性的有限故障如果恰好落在非审计步骤上，不会被任何检查捕获。确定性审计使用数学注意力内核，其成本随序列长度平方增长，在长序列训练中开销可能远超本文的测量值。AWS 也明确指出，合成测试不能确立生产环境中的精确度，建议在每次替换节点前保留人工审批。

从实际部署角度看，这套方案将检测、定位和恢复串成闭环。训练循环中的检查一旦触发告警，告警携带的 suspect_window 记录了自该检查上次通过以来的步骤范围，故障活跃于其中某一步。在 SageMaker HyperPod 由 Amazon EKS 编排的集群上，Kubernetes 节点名包含实例 ID，因此将可疑 GPU 的 rank 映射到具体实例只需一次查表。运维人员据此停止任务、隔离节点、检查 DCGM 指标，确认后通过节点健康标签或 BatchReplaceClusterNodes 接口完成硬件替换，训练脚本从 suspect_window 之前的检查点恢复。