01 · 保存更快，要以可恢复训练为目标
训练检查点是某个明确边界的状态快照，用于故障后继续训练。同步保存让训练等待全部写入；异步保存把部分工作移到后台，与后续训练重叠。它不减少训练本身的数学计算，主要影响长期完成工作的有效时间。
这里的检查点保存不同于M037激活checkpoint：后者在同一步里重算激活省显存，本篇把可恢复状态写到存储。
依据：PyTorch · 异步分布式检查点教程 ↗ · PyTorch · Distributed Checkpoint接口与兼容范围 ↗
02 · 只保存模型权重，为什么不能完整续训
| 对象 | 恢复时的作用 |
|---|---|
| 模型参数与buffer | 恢复当前模型，而非初始化版本。 |
| 优化器moment、step及分片信息 | 继续原更新历史，重置moment通常会改变训练。 |
| scheduler、AMP scaler等 | 延续学习率与精度配方。 |
| 随机状态、数据/采样位置、训练进度 | 尽量续接同一数据与随机过程，具体按数据流水合同保存。 |
| 配置、版本与检查点元数据 | 解释权重布局、精度、分片和兼容范围。 |
完成一次optimizer更新并处理配套状态后，通常容易定义一致边界。若在梯度累积中间保存，还需包含未完成梯度、microbatch进度等；不能加载模型后从整批起点重跑，却声称与原过程完全一致。
精确逐位恢复还取决于确定性算子、硬件、拓扑和数据加载过程。保存更多状态是必要准备，不能保证跨环境位级相同。
依据：PyTorch · Distributed Checkpoint接口与兼容范围 ↗ · PyTorch · DDP 执行机制（main） ↗
03 · state_dict返回，不代表已经得到独立快照
某些状态字典中的Tensor仍引用训练正在更新的底层存储。后台线程如果直接持有这些引用，可能写出t步参数与t+1步moment的混合状态。快照一致性必须由安全边界、独立副本或相应staging机制保证。
明确训练边界t
取得这一边界的模型/优化器/数据等状态
复制到独立快照缓冲，保证复制期间源不被改坏
确认staging已得到稳定快照
训练才允许执行会冲突的后续更新
后台把快照写入存储，完成后再释放缓冲异步staging可以有更精细的事件与依赖，但不能把“函数已返回”当成所有源数据都可覆盖。PyTorch DCP有不同stager及完成信号，具体返回对象、默认行为和实验接口需要按版本核对。
依据：PyTorch · 异步分布式检查点教程 ↗ · PyTorch · Distributed Checkpoint接口与兼容范围 ↗
04 · 搬到缓冲与写存储，是两个完成时刻
自设4个训练step，每步10 ms，每2步保存一次；稳定快照复制2 ms，后台写入12 ms，一份缓冲。同步总时间为40+2×(2+12)=68 ms。异步第一份复制在20–22，写入22–34；训练第3/4步在22–42，第二份复制42–44、写入44–56。
训练计算在44 ms结束，但最后一份检查点直到56 ms才写完。若此时退出或回收缓冲，不能声称它已经可恢复。最终全部完成56 ms；异步没有把最后一次写入成本凭空消掉。
训练结束时，最后一份快照写完了吗？
4步训练，每步10 ms；快照复制2 ms，一份独立缓冲。下一次复制先等上次写完；写入结束代表本教学模型的完成合同，不模拟真实存储持久性、多rank提交或竞争。本演示一份缓冲只允许一个待写快照，下一次staging前先等上次写完。真实实现可增加缓冲、跳过中间保存或限流，但要明确容量和恢复点取舍。
05 · 后台变慢，会积压还是反过来阻塞训练
若后台每次40 ms，上例第一份写到62 ms；训练第4步42 ms已结束，却要等缓冲空闲到62，再复制到64、写到104。训练完成时刻变为64 ms，后台最终完成104 ms。异步仍可覆盖一些写入，但不能持续制造无限快照。
原始状态快照每rank若为8 GiB，两份独立快照就约16 GiB缓冲，再加序列化与训练进程已有CPU状态。pinned内存可能改善设备搬运，但驻留缓冲、共享主机带宽和存储竞争也有代价。
- 限流：限制待保存数量，必要时等待或按明确策略跳过。
- 缓冲：源复制完成前不能更新冲突区域，写入结束前不能覆盖快照槽。
- 多rank：同一步边界、布局元数据和通信顺序配套。
- 失败：后台异常要被检查，不能只留下一个“任务已提交”的日志。
06 · 写完几个分片，还不是可恢复的完整版本
分布式保存常由多个rank分别写分片。只有必要分片、元数据和提交步骤都成功，才能把这个版本作为有效恢复点。不能仅根据目录存在或某一个rank的future完成，判断整个检查点已提交。
以新版本/临时目标写快照
校验必要分片、元数据与完成状态
按存储/框架合同提交可恢复版本
恢复时选择已提交且兼容的版本
加载参数与optimizer等完整状态
核对step、布局、数据进度后继续本地rename、对象存储和框架的完成协议不同，不承诺一个通用rename就保证所有存储上的原子性与持久性。DCP支持某些分片布局变化的加载，具体模型状态、优化器映射和版本仍需验证；改变卡数也不保证相同随机数据顺序。
07 · 保存频率：阻塞更少，故障可能要重做更多
过于频繁增加快照、写入与缓冲压力；间隔太大则故障后回退更多训练。应按实际保存成本、故障情况、重启时间与质量里程碑选择，异步不意味着可以无限频繁保存。
一个教学近似：每隔τ分钟有效训练保存一次，暴露保存成本为C分钟，故障平均间隔F分钟，并假设故障在保存间隔内均匀出现且开销较小。保存损失比例约C/τ，故障重做约τ/(2F)；再加重启成本。它忽略后台提交滞后和竞争，只解释取舍，不能直接给生产最优频率。
异步检查点的最新快照未提交时，实际可恢复点可能比最近staging更旧。测重做量应以有效已提交版本为准，而不是按提交后台任务的时刻。
08 · 小脚本验证快照与恢复，不只模拟时间
下载脚本训练一个随机驱动的标量momentum模型，保存独立参数/状态/随机与数据进度，恢复后对照连续运行；同时展示浅引用污染快照和漏掉优化器状态的反例。教学提交模型拒绝不完整分片，时间线检查缓冲不得提前复用。不执行真实磁盘写入或DCP。
先做小作业的保存→恢复→继续结果对照
注入未完成写入、后台失败与缺失分片
验证恢复只选择有效已提交版本
再测staging阻塞、后台吞吐、峰值CPU与训练step
长跑记录有效训练时间、失败回退和恢复耗时
# 最后退出前等待所有必要提交并处理异常。依据：PyTorch · 异步分布式检查点教程 ↗ · PyTorch · Distributed Checkpoint接口与兼容范围 ↗
09 · 从完整恢复路径验收
- 一致性：同一边界参数/状态，恢复后Loss轨迹和数据进度。
- 时间：staging、实际写入、提交、暴露阻塞和恢复总耗时。
- 资源：CPU/pinned缓冲、设备复制、网络与存储竞争。
- 可靠性：后台错误、半成品、退出、旧版本和拓扑变化。
GPU/NPU设备快照和CPU写入都需要各自的完成依赖。框架、分片形式和存储后端决定实现，不能把单进程CPU复制示例当成已验证的多机方案。
依据：vLLM Ascend · 支持功能矩阵（main） ↗
- state_dict中的Tensor仍共享存储时，为什么后台保存会混入下一步？
- 训练计算结束与最后快照可恢复，为何不是同一个时刻？
- 异步写入很慢时，增加缓冲解决了什么，又带来什么？
流程位置与关联方法
这个方法可能出现在多个位置；计算线包含模型计算与算子实现，执行线包含运行时、内存和通信。
资料与核查范围
原理依据以原始论文和官方文档为主；算例与时间线是教学推导。文档核查日期：2026-10-10。引用 main / latest 文档时，实际接口以安装版本为准。
- PyTorch · 异步分布式检查点教程 ↗
- PyTorch · Distributed Checkpoint接口与兼容范围 ↗
- PyTorch · DDP 执行机制（main） ↗
- vLLM Ascend · 支持功能矩阵（main） ↗
代码为接入片段或教学伪代码；本页没有声称完成 NVIDIA / 昇腾硬件实测。