一篇读懂 checkpoint：训练容错的存档机制

训练中断是常态，存档是底线

大规模训练的故障率背景，「GPU 集群故障工程」一篇给过量级感：几千卡跑几周的作业，硬件故障几乎是按天计的必然事件；断点续训的完整链路（数据流水线、弹性恢复、备份节点）「训练集群的工程学」一篇也拆过了。本篇聚焦那条链路的核心机制本身：checkpoint——训练的存档。它的角色像极了游戏的存档点：死了从最近的存档重来，而不是重开整局游戏。没有 checkpoint 的大规模训练，等于把数周的卡时押注在「永不出故障」上，而这个赌注在千卡规模下的赔率是必输。

存档还有一层不太被强调的价值：它是回滚手段，不只是故障恢复。训练跑飞（loss 发散、指标异常）时，回退到早一点的存档、调整超参或数据配置再续跑，比从头重训便宜一个量级；下游的微调任务也从底座的存档起步。存档质量影响的不只是容错，是整个训练迭代的周转速度。换个视角看它的分量：训练平台的恢复能力、实验迭代的效率、存储成本的大头，全压在这个机制上——它是训练基础设施里被调用最频繁的重型操作，值得像对待数据库的事务日志一样认真设计。

存档机制的工程内涵远比「把权重存个文件」丰富：存什么决定能不能满血复活，怎么存决定存档期间烧多少卡时，存多勤决定故障时丢多少进度。这三问就是本篇的骨架。

存档里存了什么

一份合格的 checkpoint 是一个状态包，核心是四件套。模型权重是主角；优化器状态是隐形的大头——Adam 类优化器给每个参数挂着一阶与二阶动量两个同形状张量，体积约为权重的两倍，不存它，恢复后优化器失忆、训练抖动（这个后果在训练集群篇里从续训链路的角度讲过，这里强调的是它的体积：存档大小的大头往往不是权重而是优化器状态）。第三件是调度与进度：训练到第几步、学习率走到哪、数据集吃到哪个位置——少了它就会重吃或跳吃数据。第四件是随机数状态与元信息：dropout、shuffle 依赖的 RNG 状态，外加配置快照、框架版本、保存时间这类元数据。元数据看似琐碎，救场时价值连城：恢复脚本要靠它判断「这份存档是哪个配置训出来的、能不能直接加载」，版本不符时能给出人话报错而不是神秘崩溃。

四件套的完整性要用演练来验证：训练集群篇强调过「故意杀一次作业」的验收方式，这里补一句验收的具体判据——恢复后的 loss 曲线与中断前平滑衔接，指标看板上没有重复段，两条都过才算存档合格。

存档的命名与滚动也有约定俗成的做法：存档名带 step 数与时间戳，恢复脚本按命名规则定位「最新的完好份」；滚动窗口内保留最近几份，更早的定期归档。格式兼容是另一个真实痛点：框架升级后旧存档能否加载，靠元数据里的版本号提前判断，加载器对旧格式做迁移——跨大版本迁移要在升级计划里预留时间，别等故障恢复时才发现新框架读不了旧存档。

权限与加密也要进清单：存档里有训练数据的足迹（数据进度、配置快照），敏感任务的存档要按敏感数据对待——访问控制、加密存储、保留期限一条不能少，别让存档成为绕过数据权限体系的后门。

保存的代价：一场显存到磁盘的搬家

保存是有代价的，代价的形状是一次同步的「三段搬运」：训练暂停，先把显存里的状态拷到 CPU 内存（跨 PCIe），再从内存写到本地盘或对象存储（走网络或存储总线）。大模型的存档体量在数百 GB 到 TB 级（权重加优化器状态，还常常不止一份滚动保留），三段搬运走完是秒级到分钟级——这段时间整组 GPU 集体空转。

算一笔账感受量级（演示口径）：保存一次耗时 2 分钟，每 30 分钟保存一次，约 6% 的墙钟时间花在存档上；如果保存间隔缩到 10 分钟，损耗比例涨到约 17%——存档频率直接从训练效率里扣钱。这笔账是后面频率权衡的核心变量。此外还有隐性代价：保存瞬间内存峰值翻倍（显存态与内存态并存），内存配小的节点可能因此 OOM；写存储的瞬时大流量可能拖累挂在同一存储上的其他作业。所以保存不是免费的保险，而是要精打细算的开销。

存储选型本身就是一笔三层账，呼应「AI 存储三层策略」篇：写本地 NVMe 最快，但节点一死存档陪葬，只配当第一落点；共享文件系统稳，但要扛住全员并发写——几百个进程同时写盘，聚合吞吐是硬指标；对象存储最便宜、容量无上限，但延迟高，适合归档层。常见的组合是「本地落第一份、共享存储留滚动窗口、远端对象存储归档」的三级结构，各层各司其职、互为备份。

分布式 checkpoint：分片保存与恢复重排

TB 级的存档不可能走「单进程收集全量写一个大文件」的老路——收集阶段就能把网络与单盘打爆。现代方案是分布式 checkpoint：每个训练进程只保存自己名下的分片（权重按并行策略切开的份额、对应的优化器状态），全体并行直写存储，存储侧得到一批中等大小的分片文件。保存时间因此随并行度摊薄，这是 TB 级训练唯一现实的存档形态。

分片的形态由并行策略决定：数据并行下各分片彼此等价；张量并行与流水线并行下，权重被切成互补的份额，谁存哪块完全由并行布局决定——这也是恢复时重排复杂、跨拓扑恢复困难的根源：新布局要反推「我需要的数据躺在哪些旧分片的哪些位置」。理解分片与并行布局的对应关系，是排查「恢复后参数错乱」这类问题的钥匙。

