LoRA 微调入门：单卡调出自己的模型
什么时候才值得微调
“我想让模型学会我们公司的业务，是不是得微调一个？"——先别急。微调解决的是风格、格式与领域语感的问题：让模型稳定输出规定格式、学会特定口吻、听懂行话。它不擅长往模型脑子里"塞知识”——知识会过期、会记错，改一次就要重训一次。
按成本从低到高排，决策链是这样的：
- 改提示词能解决的，不要动模型，九成需求停在这一步
- 需要接入私有知识、经常更新的，用 RAG（检索增强生成），把检索到的资料现场喂给模型
- 只有当输出风格与格式是硬需求、提示词怎么调都不稳时，才轮到微调
判断下来确实是第 3 类，继续往下看。整个流程的核心原则只有一句：先算显存预算，再选方案——OOM（显存溢出）报错浪费的时间，比前面所有步骤加起来都多。
第一步：数据准备，几百条就够开工
个人微调最大的好消息是：不需要百万级数据。格式与风格类任务（让输出固定成某种 JSON 结构、固定客服口吻），几百到几千条高质量问答对就够；数据质量远比数量重要，500 条干净样本胜过 5000 条脏样本。
格式上主流是 JSONL，一行一条对话：
| |
三条实操建议：
- 从真实记录里挑：客服日志、工单回复、自己的改稿记录，都是现成的高质量语料
- 覆盖边界情况：故意放几条"信息不足、无法回答"的样本，教模型学会拒答
- 先估规模：用 Token 计数与 API 成本计算器数一下数据集的总 Token 量，心里有数再往下走——它也能顺便估算这批数据走云端训练大概要多少钱
还有一个新手常踩的坑：一个适配器只干一件事。想让模型又会写周报又会答客服，拆成两个 LoRA 分别训练，推理时按需切换——比一个"全能"适配器效果好得多，翻车时也更容易定位是哪份数据出了问题。
第二步：算清显存预算，再定方案
微调方案有三档，显存差距是数量级的。以最常被问到的 7B 模型为例：
| 方案 | 显存需求（7B） | 说明 |
|---|---|---|
| 全参微调 | 112GB 起步 | 更新全部权重，效果上限最高，但只有多卡环境跑得动 |
| LoRA | 约 17GB | 冻结原模型，只训注入各层的低秩适配器，训练参数量不到原模型 1% |
| QLoRA | 约 8GB | 底座量化到 4-bit 再做 LoRA，12GB 显卡也能上 |
三个数字的来历：全参微调的经验值约 16GB/1B 参数（见全参微调词条）；LoRA 的显存约为同精度推理的 1.2 倍——7B 模型 FP16 推理约占 14GB，训练就是 17GB 上下（见 LoRA 词条）；QLoRA 约 0.9GB/1B 参数，7B 就是 6.3GB 出头，加上适配器与激活的余量，全程 8GB 左右（见 QLoRA 词条）。
不想心算，直接打开 LoRA 微调显存计算器：选好模型规模与方案，它会按批大小与序列长度给出一份显存账单和显卡建议。**这一步要在写任何训练代码之前做。**还不清楚自己显卡的显存多大，先用 GPU 检测与模型推荐工具读一下型号、显存与 WebGPU 支持。
结论很简单：24GB 卡可以直接 LoRA 7B，12GB 卡用 QLoRA，8GB 卡用 QLoRA 并减小批大小。
第三步：训练关键参数的直觉
LoRA 真正需要盯的参数只有三个：
- r（秩）：适配器的"容量"。任务简单（改格式、改语气）r=8-16 足够，复杂任务可以上 32-64。r 越大越容易过拟合，不是越大越好
- alpha：缩放系数，常取 r 的 1-2 倍，最省心的做法是 alpha = 2r
- 学习率：LoRA 比全参微调可以大一个量级，从 1e-4 到 2e-4 起步；loss 不降就加大，剧烈震荡就减半
其余默认值：训练 2-3 个 epoch 就该停，loss 还在高位横盘的曲线基本没用；批大小受显存约束，装不下就用梯度累积凑等效批大小。每 100 步存一次检查点——微调翻车是常态，检查点是唯一的后悔药。
第四步：合并与使用
训练产出是一个小的适配器文件（通常几十 MB），两种用法：
- 加载适配器：推理时"底座 + 适配器"一起加载，不同任务可以随时切换适配器
- 合并导出：把适配器合并进底座权重，导出 GGUF 量化后丢给 Ollama 或 LM Studio 日常使用
上线前务必留 20 条训练时没用过的测试问题做回归验证——拿训练数据自测等于开卷考试，分数没有任何意义。后续数据积累到一定量（比如翻了一倍），带着全部数据重训一遍，通常比在旧适配器上继续训练更干净。部署环节和量化档位怎么选，参考《16G 内存 Mac 怎么跑本地大模型》，流程完全通用。
常见问题
微调后模型"变笨了"怎么办？
典型的灾难性遗忘：只喂了任务数据，通用能力被冲掉了。三个解法：训练数据里掺 10%-20% 通用对话数据；减少 epoch；降低学习率。
训练到一半 OOM 怎么办？
按顺序做：批大小减半 → 序列长度截短 → r 调小 → 换 QLoRA。每改一项就回到显存计算器重新对账，别靠反复试错硬撞。
到底多少条数据才够？
格式与风格类任务，300-500 条通常就能看到明显效果。知识类需求别用微调硬扛——知识一更新就得重训，切回 RAG 更合适。
小结
整个流程一句话：先判断值不值得微调，再算清显存预算，然后几百条数据起步。本地跑大模型场景专题里收集了从硬件检测、成本对比到显存估算的全套工具，配合使用即可。
微调的门槛从来不在代码——训练脚本到处都是——而在数据是否干净、预算是否算清。把这两件事做对，单卡调出自己的模型是一件相当可行的事。