Llama-Factory 部署常见错误与解决方案
在大模型落地日益加速的今天,越来越多团队开始尝试对主流 LLM 进行微调以适配自身业务场景。然而,从 Llama、Qwen 到 ChatGLM,不同架构的模型背后是五花八门的训练脚本、参数配置和依赖环境——稍有不慎,就会陷入'显存爆炸'、'加载失败'或'训练不动'的泥潭。
Llama-Factory 统一支持数十种主流大模型,集成了全参微调、LoRA、QLoRA 等多种策略,并提供了直观的 WebUI 界面。尽管强大,实际部署中依然有不少问题需要注意。
全参数微调:性能天花板背后的资源代价
全参数微调更新预训练模型的所有权重,理论上能带来最强表达能力,适合数据量大、任务复杂的场景。
以 LLaMA-7B 为例,FP16 精度下仅模型权重就占约 14GB,加上梯度、优化器状态和激活值,单卡难以承载。若 batch size 稍大,OOM 警告会立即弹出。
命令行示例:
python src/train_bash.py \
--stage sft \
--model_name_or_path meta-llama/Llama-2-7b-hf \
--do_train \
--finetuning_type full \
--per_device_train_batch_size 4 \
--gradient_accumulation_steps 8 \
--fp16
建议检查以下几点:
- 显存是否充足?双卡 A100 80G 勉强可行,RTX 3090 较难;
- 数据集规模?小样本上全参微调极易过拟合;
- 是否开启
gradient_checkpointing?可节省近 40% 激活内存; - 学习率设置?一般建议 2e-5 左右,过高易震荡。
在 training_args.yaml 中加入以下配置:
gradient_checkpointing: true
optim: "adamw_torch"
lr_scheduler_type: "cosine"
warmup_ratio: 0.1
确保 HuggingFace 缓存路径指向高速 SSD。建议使用 deepspeed 进行多卡并行,配合 zero-stage 2 降低显存占用。若非科研刷榜或企业级定制需求,LoRA 效果已非常接近且资源消耗更低。
LoRA:高效微调的性价比之王
LoRA 专为资源受限环境设计,通过在原始权重旁插入低秩矩阵 $ \Delta W = BA $,训练时只更新这两个小矩阵,主干参数完全冻结。
命令示例:
python src/train_bash.py \
--model_name_or_path meta-llama/Llama-2-7b-hf \
--finetuning_type lora \
--lora_target q_proj,v_proj,k_proj,o_proj \
--rank 64 \
--lora_alpha 128 \
--per_device_train_batch_size 8
这意味着在注意力层的 Q/K/V/O 投影上添加 LoRA 模块,rank=64 决定新增参数总量约为原模型的 0.6%。原本需要 80GB 显存的任务,现在一张 A6000 即可运行。
常见问题排查:
- target layer 选得太多:除 q/v/k/o 外又加了 gate_proj/up_proj,导致适配器破坏原有语义结构;
- rank 设置过高:直接用了 128,显存压力陡增且泛化变差;

