小参数模型微调实测：LoRA、QLoRA 显存与效果对比

手头只有一张 24G 显存的卡，想微调 7B/13B 模型，实测了 LoRA 和 QLoRA，供参考。

一、实验设置
- 基座：7B 和 13B 各一款开源模型
- 数据：约 2 万条领域问答
- 对比方案：全参数微调（只在 7B 上试）、LoRA（r=16）、QLoRA（4bit 量化 + LoRA）

二、显存占用（batch size=4，序列长度 2048）
- 7B 全参数：约 60G+，24G 卡直接 OOM
- 7B LoRA：约 18G，可跑
- 7B QLoRA：约 10G，很宽松
- 13B QLoRA：约 16G，24G 卡能跑，batch 别太大

三、训练速度
QLoRA 比 LoRA 慢约 30%，主要是量化/反量化的开销。能接受。

四、效果对比（领域测试集，人工抽查 200 条）
- LoRA 和 QLoRA 的回答质量肉眼几乎无差别
- 全参数微调略好一点，但差距不值得多花的显存和时间
- r 从 16 加到 64，提升不明显；数据质量比秩重要得多

五、结论
24G 卡：7B 用 LoRA，13B 用 QLoRA，是最省心的组合。数据清洗花的每一分钟，都比调参超参数值。

你们在消费级显卡上微调，遇到过什么诡异问题？比如 loss 正常但生成全是乱码那种。

【管理员回复】感谢分享完整的实测记录，24G 卡上“7B 用 LoRA、13B 用 QLoRA”的结论很实用。补充几点经验：一是 QLoRA 建议用 NF4 量化配合双重量化，并开启梯度检查点，显存还能再省一截，代价是速度进一步变慢；二是你提到的“loss 正常但生成乱码”，常见原因有聊天模板与训练时不一致、pad token 与 eos token 设置混用、合并 LoRA 权重时基座精度不一致（例如在 4bit 基座上直接合并），排查时可先不合并、用适配器方式推理对比；三是学习率对 LoRA 比 rank 更敏感，可以先扫学习率。你这 2 万条数据是单轮问答还是包含多轮对话？

补充一下我们这边的实测细节。QLoRA 那边确实用的 NF4 加双重量化，梯度检查点也开了，13B QLoRA 压到 16G 主要就靠这两项。代价是训练速度比 LoRA 又慢一截，不过 2 万条数据量下总耗时还能接受，数据量再大就要权衡时间成本了。

乱码这块我们也踩过，排查思路跟你说的完全一致：先不合并 adapter，用 peft 直接加载推理对比。如果 adapter 推理正常、合并后乱码，问题就在合并环节（比如在 4bit 基座上直接合并）；如果都不正常，就从聊天模板和 tokenizer 设置查。pad token 与 eos token 混用是另一个常见坑，训练时 pad 的部分如果进了 loss 计算，生成端很容易输出乱码。

学习率这点非常同意。r 从 16 加到 64 效果几乎没变化，但学习率从 2e-4 降到 5e-5 后生成明显更稳。所以先扫学习率再动 rank，是最省卡时的顺序。

数据是单轮领域问答，平均 800 token 左右，没有多轮对话。batch size=4、seq 2048 的设定下 7B LoRA 刚好 18G。如果换成多轮对话，padding 浪费会大很多，24G 卡跑 13B 估计得把 batch 降到 2。

可以试试从信号完整性仿真入手，我们当时就是这么找到根因的。

CUDA开发_小李 您好，硬件视角很有价值，排查时确实应该先把硬件嫌疑排除掉。我们的经验是先软件后硬件：loss 正常但生成乱码，QLoRA 场景下大概率出在合并环节——比如在 4bit 基座上直接合并 adapter，或者 tokenizer 与基座不一致；先用 peft 不合并直接加载推理对比，基本能定位。硬件侧 nvidia-smi 看 ECC 计数和 Xid 报错、dmesg 查 PCIe AER，再换张卡复跑一次，半小时就有结论。信号完整性仿真属于重武器，一般是链路频繁降速、训练无故中断才用得上；单卡 loss 曲线正常的情况下，软件原因的概率要大一个数量级。