1. 5.9GB 的模型文件，为什么只吃掉 2.7GB 显存
先把结论摆在前面：模型文件大小和显存占用从来就不是一回事。我这次跑的是一个 5.9GB 的 GGUF 文件，加载完之后nvidia-smi显示显存占用稳定在 2.7GB 上下，中间差了整整 3.2GB。这个差值不是玄学，也不是工具在偷懒，而是 llama.cpp 这套加载机制在背后做了几件很具体的事。
很多人第一次接触 GGUF 的时候，会下意识把文件体积等同于显存需求，然后拿着一张 8GB 的卡去算“我能不能跑 7B”“我能不能跑 14B”。这个算法在早期全量加载的框架里勉强成立，但在 llama.cpp 的体系下会严重高估。原因在于 GGUF 文件里存的东西，和真正需要常驻显存的东西，是两个集合。
GGUF 文件里大致包含这几类数据：模型权重张量、量化缩放因子（scale 和 zero point）、词表、各种元数据（架构参数、超参、tokenizer 配置）、以及对齐填充。其中真正需要进显存的，只有参与矩阵乘法的权重张量和对应的量化参数。词表、元数据、部分配置项在加载后留在内存里，根本不占显存。光是这一块，就能解释掉一部分差值。
更关键的是量化本身。我这次用的是 Q4_K_M 这个量化等级，4 位量化加上 K-quant 的分块策略。一个原本 FP16 的 7B 模型大约 14GB，量化到 4 位理论上压到 3.5GB 左右，实际文件 5.9GB 是因为里面还混了一些高精度层（比如 attention 的某些投影、embedding 层往往保留更高位宽），以及量化块的对齐开销。但显存里实际驻留的，是解包后按块组织的权重，加上 CUDA 侧的 workspace、KV cache、计算图缓冲区。这几项加起来才是 2.7GB 的真实构成。
所以“5.9GB 文件只占 2.7GB 显存”这件事，本质上是三件事叠加的结果：文件里有一部分数据压根不进显存、量化让权重体积进一步压缩、以及 llama.cpp 的按需加载和内存映射策略。下面我把这三件事拆开讲清楚，再给出可复现的验证方法。
2. GGUF 文件里到底装了什么，哪些进显存哪些不进
2.1 权重张量：唯一必须常驻显存的部分
GGUF 的核心是张量数据。一个 Transformer 模型的权重可以粗分成几类：token embedding、attention 的 Q/K/V/O 投影、FFN 的 gate/up/down 投影、最后的 output 投影（很多模型和 embedding 共享）、以及各种 norm 层的权重。
在 llama.cpp 里，norm 层这种小张量通常留在 CPU 侧或者用很小的 buffer 处理，真正吃显存的是那些大矩阵。以 7B 模型为例，attention 和 FFN 的投影矩阵占了绝大部分参数量。这些张量在加载时会被分配到 GPU 的显存里，但分配的大小取决于量化后的实际字节数，而不是原始 FP16 的大小。
这里有个容易忽略的点：llama.cpp 支持把部分层放在 GPU、部分层放在 CPU，也就是-ngl（n_gpu_layers）参数控制的层卸载。如果你只卸载了 20 层，那显存里就只有这 20 层的权重，剩下的在内存里由 CPU 计算。我这次是全部层都卸载到 GPU，所以 2.7GB 是完整模型的显存占用。
2.2 量化缩放因子：跟着权重一起进显存，但体积很小
Q4_K_M 这类 K-quant 量化不是简单地把每个权重砍成 4 位，而是分块处理。每个块（通常是 32 或 256 个权重）有一组缩放因子和最小值，用来把 4 位整数还原成近似浮点。这些因子本身是 FP16 或 FP32，跟着权重块一起存。
算一下比例：如果块大小是 32，每个块存一个 FP16 的 scale 和一个 FP16 的 min，那就是 4 字节开销对应 32 个 4 位权重（16 字节），开销占比大约 25%。这听起来不小，但相比 FP16 到 4 位的 4 倍压缩，整体还是划算的。这些因子在推理时必须和权重一起在显存里，因为每次矩阵乘法都要用它们做反量化。
2.3 词表和元数据：留在内存，不占显存
词表（tokenizer 的 vocab）在 GGUF 里可能占几十到几百 MB，取决于词表大小和多语言支持程度。这部分数据在加载后被解析成 CPU 侧的数据结构，用于 tokenize 和 detokenize，完全不进显存。元数据（架构名、层数、head 数、rope 参数等）更是只有几 KB，加载后变成配置对象。
这就是为什么一个 5.9GB 的文件，显存占用能比文件小这么多。文件里可能有一大块是词表和对齐填充，这些都不参与 GPU 计算。
2.4 对齐填充：文件体积的隐形膨胀
GGUF 为了内存映射对齐，会在张量之间插入填充字节。尤其是当张量大小不是页对齐的时候，填充可能占几个百分点。这些填充在文件里存在，但加载时会被跳过，不占显存也不占有效内存。
综合下来，一个 5.9GB 的 GGUF，真正需要进显存的权重加量化因子可能只有 3GB 出头，再减去 CPU 侧处理的部分，2.7GB 就说得通了。
3. 量化等级怎么选，直接决定显存占用和输出质量
3.1 常见量化等级的显存与质量对照
llama.cpp 支持的量化等级很多，从 Q2 到 Q8，还有各种 K-quant 和 I-quant 变体。我整理了一张对照表，基于 7B 模型的实测经验值：
| 量化等级 | 文件大小（7B） | 显存占用（全卸载） | 质量损失 | 适用场景 |
|---|---|---|---|---|
| Q2_K | ~2.8GB | ~1.5GB | 明显，长文本容易崩 | 极端低显存，应急 |
| Q3_K_M | ~3.5GB | ~1.9GB | 可感知，短对话还行 | 4GB 卡勉强 |
| Q4_K_M | ~4.4GB | ~2.4GB | 轻微，日常够用 | 6GB 卡推荐 |
| Q5_K_M | ~5.3GB | ~2.9GB | 很小 | 8GB 卡推荐 |
| Q6_K | ~6.2GB | ~3.4GB | 几乎无感 | 10GB 卡 |
| Q8_0 | ~8.1GB | ~4.4GB | 基本无损 | 12GB 卡以上 |
我这次的文件 5.9GB，介于 Q5_K_M 和 Q6_K 之间，可能是某个混合量化版本，或者模型本身比 7B 略大。显存 2.7GB 对应的是 Q4 到 Q5 之间的实际驻留量，说明有一部分层可能用了更低位宽，或者 KV cache 开得很小。
3.2 为什么 Q4_K_M 是大多数人的甜点
Q4_K_M 的“M”代表 medium，是 K-quant 里的中等档。它在 4 位的基础上，对不同的张量用不同的策略：attention 的 V 投影和 FFN 的 down 投影用更精细的量化，因为这些层对输出质量影响大；其他层用更激进的压缩。这种混合策略让它在 4 位里质量最好，同时体积可控。
实测下来，Q4_K_M 和 FP16 的差距在短对话里几乎看不出来，长文本生成时偶尔会有重复或逻辑跳跃，但通过调整 temperature 和 repetition penalty 能缓解。如果你显存紧张，Q4_K_M 是首选；如果还有余量，上 Q5_K_M 会更稳。
3.3 量化对显存的影响不是线性的
从 Q4 到 Q5，文件大小增加约 20%，但显存占用增加可能只有 15%，因为 KV cache 和 workspace 是固定的。反过来，从 Q8 降到 Q4，文件减半，显存可能只降 40%。这个非线性关系在规划显存时很重要：不要按文件比例去估算显存，要按实际加载后的nvidia-smi读数来调。
4. 用 llama.cpp 加载模型时，显存到底被谁吃了
4.1 权重显存：最大头，但可压缩
权重显存就是前面说的量化后张量加缩放因子。这部分的大小基本由量化等级和卸载层数决定。全卸载时，它占显存的 70% 到 85%。我这次 2.7GB 里，权重部分大约 2.2GB。
4.2 KV cache：随上下文长度线性增长
KV cache 是推理时缓存的历史 key 和 value，用来避免重复计算。它的大小和上下文长度、层数、head 数、head 维度、以及 KV 的精度有关。公式大致是：
KV cache 大小 = 2 * n_layers * n_ctx * n_kv_heads * head_dim * bytes_per_element其中 2 是 key 和 value 两份，bytes_per_element 取决于你是否对 KV 也做了量化。llama.cpp 支持--cache-type-k和--cache-type-v参数，可以把 KV 压到 8 位甚至 4 位。
我这次上下文开了 4096，KV cache 用默认的 FP16，算下来大约 0.4GB。如果开到 8192，这部分会翻倍到 0.8GB，显存占用就会明显上升。所以“5.9GB 文件只占 2.7GB”这个数字，是在特定上下文长度下的结果，换个配置就不一样了。
4.3 计算 workspace：CUDA 的临时缓冲区
CUDA 在跑矩阵乘法、softmax、norm 这些操作时，需要临时缓冲区。llama.cpp 会预分配一块 workspace，大小和 batch size、序列长度、模型维度有关。这部分通常几百 MB，我这次大约 0.1GB。
4.4 计算图与 CUDA context：固定开销
CUDA context 本身要占几百 MB，这是驱动层面的固定开销，任何 CUDA 程序都逃不掉。llama.cpp 的计算图缓冲区也会占一部分。这两项加起来大约 0.2GB。
把这几项加起来：2.2 + 0.4 + 0.1 + 0.2 = 2.9GB，和实测的 2.7GB 基本吻合，差值来自实际分配的对齐和释放策略。
5. 实测：怎么验证你的模型到底占多少显存
5.1 用 nvidia-smi 做基线对比
最直接的方法是在加载模型前后各跑一次nvidia-smi，看显存变化。但要注意，CUDA context 在第一次调用时才会分配，所以最好先跑一个空推理，再记录基线。
# 加载前 nvidia-smi --query-gpu=memory.used --format=csv # 启动 llama.cpp 并加载模型 ./llama-cli -m model.gguf -ngl 99 -c 4096 -p "test" -n 1 # 另开终端，加载后 nvidia-smi --query-gpu=memory.used --format=csv两次读数的差值就是模型加推理的真实占用。我实测下来，空载 0.3GB，加载后 3.0GB，推理时峰值 3.1GB，稳定后 2.7GB。
5.2 用 llama.cpp 自带的日志
llama.cpp 在加载时会打印显存分配日志，包括每个 buffer 的大小。启动时加上--verbose能看到详细输出。日志里会显示llm_load_tensors的分配情况，以及 KV cache 的大小。这是最准确的信息来源，比 nvidia-smi 更细。
5.3 调整参数观察显存变化
想搞清楚每个参数对显存的影响，可以固定其他变量，只改一个：
- 只改
-ngl：从 0 到 99，看显存线性增长，斜率就是每层权重的平均大小。 - 只改
-c：从 2048 到 8192，看 KV cache 的线性增长。 - 只改
--cache-type-k：从 f16 到 q8_0，看 KV cache 减半。
我做过一组测试，-c 2048时显存 2.5GB，-c 4096时 2.7GB，-c 8192时 3.1GB。每增加 2048 上下文，KV cache 增加约 0.2GB，和公式算出来的一致。
6. 低显存跑模型的几个实用技巧
6.1 分层卸载：不是所有层都值得放 GPU
-ngl参数控制卸载到 GPU 的层数。全部卸载最快，但显存不够时可以只卸载一部分。llama.cpp 会优先把计算量大的层放 GPU，剩下的用 CPU 算。实测下来，卸载 70% 的层能保留 90% 的速度，显存省 30%。这是一个很好的折中点。
6.2 KV cache 量化：省显存最划算的一刀
把 KV cache 从 FP16 压到 Q8_0，显存直接减半，质量损失极小。再压到 Q4_0，显存减到四分之一，但长文本时可能影响注意力精度。我的建议是：显存够就 FP16，紧张就 Q8_0，极端情况才用 Q4_0。
./llama-cli -m model.gguf -ngl 99 -c 8192 --cache-type-k q8_0 --cache-type-v q8_06.3 控制 batch size 和 ubatch size
-b和-ub控制逻辑 batch 和物理 batch 的大小。默认值可能偏大，导致 workspace 占用高。在低显存场景下，把-b降到 256、-ub降到 64，能省下几百 MB。代价是 prompt 处理速度略降，但生成速度基本不变。
6.4 用 mmap 减少内存峰值
llama.cpp 默认用内存映射加载模型，这样文件不会一次性读进内存，而是按需分页。这对内存小的机器很友好，但对显存没直接影响。不过 mmap 能让加载更快，间接减少显存分配的碎片。
6.5 避免同时跑多个实例
一个常见错误是同时开两个 llama.cpp 进程，每个都占 2.7GB，8GB 卡直接爆。如果要用不同模型，建议串行跑，或者用同一个进程加载多个模型（llama.cpp 支持多模型，但显存会叠加）。
7. 踩过的坑：那些让显存估算失准的细节
7.1 文件大小不等于显存，但也不等于内存
我一开始以为 5.9GB 文件至少占 5.9GB 内存，结果发现 mmap 加载后常驻内存只有 1GB 多，其余是页缓存。这意味着你可以加载比内存大的模型，只要磁盘够快。但显存不行，显存是实打实分配的，没有页缓存这一层。
7.2 CUDA context 的隐形占用
第一次跑 CUDA 程序时，驱动会分配一个 context，占 200 到 500MB。这个开销在 nvidia-smi 里能看到，但很容易被忽略。如果你在容器里跑，context 可能更大。所以估算显存时，要留出至少 0.5GB 给 context 和驱动。
7.3 不同量化版本的实际占用差异
同样是 Q4_K_M，不同模型、不同转换脚本出来的文件，显存占用可能差 10% 到 20%。因为量化时哪些层保留高精度、块大小怎么设，都会影响。所以不要迷信“Q4_K_M 就是 2.4GB”这种固定值，要以实测为准。
7.4 上下文长度的隐性成本
很多人只关注权重显存，忽略了 KV cache。开 32768 上下文时，KV cache 可能比权重还大。我见过一个案例，7B Q4 模型权重 2.4GB，但 32K 上下文的 KV cache 占了 3.2GB，总显存 5.6GB，8GB 卡直接不够。所以规划显存时，一定要把上下文长度算进去。
7.5 显存碎片与分配策略
长时间运行、反复加载卸载模型，会导致显存碎片。llama.cpp 每次加载会重新分配，但 CUDA 的分配器不一定能完美复用。如果发现显存占用比预期高，可以重启进程，或者用PYTORCH_CUDA_ALLOC_CONF类似的策略（llama.cpp 有自己的分配器，但原理类似）。
8. 从 2.7GB 这个数字能推出什么
回到标题这个数字。5.9GB 文件、2.7GB 显存，这个比例大约是 46%。对于 Q4 到 Q5 之间的量化，这个比例是合理的。它告诉我们几件事：
第一，GGUF 的加载效率很高，文件里大量非权重数据不占显存。第二，量化确实有效，4 位量化把权重压到了原始 FP16 的四分之一左右。第三，KV cache 和 workspace 在短上下文下占比不大，但长上下文时会成为主要矛盾。
如果你手头有一张 6GB 或 8GB 的卡，看到 5.9GB 的模型文件不要慌，先看量化等级和上下文需求。Q4_K_M 加 4096 上下文，6GB 卡完全能跑。Q5_K_M 加 8192 上下文，8GB 卡也稳。真正需要担心的是那些 Q8 加 32K 上下文的组合，那才是显存杀手。
我个人的经验是：先按文件大小的 50% 估算显存，再根据上下文长度加 0.2 到 1GB，最后留 0.5GB 给 CUDA context。这个粗算公式在大多数 GGUF 模型上都适用，误差在 15% 以内。等你跑过几个模型，对量化等级和显存的关系有了手感，就能一眼看出一个模型能不能在你的卡上跑。
最后分享一个我常用的验证流程：下载模型后，先用-ngl 0纯 CPU 跑一次，确认模型能正常加载和输出；然后逐步增加-ngl，每次加 10 层，观察显存和速度变化；找到显存占用 80% 的那个点，就是你这张卡的最佳配置。这个过程花不了十分钟，但能让你对模型的显存特性了如指掌，比任何估算都靠谱。
