想在自己的显卡上微调 LLM，最怕的就是CUDA out of memory。开源项目canifinetune（can-i-finetune-this）在加载任何权重之前，就能给出一份显存估算报告：它把一次训练步骤的显存需求拆成 8 大内存组件——权重、量化开销、梯度、优化器状态、激活、logits、CUDA 开销、安全余量——逐项算出 GiB 数值，再和你的显卡总量对比，给出yes / marginal / no的可行性结论。

本文带你逐项读懂这份报告，看懂每一个数字背后的含义。

30 秒认识 canifinetune 显存估算报告

安装后无需下载模型权重，一条命令即可出报告：

canifinetune estimate --model Qwen/Qwen2.5-1.5B-Instruct --method qlora --gpu-vram-gb 16 --seq-len 2048

报告分两层看：

1. 规划层：8 大组件逐项列出 +total_estimated_gb（总预估）+feasible判定；
2. 实测层：用canifinetune bench跑一次真实训练后，report/compare命令把「预估 vs 实测」放在一起对比，结果 JSON 存放在 benchmarks/results/。

整体流程如下图所示：输入模型、GPU、训练方法，估算器经过模型元数据 → 内存公式 → VRAM 预算 → 校准，最终输出可行性结论和推荐配置。

报告长什么样：8 大组件 + 1 个总数

以仓库内置的真实基准记录 Qwen2.5-1.5B QLoRA 基准结果（RTX 4080，seq_len 1024，batch 1）为例，报告中的estimated_breakdown如下：

组件的计算逻辑在 src/canifinetune/estimator/memory.py，公式细节在 src/canifinetune/estimator/formulas.py，完整模型说明见官方文档 docs/memory_model.md。

下面逐项拆解。

1️⃣ 权重（static model）

最直观的一项：参数量 × 每个参数的字节数。bf16 每个参数 2 字节，fp32 则是 4 字节。

QLoRA 有个新手最容易误会的细节：只有 Linear 层被量化到 4-bit，embedding、lm_head和归一化层保持全精度，还会被 PEFT 上采样到 fp32。所以 Qwen2.5-1.5B 的实际加载量是1.51 GiB，而不是「1.5B × 0.5 字节 ≈ 0.79 GiB」的朴素算法——fp32 的 embedding 就占了 0.87 GiB。更大的 Qwen2.5-7B 更夸张：仅 fp32 embedding +lm_head就有 4.06 GiB。

2️⃣ 量化开销（quantization overhead）

4-bit 权重本身很小，但量化还要附带「说明书」：每个量化块要存一个缩放因子（absmax），外加一个临时的 bf16 反量化工作区。开销随量化方案不同：

这就是为什么示例报告里这项只有 0.072 GiB——双重量化把「说明书」压到了最小。

3️⃣ 梯度（gradients）

LoRA / QLoRA 下基础模型是冻结的，只有 LoRA 适配器参与训练，所以梯度只针对可训练参数计算，且以 fp32 存储（4 字节/参数）。适配器只有几百万参数，因此这项通常不到 0.05 GiB，几乎可以忽略。

而全量微调（full）时，梯度覆盖所有参数——1.5B 模型就是约 3 GiB，7B 模型则直接翻倍到 28 GiB 级别，这也是全量微调在消费级显卡上几乎不可行的根本原因。

4️⃣ 优化器状态（optimizer）

AdamW 要为每个可训练参数额外存两份状态（一阶、二阶动量估算），原生实现按参数精度存储，非融合 CUDA 实现还会多出一份额外工作区。因此：

• fp32 适配器的 AdamW 约12 字节/参数（8 字节状态 + 4 字节工作区），融合版本 8 字节；
• paged_adamw_8bit按经验值2.5 字节/参数计；
• 纯 SGD 无动量状态，为 0。

因为可训练参数只有几百万，LoRA 场景下这项通常只有几十 MB。

5️⃣ 激活（activations）

前向传播中每层要暂存的中间张量，大小由seq_len × batch × hidden × 层数决定，是随序列长度线性增长的主力项之一。两个关键影响因素：

• 梯度检查点（gradient checkpointing）：只保留每层输入 + 重算一层，大幅压低此项；
• 融合注意力（SDPA / flash-attn）：不显式生成s×s的 softmax 矩阵，省掉一项平方级开销。

6️⃣ logits / loss 链——最容易被低估的一项

这是老式估算器最常漏掉的项，也是大词表模型训练中的隐形大头：

logits ≈ seq_len × batch × vocab × 14 字节

14 字节 = bf16 logits（2）+ fp32 上采样（4）+ log-softmax 工作区（4）+ 反向传播的 fp32 梯度（4）。对词表 151936 的 Qwen2.5，seq 2048 时单项就是~4.1 GiB——比 1.5B 模型的 4-bit 权重还大，而且梯度检查点完全削减不了它。如果你用了 Liger 等融合交叉熵内核，这一项会大幅缩水，预估值就会偏保守（偏高的方向）。

7️⃣ CUDA 开销（cuda overhead）

PyTorch 缓存分配器、CUDA 上下文、cuBLAS/cuDNN 工作区和内存碎片，按显卡总量的8%固定比例估算（16 GiB 卡约 1.28 GiB）。序列超过 8192 时碎片会增多，这个比例可能偏乐观。

8️⃣ 安全余量（safety margin）

再留出显卡总量的5%，防止跑在悬崖边上——桌面合成、浏览器进程在消费级显卡上 routinely 占用 0.5–2 GB。建议对比「预估总数」和「当前可用显存」，而不是总量。

看懂 total、feasible 与 confidence

三项总和之外，报告还会给出判定（来自 memory.py 中的分类逻辑）：

例如 demo 页面中 16 GiB 预算下预估 8.420 GiB，比值 0.53，直接判定YES，并附带confidence: medium的证据等级（注意：这是启发式证据等级，不是统计概率）。

预估 vs 实测：为什么预估总是偏高一点

canifinetune bench跑完真实训练后，报告把「estimated」和「measured」并排放置。看仓库内置的对比表 benchmarks/results/_compare.md：

预估系统性高于实测是有意为之的保守设计：宁可高估也不让你在训练中途撞 OOM。对比时应看进程级peak_reserved_gb（预估值已含安全余量，直接和「总量」比会双重保守）。真实测量记录见 docs/rtx4080_baselines.md。

什么时候预估会偏？

了解边界，才能正确解读报告：

• 用了 Liger 融合 loss：logits 项大幅缩水，预估偏高几个 GiB（安全方向）；
• seq_len ≥ 8192：碎片增长，8% 的固定开销可能不够；
• 注意力实现不同：显式选--attn eager才会计入平方级 softmax 项；
• 显卡被桌面/浏览器占用：用canifinetune doctor查看空闲显存，通过--available-vram-gb传入。

小结：读报告的 3 个习惯

1. 先看 total 和 feasible，再决定要不要深挖单项；
2. 盯住 logits 和 activations——它们随 seq_len 线性增长，是长序列下 OOM 的首要嫌疑人；
3. 结论不是保证：YES 之后仍建议用bench跑一次 3 步的有界实测，把 estimated 与 measured 对上一眼。

更多细节可参考 docs/memory_model.md 的完整内存模型、docs/workflows.md 的规划到实测工作流，以及可运行的示例 examples/qwen_1_5b_qlora_4080/。