7B模型单卡LoRA微调全记录：从QLoRA配置到损失收敛与推理对比

一、为什么不用全量微调，而选QLoRA？

先交代背景。业务上需要把7B模型适配到电商评论情感分类（三分类：正向/中性/负向）。全量微调7B在单卡上基本不现实——bf16下光参数就要14G显存，加上优化器状态（AdamW需要8倍参数内存），24G卡只能塞下batch_size=1，训练速度慢到怀疑人生。

LoRA的思路是冻结原模型，只训练注入的低秩矩阵。但标准LoRA在7B上仍需要加载bf16权重（14G），留给梯度和激活的空间依然紧张。QLoRA把基座模型量化到4-bit（NF4类型），显存占用直接砍到5-6G，省下的显存全给batch_size和序列长度。我这次用的配置：量化4bit + LoRA rank=64，实际显存峰值19.8G，刚好卡在4090的甜点区。

结论：单卡微调7B，QLoRA是性价比最高的方案。效果上，4-bit量化+LoRA的组合在分类任务上基本追平全量微调（后面有数据）。

二、环境与版本说明

先把环境列清楚，避免版本坑：

torch==2.1.2
transformers==4.38.2
peft==0.9.0
bitsandbytes==0.43.1
datasets==2.17.1
accelerate==0.27.2

基座模型用Qwen/Qwen2-7B（不是chat版，因为分类任务不需要对话模板）。量化依赖CUDA 11.8，bitsandbytes在0.43版本之后才稳定支持4-bit NF4。如果你用transformers 4.36以下的版本，BitsAndBytesConfig的API会不兼容，建议直接上最新的。

三、方案设计：QLoRA配置和LoRA参数选择

核心思路：基座模型4-bit量化冻结，注入LoRA适配器（作用于attention层的q_proj、k_proj、v_proj、o_proj和MLP层的gate_proj、up_proj、down_proj）。

LoRA参数的选择我纠结了很久，最终拍板：

• rank=64：7B模型用rank=64不算激进，分类任务需要较强的表达力。rank=16试过，F1掉2个点。
• alpha=128：常规是rank的2倍，实测alpha=128比64收敛快15%左右。
• dropout=0.05：防过拟合，训练集2.1万不算大。

量化配置：

from transformers import BitsAndBytesConfig

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_use_double_quant=True,
    bnb_4bit_compute_dtype=torch.bfloat16
)

注意bnb_4bit_compute_dtype必须设成bf16，否则4-bit矩阵乘法在fp16下会溢出，loss直接变NaN。

四、核心实现：数据准备与训练代码

数据格式很简单，就是text和label两个字段。做了一点清洗：去掉URL、HTML标签，长度超过512的截断。标签映射：负向=0，中性=1，正向=2。训练集2.1万，验证集3000，类别分布基本均衡。

训练配置：

from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from transformers import TrainingArguments, Trainer

lora_config = LoraConfig(
    r=64,
    lora_alpha=128,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="SEQ_CLS",
    num_labels=3
)

training_args = TrainingArguments(
    output_dir="./qwen7b_lora_ckpt",
    per_device_train_batch_size=4,
    gradient_accumulation_steps=8,  # 等效batch_size=32
    learning_rate=2e-4,
    warmup_ratio=0.03,
    num_train_epochs=3,
    logging_steps=50,
    eval_strategy="steps",
    eval_steps=200,
    save_strategy="steps",
    save_steps=500,
    fp16=True,
    gradient_checkpointing=True,
    optim="paged_adamw_8bit",  # 关键：分页优化器，避免显存碎片
    lr_scheduler_type="cosine",
    max_grad_norm=0.3,
    load_best_model_at_end=True,
    metric_for_best_model="eval_f1"
)

两个关键点：

1. gradient_checkpointing必须开，否则激活值占的显存比模型还大。开启后训练时间增加约20%，但显存省4-5G。
2. optim用paged_adamw_8bit，这是QLoRA论文里的配套方案，把优化器状态放到CPU内存分页，减少GPU显存压力。实测比普通adamw省2G显存。

加载模型和训练：

model = AutoModelForSequenceClassification.from_pretrained(
    "Qwen/Qwen2-7B",
    quantization_config=bnb_config,
    device_map="auto",
    num_labels=3
)
model = prepare_model_for_kbit_training(model)
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()  # 可训练参数: 33,554,432 / 7,748,170,496 ≈ 0.43%

trainer = Trainer(
    model=model,
    args=training_args,
    train_dataset=train_ds,
    eval_dataset=eval_ds,
    compute_metrics=compute_metrics
)
trainer.train()

五、踩坑与优化：loss震荡和过拟合

训练过程中遇到两个问题：

问题1：前100步loss不降反升

从初始的1.2升到1.8，然后才掉头下降。排查发现是学习率2e-4对7B来说偏大，加上warmup只有3%（约90步），前期参数更新太猛。解决：把warmup_ratio提到0.06（约180步），loss曲线明显平滑。

问题2：验证集loss在第600步开始反弹

训练集loss还在降，但验证集loss从0.35涨到0.39。典型过拟合信号。对策：把LoRA dropout从0.05提到0.1，同时early stopping patience设为3（即连续3次eval不改善就停）。最终在680步触发early stopping，验证集loss停在0.31。

六、效果数据：loss曲线和推理对比

Loss曲线关键节点：

推理效果对比：

基座模型（Qwen2-7B）直接做分类，输出经常是长句子，需要解析才能拿标签，F1只有0.72。微调后的模型输出干净利落，直接是正向、中性、负向。

举两个实际例子：

输入1："手机到手三天就黑屏，客服态度还特别差，退款流程走了一周没动静"

• 基座输出："根据您的描述，这属于产品质量问题，建议您联系客服处理。同时，根据三包规定，您有权要求退货。总体来看，这是一个负面体验。"（需要额外逻辑解析）
• 微调后输出：负向（置信度0.97）

输入2："价格实惠，屏幕显示细腻，电池续航一天没问题，就是充电速度略慢"

• 基座输出："从价格、显示和续航来看，整体评价偏向正面，但充电速度可能影响部分用户体验。"（模棱两可）
• 微调后输出：正向（置信度0.89）

单条推理耗时：微调后模型在4090上约35ms（batch=1，序列长度128），基座约40ms，几乎没有性能损耗。模型体积从原始14G（bf16）降到训练时的6.2G（4-bit），合并LoRA权重后导出为8.5G的fp16模型，部署压力小很多。

七、总结

QLoRA单卡微调7B的路线是跑通的，关键参数组合：4-bit NF4量化 + rank=64 + alpha=128 + 等效batch_size=32 + 2e-4学习率 + cosine调度。最终效果：F1从0.72→0.91，训练耗时约4.2小时（4090上680步）。如果你也在做类似的分类任务，这套配置可以直接抄。但注意两点：一是任务越复杂（比如生成式任务），rank可能需要调到128甚至256；二是QLoRA对长文本（>1024 token）支持不好，量化误差会被放大，那种场景建议用标准LoRA+bf16。