LLaMA-7B全量微调要40GB以上，LoRA降到16GB、QLoRA只要8–10GB，同一张卡换一种微调方法就从“不可能”变成“可以”，硬件门槛到底该按“任务本身”算还是按“你选的技术路线”算？

一、问题的提出：三个数字背后的认知陷阱

“7B 模型全量微调要 40GB 以上，LoRA 16GB，QLoRA 8–10GB”——这组数字在中文技术社区被反复引用，几乎成了一条经验定律。它之所以流行，是因为它回答了一个非常具体的焦虑：我手上只有一张 24GB 的 4090，或者一张 16GB 的 4080，甚至一张 12GB 的 3060，我到底能不能微调一个 7B 模型？

但这组数字本身是高度条件化的。以全量微调为例，40GB 这个量级的来源，通常对应的是“混合精度 + AdamW + 单卡 + 较短序列 + 较小批次”的组合。如果把序列长度从 512 拉到 2048，激活值会线性甚至更快地膨胀；如果改用 8bit 优化器（如 bitsandbytes 的 8-bit Adam），优化器状态又能砍掉一大截。换句话说，40GB 不是全量微调的物理下限，而是某一组工程配置下的经验值。同理，LoRA 的 16GB 与 QLoRA 的 8–10GB，也各自绑定着序列长度、批次大小、是否开启梯度检查点、是否使用 FlashAttention 等一长串前提。

这就引出了本文要处理的核心问题：当我们说“硬件门槛”时，我们说的到底是什么？一种流行的说法是“门槛应该按任务本身算”——任务需要多长的上下文、多大的数据、多高的质量，就决定了需要多少显存，技术路线只是在这个约束下做选择。另一种说法是“门槛按技术路线算”——你选了 QLoRA，8GB 就能跑，这就是你的门槛。本文认为这两种说法都不完整，它们各自截取了二维可行域的一个投影。

本文的分析主线：微调显存是一个可分解、可复算的账本，硬件门槛是这个账本在“任务约束 × 技术路线”二维平面上的等值线。任何单一数字，只有标注了它所在的坐标，才有意义。

为了让这条主线落地，本文会做三件事。第一，把显存拆成权重、梯度、优化器状态、激活值四项，给出每一项的估算公式，并说明哪些项随参数量线性增长、哪些项随序列长度和批次增长。第二，逐一分析 LoRA 与 QLoRA 在这四项上分别做了什么减法，减法的数学依据是什么，边界条件在哪里。第三，给出一张从 8GB 到 80GB 的配置决策表，让读者可以按自己的卡和任务反查可行配置，而不是记住三个孤立的数字。

需要提前说明的是，本文引用的显存数值，除特别标注为“实测”外，均为基于公开公式与公开配置的估算值或整合值，读者应以自己环境下的 nvidia-smi 与 PyTorch 显存快照为准。工程实践中，框架开销、CUDA 上下文、碎片化都会带来 1–2GB 的浮动，这一点在后文的决策表中会单独留出余量。

二、显存四本账：把“40GB”拆到每一项

2.1 四项显存的定义与公式

训练时的显存占用，可以近似分解为四个部分。设模型参数量为 P（LLaMA-7B 约 6.74B），每个参数的字节数为 b，则：

权重显存      M_w  = P × b_w
梯度显存      M_g  = P × b_g          （仅对可训练参数）
优化器状态    M_o  = P × b_o × k      （k 为状态份数，AdamW 为 2）
激活值显存    M_a  ≈ f(L, B, H, N_layer, ckpt)

总显存 ≈ M_w + M_g + M_o + M_a + M_ctx + M_frag
其中 M_ctx 为 CUDA 上下文与框架开销，M_frag 为碎片余量

这个分解看似朴素，但它解释了为什么不同技术路线之间的差距可以如此悬殊。全量微调时，四项全部按 P 计；LoRA 只让梯度与优化器状态按“可训练参数量”计，而可训练参数量可能只有 P 的千分之几；QLoRA 则进一步把权重项从 16bit 压到 4bit。三项减法叠加，才有了从 40GB 到 8GB 的跨度。

2.2 全量微调的 40GB 是怎么来的

以 LLaMA-7B 的 6.74B 参数、混合精度（BF16 权重与激活、FP32 主权重）为例，逐项估算：

把上表相加，静态部分（权重 + 主权重 + 梯度 + 优化器状态）就已经超过 108GB。这显然与“40GB 以上”的说法对不上。差异来自两个工程实践：其一，混合精度训练中，BF16 权重与 FP32 主权重往往共享存储或采用分片策略，实际常按“每参数 16–18 字节”粗估；其二，更关键的是，社区所说的“40GB 能跑”，通常指的是配合 ZeRO 系列优化、CPU offload 或 8bit 优化器之后的可行配置，而不是朴素单卡全量微调。

