全量微调 vs LoRA/QLoRA，到底该怎么选？

如果你手里有一张 24G 显存的显卡，想微调一个 7B 参数的模型，你猜结果是什么？

大概率是屏幕跳出一行红字：CUDA out of memory。

这不是危言耸听。很多刚接触大模型的产品经理和算法工程师，第一次做微调都栽在这一步——不是模型选错了，也不是数据有问题，而是根本没搞清楚"全量微调"和"高效微调（LoRA/QLoRA）"之间隔着一道显存的鸿沟。选错了路径，轻则跑不起来，重则烧了几万块云服务器的钱，最后模型效果还不如人意。

这篇文章不讲虚的，就讲一件事：全量微调和 LoRA/QLoRA，到底该怎么选。我会把原理、显存账、适用场景、决策方法一次性讲清楚，看完你就知道自己下一步该怎么做。

一、先别急着选方法，你要先想清楚一件事

在讨论"选哪种微调方式"之前，有一个更底层的问题必须先想明白：你为什么要微调这个模型？

微调这件事，本质上是在两头拉扯：一头是"泛化能力"，一头是"过拟合"。

你给模型喂的数据越多、训练越久，模型在你的数据上表现得越像"背答案"——问它训练集里见过的问题，回答得又快又准；可一旦问题稍微变个说法，它就露馅了。这就是过拟合：模型不是学会了"怎么思考"，而是记住了"标准答案长什么样"。

反过来，如果训练不够、数据不够典型，模型学不到你想要的能力，泛化能力是有了，但根本没解决你的问题，等于白训。

所以在选全量微调还是 LoRA/QLoRA 之前，先把这几件事想清楚：

你要解决的问题，模型现在的表现差在哪？是完全不懂这个领域，还是懂但表达方式不对？

你手上有多少高质量数据？几百条，还是几万条？

你的目标是"效果拉满，不计成本"，还是"能跑起来、效果过得去、资源有限"？

这几个问题的答案，直接决定了你该往哪条路走。

二、全量微调：效果的天花板，也是显存的无底洞

全量微调，顾名思义，就是把模型的每一个参数都拿出来重新训练一遍。这是最"笨"也最彻底的方法——不留任何参数在原地不动，全部跟着你的数据重新调整。

它的优势很直接：理论效果上限最高。因为模型的每一层、每一个权重都参与了学习，如果数据质量够好、训练策略得当，全量微调能把模型的能力调整到最贴合你的场景。

但代价也同样直接：显存需求高到离谱。

这里要补一个基础知识：模型参数是用什么精度存储的，直接决定了它占多少显存。常见的精度类型和对应的字节数是这样的：

fp32（单精度浮点）：每个参数占 4 字节

fp16（半精度浮点）：每个参数占 2 字节

int8（8位整数）：每个参数占 1 字节

int4（4位整数）：每个参数占 0.5 字节

以一个 7B（70 亿参数）规模的模型举例，用 fp16 精度做推理，大概需要 16G 左右显存；但如果要做全量微调，除了要加载模型本身，还要为每个参数保留梯度和优化器状态（如果用 AdamW 优化器，通常还要维护一阶矩和二阶矩，这部分往往是 32 位存储），显存需求会直接翻几倍——很多场景下，一个 7B 模型做全量微调，实际显存需求要奔着 48G 去了。

这意味着什么？意味着如果你手里只有一张消费级显卡（比如 24G 显存的 4090），全量微调一个 7B 模型基本是跑不动的，你需要多卡并行，或者上云端的专业训练卡。这笔硬件成本，很多团队是承担不起的。

什么情况下值得选全量微调？

你的任务和预训练模型的原始能力差异很大，比如要让模型掌握一套完全陌生的专业术语体系和推理逻辑，小修小补不够用；

你有充足的高质量数据，且数据量级不小（不是几百条能糊弄过去的）；

你有足够的算力预算，不差钱，也不差卡；

你对效果的要求是"必须做到最好"，而不是"能用就行"。

老实说，符合这几条的团队并不多。大部分公司做微调，既没有那么多标注好的高质量数据，也没有那么厚的显卡预算。这也是为什么 LoRA 和 QLoRA 会火起来的原因。

三、高效微调两兄弟：LoRA 和 QLoRA

LoRA：不动大模型，只加一个"外挂"

LoRA（Low-Rank Adaptation，低秩自适应）的核心思路和全量微调完全不同：它不去动原模型的参数，而是冻结原模型，在旁边加一个体积很小的"外挂"模块，只训练这个外挂。

打个比方，全量微调像是把一栋已经装修好的房子彻底推倒重建；LoRA 则是不动房子的主体结构，只在关键房间里加装几个可拆卸的小柜子——柜子虽然小，但装的都是你现在最需要的东西，房子该有的承重结构、水电线路一点没变。

