上个月帮一个做电商评论分析的朋友改一版情感分类模型手上只有两万多条标注语料机器是一张 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×kLoRA 不去直接学 ΔW而是把它拆成两个瘦长矩阵的乘积ΔW B·A其中 A 是 r×kB 是 d×rr 远小于 d 和 k。前向计算就变成 h W₀x (α/r)·B·A·x。原始的 W₀ 冻结不动只有 A 和 B 参与训练。拿 BERT 里的 query 投影举例它是 768×768一共 589,824 个参数。取秩 r8那么 A 是 8×768B 是 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 bLoRA 包装之后变成 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 里唯一需要你手动决策的超参理解它们的物理意义比记住推荐值重要。rankr决定了旁路的容量。r 越大能拟合的增量方向越多表达能力越强参数量线性增长。r1 到 4 适合任务和预训练分布接近的情况比如情感分类这种 BERT 本来就擅长的任务r8 到 16 是通用起点r32 以上一般用在领域差异大或者数据量足的场合。我在 IMDB 上做过对比r4、8、16 的最终准确率差距在 0.3 个百分点以内但 r16 的训练时间比 r4 多了将近四成。所以别迷信大秩先从 8 试起。alphaα是缩放因子实际生效的是 α/r 这个比例。这里最容易踩坑很多人只调 r 不调 α结果 r 翻倍的时候缩放比例减半等效学习率跟着变了效果反而变差还以为是秩的问题。业界有个常见约定是让 α 2r 或者 α r前者相当于缩放系数固定为 2后者固定为 1。我自己的习惯是 α 取 2r理由是这样调 r 的时候缩放强度保持稳定变量只有一个排查起来清爽。dropout加在旁路的输入上也就是对 x 做 dropout 再送进 A。作用是防止小数据上旁路过拟合。数据量在万级的时候0.05 到 0.1 比较合适数据量在十万级以上可以设 0。我一开始忘了加IMDB 上训到第二轮验证集准确率就到顶了然后开始抖加上 0.1 的 dropout 之后曲线平滑很多。参数作用常用取值调整方向r秩控制旁路容量4 / 8 / 16 / 32欠拟合调大过拟合调小alpha缩放强度实际生效 α/r常取 2r 或 r与 r 联动别单独动dropout旁路输入随机丢弃0 / 0.05 / 0.1小数据调大大数据调小2.3 参数量与显存账本算一笔明白账先算参数量。BERT-base 每层注意力有四个 768×768 的投影矩阵query、key、value、output。十二层合计是 4 × 12 × 589,824 ≈ 2830 万占模型总量的四分之一左右剩下的主要是词嵌入约 2340 万和前馈网络每层两个 768×3072约 4720 万。只给 query 和 value 注入 LoRAr8 时单个矩阵的旁路参数 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 下的优化器状态约 880MBAdam 两份动量梯度 440MB权重 440MB合起来 1.7GB 左右。LoRA 只训练三十万参数优化器状态加梯度加新权重总共不到 5MB这部分开销基本可以忽略。真正剩下的显存开销就是前向激活值这部分跟全量微调一样省不掉。实际测下来batch size 32、序列长度 256、混合精度开启的情况下全量微调峰值显存约 9.2GBLoRA 版本约 7.1GB。节省的两点多 G 就是那部分参数相关的开销。这意味着同样的卡你可以把 batch size 从 32 提到 48 甚至 64训练速度又能往上提一截。配置可训练参数优化器梯度显存峰值显存bs32, len256单 epoch 耗时全量微调约 1.1 亿约 1.3GB约 9.2GB约 780sLoRA r8q,v约 29.5 万约 5MB约 7.1GB约 520sLoRA r8q,k,v,o约 59 万约 10MB约 7.2GB约 540s仅训分类头约 1,536极小约 6.8GB约 480s表里的耗时是在同一张卡、同一份数据上跑出来的量级参考不同硬件和框架版本会有出入重点看相对关系。可以看到 LoRA 的速度提升主要来自两处可训练参数少了反向传播的计算量减少显存腾出来了batch size 可以调大。3. 实操准备环境、数据与模型改造3.1 环境与依赖的版本坑环境这块我不想写得太教条但有几个版本组合确实会咬人。核心依赖就三个PyTorch、Transformers、Datasets。建议 PyTorch 2.0 以上因为 torch.compile 和 autocast 的行为在新版本里更稳定。Transformers 建议 4.30 以上再老的版本里 BERT 的注意力实现是分开写死的做模块替换的时候路径不一样。pip install torch2.0.0 transformers4.30.0 datasets2.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_length256性价比最高。如果你做的是长文档分类那就得考虑滑动窗口或者 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], truncationTrue, max_length256, paddingmax_length, ) encoded raw.map(tokenize_fn, batchedTrue, batch_size1000, remove_columns[text]) encoded encoded.rename_column(label, labels) encoded.set_format(typetorch, columns[input_ids, attention_mask, labels])注意paddingmax_length在这里是为了让整个数据集长度统一方便后面直接用默认的 collate 组 batch。如果你想省显存可以改成paddingFalse配合 DataCollatorWithPadding 做动态填充短样本不浪费算力。动态填充在 IMDB 上能省下大概 15% 的训练时间因为长度分布不均固定填到 256 会有大量无意义的 pad token 参与计算。不过注意力掩码会屏蔽掉它们所以对结果没影响纯看你要不要那点速度。数据划分上官方给的是 25000 训练 / 25000 测试。我建议从训练集里再切 2000 条做验证集用来选超参和 early stopping测试集留到最后只跑一次。直接在测试集上反复调参最后报出来的数字是不可信的。split encoded[train].train_test_split(test_size2000, seed42) 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 层并注入 BERT4.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, amath.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 fr{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_gradTrue的参数。4.2 权重注入与参数冻结策略注入的做法是把父模块里的子模块替换成包装后的版本。核心是setattr但要注意父模块的获取方式。def inject_lora(model, target_names(query, value), r8, alpha16, dropout0.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, rr, alphaalpha, dropoutdropout) setattr(parent, child_name, new_layer) return modelget_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(ftotal{total:,} trainable{trainable:,} fratio{100 * trainable / total:.3f}%) print_trainable(model)BERT-base 加 r8、queryvalue 的配置期望输出是 total 约 1.09 亿trainable 约 29.6 万多了分类头的 1536比例 0.27% 左右。如果 trainable 显示还是一亿多说明冻结没生效八成是LoRALinear.__init__里那句循环没跑到或者你在注入之前就把模型设成了requires_gradTrue并且后面又没重新冻结。分类头这块单独说一下。BertForSequenceClassification自带一个classifier它本来就是要训练的注入 LoRA 的时候不需要动它保持requires_gradTrue即可。但如果你先对整个模型做了requires_gradFalse记得把这个分类头再打开。我的做法是注入完之后统一跑一遍冻结全部然后只打开名字里带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-5LoRA 我用 1e-3 到 2e-3效果稳定。超参取值说明learning_rate1e-3 ~ 2e-3比全量微调大两个量级batch_size32 ~ 64显存省下来了可以调大epochs3 ~ 4IMDB 上 3 轮基本收敛warmup_ratio0.06前 6% 步数线性预热weight_decay0.01只作用于 LoRA 参数和分类头max_grad_norm1.0梯度裁剪防止早期不稳schedulerlinear decay预热后线性衰减到 0注意 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, lr2e-3, weight_decay0.01) num_steps len(train_loader) * EPOCHS scheduler get_linear_schedule_with_warmup( optimizer, num_warmup_stepsint(0.06 * num_steps), num_training_stepsnum_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_noneTrue) with torch.cuda.amp.autocast(dtypetorch.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_noneTrue这个小细节能省一点显存和时间因为它把梯度置为 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如果主权重是 fp16delta 是 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_locationcpu) model.load_state_dict(state, strictFalse)存下来的文件大概一兆出头对比全量微调那份四百多兆差距很明显。做多业务线的时候一份基座权重加 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_labels2对应一般不会错但如果你自己重映射过数据集就得检查。第三步看学习率。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(fgrad_norm{total_norm:.4f})正常情况下前几十步的梯度范数在 0.1 到 2 之间波动如果一直是 0说明梯度断了如果动辄上百说明学习率太大或者没有裁剪。第五步检查 dropout 和 alpha。dropout 设到 0.5 在 IMDB 上会明显拖慢收敛alpha 设成 1 而 r16 时缩放只有 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看有没有提升有就说明容量不够然后加注入点从 queryvalue 扩到四个投影全挂再把 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_decay0.01)5.4 常见问题速查表把上面这些整理成一张表出问题的时候按表逐条对比漫无目的地改代码快得多。现象最可能的原因排查动作处理方式loss 完全不降参数冻结没生效或反过来全冻了打印 trainable 占比按先全冻再点名放开重设loss 前几十步爆炸学习率过大或初始化错误看 grad_norm 量级lr 降到 1e-3确认 B 为零初始化准确率卡在 85% 左右学习率太小对比 lr5e-5 和 1e-3提到 1e-3 到 2e-3显存几乎没省优化器传了全部参数检查 AdamW 的入参只传 requires_grad 的验证集第二轮开始下降过拟合看 train/valid loss 分叉加 dropout、减 epoch、加 weight_decay推理速度没变快没做权重合并检查是否存在 LoRALinear调用 merge 或换回原模型保存的文件四百多兆存了全量 state_dict看保存的 key只存名字含 lora_ 的参数dtype 报错混合精度下 LoRA 参数类型不一致看报错行号前向时显式 cast 到 fp326. 消融实验与效果记录6.1 不同秩的对比结果为了给 r 的选择一个实证依据我在同一份数据、同一个随机种子下跑了四组。评价指标是测试集准确率训练都是三个 epoch其他超参保持一致。ralpha可训练参数测试准确率单 epoch 耗时24约 7.4 万92.2%约 505s48约 14.8 万92.6%约 512s816约 29.5 万92.8%约 520s1632约 59 万92.9%约 548s3264约 118 万92.9%约 610s从 r4 往上收益就很小了r32 相比 r8 多了四倍参数准确率只涨了 0.1 个点耗时多了 17%。所以除非你有明确的欠拟合证据r8 是完全够用的起点。这也印证了那个低秩假设情感分类这种任务需要的增量方向确实不多。顺便记一笔全量微调和只训分类头的对照全量微调lr2e-5三个 epoch测试准确率 93.6%只训分类头 88.4%。LoRA 落在 92.8%距离全量 0.8 个点比只训头高 4.4 个点。这个位置其实很说明问题LoRA 的价值在于用 0.27% 的参数拿到了全量微调 99% 以上的效果而不是要在绝对指标上打赢它。6.2 注入点组合的实测差异注入模块可训练参数测试准确率query约 14.7 万92.1%value约 14.7 万91.9%query value约 29.5 万92.8%query key value output约 59 万92.9%四投影 前馈层约 890 万93.0%最后一个配置参数量翻了三十倍只换来 0.1 个点性价比极低。而且它的可训练参数占比到了 0.8%接近半全量微调了LoRA 的存储和分发优势基本消失。所以我的建议很明确默认 query value效果不够再考虑四投影前馈层除非有特殊需求否则不挂。6.3 训练过程的一个记录片段贴一段实际训练的日志片段让你对收敛节奏有个直观感受。这是 r8、queryvalue、lr2e-3、batch size 32 的配置step50 loss0.612 grad_norm1.83 lr3.1e-04 step100 loss0.428 grad_norm0.94 lr6.2e-04 step200 loss0.311 grad_norm0.61 lr1.2e-03 step400 loss0.224 grad_norm0.48 lr2.0e-03 step800 loss0.152 grad_norm0.37 lr1.6e-03 epoch1 valid_acc0.9102 valid_loss0.231 epoch2 valid_acc0.9251 valid_loss0.198 epoch3 valid_acc0.9283 valid_loss0.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 一点关系没有。先把简单路径跑通再加复杂度这个顺序能省掉大量无效排查。