显卡进程一旦退出，显存中的临时状态通常也会随之丢失。要让长时间计算接着跑，关键不是简单重启命令，而是让程序知道上次完成到哪里、哪些状态必须一并恢复。显卡计算任务的断点恢复与故障容错设计，通常由检查点、恢复校验和有边界的重试共同完成。
先确定“恢复”需要保存什么
检查点不是只记一个进度百分比。对于分块计算，应保存已完成的块编号、输入版本、参数和结果位置；对于迭代算法，还要保存迭代步数以及影响后续计算的状态。若只恢复步数，却漏掉随机数状态或优化器状态，重跑轨迹可能改变，结果也未必等价。
例如使用 TensorFlow 进行模型训练时，tf.train.Checkpoint可用于保存模型和优化器等对象；自定义 CUDA 程序则需要自行序列化必要数据。显卡计算任务的断点恢复与故障容错设计应明确保存边界：哪些内容可重算，哪些内容丢失后会改变结果。
把检查点写成可验证的恢复点
- 记录完整元数据。至少包括任务标识、软件或模型版本、输入数据标识、当前进度、检查点格式版本和生成时间。恢复时先核对输入与版本，避免把旧状态套到新任务上。
- 先写临时文件，再完成提交。将数据写到临时路径，确认写入结束且文件可读后，再改名为正式检查点；保留上一个可用版本。这样可以降低进程在写盘中途退出造成文件残缺的风险。
- 保证状态处于一致边界。若计算使用异步设备操作，应在保存前确认相关计算已完成；分布式任务还需确保参与设备保存的是同一逻辑步骤。否则进度标记可能领先于实际结果。
- 启动时先校验再恢复。检查文件是否完整、字段是否齐全、任务版本是否匹配。校验失败时回退到上一份有效检查点，而不是把损坏文件当作正常状态继续运行。
检查点间隔与重试策略要配套
间隔太短，会增加写盘和同步开销；间隔太长，中断后需要重算的工作更多。可以先测量一次保存耗时，再按任务可接受的重算量选择间隔。作为起点，连续运行时间较长的任务可试用每数分钟到数十分钟保存一次，并在任务接近结束或完成重要阶段时额外保存；具体频率应根据检查点耗时、存储速度和中断风险调整。
重试也要分类型。设备临时不可用、节点重启或存储短暂超时，可在等待后有限重试；输入文件缺失、参数错误、显存需求长期超过设备容量等确定性问题，反复启动通常不会解决，应停止并报告原因。退避重试可逐次延长等待时间，并设置最大次数或总时限，避免故障时频繁拉起任务。
让重试不重复污染结果
输出采用幂等写入：每个任务块写入独立结果，完成后登记状态；重跑时先检查结果是否已完整提交。若输出文件可能只写了一部分，应写入临时文件并在验证后替换正式文件。这样即使重试执行了同一块，也不会把有效结果重复累加或覆盖成半成品。
实际落地时的检查顺序
- 人为终止一次测试任务，确认它能从最近检查点恢复，而不是从头开始。
- 模拟检查点文件缺失或损坏，确认程序能回退并留下清楚日志。
- 检查日志是否记录失败类型、重试次数、恢复进度和所用检查点。
- 观察保存耗时与重算量，调整间隔；若恢复不稳定，先修正状态一致性和输出提交，再增加重试次数。
显卡计算任务的断点恢复与故障容错设计，最终要验证的是“恢复后状态可信”，而不仅是进程重新启动。把检查点做成完整、可校验的恢复点，再配合故障分类、幂等写入和有限重试，才能在计算中断后安全续跑。
常见问题
显卡重启后能直接接着显存状态运行吗？
通常不能。设备进程退出后，显存中的临时状态不可依赖；程序需要从磁盘或其他持久存储读取检查点。
检查点越频繁越好吗？
不一定。保存本身会占用时间和存储带宽，应结合保存耗时、中断风险及可接受的重算量确定间隔。
重试次数应该设置多少？
没有适用于所有任务的固定值。对短暂故障可设有限次数并逐步延长等待；确定性错误应尽早停止，避免无效重跑。
只有一个进度数字，能实现续跑吗？
只有在其余状态可准确重建、且输出不会重复写入时才够用。迭代算法或带随机性的任务往往还需保存其他运行状态。
