← 总目录 / 板块一 · 模型的范式变迁
板块一 · 模型的范式变迁

第10篇 · LoRA

把微调的增量压进一个低秩子空间——参数高效微调的奠基之作
LoRA: Low-Rank Adaptation of Large Language Models · Edward Hu 等,Microsoft Corporation · 2021(ICLR 2022) · arXiv:2106.09685

本页所有数字均复述自论文原文,未做外部验证;标注【论文声称】【实验支持】【解读者补充】【解读者观点】以区分来源。

一、全局大图

1.1 摘要拆解与导航表

摘要的每个短语都能映射到论文章节。下表兼作全文导航:

摘要短语对应原文章节本页精读章节
"full fine-tuning becomes less feasible"§1–§2 问题陈述二·A 全量微调的账单
"deploying independent instances… prohibitively expensive"§2、脚注4二·A 手算验证
"freezes the pre-trained model weights and injects trainable rank decomposition matrices"§4 方法二·C LoRA方法本体
"reduce trainable parameters by 10,000 times, GPU memory by 3 times"§4.2 Practical Benefits二·D 工程账单与数字对账
"no additional inference latency"§3(对比adapter)、§4.1二·B 现有方案为何不够好
"on-par or better on RoBERTa, DeBERTa, GPT-2, GPT-3"§5 实验二·E 实验结果精读
"empirical investigation into rank-deficiency"§7 Understanding Low-Rank Updates二·F 低秩之谜:ΔW到底长什么样

1.2 贡献清单与证据强度预评

#论文声称的贡献预评证据强度
1低秩重参数化 ΔW=BA 可替代全量微调且不掉点强实验支撑 四个模型规模+三个任务族主表
2无推理延迟(权重可合并)构造性证明 + 延迟实测 §4.1 by construction,§3 Table 1 反证adapter
3训练显存降至1/3、checkpoint缩小万倍、吞吐提升25%工程陈述为主 给出数字但无系统消融
4适配增量具有极低"内在秩"(r=1甚至够用)仅有消融 Table 6 + 子空间分析,但只测了两个数据集
5ΔW放大了W中"未被强调"的方向而非重复其顶部方向解释性主张 Table 7 支持相关结论,机制解读属推测成分

1.3 知识依赖主干线

过参数化模型处于低内在维流形(Li et al. 2018a / Aghajanyan et al. 2020)→ 猜想:适配时的权重更新同样低秩 → 重参数化 h=W₀x+BAx → 可合并 ⇒ 零推理延迟 → 实验证实 r=1~4 即够用 → 子空间分析反推微调机制。

1.4 推荐阅读路线

必读主线:§2 → §3 → §4 → §5.5(GPT-3) → §7.2。可跳读支线:§5.2–§5.4 的 GLUE/E2E 细节表(跳过的代价:看不到"LoRA 在 RTE 上比 FT 高 86.6 vs 78.7"这类细节证据);附录 D 超参。值得慢读:§4.1 与 §7.2 是全文两个枢纽——前者定义了此后整个 PEFT 领域的语法,后者回答"为什么这么小的秩就够"。

二、逐章精读

A. 问题表述:全量微调的账单【来源:论文§2】

失效模式先行。全量微调的问题不是"训不动"而是"存不下、换不起":对每个下游任务,学到的增量 ΔΦ 维度等于 |Φ₀| 本身。GPT-3 有 |Φ₀|≈1750 亿参数(§2),意味着每个任务的独立副本都是一个 175B 模型。论文脚注4给出部署账单:100 个任务的全量微调副本 ≈ 100 × 350GB ≈ 35TB 存储。

学习目标:学完本节能写出全量微调的目标函数(式1),并解释为什么把它改写成对 Θ 的优化(式2)是"参数高效"的形式化表达。

maxΦ Σ(x,y)∈𝒵 Σt=1..|y| log(PΦ(yt|x,y<t)) → maxΘ … log(pΦ₀+ΔΦ(Θ)(…))

式2的含义:解读者补充——把"自由变量从 Φ 换成 Θ",即不再直接优化 175B 个权重,而是优化一个远小于它的编码 |Θ|≪|Φ₀|。LoRA 就是给 ΔΦ(Θ) 选了一种具体编码:ΔΦ = BA。论文声称 GPT-3 上 |Θ| 可以小到 |Φ₀| 的 0.01%(§2)。手算核验:175,255.8M × 0.01% ≈ 17.5M,与后文 LoRA 37.7M(rq=rv=8)同量级、比 4.7M 还宽松一个数量级,该声称成立。