本文评述：这里暴露了一个常见的传播失真——一个“在特定优化组合下勉强可行”的配置，被简化成了“全量微调需要 40GB”。如果按每参数 16 字节（BF16 权重 2 + 梯度 2 + FP32 主权重 4 + AdamW 两状态 8）粗估，6.74B 参数约需 108GB；即便把优化器状态换成 8bit，也只能压到 60GB 量级。真正把数字拉到 40GB 附近的，是 ZeRO-3 的参数分片——它把静态状态分散到多卡，单卡账面上的数字自然下降。所以更准确的说法是：单卡朴素全量微调 7B 模型，显存需求在百 GB 量级；40GB 是“单卡 + 若干优化技巧”的工程折中值。这个澄清很重要，因为它决定了后文对比的基准线是否公平。

三、LoRA：在优化器状态上做减法的数学依据

3.1 低秩假设：LoRA 到底假设了什么

LoRA（Low-Rank Adaptation）的核心假设是：模型在适配下游任务时，权重更新量 ΔW 具有低秩结构。具体做法是把 ΔW 分解为两个小矩阵的乘积 ΔW = BA，其中 B ∈ R^{d×r}，A ∈ R^{r×k}，秩 r 远小于 d 和 k。训练时冻结原始权重 W，只训练 A 和 B。

这个假设不是凭空来的。Hu 等人 2021 年的原始论文（arXiv:2106.09685）在 GPT-3 175B 上观察到，随机投影到低维子空间后的更新，性能与全秩更新接近，这为低秩假设提供了经验支持。但本文要强调的是：低秩假设是一种归纳偏置，它成立与否取决于任务。对于“风格迁移”“指令跟随格式对齐”这类任务，低秩往往足够；对于需要模型学习全新知识体系或复杂推理链的任务，低秩可能成为瓶颈。这一点在第七节会展开。

3.2 显存减法发生在哪一项

LoRA 的显存收益，主要不在权重项，而在梯度与优化器状态项。设可训练参数量为 P_train，则：

M_g(LoRA) = P_train × b_g
M_o(LoRA) = P_train × b_o × 2
M_w(LoRA) = P × b_w   （冻结权重仍需常驻）

以 r=8、仅作用于 q_proj 与 v_proj 为例：
P_train ≈ 2 × 4096 × 8 × 32 层 × 2 个投影 ≈ 4.2M
占 6.74B 的约 0.06%

按这个比例，梯度与优化器状态从百 GB 量级降到几十 MB 量级。冻结权重仍以 BF16 常驻，约 13.5GB，加上激活值与框架开销，16GB 卡上跑 LoRA 是完全合理的。这就是“LoRA 降到 16GB”的账本来源。

但这里有一个容易被忽略的细节：LoRA 的显存收益与 r 的取值、作用模块的选择强相关。如果对所有线性层都加 LoRA，且 r 取 64 甚至 128，P_train 会显著上升。以 r=64、作用于全部 7 个线性投影为例，可训练参数可达数亿量级，优化器状态随之回升。所以“LoRA 省显存”不是一个无条件命题，它同样有配置边界。

笔者认为，LoRA 真正的工程价值，与其说是“省显存”，不如说是“把显存预算从优化器状态转移到了激活值”。因为一旦优化器状态不再是瓶颈，序列长度和批次大小就成了新的可调杠杆，而这恰恰是很多下游任务（长文档理解、多轮对话）真正需要的。这个视角的转换，比记住“16GB”这个数字更有用。

3.3 一个可复算的 LoRA 配置示例

以 LLaMA-7B、r=16、作用于 q/k/v/o 四个投影、序列长度 1024、批次 4、开启梯度检查点为例，估算如下（模拟整合值，用于说明量级）：

合计约 18–22GB。这意味着在 24GB 卡上跑这个配置是可行的，但在 16GB 卡上需要把批次降到 1–2、序列长度降到 512，或者进一步减少 LoRA 作用模块。这就是为什么“LoRA 16GB”这个说法在社区里既对又不对——它对应的是较保守的配置，而不是任意配置。

四、QLoRA：把冻结权重压到 4bit 的工程细节

4.1 三项技术叠加：4bit NormalFloat、双重量化、分页优化器

QLoRA（Dettmers 等，2023，arXiv:2305.14314）在 LoRA 的基础上又做了三件事，把 7B 模型的微调门槛压到 8–10GB 量级。

