预训练模型微调实战：迁移学习、LoRA与Transformers

1. 迁移学习到底在迁移什么？微调前先看清本质

迁移学习这四个字听着玄乎，落到代码上其实就一个动作：把别人在超大规模数据上辛辛苦苦训练好的模型拿过来，在你自己的小数据集上接着训练。这个过程放到 Hugging Face 的 Transformers 生态里，就是常说的微调。我见过太多人一上来就问“哪个代码能迁移学习”，其实没有什么一键咒语，真正的落地路径就是“加载预训练模型 + 准备数据 + 训练 + 评估”这四步。把这四步走通，迁移学习的原理和工程问题你基本就都摸到了。

1.1 预训练、微调、迁移学习三者的关系

先给一个最朴素的理解。预训练模型相当于一个在“通用领域”读过大量文本的毕业生。BERT 读过维基百科和书籍，GPT 读过海量网页，这些模型已经掌握了语法、常识、逻辑关系，但这些知识是泛化的。微调就是让这位毕业生入职你的公司，完成岗前培训，逐渐适应“你们的业务语言”。比如你的业务是客服工单分类，那就拿几万条工单数据，让模型学会“退费”和“维修”这些词在你这个场景里的真实含义。

顺带说一句，迁移学习里还有个概念叫直推式迁移学习，说的是源任务和目标任务相同，但源域和目标域不同，而且目标域没有标注数据可用。这类设定在领域自适应里更常见。日常说的“预训练+微调”，其实更贴近归纳式迁移学习：目标领域有标注数据，任务是新的，但两个任务共享底层的通用知识。理解这个，你就明白为什么微调不需要从零训练，也不用把学习率设得太大——因为模型底子已经很好了，你只需要做轻度修正。

1.2 为什么“加载预训练模型直接预测”不叫落地？

很多人有个误区：既然预训练模型这么强，我直接用它做预测不就行了？真不是。我举个例子：你用bert-base-chinese直接对一个商品评论做“正向/负向”二分类，拿出来的输出是一堆 token 的隐藏层向量，根本没有分类概率。因为 BERT 本体只有 Transformer 编码器和 MLM 预训练头，它学的是“完形填空”，而不是“情感判断”。同样，你拿 GPT-2 直接问一句“上海明天天气怎么样”，它只会继续输出下一段文字，不会给你一个严谨的答案。

所以微调的核心任务，是在预训练模型之上加一个“任务适配层”，然后用你的数据把这一层和模型的其余部分一起调优。这也解释了为什么同样一个 BERT，有人拿它做情感分析，有人拿它做命名实体识别，有人拿它做相似度计算——下游任务不同，适配层不同，微调数据不同，但底座是同一个。这才是迁移学习“一鱼多吃”的真正价值。

2. 环境搭建与版本配套：Transformers 库选型避坑

环境问题真的是劝退新手的第一道坎，尤其是 GPU 驱动、CUDA、PyTorch、Transformers 四个版本叠在一起，版本不匹配，代码一行没跑就报错。我在群里看到过最典型的问题：“哪个版本的 PyTorch 和 CUDA 支持 transformers==3.4.0”。这问题本身没错，但我得先说一句实话：除非你要复现一个 2020 年的老项目，否则不要主动选 3.4.0。

2.1 版本搭配：PyTorch、CUDA、Transformers 到底怎么配对

为什么老版本会坑人？transformers 3.4.0 是 2020 年发布的，当时 PyTorch 还在 1.5/1.6，CUDA 主流是 10.1/10.2，而到了今天，PyTorch 2.x 在很多 API 上已经和老版本不兼容了。你装上 transformers 3.4.0 之后，很可能连from_pretrained的参数名都对不上，更别提 peft、datasets 这些配套库是否兼容。

我现在的建议列表：

这里有个大家容易忽略的点：CUDA 版本指的是 PyTorch 编译时用的 CUDA runtime，不是你nvidia-smi里看到的驱动版本。驱动只要够新，向下兼容即可，而 PyTorch 内部带的 CUDA 库才是关键。所以你的判断顺序应该是：先看显卡驱动支不支持，再装对应 CUDA 版本的 PyTorch，最后根据 PyTorch 选配套的 transformers。

2.2 装完环境先别急着训练，三步验证

第一步，确认 PyTorch 和 GPU 是否真的通了，跑下面这段：

