训练中断怎么办？断点续训功能配置与使用说明

训练中断怎么办？断点续训功能配置与使用说明

在大模型训练的实战中，最让人头疼的场景之一莫过于：跑了三天三夜的训练任务，眼看就要收敛，突然因为云实例被抢占、CUDA Out of Memory 或网络抖动导致进程崩溃。重启从头开始？那意味着成千上万步的梯度更新白做了，GPU算力白白烧掉几十甚至上百小时。

这不只是资源浪费的问题，更是对研发节奏的巨大打击——尤其是当你在做RLHF、DPO这类长周期、多阶段的复杂训练时，一次中断可能直接打断整个实验迭代链条。

好在现代深度学习框架已经普遍支持断点续训（Checkpoint Resume Training），它像“游戏存档”一样，在关键时刻保存完整的训练状态，让训练可以从中断处无缝恢复。而ms-swift作为魔搭社区推出的大模型全链路训练部署框架，不仅原生集成了这一能力，还将其深度融入预训练、微调、对齐等各类任务流程中，覆盖600+纯文本模型和300+多模态模型，真正做到了开箱即用。

断点续训是如何工作的？

简单来说，断点续训的核心思想是：把训练过程中的所有“上下文”都保存下来，不只是模型权重。

很多人误以为“保存模型”就等于“能恢复训练”，但实际上，如果只保存了model.state_dict()，重新加载后虽然模型结构还在，但优化器的状态（比如Adam的动量、方差）、学习率调度器的进度、当前训练步数、随机采样位置等关键信息都会丢失。结果就是——看似继续训练，实则变成了一个全新的训练过程，收敛行为完全不同。

真正的断点续训需要持久化的状态包括：

• 模型参数 (model.state_dict())
• 优化器状态 (optimizer.state_dict())
• 学习率调度器状态 (lr_scheduler.state_dict())
• 当前全局步数（global step）和epoch
• 随机数生成器状态（RNG state），确保数据打乱顺序一致
• 数据加载器的采样器状态（sampler state），避免重复或跳过样本

这些内容组合起来，才构成一个可恢复的“检查点”（checkpoint）。当训练重启时，系统会自动检测是否存在有效的检查点目录，并从中加载全部状态，使训练行为与中断前完全一致。

典型的输出目录结构如下：

output/ └── qwen-7b-lora/ ├── checkpoint-500/ │ ├── pytorch_model.bin # 模型权重 │ ├── optimizer.pt # 优化器状态 │ ├── scheduler.pt # 学习率调度器 │ ├── trainer_state.json # 当前step、loss记录等元信息 │ └── rng_state.pth # 随机种子状态 └── last_checkpoint -> checkpoint-500 # 符号链接指向最新检查点

其中last_checkpoint是一个符号链接，方便程序快速定位最新的可用检查点，无需遍历所有子目录。

如何在 ms-swift 中启用断点续训？

ms-swift 的设计目标之一就是降低大模型训练的技术门槛，因此断点续训功能被封装得极为简洁。你只需要在配置中打开几个开关，剩下的由框架自动处理。

基础配置示例

