LoRA/QLoRA微调7B模型：从数据准备到Loss收敛全记录

1. 背景与动机：为什么是LoRA？

最近接到一个任务：给内部客服系统微调一个7B级模型，让它能准确理解并回答特定产品领域的复杂问题。跑了一遍全参数微调（Full Fine-tune），显存直接飙到140GB，即便用DeepSpeed ZeRO-3也占120GB+，单卡根本跑不了。于是转向参数高效微调（PEFT），LoRA（Low-Rank Adaptation）是首选——它冻结原模型，插入低秩矩阵，只训练新增参数（通常只占原模型0.1%~1%），显存占用能降到20~40GB。

QLoRA更进一步：用4bit量化加载模型，再叠LoRA，单卡80G轻松微调7B。我这套方案就是QLoRA + 双LoRA（Q和V矩阵），效果与Full FT差距极小。

2. 环境与版本

硬件：
- GPU：NVIDIA A100 80G × 1
- 内存：128GB
- 存储：2TB NVMe SSD

软件：
- Python 3.10.12
- PyTorch 2.1.2 + CUDA 12.1
- transformers 4.38.2
- peft 0.9.0
- bitsandbytes 0.43.0
- datasets 2.18.0
- accelerate 0.27.2

安装命令：

pip install torch==2.1.2 torchvision==0.16.2 --index-url https://download.pytorch.org/whl/cu121
pip install transformers==4.38.2 peft==0.9.0 bitsandbytes==0.43.0 datasets==2.18.0 accelerate==0.27.2

基础模型：NousResearch/Llama-2-7b-chat-hf（HuggingFace仓库）

3. 数据准备：3k条高质量领域问答

数据是自己爬取+人工标注的客服对话记录，总计3200条，格式为：

{
  "instruction": "用户提问：我的设备型号是X100，开机后屏幕一直闪烁，怎么办？",
  "input": "",
  "output": "首先检查电源线是否插紧，然后长按电源键10秒强制重启。如问题依旧，请提供设备序列号，我们安排工程师上门检测。"
}

关键处理步骤：

1. 清洗：去掉过短（1024 token）的样本，保留2897条
2. 模板化：按Chat格式包装，使用[INST] {instruction} [/INST] {output}
3. tokenizer设置：设置padding_side="right"，truncation=True，max_length=2048
4. 数据拆分：2600条训练，297条验证

4. 方案设计：QLoRA + 双LoRA

选择QLoRA而非纯LoRA，因为4bit量化让单卡80G能处理batch_size=8（纯LoRA同样配置只能batch=4）。具体配置：

• 量化：4bit NormalFloat（NF4），双量化（double_quant），计算类型bfloat16
• LoRA：r=16，alpha=32，dropout=0.05，target_modules=["q_proj", "v_proj"]
• 优化器：paged_adamw_8bit（节省显存）
• 学习率：3e-4，cosine scheduler，warmup_steps=100
• batch_size：8（gradient_accumulation_steps=1），共325步/epoch
• epoch：3

核心代码片段（训练配置）：

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

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

# 加载基础模型
model = AutoModelForCausalLM.from_pretrained(
    "NousResearch/Llama-2-7b-chat-hf",
    quantization_config=bnb_config,
    device_map="auto",
    trust_remote_code=True
)
tokenizer = AutoTokenizer.from_pretrained("NousResearch/Llama-2-7b-chat-hf")
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "right"

# 准备k-bit训练
model = prepare_model_for_kbit_training(model)

# LoRA配置
lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "v_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: 6,742,609,920 || trainable%: 0.1244

5. 训练过程：Loss曲线与踩坑

5.1 第一个坑：梯度爆炸

第一轮训练，loss在50步后从1.2直接跳到inf。排查发现：部分样本的label中包含了` token（id=0），但模型对这些位置也计算了loss。解决方案：在DataCollator中设置ignore_index=-100，并用-100`屏蔽padding位置的loss。

