语言模型微调实战（05）：从配置到合并模型
环境和数据就绪，这一篇跑通第一次训练：LoRA SFT → 合并适配器 → 离线评估。「第一次训练」追求的是闭环，不是刷榜。
主流程三步
在容器内依次执行（路径按你的挂载调整）：
1 | # 1) LoRA SFT |
训练配置里最值得盯的字段
任务与方法
1 | stage: sft |
LoRA
1 | lora_rank: 8 |
数据与模板
1 | dataset_dir: /app/LLaMA-Factory/data |
优化与精度
1 | per_device_train_batch_size: 2 |
验证（强烈建议打开）
1 | eval_dataset: <your_val_dataset_name> |
让 save_steps 与 eval_steps 对齐，便于事后对比 checkpoint。
合并配置在做什么
合并不是再训练，而是把 LoRA 权重写回基座：
1 | model_name_or_path: /app/models/<base-model> |
合并后的目录通常包含分片权重与 tokenizer，可独立加载，不必再挂适配器。
训练时你会看到什么
- 进度条与
loss/learning_rate； - 若开启评估：周期性
eval_loss； - 输出目录出现
checkpoint-*、adapter_model.safetensors、training_loss.png等。
第一次跑通的标准：进程正常结束 + 合并目录可加载 + 能跑通评估脚本。效果优化放到下一篇。
中断恢复
若配置了定期保存，可在 YAML 中设置：
1 | resume_from_checkpoint: /app/output/<lora-dir>/checkpoint-xxx |
重跑前清理
避免新旧权重混用：
1 | rm -rf /app/output/<lora-dir> /app/output/<merged-dir> |
小结
「第一次训练」追求的是闭环，不是刷榜。
语言模型微调实战第 05 篇完。下一篇专门讲：如何用日志和验证集判断轮数够不够。
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 WALL-E's Blog！
相关推荐
2026-08-01
语言模型微调实战（00）：系列导读
用 LLaMA-Factory 对 Qwen2.5-3B-Instruct 做一次 LoRA 监督微调（SFT），把「跑通流程 → 看懂评估 → 提升泛化」完整走一遍。这不是官方 README 的摘抄，而是一次可复现实验的方法论复盘。 这个系列讲什么 为什么要微调，而不是直接用基座模型？ SFT 和 LoRA 分别指什么？ 环境怎么搭、配置怎么写？ 训练日志怎么读、轮数怎么选？ 评估指标怎么选、失败案例怎么归因？ 如何用「数据增强 + 推理侧约束」提升结构化输出的可靠性？ 文中示例均为虚构示意，不引用真实业务语料，也不公开任何训练/验证样本。 技术栈（脱敏后） 项目 选型 基座模型 Qwen2.5-3B-Instruct 微调框架 LLaMA-Factory 训练阶段 SFT（监督微调） 训练方法 LoRA 运行环境 Ubuntu + NVIDIA GPU + Docker 数据格式 Alpaca 风格 JSONL（示意） 阅读路线 序号 主题 00 本篇：系列导读 01 为什么要微调，以及整体路线图 02 SF...
2026-08-02
语言模型微调实战（01）：为什么要微调与路线图
通用 Instruct 模型已经很会对话，但接到垂直任务时常常「不够稳」。这一篇先不写命令，而是把「为什么要微调、目标是什么、整条路线怎么走」讲清楚。 基座模型哪里不够？通用 Instruct 模型接到垂直任务时，常见短板是： 行为约束不够稳：角色、口吻、拒答边界容易漂移。 结构化输出不可靠：下游系统需要固定 schema（例如 JSON），模型却经常用自然语言「解释一遍」。 微调的目标，通常就是两件事同时推进： 让模型更贴合任务人设与领域表达； 让模型在「需要结构化输出」时，稳定产出可解析结果。 推荐路线图1234567891011定义任务与输出 schema ↓构造监督数据（Alpaca JSONL） ↓互斥划分 train / val ↓LLaMA-Factory：SFT + LoRA ↓合并适配器 → 完整模型 ↓离线评估 +（可选）推理侧校验 为什么起步用 LoRA，而不是全量微调？因为对中小规模监督数据，LoRA 通常已经够用：显存更省、迭代更快、产物更小。全量微调可以作为后续对比实验...
2026-08-03
语言模型微调实战（02）：SFT 与 LoRA，别把两个概念搞混
常见误区：「我这份数据到底叫 SFT 还是 LoRA？」正确理解是——数据属于 SFT（监督微调）数据，LoRA 是训练方法。这一篇把两个不在同一层的概念彻底分清。 两个词不在同一层 术语 指什么 配置里常见字段 SFT 训练任务：用「输入 → 标准答案」监督模型 stage: sft LoRA 参数高效微调：冻结基座，只训低秩适配器 finetuning_type: lora 所以规范的说法是：用 SFT 数据，做 LoRA 微调。 同一套数据，可以换多种训法 方法 含义 显存压力 备注 LoRA 只训适配器 低 本系列默认 Full 更新全部参数 高 适合更大盘数据或冲上限 QLoRA 量化基座 + LoRA 更低 显存紧张时 换方法时，数据集通常不用重做；主要改配置中的微调类型，以及学习率、batch 等超参。 配置对应关系（示意）1234567stage: sftdo_train: truefinetuning_type: loralora_rank: 8lora_alpha: 16lora_target: all 训练完成后...
2026-08-04
语言模型微调实战（03）：Docker 里跑 LLaMA-Factory
微调的依赖链很长（CUDA、PyTorch、transformers、LLaMA-Factory），容器化能让「昨天能训、今天也能训」。这一篇讲怎么用 Docker 把环境固化下来，并在进容器后先做自检。 你需要什么 类别 建议 系统 Ubuntu（或其他 Linux） GPU NVIDIA GPU，建议 16GB+ 显存（LoRA 微调 3B 量级通常够用） 软件 Docker + NVIDIA Container Toolkit 磁盘 预留足够空间给基础镜像、基座模型与训练输出 具体型号、云厂商、镜像源不必写进文章；按你机器上的实际环境配置即可。 为什么用 Docker 宿主机干净，依赖锁在镜像里； 换机器时更容易复现； 代码与数据通过挂载目录注入，不必 bake 进镜像每一层。 典型目录挂载宿主机项目目录挂到容器内，职责大致如下： 宿主机 容器内 用途 models/ /app/models/ 基座模型（常只读） train_data/ /app/train_data/ 训练/验证数据 output/ /app/...
2026-08-10
语言模型微调实战（09）：部署、复盘与下一步
微调并不神秘：把任务定义清楚，把数据划干净，把训练跑稳定，再用评估驱动下一轮改进。这一篇收束到部署产物、上线检查清单与复盘要点。 你最终该交付什么 产物 说明 LoRA 适配器目录 体积小，需搭配同版本基座加载 合并后的完整模型目录 可独立部署，适合多数推理服务 推理入口 建议默认走 schema 校验；评估脚本可对比「原始 vs 后处理」 合并模型与适配器的关系可以记成： 1基座模型 + LoRA 适配器 --export--> 合并后的完整模型 线上一般加载合并后的完整模型；若要快速试验多个适配器，也可以基座 + 适配器热插拔。 最小上线检查清单 训练配置与评估脚本使用同一套 tokenizer / template 验证集与训练集互斥（流程可审计） 结构化任务用低温度推理 枚举表、训练标签、后处理规则三者一致 有回滚方案（保留上一版 merged 目录） 日志中可区分「模型原始输出」与「后处理输出」（便于排障） 复盘：这套流程真正学到的点 SFT 描述任务，LoRA 描述怎么训——术语别混用。 数据划分错误会制造...
2026-08-08
语言模型微调实战（07）：评估与失败分析
评估的意义不是得到一个「好看的百分比」，而是得到可执行的改进清单。这一篇用抽象案例说明分析方法——不引用真实训练/验证样本原文。 先选对指标 任务类型 更合适的指标 不太合适的指标 结构化输出（JSON / 固定模板） 可解析率、字段完全匹配、枚举合法性 纯字符相似度 开放文本 人工抽检、语义相似度、关键信息覆盖 字符串完全匹配 同一条验证集里若混有两类任务，应分别统计，否则开放文本会把总分拉得很「难看」，掩盖结构化任务其实已经不错的事实。 评估脚本建议具备的能力 加载合并模型（或基座 + 适配器）； 按统一采样参数推理（结构化任务建议低温度，甚至 0）； 分别计算： 结构化：解析成功？字段是否等于期望？ 开放文本：可先只做抽检，避免被严格字符串匹配误导； 导出明细 JSON，便于离线归因（明细同样不要外发）。 失败归因的常见桶把结构化任务的错误先归类，而不是逐条「感觉不对」： 1. 划分导致的「未见过说法」验证集按输入互斥划分后，模型必须靠泛化。若训练集里同类标签的说法覆盖不足，验证集上的近义表达就容易错。 对策：补同义改写与对比...
