21 · 训练稳定性与故障恢复

⏱ 26 分钟 ｜ ⭐ 千卡训练时，硬件故障是常态不是意外

🎯 一句话

在 1000 张 GPU 上跑一个月，"什么都不坏"的概率接近零。 大规模训练的工程重点不是"避免故障"，而是"故障后能快速、正确地恢复" —— 而最可怕的不是崩溃，是那些不崩溃的错误。

📉 一、先接受一个数字

常见故障类型：

💾 二、Checkpoint 策略

四个必须做对的点：

# 🧩 骨架：`model` 来自你自己的代码，这一段只看写法
# ⭐ PyTorch 分布式 checkpoint（异步 + 分片）
import torch.distributed.checkpoint as dcp

fut = dcp.async_save(
    {"model": model, "optim": opt, "step": step, "rng": get_rng_state()},
    checkpoint_id=f"ckpt/step-{step}")
# 训练继续，不阻塞 ⭐

⭐ checkpoint 里必须存什么

🔍 三、最可怕的：不崩溃的错误

四种典型的静默失败：

# ⭐ 一个便宜的静默错误探测器：定期检查各 rank 是否一致
import torch
def sanity_check_across_ranks(loss, grad_norm, step):
    t = torch.tensor([loss, grad_norm], device='cuda')
    gathered = [torch.zeros_like(t) for _ in range(dist.get_world_size())]
    dist.all_gather(gathered, t)
    if dist.get_rank() == 0:
        vals = torch.stack(gathered)
        spread = (vals.max(0).values - vals.min(0).values) / (vals.mean(0).abs() + 1e-9)
        if spread.max() > 0.5:          # ⭐ 各卡差异过大 = 有问题
            print(f"⚠️ step {step} rank 间差异异常: {vals}")

🔑 数据并行下各卡的 loss 应该不同（数据不同），但梯度范数在 AllReduce 后应该一致。 如果 AllReduce 之后各卡的梯度范数不一样 —— 通信出问题了。

🩹 四、训练不稳定：loss 尖峰

五个实用的稳定化手段：

# 🧩 骨架：`model` 来自你自己的代码，这一段只看写法
# ⭐ 跳过异常 batch：非常便宜，收益很大
import torch
gn = torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0)
grad_history.append(gn.item())
median = statistics.median(grad_history[-100:])

if gn > 10 * median and len(grad_history) > 100:
    opt.zero_grad(set_to_none=True)        # ⭐ 丢弃这一步
    log(f"skip step {step}, grad_norm={gn:.1f} vs median {median:.1f}")
else:
    opt.step(); opt.zero_grad(set_to_none=True)

💡 "回滚 + 换数据顺序"是大模型训练的标准操作： 如果尖峰是某批数据引起的，换个顺序往往就跳过去了。 大厂的训练日志里这类回滚很常见 —— 它不是失败，是正常流程。

🔁 五、弹性训练与快速恢复

加快恢复的三个手段：

# ⭐ 三个必设的 NCCL 环境变量
export TORCH_NCCL_BLOCKING_WAIT=1          # 超时报错而不是永久挂起
export TORCH_NCCL_ASYNC_ERROR_HANDLING=1   # 异常时干净退出
export NCCL_TIMEOUT=1800                   # 30 分钟（默认可能太长）

💥 不设 BLOCKING_WAIT 的后果： 一张卡挂了，其他 999 张卡会永远等下去 —— GPU 利用率显示 100%（在空转），但一步都没往前走。 你可能几小时后才发现。（第 10 章提过这个坑）

🔗 和站内其他章的关系

✅ 检查点

1. 1000 张卡的集群 MTBF 大概是多少？这意味着什么？
2. checkpoint 间隔的经验公式是什么？
3. checkpoint 的四个要点是什么？为什么要原子写入？
4. checkpoint 里最常被漏掉的是什么？漏了会怎样？
5. 为什么说"崩溃是好故障"？
6. 怎么便宜地探测静默错误？各卡的 loss 和梯度范数应该一致吗？
7. loss 尖峰的常见原因？五个稳定化手段？
8. "跳过异常 batch"怎么实现？
9. 不设 TORCH_NCCL_BLOCKING_WAIT 会怎样？

🛑 可以停在这里

⚡ 走神救援

⭐ 千卡训练时硬件故障是常态：单卡平均无故障时间除以卡数，上千张卡就是几小时坏一次——⭐ 所以 checkpoint 和自动恢复决定训练能不能完成。 间隔有个现成的平方根公式，⭐ 它的形状是「保存越贵就存越稀，故障越频就存越密」。

四个要点：⭐ 异步保存（先拷到内存再后台写盘，阻塞从几分钟降到几秒）、⭐ 分片保存（别汇总到一张卡上）、原子写入（先写临时文件再改名，防写一半崩溃）、留多份。

⭐ checkpoint 里最常漏的是数据加载器的位置——⚠️ 漏了会重新从头读数据，某些样本训了好几次、某些一次没见过，而且不报错。 还要存调度器、随机数状态和缩放器。

⭐⭐ 最可怕的不是崩溃，是静默失败——训练照跑、loss 也在降，但结果是错的。⭐ 崩溃是好故障，它至少会告诉你出事了。

⭐ 有个极便宜的探测器：定期把各个 rank 的 loss 和梯度范数收上来比一比——⭐⭐ loss 应该不同（数据不同），但梯度范数在同步之后必须一致；不一致就是通信出了问题。

loss 尖峰的五个手段里性价比最高的是 ⭐ 跳过异常 batch：梯度范数远超近期中位数就丢掉这一步——极便宜、收益很大。⭐ 另一条要记的心态：回滚加换数据顺序重跑，是大厂的标准操作，不是失败。

⚠️⭐ 最后是三个必须设的通信库环境变量：不设阻塞等待的那个，一张卡挂了、其余全部会永远等下去——💀 GPU 显示满负荷，而一步都没走，几小时后才有人发现。

下一节 👉 22-数据管线与存储.md