第一是 4bit NormalFloat（NF4）量化。NF4 是一种信息论上对正态分布权重最优的量化数据类型，它假设预训练权重近似服从零均值正态分布，从而在 4bit 的有限码点上分配更多精度给高密度区间。这一步把冻结权重的存储从 16bit 压到约 4bit，7B 模型的权重占用从 13.5GB 降到约 3.5GB。

第二是双重量化（double quantization）。量化本身需要存储缩放因子（scale），这些因子如果按 FP32 存，会带来额外开销。双重量化对缩放因子再做一次 8bit 量化，进一步省出约 0.4–0.5GB（对 7B 模型而言）。

第三是分页优化器（paged optimizer）。当显存出现瞬时峰值时，分页优化器借助 NVIDIA 的统一内存机制，把优化器状态临时换出到 CPU 内存，避免 OOM。这一步不减少平均显存，但显著降低了峰值显存，对“差一点就能跑”的场景很关键。

4.2 反量化开销：QLoRA 不是免费的午餐

4bit 权重在参与矩阵乘法前需要反量化回 BF16，这一步带来额外的计算开销。Dettmers 等人的报告指出，QLoRA 的训练速度相比标准 LoRA 有明显下降，具体幅度取决于硬件与实现。本文评述：这个速度代价在决策时经常被忽略。显存门槛降低的代价是时间门槛上升，如果任务是“小数据、快速迭代”，QLoRA 的慢可能抵消它带来的显存便利；如果任务是“大数据、一次性长训练”，慢一点换取“能在现有卡上跑起来”则是划算的。所以 QLoRA 的适用性同样依赖任务画像，而不是普适最优。

另一个常被忽略的细节是：QLoRA 的 4bit 量化只作用于冻结的基座权重，LoRA 适配器本身仍以 BF16 训练。这意味着适配器的精度不受量化影响，但基座权重的量化误差会通过前向传播进入梯度。Dettmers 等人的实验表明，在多数指令跟随任务上，这种误差对最终质量的影响可控，但在需要精细数值推理的任务上，量化误差可能被放大。这一点在第七节会结合质量对比讨论。

4.3 8–10GB 的账本复算

合计约 6.5–9GB，与“8–10GB”的说法吻合。但同样要注意，这个账本对应的是短序列、小批次的保守配置。如果把序列长度拉到 2048、批次拉到 4，激活值会迅速吃掉余量，8GB 卡就不够了。所以 QLoRA 的“8GB 门槛”也有它的坐标。

拓展阅读：Hugging Face PEFT 官方文档对 LoRA 与 QLoRA 的配置参数有详细说明，可作为动手实践的起点（huggingface.co/docs/peft）；bitsandbytes 项目的 GitHub 仓库则记录了 4bit 量化与分页优化器的实现细节（github.com/TimDettmers/bitsandbytes）。

五、激活值：被低估的显存黑洞与序列长度杠杆

5.1 激活值为什么随序列长度超线性增长

在前四节的账本里，激活值往往是变动最大、最难精确估算的一项。它的大小与批次 B、序列长度 L、隐藏维度 H、层数 N 相关，且注意力机制中的注意力矩阵本身是 O(L²) 的。虽然 FlashAttention 系列工作通过分块计算避免了显式存储完整的 L×L 注意力矩阵，但中间激活（如 QKV 投影输出、MLP 中间层）仍随 B×L×H 线性增长。

这意味着，当序列长度从 512 翻到 2048 时，激活值大致翻四倍（在未做特殊优化的情况下）。对于一个已经把优化器状态压到极致的 LoRA 配置，激活值很可能成为新的主导项。这就是为什么很多工程师发现：明明按公式算 LoRA 只要 14GB，实际跑 2048 序列时 24GB 卡还是 OOM。

5.2 梯度检查点：用时间换空间的经典权衡

梯度检查点（gradient checkpointing）的思路是：前向传播时只保存部分中间激活，反向传播时重新计算其余部分。它把激活值显存从 O(N) 降到 O(√N) 量级，代价是额外的计算量（通常增加 20%–30% 的前向计算）。本文评述：这是一个典型的“时间换空间”权衡，在显存受限时几乎总是值得开启，但它不是免费的——如果你的瓶颈是训练吞吐而非显存，开启它反而拖慢整体进度。所以是否开启，取决于你当前是“显存 bound”还是“算力 bound”。

与梯度检查点配合的还有 FlashAttention。FlashAttention-2（Dao，2023，arXiv:2307.08691）通过改进工作划分与并行策略，在保持 IO 感知优点的同时提升了吞吐。它的显存收益主要体现在避免物化完整注意力矩阵，对长序列场景尤其明显。工程上，现代训练框架（如 Hugging Face Transformers 配合 FlashAttention 实现）通常可以一行配置开启。