常见误读①:"参数高效微调是为了省训练算力"。原文动机第一位的是存储与任务切换成本(每任务一个小模块),省显存只是附带收益。

一句话蒸馏:全量微调让每个下游任务都复制一份 175B 模型;参数高效方法的本质是把 ΔΦ 编码成小得多的 Θ。

B. 失效模式先行:Adapter 与 Prefix 为什么不够好【来源:论文§3】

学习目标:能说出两类已有方法各自的失效模式,并复述延迟表的至少一组数字。

Adapter 层引入串行推理延迟

Adapter 在 Transformer 块之间插入新层,新增 FLOPs 不多,但必须串行执行——大模型靠并行吃满硬件才压得住延迟,在线推理 batch size 通常为 1,此时串行深度就是延迟。Table 1(GPT-2 medium,NVIDIA Quadro RTX8000,100次前向平均):

配置batch/长度/|Θ|FT或LoRAAdapterᴸAdapterᴴ
离线大batch32 / 512 / 0.5M–11M1449.4 ms+2.2%+3.0%
在线小batch1 / 128 / 11M19.8 ms+20.7%(23.9ms)+30.3%(25.8ms)

【解读者观点】这是全文最容易被低估的一张表:它说明"参数少 ≠ 计算开销小",延迟由结构位置决定而不由参数量决定。这正是 LoRA 选择"并联旁路"而非"串联插入"的直接原因。

Prompt 类方法的两个坑

Prefix-tuning 占用序列长度(为适配保留的 token 挤占了任务可用的上下文),且性能随可训练参数非单调变化:GPT-3 上超过 256 个特殊 token(PreEmbed)或 32 个(PreLayer)反而显著掉点(§5.5),作者猜测是输入分布被推离了预训练分布。【解读者补充】这一现象后来成为 prompt 类方法在长序列时代式微的原因之一。

闭卷自检:不看材料,我能说出 adapter 在线场景延迟增加的两个百分比吗?能说出 prefix 掉点的临界 token 数吗?

C. 方法本体:h = W₀x + BAx 的公式手术【来源:论文§4.1–§4.2】

直觉类比:冻结的原模型是一座已建成的图书馆,LoRA 不改建图书馆,而是在旁边修一条 r 米宽的小走廊(BA),让信息经过图书馆后再过一道"任务修正"。类比在哪里失效:走廊不是独立的第二通道——最终部署时 B A 会被加回 W₀ 合并成 W=W₀+BA,图书馆和小走廊融为一体,仿佛从未分开。

公式手术

h = W₀x + ΔWx = W₀x + B A x,其中 B∈ℝd×r,A∈ℝr×k,r ≪ min(d,k)
符号它是什么直觉
W₀ ∈ ℝd×k预训练冻结权重共享底座,永不更新
A ∈ ℝr×k降维投影(随机高斯初始化)把 k 维输入压到 r 维瓶颈
B ∈ ℝd×r升维投影(零初始化)把 r 维修正投回 d 维输出
rLoRA 秩修正信号的"带宽";GPT-3 上 d=12288 而 r 可取 1–4
α/r缩放系数ΔWx 乘以 α/r;用 Adam 时调 α ≈ 调学习率,故固定 α 为第一次尝试的 r 后不再调

张量形状与维度流:x∈ℝk → A 把它压到 ℝr → B 升回 ℝd,与 W₀x 逐坐标相加。两条路径输出维度相同(都是 d),这就是"并联"的结构含义。

关键设计决策三连(答辩预演)

常见误读②:"LoRA 学到的是一个更小的压缩版模型"。错。LoRA 学的是更新的低秩参数化,不是模型的压缩;W₀ 从头到尾完整存在且参与前向。

常见误读③:"LoRA 一定比全量微调省时间"。合并后的推理确实零额外开销,但若不同任务要在一个 batch 里混跑,合并后的 W 无法按样本切换 LoRA 模块(§4.2 明确承认此局限);且训练时多了一条旁路的前向/反向,吞吐收益来自"免算大部分梯度"而非计算量绝对减少。

一句话蒸馏:LoRA = 冻结 W₀,用零初始化的并联低秩旁路 BA 参数化全部更新,线性性保证可合并 ⇒ 存储省万倍、推理零延迟。

D. 工程账单与数字对账【来源:论文§4.2 及脚注】

