数据存储方案 | 第14期：训练中断不是事故，是日常——检查点存储怎么搭
数据存储方案 | 第14期：训练中断不是事故，是日常——检查点存储怎么搭
> 摘要：一次故障丢多少活，检查点说了算。64 卡实测：状态迁移把带故障的训练从 818 分钟拉回 405 分钟。这一期把检查点分三层搭：本地 NVMe、阵列对象层、HDD 冷存。
训练跑起来之后，故障不是会不会来的问题，是来了丢多少的问题。Meta 公开的 Llama 3 训练记录摆在那儿：54 天、1.6 万张卡，419 次非计划中断。卡越多，故障越是排班表里的一项。
所以检查点不是备份习惯，是训练的时间保险：保费是每次写盘的开销，保额是故障时不用重算的步数。这一期就把这份保险怎么搭，拆开算。
一、一张 64 卡实测：恢复方式不同，总时长差出一倍
Clockwork 今年 3 月公布的自测，方法写明了，算厂商自测、不算第三方审计：TorchTitan 跑 Llama-4 MoE Scout（109B），64 张 H200，四轮对照，检查点每 100 步一次，故障按每 2700–4500 秒一次随机注入——这个频率约等于 3.2 万卡集群的水平。结果：检查点重启 818 分钟，TorchPass 状态迁移 405 分钟，TorchFT 副本组剔除 930 分钟。TorchPass 与 TorchFT 都是零步丢失（不用重算），检查点重启每一次都要从上一个检查点重来。1
图：同一批故障，三种恢复方式的总耗时。数据：Clockwork 厂商自测（见引用 1），程序绘制
*图：同一批故障，三种恢复方式的总耗时。数据：Clockwork 厂商自测（见引用 1），程序绘制*
同场 PyTorch 大会（10 月 20–21 日，圣何塞）的现场演示更直观：拔网线，训练没停；拔掉一半 GPU 的电，状态从存活的数据并行副本里重建，不到一分钟回到备机，零步丢失。3演示是厂商搭的台子，数字要打折看，但方向是一致的：恢复能不能离开作业的关键路径，决定了故障的代价。
还有一笔会议上 Together AI 给出的成本账：1024 卡跑 30 天，故障丢掉的算力折 20.7 万到 25 万美元；到 8192 卡，有效产出只剩 71%–81%。3数字是演讲口径，二手，但它点出了关键：故障成本随规模放大，检查点设计也就越往后越不能靠习惯。
二、账算在哪：间隔、大小、带宽三连乘
检查点不是模型权重一个文件。能从断点原样续跑，要凑齐权重、优化器状态、学习率调度、随机数状态，缺一环，续跑就变重训。优化器状态往往比权重本身还占地方——这就是为什么检查点一写就是几倍模型大小，写盘带宽先被它吃掉。
间隔的账，Clockwork 自己给了个算法：检查点每 3 小时一次，单次故障平均丢 1.5 小时。间隔砍一半，平均损失也砍一半；代价是写盘次数翻倍。3 小时这个数不重要，重要的是这道换算：间隔 = 你丢得起多少分钟。2
写盘路径的通行做法，是先落本地高速盘、再异步沉到对象存储：前者保恢复速度，后者保跨节点可达。两步分开，恢复不必等最慢的那一步。
三、方案怎么搭：检查点也要分三层
热层，本地 NVMe。秒级落盘、就近恢复。故障后的第一落点，恢复先从这儿拿，不经过网络。代价是盘位和写入寿命，要单独留预算。
温层，阵列和对象存储。检查点从本地盘异步沉降过来，任何节点都能拉到。跨机恢复、换机恢复都靠这一层撑着；S3 协议打通之后，它也是数据湖那一层的老熟人（第 13 期 MinIO 那条线讲过对象层的做法，这里不重复）。
冷层，HDD。留历史版本、做审计和回滚。便宜、慢、容量大，但别指望它抢恢复时间——它管的是「万一要回到三天前」，不是「十分钟内续跑」。
图：检查点三层分工。程序绘制
*图：检查点三层分工。程序绘制*
落到操作上，四条可抄走的：间隔按丢得起的分钟数倒推；检查点容量单独列进 BOM，别等上线才发现盘不够；恢复演练列入验收，不演练的检查点等于没写；历史版本留几份、留多久，提前定，别等盘满了现删。
四、对照：不止一家在走这条路
Meta 的 TorchFT 走的是另一条路：故障时把整个副本组剔除，剩下组继续跑，不用备机；代价是「爆炸半径」等于整个副本组——一个 8 节点×8 卡的组里坏一块卡，64 张卡都不能用。2PyTorch 的 dist._reconfigure 让存活进程原地重建进程组，256 张 H100 的演示里，每 10 分钟杀一台主机，备机约 30 毫秒从存活节点拉回分片；模拟到 9.8 万卡，有效训练时间从 44% 升到 80%。3这两条都是会议报告，二手，但它们和 TorchPass 指向同一个结论：恢复正在从「重启作业」变成「作业内部的事」。
也别把迁移想成免费：GB200/GB300 这一代系统，惯例是每机架 72 张卡里留 8 张作热备，约 11%。2迁移省的是重算的时间，备机本身还是要花钱的——这笔账，报价时要跟客户说在前面。
五、九羲观察：没有热备池，也能抄走简化版
中小集群没有 TorchPass，没有备机池，照样能把这套逻辑落地成便宜版：本地 NVMe 作热层；检查点双写一份到邻节点或阵列，算温层；HDD 留历史版本作冷层。恢复演练当验收做，间隔按业务能忍的丢失分钟数定。盘位和 NVMe 位，库存服务器集群里本来就有，不用为检查点单独立项买新硬件。
盘价每个季度都在变，摆放数据的方法变得慢。检查点分层是少花钱、多保命的那类设计。
还留一个没统一答案的问题：检查点该不该连同数据版本一起管？模型回滚到三天前，数据还是不是三天前那份？行业里还没有统一做法，先把问题摆出来，比假装它不存在强。
觉然小注：故障最容易让人犯的错，是把它当成意外来处理。意外才需要临时抱佛脚，日常才需要排班、演练和预算。 检查点是训练的时间保险。保费不高，保额是故障时不用重算的每一步——这笔账，跑过大集群的人都算过。
引用与出处
[1] Clockwork. Fault Tolerance Benchmark: Clockwork TorchPass, TorchFT and checkpoint, 2026-03-11. https://clockwork.io/blog/keeping-distributed-training-running-through-failures/?pdf=1 （成色：厂商自测，方法公开：注入故障频率、检查点频率均披露；非第三方审计）
[2] Clockwork. Common Approaches to Fault Tolerant AI Training & Selection Framework. https://clockwork.io/blog/common-approaches-to-fault-tolerant-ai-training-selection-framework/ （厂商技术文章：TorchFT 副本组剔除、热备 8/72、3 小时检查点平均丢 1.5 小时均出此文；Llama 3 中断数为转引 Meta 论文）
[3] gengwg. PyTorch Conference 2026: Notes from an Infra Engineer, Medium, 2026-10-24. https://gengwg.medium.com/pytorch-conference-2026-notes-from-an-infra-engineer-85c3e9a9f8cb （成色：参会工程师现场笔记，二手；演示、成本账、dist._reconfigure 演示均出此文）
---
九羲科技｜重构服务器 · 硬盘 · 私有 AI 落地解决方案
系列目录：数据存储方案
上一篇｜数据存储方案 第13期：显存不够用，存储来补位
下一篇｜数据存储方案 第15期：待定
合作 | 联系我们：jx@jiuxii.cn
脚踏实地 行知合一
互相成就 拥抱未来