from swift import Trainer, SwiftConfig training_args = SwiftConfig( output_dir='./output/qwen-7b-lora', per_device_train_batch_size=4, gradient_accumulation_steps=8, learning_rate=1e-4, num_train_epochs=3, save_steps=500, # 每500步保存一次检查点 save_total_limit=3, # 最多保留最近3个检查点，防止磁盘爆满 resume_from_checkpoint=True, # 自动恢复最新检查点 seed=42 # 固定随机种子，保证可复现性 ) trainer = Trainer( model=model, args=training_args, train_dataset=train_dataset, data_collator=data_collator, ) # 启动训练，框架自动判断是否需要恢复 trainer.train(resume_from_checkpoint=training_args.resume_from_checkpoint)

这段代码的关键在于resume_from_checkpoint=True和save_steps=500的配合。前者告诉 Trainer 在启动时主动查找已有检查点，后者定义了保存频率。两者结合，即可实现“自动存档 + 自动读档”的闭环。

更进一步，ms-swift 还支持命令行参数控制，适合脚本化运行：

python train.py \ --output_dir ./output/qwen-7b-lora \ --resume_from_checkpoint true \ --save_steps 500 \ --save_total_limit 3

无需修改任何代码，只需调整参数即可开启断点续训。

分布式训练下的挑战：多个GPU怎么统一恢复？

单卡训练的断点续训相对直观，但在 DDP、FSDP 或 DeepSpeed 等分布式训练场景下，问题变得复杂得多：模型和优化器状态被切分到多个设备上，如何聚合？如何避免每个rank各自保存一份冗余数据？恢复时又该如何广播初始化？

以 FSDP（Fully Sharded Data Parallel）为例，其核心机制如下：

1. 状态聚合：通过FSDP.full_optim_state_dict()将分布在各GPU上的优化器状态合并到主节点（通常为 rank 0）。
2. 统一保存：仅在主节点将完整状态写入磁盘，避免N份重复文件。
3. 恢复广播：加载时先在主节点重建状态，再通过dist.broadcast()分发给其他设备。

DeepSpeed 则提供了更高层的抽象，其检查点管理更为自动化：

from deepspeed import DeepSpeedEngine # DeepSpeed 配置文件 ds_config.json """ { "train_batch_size": 128, "gradient_accumulation_steps": 4, "optimizer": { "type": "AdamW", "params": { "lr": 1e-5 } }, "fp16": { "enabled": true }, "checkpoint": { "tag_validation": false, "save_interval": 1000, "strip_dp_rank_zero": true } } """ engine, optimizer, _, _ = DeepSpeedEngine( args=training_args, model=model, config="ds_config.json" ) # 训练循环 for step, batch in enumerate(train_dataloader): loss = engine(batch) engine.backward(loss) engine.step() if step % 1000 == 0: engine.save_checkpoint("./output/deepspeed_ckpt")

下次启动时调用engine.load_checkpoint()即可恢复全部状态，包括 ZeRO 分区后的优化器张量和 RNG 状态。ms-swift 内部已集成对 DeepSpeed、FSDP、DDP 等多种并行策略的支持，用户无需关心底层细节。

此外，对于跨并行策略迁移的需求（例如从 FSDP 转移到 DeepSpeed），ms-swift 也提供工具脚本进行检查点格式转换，提升灵活性。

实际应用场景：这些“救命时刻”你一定遇到过

场景一：抢占式实例被回收

很多团队为了节省成本会选择云平台的抢占式实例（Spot Instance）训练大模型。这类实例价格低廉，但随时可能被回收。

假设你在训练一个 Qwen-7B LoRA 模型，设置save_steps=500，运行至第8000步时实例被释放。此时：

• 最近一次保存的是checkpoint-8000
• 重启新实例后，挂载原有存储路径，执行相同训练脚本
• ms-swift 自动检测到last_checkpoint指向checkpoint-8000
• 提示：“Found existing checkpoint… Do you want to resume training? [y/N]”
• 输入y，训练从 step 8001 继续

原本要重跑的7500+步计算得以避免，恢复时间不超过5分钟。这种效率提升在大规模实验中尤为关键。

场景二：DPO训练中途OOM崩溃

强化学习类任务如 DPO、PPO 往往需要数万步才能收敛，且每步计算图复杂，极易触发显存溢出。

某次 DPO 训练运行到第15000步时因 batch 处理不当导致 CUDA OOM。若无断点续训，则需重新走一遍 RM 打标、数据清洗、初始SFT模型准备等前置流程，耗时数小时。

但有了检查点机制：

• 使用 QLoRA + DeepSpeed ZeRO-2 减少显存占用
• 开启定期保存（如每1000步）
• 崩溃后从checkpoint-15000恢复
• 直接继续策略梯度优化

整个过程无需回退到数据处理阶段，极大提升了调试效率。

工程实践建议：别让“救火功能”变成隐患

尽管断点续训带来了巨大便利，但如果使用不当，也可能引入新的风险。以下是我们在实际项目中总结的一些最佳实践：

✅ 检查点频率设置要合理

太频繁会增加I/O压力，影响训练吞吐；太稀疏则可能导致过多工作丢失。一般建议控制在每次保存耗时不超过训练周期的5%。

✅ 存储路径优先使用共享存储

本地磁盘容易因机器故障导致检查点丢失。推荐将output_dir挂载到 NAS、OSS 或其他分布式文件系统上，确保即使节点宕机，检查点依然可访问。

✅ 启用检查点轮转机制

务必设置save_total_limit=N（如3或5），防止长期运行积累过多检查点撑爆磁盘。ms-swift 会在保存新检查点时自动清理最旧的一个。

✅ 注意代码版本一致性

检查点依赖于模型结构和训练逻辑。如果恢复时使用的代码与保存时不一致（例如修改了模型层名、删减了模块），会导致load_state_dict()失败或行为异常。

建议：
- 结合 Git 版本号命名输出目录，如output/qwen-7b-lora-v1.2/
- 或在trainer_state.json中嵌入 commit hash，便于追溯

✅ 监控磁盘空间并设置告警

可在训练脚本中加入简单的磁盘监控逻辑：

import shutil def check_disk_usage(path, threshold=0.8): usage = shutil.disk_usage(path) percent_used = usage.used / usage.total if percent_used > threshold: print(f"⚠️ Disk usage {percent_used:.2f} exceeds threshold {threshold}") # 可触发告警或提前终止

也可借助 Prometheus + Node Exporter 实现集群级监控。

为什么说断点续训已是标配？

回顾几年前，许多研究者还在手动管理模型保存，甚至靠“人肉看护”来防止训练中断。如今，随着大模型训练周期越来越长、硬件环境越来越动态（尤其是云上），断点续训已不再是“加分项”，而是工业级AI系统的必备能力。

它带来的价值远不止“容错”本身：

• 提升资源利用率：减少重复计算，尤其在昂贵的TPU/NPU集群上意义重大；
• 增强实验稳定性：支持在不稳定的网络或硬件环境下持续迭代；
• 保障可复现性：结合固定种子和检查点，实现端到端的实验还原；
• 加速多阶段训练：在 SFT → Reward Modeling → PPO 流程中灵活切换起点。

而 ms-swift 正是基于这样的理念构建：不仅提供强大的训练能力，更要让开发者专注于模型设计本身，而不是被基础设施问题牵扯精力。

写在最后

如果你还没有为你的训练任务默认开启断点续训，现在就是最好的时机。

无论是学术研究还是企业落地，每一次意外中断都是对时间和信心的消耗。而一个小小的resume_from_checkpoint=True配置，就能让你在面对突发状况时多一份从容。

与其事后补救，不如事前设防。把断点续训纳入你的标准训练模板，配合自动化监控与存储管理，才能真正构建起高效、健壮的大模型研发体系。

毕竟，在通往AGI的路上，我们输不起的不是算力，而是耐心。