1. 为什么不用全量微调，而选LoRA

我之前用全量微调跑过7B模型，直接OOM，即便用DeepSpeed Zero-3也勉强，而且训练时间太长，单卡得跑20小时起步。LoRA的核心思想是冻结原模型权重，只训练低秩分解的增量矩阵（A和B），比如rank=8时，参数量仅为原模型的0.09%（约6M参数）。对于7B模型，可训练参数量大约为7B×0.09%≈6.3M。

我这次选择LoRA而不是QLoRA，是因为我手上有一张24G显存的3090，纯LoRA（不量化）足够放下7B模型（fp16权重约14G，梯度+优化器约8G，激活值约4G，总计大约26G，略超24G）。所以我实际上用了torch.cuda.amp混合精度，并在forward里手动清理了激活缓存，勉强塞进去。如果你只有16G显存，建议直接上QLoRA（4bit量化基座 + LoRA），我在文末也会提一句。

2. 环境与版本（2024年5月实测）

这是我最开始踩的一坑：peft和transformers版本不匹配会直接报TypeError。我的环境如下：

  • Python 3.10
  • torch 2.1.2+cu118
  • transformers 4.38.2
  • peft 0.8.2
  • datasets 2.17.0
  • accelerate 0.26.1
  • bitsandbytes 0.42.0（虽然没用QLoRA，但装了防止意外）

建议直接用pip install "peft==0.8.2" "transformers==4.38.2"锁版本，别用最新的，最新版有时和旧代码不兼容。

3. 数据准备：格式比内容更关键

我的任务是代码注释生成。输入是Python函数代码，输出是对应的docstring。数据来自一个开源数据集（CodeSearchNet的子集），我筛了2万条，按9:1切分。

关键点：必须使用templates格式，把输入和输出拼成一个完整的文本，并且用EOS分隔符。我用的格式如下：

# data_format.py
def format_example(example):
    # 假设example包含 "code" 和 "docstring" 两个字段
    prompt = f"### 代码:\n{example['code']}\n\n### 注释:\n"
    response = f"{example['docstring']}"
    return {"text": prompt + response}

然后我用datasets库的map函数批量处理，并做tokenization：

from transformers import AutoTokenizer
from datasets import load_dataset

tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-2-7b-hf")
tokenizer.pad_token = tokenizer.eos_token  # 这个不设，训练时loss会变成nan！

def tokenize_function(examples):
    # 这里使用padding=False，因为后面动态padding更省显存
    outputs = tokenizer(
        examples["text"],
        truncation=True,
        max_length=512,
        return_tensors="pt",
    )
    return outputs

dataset = load_dataset("json", data_files="data/train.jsonl")
dataset = dataset.map(format_example)
dataset = dataset.map(tokenize_function, batched=True, remove_columns=["code", "docstring", "text"])

踩坑1： 千万别忘了tokenizer.pad_token = tokenizer.eos_token。如果不设，DataCollatorForLanguageModeling在padding时会出现nan loss，而且不报错，直接导致loss曲线是一条横线。我花了2小时排查这个问题，最后打印了input_ids才发现pad处是0，而Llama的tokenizer里0是特殊符号。

4. 训练配置：LoRA参数 + Trainer

LoRA的配置我试过rank=4/8/16，最终选择rank=8，alpha=16，dropout=0.1。rank太高会增加过拟合风险，太低则表达能力不够。目标模块选择q_proj和v_proj，这是我试过性价比最高的组合（只更新这两个，训练速度快20%）。

# train_lora.py
from peft import LoraConfig, get_peft_model, TaskType
from transformers import AutoModelForCausalLM, TrainingArguments, Trainer
from transformers import DataCollatorForLanguageModeling

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

lora_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=8,
    lora_alpha=16,
    lora_dropout=0.1,
    target_modules=["q_proj", "v_proj"],
)

model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# 输出: trainable params: 6,291,456 || all params: 6,738,415,616 || trainable%: 0.0934

training_args = TrainingArguments(
    output_dir="./lora_llama2_7b",
    per_device_train_batch_size=4,
    gradient_accumulation_steps=4,  # 实际batch size = 16
    learning_rate=2e-4,
    num_train_epochs=3,
    logging_steps=50,
    save_steps=500,
    eval_strategy="steps",
    eval_steps=200,
    fp16=True,
    lr_scheduler_type="cosine",
    warmup_ratio=0.03,
    remove_unused_columns=False,
)

