大多数人微调大模型应该从 LoRA 开始而不是全量微调。LoRA 只训练一小部分附加参数训完得到的是几十到几百 MB 的 adapter基座模型不变显存友好。显存不够时按顺序尝试batch 改 1、加大梯度累积、缩短 cutoff_len、上四 bit 量化、换更小模型。LoRA 训完不是完整模型部署时要「基座加 adapter」或先 merge。一、为什么很少人一上来就全量微调七 B 量级的大模型如果所有参数都参与更新显存占用非常可观往往需要多张高端显卡。对个人学习者、小团队和业务验证来说这条路的成本和门槛都偏高。LoRA 的思路很务实不动整个模型只在部分层加一小撮可训练参数叫做 adapter。训练完成后你得到的是体积很小的 adapter 文件基座模型仍然是 Hugging Face 上那个原样。对个人、小团队、第一次做项目LoRA 应该是默认首选而不是备选项。yaml 里典型写法是 finetuning_type: loralora_rank: 8lora_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。不要和显存较劲把精力放在数据和评估上回报更高。