BERT情感分类LoRA微调实战：低秩自适应原理与实现

上个月帮一个做电商评论分析的朋友改一版情感分类模型，手上只有两万多条标注语料，机器是一张 24G 显存的卡。他原先的做法是把 BERT 整个放开做全量微调，跑三个 epoch 要将近四十分钟，换一条业务线就得重训一遍，权重存下来一个多 G，版本管理乱成一锅粥。我给他换了个思路：把原始权重全部冻住，只在注意力层里塞进两个小矩阵，可训练参数量从一亿多降到三十万不到，单卡训练时间砍掉三分之二，准确率只掉了不到一个点。这套小矩阵的做法就是 LoRA，业内一般叫低秩自适应（Low-Rank Adaptation），很多人第一次看到容易写成"低阶自适用"，其实就是低秩分解那点事。这篇内容我会把 BERT 在 IMDB 情感分类数据集上跑 LoRA 微调的完整链路拆开讲：为什么选它、秩和缩放因子怎么定、注入点怎么找、代码怎么写、训崩了怎么查。适合手上有预训练模型但算力吃紧的同学，也适合想搞清楚 LoRA 到底在改什么、而不是只会调库的读者。全程只讲原理和实操，不依赖任何特定框架的高级封装，你自己手写一遍，后面换到别的模型上也是同一套思路。

1. 为什么在 BERT 上折腾 LoRA：问题起点与方案选型

1.1 全量微调的三个现实痛点

先把这个问题的背景说清楚。BERT-base 是十二层 Transformer 编码器，隐藏维度 768，总参数量大概 1.1 亿。全量微调的意思是把这一亿多个参数全部打开，跟着下游任务的数据一起更新。听起来很自然，但实际落地时会撞上三堵墙。

第一堵墙是显存。训练时的显存占用不只是权重本身。fp32 下权重要占 440MB 左右，梯度再占一份，Adam 优化器还要为每个参数维护一阶动量和二阶动量两份状态，又是两份。粗算下来光参数相关的开销就接近 1.8GB。真正吃显存的是激活值——batch size 32、序列长度 256 的时候，十二层的前向中间结果加起来能顶到 6GB 以上。你想再往上调 batch size，或者把序列拉到 512，很快就 OOM。第二堵墙是存储和版本管理。每换一个任务、每换一条业务线，就得存一份完整的 1.1 亿参数权重，四百多兆起步。十个任务就是四五个 G，做 A/B 实验的时候版本号能把人逼疯。第三堵墙是灾难性遗忘和过拟合。下游数据只有几千条的时候，全量微调很容易把预训练阶段学到的通用语言知识冲掉，小数据集上训三轮就开始过拟合，验证集 loss 掉头向上。

注意：这里的显存估算只是量级参考，实际占用跟框架版本、是否开启混合精度、是否用梯度检查点强相关，不要拿这个数字去卡死自己的配置。

LoRA 对付的就是这三堵墙。它不去动原始权重，而是给权重旁边挂一条"旁路"，只训练旁路上的小矩阵。冻结的部分不产生梯度，也不产生优化器状态，显存占用立刻降下来；保存的时候只存旁路那几十万参数，一个任务几兆，扔进 Git 都不心疼；因为主权重没被改动，通用语言知识基本保留，小数据上的过拟合风险也低不少。这三条正好对上前面三个痛点，这是我的第一层选型理由。

1.2 LoRA 的低秩思路到底省在哪

要理解 LoRA 为什么能只训一小撮参数还有效果，得先接受一个经验假设：模型在适配下游任务时，权重的变化量是低秩的。直白点说，从通用语言模型变成情感分类模型，不需要把整个 768×768 的权重矩阵朝所有方向都拧一遍，真正需要调整的方向可能只有那么几个。

数学上的表述是，对于一个预训练权重矩阵 W₀（维度 d×k），LoRA 不去直接学 ΔW，而是把它拆成两个瘦长矩阵的乘积：ΔW = B·A，其中 A 是 r×k，B 是 d×r，r 远小于 d 和 k。前向计算就变成 h = W₀x + (α/r)·B·A·x。原始的 W₀ 冻结不动，只有 A 和 B 参与训练。