账目缓解的压力新增的压力/债
只训 A、B显存(免存冻结参数的 Adam 优化器状态):GPT-3 训练 VRAM 1.2TB → 350GB需要维护两套权重的合并/还原逻辑
r=4 只挂 Wq,Wv存储:checkpoint 350GB → 35MB(≈10,000×);100个任务 ≈354GB 而非 35TB跨任务混批推理困难(§4.2 承认)
免梯度回传大部分参数吞吐 +25%:32.5 → 43.1 tokens/s/V100旁路本身的计算是净增项(batch大时占比上升)

数字对账(解读者核算)

论文称可训参数"减少 10,000 倍"。逐条验算 GPT-3(96 层,d_model=12288):

E. 实验结果精读【来源:论文§5,Table 2–4】

评测配置要点(魔鬼在配置里):与 adapter 公平对比时,LoRA 被限制在 seq len=128、固定 batch size、且 MRPC/RTE/STS-B 从预训练模型(而非 MNLI 适配后模型)出发(†标记行)。引用的基线数字尽量沿用先前工作发表值(*行)——这意味着部分基线并非作者亲手复现。

GPT-3 175B 主表(Table 4)

方法|Θ|WikiSQL 准确率%MNLI-m %SAMSum R1/R2/RL
Full FT175,255.8M73.889.552.0/28.0/44.5
BitFit14.2M71.391.051.3/27.4/43.5
PreEmbed3.2M63.188.648.3/24.2/40.5
PreLayer20.2M70.189.550.8/27.3/43.5
Adapterᴴ (40.1M)40.1M73.291.553.2/29.0/45.1
LoRA (4.7M)4.7M73.491.753.8/29.8/45.9
LoRA (37.7M)37.7M74.091.653.4/29.2/45.1

主张 vs 事实:【实验支持】LoRA 用 4.7M 参数在三个任务上匹配或超过 175,255.8M 的全量微调。【论文声称】"not all methods benefit monotonically from more trainable parameters"——LoRA 自己在 MNLI/SAMSum 上从 4.7M 加到 37.7M 也略降,说明参数更多并不必然更好,作者归因存疑处未深究。波动范围:WikiSQL ±0.5%、MNLI-m ±0.1%、SAMSum ±0.2 左右——注意 WikiSQL 上 LoRA(74.0) 对 FT(73.8) 的领先只有 0.2,落在噪声带内,不应解读为显著超越。

附录A补一刀动机证据:GPT-3 few-shot 在 MNLI-m 只有 40.6%、RTE 69.0%,微调后分别 89.5%、85.4%——大模型的 in-context 能力不能替代参数更新。

一句话蒸馏:四个模型规模上,千分之一级别的可训参数持续追平或超过全量微调,且唯一没有推理延迟副作用的 PEFT 方案。

F. 低秩之谜:ΔW 到底长什么样【来源:论文§7】

学习目标:能复述"哪些矩阵该挂 LoRA""最优 r 是多少""ΔW 与 W 的关系"三问的答案及各自证据类型。

F1. 该挂哪些矩阵?(Table 5,18M 固定预算)

同样 18M 预算下:只挂 Wq(r=8)WikiSQL 仅 70.4;挂 Wq+Wv(各 r=4)73.7;四类全挂(各 r=2)73.7 且 MultiNLI 最高 91.7。广度胜过深度:宁可多挂几类矩阵用小 r,也不要在一类上堆大 r。MLP 层是否也值得挂?论文明确留作 future work(§4.2)——后来的实践证明 MLP 同样有效,这属于原文未覆盖的部分。

F2. 最优 r 是多少?(Table 6)

{Wq,Wv} 配置下 r=1 已达 WikiSQL 73.4 / MNLI 91.3,加到 r=64 无实质提升。子空间分析(式4的 Grassmann 归一化相似度 φ∈[0,1])显示:A(r=8) 与 A(r=64) 的顶部奇异向量高度重叠(相似度>0.5),其余方向近乎随机噪声;不同随机种子的两次 r=64 训练也只在少数顶部方向上一致。这构成"内在秩很低"的核心证据——但它只测了 WikiSQL/MNLI 两个数据集和第48层。【解读者观点】对跨语言迁移、风格重写等大改动任务,作者自己在脚注6承认小 r 未必够。

F3. ΔW 与 W 的关系(Table 7)

