训练任务中断后，GPU服务器最快的恢复路径不是重跑，而是从最近的检查点（checkpoint）续跑。 检查点文件完整、环境变量一致、分布式通信状态复位，这三件事做对了，大多数中断都能在几分钟内接上,而不是让几十个小时的计算归零。
GPU服务器训练中断后怎么恢复？先做这3步
我处理过上百次训练中断，有一半以上是凌晨被告警叫醒，醒来第一件事不是看日志，而是按固定顺序做三件事：定位中断原因、确认检查点、恢复训练脚本。
第一步：判断是硬件故障还是软件崩溃
先看系统日志和GPU日志，区分“服务器自己挂了”和“程序自己崩了”，硬件问题比如显卡掉驱动、电源过载、内存ECC错误，这类恢复需要先重启服务器；软件问题比如OOM、梯度爆炸、NCCL超时，这类不用重启物理机,直接重启进程就行。
实操命令：
nvidia-smi -q -d TEMPERATURE,ERROR dmesg | tail -50
如果看到 Xid 错误且数值在 13、31、43 或 45 附近，基本可以断定是GPU硬件或驱动层面的问题，需要先处理物理状态再谈恢复，如果只是 Python traceback 或 CUDA error,则进入下一步。
第二步：检查最近的检查点文件
训练中断恢复的核心是检查点，不是日志，先找到 save_dir 下最新的 .pt、.ckpt 或 .h5 文件,确认它的时间戳和步数。
ls -lh --time-style=full-iso /data/checkpoints/
检查点里通常包含模型权重、优化器状态、当前epoch和step编号，行业共识认为，检查点的保存频率决定了中断恢复的最大损失每1小时保存一次，断点最多丢失1小时算力；每24小时保存一次,赔进去的就是一整天。
如果检查点文件大小异常小（比如模型权重应该2GB，文件只有200MB），大概率是保存时进程被强杀导致文件没写完，这种情况只能退回上一个完整检查点,没有捷径。
第三步：按原环境重启训练脚本
环境不一致是恢复失败的头号原因，很多人以为“权重读回来就行”，但优化器状态、学习率调度器、随机数生成器状态也必须同步恢复，PyTorch 里用 load_state_dict 时，不仅要 model 要调用，optimizer 和 scheduler 也得调用。
重启命令要和拉起训练时保持一致，不要改 batch size、学习率或分布式卡数，改了 batch size，batch norm 的 running stats 会错位；改了分布式卡数，NCCL 的通信集合会重建，之前的进度虽然没丢,但后续收敛可能出问题。
断点续训配置对比：PyTorch vs TensorFlow
不同框架的恢复写法差异很大，如果你用的是 PyTorch，核心思路是“手动保存 + 手动恢复”，TensorFlow 则偏向“状态管理”，我把两者差异拆开讲,方便你按需选择。
PyTorch 的 torch.save 与 resume
保存时尽量打包成一个字典,不要只存权重：
checkpoint = {
'epoch': epoch,
'global_step': global_step,
'model_state_dict': model.state_dict(),
'optimizer_state_dict': optimizer.state_dict(),
'scheduler_state_dict': scheduler.state_dict(),
'loss': loss
}
torch.save(checkpoint, f'ckpt_{global_step}.pt')
恢复时先加载到 CPU，再搬到 GPU：
ckpt = torch.load('ckpt.pt', map_location='cpu')
model.load_state_dict(ckpt['model_state_dict'])
optimizer.load_state_dict(ckpt['optimizer_state_dict'])
global_step = ckpt['global_step']
torch.load 默认会直接把张量加载到原来的设备，如果你的恢复环境卡号变了，或者显存布局不一样，必须加 map_location='cpu' 做中转，否则容易报 CUDA error: device-side assert triggered。
TensorFlow 的 CheckpointManager
TensorFlow 的 tf.train.Checkpoint 配合 tf.train.CheckpointManager 是官方推荐路径，它自动保留最近N个检查点,并且恢复时不用手动管理字典。
checkpoint = tf.train.Checkpoint(model=model, optimizer=optimizer, step=tf.Variable(0)) manager = tf.train.CheckpointManager(checkpoint, dir='/data/ckpt', max_to_keep=3) status = checkpoint.restore(manager.latest_checkpoint)
这里有个关键点：restore 之后最好调用 status.assert_existing_objects_matched() 来验证键值匹配，分布式策略下，如果你用了 tf.distribute.MirroredStrategy，恢复时要在 strategy.scope() 里执行 checkpoint.restore，否则变量创建上下文不匹配,恢复失败。
断点续训配置对比表
| 对比项 | PyTorch | TensorFlow |
|---|---|---|
| 保存接口 | torch.save | tf.train.Checkpoint |
| 恢复接口 | torch.load | restore |
| 是否自动管理多版本 | 否 | CheckpointManager 支持 |
| 需恢复优化器状态 | 是 | 是 |
| 分布式恢复 | 需要手动同步 | 策略内自动处理 |
| 常用检查点格式 | .pt / .pth | 目录+索引文件 |
从恢复操作复杂度看，PyTorch 更透明，但手动步骤多；TensorFlow 自动管理更省心，但黑盒程度高，TensorFlow 的 CheckpointManager 容错更好；对精细控制每一步的学习率变化，PyTorch 更顺手。
分布式训练中断恢复的硬骨头：NCCL 通信与超时
单卡训练中断恢复属于“简单模式”，多卡或多机训练才是真坑，分布式训练中断后，即使每个节点都有完整检查点,直接重新启动进程也常常报错。
NCCL 超时是分布式恢复的头号障碍
常见错误像 NCCL timeout、unhandled cuda error、ncclSystemError，本质是通信集合（communicator）已经失效，进程前的训练中断后，机械的重新初始化 dist.init_process_group 并不够，你需要先关闭旧的进程组,再重新初始化。
# 清理残留进程（每台机器都要执行） pkill -f train_script.py sleep 5
然后重启训练，如果仍然报超时，检查 IP 是否变化，以及防火墙是否拦截了 29500 端口（默认的 MASTER_PORT），部分租用的 GPU 服务器重启后内网 IP 会变，导致 MASTER_ADDR 失效,这是最容易忽略的坑。
分布式恢复的推荐配置
推荐用 torchrun 而不是手动 nn.distributed，因为 torchrun 能处理环境变量传递，并且会自动设置 MASTER_ADDR 和 RANK,恢复时这样写：
torchrun --nnodes=2 --nproc_per_node=8 --master_addr=192.168.1.10 resumable_train.py
脚本里要对每个 rank 执行同一份检查点的恢复逻辑，注意不要只让 rank0 恢复，其他 rank 也要恢复各自的优化器状态，否则某些参数更新进度不同步，后续 loss 会突然飙升。
成都GPU服务器租用场景下，中断恢复有哪些坑
说到地域场景，我接触过不少成都本地的 AI 公司，他们租用 GPU 服务器做训练，中断恢复的问题更特殊，机房断电、网络波动、共享存储延迟,这些都会让恢复流程变得更长。
数据持久化：检查点不能只写在本地磁盘
很多租用的 GPU 服务器默认数据盘是临时的，重启后可能被清空，如果检查点写在本地，而机器被机房强制重启，磁盘数据可能直接没了，成都有些机房提供共享 NAS 或对象存储，建议把 save_dir
挂到共享存储上,具体做法是：
mount -t nfs4 10.0.0.5:/data /checkpoint
至少也要定期把检查点 rsync 到另一台机器或对象存储，宁可慢一点,不能丢模型。
租用场景下的成本问题：训练恢复会增加费用吗
租用按小时计费，中断后重跑就意味着多付几小时的空转费，如果每次中断都从头训练，一个月下来成本会高得吓人，所以租用 GPU 服务器时，一定要选支持镜像快照和检查点存储的套餐，并且提前确认“是否支持从检查点恢复后继续计费暂停”，多数租用平台支持“停止实例”而不是“销毁实例”，停止后磁盘保留，恢复时直接开机续跑,比重新创建实例省钱得多。
还有一种情况：你租的是多机多卡集群，但恢复时只想用其中一部分卡来测试，这时需要设置 CUDA_VISIBLE_DEVICES 来限定可见卡，避免程序强行初始化所有卡导致通信失败,测试通过后再恢复全量训练地址。
Q&A：GPU服务器训练中断恢复常见问题
检查点保存间隔设多少最合理？
没有绝对标准，但行业共识是：保存间隔的算力成本要远小于重启重跑的成本，实践证明，每 10 分钟或每 1000 步保存一次，性价比最高；如果显存和磁盘充裕，可以每 5 分钟存一次，大规模分布式训练的成本高,保存更频繁反而划算。
中断恢复后 loss 比中断前高，正常吗？
正常，优化器状态恢复后，前几个 batch 的学习率、动量会重新对齐，loss 可能出现小幅波动，一般跑 100-200 步后会回到原水平，如果持续偏高，检查是不是没有恢复 scheduler_state_dict，或者 batch size 变了导致 BN 统计量漂移。
硬件故障恢复后，检查点加载报错 `CUDA error: out of memory` 怎么办？
先降低 batch size 或清空缓存 torch.cuda.empty_cache()，如果仍然 OOM，说明当前 GPU 显存不如故障前，这时需要把优化器状态动态调整到另一块卡上，或者使用梯度累积，注意，不要直接重装驱动，很容易把问题扩大化，先检查显存占用，如果故障卡是显存物理损坏，换卡后在同一节点恢复，MASTER_ADDR 不变，检查点可以直接加载；换节点则需要同步修改所有 rank 的地址配置。
训练中断不是灾难，只要检查点策略到位、恢复路径清晰，损失可以控制在几分钟内。 关键是把检查点当作唯一真相，把环境一致当作铁律，把通信状态当作直接底线，下次再遇到中断，按上面步骤走一遍，GPU 服务器会很快回到训练状态。