★ FEATURED ARTICLE 1. 5.9GB 的模型文件为什么只吃掉 2.7GB 显存先把结论摆在前面模型文件大小和显存占用从来就不是一回事。我这次跑的模型GGUF 文件躺在硬盘上是 5.9GB加载进 llama.cpp 之后nvidia-smi显示显存占用稳定在 2.7GB 上下差了整整一倍多。很多人第一次看到这个数字会觉得哪里出错了或者怀疑是不是模型没加载完整、层没全部 offload 到 GPU。实际上这个差值是完全正常的而且它背后牵扯到的东西恰恰是低显存跑模型这件事最核心的知识点。我先把这次实验的环境交代清楚方便你对照自己的情况。显卡是一张 12GB 显存的卡CUDA 版本 12.xllama.cpp 用的是带 CUDA 后端的编译版本模型是 GGUF 格式的量化模型。整个加载过程没有用任何额外的显存优化开关就是最朴素的-ngl全量 offload。跑起来之后显存占用 2.7GB推理速度也正常没有出现层被挤回 CPU 导致的性能塌方。那 5.9GB 到 2.7GB 之间蒸发掉的那 3.2GB 去哪了这个问题值得掰开揉碎讲因为它直接决定了你能不能在一张 6GB 甚至 4GB 的卡上跑起来一个看起来装不下的模型。理解了这个机制你在选模型、选量化档位、配-ngl参数的时候心里就有底了而不是靠一次次试错去撞。这篇文章我会从 GGUF 的文件结构讲起说清楚磁盘上的字节和显存里的字节为什么对不上然后讲量化到底在省什么接着给出一套可复现的显存估算方法让你在下载模型之前就能算出来自己的卡能不能扛住最后聊几个实际部署里最容易踩的坑包括那个让无数人抓狂的no lm runtime found for model format gguf报错。全程围绕 llama.cpp GGUF CUDA 这条链路不跑偏。2. GGUF 文件里的字节和显存里的字节不是一回事2.1 磁盘上的 5.9GB 到底装了什么GGUF 是 llama.cpp 生态里的模型容器格式你可以把它理解成一个打包好的模型压缩包。它里面装的东西比很多人想象的要杂除了模型权重本身还有词表、各种超参数、张量名称映射、对齐填充、甚至一些元数据。这些非权重的部分在磁盘上占的空间不算小尤其是词表一个多语言词表动辄几十上百 MB。更关键的是GGUF 文件在磁盘上是按方便存储和分发的方式排列的不一定按方便 GPU 读取的方式排列。文件里会有对齐填充会有为了兼容不同后端而保留的冗余信息。这些字节在你把它加载进显存的时候大部分是不需要原样搬进去的。我拿这次这个 5.9GB 的模型举例粗略拆一下它的构成。权重部分大概占 5.4GB 左右词表和元数据加起来 300MB 上下剩下的是对齐和格式开销。也就是说真正需要进显存的有效载荷从一开始就比文件总大小要少一截。这是第一层缩水。2.2 加载时哪些东西被留在了内存里llama.cpp 在加载模型的时候并不是把整个 GGUF 文件一股脑塞进显存。它做的事情更像是一个按需搬运的过程。权重张量会根据你的-ngl设置决定放多少层到 GPU词表、采样相关的缓冲区、部分元数据这些默认是留在系统内存里的。这里有个很多人忽略的点词表在推理时其实不需要常驻显存。tokenize 和 detokenize 是在 CPU 侧完成的词表放在内存里就够了。一个几十 MB 甚至上百 MB 的词表就这么从显存账单里被划掉了。模型越大、词表越复杂这部分省下来的就越多。还有 KV cache。KV cache 是推理过程中动态增长的它占的是显存但它不属于模型加载那部分。你在nvidia-smi里看到的 2.7GB如果是在模型刚加载完、还没开始长上下文的时候测的那基本就是纯权重占用如果是在跑了一段长对话之后测的那里面还包含了 KV cache。这两个数字要分开看不然会误判。2.3 量化把 16 位浮点压成 4 位整数的魔法真正让 5.9GB 变成 2.7GB 的主力是量化。原始模型权重通常是 FP16每个参数占 2 字节。一个 7B 参数的模型FP16 下光权重就要 14GB。量化就是把这些参数用更少的位数来表示Q4 量化下每个参数大约占 0.5 字节出头7B 模型权重就降到 4GB 左右。但量化不是简单地把数字截断。它有一套自己的编码方式把一组权重比如 32 个或 256 个归一化到一个共享的缩放因子上然后用低位整数表示相对值。这样既压了体积又尽量保住了精度。Q4_K_M 这种档位之所以流行就是它在体积和精度之间找到了一个甜点。这里要澄清一个常见误解量化后的模型文件大小约等于量化后权重的显存占用但不完全相等。因为文件里还有前面说的那些非权重开销而显存里又可能有 KV cache 和对齐开销。两者会有出入但量级上是对得上的。我这次 5.9GB 文件对应 2.7GB 显存说明这个模型的量化档位压得比较狠同时词表和元数据占比不低。3. 显存占用的三层账权重、KV cache、运行时开销3.1 权重占用可以精确估算的部分权重占用是显存账单里最可控的一块。估算公式很简单权重显存 ≈ 参数量 × 每参数字节数不同量化档位的每参数字节数大致如下表。这张表我建议你存下来选模型的时候直接查。量化档位每参数字节数约7B 模型权重13B 模型权重备注FP162.014GB26GB原始精度基本不用于本地Q8_01.067.4GB13.8GB精度损失极小体积大Q6_K0.825.7GB10.7GB精度和体积平衡好Q5_K_M0.704.9GB9.1GB常用档位Q4_K_M0.584.1GB7.6GB最流行的甜点档Q4_00.563.9GB7.3GB老档位兼容性好Q3_K_M0.463.2GB6.0GB精度开始明显下降Q2_K0.352.5GB4.6GB极限压缩质量堪忧注意表里的数字是约因为不同模型的层结构、注意力头数、词表大小都不一样实际会有 5% 到 10% 的浮动。但用这张表做快速判断足够了。比如你有一张 6GB 的卡想跑 7B 模型Q4_K_M 下权重 4.1GB加上 KV cache 和运行时开销勉强能塞下但上下文不能开太长。3.2 KV cache被严重低估的显存杀手KV cache 是很多人在估算显存时漏掉的一块也是明明模型装下了却还是爆显存的头号元凶。它的计算公式是KV cache ≈ 2 × 层数 × 注意力头数 × 头维度 × 上下文长度 × 每元素字节数简化一下对于大多数模型KV cache 每 1K 上下文大约占几十到一百多 MB。上下文开到 8KKV cache 就可能吃掉 1GB 以上。如果你用的是 FP16 的 KV cache这个数字还要翻倍。llama.cpp 提供了--cache-type-k和--cache-type-v参数可以把 KV cache 也量化成 Q8 甚至 Q4。这一招在低显存场景下非常管用能把 KV cache 占用砍掉一半以上代价是长上下文下的精度会有一点点损失。我实测下来Q8 的 KV cache 在大多数对话场景里几乎感觉不到质量下降但省下来的显存很实在。3.3 运行时开销CUDA 上下文和临时缓冲区还有一块容易被忽略的显存占用是 CUDA 运行时本身的开销。CUDA context 一创建就要占几百 MB这是固定成本跟你跑什么模型无关。llama.cpp 在推理时还会申请一些临时缓冲区用于矩阵运算这部分大小跟 batch size 和模型结构有关。所以你在nvidia-smi里看到的数字其实是这三层账的总和总显存 权重 KV cache CUDA运行时开销 临时缓冲区我这次 2.7GB 的占用大概是权重 2.2GB 左右CUDA 开销 300MB 上下KV cache 因为上下文还短所以只有 100 多 MB。等上下文涨到 4K、8K这个数字会明显往上走。所以模型只占 2.7GB这个说法严格讲是模型加载完、短上下文状态下占 2.7GB长上下文下会更高。4. 动手算一遍下载模型前就知道能不能跑4.1 从模型名里读出参数量和量化档位GGUF 模型的命名通常很有规律比如Qwen2.5-7B-Instruct-Q4_K_M.gguf。这里面7B是参数量Q4_K_M是量化档位。看到这两个信息你就能用前面的表快速估算权重占用。但有些模型名会骗人。比如 MoE 架构的模型名字里写的是总参数量但实际激活的参数量可能只有一小部分。这种情况下显存占用要按总参数量算因为所有专家权重都得加载进显存只是每次推理只激活其中几个。这一点在选 MoE 模型时特别重要别被激活参数少误导了显存估算。4.2 一套可复现的显存估算流程我平时用下面这套流程做快速判断基本不会翻车确定参数量和量化档位从模型文件名或模型卡里读出来。查表估算权重用 3.1 节的表或者用参数量 × 每参数字节数手算。估算 KV cache按你打算用的上下文长度算每 1K 上下文预留 100MB 到 150MBFP16 KV cache。加上固定开销CUDA context 和运行时预留 500MB 到 800MB。留出安全余量总占用不要超过显存的 85%给系统和其他进程留空间。举个例子一张 8GB 的卡想跑 7B 的 Q4_K_M 模型上下文开 4K权重约 4.1GBKV cache4K 上下文约 0.5GB固定开销约 0.6GB合计约 5.2GB8GB 的卡跑这个配置占用 5.2GB占比 65%很安全。如果上下文开到 8KKV cache 涨到 1GB合计 5.7GB也还行。但如果换成 Q6_K 的权重5.7GB合计就奔着 7GB 去了8GB 的卡就开始紧张。4.3 用 llama.cpp 自带的信息做验证llama.cpp 在加载模型时会打印一堆信息包括每一层的张量大小、总权重占用、KV cache 大小。这些信息比任何估算都准。我习惯在正式跑之前先用一个很短的 prompt 加载一次看它打印的显存相关日志确认没问题再上正式任务。如果你用的是带 Web UI 的封装可能看不到这些日志。这时候可以退而求其次用nvidia-smi在加载前后各测一次差值就是模型加载占用的显存。这个方法虽然粗但足够判断能不能装下。5. 低显存部署的实操参数与踩坑记录5.1-ngl到底设多少-nglnumber of GPU layers是 llama.cpp 里最关键的显存控制参数。它决定有多少层被 offload 到 GPU。设成 0 就是纯 CPU 推理设成 999 或者模型总层数就是全量 offload。全量 offload 速度最快但显存占用最高。如果显存不够就得把一部分层留在 CPU 上用-ngl控制 offload 的层数。每少 offload 一层显存就省一点但速度也慢一点。这个权衡需要你自己试找到刚好不爆显存的那个点。我的经验是先设全量 offload如果爆显存就往下调每次调 2 到 4 层直到稳定。别一次调太多不然会白白损失速度。另外不同层的显存占用不一样前面的层通常小一些后面的层大一些所以调的时候要有耐心。5.2 那个让人抓狂的no lm runtime found for model format gguf这个报错我见过太多次了尤其是在把 GGUF 模型往各种封装工具里塞的时候。它的本质是你用的那个运行时runtime不认识 GGUF 格式或者没有编译对应的后端支持。常见原因有这么几个你用的 llama.cpp 版本太老不支持你下载的 GGUF 版本。GGUF 格式本身也在演进新模型可能用了新特性。你装的是纯 CPU 版本的 llama.cpp但模型需要 CUDA 后端或者反过来。你用的封装工具比如某些 Web UI内置的是 ONNX 或 PyTorch 后端根本不支持 GGUF。解决办法先确认你的 llama.cpp 是带 CUDA 编译的用llama-cli --version看输出里有没有 CUDA 字样。然后确认模型文件的 GGUF 版本和你的 llama.cpp 版本兼容。实在不行重新拉最新代码编译一遍大部分情况下能解决。5.3 CUDA 版本和显卡驱动的匹配CUDA 版本不匹配是另一个高频坑。llama.cpp 编译时链接的 CUDA 版本必须和你的显卡驱动支持的版本兼容。驱动太老新 CUDA 跑不起来驱动太新老 CUDA 可能有问题。我一般这么做先用nvidia-smi看驱动版本和支持的最高 CUDA 版本然后装一个不超过这个上限的 CUDA Toolkit。比如驱动支持到 CUDA 12.4我就装 12.1 或 12.2留一点余量。装完之后用nvcc --version确认再重新编译 llama.cpp。如果你在 WSL2 里跑还要注意 WSL2 的 CUDA 是透传的不需要在 WSL 里单独装驱动但需要装 CUDA Toolkit。这个细节很多人搞混在 WSL 里装了一遍驱动结果和宿主机的驱动打架。5.4 量化档位的选择不是越低越好低显存场景下很多人会本能地选最低的量化档位比如 Q2_K觉得这样最省显存。但 Q2_K 的精度损失是肉眼可见的模型会变得笨回答质量明显下降甚至开始胡言乱语。我的建议是优先保证量化档位不低于 Q4_K_M。如果 Q4_K_M 装不下宁可换一个更小的模型也不要硬压量化档位。一个 3B 的 Q4_K_M 模型效果通常比一个 7B 的 Q2_K 模型好而且跑得更快。这个取舍在低显存场景下非常关键。如果实在要用低档位可以试试 Q3_K_M它是低档位里质量还能接受的。Q2_K 和 Q2_K_S 我基本不推荐除非你只是做格式验证或者跑着玩。6. 从 2.7GB 这个数字里能读出什么回到开头那个 5.9GB 文件占 2.7GB 显存的例子。这个数字其实透露了不少信息。它说明这个模型的量化档位压得比较狠权重部分大概只占文件的一半多也说明词表和元数据在这个模型里占比不低可能有 300MB 到 500MB 被留在了内存里还说明当前上下文很短KV cache 还没长起来。如果你在自己的机器上测出来的数字和文件大小差得没这么多比如 5.9GB 文件占了 5GB 显存那可能是几个原因量化档位比较高比如 Q8_0词表比较小或者你测的时候上下文已经很长了KV cache 把差值补回来了。这些都不是问题只是说明你的配置和我的不一样。真正要警惕的是显存占用比文件还大很多的情况。比如 5.9GB 的文件占了 8GB 显存那多半是 KV cache 开太大了或者 batch size 设太高或者有别的进程在抢显存。这时候就要去查-ngl、--ctx-size、--batch-size这几个参数逐个排查。我个人的习惯是每换一个新模型都先做一次空载测试加载模型不跑推理看显存占用然后跑一个短 prompt再看一次最后跑一个长上下文看第三次。三次数字记下来心里就有谱了以后配参数直接参考不用每次重新试。低显存跑模型这件事说到底就是把这笔显存账算清楚。算清楚了你就知道该选什么模型、什么量化档位、什么上下文长度而不是靠运气去撞。5.9GB 变 2.7GB 不是什么黑魔法就是量化、词表分离、按需加载这几件事叠加起来的结果。理解了这些你在 6GB 甚至 4GB 的卡上也能找到属于自己的那个刚好能跑的配置。
阅读完成 · 觉得有帮助？
