为什么大家都在“省显存”，却越来越说不清显存去哪了
在大模型微调项目里，几乎所有团队都会走到同一个阶段：
- 显存开始吃紧
- 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 的区别，
从来不在“谁更省显存”，
而在“谁把显存留给了谁”。
当你开始：
- 把显存看成结构
- 而不是预算
在换方案之前先问一句
“我到底想省哪一块？”
你才真正开始工程化地解决显存问题。
