1. 问题背景：为什么不用全参微调？

上周接到一个需求：对电商评论做细粒度情感分类（好评/差评/中评，且要区分“物流慢但质量好”这种混合情感）。我第一反应是直接全参微调Llama-2-7B-chat，结果刚启动训练就看到显存报警——全参微调7B模型，光优化器状态就要占16G+，加上梯度、激活值，单卡A100-40G都吃得紧，更别说我们组只有两张3090。

同事老张一句话点醒我：“用LoRA啊，显存直接砍半，QLoRA能砍到1/4。” 于是有了这篇实践记录。

2. 环境与版本（血泪教训）

先说版本，这坑我踩了两天：

Python 3.10.13
torch 2.1.2+cu118
transformers 4.38.2
peft 0.10.0
bitsandbytes 0.43.1
datasets 2.17.0
accelerate 0.27.2

注意：peft 0.9.0及以下版本对QLoRA的nf4量化支持有bug，会报Unsupported quantization type错。bitsandbytes 0.43.x必须搭配torch>=2.1，否则CUDA算子加载失败。

3. 方案设计：LoRA vs QLoRA

核心思路：冻结原模型，只训练注入的低秩矩阵。

LoRA：权重更新量ΔW = BA，B∈R^(d×r)，A∈R^(r×d)，r=8/16/32。训练时只更新A和B，显存占用主要来自激活值。

QLoRA：在LoRA基础上，把预训练权重4bit量化（NF4类型），同时引入双重量化和分页优化器，显存再降一档。

我的选择：先用LoRA跑通流程，再用QLoRA对比。任务用cardiffnlp/twitter-roberta-base的6分类情感标签映射到3分类（好评/中性/差评），训练集2.4万条，验证集3000条。

4. 核心实现：数据准备与训练配置

4.1 数据准备（关键：格式匹配）

7B模型输入模板必须匹配其chat格式，否则loss不下降。Llama-2的模板是：

B_INST, E_INST = "[INST]", "[/INST]"
B_SYS, E_SYS = ">\n", "\n>\n\n"

def format_prompt(text, label):
    system_prompt = "Classify the sentiment as positive, neutral, or negative."
    user_prompt = f"Text: {text}\nSentiment:"
    return f"{B_INST} {B_SYS}{system_prompt}{E_SYS}{user_prompt} {E_INST} {label}"

4.2 训练配置（LoRA版）

from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from datasets import load_dataset

# 加载模型（LoRA用16bit，QLoRA用4bit）
model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-2-7b-chat-hf",
    torch_dtype=torch.float16,
    device_map="auto",
    use_cache=False  # 训练时必须关，否则显存爆炸
)

# LoRA配置
lora_config = LoraConfig(
    r=16,              # 秩
    lora_alpha=32,     # 缩放系数
    target_modules=["q_proj", "v_proj", "k_proj", "o_proj"],  # 只改注意力层
    lora_dropout=0.1,
    bias="none",
    task_type="CAUSAL_LM"
)

model = prepare_model_for_kbit_training(model)
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()  # 输出：trainable params: 8,388,608 || all params: 6,738,415,616 || trainable%: 0.1245

training_args = TrainingArguments(
    output_dir="./lora_sentiment",
    per_device_train_batch_size=4,
    gradient_accumulation_steps=8,   # 等效batch=32
    learning_rate=2e-4,
    warmup_steps=100,
    num_train_epochs=3,
    logging_steps=50,
    eval_steps=200,
    save_steps=500,
    fp16=True,
    report_to="tensorboard",
)

QLoRA的改动只有一行：把load_in_4bit=True加进from_pretrained，并加bnb_4bit_compute_dtype=torch.float16。

4.3 踩坑：loss不下降的元凶

跑第一个epoch时loss卡在1.1不降，排查半天发现是数据填充问题——tokenizer.pad_token未设置，导致pad位参与了loss计算。修复：

tokenizer.pad_token = tokenizer.eos_token
# 并在Trainer里设置
data_collator = DataCollatorForSeq2Seq(tokenizer, padding=True, label_pad_token_id=-100)

5. 训练过程：loss曲线与显存实测

5.1 显存对比（nvidia-smi实测）

方案 峰值显存 训练时间/epoch 备注
全参微调 38.2G 42min 需要A100
LoRA (r=16, fp16) 21.4G 18min 3090可跑
QLoRA (4bit, r=16) 6.2G 22min 3060ti可跑

5.2 loss曲线特征

  • LoRA：loss从1.35降到0.42，在step 1200后趋于平缓。
  • QLoRA：收敛略慢（step 1500才到0.51），但最终val_loss只比LoRA高0.06。
  • 关键：学习率2e-4比默认1e-5快3倍收敛，但超过5e-4就震荡。

6. 推理效果对比：LoRA/QLoRA vs 全参微调

测试集1200条，对比指标：

模型 Accuracy Macro-F1 推理延迟(ms/条)
原版Llama-2-7B-chat 0.52 0.47 38
全参微调 0.87 0.85 42
LoRA微调 0.86 0.84 41
QLoRA微调 0.85 0.83 40

结论：QLoRA在显存降低70%的情况下，只损失1个点的F1，推理延迟几乎无差异。

6.1 一条典型案例

输入："手机颜值高，但充电口松了"

  • 原版：Positive（被“颜值高”误导）
  • LoRA/QLoRA：Mixed（正确识别“但”转折）

这归功于LoRA对注意力头的微调——q_proj和v_proj的秩16矩阵学到了转折词的句法模式。

7. 踩坑总结与优化建议

  1. pad_token必须设置，否则loss虚低。
  2. QLoRA别用device_map="auto"，手动指定device_map={"": 0}避免量化层被分散到CPU。
  3. 推理时合并LoRA权重：model = model.merge_and_unload()，可减少10%推理延迟。
  4. 如果显存不够，把per_device_train_batch_size减到1，梯度累积提到16。
  5. 数据量小（<1万条），r=8就够了，r=16容易过拟合。

8. 总结

LoRA/QLoRA不是魔法，它用1%的可训练参数换来了接近全参微调的效果。对我来说，QLoRA最大的价值不是省显存，而是让消费级显卡也能微调7B模型——我们组现在用一张3060ti就能做实验，迭代速度翻倍。如果你还在纠结全参微调的显存问题，不妨试试这条路。

最后提醒：模型量化后输出会略微“机械”（比如重复标点），如果做生成任务，建议推理时用temperature=0.7缓解。