5.2 第二个坑：过拟合

epoch=2时，训练loss降到0.38，但验证loss从0.52上升到0.61。明显过拟合。我将dropout从0.05提高到0.1，同时把epoch从3降回2.5（即训练2150步后early stop）。调整后验证loss稳定在0.48。

5.3 Loss曲线

训练全程用wandb记录，关键节点：
- 第1步：loss=2.87
- 第100步（warmup结束）：loss=1.34
- 第325步（epoch 1）：loss=0.72，验证loss=0.63
- 第650步（epoch 2）：loss=0.41，验证loss=0.52（开始发散）
- 第812步（early stop）：loss=0.36，验证loss=0.48

训练用时：约3小时20分钟（A100 80G）。显存峰值：42.3GB。

5.4 推理配置

推理时合并LoRA权重：

from peft import PeftModel

base_model = AutoModelForCausalLM.from_pretrained(
    "NousResearch/Llama-2-7b-chat-hf",
    torch_dtype=torch.bfloat16,
    device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained("NousResearch/Llama-2-7b-chat-hf")
tokenizer.pad_token = tokenizer.eos_token

# 加载LoRA适配器
model = PeftModel.from_pretrained(base_model, "./lora_adapter")
model = model.merge_and_unload()  # 合并权重，提升推理速度

# 推理函数
def generate_response(prompt, max_new_tokens=256):
    inputs = tokenizer(f"[INST] {prompt} [/INST]", return_tensors="pt").to("cuda")
    with torch.no_grad():
        outputs = model.generate(
            **inputs,
            max_new_tokens=max_new_tokens,
            temperature=0.7,
            top_p=0.9,
            do_sample=True,
            repetition_penalty=1.1
        )
    return tokenizer.decode(outputs[0], skip_special_tokens=True)

6. 效果数据：准确率从52%到78%

6.1 测试集构造

从原始数据中留出297条作为测试集，另外构造了150条对抗样本（包含歧义、拼写错误、长尾问题）。

6.2 评估指标

• 准确率：回答核心信息完全正确，且无错误信息
• 完整性：回答覆盖问题所有要点（人工评分1-5）
• 指令遵循：是否按要求格式回答

6.3 对比结果

关键发现：
- QLoRA vs Full FT：准确率仅差5.1%，但显存使用降低70%（120GB→42GB）
- 增加LoRA rank从16到32，准确率提升2.3%，但训练时间增加40%
- 双LoRA（Q+V）比单Q好约1.5%，比单V好约3%

6.4 实际对话对比

用户提问：我的设备X100开机闪烁，已经按你说的重启了，还是不行。

原始模型回答：建议检查电源线，或者联系客服。（错误：重复了无用建议，缺少具体后续步骤）

微调模型回答：请提供设备序列号（位于机身底部标签），我们安排工程师远程诊断。如果闪烁持续，可能是屏幕排线松动，建议不要继续使用，等待工程师上门处理。（正确：提供了新步骤，有风险提示）

7. 总结与建议

这次实践证明了LoRA/QLoRA在资源受限场景下的巨大价值。几点经验：

1. 数据质量＞数据量：3k条高质量数据的效果远超10k条粗标数据（前者准确率78%，后者仅61%）
2. LoRA rank不是越大越好：16~32足够，再往上收益递减
3. QLoRA的4bit量化几乎不损失效果（在7B上只差1.8%），省下的显存可以用来增大batch size
4. 必须监控验证loss：我差点被训练loss骗了，以为模型还在收敛，其实已经过拟合

下一步尝试：用QLoRA微调13B模型（单卡80G极限），以及探索DoRA（Weight-Decomposed Low-Rank Adaptation）是否能带来额外提升。

最后提一句：别迷信全参数微调——在垂直领域，LoRA/QLoRA的性价比极高，尤其是在推理时还能保留通用能力（因为基座模型未被破坏）。