【AI工程师精讲】10：微调方案选型：全参微调、LoRA、QLoRA 到底怎么选

在技术评审里，经常出现这样一段对话：

"我们有两张卡，显存够，那就全参微调吧。"

这个推理的漏洞在于：它把"能不能做"当成了"该不该做"。

显存只是约束之一------而它甚至不是最重要的那一个。

真正决定选型的是三个问题：

你要改的是模型的什么？（表达方式，还是知识）
你有多少数据？
上线后要怎么维护这些模型？

这篇文章把这几个方案的能力边界讲清楚。先给结论：

绝大多数业务微调的需求，LoRA 一类的方法就足够；而真正需要全参微调的场景，比多数人想的少得多。

第一部分：四类方案，从"改得多"到"改得少"

按改动范围从大到小排列。

1.1 第一类：全参微调

更新模型全部参数。

	内容
优点	表达能力上限最高
代价	对显存、数据量、训练稳定性的要求也最高
适合	"要深度改造模型行为"的场景

1.2 第二类：LoRA 一类（低秩旁路）

冻结基座，只训低秩旁路矩阵。

	内容
优点	多数任务上效果接近全参，显存需求大幅下降，还能做到多任务可插拔
代价	学不进大量新知识（原理决定，见 009 篇）

1.3 第三类：QLoRA

在量化后的基座上做 LoRA。

它把门槛压到"单张消费级显卡可以微调中等规模模型"。

	内容
优点	显存门槛最低
代价	训练速度更慢、精度略有损失

1.4 第四类：Adapter 与提示微调

（Prefix Tuning / Prompt Tuning）

在模型里插入少量新模块，或只训练一段额外的"前缀向量"。

	内容
优点	参数量最少
代价	表达能力也最受限，通常只适合风格与格式层面的轻量调整，且推理有额外开销

1.5 一句话概括这四类

改动范围越小，成本越低、越安全，但能改的东西也越少。

第二部分：对比不能只看显存

把常见的对比维度补齐，你会发现结论和直觉不一样。

2.1 六维对比表

维度	全参微调	LoRA	QLoRA	提示微调类
显存需求	最高（模型+梯度+优化器状态）	中	最低	低
效果上限	最高	接近全参（多数任务）	略低于 LoRA	有限
数据需求	大	中	中	小
多任务切换	需多份完整权重	换小文件即可	同 LoRA	同 LoRA
推理开销	无	合并后无	量化损失	有额外前缀计算
训练稳定性	较难调	较稳	较稳但更慢	稳定
主要风险	遗忘、成本	学不进新知识	精度损失	能力提升有限

2.2 读这张表的关键

真正拉开差距的是"数据需求"和"多任务切换"，而不是显存。

为什么？ 因为这两项恰恰是工程上最贵的东西：

数据需求高 → 意味着你要投入大量人力去采集、清洗、标注；
多任务切换成本高 → 意味着每加一个业务就要多一份完整权重，显存线性增长，运维复杂度也跟着涨。

而显存是可以买的 ------多买一张卡就解决了。但数据和工程习惯买不到。

这个视角的转换很重要：它让你从"我能买多少卡"转向"我能不能持续维护这条链路"。

第三部分：按你要改的东西来选

这是最实用的一节。按目标反推方案。

3.1 目标一：让它按某种风格/格式输出

选 LoRA，甚至提示微调就够。

理由：这类需求本质是"引导已有能力"，不需要动很多参数。

具体配置建议：只挂注意力层的投影，r 取 8~16。

3.2 目标二：让它掌握某个领域的表达习惯与术语

选 LoRA，建议把前馈层也纳入目标模块。

理由：术语与表达习惯比纯格式更深一层，需要更多参数容量。

具体配置建议 ：加上前馈层，r 取 16~32。数据质量比数量重要。

3.3 目标三：让它具备大量新知识

这里要说清楚：微调不是好工具。

原因（原理层面）：LoRA 的低秩旁路能承载的信息量有限，而且只作用于部分层。它擅长改"怎么说"，不擅长改"知道什么"。

知识注入更适合两条路：

检索增强（把知识放在外部）；
继续预训练 + 指令微调（成本高得多）。

用 LoRA 硬灌知识，通常表现是"说得像但记不准"。

这个失败模式很典型 ：模型学会了"用我们行业的语气引用某个概念"，但引用的内容经常是错的。它比"明显不知道"更危险，因为它看起来像知道。

3.4 目标四：改变模型的推理或对齐行为

这类需求往往需要偏好优化（对齐类方法）而非单纯微调。

SFT 能让它学会格式，但很难改变它的偏好倾向。