具体到技术上，LoRA 会在模型的关键层（比如注意力机制里的 Query、Value 矩阵）旁边插入两个低秩矩阵，训练的时候只更新这两个小矩阵的参数，原模型的参数全程冻结不动。

这么做的好处是实打实的：

训练参数量极小。用 LoRA 微调，需要训练的参数往往只有原模型整体参数的万分之一左右，这意味着需要保存的梯度和优化器状态也大幅减少；

显存占用明显下降。相比全量微调，GPU 显存使用量可以减少约三分之二；

不增加推理耗时。训练完之后，LoRA 的低秩矩阵可以直接合并回原模型权重里，推理时和原模型没有额外的计算开销。

这也是为什么 LoRA 现在是大多数中小团队做微调的默认选择——不需要豪华的硬件配置，一张消费级显卡往往就能跑起来。

QLoRA：把模型本身也"瘦身"，进一步压榨显存

如果说 LoRA 已经把训练参数量降到了很低，那 QLoRA 解决的是另一个问题：原模型本身的权重，占的显存还是很大。

QLoRA 的思路是"量化 + LoRA"的组合拳：先把冻结的原模型权重压缩到 4-bit 精度（用的是一种专门针对神经网络权重分布优化的量化方式，叫 NF4，即 4-bit NormalFloat），再加上"双重量化"进一步压缩存储量化参数本身占的空间，最后配合"分页优化器"，在显存快撑不住的时候把一部分数据临时挪到 CPU 内存里缓冲，避免训练过程中显存峰值爆掉。

简单说，QLoRA 做的事情是：LoRA 已经让你只训练一小部分参数了，QLoRA 再把这一小部分参数之外、原模型那一大块"不训练但占显存"的权重也给压缩了。

效果有多明显？公开的技术资料显示，QLoRA 可以把微调一个 65B 参数规模模型的显存需求，从原本超过 780G，降低到 48G 以内——这意味着原本需要好几张专业训练卡才能跑的任务，QLoRA 之后单张显卡就有可能带得动。放到更常见的 7B、13B 模型上，QLoRA 微调所需显存基本可以压到 8～10G 左右，一张普通的消费级显卡就能应付。

当然，天下没有免费的午餐。量化会带来一定的精度损失，也有实测反馈显示，QLoRA 虽然能进一步节省显存（相比 LoRA 大概能再省下三成左右），但由于训练过程中需要频繁地对量化权重做量化和反量化操作，训练时间会比单纯用 LoRA 更长。所以 QLoRA 是拿"训练速度"换"显存空间"，这笔账要自己算清楚。

一句话总结两者的关系

QLoRA 不是脱离 LoRA 的另一套新方法，而是 LoRA 的"显存增强版"——LoRA 解决的是"要训练的参数太多"，QLoRA 在这基础上，又解决了"不训练但占地方的原模型太大"。

四、显存账到底怎么算？一张对照表看明白

回到最开始那张笔记里的量化对照表，这里把它还原成一个更直观的版本，帮你在选型之前先估算一下自己的硬件能不能扛得住：

这张表的意义在于：在你决定要不要做全量微调之前，先拿自己手上的显卡容量对照一下这张表，很多时候答案自己就出来了。

如果你手里是消费级显卡（16G～24G 显存），全量微调 7B 模型大概率是跑不动的，直接跳过，走 LoRA 或 QLoRA；如果你有企业级多卡集群，那全量微调才有讨论的空间。

五、决策不是拍脑袋，看这三个维度

选全量微调还是 LoRA/QLoRA，不需要靠感觉，把下面三个维度过一遍，答案基本就清晰了。

第一个维度：你的硬件条件。

这是最硬的约束，前面那张对照表已经说得很清楚了。手里的显卡容量决定了你有没有资格讨论全量微调。没有对应的硬件，讨论其他维度都是空谈。

第二个维度：你的数据量和数据质量。

全量微调需要更大量、更多样的数据来支撑模型参数的整体调整，数据量不够，全量微调很容易学"歪"，过拟合到一小撮样本上。而 LoRA/QLoRA 因为只调整一小部分参数，对数据量的要求相对没那么苛刻，哪怕是几百到几千条高质量数据，也能训练出可用的效果。

第三个维度：你要的效果和能接受的成本。

如果你的任务只是让模型"学会某种说话方式""记住某个领域的术语和规则"，这种偏"局部调整"性质的任务，LoRA 完全够用，性价比最高。如果你的任务是要模型具备一种全新的、复杂的推理能力，且和原模型的能力差距很大，那可能只有全量微调才能达到你要的效果——但前提是你得先确认自己有没有对应的硬件和数据支撑。

三个维度过一遍之后，给一个简单的判断顺序：

先看硬件够不够全量微调 → 不够，直接上 LoRA/QLoRA；够，再看数据量和数据质量是否支撑全量微调 → 不够，依然建议先用 LoRA/QLoRA 探路；都够，且任务确实需要模型脱胎换骨式的能力调整，这时候全量微调才是合理选择。

