AWS 称 GPU 算错不报错，HyperPod 用三道检查把它揪出来
AWS 称，静默数据损坏（silent data corruption，SDC）是指 GPU 等硬件返回了一个错误但看似合理的数值，且不触发任何报错。在分布式训练中，这个错误数值会经由梯度全归约（all-reduce）流入每个副本的梯度和权重，loss 可以在数小时内看起来完全正常，等团队发现不明发散或模型变弱时，算力已经浪费了。AWS 在博客中引用 Meta 的数据：Llama 3 405B 预训练期间，在长达 54 天、最多使用 16K 张 H100 GPU 的过程中，419 次意外作业中断里有 6 次被归因于 SDC——而这还只是导致作业中断并被追溯到 SDC 的案例。
它解决什么问题
据 AWS 博客，SageMaker HyperPod 已有的节点健康监测机制包括：健康监测代理监控 GPU 报错、深度健康检查对节点做压力测试、自动节点恢复替换故障硬件。但 SDC 能绕过所有这些机制，因为硬件从未报告任何异常。
AWS 介绍，SDC 的根源在于制造缺陷（通过厂商筛选的边缘晶体管）和硅片老化，最常出现在张量核心的乘加运算通道上——这恰恰是模型训练最密集使用的硬件。这种边缘电路大多数时候计算正确，只在高温、电压跌落或特定操作数模式下出错。由于算术逻辑路径没有 ECC 或奇偶校验（与内存不同），错误结果（比如 4.0001 而非 4.0000）永远不会被标记，直接流入激活值和梯度，最终进入每个副本的权重。因此，检测必须来自训练作业本身，对计算结果做校验。
它怎么做：三道检查
AWS 称，该方案在 PyTorch DistributedDataParallel（DDP）训练循环中加入三道检查，每道覆盖故障可能落入的不同位置，按固定顺序在每个训练步内执行。
第一道：非有限梯度检查。 AWS 称，在全归约之前，检查每个 rank（即每个参与训练的 GPU 进程）的本地梯度是否包含 NaN 或 Inf；全归约之后，再检查归约后的梯度。这能在故障发生的当步捕捉前向或反向传播中爆掉的数值，也能捕捉全归约本身引入的 NaN 或 Inf。clip_grad_norm_ 已经计算了归约后梯度的范数，因此该检查每步只额外增加一次单元素全归约。
第二道：环形重放审计（ring replay audit）。 AWS 介绍，在审计步（audit step）上、优化器更新之前执行。每个 GPU 重新计算另一个节点上某个 rank 的微批次（micro-batch），然后逐位比较 loss，并在使用确定性内核时比较每个参数梯度的指纹。由于所有副本在 optimizer.step() 之前持有相同的权重，任何 rank 都可以重算其他 rank 的微批次，结果必须完全一致。这道检查能捕捉有限但错误的数值——这类错误不会表现为 NaN 或 Inf，第一道检查看不到。当某个 rank 同时出现在两组比较中且都不匹配，即判定它是故障源；若只有一组不匹配，则由第三个节点上的 GPU 再做一次重放来确认，因此至少需要三个不同节点。
第三道：权重指纹比对。 AWS 称，在 optimizer.step() 之后执行。每个副本对所有权重张量计算指纹（两个 64 位校验和，一个普通求和、一个按位置加权求和），然后收集所有副本的指纹做比较。某个 rank 的某个张量指纹与严格多数（超过半数）不同时，该 rank 被标记为可疑。这道检查能捕捉优化器步骤中和已存储权重中的损坏。据该博客，在测试中，一个权重在某次更新后立即被损坏，在下一个检查点步被捕获，检查点未被写出；若没有这道强制检查，损坏的副本会被直接保存。
AWS 称，当第一道或第二道检查触发时，梯度被清零、优化器更新不执行，坏梯度不会进入权重或优化器状态。检查点仅在三道检查全部通过时才保存。
和以前的做法有何不同
据 AWS 博客，一个自然的替代设计是比较各 rank 本地梯度范数的离群程度。AWS 团队在 32 张 H100 上用 9.53 亿参数模型做了 22,800 步无故障训练记录，发现健康状态下各 rank 的本地梯度范数差异已达 1,240 个 MAD（中位绝对偏差）。把阈值设为 336 MAD（前 800 步最高分的 1.5 倍），在剩余 22,000 步中仍产生 11 次误报；而注入故障时，故障 rank 的得分从未超过 6.9——即使把一个激活值乘以 10,000。换言之，健康噪声比故障信号还大，梯度范数比较对有限错误值无效。
开销与误报
据 AWS 博客，团队在 4 台 ml.p5.48xlarge 实例（32 张 H100）上用软件注入故障做了测试，并在 3 台实例上重复了所有场景。在 9.53 亿参数模型上，权重指纹比对每次耗时 31.1 毫秒，每 10 步运行一次时占步时约 2%。审计步使用确定性内核，成本是默认步的 2.4 倍。每 100 步做一次审计的端到端开销约为 10%。
AWS 称，在无故障运行中，15,320 次审计步和 3,080 次权重检查均未触发告警，据此以 95% 置信度估算误报率上限约为每 5,100 次审计步 1 次。
目前的边界
据 AWS 博客，该方案目前仅在 DDP 下测试。权重指纹比对适用于任何保留独立权重副本的并行布局（张量并行、流水线并行、上下文并行、HSDP、混合专家），但在 ZeRO-1 或完全 FSDP 分片下不适用，因为每个分片的更新只在一个 rank 上计算。环形重放审计至少需要三个不同节点。未测试的场景包括：未使用的参数、梯度累积、BatchNorm 和带副作用的前向钩子。审计步使用 math attention 内核，其成本随序列长度的平方增长。此外，AWS 明确指出，全归约内部产生的有限错误值仍能通过所有检查；单次出现在非审计步上且不再复现的有限故障也无法被捕捉。测试使用的是软件注入故障，AWS 建议在生产环境中对每次节点替换保留人工审批，直到在自己的工作负载上积累了足够的精度证据。
主题分类：AI 基础设施/训练可靠性