举个具体例子：你希望模型在不确定时倾向于说"我不知道"，而不是编一个答案。

用 SFT ：给它一堆"说不知道"的样本------它学会的是"在某些输入下输出这句话"，而不是"不确定时该怎么做"；
用偏好优化 ：给它成对的偏好数据（"说不知道"优于"编答案"），它学到的是偏好方向。

这两者的泛化能力差很多。

3.5 目标五：需要一个专用小模型替换大模型

考虑"蒸馏 + 微调" ，并且通常要用全参或较大秩的 LoRA。

理由：这已经不是"引导已有能力"，而是要重建一个能力分布。

3.6 所以第一个判断问题

我改的是"表达"还是"能力"？

改表达 → 用参数高效方法（LoRA 系）；
改能力 → 要准备更多投入（全参、继续预训练、偏好优化）。

这一个问题就能定掉大部分选型。

第四部分：QLoRA 的边界------它省的是显存，不是时间

QLoRA 常被当作"平民方案"，但它有三个必须知道的性质。

4.1 性质一：它省显存，但训练更慢

量化基座在前向和反向时都要额外做反量化与精度转换。

后果：吞吐通常明显低于同规模的普通 LoRA。

这一点在估算项目周期时经常被忽略 ：很多人以为"显存小了，训练会更快"，实际相反。

4.2 性质二：它有精度损失，但影响通常在可接受范围

量化误差会体现在训练稳定性上 ，特别是秩较大、学习率较高时更容易出现异常（比如损失突然跳变、梯度爆炸）。

一个实用做法 ：先在 QLoRA 上跑通，再用相同配置在 LoRA 上复现一次。如果两者效果接近，说明精度损失可接受。

4.3 性质三：它最适合"数据不多、想先验证可行性"

场景	是否适合 QLoRA
先跑通、看看这条路有没有希望	非常适合
长期生产化训练	通常还是走 LoRA 或全参

一句话：QLoRA 是验证工具，不是终点方案。

这个定位很重要 ------它意味着你不必在 QLoRA 和 LoRA 之间纠结"哪个更好"，而是按阶段使用：早期用 QLoRA 快速验证，确定方向后再切到正式方案。

第五部分：三个被忽略的隐性成本

选型时最容易漏掉的三项，最后往往会变成主要成本。

5.1 隐性成本一：评测与回归的工作量

每训一版都要跑评测 ，而评测集的建设与维护往往比训练本身更耗时。

方案切换频繁时，这部分成本会显著上升------因为每次换方案都意味着要重新建立基线。

量化一下 ：如果一次微调训练要 2 小时，而准备与执行一轮完整评测要 4 小时（含人工判读），那么评测成本就是训练成本的两倍 。而这部分在实际排期里经常被算成"零"。

5.2 隐性成本二：部署形态的复杂度

动态加载多份 LoRA 需要框架支持；
量化模型的部署又与普通模型不同。

选型时没有把部署算进去，上线时就要返工。

返工的代价往往很大------因为部署形态会影响训练方式（比如是否合并权重），到上线才发现不合适，可能要重训。

5.3 隐性成本三：数据准备与清洗

无论选哪种方案，数据都是瓶颈。

很多团队以为选个好方案就能省事，结果发现 80% 的时间花在数据上。

这一条的启示是 ：选型讨论的焦点经常放错地方 。与其花两周争论"用 LoRA 还是全参"，不如花两周把数据整理好------后者对最终效果的贡献大得多。

5.4 把这三项纳入考虑后的结论

你会更倾向于选择"改动少、易切换、易评测"的方案------也就是参数高效这一类。

注意这个结论的推导方式 ：它不是从"效果上限"推出来的，而是从"全生命周期成本"推出来的。这才是工程选型应有的视角。

第六部分：一份可执行的选型流程

按顺序走，基本不会错。

6.1 第一步：确认微调是否必要

提示词、few-shot、检索、结构化输出------这些手段先试一轮。

能不用微调就不用。

6.2 第二步：明确改动类型

是改表达、改格式，还是注知识、改行为？

这一步决定了大方向。

参考第三部分的五个目标。

6.3 第三步：看数据规模与质量

只有几百条高质量样本 → 优先小秩 LoRA + 严格验证集；
数据充足 → 才有资格考虑更大改动。

6.4 第四步：选最低成本的可行方案先跑通

先跑 LoRA（或 QLoRA），建立基线与评测流程。

不要一上来就全参。

"先跑通"的另一个作用 是：它让你知道这个任务的难度上限在哪。 如果小秩 LoRA 就能达到目标，那后面的讨论都可以省掉。

