7B模型LoRA/QLoRA微调全记录：从数据准备到效果对比

一、为什么不用全量微调：显存和时间的双重暴击

项目需求很明确：把开源7B模型调成懂《劳动合同法》的问答助手。我先试了全量微调，batch_size=1、seq_len=2048的情况下，A100 80G显存直接爆掉——光是优化器状态（AdamW的fp32一阶二阶动量）就要占7B×16字节×2=224GB，更别说梯度了。即便用DeepSpeed ZeRO-3分片，单卡也跑不动。

LoRA（Low-Rank Adaptation）的思路是在冻结原模型权重的同时，只训练注入的低秩矩阵。以秩r=16为例，一个768维的线性层原本要训练768×768=589,824个参数，LoRA只训练768×16+16×768=24,576个，参数量减少96%。QLoRA更进一步，把基座模型量化为4bit NF4格式，显存占用直接砍到原来的1/4。

实际测试：QLoRA（4bit+LoRA）训练时峰值显存21.3GB，LoRA（8bit）是38.7GB，全量微调直接爆显存。时间上，QLoRA每轮迭代约1.2秒，LoRA约2.1秒，全量微调没跑起来就不比了。

二、环境与版本：这些坑我已经替你踩了

我的环境配置如下，建议严格对齐，尤其是bitsandbytes和transformers的版本，否则4bit量化会报错。

Python 3.10.12
torch 2.1.2+cu118
transformers 4.36.2
peft 0.7.1
bitsandbytes 0.41.3
datasets 2.16.1
accelerate 0.25.0
flash-attn 2.3.6（可选，加速用）

特别注意：bitsandbytes 0.41.3 以上才支持4bit NF4格式，transformers 4.36.2 以上才支持load_in_4bit=True参数。之前用transformers 4.31.0，加载4bit模型直接报KeyError: 'quantization_config'。

三、方案设计：数据清洗和LoRA参数选择

3.1 数据准备：质量比数量重要

我从裁判文书网爬了5000条劳动纠纷问答，但原始数据质量堪忧。清洗流程如下：

去重：基于Levenshtein距离，相似度>0.85的只保留一条，去掉约1200条重复。
过滤：长度小于50个字符的样本丢弃（信息量不足），大于2048的截断（超过模型上下文）。
格式统一：统一为"问题：xxx\n回答：xxx"格式，用和包裹。
难例挖掘：从剩余样本中人工挑选200条长尾问题（如“孕期请假被辞退怎么赔偿”），防止模型只学会常见问题。

最终保留3800条训练样本，200条验证集。数据划分用datasets库的train_test_split(test_size=0.05, seed=42)。

3.2 LoRA配置：秩和alpha的平衡

LoRA有两个关键超参：r（秩）和alpha（缩放因子）。我测试了r=8/16/32三组，验证集loss对比如下：

r	alpha	验证loss	训练时间
8	16	1.12	4.2h
16	32	0.87	6.1h
32	64	0.82	9.8h

r=32的loss最低，但训练时间多60%，且推理速度变慢（因为要额外计算两个低秩矩阵的乘积）。最终选r=16/alpha=32，性价比最高。target_modules设置为["q_proj", "k_proj", "v_proj", "o_proj"]，注意gate_proj和up_proj不用加，加了反而容易过拟合。

四、核心实现：两段可运行的代码

4.1 加载4bit模型并配置LoRA

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training

# 4bit量化配置
bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_use_double_quant=True,
    bnb_4bit_compute_dtype=torch.bfloat16
)

# 加载模型，device_map="auto"自动分配显存
model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3-8B",
    quantization_config=bnb_config,
    device_map="auto",
    trust_remote_code=True
)
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3-8B")
tokenizer.pad_token = tokenizer.eos_token  # 关键：设置pad_token，否则训练报错

# 冻结原模型，准备kbit训练
model = prepare_model_for_kbit_training(model)

# LoRA配置
lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM"
)
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()  # 输出: trainable params: 8,388,608 || all params: 8,186,941,440 || trainable%: 0.1024

4.2 训练循环：用transformers的Trainer

from transformers import TrainingArguments, Trainer
from datasets import load_dataset

# 准备数据集
dataset = load_dataset("json", data_files="law_qa.jsonl")["train"]
dataset = dataset.map(lambda x: tokenizer(
    x["text"],
    truncation=True,
    max_length=2048,
    padding="max_length"
), batched=True)

training_args = TrainingArguments(
    output_dir="./law_llama_lora",
    per_device_train_batch_size=4,
    gradient_accumulation_steps=8,  # 等效batch_size=32
    num_train_epochs=3,
    learning_rate=2e-4,
    lr_scheduler_type="cosine",
    warmup_ratio=0.03,
    logging_steps=10,
    save_steps=500,
    evaluation_strategy="steps",
    eval_steps=200,
    save_total_limit=2,
    fp16=True,
    report_to="tensorboard"
)

