为什么大家都在“省显存”，却越来越说不清显存去哪了
在大模型微调项目里，几乎所有团队都会走到同一个阶段：
-
显存开始吃紧
-
batch size 一减再减
-
sequence length 不敢动
-
然后开始讨论：
“要不要换 LoRA / QLoRA？”
但非常诡异的一点是：
-
换了方案
-
显存确实降了一点
-
但OOM 还是会来
-
而且很难解释“为什么这次又不行了”
你会发现，讨论显存时，大家常常在说：
-
“这个方案省显存”
-
“那个方案显存占用低”
但很少有人真正说清楚：
**它到底省的是哪一部分显存，
又留下了哪一部分不动。**
而这，正是这篇文章要解决的问题。
先给一个非常重要的结论（一定要先看）
在正式对比之前，我先把这篇文章最重要的一句话写出来：
**LoRA、全参、QLoRA 的显存差异，
不在“模型大小”，
而在“哪些东西必须常驻显存”。**
如果你只是盯着参数量，
那你永远都会算错显存。
第一层：显存到底由哪几部分构成（先统一账本）
在任何一种微调方案里，显存大致可以拆成四块：
1. 模型参数（parameters）
2. 梯度（gradients）
3. 优化器状态（optimizer states）
4. 中间激活（activations）
注意一个关键事实：
**不是所有方案，
都会同时保留这四样东西。**
而 LoRA、全参、QLoRA 的区别，
正是体现在：
哪一块在、哪一块不在、哪一块被压缩。
显存四大构成模块
第二层：全参微调 —— 显存结构最“老实”的方案
我们先从最容易理解、但最吃显存的方案说起。
全参微调，显存里有什么？
在全参微调中：
-
所有模型参数：在
-
所有参数的梯度：在
-
所有优化器状态（Adam 的 m / v）：在
-
所有中间激活：在
也就是说：
四大块，一块不少。
如果用一句话总结：
全参微调的显存结构，是“完整模型世界”。
为什么全参显存这么贵？
因为参数不仅要存一次，还要：
-
再存一份梯度
-
再存两份优化器状态
粗略估算（以 Adam 为例）：
参数：1x
梯度：1x
优化器状态：2x
----------------
≈ 4x 参数规模
还没算 activation。
所以你看到的并不是：
“模型 7B，占 7B 显存”
而是：
“7B 模型，训练时可能占几十 GB 显存”
全参微调显存堆叠结构
第三层：LoRA —— 省掉的是“谁的梯度”
很多人对 LoRA 的第一印象是：
“LoRA 参数少，所以省显存。”
这句话只对了一半。
真正准确的说法是：
**LoRA 省显存，
是因为它不再为 base model 的参数保存梯度和优化器状态。**
LoRA 微调时，显存里有什么？
在 LoRA 中：
-
base model 参数：在（冻结）
-
base model 梯度：不在
-
base model 优化器状态：不在
而新增的 LoRA 参数：
-
参数：在
-
梯度：在
-
优化器状态：在
activation 呢？
完全一样，一点没省。
这是很多人第一次踩坑的地方。
第四层：LoRA 为什么“省得不彻底”
你可能会遇到一个很真实的现象：
-
换 LoRA 后
-
参数显存确实降了
-
但 activation 还是把你顶爆
原因就在这里：
**LoRA 只动了“参数相关显存”，
对 activation 显存，
几乎没有任何帮助。**
而在很多大模型训练场景中：
-
长 sequence
-
大 hidden dim
-
多层 attention
activation 往往才是显存大头。
这也是为什么你会看到：
“LoRA + batch=1 + length=4096 还是 OOM”
这不是 LoRA 失效，
而是你省错了地方。
第五层：QLoRA —— 显存结构第一次“断裂”
QLoRA 的出现，是因为大家终于意识到：
**光省梯度不够，
参数本身也太占地方了。**
QLoRA 的核心思想并不是 LoRA，
而是：
**把 base model 参数，
从 FP16/FP32，
压缩到 4bit。**
QLoRA 下，显存里有什么？
-
base model 参数：在（4bit）
-
base model 梯度：不在
-
base model 优化器状态：不在
-
LoRA 参数 + 梯度 + 优化器状态：在
-
activation：在（通常 FP16）
注意一个非常重要的点：
**QLoRA 并没有减少 activation，
它只是让“常驻参数”变得非常轻。**
第六层：为什么 QLoRA 看起来“显存奇迹”，但仍然会 OOM
很多人第一次用 QLoRA 会有一种错觉：
“显存突然自由了。”
确实，在参数层面：
- base model 显存占用骤降
但很快你会发现：
-
batch 稍微一大
-
sequence 稍微一长
-
OOM 又来了
原因很简单：
activation 从来没被压缩过。
而在 QLoRA 中，还有一个隐藏成本：
-
量化参数需要在计算时反量化
-
有额外的临时 buffer
-
有时还会引入显存碎片
所以 QLoRA 解决的是：
“模型能不能被放进显存”
而不是：
“训练时显存是否稳定”
第七层：三种方案的显存占用“结构对比图景”
我们用一种更直观的方式总结：
全参微调
参数 ██████████
梯度 ██████████
优化器 ██████████
激活 ████████████████
LoRA
参数 ██████████ (冻结)
梯度 ██ (LoRA)
优化器 ██ (LoRA)
激活 ████████████████
QLoRA
参数 ██ (量化)
梯度 ██ (LoRA)
优化器 ██ (LoRA)
激活 ████████████████
你会发现一个非常刺眼的事实：
**三种方案里，
激活永远是那个“最胖的块”。**
第八层：为什么很多“显存问题”，换方案根本解决不了
如果你的 OOM 来源是：
-
activation
-
attention 的 L²
-
长上下文
那你会发现：
**无论是 LoRA 还是 QLoRA，
都只能延缓问题，
无法根治。**
真正能影响 activation 的，是：
-
sequence length
-
batch size
-
attention 结构
-
checkpointing 策略
而不是微调方案本身。
第九层：一个极简代码视角，看三者的差别
# 全参
for p in model.parameters():
p.requires_grad = True
# LoRA
for p in model.parameters():
p.requires_grad = False
for p in lora_parameters:
p.requires_grad = True
# QLoRA
quantize(model.parameters(), bits=4)
for p in model.parameters():
p.requires_grad = False
for p in lora_parameters:
p.requires_grad = True
注意：
**没有任何一行代码，
减少了 activation。**
第十层：什么时候该选哪一种（工程判断）
- 全参微调
* 资源充足
* 行为需整体重塑
* 长期维护
- LoRA
* 想快速试方向
* 关注行为偏移
* 不改模型底座
- QLoRA
* 显存极度受限
* 模型太大
* 但愿意接受计算复杂度增加
但无论选哪一种，你都必须清楚：
**它解决的是哪一类显存问题，
而不是“所有显存问题”。**
很多团队在 LoRA、QLoRA、全参之间反复切换，根本原因不是选错方案，而是对显存结构缺乏整体认知。用LLaMA-Factory online对不同微调方案下的显存占用和训练行为进行对照，更容易看清：真正的瓶颈在参数、梯度，还是激活阶段。
总结：显存不是一个数，而是一种结构
我用一句话，把这篇文章彻底收住：
**LoRA、全参、QLoRA 的区别，
从来不在“谁更省显存”，
而在“谁把显存留给了谁”。**
当你开始：
-
把显存看成结构
-
而不是预算
-
在换方案之前先问一句
> “我到底想省哪一块？”
你才真正开始工程化地解决显存问题。