5.3 一个长序列场景的反例

假设任务是对 8K token 的法律合同做结构化抽取。此时序列长度 8192，批次只能压到 1。即便用 QLoRA，权重 3.5GB + LoRA 状态 0.5GB，激活值在开启梯度检查点与 FlashAttention 后仍可能达到 6–10GB，加上框架开销，总显存在 12–15GB。这意味着 8GB 卡在这个任务上依然不够，而 16GB 卡勉强可行。这个反例说明：任务的长上下文需求，会直接改写技术路线的显存账本。脱离序列长度谈“QLoRA 只要 8GB”，在长文本任务上会误导决策。

六、从 8GB 到 80GB：一张可执行的配置决策表

把前五节的账本汇总，可以得到一张按显存容量反查配置的决策表。表中数值为估算整合值，实际部署需预留 1–2GB 余量，并以实测为准。

这张表的使用方式是“双向”的：如果你已经有一张卡，按行查可行配置；如果你有一个明确的任务（比如 L=4096），按列反查需要哪一档显存。它把“门槛”从一个点扩展成了一条线，这条线就是本文所说的二维可行域的边界。

操作路径上，建议按以下步骤推进：第一步，用 torch.cuda.memory_summary() 在最小配置下测一次基线，记录权重、激活、优化器各自的峰值；第二步，固定技术路线，逐项调整序列长度与批次，观察哪一项先撞墙；第三步，如果撞墙的是激活值，优先开梯度检查点与 FlashAttention；如果撞墙的是优化器状态，考虑换 8bit 优化器或降 r；第四步，只有在上述手段用尽后，才考虑换技术路线（LoRA→QLoRA）或换硬件。这个顺序能避免“一遇 OOM 就换路线”的盲目性。

七、质量—显存权衡：LoRA 到底损失了什么

讨论显存门槛，不能回避一个前置问题：省下来的显存，是不是用质量换的？这个问题没有统一答案，但有可验证的边界。

从公开研究看，LoRA 在指令微调、风格对齐、领域术语适配等任务上，与全量微调的差距通常较小；但在需要模型习得新事实、新推理模式的任务上，差距可能显现。QLoRA 在此之上又叠加了 4bit 量化误差，Dettmers 等人的实验显示，在多数基准上 QLoRA 能接近 16bit LoRA 的表现，但这一结论依赖于基座模型权重的分布假设（近似正态），对分布异常的权重，NF4 的优势会减弱。

本文评述：更值得工程团队关注的，不是“LoRA 比全量差几个点”这种静态比较，而是“在你的任务上，质量对可训练参数量的敏感度曲线”。这条曲线可以通过小规模消融实验快速测出：固定数据与评估集，把 r 从 4 扫到 64，观察指标变化。如果曲线在 r=16 后就趋于平坦，说明任务对低秩假设友好，省显存的代价很小；如果曲线持续上升，说明任务需要更高秩，此时 QLoRA 的 8GB 门槛可能以质量损失为代价，需要重新权衡。这个实验的成本远低于盲目上大卡，是决策前值得做的一步。

另一个常被忽略的维度是数据质量与显存的关系。在显存受限时，工程师倾向于减小批次，而小批次会带来梯度噪声增大、训练不稳定。此时用梯度累积来模拟大批次是常见做法，但它不改变显存峰值，只改变有效批次。这意味着“小卡跑大任务”在优化层面仍有腾挪空间，不应过早归因于硬件不足。

八、结论：门槛是二维可行域，不是单一数字

回到开篇的问题：硬件门槛到底该按“任务本身”算，还是按“你选的技术路线”算？本文的结论是，这个二选一的提问方式本身就有问题。门槛是一个二维可行域：横轴是任务约束（序列长度、批次、精度、可接受质量损失），纵轴是技术路线（全量、LoRA、QLoRA 及其配置）。任何一个具体数字，都是这个平面上的一条等值线，脱离坐标谈数字，就会重蹈“40GB 其实是优化后的折中值”那样的传播失真。

对从业者而言，更实用的心智模型是“显存账本 + 决策顺序”：先算账，知道四项各占多少；再定位，知道当前撞的是哪一项；最后才谈换路线或换卡。这个顺序能把“一遇 OOM 就换 QLoRA”的反射式决策，替换成有依据的工程判断。对研究者而言，值得继续追问的是：低秩假设在什么任务分布下会失效？4bit 量化的误差在什么权重分布下会被放大？这些问题的答案，会直接改写未来那张决策表的边界。

最后需要强调，本文所有显存数值均为基于公开公式与公开配置的估算或整合值，用于说明量级与决策逻辑，不构成对任何具体环境的性能承诺。真实部署请以实测为准。