python -c "import torch; print('torch:', torch.__version__); print('cuda:', torch.cuda.is_available())"

如果输出cuda: True，说明 PyTorch 能看到 GPU，这是能否训练的前提。第二步，确认 transformers 版本打印正常：

python -c "import transformers; print(transformers.__version__)"

第三步，做一个最小加载测试，加载一个小模型并跑一次前向：

from transformers import AutoModel, AutoTokenizer model_name = "bert-base-uncased" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModel.from_pretrained(model_name) inputs = tokenizer("hello world", return_tensors="pt") outputs = model(**inputs) print(outputs.last_hidden_state.shape)

如果这三步都能跑，说明你的环境没问题，后面再报错基本都是数据和训练配置的问题了。我自己的习惯是每次新建项目都跑一遍这套验证脚本，花不了两分钟，能省掉大量排障时间。

注意：新项目尽量选 transformers 4.30 以上的主流通用版本，配套的 peft、datasets、accelerate 生态也更全，LoRA、QLoRA 这些省显存方案才能直接用。

3. 微调方案选型：全量微调、Freeze 微调、LoRA 微调怎么选

现在跑微调，你首先要回答一个问题：到底更新模型的哪些参数？不同参数更新策略，决定了你的显存占用、训练速度、最终效果，也决定了你能不能在手头这张显卡上把大模型跑起来。这个环节没有“最牛的方案”，只有“最适合你现状的方案”。

3.1 全量、Freeze、LoRA 的差异：先搞清楚你改的是哪些参数

我直接拿“改合同”来打比方。全量微调是把整个公司所有流程都重新培训一遍，模型的每一层参数都被更新。这种方案效果上限最高，因为模型能完全适应你的任务，但代价也最大：训练时要保存梯度、优化器状态、中间激活值，显存需求非常夸张。比如一个 7B 参数的模型，全量微调哪怕用 fp16，也可能需要 60G 以上的显存，普通玩家基本没戏。

Freeze 微调是只改“合同里的关键条款”：把预训练主干冻结住，不更新主干参数，只训练新加的适配层，比如分类头。这个方法非常适合 BERT 这类小模型上的分类任务，显存占用低，收敛快。但它的短板也很明显：主干被冻结后，模型对目标领域的风格迁移能力会受限，如果任务和预训练语料差异特别大，效果就上不去。

LoRA 是 2021 年后最火的方案。它先把原始权重冻结，然后在每层旁边插入一个低秩矩阵作为“可训练的小旁路”，训练时只更新这个小旁路。这个思路很聪明：既然一个矩阵的完整更新量很大，那我把更新量拆成两个小矩阵相乘，用很小的参数量去逼近真实更新。实际使用中，LoRA 的可训练参数量通常只有全量微调的 1% 左右，显存需求大幅下降。

3.2 显存、效果、速度怎么权衡

这里的“接近全量”很多人不信，但 LoRA 在多数 NLU 任务上确实能做到和全量微调相差无几的效果，前提是任务难度适中、数据量不是特别大。如果你的业务有 10 万条以上的数据，想要类 ChatGPT 级别的深度改造成果，那全量微调依然有它的位置；如果只是几千到几万条数据做垂直领域适配，LoRA 基本够用了。

另一个很实际的问题：你有多少张卡？只有一张 4090 24G，想微调 Qwen 这种开源大模型，全量微调基本不用想，QLoRA 加 4bit 量化能把你从悬崖边拉回来。这也就是为什么现在 LoRA 微调教程在社区里那么火——不是因为大家都喜欢炫技，是真的显存不够用。

3.3 LoRA 配置与代码骨架：用 PEFT 可以少写几百行

手写 LoRA 不是不行，但没有必要，直接上 PEFT 库。PEFT 是 Hugging Face 官方出的参数高效微调工具库，几行代码就能把 LoRA 配置挂到模型上：

from transformers import AutoModelForCausalLM from peft import LoraConfig, get_peft_model model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-7B-Instruct", torch_dtype="auto") lora_config = LoraConfig( r=8, # 低秩矩阵的秩，越大表达力越强，显存也越高 lora_alpha=32, # 缩放系数，一般设为 r 的 2~4 倍 target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_config) model.print_trainable_parameters()

