LoRA、全参、QLoRA：显存占用结构对比

本文剖析了大模型微调中显存占用的核心问题，指出LoRA、全参和QLoRA方案的本质区别不在于参数规模，而在于"哪些内容必须常驻显存"。显存主要由模型参数、梯度、优化器状态和中间激活四部分构成，不同方案对这四部分的处理方式不同：全参微调保留全部内容，LoRA省去了基础模型的梯度和优化器状态，QLoRA进一步将基础模型参数压缩到4bit。文章特别强调，这些方案都无法减少中间激活的显

L7784848

647人浏览 · 2026-02-08 19:09:14

L7784848 · 2026-02-08 19:09:14 发布

为什么大家都在“省显存”，却越来越说不清显存去哪了

在大模型微调项目里，几乎所有团队都会走到同一个阶段：

显存开始吃紧
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