拿 BERT 里的 query 投影举例，它是 768×768，一共 589,824 个参数。取秩 r=8，那么 A 是 8×768，B 是 768×8，加起来只有 12,288 个参数，是原来的百分之二。十二层里每层有 query 和 value 两个矩阵，总共就 294,912 个参数。相比 1.1 亿的总量，占比 0.27% 左右。这就是"省"的来源，它不是压缩，而是根本不去碰大矩阵。

还有个容易被忽略的细节：初始化方式。A 用随机初始化（Kaiming 均匀分布），B 全零初始化。这样训练开始时 B·A 恒等于零，模型的输出和原始预训练模型完全一致。这个设计的意图是让训练从一个"无损"的起点出发，避免一开始就破坏预训练权重已有的表示。我在第一次手写实现的时候图省事把两个矩阵都随机初始化了，结果前两百步 loss 直接飙到 3 以上再慢慢往下掉，白白浪费了半轮训练。

1.3 为什么用 BERT + IMDB 这个组合练手

选 BERT-base 做基座，是因为它结构规整、层数适中、社区资料足够多，出问题容易定位。选 IMDB 电影评论数据集，是因为它是二分类情感任务，标签干净，正负样本均衡（各两万五千条），文本长度中等偏长，正好能体现 LoRA 在序列建模上的实际表现，同时不会像多分类或序列标注那样引入额外的评估复杂度。

而且这个组合有个好处：它有明确的公开基线。BERT-base 在 IMDB 上全量微调的准确率普遍落在 93% 到 94.5% 区间，你在自己机器上跑 LoRA，只要落在 92% 到 93.5%，就说明实现没跑偏。有参照物，排查问题就有锚点，这比在一个没人跑过的任务上瞎摸索要高效得多。

1.4 什么场景下不建议用 LoRA

不是所有情况都适合。如果你的下游数据和预训练分布差异极大，比如从通用中文语料直接跳到某种高度专业的小语种或符号化文本，低秩旁路的表达能力可能不够，这时候全量微调或者中间层解冻会更稳。如果任务要求模型输出结构发生根本改变（比如从编码器改造成生成式结构），LoRA 也帮不上忙，那是架构层面的事。还有一种情况是数据量非常充足，几十万条以上，并且算力不缺，那全量微调的上限确实更高，LoRA 更像是算力受限时的性价比方案，而不是无条件的替代品。

2. LoRA 的核心原理拆解与参数计算

2.1 前向与反向：旁路是怎么接进去的

把 LoRA 层看作一个包装器会更直观。原来的线性层做的是 y = W₀x + b，LoRA 包装之后变成 y = W₀x + b + (α/r)·B·A·x。注意偏置项 b 一般是保留且冻结的，也有人选择训练它，但收益很小，我倾向冻结，减少不必要的变量。

反向传播的时候，因为 W₀ 的 requires_grad 被设为 False，梯度不会流进它，只会流进 A 和 B。梯度怎么算？设损失对输出的梯度是 g，那么对 B 的梯度是 (α/r)·g·(A·x)ᵀ，对 A 的梯度是 (α/r)·(Bᵀ·g)·xᵀ。注意对 A 的梯度里含有 B，而 B 初始是零，所以第一步训练时 A 的梯度也是零，只有 B 在更新；等 B 有了非零值，A 才开始动。这个"错峰启动"是正常现象，不是 bug，很多人看到第一步只有一半参数有梯度会以为实现错了。

这里有个实操上的坑：如果你用混合精度训练，LoRA 的 A、B 矩阵要保持 fp32。因为它们的值域跨度可能比较大，纯粹用 fp16 存会有精度损失，尤其在 r 很小的时候，数值误差会被放大。我的做法是把 LoRA 参数单独设成 float32，前向时再 cast 到计算精度，或者直接用 torch.autocast 包住前向、让参数维持 fp32。

2.2 rank、alpha、dropout 三个参数到底怎么定

这三个是 LoRA 里唯一需要你手动决策的超参，理解它们的物理意义比记住推荐值重要。

rank（r）决定了旁路的容量。r 越大，能拟合的增量方向越多，表达能力越强，参数量线性增长。r=1 到 4 适合任务和预训练分布接近的情况，比如情感分类这种 BERT 本来就擅长的任务；r=8 到 16 是通用起点；r=32 以上一般用在领域差异大或者数据量足的场合。我在 IMDB 上做过对比，r=4、8、16 的最终准确率差距在 0.3 个百分点以内，但 r=16 的训练时间比 r=4 多了将近四成。所以别迷信大秩，先从 8 试起。

