一、问题背景：为什么我放弃了全参微调

上周接到一个医疗问答系统需求，需要在私有知识库上微调Llama-2-7B。起初直接全参微调，发现几个致命问题：
1. 显存占用接近47GB，A100勉强跑得动，但公司只分配了1张卡
2. 每轮训练耗时2.4小时，迭代实验周期太长
3. 全参微调后模型出现严重的灾难性遗忘，通用能力掉点明显

后来改用LoRA，同样的数据量训练时间缩短到1.9小时/epoch，显存降到9.3GB。更重要的是，冻结原始权重后，模型在通用任务上的表现几乎不受影响。这篇文章把完整流程和踩坑记录分享出来，给同样在折腾7B模型微调的朋友参考。

二、环境与版本

torch==2.1.2
transformers==4.36.2
peft==0.5.0
datasets==2.16.1
accelerate==0.25.0
bitsandbytes==0.41.3

注意几个版本坑：
- peft 0.5.0必须配transformers 4.36+，否则prepare_model_for_kbit_training会报错
- bitsandbytes在0.41.3版本后对A100支持稳定，之前版本在4bit量化时偶发CUDA error
- 建议用pip install -U peft transformers，别用conda源，版本经常滞后

三、方案设计：QLoRA还是LoRA？

先说结论：数据量在10万条以下，直接LoRA足够。QLoRA虽然显存更低（4bit量化后约6.2GB），但我在实验中遇到两个问题：
1. 4bit量化后推理速度下降约15%，部署时还得反量化
2. 训练时loss曲线抖动比LoRA严重，需要调低学习率到2e-4才能稳定

最终选择：LoRA + 8bit量化。配置如下：

from peft import LoraConfig, get_peft_model, TaskType
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig

bnb_config = BitsAndBytesConfig(
    load_in_8bit=True,
    bnb_8bit_quant_type="nf8",
    bnb_8bit_use_double_quant=True,
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-2-7b-chat-hf",
    quantization_config=bnb_config,
    device_map="auto",
    torch_dtype=torch.bfloat16,
)

lora_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=8,
    lora_alpha=16,
    lora_dropout=0.05,
    target_modules=["q_proj", "v_proj"],  # 关键：别加k_proj和o_proj
    bias="none",
)

model = get_peft_model(model, lora_config)
model.print_trainable_parameters()  # 输出: trainable params: 4,194,304 || all params: 6,738,415,616 || trainable%: 0.0623

为什么target_modules只用q_proj和v_proj？ 我实验过加k_proj和o_proj，参数量翻倍到838万，但CMB分数只提升0.3，训练时间却增加40%。对于7B模型，q和v的投影矩阵已经能捕捉大部分领域知识。

四、数据准备与处理

医疗问答数据来自公开的CMB数据集，原始数据3.2万条，格式为{"question": "...", "answer": "..."}。清洗流程：

  1. 去HTML标签：因为有大量答案包含``标签
  2. 长度过滤：去掉question小于5字或answer大于512字的样本（避免embedding截断）
  3. 指令模板：统一转为chat格式
def format_example(example):
    prompt = f"""你是一位专业的医疗顾问，请根据以下问题给出准确、详细的回答。

问题：{example['question']}

回答："""
    return {
        "text": prompt + example["answer"] + tokenizer.eos_token,
        "length": len(tokenizer.encode(prompt + example["answer"]))
    }

dataset = dataset.map(format_example)
dataset = dataset.filter(lambda x: x["length"] <= 1024)

这里有个隐藏坑：tokenizer的padding方向。Llama-2的tokenizer默认是padding_side="right"，但在batch训练时，右侧padding会导致attention mask无法正确覆盖padding位置，从而让loss计算包含无效token。我在实验中发现，用padding_side="left"后训练loss下降更平滑，最终评价指标平均提升2%。

另外，必须设置truncation=True，否则长度超过1024的样本会报错。

五、训练配置与Loss曲线分析

核心训练参数：

training_args = TrainingArguments(
    output_dir="./lora_medical",
    num_train_epochs=3,
    per_device_train_batch_size=4,
    gradient_accumulation_steps=8,  # 等效batch size=32
    learning_rate=2e-4,
    lr_scheduler_type="cosine",
    warmup_steps=200,
    logging_steps=50,
    save_strategy="epoch",
    fp16=True,
    gradient_checkpointing=True,
    optim="paged_adamw_8bit",
)

关键点：学习率与lora_alpha的关系。LoRA的缩放因子是alpha/r，当r=8，alpha=16时，实际缩放为2。如果学习率不用2e-4而用默认的5e-5，在第一个epoch内loss几乎不下降。我实验发现，对于7B模型，LoRA学习率应该比全参微调大3-5倍，因为梯度只更新0.06%的参数量。

Loss曲线：前200步（warmup阶段）loss从2.1缓慢下降到1.8，200-500步快速下降到0.9，500步后进入平台期，最终稳定在0.72。注意观察loss是否出现周期性波动——如果每几百步loss突然跳升0.2，多半是QK-norm位置没设对，需要检查config.json里是否有normalize_qk字段，如果没有，在AutoConfig.from_pretrained时手动加config.normalize_qk=True。

六、推理效果对比与踩坑记录

训练完成后，用model.generate对比基础模型和微调后的效果：

from transformers import GenerationConfig

base_model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-2-7b-chat-hf",
    device_map="auto",
    torch_dtype=torch.bfloat16,
)

gen_config = GenerationConfig(
    max_new_tokens=256,
    do_sample=True,
    temperature=0.7,
    top_p=0.9,
)

def generate(model, prompt):
    inputs = tokenizer(prompt, return_tensors="pt").to("cuda")
    outputs = model.generate(**inputs, generation_config=gen_config)
    return tokenizer.decode(outputs[0], skip_special_tokens=True)

# 测试样例
test_prompt = "患者男，45岁，持续胸痛2小时，伴大汗，心电图示ST段抬高，请问最可能的诊断是什么？"
print("基础模型：", generate(base_model, test_prompt)[:200])
print("微调模型：", generate(peft_model, test_prompt)[:200])

对比结果：

指标 基础模型 LoRA微调后
CMB-F1 0.31 0.61
CMB-BLEU 5.2 12.8
回答长度 平均380字 平均214字
事实错误率 34% 12%

三个踩坑记录：

  1. 推理时忘记合并LoRA权重：如果直接用peft_model.generate()，速度比合并后的慢4倍。需要model = model.merge_and_unload()后再推理，显存占用不变，但生成速度从18 tokens/s提升到51 tokens/s。

  2. 领域数据污染问题：微调后模型在OpenBookQA等通用知识测试上掉点5%，但用peft的disable_adapter()可以随时切回原始权重，这个功能很实用。

  3. 中文标点符号问题：原始tokenizer对中文标点支持不好，微调后回答会混用中英文标点。需要在数据处理阶段统一转成全角标点，否则生成结果看起来不专业。

七、总结

这套流程最终交付的效果：单卡A100上，3个epoch耗时5.7小时，模型大小只增加32MB（LoRA权重）。相比全参微调，显存占用降低72.6%，训练时间缩短20%，通用知识掉点从18%缩小到5%以内。

如果你要复现，建议先拿500条数据跑通流程，确认loss下降趋势正确后再全量训练。LoRA的核心价值不是省显存，而是让你能快速迭代多个领域适配层——我现在同时维护着医疗、法律、金融三个LoRA适配器，推理时按需加载，切换成本不到1秒。