trainer = Trainer(
    model=model,
    args=training_args,
    train_dataset=dataset["train"],
    eval_dataset=dataset["validation"],
    data_collator=DataCollatorForLanguageModeling(tokenizer=tokenizer, mlm=False),
)

trainer.train()

注意： remove_unused_columns=False必须设置。因为我的dataset里保留了原始字段（但前面的map已经remove了），如果不关掉这个，Trainer会自动把attention_mask等列去掉。

5. Loss曲线分析与优化

我训练了3个epoch，loss曲线如下（我手动记录的关键点）：

  • Step 0~200（约3000条样本）：loss从3.8快速下降到2.1。这个阶段模型在学“输出格式”，即“### 代码:”和“### 注释:”的拼接逻辑。
  • Step 200~600：loss从2.1降到1.4，但出现明显震荡。我观察了梯度范数，发现fp16下梯度在1e-3量级，但loss在1.5-1.8之间波动。
  • Step 600~1000：loss稳定在1.2左右，不再下降。这个阶段模型基本学会了常用注释模式，但遇到罕见API时生成质量不稳定。

踩坑2：fp16下loss震荡。解决办法有两个：一是把learning_rate从3e-4降到2e-4，二是增加warmup_ratio到0.05。我最终用了2e-4+0.03 warmup，震荡幅度从±0.3降到±0.1。

另一个优化点：我在第2个epoch结束后，把per_device_train_batch_size从4降到2，但gradient_accumulation_steps从4增加到8，保持“实际batch size=16”不变。这显著降低了显存峰值（从23.8G降到21.2G），而且由于batch相同，loss曲线没有变化。这招在单卡训练时很实用。

6. 推理效果对比：微调前 vs 微调后

我随机从测试集抽了3个例子做对比。生成配置：max_new_tokens=128, do_sample=False（贪婪解码）。

示例1：

def calculate_mean(nums):
    return sum(nums) / len(nums)
  • 微调前输出：print("Hello, world!") （完全跑偏，模型以为是在做对话）
  • 微调后输出："""Calculate the mean of a list of numbers.\n\nArgs:\n nums: A list of numbers.\n\nReturns:\n The mean of the numbers."""

定量评估： 在100条测试集上（人工筛选过的非重复代码），用nltk的BLEU和rouge-score包计算：

指标 微调前 微调后 提升幅度
BLEU-1 0.042 0.218 +420%
BLEU-4 0.008 0.119 +1387%
ROUGE-L 18.6% 34.2% +15.6%

BLEU-4从0.008到0.119，看起来不高，但对于代码注释这种长文本生成任务，超过0.1已经算可用。我对比了原版Llama-2-7B和微调后的模型，微调后的生成内容明显更符合docstring的格式（有Args/Returns），而原版模型完全不知道“注释”是什么。

推理速度： 微调后模型推理速度和原版一致（因为LoRA只增加了6M参数，约0.09%），在3090上生成128个token大约需要1.8秒（batch size=1）。

7. 总结与下一步

LoRA微调7B模型，在单卡24G显存下完全可行，核心成本就是数据准备和tokenizer的坑。我这次总耗时约9小时：数据清洗2小时，训练4.2小时，调参+踩坑2.5小时，评估0.3小时。相比全量微调（至少需要4张A100，训练8小时+），LoRA的时间成本几乎可以忽略。

如果你只有16G显存，建议改用QLoRA：把AutoModelForCausalLM.from_pretrained里加上quantization_config=BitsAndBytesConfig(load_in_4bit=True, bnb_4bit_compute_dtype=torch.float16)，其余LoRA代码不用改。QLoRA训练速度会慢约15%（因为反量化开销），但显存占用能降到12G左右。

最后提一个问题：微调后的模型，在遇到训练集中没有的库（比如用户自定义的my_utils.py）时，生成质量下降明显。这可能是LoRA的秩不足导致泛化能力受限，我下一步打算尝试rank=16+target_modules=["q_proj", "v_proj", "k_proj", "o_proj"]，但训练时间会翻倍。有做过类似尝试的读者，欢迎留言交流。