alpha（α）是缩放因子，实际生效的是 α/r 这个比例。这里最容易踩坑：很多人只调 r 不调 α，结果 r 翻倍的时候缩放比例减半，等效学习率跟着变了，效果反而变差，还以为是秩的问题。业界有个常见约定是让 α = 2r 或者 α = r，前者相当于缩放系数固定为 2，后者固定为 1。我自己的习惯是 α 取 2r，理由是这样调 r 的时候缩放强度保持稳定，变量只有一个，排查起来清爽。

dropout加在旁路的输入上，也就是对 x 做 dropout 再送进 A。作用是防止小数据上旁路过拟合。数据量在万级的时候，0.05 到 0.1 比较合适；数据量在十万级以上可以设 0。我一开始忘了加，IMDB 上训到第二轮验证集准确率就到顶了然后开始抖，加上 0.1 的 dropout 之后曲线平滑很多。

2.3 参数量与显存账本：算一笔明白账

先算参数量。BERT-base 每层注意力有四个 768×768 的投影矩阵：query、key、value、output。十二层合计是 4 × 12 × 589,824 ≈ 2830 万，占模型总量的四分之一左右，剩下的主要是词嵌入（约 2340 万）和前馈网络（每层两个 768×3072，约 4720 万）。

只给 query 和 value 注入 LoRA，r=8 时：

• 单个矩阵的旁路参数 = r × 768 + 768 × r = 8×768×2 = 12,288
• 每层两个矩阵 = 24,576
• 十二层合计 = 294,912
• 占总参数比 ≈ 0.27%

如果四个矩阵全注入，参数量翻倍到 589,824，占比约 0.53%。加上分类头（768×2 = 1536 个参数），总量还是三十万上下。

再算显存。全量微调时，1.1 亿参数在 fp32 下的优化器状态约 880MB（Adam 两份动量），梯度 440MB，权重 440MB，合起来 1.7GB 左右。LoRA 只训练三十万参数，优化器状态加梯度加新权重总共不到 5MB，这部分开销基本可以忽略。真正剩下的显存开销就是前向激活值，这部分跟全量微调一样，省不掉。

实际测下来，batch size 32、序列长度 256、混合精度开启的情况下，全量微调峰值显存约 9.2GB，LoRA 版本约 7.1GB。节省的两点多 G 就是那部分参数相关的开销。这意味着同样的卡，你可以把 batch size 从 32 提到 48 甚至 64，训练速度又能往上提一截。

表里的耗时是在同一张卡、同一份数据上跑出来的量级参考，不同硬件和框架版本会有出入，重点看相对关系。可以看到 LoRA 的速度提升主要来自两处：可训练参数少了，反向传播的计算量减少；显存腾出来了，batch size 可以调大。

3. 实操准备：环境、数据与模型改造

3.1 环境与依赖的版本坑

环境这块我不想写得太教条，但有几个版本组合确实会咬人。核心依赖就三个：PyTorch、Transformers、Datasets。建议 PyTorch 2.0 以上，因为 torch.compile 和 autocast 的行为在新版本里更稳定。Transformers 建议 4.30 以上，再老的版本里 BERT 的注意力实现是分开写死的，做模块替换的时候路径不一样。

pip install torch>=2.0.0 transformers>=4.30.0 datasets>=2.12.0 pip install scikit-learn tqdm

第一个坑是 datasets 的加载。IMDB 数据集默认从网络拉取，如果你在离线环境，得提前把数据缓存好，或者用本地 parquet 文件加载。第二个坑是 tokenizer 的并行告警，处理两万五千条文本的时候会刷一屏的 tokenizers 并行警告，用os.environ["TOKENIZERS_PARALLELISM"] = "false"关掉就行，不影响结果。

第三个坑最隐蔽：如果你装了 accelerate 但版本和 transformers 不匹配，from_pretrained会静默走一些奇怪的加载路径，导致你替换模块的时候找不到预期的属性名。遇到"AttributeError: 'BertSelfAttention' object has no attribute 'query'"这种报错，八成是版本问题，先把版本对齐再看代码。