把 Wq 投影到 ΔWq 的 top-r 子空间:‖U⊤WqV⊤‖_F = 0.32(r=4)/1.90(r=64),而 ‖Wq‖_F=61.95、‖ΔWq‖_F=6.91。三条结论:(1) ΔW 与 W 相关性强于随机矩阵(0.32 vs 0.02),它放大 W 中已有的特征;(2) 但它不重复 W 的 top 方向,而是放大 W 中未被强调的方向;(3) 放大因子巨大:6.91/0.32 ≈ 21.5。【论文声称】这暗示适配是在"唤醒"预训练中学到但对通用目标不重要的能力——机制层面这是解释性推测,不是定理。

常见误读④:"r=1 就够用"是本文的普适结论。错。Table 6 只覆盖两个 NLU 任务;单挂 Wq 时 r=1 明显不足(68.8 vs r=4 的 70.5)。正确表述是:在这类与预训练分布相近的任务上,内在秩可以非常低。

闭卷自检清单:我能不看书写出 h=W₀x+BAx 并标出每个矩阵形状吗?能算出 rq=rv=8 时的可训参数吗?能说出 21.5 这个放大因子是怎么来的吗?能说出 LoRA 相对 adapter 的结构性优势是什么吗?

三、批判性阅读

3.1 这些 benchmark 到底测什么

WikiSQL 测的是受限模板下的 NL→SQL 逻辑形式准确率——它衡量"格式化生成+表格理解",不代表开放域 Text-to-SQL 难度;MNLI-m 测三分类自然语言推断;SAMSum 测对话摘要的 ROUGE(对摘要质量本身是不完美的代理)。GLUE 各子任务指标异质(CoLA 用 Matthews 相关、STS-B 用 Pearson),求平均 Avg 时这些不可通约的分数被直接平均——【解读者观点】Avg 列的涨跌应谨慎解读。

3.2 比较公平吗

三点值得警惕:(1) 大量基线数字直接引自先前工作(*行),超参搜索空间未必对齐;(2) 与 adapter 对比时 LoRA 接受了†标记的更严苛设定,这部分公平;但 adapter 文献中也有缓解延迟的多任务技巧(Rücklé 2020),论文虽提及但主叙事突出其短板;(3) GPT-3 实验每个配置只调了学习率(附录D.4),epoch 固定 2、batch 固定 128——对基线和 LoRA 一视同仁,这点公平,但也意味着所有方法都可能未达各自最优。

3.3 第二坐标轴:成本

本文的最大贡献其实在效果分之外:存储(35MB/任务)、切换成本(减 BA 加新 BA 即可热切换)、训练吞吐(+25%)、显存门槛(1.2TB→350GB 让更多实验室训得起 175B 微调)。若只看准确率表,会错过这篇论文改变行业的真正原因。

3.4 论文没有告诉你什么

声明:以上所有数字仅复述自论文原文,未经外部验证。

四、综合考核

4.1 重建因果链

仅从"175B 参数 / 每任务一份副本 / 在线推理 batch=1"三个事实出发,推演为什么 LoRA 必须同时满足:低秩、并联、线性、零初始化。参考答案见折叠块。

参考答案与评分标准(4要点)

①175B ⇒ 全量副本存储不可行 ⇒ 必须参数化小增量(逼出低秩分解);②在线 batch=1 ⇒ 任何串行新增深度都会放大延迟(§3 的 +20~30%)⇒ 增量必须并联;③并联旁路要零延迟 ⇒ 必须可与 W₀ 合并 ⇒ 必须线性(无激活函数);④微调要从预训练行为出发 ⇒ 初态 ΔW=0 ⇒ B 零初始化。评分:每点 2.5 分,缺"线性⇒可合并"这环扣分最多,因为它是 LoRA 区别于 adapter 的本质。

4.2 数字总对账(5 组)

请自行验算并对照:① 4.7M 与 rq=rv=1 公式值;② 37.7M 与 rq=rv=8;③ 18M 预算与 FP16 字节数(论文写 35MB vs 算出 37.7MB);④ 1.2TB/350GB 与摘要"3倍";⑤ 350GB/35MB 与摘要"10,000倍"及参数口径 175,255.8M/4.7M≈37,000 的差异。

对账答案

①2×96×2×12288×1≈4.72M ✓;②×8≈37.75M ✓;③18.87M×2B=37.7MB≠35MB,论文取整偏小,量级无误;④3.43≈"3 times"✓;⑤checkpoint 口径恰为 10,000,参数口径约 37,000,摘要的"10,000 times trainable parameters"严格说口径不严谨——这是精读发现的原文小瑕疵。

