上个月接了个私活，甲方要在 Qwen3-7B 上微调一个垂直领域的客服模型。我寻思 LoRA 微调嘛，2026 年了谁还不会这个，结果从数据格式到训练超参，能踩的坑我一个不落全踩了。跑了 4 天才出第一个能用的 checkpoint，期间 OOM 了十几次、loss 飙到 NaN 三次、生成结果全是乱码两次。把这些坑整理出来，希望后面的人少走弯路。

LoRA 微调的核心流程是：准备 JSONL 格式数据 → 选基座模型 → 配置 LoRA rank/alpha/target modules → 设训练超参 → 跑训练 → 验证效果。看起来简单，每一步都有新手必踩的暗坑。

先说结论

环节	最常见的坑	后果	修复成本
数据格式	system/user/assistant 角色标签不对	模型学到错误的对话模式	重新清洗+重训
数据质量	样本长度分布不均、重复样本	loss 震荡不收敛	半天
LoRA 参数	rank 设太高，alpha 没跟着调	显存 OOM 或过拟合	几分钟改配置
学习率	直接用 full finetune 的 lr	loss 爆炸到 NaN	重跑
评估方式	只看 train loss 不做 eval	严重过拟合浑然不知	白跑几小时

环境准备

我的环境是一张 A100 80G（AutoDL 上租的，¥3.2/h），跑 Qwen3-7B 的 LoRA 微调绰绰有余。如果你只有 24G 的 4090，rank 别超过 32，batch_size 设 1 加 gradient accumulation 也能跑。

# 核心依赖，版本很重要
pip install transformers==4.45.2
pip install peft==0.13.2
pip install trl==0.12.1
pip install datasets==3.1.0
pip install bitsandbytes==0.44.1 # 4bit量化用

有个坑：peft 0.12.x 和 transformers 4.45+ 有兼容问题，会报 AttributeError: 'PeftModel' object has no attribute 'active_adapter'。升到 0.13.2 就好了。

坑一：数据格式——ChatML 模板没对齐

这是我浪费时间最多的地方。Qwen3 用的是 ChatML 格式，但我一开始按 Alpaca 格式写的 JSONL：

{"instruction": "你是客服", "input": "退货流程是什么", "output": "您好，退货流程如下..."}

跑完发现模型回复永远带着 "您好" 开头，不管问什么都像在背书。后来才意识到，得用 messages 格式：

{"messages": [{"role": "system", "content": "你是XX品牌的售后客服，回复简洁专业"}, {"role": "user", "content": "买了三天的耳机坏了能换吗"}, {"role": "assistant", "content": "可以的，三天在7天无理由范围内。请提供订单号，我帮您发起换货申请。"}]}

不同基座模型的 chat template 不一样。Qwen3 是 ChatML，Llama 4 是自己那套，搞混了模型学到的就是噪声。用 tokenizer.apply_chat_template() 验证一下你的数据 tokenize 出来长什么样，别偷懒。

坑二：数据质量——长度分布和去重

我最初有 3200 条数据，直接扔进去训。loss 前 200 步正常下降，然后开始剧烈震荡。排查了半天发现问题：

• 有 47 条样本的 assistant 回复超过 2048 token（被截断了，模型在学一个没有结尾的回复）
• 有 180 条几乎一模一样的样本（同一个问题换了个"请问"/"想问下"）

# 数据清洗脚本片段
import json
from collections import Counter

with open("train.jsonl") as f:
 data = [json.loads(line) for line in f]

# 检查长度分布
lengths = [len(str(d["messages"][-1]["content"])) for d in data]
print(f"回复长度 - P50: {sorted(lengths)[len(lengths)//2]}, P95: {sorted(lengths)[int(len(lengths)*0.95)]}, Max: {max(lengths)}")

# 去重：用 assistant 内容的前100字做 key
seen = set()
deduped = []
for d in data:
 key = d["messages"][-1]["content"][:100]
 if key not in seen:
 seen.add(key)
 deduped.append(d)

print(f"去重前: {len(data)}, 去重后: {len(deduped)}")
# 我的结果：3200 → 2891

清洗完重新跑，loss 平滑多了。数据质量这事大家都知道重要，但真到自己头上就是会偷懒。

坑三：LoRA 参数——rank 和 alpha 的关系

这个坑比较隐蔽。我一开始设 r=64, lora_alpha=16，觉得 rank 高点效果好。结果：

1. 显存直接多吃了 8G（A100 还扛得住，4090 就 OOM 了）
2. 训完效果反而不如 r=16 的版本——过拟合了

后来看了几篇论文才搞明白：lora_alpha / r 这个比值才是实际的 scaling factor。alpha=16, r=64 意味着 scaling 只有 0.25，等于你加的 LoRA 权重被缩了 4 倍，学习信号很弱。

我最后用的配置：

from peft import LoraConfig

lora_config = LoraConfig(
 r=16,
 lora_alpha=32, # alpha/r = 2，比较激进但我数据量小需要学快点
 target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"],
 lora_dropout=0.05,
 bias="none",
 task_type="CAUSAL_LM",
)

graph TD
 A[选择 rank] --> B{显存够不够?}
 B -->|4090 24G| C[r=8 或 r=16]
 B -->|A100 80G| D[r=16 或 r=32]
 C --> E[alpha = r × 2]
 D --> E
 E --> F{数据量多大?}
 F -->|< 1000 条| G[dropout=0.1 防过拟合]
 F -->|> 5000 条| H[dropout=0.05 或 0]
 G --> I[开始训练]
 H --> I