print_trainable_parameters()会直接打印出可训练参数量和占比，我建议每次微调前都打一眼，确认配置没有配错。如果你不想手写 Trainer 训练循环，也可以直接上 LlamaFactory 这类封装好的工具，它底层就是 Transformers + PEFT，通过 YAML 配置文件把数据路径、模型路径、LoRA 参数、学习率都写清楚，对教学演示和快速验证场景非常合适。

现在不少人直接把“微调”默认理解成 LoRA，并不是因为 LoRA 万能，而是它最适合单卡环境下的快速迭代。我自己做 7B 模型的垂直领域适配，默认起手式就是 LoRA。数据量很大、任务适配要求极高的时候，再考虑全量微调或 Freeze。

4. 数据集准备：分类任务与指令微调数据集怎么构造

很多项目死在数据上，不是算法不行，而是喂给模型的“教材”本身有问题。你去看所有微调失败案例，十有八九是数据格式不对、标签分布不均衡、噪声太多。这一节我把最常见的两种数据范式拆开讲。

4.1 文本分类数据集：最简单也最容易出错的教科书

微调 BERT 做情感分类、主题分类这类任务，数据一般长这样：

[ {"text": "这家店的奶茶太好喝了，下次还来", "label": 1}, {"text": "发货太慢了，等了三天才到", "label": 0}, ]

label 通常是整数，0 和 1 分别表示负向、正向。麻烦在哪？如果你用的是AutoModelForSequenceClassification，它要求label是从 0 开始连续的整数，不能是“positive”“negative”这种字符串，也不能是 2、5 这样的稀疏编号。我之前帮同事排查问题，他一股脑把 label 从 1 编到 12，最后训练时模型报错，就是因为id2label和label2id映射没写好。

正确做法是提前定义好标签映射，让模型知道 0 到 11 各代表什么含义：

label2id = {"negative": 0, "positive": 1} id2label = {v: k for k, v in label2id.items()}

第二种常见范式是指令微调。如果目标是 Qwen、Llama 这类大语言模型，数据不再是“文本+标签”，而是“指令+输入+输出”。比如你要做一个发票信息抽取助手，数据格式是 JSON，把期望模型看到什么、输出什么都交代清楚：

{ "instruction": "你是发票信息抽取助手，请从用户的输入中抽取发票号和金额。", "input": "发票号码：00452122，金额：人民币伍佰元整。", "output": "发票号：00452122，金额：500元" }

这种数据的核心在于“指令质量”，而不只是“输出质量”。你想想，一个模型如果长期被喂“糊里糊涂的问题 + 稀里糊涂的答案”，它怎么可能变聪明？我见过很多人直接从别的项目里复制指令模板，连领域术语都没改，训练出来的模型看着输出挺通顺，一问专业问题就胡说。指令本身要写清楚角色、任务、输入格式、输出格式，最好再加一两个示例。

4.2 数据清洗比“选模型”更值得花时间

这里分享几条我踩坑踩出来的原则。

第一，清洗异常文本。全角半角混用、HTML 标签、URL、重复标点、乱码符号，都要在预处理阶段处理掉。尤其从爬虫拿来的数据，可能一半都是“景点门票 景点门票 景点门票”这种重复文本。模型不是人，人看一遍能自动忽略重复噪音，模型会当成真的知识去学。

第二，检查标签分布。二分类问题，正负样本别差异得太离谱。10 比 1 的不平衡虽然也能训，但模型很容易学会“无脑输出大类”，然后评估时准确率看似很高，细看完全不干活。可以先跑一轮统计分析，看每条类别的数量，再决定要不要做欠采样、过采样或者设计加权损失。

第三，务必划分验证集。我自己现在固定从完整数据中切出 10%~20% 当验证集，并且保证验证集和训练集没有重合样本。如果数据是同一个用户产生的多条记录，更要做用户级别的划分，防止模型只是“背”了训练数据。验证集不干净，后面所有的指标都是自欺欺人。

如果你的目标是“大模型 + 偏好对齐”方向，还需要额外构造强化学习用的偏好数据集，即同一问题的“好回答”和“坏回答”配对。这类数据要求更高，写不好会让模型产生“为了迎合而不讲事实”的倾向，这一块建议在指令微调跑通之后再入门。

5. 微调实战全流程：从加载模型到保存权重