4.3 设计决策答辩(3 题)

4.4 证据审计(回看 1.2 预评)

贡献1维持"强实验支持"(四模型三任务一致);贡献2升级确信度——既有构造性证明又有 Table 1 反证;贡献3维持"工程陈述",因 25% 吞吐提升无独立消融;贡献4读后降半档:证据只在两个数据集成立,且作者脚注自我设限;贡献5维持"解释性主张":Table 7 数字支持相关性结论,但"放大未被强调的特征"的机制语言超出数据所能证明的范围。

4.5 自测题(四级题型)

  1. L1 直接应用对 GPT-3(96 层,d_model=12288)使用 LoRA,只挂 Wq 和 Wv,rq=rv=4,可训练参数是多少 MB(FP16 存储)?
    标准答案

    |Θ|=2类型×96层×2块×12288×4=18.87M;FP16 每参数2字节 ⇒ ≈37.7MB。容差±0.5MB。变式:若四类注意力矩阵各 r=2,参数量相同(仍18.87M),这正是§7.1固定预算实验的设计逻辑。

  2. L1 直接应用训练开始时模型输出的前向结果与原始预训练模型完全一致的直接原因是什么?
    标准答案

    B 初始化为零 ⇒ ΔW=BA=0 ⇒ h=W₀x。注意:仅有 A 高斯随机、B 为零这一个条件就够了;答"A 和 B 都为零"不得分(那样无法打破对称性、A 无梯度流动路径……严格说 B=0 时 A 的梯度也不为零,但论文设计是 A 高斯、B 零)。

  3. L2 迁移某团队要在同一个已合并 LoRA 的 70B 底座上同时服务 50 个租户的不同微调版本,且要求单请求毫秒级切换。应该合并还是不合并?说明权衡。
    参考答案与评分标准

    应选择不合并:保留 W₀ 常驻显存,按请求动态选择 LoRA 模块(论文§4.2明确给出该选项)。评分要点:①指出合并后无法按样本/请求切换单 batch 内的不同任务(3分);②指出不合并的代价是旁路两跳小矩阵乘带来的少量延迟,但 batch=1 场景下 BA 的 FLOPs 远小于 W₀x(3分);③指出存储只需 350GB+50×35MB 量级而非 50 份底座(2分);④提到混合方案(高频任务合并缓存)加分(2分)。

  4. L2 迁移把 LoRA 的 α/r 缩放去掉(即 h=W₀x+BAx 不再除 r)。当用户从 r=4 调到 r=64 时,训练动态会发生什么问题?
    参考答案

    B×A 的乘积尺度随 r 增大而增大(更多项求和),初始后更新的数值尺度随之漂移,相当于隐式改变了更新步长的有效大小,原先调好的学习率失配,需要重新调 lr 或重新缩放初始化。评分要点:说出尺度随 r 漂移(5分)+联系到 α/r 的设计目的是"减少换 r 时的超参重调"(3分)。

  5. L3 构造反例"既然 r=1 在 WikiSQL 上就够用,那么任何下游适配都可以用 r=1。"请构造至少两个该命题失败的具体场景,并说明为何本文证据不支持它。
    参考答案与评分标准

    场景示例:①下游任务与预训练语言不同(论文脚注6自己的思想实验:跨语言重训接近 r=d_model 的全量更新才能赢);②需要大量新知识/新格式的任务(如长文档新领域代码生成),更新方向数可能超过1;③单挂 Wq 时 r=1 已明显不足(68.8 vs 70.5),说明"哪个矩阵、什么任务"共同决定所需秩。评分:每个场景3分(须说明失效机制),指出原文证据仅限 WikiSQL/MNLI 两个近分布任务再加4分。

  6. L4 综合综合 §3、§4、§7:如果 LoRA 的旁路里加了一个 ReLU,论文的四条核心优势各会受到什么影响?
    参考答案与评分标准

    ①零推理延迟丧失:非线性使 BA 无法并入 W₀,退化为类似 adapter 的串联/并联常驻计算(4分);②存储优势不变(A、B 参数量不变)(2分);③训练显存优势基本不变(优化器状态仍只针对 A、B)(2分);④§7 的低秩解释框架部分失效:ΔW 不再是线性算子,"投影到 ΔW 子空间""放大因子"等分析失去定义(4分)。总评:一条非线性同时摧毁"可合并性"这条主线,说明 LoRA 的全部工程红利几乎都源自"线性+低秩"两个约束。