恢复时的关键问题是拓扑可能变了：故障换卡、弹性伸缩改变了进程数与分片边界，新进程名下的参数可能躺在旧分片的其他位置——恢复方需要按新拓扑从旧分片集合里把各自的数据重排拼装（resharding）。同拓扑恢复走快路径，跨拓扑恢复慢且复杂，重要任务通常固定并行配置避开它（这个取舍训练集群篇讲过，机制层面到此即可）。配套的工程习惯再强调两件：写完做校验（校验和或抽样比对），存档损坏能自动回退到上一份；滚动保留最近几份加定期远端归档——存档和被保护的数据待在同一块盘上是经典的单点自毁，本地盘烧了存档跟着殉葬，远端那份才是最后的底牌。

归档的可用性还要靠一份元数据清单保障：每个分片的哈希、大小、归属（哪种布局下的第几号分片）、校验状态，清单与分片一起存。没有清单的分布式存档，恢复时要从文件名反推结构，一旦命名有出入就拼不回去——清单是分片集合的「装配说明书」，别省。

恢复窗口也要预估：加载时间约等于存档体量除以存储聚合读吞吐，再加校验与重排的额外开销（演示口径：每秒 10GB 的聚合读吞吐，加载 2TB 存档约三分钟）。恢复窗口是「体量、吞吐、校验」三项之和，预算超标的任务要么提存储吞吐、要么压单份存档体量——别等到真出故障时才发现，恢复本身要半个小时。

保存频率的权衡与工程方向

频率的算术

保存频率是一道期望损失的最优化题。存得太疏：故障点到最近存档之间的进度全部蒸发，损失与间隔成正比；存得太勤：存档开销吃掉有效训练时间，前文的账已经算过。工程上的常见落点是每几百到几千步存一次，或按固定分钟数存一次（常识口径，按任务的故障敏感度与存档耗时调），原则是让「单次存档耗时占间隔的比例」控制在个位数百分比，同时「期望丢掉的进度」在可接受范围。

频率还该随训练阶段动态调整：前期超参未稳、loss 抖动大，存密一点，方便快速回退试错；中后期稳定推进，放宽间隔省开销。回退的成本也要有意识权衡：从越早的存档续跑，重复算的步数越多、超参变化后轨迹偏离越大——回退不是免费的撤销键，回退多远是决策不是默认。

存档动作本身也要「瘦身」：只存必要状态、压缩可压缩的张量、清掉调试用的中间量——单份体量小了，频率的权衡空间就大，恢复窗口也跟着缩短。体量治理是频率治理的前置功课，很多「存档太慢」的问题，根子是存了太多没必要存的东西。配合滚动保留策略（最近几份循环覆盖、低频全量归档），存储体积也有界。

异步与增量：把存档藏进计算的背后

方向性的工程优化是把同步搬运藏起来。异步 checkpoint：先把显存状态快速拷进 CPU 锁页内存（这一段必须短暂同步，因为显存马上要继续训练），随后的写盘由后台线程慢慢做，训练全程不停——存档的墙钟代价从分钟级压到秒级的显存拷贝；代价是内存里要多驻留一份状态，内存配额要跟上，主流训练框架对此已有成熟支持（常识口径）。

异步化也带来新的策略问题：后台还在写上一份存档，下一个存档点又到了——写盘速度跟不上保存频率怎么办？要么跳过本次、要么排队串行写，策略要显式定义；最忌讳默认行为变成「越攒越多」，把内存吃爆。增量路线有自己的前提：恢复时要随机读旧存档的变化块，存储的随机读性能成为新瓶颈——增量省写却可能费读，先测存储的随机读，再决定要不要上。增量 checkpoint 更进一步：利用优化器状态大部分步内变化有限的特点只写变化分块，写盘量再降一档。再往前是「少存档化」的研究方向（内存态迁移、快速恢复一类的工作，业内仍在探索，此处存目不论）。落地建议按成熟度排：先把分片保存与频率算术做对，再上异步化，增量按框架支持情况选配。

小结

checkpoint 是训练容错的存档机制，也是大规模训练敢开机的底气。存档内容是四件套：权重、体积常大于权重的优化器状态、调度与数据进度、随机数状态加元信息，完整性靠「杀一次作业、看 loss 衔接」来验收；保存的代价是一场显存到内存到磁盘的同步搬家，TB 级体量下分钟级空转，频率与开销的算术决定它吃掉多少有效训练时间；分布式 checkpoint 用全员分片直写解决体量问题，用重排恢复应对拓扑变化，用校验、回退、远端归档守住最后一道保险；频率落点每几百到几千步，异步化把搬运藏进计算背后，增量按需选配。

把本篇放进系列里看，它是一个交汇点：存档机制向上承接训练集群的弹性恢复链路，向下依赖存储分层（存档写哪层、留几份，正是「AI 存储三层策略」的 checkpoint 应用题），故障率数据则决定存档频率的参数。三条线拧在一起，才是「训练作业在任何故障下损失可控」的完整答案。对实践者，本篇浓缩成一句口诀：存得全、存得散、存得勤而不贵、存档永远有异地的备份——四条全占，凌晨三点的故障电话就只是一条自动恢复的日志。

最后给验收一个固定仪式：每次改动存档配置（频率、层级、格式、框架版本升级）之后，都做一次「杀作业恢复演练」——变更引入的恢复问题，只有在演练里才会现形；演练通过的存档系统，才配得上「底线」这两个字。