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，显存压力陡增且泛化变差；