提示：动手之前先打印一遍model的结构，把每一层的模块名记下来。不同版本的 Transformers 里，注意力子层的属性名可能是query/key/value，也可能是q_lin/k_lin/v_lin，硬编码模块名是最常见的翻车原因。

3.2 IMDB 数据加载与分词处理

IMDB 是长文本，评论长度分布很宽，短的几十个词，长的上千词。BERT 的最大位置编码是 512，所以必须截断。这里有个取舍：截到 128 还是 256 还是 512？

我做过对比，截到 128 的时候准确率大概掉 1.5 个点，因为很多评论的关键情感词出现在后半段；截到 256 基本能拿到 512 的 99% 效果，但计算量只有一半。所以我一般用 max_length=256，性价比最高。如果你做的是长文档分类，那就得考虑滑动窗口或者 Longformer 一类的方案，那是另一个话题。

import os os.environ["TOKENIZERS_PARALLELISM"] = "false" from datasets import load_dataset from transformers import AutoTokenizer raw = load_dataset("imdb") tokenizer = AutoTokenizer.from_pretrained("bert-base-uncased") def tokenize_fn(batch): return tokenizer( batch["text"], truncation=True, max_length=256, padding="max_length", ) encoded = raw.map(tokenize_fn, batched=True, batch_size=1000, remove_columns=["text"]) encoded = encoded.rename_column("label", "labels") encoded.set_format(type="torch", columns=["input_ids", "attention_mask", "labels"])

注意padding="max_length"在这里是为了让整个数据集长度统一，方便后面直接用默认的 collate 组 batch。如果你想省显存，可以改成padding=False配合 DataCollatorWithPadding 做动态填充，短样本不浪费算力。动态填充在 IMDB 上能省下大概 15% 的训练时间，因为长度分布不均，固定填到 256 会有大量无意义的 pad token 参与计算。不过注意力掩码会屏蔽掉它们，所以对结果没影响，纯看你要不要那点速度。

数据划分上，官方给的是 25000 训练 / 25000 测试。我建议从训练集里再切 2000 条做验证集，用来选超参和 early stopping，测试集留到最后只跑一次。直接在测试集上反复调参，最后报出来的数字是不可信的。

split = encoded["train"].train_test_split(test_size=2000, seed=42) train_ds, valid_ds = split["train"], split["test"]

3.3 BERT 结构解剖：找对注入点

注入点的选择是 LoRA 落地时第一个需要决策的地方。理论上你可以给 BERT 里任何一个 Linear 层挂旁路，但不同位置的效果差异很大。

先看清楚 BERT 一层里有什么：自注意力的四个投影（query、key、value、output），然后是两个前馈层（中间维度 3072 的那个扩张层和收缩层），再加上 LayerNorm。原论文的消融实验给出的结论是：只调 query 和 value 性价比最高，四个全调效果略好但参数量翻倍，只调 query 或只调 value 都明显更差。前馈层也可以挂，但收益递减。

我自己的实测结果和这个结论基本吻合。在 IMDB 上：

• 只挂 query：准确率约 92.1%
• query + value：约 92.8%
• query + key + value + output：约 92.9%
• 再加上前馈层：约 92.9%，参数翻了一倍多

所以默认方案就是 query + value，只有在效果确实不够、且参数量不是瓶颈的时候再往上加。

怎么定位这两个层？两种方式。一种是按模块类型遍历，用isinstance(m, nn.Linear)加上名字过滤；另一种是直接按名字匹配。我更推荐前者，因为跨模型迁移的时候不用改名字。

def find_target_modules(model, target_names=("query", "value")): targets = [] for name, module in model.named_modules(): if isinstance(module, nn.Linear): leaf = name.split(".")[-1] if leaf in target_names: targets.append(name) return targets # 打印出来确认一下数量，BERT-base 应该是 24 个 names = find_target_modules(model) print(len(names), names[:4])

跑出来应该是 24 个，十二层每层两个。如果数量不对，说明版本里的命名不一样，把前几个名字打出来看看实际的叶子节点叫什么，再调整 target_names。

4. 动手实现：从零写一个 LoRA 层并注入 BERT

4.1 LoRALinear 模块的实现细节

我倾向于自己写一遍，而不是直接调现成的封装。原因很简单：自己写过一遍，出了问题你知道该看哪里；用现成的，报错的时候只能去翻别人的源码。下面这份实现我在多处用过，逻辑是完整的。

