核心内容摘要
男生女生一起错错错：那些年我们一起犯过的“小糊涂”
checkpoint怎么选保存策略与恢复技巧说明微调大模型时checkpoint检查点不只是训练过程中的一个中间产物它直接决定了你能否回溯效果、复现结果、快速验证想法甚至影响最终部署的稳定性和灵活性。
尤其在单卡资源有限的场景下——比如用一块 RTX 4090D24GB跑 Qwen
2.
B 的 LoRA 微调——每一轮 save_steps 都在显存、磁盘空间和时间成本之间做权衡。
选错 checkpoint轻则白跑几小时重则无法还原最佳状态。
本文不讲抽象理论也不堆参数公式而是从真实微调现场出发结合你正在使用的镜像单卡十分钟完成 Qwen
2.
B 首次微调手把手拆解checkpoint 到底该不该存存多少--save_steps 50是怎么算出来的为什么不是 10 或 200训练中断后如何精准续训而不是从头再来推理时加载checkpoint-xxx和加载最终merged模型效果真的一样吗多个 checkpoint 并存时怎么一眼识别哪个“最聪明”所有答案都来自你在/root/output/目录下亲手生成的那些文件夹。
checkpoint 是什么它不是“快照”而是“可执行的状态包”很多人把 checkpoint 理解成“训练中途截个图”这是误区。
在 ms-swift 框架中一个典型的checkpoint-100文件夹实际包含以下核心内容adapter_config.json记录 LoRA 的结构配置rank8, alpha32, target_modulesall-linearadapter_model.bin真正的低秩增量权重通常 10–15MBtrainer_state.json当前训练步数、loss 历史、optimizer 状态关键决定能否续训global_stepX.bin可选梯度或 optimizer 分片仅当启用 ZeRO 类优化时出现划重点只有同时具备adapter_model.bintrainer_state.json这个 checkpoint 才能既用于推理也能用于续训。
缺一不可。
而像pytorch_model.bin这类全量权重文件在 LoRA 微调中默认不会生成——因为没必要。
Qwen
2.
B 原始模型本身已固定我们只学“小补丁”。
这也是为什么本镜像能在 24GB 显存里跑起来的根本原因。
保存策略不是越多越好而是“够用可控可验证”镜像默认命令中设置了--save_steps 50 \ --save_total_limit 2 \ --eval_steps 50这组参数不是随便写的而是针对self_cognition.json约 50 条数据、单卡 4090D、LoRA 微调这一具体场景反复验证后的平衡点。
我们来逐条拆解
1--save_steps 50为什么是 50不是 10也不是 100先看数据量50 条样本 ×per_device_train_batch_size 1 每轮 epoch 实际只走 50 步。
再看gradient_accumulation_steps 16意味着模型每看到 16 个 batch 才更新一次参数 → 实际参数更新频率是每 16 步一次。
所以save_steps50≈ 每1 个完整 epoch 后保存 1 次50 ÷ 16 ≈
1 次更新 → 覆盖完整学习周期若设为1010 步 ≈
6 次更新 → 保存太密磁盘写入频繁且每个 checkpoint 差异极小无区分度若设为200200 步 ≈
1
5 次更新 → 跨越多个 epoch一旦在第 150 步崩溃就得倒退 100 步重训损失巨大实操建议小数据集200 条save_steps 数据条数 ÷ 2如 50 条 → 设 25~50中等数据集500–2000 条save_steps 100~200配合eval_steps保持一致每次 save 同时触发 eval → 你能立刻看到checkpoint-50对应的 loss 和回答质量而不是靠猜
2--save_total_limit 2为什么只留 2 个不怕删掉最好的吗save_total_limit控制的是/root/output/下同级 checkpoint 文件夹的数量上限。
当新 checkpoint 生成系统会自动删除最旧的那个FIFO 策略。
但注意它只删同级目录不删子目录。
例如output/ ├── v
/ ← 当前训练主目录 │ ├── checkpoint-50/ │ ├── checkpoint-100/ │ └── checkpoint-150/ ← 新生成触发删除 checkpoint-50所以limit2实质是永远保留最近两次完整评估过的状态。
这对 self-cognition 这类目标明确的微调非常友好——你总能对比“前一次”和“这一次”的回答差异快速判断是否过拟合比如开始机械重复“我是 CSDN 迪菲赫尔曼 开发的”但对其他问题答非所问。
❌ 错误认知“留越多越保险”。
正确认知“留够验证窗口比堆数量更重要”。
磁盘空间有限人工筛选成本高2 个高质量 checkpoint 1 份日志远胜 10 个模糊状态。
3--eval_steps 50保存和评估必须同步否则 checkpoint 就是“盲盒”镜像命令中--eval_steps 50与--save_steps 50完全对齐。
这意味着每生成一个checkpoint-50系统必跑一次验证用相同 prompt 测 self-cognition 效果评估结果loss、accuracy、示例输出会写入trainer_state.json和日志文件你打开output/v
/checkpoint-100/时能立刻看到eval_results.json里写着{ eval_loss:
214, eval_samples: 8, eval_runtime:
1
34, eval_samples_per_second:
65 }这才是 checkpoint 的“可信标签”。
没有 eval 结果的 checkpoint就像没试飞过的飞机——你不知道它能不能平稳落地。
实操动作每次训练完别急着 infer先去对应 checkpoint 目录下cat eval_results.json扫一眼 loss 是否持续下降。
如果checkpoint-100的 loss 比checkpoint-50高说明可能过拟合立刻切回去用checkpoint-50推理。
恢复技巧中断≠重来3 步精准续训训练过程中遇到显存溢出、SSH 断连、系统重启别慌。
只要trainer_state.json完整就能从断点继续不丢步数、不重算梯度、不浪费 GPU 时间。
1 第一步确认断点位置进入你的训练主目录如output/v
/执行ls -t checkpoint-*输出类似checkpoint-150 checkpoint-100 checkpoint-50再查看最新 checkpoint 的trainer_state.jsonjq .global_step checkpoint-150/trainer_state.json # 输出150这个150就是已成功完成的总步数也是续训的起点。
2 第二步修改微调命令加入恢复参数原命令swift sft --model Qwen
2.
B-Instruct ... --output_dir output改为仅增加两行CUDA_VISIBLE_DEVICES0 \ swift sft \ --model Qwen
2.
B-Instruct \ --train_type lora \ --dataset self_cognition.json \ --torch_dtype bfloat16 \ --num_train_epochs 10 \ --per_device_train_batch_size 1 \ --per_device_eval_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. \ --warmup_ratio
05 \ --dataloader_num_workers 4 \ --model_author swift \ --model_name swift-robot \ # 新增两行指定从 checkpoint-150 恢复 --resume_from_checkpoint output/v
/checkpoint-150 \ --ignore_mismatched_sizes # 防止因路径微小差异报错关键细节--resume_from_checkpoint必须指向完整路径含output/xxx/checkpoint-xxx不能只写checkpoint-150--ignore_mismatched_sizes是安全垫当模型结构微调后略有变化如新增 token它跳过校验避免中断
3 第三步验证续训是否生效启动后观察日志首行Loading checkpoint from output/v
/checkpoint-150 Resuming training from global step 150接着看 step 计数是否从 151 开始Step: 151/2000 | Loss:
211 | ... Step: 152/2000 | Loss:
209 | ...如果看到Step: 1/2000说明路径错了它当成了全新训练。
经验口诀“看三行日志定生死第一行有Resuming第二行有global step XXX第三行 step 数 XXX —— 续训成功。
”
推理加载checkpoint vs merged选哪个更稳训练完成后你会在output/xxx/下看到两类产物类型路径示例特点适用场景LoRA checkpointoutput/v
/checkpoint-150/仅含 adapter 权重10MB依赖原始模型快速验证、A/B 测试、多身份切换Merged 模型output/v
/merged/LoRA 权重已融合进 Qwen
2.
B生成完整pytorch_model.bin~5GB生产部署、离线使用、跨框架迁移
1 为什么推荐优先用 checkpoint 推理启动快加载 10MB 比加载 5GB 快 10 倍以上swift infer命令秒响应灵活你可以在同一基础模型上同时加载checkpoint-100偏通用和checkpoint-150偏自认知对比效果安全不改动原始模型避免 merge 错误导致基础模型损坏命令就是你文档里写的swift infer \ --adapters output/v
/checkpoint-150 \ --stream true \ --temperature 0 \ --max_new_tokens
2
2 什么时候必须 merge需要导出给 HuggingFace Transformers、vLLM、Ollama 等不支持 LoRA 动态加载的框架要打包成 Docker 镜像交付给客户且客户环境无法保证ms-swift运行时做量化如 AWQ、GPTQ多数量化工具要求输入是完整模型merge 命令在训练完成后自动触发或手动运行swift export \ --ckpt_dir output/v
/checkpoint-150 \ --output_dir output/v
/merged \ --device_map auto重要提醒merge 后的模型仍需指定--model_type qwen否则 infer 会报错。
因为模型结构信息如 rotary base、attention mask 处理不包含在权重里必须由框架注入。
进阶技巧用 checkpoint 做“模型体检”checkpoint 不只是恢复用的它还是你诊断模型健康度的听诊器。
三个实用技巧
1 对比 loss 曲线识别过拟合拐点进入output/xxx/执行grep loss logs/train.log | tail -n 20你会看到类似Step: 130/2000 | Loss:
225 | ... Step: 140/2000 | Loss:
221 | ... Step: 150/2000 | Loss:
218 | ... Step: 160/2000 | Loss:
235 | ← 注意这里上升了 Step: 170/2000 | Loss:
242 | ← 持续上升 → 过拟合信号此时checkpoint-150就是你的“黄金点”。
后续所有推理、merge、测试都基于它而不是最后那个checkpoint-200。
2 提取特定 layer 的 LoRA 变化定位“记忆焦点”LoRA 的lora_A和lora_B矩阵分别作用于 attention 和 FFN 层。
你想知道模型在哪一层“最努力记住了自我认知”用以下代码快速探查import torch adapter torch.load(output/v
/checkpoint-150/adapter_model.bin) # 查看 attention 层 LoRA 的 L2 norm越大表示改动越强 attn_norms [v.norm().item() for k, v in adapter.items() if self_attn in k and lora_B in k] print(Attention layer LoRA strength:, sorted(attn_norms, reverseTrue)[:3]) # 输出类似[
1
4,
1
8,
2] → 说明前三层 attention 被重点调整这能帮你理解为什么模型对“你是谁”回答很准但对“今天天气”却答得生硬——因为 LoRA 主要强化了 self-attention 的 identity 相关通路。
3 一键生成 checkpoint 报告告别手动翻日志把下面脚本保存为check_report.py放在/root/下每次训练完运行它#!/usr/bin/env python3 import os, json, glob from pathlib import Path output_dir output for d in Path(output_dir).glob(v*): if not d.is_dir(): continue checkpoints sorted(d.glob(checkpoint-*)) if not checkpoints: continue print(f\n Report for {d.name}) for cp in checkpoints[-3:]: # 只看最近3个 ts json.load(open(cp / trainer_state.json)) eval_f cp / eval_results.json if eval_f.exists(): ev json.load(open(eval_f)) print(f {cp.name}: step{ts[global_step]}, loss{ev[eval_loss]:.3f}) else: print(f {cp.name}: no eval result (run eval manually))运行python check_report.py输出即清晰Report for v
checkpoint-50: step50, loss
312 checkpoint-100: step100, loss
245 checkpoint-150: step150, loss
0.
2186.
总结checkpoint 选择的本质是工程节奏的掌控选 checkpoint从来不是技术问题而是项目管理问题。
你有多少时间→ 决定save_steps密度你有多少磁盘→ 决定save_total_limit上限你要快速验证还是长期部署→ 决定用checkpoint还是merged你怕中断重来还是怕效果波动→ 决定是否开启eval_steps同步在单卡微调 Qwen
2.