6.5 第五步：只有在"LoRA 明显不够"时才升级

而且要有证据说明不够 ------是验证集指标卡住了，不是"感觉还能更好"。

这个区别很重要：

判断依据	性质
验证集指标卡在 70%，目标是 85%	可验证的差距
"感觉还能更好"	主观感受，不是升级理由

6.6 第六步：提前规划部署形态

多任务可切换，还是单任务融合进权重？

这个决定会反过来约束你的训练方式。

举例：如果决定"动态加载多 LoRA"，那么训练时要保持 LoRA 独立（不合并）；如果决定"合并进权重"，那么训练完要多一步合并操作，且一旦合并就无法再调整。

第七部分：效果差距到底有多大

这是最常被争论的一点，需要说清边界。

7.1 在"格式与风格"类任务上

LoRA 与全参微调的差距通常很小，有时 LoRA 甚至更稳（因为改动面小、不易过拟合）。

7.2 在"领域知识注入"上

全参微调明显更强，但代价是：

要有足够多的领域语料；
遗忘风险更大。

不过这个差距，用检索增强往往能更便宜地补上。

这是关键的一句 ：很多人拿"全参在知识注入上更强"作为选全参的理由，但要问一句------你的目标真的需要"模型内部知道"，还是"回答时能取到"？

如果是后者，检索就够了。

7.3 在"复杂指令遵循"上

如果基座能力本身不足，两种方法都难有大提升。

这时候问题不在微调方式，而在基座选择。

这条最容易被忽略 ：团队在微调方案上反复试验，而真正的问题是需要换一个更强的基座。

7.4 所以更准确的表述是什么

LoRA 与全参的差距，主要出现在"需要改变模型内部表示"的任务上；而在"引导输出形态"的任务上，两者接近。

这个表述的价值在于它给出了一个判断依据，而不只是一句"看情况"。

常见误区

误区一："显存够就上全参。"

全参的真正门槛是数据量与评测能力，不是显存。

数据不够时，全参反而更容易训坏。

为什么？ 因为可训练参数多，意味着模型有足够容量去"记住"训练数据里的噪声。小数据集 + 全参微调，过拟合几乎必然发生。

误区二："LoRA 只是省钱的将就方案。"

它的可插拔 与低遗忘风险 ，在很多业务里是更优的工程选择，而不是退而求其次。

"将就"这个词本身就有误导性 ------它暗示有一个更好的方案但因为成本放弃了。但实际上在很多场景下，LoRA 就是更好的那个方案。

误区三："QLoRA 训出来的模型一定比 LoRA 差很多。"

差距通常小于预期，但训练更慢、稳定性略差。

关键看你是否能接受更长的实验周期。

误区四："微调能替代检索。"

知识更新频繁的场景，微调意味着每次更新都要重训。

检索更新成本是分钟级，微调是天级。

这个时间尺度的对比，往往比任何效果对比都更有说服力。

误区五："方案越复杂效果越好。"

复杂方案引入的是风险，不是能力。

比如：QLoRA 引入精度损失与训练不稳定性；全参引入遗忘风险；动态多 LoRA 引入部署复杂度。

在效果接近的前提下，永远选更简单的那个。

误区六："应该先定方案，再准备数据。"

反了。数据质量决定效果上限，方案只是在这个上限内做取舍。

如果你只有 200 条数据，那么不管选什么方案，效果都不会太好；如果你有 5000 条高质量数据，很多方案都能达到目标。

实战问答

Q1：面试问"什么情况下必须全参微调"，怎么答得专业？

A ：指出全参的不可替代场景：需要改变模型的内部表示或能力分布。

典型如：

领域继续预训练（要注入大量新知识）；
大幅改变对齐行为（改变偏好倾向）；
为蒸馏准备教师模型（要重建能力分布）。

再补一句关键判据：

"如果目标能通过引导已有能力达成，就不需要全参。"

这样答既显示了边界感，也显示了工程判断力。

Q2：我们只有一张 24G 的卡，想微调一个中等规模模型，可行吗？

A：可行，走 QLoRA。三点注意：

显存要留给激活值，序列长度别开太长（这是常见的显存爆掉原因）；
训练时间会明显拉长，实验节奏要按天算；
结果要和 LoRA 基线对比一次，确认精度损失可接受。

第三条容易被省略，但它决定了你能不能放心地把这条路走下去。

Q3：为什么我们用 LoRA 训完，模型在新任务上好了，但通用问题答得很差？

A：这是典型的灾难性遗忘（虽然 LoRA 比全参轻）。

三个原因：

