Spot Instance中断处理：自动保存检查点恢复训练

Spot Instance中断处理：自动保存检查点恢复训练

在大模型训练的世界里，算力成本始终是一道绕不开的门槛。对于个人开发者或中小团队而言，动辄每小时数十甚至上百美元的A100/H100实例费用，足以让一次完整训练变成“奢侈品”。而云厂商提供的Spot Instance（竞价型实例），以低至按需价格1/10的成本提供强大GPU资源，无疑是雪中送炭。

但硬币总有另一面——这些实例随时可能被系统回收。想象一下：你花了三天时间训练一个7B模型，刚到第4000步，突然连接断开，日志显示“Instance terminated by AWS”。此前所有进度清零，只能从头再来？这不仅是时间和金钱的浪费，更是对工程韧性的严峻考验。

真正的解决方案，并不是避免使用Spot，而是坦然接受它的不稳定性，并构建一套能与之共舞的技术体系。其中最关键的，就是“自动保存检查点并从中断处恢复训练”的能力。

现代训练框架如ms-swift已经将这一能力封装得极为简洁，但其背后涉及的状态管理、分布式协同和轻量化策略，才是真正决定系统鲁棒性的核心。我们不妨抛开“先讲概念再列代码”的套路，直接深入实战视角，看看如何打造一条既能扛住抢占、又能高效续训的AI训练流水线。

当我们在Spot实例上启动一次训练任务时，最怕的不是慢，而是“白干”。因此，持久化中间状态成了第一要务。这里的“状态”远不止模型权重，还包括优化器动量、学习率调度器、当前训练步数等。如果只保存model.state_dict()，重启后虽然模型结构还在，但Adam的梯度一阶二阶矩全部丢失，相当于从随机初始化重新开始收敛——前几千步的效果几乎作废。

理想的做法是：每隔一定步数，把整个训练上下文打包存下来。这个包我们称之为“检查点”（Checkpoint）。在ms-swift中，只需几行配置即可实现：

from swift import Trainer, SwiftConfig training_args = SwiftConfig( output_dir="./output/checkpoints", save_steps=500, save_total_limit=3, resume_from_checkpoint=True, checkpoint_save_policy="best+latest" )

这段代码看似简单，实则暗藏玄机。save_steps=500意味着每500步写一次磁盘，太频繁会影响训练吞吐，太少则风险过高；save_total_limit=3启用LRU机制自动清理旧版本，防止OSS/S3账单爆炸；而resume_from_checkpoint=True则是“容错开关”——程序启动时会自动扫描目录下是否有.checkpoint标记文件，若有，则加载对应权重并跳转到global_step继续训练。

更重要的是，ms-swift默认保存的是全状态集合：不仅包括模型参数，还有optimizer、scheduler乃至随机种子。这意味着恢复后的训练轨迹与中断前完全一致，保证了实验的可复现性。

然而，单机训练早已无法满足当前大模型的需求。更多场景下，我们会用FSDP或DeepSpeed ZeRO将模型拆到多个GPU上。这时问题就来了：每个设备只持有部分参数分片，如何确保恢复时全局状态一致？

以FSDP为例，它采用“完全分片数据并行”策略，将模型参数、梯度和优化器状态都打散到各个GPU。保存检查点时，并非每个rank都独立写文件，而是由主节点（rank 0）协调统一命名和路径，其他节点同步输出自己的分片。读取时也类似，各GPU并行加载对应块，最后通过通信操作重组完整模型。

这种机制对中断恢复提出了更高要求：一旦某个节点在写入过程中被抢占，可能导致部分分片缺失，进而引发整个检查点损坏。为此，ms-swift在底层做了多重防护：

• 使用原子写入 + 临时文件机制，确保要么全成功，要么不保留残缺状态；
• 支持fsdp_offload_params=True，将参数卸载到CPU内存，进一步降低显存压力，提升在T4/V100等中低端卡上的稳定性；
• 集成BF16混合精度训练下的状态序列化支持，避免因数值截断导致恢复失败。

实际部署时，你可以这样启用FSDP模式：