环境没问题，数据也理清了，接下来就是核心的流程代码。我按照“分类任务 + Trainer”这套最通用的组合来讲，因为这套流程能覆盖 70% 以上的场景，而且对新手最友好。如果你要训生成式大模型，改动也不大，主要区别在数据格式和评价函数。

5.1 加载预训练模型与分词器：这两行不是随便写写

分类任务用AutoTokenizer和AutoModelForSequenceClassification就够了：

from transformers import AutoTokenizer, AutoModelForSequenceClassification model_name = "bert-base-chinese" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForSequenceClassification.from_pretrained( model_name, num_labels=2, label2id=label2id, id2label=id2label )

这里有两个细节。第一，num_labels必须和你数据里的标签数一致，不是写 2 就一定对，你真有 5 类就写 5，这个参数决定了模型最后一层分类头的维度。第二，from_pretrained第一次执行会从网上下载模型和词表，如果网络访问 HuggingFace 的模型仓库经常中断，建议提前把模型拉到本地缓存，或者直接设local_files_only=True强制用本地文件。

5.2 用 Trainer 把训练简化成“填参数”

Transformers 库最大的好处是它把训练循环封装好了。你用 Trainer 只需要准备数据集对象和 TrainingArguments：

from transformers import Trainer, TrainingArguments train_args = TrainingArguments( output_dir="./bert_cls", num_train_epochs=3, per_device_train_batch_size=16, per_device_eval_batch_size=32, learning_rate=2e-5, weight_decay=0.01, evaluation_strategy="epoch", save_strategy="epoch", load_best_model_at_end=True, metric_for_best_model="eval_loss", greater_is_better=False, fp16=True, ) trainer = Trainer( model=model, args=train_args, train_dataset=train_dataset, eval_dataset=eval_dataset, tokenizer=tokenizer, ) trainer.train()

别小看这几个参数，每一个都值得掰开说。学习率设成 2e-5 是关键，因为预训练模型的参数已经收敛得很好了，微调时学习率如果设置成 1e-3 这种常见值，梯度一步就把之前的通用知识冲掉，模型很容易训坏。fp16=True能显著降低显存和加速训练，但要注意如果你的显卡是老旧架构，半精度反而可能出问题，到时候先关掉试试。

save_strategy建议和evaluation_strategy保持一致，都设成epoch或者steps，这样每个评估点都有对应的模型快照。load_best_model_at_end=True是说训练结束后自动把验证集指标最好的那一次权重加载回来，而不是傻乎乎用最后一轮的权重。这个细节能救很多人，因为最后一轮模型不一定是最优的，过拟合往往就在最后几个 epoch 出现。

5.3 保存与推理验证：你的模型到底有没有学会

训练完马上做两件事：

trainer.save_model("./bert_cls_final") tokenizer.save_pretrained("./bert_cls_final")

保存后不要直接丢给业务，先在验证集上跑一遍推理，打印几条样本看效果：

from transformers import pipeline cls_pipeline = pipeline("text-classification", model="./bert_cls_final") print(cls_pipeline("这家店的奶茶太好喝了")) print(cls_pipeline("客服不解决问题，差评"))

打印结果会告诉你模型对每句话的分类概率。我习惯把预测错误的样本单独抽出来看一遍：是标签有问题，还是文本本身有歧义，还是某类样本太少？这个环节叫错误分析，比调任何超参数都有效。比如我发现所有预测错的样本里，“好吃”这个词都出现在负向评论中，那很可能数据里有“好吃但贵”这种带转折的句子，模型没学到转折逻辑，这时该补充的是带转折连词的样本，而不是调学习率。

如果做的是生成式大语言模型微调，推理验证还需要注意 prompt 格式要和训练时一致。比如 Qwen 训练时用了 ChatML 格式，推理时也要加上 system、user 这些标记，模板错了，模型输出质量会肉眼可见地下降。Transformers 里可以直接用tokenizer.apply_chat_template()来统一处理，能防止这类低级错误。如果你后续要做私有化部署，记得在模型验证通过后把 LoRA 权重合并回主干模型，或者导出成 vLLM 需要的格式，免得到部署环境还要重新挂 adapter。

6. 微调常见问题与排查技巧实录

这一节是我最想写的内容。模型微调不像普通人想的“点一下训练等结果”，实际过程中必然遇到一堆幺蛾子。有些坑我踩过数次，写下来给大家当排障手册。