原因	缓解方式
训练轮数过多	早停
学习率过高	降低学习率
数据分布太单一	在训练数据里混入 5%~20% 的通用指令数据

并建议把训练轮数压下来。

第三个原因最根本------如果训练数据全是"某一种任务"，模型自然会把资源全部倾斜过去。

Q4：多个业务都想定制，怎么做最省事？

A ：一个基座 + 多份 LoRA，按请求路由。

要点有三：

① 统一的数据格式与评测标准（否则无法横向比较不同业务的 LoRA 效果）；

② 每份 LoRA 独立做回归测试（一个业务的定制可能影响另一个业务的边界情况）；

③ 推理框架要支持多 LoRA 动态加载，否则显存会失控。

第三条是硬性前提 ------如果不支持，就得为每个业务部署一套服务，成本立刻变成数量级的差别。

Q5：QLoRA 和 LoRA 我该用哪个？

A：按阶段选，不用二选一。

阶段	建议
探索期（验证这个方向有没有希望）	QLoRA（门槛低、跑通快）
正式训练（要长期维护）	LoRA（更稳、更快）
显存实在不够	QLoRA，并接受更长周期

核心判断是"你要的是速度还是稳定性"：

探索期要速度 → QLoRA（快速拿到一个结果，判断方向）；
生产期要稳定 → LoRA（可重复、可复现）。

而且要注意 ：如果 QLoRA 训出来的效果就足够好，那就没有理由升级到 LoRA------只在"效果不够 + 显存允许"时才需要切换。

Q6：怎么说服团队"我们不需要全参微调"？

A ：不要争论"哪个效果更好"，用三个问题把讨论拉回决策框架。

问题一：我们要改的是表达还是能力？

如果是表达 → LoRA 够用；
如果是能力 → 那要讨论的是"该不该做这件事"，而不是"用哪种微调"。

问题二：我们的数据有多少？

如果只有几百到几千条 → 全参的数据量根本不够，硬上会训坏。

问题三：上线后谁维护？

多任务切换、模型升级、评测回归------这些工作谁做？ 如果没有明确的人，方案越复杂，风险越大。

把这三个问题摆出来，讨论会从"技术偏好"转向"工程约束"，通常结论就会清晰。

Q7：报告里要写"为什么选 LoRA 不选全参"，怎么写？

A：建议按"目标 → 约束 → 决策 → 验证策略"四段写。

text 复制代码

目标：让模型按公司客服话术风格输出，不涉及新知识注入。
约束：数据约 800 条；需要按客户品牌切换话术（多份定制）；
      上线后由 1 人兼职维护。
决策：LoRA（只挂注意力层，r=16），保持可插拔；
      不合并进基座，以支持按品牌切换。
验证：新任务指标 + 通用能力回归 + 安全拒答回归三者同时达标才发布。
备用方案：若验证集指标卡住超过两轮，再评估加大秩或纳入前馈层。

这样写的价值在于：它记录的是"决策依据"，而不只是"结论"。 半年后有人问"为什么当初这么选"，这份文档能直接回答。

术语表

术语	含义
全参微调	更新模型全部参数的微调方式，能力上限最高、成本也最高
LoRA	冻结基座、只训低秩旁路的参数高效微调方法
QLoRA	在量化基座上执行 LoRA，显著降低显存门槛
Adapter	在层间插入小型可训练模块的定制方法，推理有额外开销
提示微调（Prefix / Prompt Tuning）	只训练一段额外前缀向量，参数最少、能力最受限
灾难性遗忘	微调后模型原有能力下降的现象
目标模块（target modules）	LoRA 作用于哪些层的配置项
参数高效微调（PEFT）	只训练少量参数的一类微调方法的统称

结语

把这篇压缩成三句话：

第一，选微调方案，先问"我要改的是表达还是能力"。

改表达用 LoRA 就够；改知识优先考虑检索；只有在需要改变模型内部表示时，才轮到全参微调。

第二，显存只是入场券，数据和评测能力才决定你能走多远。

真正拉开方案差距的两个维度是数据需求 和多任务切换成本------而这两项恰恰是钱买不到的。

第三，那三项隐性成本（评测、部署、数据）应该在一开始就纳入考虑。 因为它们最后往往会变成主要成本，而它们对方案选择的倾向是一致的：都指向"改动少、易切换、易评测"的方案。

而如果只允许带走一个判断，那就是：先跑 LoRA，用证据决定要不要升级。 因为从经验上看，绝大多数业务需求，LoRA 都能覆盖；而"LoRA 不够"的判断，应该来自验证集指标的卡顿，而不是主观感觉。