import math import torch import torch.nn as nn class LoRALinear(nn.Module): def __init__(self, base_layer: nn.Linear, r: int = 8, alpha: int = 16, dropout: float = 0.05): super().__init__() assert r > 0 self.base = base_layer # 冻结原始权重与偏置 for p in self.base.parameters(): p.requires_grad = False self.r = r self.alpha = alpha self.scaling = alpha / r in_f = base_layer.in_features out_f = base_layer.out_features # A: (r, in_f) B: (out_f, r) self.lora_A = nn.Parameter(torch.empty(r, in_f)) self.lora_B = nn.Parameter(torch.zeros(out_f, r)) nn.init.kaiming_uniform_(self.lora_A, a=math.sqrt(5)) self.dropout = nn.Dropout(dropout) if dropout > 0 else nn.Identity() def forward(self, x): base_out = self.base(x) lora_in = self.dropout(x).to(self.lora_A.dtype) lora_out = (lora_in @ self.lora_A.t()) @ self.lora_B.t() return base_out + lora_out * self.scaling def extra_repr(self): return f"r={self.r}, alpha={self.alpha}, scaling={self.scaling:.3f}"

几个细节值得单独说。第一，lora_B必须是全零初始化，这个前面讲过，是为了让初始状态等价于原始模型。第二，lora_A用 Kaiming 初始化，而不是全零，否则两个矩阵都是零，梯度永远出不来。第三，lora_in.to(self.lora_A.dtype)这步是为了混合精度下的类型对齐，如果主模型用 fp16 算、LoRA 参数是 fp32，这里不做转换会报 dtype mismatch。第四，缩放作用于输出而不是输入，位置不同对数值稳定性有细微影响，实践上作用在输出更常见。

还有一个容易被忽视的点：self.base里的参数虽然冻结了，但它本身还是一个nn.Linear，会被model.parameters()遍历到。做优化器的时候如果直接把model.parameters()塞进去，会把这些冻住的参数也加进优化器，虽然梯度是 None 不会更新，但优化器状态还是会给它们预分配空间，白白吃显存。所以优化器只喂requires_grad=True的参数。

4.2 权重注入与参数冻结策略

注入的做法是把父模块里的子模块替换成包装后的版本。核心是setattr，但要注意父模块的获取方式。

def inject_lora(model, target_names=("query", "value"), r=8, alpha=16, dropout=0.05): # 先收集，避免在遍历过程中修改结构 targets = find_target_modules(model, target_names) for name in targets: parent_name, _, child_name = name.rpartition(".") parent = model.get_submodule(parent_name) child = getattr(parent, child_name) new_layer = LoRALinear(child, r=r, alpha=alpha, dropout=dropout) setattr(parent, child_name, new_layer) return model

get_submodule是 PyTorch 1.9 之后提供的，比手工按点号逐层 getattr 干净得多。用rpartition拆出父路径和子名字，注意别用split(".")取最后一段，那样父路径容易拼错。

注入之后要做的第二件事是全局检查可训练参数。这一步是防呆的，我每次都会打印：

def print_trainable(model): total = sum(p.numel() for p in model.parameters()) trainable = sum(p.numel() for p in model.parameters() if p.requires_grad) print(f"total={total:,} trainable={trainable:,} " f"ratio={100 * trainable / total:.3f}%") print_trainable(model)

BERT-base 加 r=8、query+value 的配置，期望输出是 total 约 1.09 亿，trainable 约 29.6 万（多了分类头的 1536），比例 0.27% 左右。如果 trainable 显示还是一亿多，说明冻结没生效，八成是LoRALinear.__init__里那句循环没跑到，或者你在注入之前就把模型设成了requires_grad=True并且后面又没重新冻结。

分类头这块单独说一下。BertForSequenceClassification自带一个classifier，它本来就是要训练的，注入 LoRA 的时候不需要动它，保持requires_grad=True即可。但如果你先对整个模型做了requires_grad=False，记得把这个分类头再打开。我的做法是注入完之后统一跑一遍：冻结全部，然后只打开名字里带lora_的参数和classifier的参数。

for p in model.parameters(): p.requires_grad = False for n, p in model.named_parameters(): if "lora_" in n or n.startswith("classifier"): p.requires_grad = True