绝大多数中小团队和个人开发者，走到这个判断顺序的第一步或第二步就已经有答案了：用 LoRA，显存紧张就上 QLoRA。这不是因为全量微调不好，而是因为全量微调对硬件和数据的门槛，把大多数人挡在了门外。

六、选完方法之后，微调这件事怎么落地

选定方向之后，实际动手微调，基本会走完这几步，缺一不可：

1. 模型准备

先确定你要在哪个基座模型上做微调，同时结合前面讲的显存对照表，确认自己的硬件能不能带得动这个模型规模和你选择的微调方式。这一步错了，后面全白搭。

2. 数据准备

数据是微调的燃料。实操中一个简单可行的做法是：打开一个在线表格工具，新建一张表，A 列放用户提问（user），B 列放期望的模型回答（assistant），C 列可以加标注标签，方便后续分类管理——就像整理日常对话记录一样，把你希望模型学会的"问答范式"一条条录进去。

需要注意的是，导出数据的时候，一定要把表格里的空白行、空白单元格清理干净，否则会在训练数据里混入脏数据，直接影响训练效果。导出之后，把文件重命名，后缀改成 .jsonl 格式，这是大多数微调框架能直接读取的标准格式。

3. 训练配置

这一步要设定好训练相关的参数，其中最关键的两个是"迭代轮次"（模型把数据集完整学习几遍）和"学习率"（模型每次调整参数的步子迈多大）。参数设置没有放之四海而皆准的标准答案，需要结合你的数据量和模型规模去调整，一般思路是：轮次不宜过多，避免过拟合；学习率不宜过大，避免训练不稳定。

4. 启动微调

配置好参数之后，正式启动训练。这一步如果前面选对了方法（LoRA/QLoRA）、算清楚了显存账，理论上不应该再遇到显存溢出的问题；如果还是报错，大概率是模型规模和精度选择超出了硬件承受范围，需要回头重新核算。

5. 验证评估，不行就从头来

训练完成不代表工作结束，必须做验证评估，通常会看训练过程中的 loss（损失）值——损失值越低、越接近收敛，说明模型对训练数据的拟合程度越高，但也要注意这不等于效果一定好，还要拿一批模型没见过的数据实测效果，看它是不是真的学会了"举一反三"，而不是死记硬背。

如果验证发现效果不理想，不要恋战，直接回到数据准备或训练配置那一步重新来过。这是微调工作的常态，不是失败——数据没喂对、参数没调好，是最常见的两个原因。

6. 部署与推理

验证通过之后，就是把训练好的模型部署起来，对外提供服务。这一步需要配置好调用地址（baseurl）、密钥（apikey）、模型名称（model name）这几项基本信息，确保后续能通过接口正常调用这个微调后的模型，并且要实际测试一下交互体验，确认线上效果和验证阶段看到的一致。

七、写给正在纠结的你：一份可以直接照做的方法论

看到这里，如果你还是拿不定主意，按下面这个流程走一遍，基本能得出适合你的答案：

第一步，摸清自己的硬件底牌。不管你想不想做全量微调，先老老实实拿出显卡的显存参数，对照文中的精度-显存对照表，算清楚全量微调这个模型需要多少显存、你现在有多少。这一步不需要任何主观判断，是硬指标。

第二步，盘点手上的数据。数据量在几百到几千条这个区间，质量参差不齐，那就不要考虑全量微调，直接从 LoRA 开始；如果你有上万条甚至更多经过严格清洗和标注的数据，且硬件条件也够，全量微调才值得认真评估。

第三步，明确任务性质。问自己一句话："我是希望模型在原有能力基础上学会一种新的表达方式/记住一套新的规则，还是希望模型具备一种它原本完全不具备的复杂能力？"前者选 LoRA，后者才有必要考虑全量微调。

第四步，如果显存依然紧张，直接上 QLoRA。不用犹豫，QLoRA 在绝大多数中小规模任务上已经能做到和全量微调、LoRA 相差不大的效果，同时把硬件门槛压到了消费级显卡也能承受的范围，这笔账怎么算都划算。

第五步，按六步流程走完整个微调闭环，验证不通过就退回上一步重来，不要跳步。模型准备、数据准备、训练配置、启动微调、验证评估、部署推理，每一步都是为下一步兜底的，跳过任何一步都容易在后面付出更大的返工成本。

最后说一句大实话：模型微调不是一次就能调好的事情，第一次跑出来的效果不理想，是绝大多数人的常态，不是你的方法有问题。真正拉开差距的，不是谁第一次就调对了参数，而是谁能把"验证不行就从头来"这件事，坚持做到数据和参数都调对为止。

选对路径只是第一步，剩下的，靠的是把这套流程扎扎实实跑几遍。