training_args = SwiftConfig( output_dir="./output/fsdp_ckpt", save_steps=200, fsdp=["full_shard", "auto_wrap"], fsdp_offload_params=True, mixed_precision="bf16" ) trainer = Trainer(model=model, args=training_args, ...) trainer.train(resume_from_checkpoint=True)

即使整个集群被清退，只要检查点已完整上传至OSS/S3这类持久化存储，下次拉起新实例组时，依然可以无缝续训。这对于长期运行的千步级以上任务尤为重要。

如果说FSDP解决的是“大模型能不能跑起来”的问题，那么LoRA/QLoRA则回答了另一个现实命题：如何让检查点变得更小、更快、更便宜？

考虑这样一个场景：你在用Spot实例微调Qwen-7B，基础模型本身约14GB显存占用。若采用全参数微调，每次保存检查点都要写出14GB以上数据，I/O延迟显著，且极易因网络波动导致写入失败。而在QLoRA方案下，情况完全不同。

QLoRA的核心思想是三重优化：
1.4-bit量化加载：使用NF4格式将原始权重压缩为4位浮点，显存占用降至原来的1/4；
2.注入低秩适配器：仅在注意力层的q_proj、v_proj等模块插入少量可训练参数（通常r=8），冻结其余部分；
3.增量式保存：检查点只包含LoRA权重，体积通常不足100MB。

这意味着你可以把save_steps设得非常激进——比如每100步保存一次——几乎不影响训练速度，同时极大缩短了“暴露窗口”（即中断后最多损失的工作量）。

具体实现如下：

from swift import Swift, LoRAConfig lora_config = LoRAConfig( r=8, target_modules=["q_proj", "v_proj"] ) model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen-7B", load_in_4bit=True # 启用NF4量化 ) model = Swift.prepare_model(model, lora_config) # 注入LoRA training_args = SwiftConfig( output_dir="./output/lora_ckpt", save_steps=100, save_safetensors=True, resume_from_checkpoint=True ) trainer = Trainer(model=model, args=training_args, ...) trainer.train()

由于最终只需保存LoRA权重，即使你在T4实例上训练，也能快速完成写入。更妙的是，恢复时只需重新加载基础模型（可缓存于本地或NAS）+ 加载LoRA增量，几秒内即可回到训练状态。这种“冷基础+热增量”的模式，特别适合Spot环境下频繁启停的工作流。

当然，技术选型从来不是孤立的。在一个典型的基于Spot的大模型训练系统中，架构设计必须通盘考虑以下几个关键点：

• 存储必须持久化：绝不能依赖本地磁盘。务必挂载OSS/S3/NAS等远程存储，确保实例销毁后检查点仍可访问；
• 网络带宽预留：检查点上传可能占用高达百MB/s的带宽，建议异步执行或错峰进行，避免影响主训练进程；
• 恢复逻辑自动化：可通过脚本（如/root/yichuidingyin.sh）封装模型下载、环境配置、检查点探测与续训判断，实现“一键重启”；
• 成本与稳定权衡：某些实例类型（如AWS的p3.2xlarge）虽然性能一般，但Spot中断率较低，适合长时间任务；而H100类高端卡虽强，但被抢占概率高，更适合短周期冲刺。

此外，还可以结合监控告警机制，在检测到Spot中断预警信号（如EC2的两分钟通知）时，主动触发紧急检查点保存，进一步降低损失。

最终你会发现，真正拉开差距的，不是谁用了多少张A100，而是谁能把每一次中断的影响降到最低。借助ms-swift这样的现代化训练框架，我们可以轻松整合自动检查点、分布式恢复、轻量微调等多项能力，构建出一条抗干扰强、成本低、迭代快的训练流水线。

未来，随着云平台对Spot实例调度策略的优化（如提供“最长驻留时间”选项），以及训练框架在弹性伸缩、动态扩缩容方面的演进，我们甚至可以设想一种全新的工作模式：训练任务像“幽灵”一样漂浮在云中，无论底层硬件如何更替，只要检查点不断，进度就不会丢。

那时，“中断”不再是灾难，而只是训练过程中的一个普通事件。