这种"先全冻再点名放开"的顺序比"先全开再逐个冻结"安全得多，因为后者一旦漏掉某个模块就会静默地多训一堆参数，你还看不出来。

4.3 训练循环与超参设置

超参这块，LoRA 和全量微调最大的区别在学习率。因为可训练参数少、旁路初始接近零，LoRA 能承受比全量微调大一到两个数量级的学习率。全量微调 BERT 一般用 2e-5 到 5e-5，LoRA 我用 1e-3 到 2e-3，效果稳定。

注意 weight_decay 的坑：如果你用 AdamW 并且把model.parameters()全部传给优化器，那些冻结参数的 weight decay 也会被计算，虽然没梯度不影响更新，但概念上是错的。更规范的做法是分组传参，只传需要训练的那些。另外 LayerNorm 的权重和偏置通常不施加 weight decay，这在全量微调里是常识，在 LoRA 里因为 LayerNorm 本来就冻着，所以不用管。

训练循环本身没什么特别的，标准的 PyTorch 流程。有一点要注意：混合精度下 GradScaler 是必须的，而且scaler.unscale_(optimizer)要在裁剪之前调用，顺序反了裁剪会作用在缩放过的梯度上，等于没裁。

from torch.optim import AdamW from transformers import get_linear_schedule_with_warmup trainable_params = [p for p in model.parameters() if p.requires_grad] optimizer = AdamW(trainable_params, lr=2e-3, weight_decay=0.01) num_steps = len(train_loader) * EPOCHS scheduler = get_linear_schedule_with_warmup( optimizer, num_warmup_steps=int(0.06 * num_steps), num_training_steps=num_steps, ) scaler = torch.cuda.amp.GradScaler() for epoch in range(EPOCHS): model.train() for batch in train_loader: batch = {k: v.to(device) for k, v in batch.items()} optimizer.zero_grad(set_to_none=True) with torch.cuda.amp.autocast(dtype=torch.float16): out = model(**batch) loss = out.loss scaler.scale(loss).backward() scaler.unscale_(optimizer) torch.nn.utils.clip_grad_norm_(trainable_params, 1.0) scaler.step(optimizer) scaler.update() scheduler.step()

set_to_none=True这个小细节能省一点显存和时间，因为它把梯度置为 None 而不是填零，反向传播时直接覆盖写。在 LoRA 这种参数很少的场景下收益不大，但习惯养成了没坏处。

评估部分，验证集每个 epoch 跑一次，记录准确率和 loss，用准确率做模型选择。IMDB 是均衡二分类，准确率就够用了；如果是不均衡数据，得看 F1 或者 AUC。

实测曲线大致是这样：第一轮结束验证准确率 91% 左右，第二轮 92.5%，第三轮 92.8%，第四轮开始持平甚至微降。所以我一般训三轮就停，再往后是浪费算力。

4.4 合并权重与推理加速

训练完把旁路合并回主权重，这一步很多人省略，但它对推理性能有实际影响。合并之前，每次前向都要多算两次矩阵乘法，虽然参数量小，但在高并发推理场景下累积起来是可观的。合并之后，模型结构和原始 BERT 完全一致，推理代码不用改。

合并的数学很直接：ΔW = B·A·scaling，直接加到 W₀ 上。

@torch.no_grad() def merge_lora(model): for module in model.modules(): if isinstance(module, LoRALinear): base = module.base delta = (module.lora_B @ module.lora_A) * module.scaling base.weight.data += delta.to(base.weight.dtype) module.merged = True return model

合并的时候要小心 dtype，如果主权重是 fp16，delta 是 fp32，直接加会报类型错误或者静默降精度。先 cast 再相加。另外合并是一次性的、不可逆的操作，如果你后面还要接着训或者做多任务切换，就别合并，或者合并前先存一份旁路参数。

def save_lora(model, path): state = {n: p for n, p in model.named_parameters() if "lora_" in n} torch.save(state, path) def load_lora(model, path): state = torch.load(path, map_location="cpu") model.load_state_dict(state, strict=False)

存下来的文件大概一兆出头，对比全量微调那份四百多兆，差距很明显。做多业务线的时候，一份基座权重加 N 份旁路，磁盘占用和分发成本都降下来了，这是 LoRA 在生产环境里最实用的地方。

5. 训练过程中的常见问题与排查实录