6.1 Loss 不下降或剧烈震荡

先说结论：大部分 Loss 不下降不是模型问题，是数据问题。检查顺序有两条：一是看数据有没有读对。我遇到过一次，某个 CSV 的label列读出来全是字符串，模型训练时把它当成了回归任务，Loss 当然怎么都降不下来。二是看训练集和验证集是不是乱排了。如果你从 HuggingFace 的 Datasets 库里做了shuffle，要确认验证集在 shuffle 之前就切好了，否则验证集里混进训练集样本，验证 Loss 会永远好看，但真实效果一塌糊涂。

Loss 剧烈震荡的常见原因是学习率太大。对预训练模型做微调，学习率超过 5e-5 就要警惕了，LoRA 训练可以稍微放宽一点，但一般也不超过 2e-4。你可以先跑两三个 step，观察 Loss 曲线，如果像心电图一样忽上忽下，不妨把学习率按 10 倍往下调试试。

6.2 显存不足、训练速度慢

显存不足最直接的解法就是“三连”：降低 batch size、开梯度累积、打开混合精度 fp16/bf16。batch size 设到 1 还不行的，再考虑梯度累积把 8 个小 batch 合成一次大更新。如果模型做过量化，用 bitsandbytes 加载 4bit 模型，配合 LoRA 训练，显存需求会大幅下降。

训练速度慢，优先看数据加载管线。直接把整个 CSV 糊进Dataset.from_pandas()会有很多重复的 tokenization 操作。正确做法是预先在数据预处理里就把文本变成input_ids、attention_mask，训练时 GPU 只做矩阵运算，不再做文本映射。对 7B 大模型做 SFT，强烈建议用 packing 把多个短样本拼成一个固定长度序列，能降低大量 padding 浪费。这一步做完，训练步数和吞吐量通常能提升 20%~40%。

6.3 微调后效果反而变差了

这个现象在分类任务里非常常见，原因一般是三个。一是数据量太小还硬训，几百条数据微调一个 BERT，结果就是灾难，这时候不如用 Embedding 相似度或小样本提示。二是验证集和训练集分布不一致，或者是采样时种子没固定，模型跑完一轮效果看着不错，换一次随机种子就大变样，说明你的训练是不稳定的。固定 seed 并多跑几次取平均表现才可靠。三是反例：微调数据里包含大量原模型答不对的极端样本，模型为了硬记这些样本反而把原本正确的能力覆盖掉了。解决办法是在数据里掺一部分原本正确的样本，做“持续学习 + 经验回放”。

6.4 给学生演示或快速验证，选什么模型效果最明显？

这个问题是很多人私信问过的，因为上课或者做技术分享，你要在有限时间内展示微调的价值，不能挑一个训完像没训的模型。我试下来最推荐三个组合。

第一是语言模型续写风格差异。拿 Qwen2.5-0.5B 这类小模型，分别用“官方话术”和“大白话口语”两组数据做 LoRA 微调，训练前后用同样一句 prompt，输出风格差别一目了然。第二是分类头可视化，拿 BERT 做垃圾邮件识别，训练前随机预测，训练后准确率直接拉满，对比足够直观。第三是做目标检测的话，可以用百度的 RT-DETR 这类视觉模型，准备十几张带标注的图片做微调，看检测框从乱飘到对齐，课堂效果非常好。如果你特别喜欢刷榜型效果，拿 SAM 系列做少样本分割演示也行，但训练流程相对较长。

这里有个实操心得：演示场景一定要提前把数据、模型路径、训练脚本全部固定，然后在展示前自己完整跑一遍。我在课堂上翻过车，当时因为忘了开fp16，训练速度慢得离谱，硬生生把半小时的演示拖成了全场沉默。提前做一次 dry run，比什么都重要。

说实话，迁移学习这条路我走了很久，最大的体会是：别迷信“神奇模型”，把数据、版本、训练参数这三件事做扎实，哪怕用一个早期的 BERT，都能在业务里产生非常能打的效果。反过来，模型再新，数据一塌糊涂，训练配置随手写，最后还是浪费 GPU 电费。微调这件事，真正的门槛从来不在算法上，而在工程上稳。希望这篇实战笔记能让你少走几步弯路，哪怕只帮你省下一个晚上的排障时间，也算值了。