target_modules 也容易踩坑。只挂 q_proj, v_proj 是最保守的选法，但我实测 Qwen3-7B 上把 MLP 层的 gate_proj, up_proj, down_proj 也加上，效果明显好一截。代价是参数量从 4.7M 涨到 18M，训练慢 40% 左右。

坑四：学习率——LoRA 和 full finetune 差一个数量级

这个坑让我 loss 直接飙到 NaN。我习惯性地设了 lr=2e-5（full finetune 的常用值），跑了 50 步 loss 从 1.8 直接飞到 65536 然后 NaN。

LoRA 微调的学习率通常要比 full finetune 高一个数量级，因为你只更新很少的参数，梯度信号需要更强。但也不能太高。

我试过的组合：

学习率	结果
2e-5	loss NaN（太高了，对 LoRA 来说反而太激进）
1e-4	loss NaN（更离谱）
2e-4	前期正常，后期震荡
5e-5	收敛稳定，最终 loss 0.42
3e-5	收敛慢但最终 loss 最低 0.38

等等，你可能注意到了——2e-5 对 full finetune 合适，但对 LoRA 反而可能不够或者不稳定？其实这跟 alpha/r 的 scaling 有关。我后来发现我第一次 NaN 不是 lr 的问题，是数据里有几条 content 是空字符串，tokenize 出来长度为 0 导致的除零错误。

所以真正的建议是：lr 设 1e-4 到 3e-4 之间，配 cosine scheduler + warmup 前 10% 步数。出 NaN 先检查数据，别急着调 lr。

# 我最终的训练配置（SFTTrainer 格式）
training_args:
 output_dir: ./output/qwen3-7b-lora-cs
 num_train_epochs: 3
 per_device_train_batch_size: 4
 gradient_accumulation_steps: 4 # 等效 batch_size = 16
 learning_rate: 2e-4
 lr_scheduler_type: cosine
 warmup_ratio: 0.1
 bf16: true
 logging_steps: 10
 save_steps: 100
 eval_strategy: steps
 eval_steps: 100
 load_best_model_at_end: true
 metric_for_best_model: eval_loss

坑五：只看 train loss 不做 eval

前面四个坑都踩完之后，我终于跑出了一个 loss 从 1.8 降到 0.15 的模型。开心了五分钟，拿去推理发现——它把训练集背下来了。问训练集里有的问题回答得完美，换个说法就胡说八道。

经典过拟合。

解决方案很简单但很多教程不提：数据集 split 出 10%-15% 做 eval set，训练时监控 eval_loss。当 eval_loss 开始上升而 train_loss 还在降，就该停了。

from datasets import load_dataset

dataset = load_dataset("json", data_files="train_cleaned.jsonl", split="train")
split = dataset.train_test_split(test_size=0.1, seed=42)

# 传给 SFTTrainer
trainer = SFTTrainer(
 model=model,
 args=training_args,
 train_dataset=split["train"],
 eval_dataset=split["test"], # 这行很多教程漏了
 # ...
)

我最终模型在 epoch 2.3 左右 eval_loss 开始反弹，所以最佳 checkpoint 是 step 700 附近而不是跑完 3 个 epoch 的那个。

推理验证

训完了得验证效果。我用 Qwen3-7B 基座做 baseline 对比——微调前后让模型回答同样 50 个测试问题，人工打分。

推理代码里有个细节：加载 LoRA adapter 时如果 base model 的 tokenizer 和你训练时不一致（比如你训练时加了 special token），推理就会出乱码。

from peft import PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer

base_model = AutoModelForCausalLM.from_pretrained(
 "Qwen/Qwen3-7B",
 torch_dtype="auto",
 device_map="auto"
)
model = PeftModel.from_pretrained(base_model, "./output/qwen3-7b-lora-cs/checkpoint-700")
tokenizer = AutoTokenizer.from_pretrained("./output/qwen3-7b-lora-cs/checkpoint-700") # 用训练保存的tokenizer！

踩坑记录补充

还有个小坑记一下：训练中途想用 Claude Opus 4.7 帮我批量生成更多训练数据（合成数据扩充），调 Anthropic 官方 API 一直 timeout。后来换到 OpenRouter 和 ofox.io 这类聚合平台试了下，ofox.io 走的是 Anthropic 官方授权通道且 0% 加价，改个 base_url 就通了，生成 500 条数据花了大概 ¥45。

from openai import OpenAI

# 生成合成训练数据
client = OpenAI(api_key="your-key", base_url="https://api.ofox.io/v1")
response = client.chat.completions.create(
 model="claude-opus-4.7",
 messages=[{"role": "user", "content": "请模拟一个客户询问退货政策的对话..."}],
 temperature=0.8,
)

小结

LoRA 微调本身不难，难的是那些教程里一笔带过的细节。数据格式对齐 chat template、清洗长度异常和重复样本、rank/alpha 比值设合理、学习率配 warmup 别裸跑、一定要 split eval set 监控过拟合——这五个点搞定了，基本不会翻车。

我现在的工作流是：先花 60% 时间在数据清洗上，配置模板直接复用上面那套 yaml，跑起来之后盯前 200 步的 loss 曲线。如果前 200 步 loss 没有稳定下降的趋势，肯定是数据或者 lr 有问题，别等它跑完再看。