trainer = Trainer(
    model=model,
    args=training_args,
    train_dataset=dataset["train"],
    eval_dataset=dataset["test"],
    tokenizer=tokenizer
)

trainer.train()
trainer.save_model("./law_llama_lora_final")

注意：gradient_accumulation_steps=8配合batch_size=4，等效batch_size=32，对LoRA训练很重要——batch太小loss震荡大，太大显存不够。学习率2e-4是LoRA的常用值，全量微调一般用1e-5。

五、踩坑与优化：三个教训

坑1：中文分词截断导致loss不降

第一次训练，loss卡在1.8不降。排查发现：Llama-3的tokenizer对中文支持很差，一个“劳动合同法”被切成["劳", "动", "合", "同", "法"]，导致序列长度暴涨，大量样本被截断。解决：用tokenizer.encode("劳动合同法")检查，发现平均每个中文字符占1.5个token。最后把max_length从2048提到4096，但显存不够。换思路：对训练样本做了段落截断，只保留与问题直接相关的3个段落（约800字），loss立刻降到0.9以下。

坑2：样本重复导致过拟合

训练到第2轮，验证loss开始上升，但训练loss还在降——典型过拟合。检查数据发现：清洗时去重阈值0.85太宽松，有300多条样本只是换了个问法，内容几乎相同。用datasets的deduplicate函数重新清洗，阈值提到0.95，过拟合缓解。

坑3：推理时temperature过高

微调后推理，设置temperature=0.9，模型输出“根据《劳动合同法》第四十八条...”，但后半段开始胡编“用人单位应支付三倍工资”之类。改成temperature=0.1、top_p=0.9后，回答准确率大幅提升。经验：微调模型推理，temperature别超过0.3。

六、效果数据：量化对比

6.1 Loss曲线

训练日志记录如下（每50步取样）：

Step 100: loss 1.87, val_loss 2.01
Step 500: loss 1.22, val_loss 1.45
Step 1000: loss 0.94, val_loss 1.12
Step 1500: loss 0.78, val_loss 0.92
Step 2000: loss 0.65, val_loss 0.87
Step 2500: loss 0.58, val_loss 0.89（开始过拟合，提前停止）

最终在Step 2200左右early stop，保存的checkpoint验证loss为0.87。

6.2 推理效果对比

用同一个问题测试微调前后：

问题：“我在公司工作3年，现在怀孕了，公司要辞退我，合法吗？”

微调前（原版Llama-3-8B）：
“根据中国法律，怀孕女职工是受到保护的。但是具体要看劳动合同的约定......（含糊其辞，没有给出明确结论）”

微调后（LoRA版本）：
“根据《劳动合同法》第四十二条，女职工在孕期、产期、哺乳期的，用人单位不得依照本法第四十条、第四十一条的规定解除劳动合同。公司在你怀孕期间辞退你，属于违法解除，你可以要求继续履行合同，或者要求支付赔偿金（双倍经济补偿金）。”

量化指标（200条测试集）：
- BLEU分数：从0.31提升到0.54（提升0.23）
- 人工评测满意率（3名法律专家打分）：从31%提升到78%
- 回答平均长度：从312字降到186字（更精炼）
- 幻觉率（人工标注的“编造法条”占比）：从22%降到6%

6.3 推理速度

LoRA推理时，基座模型参数不变，只额外计算低秩矩阵，速度影响不大：单条推理从1.8秒（原版）变成2.1秒（LoRA），慢了16%但可接受。如果用merge_and_unload()把LoRA权重合并回原模型，速度恢复原版水平。

# 合并权重，加速推理
from peft import PeftModel
merged_model = PeftModel.from_pretrained(model, "./law_llama_lora_final").merge_and_unload()
merged_model.save_pretrained("./law_llama_merged")

七、总结：LoRA/QLoRA的适用边界

这次实践验证了LoRA在小规模垂直领域微调上的性价比：参数量只训练0.1%，却在BLEU和人工评测上分别提升0.23和47个百分点。但也要注意：

数据量别贪多：5000条清洗后剩3800条，足够了。之前试过2万条，过拟合更严重。
目标模块要少：只改attention的四个投影层，别动MLP，效果反而更好。
QLoRA的4bit对精度影响：在问答任务上没明显差异，但如果做数学推理或代码生成，建议8bit LoRA更稳。
合并权重是必须的：部署时用merge_and_unload()合并，否则推理多一步低秩矩阵计算，延迟涨20%。

最后说一句：LoRA不是万能的，如果领域差异极大（比如从通用对话改成金融风控），可能还是得全量微调。但7B模型在单卡上全量微调，除非你有8张A100，否则别碰。QLoRA是当前性价比最优解。

大家在看