大模型学习笔记 · 第五篇 · LoRA 与省显存训练

大多数人微调大模型，应该从 LoRA 开始，而不是全量微调。LoRA 只训练一小部分附加参数，训完得到的是几十到几百 MB 的 adapter，基座模型不变，显存友好。显存不够时，按顺序尝试：batch 改 1、加大梯度累积、缩短 cutoff_len、上四 bit 量化、换更小模型。LoRA 训完不是完整模型，部署时要「基座加 adapter」或先 merge。

一、为什么很少人一上来就全量微调

七 B 量级的大模型，如果所有参数都参与更新，显存占用非常可观，往往需要多张高端显卡。对个人学习者、小团队和业务验证来说，这条路的成本和门槛都偏高。

LoRA 的思路很务实：不动整个模型，只在部分层加一小撮可训练参数，叫做 adapter。训练完成后，你得到的是体积很小的 adapter 文件，基座模型仍然是 Hugging Face 上那个原样。对个人、小团队、第一次做项目，LoRA 应该是默认首选，而不是备选项。

yaml 里典型写法是 finetuning_type: lora，lora_rank: 8，lora_target: all。看到训练日志里可训练参数只占全模型的百分之零点几，这是正常现象，不是配置错了。

二、三个参数，够你理解八成

lora_rank 可以理解成 adapter 的容量，越大通常越强，也越吃显存。入门先试 8，需要再调到 16 或 32。

lora_alpha 是缩放强度，常设为 rank 的一到两倍，不写时框架会按默认规则处理。

lora_target 决定在哪些层加 LoRA。不确定时写 all 最省心，让框架帮你选。

不必一开始就被 LoRA 的论文公式困住。把它想成「在模型旁边挂一个小外挂，专门学你的任务」，就够用很久了。

三、显存大概是什么量级

以下只是七 B、四 B 量级、batch 为 1 时的经验参考，实际还受 cutoff_len 和显卡型号影响。

LoRA 加 bf16，十六到二十四 G 显存通常比较从容。LoRA 加四 bit 量化，也就是 QLoRA，八到十二 G 也有机会跑起来。全量微调则往往需要多卡。

如果一训练就 OOM，不要硬扛，按下面顺序救。

四、显存不够时的救命顺序

第一步，把 per_device_train_batch_size 设为 1，同时增大 gradient_accumulation_steps。这样每次只喂一条样本，但累积多步再更新，等效 batch 并不小，显存却省很多。

第二步，缩短 cutoff_len，比如从 2048 降到 1024。客服 FAQ、短对话场景，1024 往往够用。

第三步，上四 bit 量化。可以用 examples/train_qlora/ 下的 yaml，或在配置里加 quantization_bit: 4，需要先安装 bitsandbytes 相关依赖。

第四步，换更小模型。七 B 换四 B 或三 B，有时比在一卡上硬挤量化更省心。

这个顺序背后的逻辑是：先动训练策略，再动模型精度，最后动模型大小。

五、LoRA 训完，你手里到底是什么

output_dir 里主要是 adapter_config.json 和 adapter_model.safetensors，体积小，拷贝方便。使用时有两条路：推理配置里同时指定基座路径和 adapter 路径，直接加载；或者用 llamafactory-cli export 合并成完整模型，交给更习惯「单目录部署」的平台。

不要误以为 LoRA 训完就得到了一个可以独立拷贝的完整大模型。基座仍然在原处，adapter 是你训出来的「差分」。

六、什么时候才值得考虑全量微调

公司有充足 GPU，且已经验证 LoRA 的效果触顶。领域差距极大，需要改动大量参数才能收敛。研究或竞赛场景，追求极致指标。

对应配置在 examples/train_full/。对个人学习和大多数业务验证，全量微调不是第一站。

七、其他省显存手段，知道即可

flash_attn: fa2 在支持的显卡上能省显存、加速训练，4090、A100 这类卡值得开。use_unsloth: true 在部分模型上能进一步加速 LoRA，需要额外依赖。多卡训练在第八篇会讲，两张卡以上时框架通常会自动分布式。

对个人学习者，最稳的组合仍然是 batch 为 1、梯度累积、LoRA。不要和显存较劲，把精力放在数据和评估上，回报更高。