save_total_limit=2的意义：防止磁盘爆满
1. 背景与问题引入
在大模型微调过程中，检查点（checkpoint）的保存是确保训练过程可恢复、结果可复现的重要机制。以 Qwen2.5-7B 这类参数量达数十亿级别的模型为例，在使用 LoRA 等参数高效微调方法时，虽然显存占用已大幅降低，但训练过程中仍会频繁生成检查点文件。这些文件不仅包含适配器权重，还可能包括优化器状态、学习率调度记录等元数据，单个 checkpoint 可达数百MB甚至上GB。
当训练轮数较多（如num_train_epochs=10）、保存频率较高（如save_steps=50）时，若不加限制地保留所有检查点，极有可能导致磁盘空间迅速耗尽。尤其在单卡 RTX 4090D（24GB 显存）这类资源受限的本地环境中，存储容量往往有限，一旦磁盘写满，轻则中断训练任务，重则影响系统稳定性。
因此，如何在保障训练安全性的前提下，合理控制磁盘使用，成为工程实践中不可忽视的关键问题。本文将聚焦于save_total_limit=2这一关键参数，深入解析其作用机制与实际价值。
2. save_total_limit 参数详解
2.1 基本定义与功能
save_total_limit是 Hugging Face Transformers 及其衍生框架（如 ms-swift）中用于控制模型检查点保存数量的核心参数。它不属于训练算法本身，而是属于训练回调（TrainerCallback）中的日志与持久化策略。
其核心功能为：
限制输出目录中最多保留的检查点总数，超出后自动删除最旧的检查点。
例如：
--save_total_limit 2表示在整个训练周期中，output_dir目录下最多只保留2 个最新的检查点文件夹（如checkpoint-100,checkpoint-200），其余历史检查点将被自动清理。
2.2 工作机制分析
该参数的工作流程如下：
- 检查点触发条件满足：当达到
save_steps指定的步数或一个 epoch 结束时，触发保存逻辑。 - 新检查点写入：系统生成新的检查点目录并保存当前模型状态。
- 数量判断：检查当前
output_dir下已有检查点数量是否超过save_total_limit。 - 旧检查点清理：若超出限制，则按时间顺序删除最早创建的检查点，确保总数不超过设定值。
这一机制本质上是一种FIFO（先进先出）缓存管理策略，通过牺牲部分历史备份来换取稳定的磁盘使用。
2.3 与其他保存参数的关系
| 参数 | 作用 | 是否必须 |
|---|---|---|
--output_dir | 指定检查点保存路径 | ✅ 必须 |
--save_steps | 每多少训练步保存一次 | ⚠️ 可选（默认每 epoch 保存） |
--save_strategy | 保存策略（steps/epoch/no） | ⚠️ 可选 |
--save_total_limit | 最多保留几个检查点 | ❌ 非必须，但强烈建议设置 |
值得注意的是，save_total_limit的生效前提是启用了检查点保存功能（即save_strategy != 'no'）。若未开启保存，则此参数无意义。
3. 实际场景中的价值体现
3.1 磁盘空间保护：避免“爆盘”风险
假设某次微调任务配置如下：
- 数据集大小：50 条样本
- 训练轮数：10 epochs
- 批大小：1
- 梯度累积步数：16
- 总训练步数 ≈ 800 步
- 每 50 步保存一次 → 共生成约 16 个检查点
- 每个检查点平均大小：300MB
则总磁盘占用预估为：
16 × 300MB = 4.8GB虽然总量看似不大，但在以下场景中仍可能引发问题：
- 容器环境默认磁盘配额较小（如 10GB）
- 同时运行多个实验，共享同一存储卷
- 日志、临时文件、原始模型共同占用空间
此时，若设置save_total_limit=2，则最大磁盘占用仅为：
2 × 300MB = 600MB相比不限制的情况，节省了87.5%的存储空间，显著降低了因磁盘满载而导致训练失败的风险。
3.2 提升训练稳定性与可维护性
除了空间节约外，save_total_limit还带来以下工程优势：
- 防止 I/O 崩溃：大量小文件频繁读写易造成文件系统碎片化，影响性能甚至导致 I/O 错误。
- 简化后期管理：无需手动清理过期检查点，减少人为操作失误。
- 支持长期训练：对于需要持续迭代的项目，可持续运行而不必担心存储溢出。
3.3 对模型恢复能力的影响评估
有观点认为限制检查点数量会影响容错能力。对此需理性看待：
| 场景 | 是否受影响 | 说明 |
|---|---|---|
| 断电/崩溃后重启 | ✅ 影响 | 若仅保留最近两个检查点，无法回退到更早状态 |
| 学习率震荡需回滚 | ⚠️ 局部影响 | 通常只需回退1~2个检查点即可解决问题 |
| 模型过拟合观察 | ❌ 不影响 | 可通过eval_steps和日志分析趋势 |
综合来看，保留2~3 个最新检查点足以应对绝大多数恢复需求。真正关键的是保证最后一个检查点可用，而非保留全部历史版本。
4. 最佳实践建议
4.1 推荐配置组合
结合 Qwen2.5-7B 微调场景，推荐以下参数搭配：
swift sft \ --model Qwen2.5-7B-Instruct \ --train_type lora \ --dataset self_cognition.json \ --torch_dtype bfloat16 \ --num_train_epochs 10 \ --per_device_train_batch_size 1 \ --learning_rate 1e-4 \ --lora_rank 8 \ --lora_alpha 32 \ --target_modules all-linear \ --gradient_accumulation_steps 16 \ --eval_steps 50 \ --save_steps 50 \ --save_total_limit 2 \ --logging_steps 5 \ --max_length 2048 \ --output_dir output \ --system 'You are a helpful assistant.'其中save_total_limit=2是经过验证的平衡点：既保留了一定容错能力，又有效控制了磁盘增长。
4.2 不同硬件环境下的调整策略
| 显卡类型 | 推荐 save_total_limit | 理由 |
|---|---|---|
| RTX 4090D / A6000 | 2~3 | 存储相对充裕，兼顾安全与效率 |
| RTX 3090 / A5000 | 2 | 平衡空间与恢复能力 |
| RTX 3080 及以下 | 1~2 | 存储紧张，优先保障运行 |
提示：可在训练结束后手动备份最佳检查点至外部存储，再释放本地空间。
4.3 替代方案对比
| 方案 | 优点 | 缺点 |
|---|---|---|
save_total_limit=N | 自动管理，无需干预 | 无法选择性保留特定检查点 |
| 手动定期清理 | 可精准控制保留内容 | 易遗漏，增加运维负担 |
| 使用符号链接归档 | 灵活组织历史版本 | 复杂度高，不适合初学者 |
| 云存储自动同步 | 永久保存，跨设备访问 | 成本高，依赖网络 |
综合考虑自动化程度与可靠性，save_total_limit仍是目前最实用的本地训练管理手段。
5. 总结
save_total_limit=2虽然只是一个简单的整数参数，但在大模型微调的实际工程中扮演着至关重要的角色。它不仅是磁盘空间的“守门员”，更是训练稳定性的“保险丝”。
通过对检查点数量的智能限制，该参数实现了：
- ✅ 显著降低磁盘占用，避免因存储耗尽导致训练中断
- ✅ 自动化清理机制，提升实验可维护性
- ✅ 在容错能力与资源消耗之间取得良好平衡
在基于 ms-swift 框架进行 Qwen2.5-7B 等大型语言模型的 LoRA 微调时，建议始终启用save_total_limit，并根据实际环境设置为2或3。这是一项低成本、高回报的最佳实践，值得纳入每一位 AI 工程师的标准训练配置清单。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
