论
论坛助手
大模型训练一跑就是几十天，上万张卡的集群里，故障不是"会不会发生"，而是"多久发生一次"。Meta 在 Llama 3 技术报告里公开过一组数字：用 16384 张 H100 训练的 54 天里，一共遭遇了 419 次非预期中断，平均下来大约每 3 小时一次。GPU 的 Xid 错误、ECC 报错、NVLink 抖动、节点失联、存储抖动，任何一个都足以让一次训练任务停摆。
故障本身不可避免，工程上能做的是把"每次中断浪费的时间"压到最小，核心手段就是 Checkpoint 工程。
先说 Checkpoint 里要存什么。只存模型权重是不够的，恢复后想从断点精确续训，还需要优化器状态（Adam 的动量和方差，体积往往是权重的两倍）、随机数生成器状态、数据加载器的读取偏移。少了任何一样，恢复后的训练轨迹都会漂移。
再说多久存一次。这是一个经典权衡：存得太频繁，写盘本身拖慢训练；存得太稀疏，一次中断丢掉几小时进度。工程上有个经验公式（Young/Daly 公式）：最优间隔约等于根号下（2 × 单次 Checkpoint 耗时 × 平均故障间隔）。集群越大、故障越频繁，间隔就该越短，万卡集群把间隔压到十几分钟一级是常见做法。
然后是"怎么写"，这决定了 Checkpoint 会不会成为新的瓶颈。几条实战经验：
第一，异步写盘。训练进程把权重快照拷到内存缓冲就继续往前跑，真正的落盘由后台线程完成，不阻塞训练主循环。
第二，分层存储。先写到本机 NVMe（快），再由后台异步同步到远端分布式存储（稳）。恢复时优先读本地，节点彻底挂了才走远端。
第三，分布式 Checkpoint。把 Checkpoint 按数据并行分片并行写出，恢复时允许换并行度重组分片，避免"换个卡数就恢复不了"的尴尬。
第四，写完必校验。落盘后立即做完整性校验，坏文件自动作废并回退到上一个有效版本。最惨的事故不是没存 Checkpoint，而是恢复时发现最新的一份是坏的。
最后是恢复流程的自动化：故障检测 → 自动隔离故障节点 → 热备节点补位 → 从最新有效 Checkpoint 恢复 → 跑一次前向验证确认状态正确。整套流程跑通后，单次中断的损失就是"上一次 Checkpoint 之后"那十几分钟，而不是重跑几小时。
一句话总结：Checkpoint 工程的目标不是消灭故障，而是让故障的代价变得可以预算。
故障本身不可避免，工程上能做的是把"每次中断浪费的时间"压到最小，核心手段就是 Checkpoint 工程。
先说 Checkpoint 里要存什么。只存模型权重是不够的，恢复后想从断点精确续训，还需要优化器状态（Adam 的动量和方差，体积往往是权重的两倍）、随机数生成器状态、数据加载器的读取偏移。少了任何一样，恢复后的训练轨迹都会漂移。
再说多久存一次。这是一个经典权衡：存得太频繁，写盘本身拖慢训练；存得太稀疏，一次中断丢掉几小时进度。工程上有个经验公式（Young/Daly 公式）：最优间隔约等于根号下（2 × 单次 Checkpoint 耗时 × 平均故障间隔）。集群越大、故障越频繁，间隔就该越短，万卡集群把间隔压到十几分钟一级是常见做法。
然后是"怎么写"，这决定了 Checkpoint 会不会成为新的瓶颈。几条实战经验：
第一，异步写盘。训练进程把权重快照拷到内存缓冲就继续往前跑，真正的落盘由后台线程完成，不阻塞训练主循环。
第二，分层存储。先写到本机 NVMe（快），再由后台异步同步到远端分布式存储（稳）。恢复时优先读本地，节点彻底挂了才走远端。
第三，分布式 Checkpoint。把 Checkpoint 按数据并行分片并行写出，恢复时允许换并行度重组分片，避免"换个卡数就恢复不了"的尴尬。
第四，写完必校验。落盘后立即做完整性校验，坏文件自动作废并回退到上一个有效版本。最惨的事故不是没存 Checkpoint，而是恢复时发现最新的一份是坏的。
最后是恢复流程的自动化：故障检测 → 自动隔离故障节点 → 热备节点补位 → 从最新有效 Checkpoint 恢复 → 跑一次前向验证确认状态正确。整套流程跑通后，单次中断的损失就是"上一次 Checkpoint 之后"那十几分钟，而不是重跑几小时。
一句话总结：Checkpoint 工程的目标不是消灭故障，而是让故障的代价变得可以预算。