5.1 loss 不降或者震荡的排查路径

这是最高频的问题。我自己踩过、也帮别人排查过很多次，总结下来有个从快到慢的顺序。

第一步，看可训练参数占比。如果打印出来是 100% 或者接近，说明冻结没生效，那你的 LoRA 其实变成了全量微调，用小学习率（1e-3）去训全量模型，loss 必然炸。这一步三十秒能确认，先做。

第二步，看初始 loss。BERT 二分类在随机初始化分类头的情况下，初始 loss 应该在 0.69 附近（ln2）。如果你看到的是 0.3 或者 1.2，说明分类头有问题或者标签映射错了。IMDB 的标签是 0/1，跟num_labels=2对应，一般不会错，但如果你自己重映射过数据集就得检查。

第三步，看学习率。LoRA 用 5e-5 这种全量微调的学习率，表现是 loss 降得极慢，三轮下来准确率还在 85% 左右晃。很多人以为 LoRA 效果不如全量微调，其实是学习率没调。把 lr 提到 1e-3 立刻正常。

第四步，看梯度。在训练循环里插一句梯度范数打印：

total_norm = 0.0 for p in trainable_params: if p.grad is not None: total_norm += p.grad.data.norm(2).item() ** 2 total_norm = total_norm ** 0.5 print(f"grad_norm={total_norm:.4f}")

正常情况下前几十步的梯度范数在 0.1 到 2 之间波动，如果一直是 0，说明梯度断了；如果动辄上百，说明学习率太大或者没有裁剪。

第五步，检查 dropout 和 alpha。dropout 设到 0.5 在 IMDB 上会明显拖慢收敛，alpha 设成 1 而 r=16 时缩放只有 0.0625，等于把旁路效果压得几乎看不见，表现和只训分类头差不多。

5.2 显存没降下来是什么原因

有人按 LoRA 改完之后发现显存几乎没变，这种情况一般是三个原因。

一是优化器传参方式不对。如果你写的是AdamW(model.parameters(), ...)，即使大部分参数冻结，优化器仍然会为所有参数创建状态（PyTorch 的 Adam 对grad is None的参数确实会跳过状态创建，但早期版本行为不完全一致，而且有些实现会预分配）。稳妥做法是显式只传需要训练的。

二是激活值仍然是主要开销。序列长度 512、batch size 64 的时候，激活值能占到总显存的 80% 以上，这种情况下 LoRA 省下的那点参数开销几乎看不出来。想让显存真正降下来，得从 batch size、序列长度、梯度检查点这几个方向入手，那不是 LoRA 能解决的。

三是模型没有正确切换到 eval 或 train 模式。这个听起来低级，但真的常见：注入 LoRA 之后你新建了模块，它的training标志默认是 True，如果整个模型还在 eval 模式下跑前向，dropout 的行为会不一致，虽然不影响显存，但会影响结果的复现性。

5.3 效果比全量微调差一截怎么调

先明确一点：差 0.5 到 1 个点在 LoRA 上是正常的，如果你追求极致效果并且算力充足，全量微调确实更高。但如果差到 2 个点以上，那就是配置问题。

调参顺序我建议这样：先把 r 从 8 提到 16，看有没有提升，有就说明容量不够；然后加注入点，从 query+value 扩到四个投影全挂；再把 dropout 从 0.1 降到 0.05 或 0；最后考虑多训一轮。这几个动作基本上是收益递减的顺序，一般前两步就能补上大部分差距。

还有一个容易被忽略的点：分类头的初始化。BertForSequenceClassification的分类头是随机初始化的，如果你用很小的学习率，这个头在前几百步基本学不动，会拖累整体收敛。LoRA 的大学习率恰好掩盖了这个问题，但如果你为了稳定把 lr 调到 2e-4，就需要给分类头单独设一个更高的学习率。参数分组可以这么写：

lora_params, head_params = [], [] for n, p in model.named_parameters(): if not p.requires_grad: continue if n.startswith("classifier"): head_params.append(p) else: lora_params.append(p) optimizer = AdamW([ {"params": lora_params, "lr": 1e-3}, {"params": head_params, "lr": 5e-3}, ], weight_decay=0.01)

5.4 常见问题速查表

把上面这些整理成一张表，出问题的时候按表逐条对，比漫无目的地改代码快得多。

