后厨里的数学革命：用“灶台与菜”看懂 LoRA 大模型微调

slug

type

status

date

前置信息

LoRA来源于微2021年发Paper: 《LORA: LOW-RANK ADAPTATION OF LARGE LANGUAGE MODELS》低秩矩阵微调（不得不说，想出LoRA的团队真的是小天才，抓住了本质）

LoRA能够成功的原因是参数改变量之间的高度相关性。不需要去改动全部的参数，只用找到最核心、最不可替代的少量维度，通过第一阶段和第二阶段就可以以一个相当小的存储空间，完成所有操作。

地址：[https：//arxiv.org/pdf/2106.09685.pdf]

2106.09685v2.pdf

1.5 MiB

Github 地址: [https://github.com/microsoft/LoRA]

核心公式：

效果有多好的形象展示：

假设原始维度 d=1024, k=1024，我们设秩 r=8：

原本需要的空间：个参数。

LoRA 需要的空间：矩阵 B ( ) + 矩阵 A ( ) = 8192 + 8192 = 16,384 个参数。

结果： 存储空间直接压缩了约 64 倍！这就是为什么 LoRA 可以在显存很小的显卡上运行的原因。

1. 开篇：大厨与新挑战

• 背景：介绍 Base 模型（基座模型） 就像一位读过万卷食谱的“满级厨师”，他懂得所有食材的特性，但并不了解你这家餐厅（特定任务）的口味偏好。 • 痛点：如果你想让他学会做“湘菜”，传统的全量微调（Full Fine-tuning）要求他忘掉过去，重新学起，这太慢且太贵了（算力成本极高）。

2. LoRA 的登场：侧边灶台的智慧

• 核心逻辑：我们不再动主厨的大脑（冻结原模型参数），而是在他旁边放一个侧边灶台（LoRA Adapter）。 • 低秩矩阵（Rank）的本质：我们假设：虽然做一道菜很复杂，但决定“湘菜味”的核心变量（如火候、辣度）其实只有那几个。这就是本征维度（Intrinsic Dimension），不会弄的很大，4或者8就可以，如果微调的要求比较复杂，那么可能设置为64]。 ◦ 矩阵 A：负责把成百上千种食材“压缩”成几个核心风味（输入降维）。 ◦ 矩阵 B：负责把这几个核心风味还原成最终的菜品（输出升维）。

*本征维度：论文中我们一般使用r来表示，这是个超参数（搞学术的大家装逼的，或者说直译害人，hyperparameter意味着要手动进行调整的参数,看英文真的就很好理解，但是中文翻译过来，第一眼让人看得一脸懵，所以直接看英文可以加快很多效率)

3. 硬核复盘：谁该为“太咸了”负责？

审计公式（梯度公式：本质代表的是责任分配）：

• 菜（Error）：客人反馈菜太咸了，这是“上层传来的误差信号”。 • 灶台（Ax）：我们回头看，当时哪个灶台火开得最猛？提供了多少半成品？ • 责任分配（外积运算）：将“菜的错”和“灶台的功”交叉相乘，我们就得到了一张精准的责任清单（梯度矩阵）。 ◦ 每一个都会对应到一个具体的惩罚：因为 1 号菜咸了，而 2 号灶台当时出货最多，所以 2 号灶台对 1 号菜的“放盐权限”必须下调！

4. 为什么 B 最初要等于 0？（安全启动）

• 逻辑：开业第一天（初始化），我们让矩阵 B 全为 0。 • 意义：这保证了微调刚开始时，侧边灶台不输出任何杂音，完全信任“主厨”的原味。只有当客人反馈（Error）回来后，侧边灶台才开始根据上面的公式慢慢“破冰”学习。

5. 总结：小成本办大事

• 结论：LoRA 让我们在不改变主厨（Base）的情况下，只通过调节几个侧边灶台（A 和 B），就让模型变得极其听话（Instruct）。 • 工程价值：显存需求低，适配器可插拔，这就是 AI 工业化的未来。

小结语

在矩阵的世界里，秩（Rank）的降低是对信息的宽容；在工程的世界里，LoRA 的流行是对效率的追求。正如 OOP 让我们通过抽象管理复杂系统，低秩微调让我们通过抓住核心维度来掌控百亿参数。

论文中最重要的一幅图