6. 消融实验与效果记录

6.1 不同秩的对比结果

为了给 r 的选择一个实证依据，我在同一份数据、同一个随机种子下跑了四组。评价指标是测试集准确率，训练都是三个 epoch，其他超参保持一致。

从 r=4 往上收益就很小了，r=32 相比 r=8 多了四倍参数，准确率只涨了 0.1 个点，耗时多了 17%。所以除非你有明确的欠拟合证据，r=8 是完全够用的起点。这也印证了那个低秩假设：情感分类这种任务需要的增量方向确实不多。

顺便记一笔全量微调和只训分类头的对照：全量微调（lr=2e-5，三个 epoch）测试准确率 93.6%，只训分类头 88.4%。LoRA 落在 92.8%，距离全量 0.8 个点，比只训头高 4.4 个点。这个位置其实很说明问题：LoRA 的价值在于用 0.27% 的参数拿到了全量微调 99% 以上的效果，而不是要在绝对指标上打赢它。

6.2 注入点组合的实测差异

最后一个配置参数量翻了三十倍，只换来 0.1 个点，性价比极低。而且它的可训练参数占比到了 0.8%，接近"半全量微调"了，LoRA 的存储和分发优势基本消失。所以我的建议很明确：默认 query + value，效果不够再考虑四投影，前馈层除非有特殊需求否则不挂。

6.3 训练过程的一个记录片段

贴一段实际训练的日志片段，让你对收敛节奏有个直观感受。这是 r=8、query+value、lr=2e-3、batch size 32 的配置：

step=50 loss=0.612 grad_norm=1.83 lr=3.1e-04 step=100 loss=0.428 grad_norm=0.94 lr=6.2e-04 step=200 loss=0.311 grad_norm=0.61 lr=1.2e-03 step=400 loss=0.224 grad_norm=0.48 lr=2.0e-03 step=800 loss=0.152 grad_norm=0.37 lr=1.6e-03 epoch=1 valid_acc=0.9102 valid_loss=0.231 epoch=2 valid_acc=0.9251 valid_loss=0.198 epoch=3 valid_acc=0.9283 valid_loss=0.211

几个观察点。第一，前一百步 loss 掉得特别快，因为旁路从零开始，模型在快速学习"往哪个方向偏"。第二，grad_norm 从 1.8 一路降到 0.37，说明优化在逐步收敛，没有出现梯度爆炸。第三，第三轮的 valid_loss 比第二轮高，但 valid_acc 也高，这是典型的边界样本置信度变化，属于正常波动，不用紧张。如果你看到 valid_loss 连续两轮明显上升而 acc 下降，那才是过拟合，该停了。

7. 最后分享几个实操心得

第一个心得关于随机种子的重要性。LoRA 可训练参数少，对初始化的敏感性反而比全量微调更高。同一个配置换三个种子，测试准确率能差 0.4 个点。所以做对比实验的时候，一定要固定种子，最好是跑三个种子取平均，否则你看到的差异可能只是噪声。

第二个心得关于保存策略。训练过程中我建议每个 epoch 都存一份旁路参数，文件名带上验证准确率。因为旁路文件只有一兆多，存十份也不占地方，但事后回滚的时候能救命。我就遇到过一次第三轮训崩了的情况，因为前两轮的旁路还在，直接拿来用，省了半小时重训。

第三个心得关于跨任务复用。同一份基座权重上，你可以挂多份不同的旁路，做任务切换的时候只需要换旁路参数，基座不用重新加载。这在部署多业务线的时候特别省事，一个进程里加载一份 BERT，配 N 组旁路，按请求路由过去。不过要注意旁路参数和基座必须严格对应，换了基座版本，旧旁路就失效了，所以版本号要绑在一起管理。

第四个心得，也是我踩得最深的一个坑：不要在没有基线的情况下直接上 LoRA。先把"只训分类头"这条最简单的基线跑通，确认数据管线、标签映射、评估逻辑全对，再去加 LoRA。因为 LoRA 引入了额外的变量，一旦结果不好，你分不清是 LoRA 配错了还是数据本身有问题。我早期有一次折腾了一下午，最后发现是验证集的 label 列名在 rename 的时候写错了，跟 LoRA 一点关系没有。先把简单路径跑通，再加复杂度，这个顺序能省掉大量无效排查。