1. 从一条日志说起5.9GB 模型为什么只吃 2.7GB 显存先把结论摆在前面模型文件大小和显存占用从来就不是一回事。我本地跑一个 5.9GB 的 GGUF 模型nvidia-smi里看到进程显存稳定在 2.7GB 上下第一次看到这个数字的时候我也愣了一下以为是加载失败了结果 token 正常往外吐速度还挺稳。后来把 llama.cpp 的加载日志逐行翻了一遍才把这件事彻底想明白。这篇东西适合三类人看一是手里只有 6G、8G 显存卡想跑本地大模型但一直被“模型多大就要多大显存”吓退的人二是已经在用 llama.cpp、Ollama、ComfyUI 这类工具加载 GGUF但搞不清显存到底花在哪的人三是想搞清楚量化、mmap、KV Cache 这几件事之间关系的人。我会把这条日志背后的机制、参数、实操步骤、踩过的坑全部摊开讲尽量让你看完能自己复现一遍并且知道每一步为什么这么做。核心关键词就几个llama.cpp、GGUF、CUDA、显存、量化。这五个词基本构成了本地推理的全部骨架。llama.cpp 是推理引擎GGUF 是模型文件格式CUDA 是 NVIDIA 显卡的计算后端显存是真正决定你能不能跑起来的硬约束量化是让模型瘦身、把显存压下来的关键手段。理解了这五者的关系5.9GB 变 2.7GB 这件事就一点都不神秘了。我先把这条日志里最容易被误读的几个数字列出来后面逐个拆数字含义是否等于显存占用5.9GBGGUF 文件在磁盘上的大小否2.7GB进程实际占用的显存是含 KV Cache模型参数量决定计算量间接相关量化位数决定每参数字节数直接相关很多人第一反应是“5.9GB 的文件怎么也得占 5.9GB 显存吧”这个直觉在早期 PyTorch 直接model.to(cuda)的时代基本成立但在 llama.cpp GGUF mmap 这套组合下完全不成立。原因有三层量化让权重变小、mmap 让权重不必全部进显存、KV Cache 才是显存的大头之一。下面一层层剥。2. 拆解显存账本权重、KV Cache、计算缓冲各占多少2.1 量化到底把模型压小了多少先讲量化。一个模型原始权重通常是 FP16每个参数 2 字节。假设一个 7B 模型FP16 下光权重就是 7 × 10^9 × 2 字节 ≈ 14GB。这就是为什么早期 7B 模型要 16G 显存才能跑。量化就是把每个参数的表示位数降下来Q8_0约 8.5 bit/参数接近无损7B 约 7GBQ6_K约 6.6 bit/参数7B 约 5.5GBQ5_K_M约 5.5 bit/参数7B 约 4.8GBQ4_K_M约 4.8 bit/参数7B 约 4.1GBQ3_K_M约 3.9 bit/参数7B 约 3.3GBQ2_K约 2.6 bit/参数7B 约 2.7GB注意这里的“约”字因为 GGUF 的 K-quant 系列不是简单地把每个参数砍成固定位数而是对不同的张量用不同的量化策略。比如 attention 的v权重、feed-forward 的down_proj往往保留更高精度而一些对精度不敏感的层用更低位数。这就是为什么 Q4_K_M 比纯 Q4_0 效果好但体积略大。我那条日志里的 5.9GB 文件按经验大概率是 Q5_K_M 或 Q6_K 级别的 7B~8B 模型。文件 5.9GB 是磁盘上的压缩表示加载进显存时如果全部驻留理论上也接近这个数。但实际只用了 2.7GB说明权重并没有全部进显存。这就引出了 mmap。2.2 mmap让权重“按需上桌”llama.cpp 默认使用mmap内存映射加载 GGUF 文件。你可以把它理解成模型文件还在磁盘上系统给这块文件建了一个“映射表”CPU 访问哪一页就把哪一页读进内存GPU 需要哪部分权重再通过 CUDA 的 unified memory 或显式拷贝传过去。这里有个关键点llama.cpp 在 CUDA 后端下默认会把多少层放到 GPU 是可以配置的这个参数叫-nglnumber of GPU layers。如果你设-ngl 0那所有权重都在 CPU 内存里显存占用几乎为 0只剩一点 CUDA context。如果你设-ngl 99理论上所有层都上 GPU显存占用就会接近文件大小。但实际中即使-ngl设得比较高llama.cpp 也不会把整个文件一次性拷进显存。它采用按层加载 按需驻留的策略当前计算需要哪一层的权重就把那一层从 mmap 的内存里拷到显存算完可以释放或复用。这就解释了为什么 5.9GB 的文件只占 2.7GB 显存——同一时刻显存里只需要放正在计算的那几层而不是全部。注意这个行为在不同版本、不同后端下不完全一致。有些版本会把-ngl指定的层常驻显存有些则更激进地做动态换入换出。所以看到显存远小于文件大小时先别慌去看日志里的load_tensors和offload行。2.3 KV Cache被低估的显存大户权重之外显存里还有一块大头KV Cache。Transformer 每生成一个 token都要缓存之前所有 token 的 key 和 value 向量避免重复计算。这个缓存的大小和以下因素成正比上下文长度context length层数注意力头数每头维度批大小batch sizeKV Cache 的数据类型FP16 还是量化后的 Q8/Q4公式大致是KV Cache 字节数 2 × 层数 × 上下文长度 × 隐藏维度 × 数据类型字节数以一个 7B 模型为例32 层隐藏维度 4096上下文 4096FP162 × 32 × 4096 × 4096 × 2 ≈ 2.1GB如果上下文拉到 8192直接翻倍到 4.2GB。这就是为什么很多人跑长上下文时显存突然爆掉——不是权重变大了是 KV Cache 涨了。llama.cpp 提供了--cache-type-k和--cache-type-v参数可以把 KV Cache 量化成 Q8_0 甚至 Q4_0显存能砍掉一半以上。我实测在 8G 卡上把 KV Cache 设成 Q8_0上下文 8192 也能稳住。2.4 计算缓冲与 CUDA context还有两块容易被忽略CUDA context每个进程初始化 CUDA 大约占 200~500MB取决于驱动和显卡。计算缓冲矩阵乘、attention 计算时的临时张量和 batch size、序列长度相关通常几百 MB。所以 2.7GB 的构成大致是一部分常驻权重 KV Cache CUDA context 计算缓冲。具体比例要看你的-ngl、上下文长度和 batch 设置。3. 实操从零复现这条日志的完整流程3.1 环境准备与 CUDA 版本选择先说环境。我用的是一张 8G 显存的卡驱动版本和 CUDA 版本要匹配。llama.cpp 的 CUDA 后端对 CUDA Toolkit 版本有要求太老或太新都可能编译失败。# 查看显卡和驱动 nvidia-smi # 查看已安装的 CUDA nvcc --version ls /usr/local/ | grep cuda如果你是多版本 CUDA 共存编译时用CUDACXX指定export CUDACXX/usr/local/cuda-12.1/bin/nvcc编译 llama.cppgit clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURESnative cmake --build build --config Release -jCMAKE_CUDA_ARCHITECTURESnative会自动检测你的显卡架构避免编译出用不了的 kernel。这一步很多人踩坑手动指定了错误的架构编译能过但运行时报no kernel image is available。提示如果你在 WSL2 里跑CUDA 是透传的不需要在 WSL 里再装驱动但需要装 CUDA Toolkit。WSL2 的显存占用会比原生 Linux 略高一点因为多了一层虚拟化。3.2 模型下载与 GGUF 选择GGUF 模型来源很多选的时候注意三点量化等级、是否带 chat template、是否分片。# 假设你已经有一个 GGUF 文件 ls -lh model-Q5_K_M.gguf # -rw-r--r-- 1 user user 5.9G ... model-Q5_K_M.gguf5.9GB 这个体积对应 7B~8B 模型的 Q5_K_M 或 Q6_K。选量化等级的原则显存紧张优先 Q4_K_M性价比最高追求质量且显存够用选 Q6_K 或 Q8_0低于 Q3 的量化在中文任务上掉点明显慎用3.3 启动参数与显存观测关键启动命令./build/bin/llama-cli \ -m model-Q5_K_M.gguf \ -ngl 99 \ -c 4096 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ -b 512 \ -n 512 \ -p 你好请介绍一下你自己参数解释参数作用对显存的影响-ngl 99尽量多放 GPU 层越大显存越高-c 4096上下文长度线性影响 KV Cache--cache-type-k/vKV Cache 量化q8_0 约省一半-b 512批大小影响计算缓冲-n 512生成 token 数影响 KV Cache 增长启动后另开一个终端watch -n 1 nvidia-smi你会看到显存占用在加载阶段爬升然后稳定在一个值。我这条日志里稳定在 2.7GB 左右对应的就是上面这套配置。3.4 日志逐行解读llama.cpp 启动时会打印大量信息重点看这几行llm_load_tensors: ggml ctx size 0.30 MiB llm_load_tensors: offloading 32 repeating layers to GPU llm_load_tensors: offloaded 32/33 layers to GPU llm_load_tensors: CPU buffer size 512.00 MiB llm_load_tensors: CUDA0 buffer size 2048.00 MiB llama_new_context_with_model: KV self size 512.00 MiB llama_new_context_with_model: compute buffer total size 128.00 MiB这几行直接告诉你显存花在哪CUDA0 buffer 是权重KV self size 是缓存compute buffer 是计算临时区。加起来差不多就是nvidia-smi看到的数字。看懂这几行你就能自己算显存账不用再猜。4. 常见问题与排查技巧实录4.1 显存占用比预期高怎么办先按优先级排查降低-ngl从 99 往下调比如 20、15看显存变化。缩短上下文-c从 8192 降到 4096 甚至 2048。量化 KV Cache加--cache-type-k q8_0 --cache-type-v q8_0。减小 batch-b从 512 降到 256 或 128。换更低量化等级的模型Q5 换 Q4Q4 换 Q3。我整理了一张速查表现象可能原因解决方向加载即 OOM-ngl太高或上下文太长降-ngl、降-c生成中途 OOMKV Cache 随 token 增长量化 KV、限制-n显存远小于文件mmap 按需加载正常现象无需处理显存远大于文件全部层常驻 大 KV检查-ngl和-c速度极慢层在 CPU 上算提高-ngl但注意显存4.2 踩过的坑坑一以为-ngl 99就是全部上 GPU。实际上 99 是“尽量多”如果显存不够llama.cpp 会自动把放不下的层留在 CPU日志里会显示offloaded 28/33 layers这种。所以看到显存没满但速度慢先看这行。坑二忽略 KV Cache 量化。很多人只关注权重量化忘了 KV Cache 也能量化。在长上下文场景下KV Cache 量化的收益比权重量化还大。坑三CUDA 版本和驱动不匹配。编译过了不代表能跑运行时报CUDA error: no kernel image基本都是架构或版本问题。用native架构编译最稳。坑四WSL2 下显存显示不准。WSL2 的nvidia-smi有时显示的是宿主机的总量进程占用要看nvidia-smi的 processes 部分或者用nvidia-smi --query-compute-appspid,used_memory --formatcsv。坑五多进程抢显存。同时跑 ComfyUI 和 llama.cpp两个进程都在抢OOM 是必然的。跑之前先nvidia-smi确认没有残留进程。4.3 低显存运行的核心思路如果你只有 6G 甚至 4G 显存核心思路是把权重尽量留在 CPU只把计算密集的部分放 GPU。具体做法-ngl设小一点比如 10~20上下文控制在 2048~4096KV Cache 量化到 q8_0 或 q4_0batch 设小比如 128用 Q4_K_M 或更低的量化这样速度会慢一些但能跑起来。我实测 6G 卡跑 7B Q4_K_M-ngl 20、-c 2048、KV q8_0显存稳定在 3.5GB 左右生成速度大概 8~12 token/s日常问答够用。5. 从这条日志延伸出去的几个认知5.1 显存和模型参数的关系不是线性的很多人问“7B 模型要多少显存”这个问题没有标准答案因为取决于量化等级、上下文、KV Cache 类型、-ngl设置。同样是 7BQ8_0 全上 GPU 加 8192 上下文可能要 12GBQ4_K_M 部分上 GPU 加 2048 上下文4GB 就能跑。显存需求是一个区间不是一个固定值。5.2 GGUF 的设计哲学GGUF 之所以能做到“文件大、显存小”核心在于它把模型权重、tokenizer、超参数、chat template 全部打包在一个文件里并且支持 mmap 和分片。这让推理引擎可以灵活决定哪些部分进显存、哪些留在内存。相比早期 PyTorch 的state_dictGGUF 对本地部署友好太多。5.3 量化不是免费的午餐量化省显存、省带宽但会掉精度。Q4_K_M 在大多数任务上和 FP16 差距很小但 Q2_K 在数学、代码、长链推理上掉点明显。我的建议是能上 Q5 就别用 Q4能上 Q4 就别用 Q3除非显存实在不够。另外不同模型的量化敏感度不一样有些模型 Q4 就很稳有些 Q5 都掉点最好自己跑几个测试用例对比。5.4 关于“低显存运行模型”的常见误区误区一模型文件多大就要多大显存。错mmap 和按需加载让显存可以远小于文件。误区二显存越大速度越快。不一定速度还取决于-ngl、batch、CPU 内存带宽。误区三量化等级越低越好。错太低会掉点要平衡。误区四KV Cache 不用管。错长上下文下它是显存大头。6. 一套可复用的显存估算方法最后给你一套我自己常用的估算流程不用跑起来就能大致算出显存需求算权重大小参数量 × 量化位数 / 8。比如 7B × 5.5bit / 8 ≈ 4.8GB。算 KV Cache2 × 层数 × 上下文 × 隐藏维度 × 字节数。FP16 是 2 字节Q8 是 1 字节。加 CUDA context约 0.3~0.5GB。加计算缓冲约 0.1~0.5GB看 batch。乘一个系数如果-ngl不是全部权重部分按比例算。举个例子7B Q5_K_M32 层隐藏 4096上下文 4096KV q8_0-ngl 99权重约 4.8GBKV2 × 32 × 4096 × 4096 × 1 ≈ 1.07GBcontext buffer约 0.6GB合计约 6.5GB如果-ngl 20权重只有 20/32 上 GPU约 3GB合计约 4.7GB。这就和实际观测对上了。我个人的体会是别被模型文件大小吓到先跑起来看日志再根据日志调参数。llama.cpp 的日志信息非常全看懂那几行比看十篇教程都管用。你要是也在折腾本地推理不妨把nvidia-smi和启动日志对着看一遍很多疑问自然就解开了。 
长河君 · 2026/11/4 4:03:50 · 阅读 1.2k llama.cpp 加载 GGUF 模型：5.9GB 文件为何只占 2.7GB 显存？
1. 从一条日志说起5.9GB 模型为什么只吃 2.7GB 显存先把结论摆在前面模型文件大小和显存占用从来就不是一回事。我本地跑一个 5.9GB 的 GGUF 模型nvidia-smi里看到进程显存稳定在 2.7GB 上下第一次看到这个数字的时候我也愣了一下以为是加载失败了结果 token 正常往外吐速度还挺稳。后来把 llama.cpp 的加载日志逐行翻了一遍才把这件事彻底想明白。这篇东西适合三类人看一是手里只有 6G、8G 显存卡想跑本地大模型但一直被“模型多大就要多大显存”吓退的人二是已经在用 llama.cpp、Ollama、ComfyUI 这类工具加载 GGUF但搞不清显存到底花在哪的人三是想搞清楚量化、mmap、KV Cache 这几件事之间关系的人。我会把这条日志背后的机制、参数、实操步骤、踩过的坑全部摊开讲尽量让你看完能自己复现一遍并且知道每一步为什么这么做。核心关键词就几个llama.cpp、GGUF、CUDA、显存、量化。这五个词基本构成了本地推理的全部骨架。llama.cpp 是推理引擎GGUF 是模型文件格式CUDA 是 NVIDIA 显卡的计算后端显存是真正决定你能不能跑起来的硬约束量化是让模型瘦身、把显存压下来的关键手段。理解了这五者的关系5.9GB 变 2.7GB 这件事就一点都不神秘了。我先把这条日志里最容易被误读的几个数字列出来后面逐个拆数字含义是否等于显存占用5.9GBGGUF 文件在磁盘上的大小否2.7GB进程实际占用的显存是含 KV Cache模型参数量决定计算量间接相关量化位数决定每参数字节数直接相关很多人第一反应是“5.9GB 的文件怎么也得占 5.9GB 显存吧”这个直觉在早期 PyTorch 直接model.to(cuda)的时代基本成立但在 llama.cpp GGUF mmap 这套组合下完全不成立。原因有三层量化让权重变小、mmap 让权重不必全部进显存、KV Cache 才是显存的大头之一。下面一层层剥。2. 拆解显存账本权重、KV Cache、计算缓冲各占多少2.1 量化到底把模型压小了多少先讲量化。一个模型原始权重通常是 FP16每个参数 2 字节。假设一个 7B 模型FP16 下光权重就是 7 × 10^9 × 2 字节 ≈ 14GB。这就是为什么早期 7B 模型要 16G 显存才能跑。量化就是把每个参数的表示位数降下来Q8_0约 8.5 bit/参数接近无损7B 约 7GBQ6_K约 6.6 bit/参数7B 约 5.5GBQ5_K_M约 5.5 bit/参数7B 约 4.8GBQ4_K_M约 4.8 bit/参数7B 约 4.1GBQ3_K_M约 3.9 bit/参数7B 约 3.3GBQ2_K约 2.6 bit/参数7B 约 2.7GB注意这里的“约”字因为 GGUF 的 K-quant 系列不是简单地把每个参数砍成固定位数而是对不同的张量用不同的量化策略。比如 attention 的v权重、feed-forward 的down_proj往往保留更高精度而一些对精度不敏感的层用更低位数。这就是为什么 Q4_K_M 比纯 Q4_0 效果好但体积略大。我那条日志里的 5.9GB 文件按经验大概率是 Q5_K_M 或 Q6_K 级别的 7B~8B 模型。文件 5.9GB 是磁盘上的压缩表示加载进显存时如果全部驻留理论上也接近这个数。但实际只用了 2.7GB说明权重并没有全部进显存。这就引出了 mmap。2.2 mmap让权重“按需上桌”llama.cpp 默认使用mmap内存映射加载 GGUF 文件。你可以把它理解成模型文件还在磁盘上系统给这块文件建了一个“映射表”CPU 访问哪一页就把哪一页读进内存GPU 需要哪部分权重再通过 CUDA 的 unified memory 或显式拷贝传过去。这里有个关键点llama.cpp 在 CUDA 后端下默认会把多少层放到 GPU 是可以配置的这个参数叫-nglnumber of GPU layers。如果你设-ngl 0那所有权重都在 CPU 内存里显存占用几乎为 0只剩一点 CUDA context。如果你设-ngl 99理论上所有层都上 GPU显存占用就会接近文件大小。但实际中即使-ngl设得比较高llama.cpp 也不会把整个文件一次性拷进显存。它采用按层加载 按需驻留的策略当前计算需要哪一层的权重就把那一层从 mmap 的内存里拷到显存算完可以释放或复用。这就解释了为什么 5.9GB 的文件只占 2.7GB 显存——同一时刻显存里只需要放正在计算的那几层而不是全部。注意这个行为在不同版本、不同后端下不完全一致。有些版本会把-ngl指定的层常驻显存有些则更激进地做动态换入换出。所以看到显存远小于文件大小时先别慌去看日志里的load_tensors和offload行。2.3 KV Cache被低估的显存大户权重之外显存里还有一块大头KV Cache。Transformer 每生成一个 token都要缓存之前所有 token 的 key 和 value 向量避免重复计算。这个缓存的大小和以下因素成正比上下文长度context length层数注意力头数每头维度批大小batch sizeKV Cache 的数据类型FP16 还是量化后的 Q8/Q4公式大致是KV Cache 字节数 2 × 层数 × 上下文长度 × 隐藏维度 × 数据类型字节数以一个 7B 模型为例32 层隐藏维度 4096上下文 4096FP162 × 32 × 4096 × 4096 × 2 ≈ 2.1GB如果上下文拉到 8192直接翻倍到 4.2GB。这就是为什么很多人跑长上下文时显存突然爆掉——不是权重变大了是 KV Cache 涨了。llama.cpp 提供了--cache-type-k和--cache-type-v参数可以把 KV Cache 量化成 Q8_0 甚至 Q4_0显存能砍掉一半以上。我实测在 8G 卡上把 KV Cache 设成 Q8_0上下文 8192 也能稳住。2.4 计算缓冲与 CUDA context还有两块容易被忽略CUDA context每个进程初始化 CUDA 大约占 200~500MB取决于驱动和显卡。计算缓冲矩阵乘、attention 计算时的临时张量和 batch size、序列长度相关通常几百 MB。所以 2.7GB 的构成大致是一部分常驻权重 KV Cache CUDA context 计算缓冲。具体比例要看你的-ngl、上下文长度和 batch 设置。3. 实操从零复现这条日志的完整流程3.1 环境准备与 CUDA 版本选择先说环境。我用的是一张 8G 显存的卡驱动版本和 CUDA 版本要匹配。llama.cpp 的 CUDA 后端对 CUDA Toolkit 版本有要求太老或太新都可能编译失败。# 查看显卡和驱动 nvidia-smi # 查看已安装的 CUDA nvcc --version ls /usr/local/ | grep cuda如果你是多版本 CUDA 共存编译时用CUDACXX指定export CUDACXX/usr/local/cuda-12.1/bin/nvcc编译 llama.cppgit clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURESnative cmake --build build --config Release -jCMAKE_CUDA_ARCHITECTURESnative会自动检测你的显卡架构避免编译出用不了的 kernel。这一步很多人踩坑手动指定了错误的架构编译能过但运行时报no kernel image is available。提示如果你在 WSL2 里跑CUDA 是透传的不需要在 WSL 里再装驱动但需要装 CUDA Toolkit。WSL2 的显存占用会比原生 Linux 略高一点因为多了一层虚拟化。3.2 模型下载与 GGUF 选择GGUF 模型来源很多选的时候注意三点量化等级、是否带 chat template、是否分片。# 假设你已经有一个 GGUF 文件 ls -lh model-Q5_K_M.gguf # -rw-r--r-- 1 user user 5.9G ... model-Q5_K_M.gguf5.9GB 这个体积对应 7B~8B 模型的 Q5_K_M 或 Q6_K。选量化等级的原则显存紧张优先 Q4_K_M性价比最高追求质量且显存够用选 Q6_K 或 Q8_0低于 Q3 的量化在中文任务上掉点明显慎用3.3 启动参数与显存观测关键启动命令./build/bin/llama-cli \ -m model-Q5_K_M.gguf \ -ngl 99 \ -c 4096 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ -b 512 \ -n 512 \ -p 你好请介绍一下你自己参数解释参数作用对显存的影响-ngl 99尽量多放 GPU 层越大显存越高-c 4096上下文长度线性影响 KV Cache--cache-type-k/vKV Cache 量化q8_0 约省一半-b 512批大小影响计算缓冲-n 512生成 token 数影响 KV Cache 增长启动后另开一个终端watch -n 1 nvidia-smi你会看到显存占用在加载阶段爬升然后稳定在一个值。我这条日志里稳定在 2.7GB 左右对应的就是上面这套配置。3.4 日志逐行解读llama.cpp 启动时会打印大量信息重点看这几行llm_load_tensors: ggml ctx size 0.30 MiB llm_load_tensors: offloading 32 repeating layers to GPU llm_load_tensors: offloaded 32/33 layers to GPU llm_load_tensors: CPU buffer size 512.00 MiB llm_load_tensors: CUDA0 buffer size 2048.00 MiB llama_new_context_with_model: KV self size 512.00 MiB llama_new_context_with_model: compute buffer total size 128.00 MiB这几行直接告诉你显存花在哪CUDA0 buffer 是权重KV self size 是缓存compute buffer 是计算临时区。加起来差不多就是nvidia-smi看到的数字。看懂这几行你就能自己算显存账不用再猜。4. 常见问题与排查技巧实录4.1 显存占用比预期高怎么办先按优先级排查降低-ngl从 99 往下调比如 20、15看显存变化。缩短上下文-c从 8192 降到 4096 甚至 2048。量化 KV Cache加--cache-type-k q8_0 --cache-type-v q8_0。减小 batch-b从 512 降到 256 或 128。换更低量化等级的模型Q5 换 Q4Q4 换 Q3。我整理了一张速查表现象可能原因解决方向加载即 OOM-ngl太高或上下文太长降-ngl、降-c生成中途 OOMKV Cache 随 token 增长量化 KV、限制-n显存远小于文件mmap 按需加载正常现象无需处理显存远大于文件全部层常驻 大 KV检查-ngl和-c速度极慢层在 CPU 上算提高-ngl但注意显存4.2 踩过的坑坑一以为-ngl 99就是全部上 GPU。实际上 99 是“尽量多”如果显存不够llama.cpp 会自动把放不下的层留在 CPU日志里会显示offloaded 28/33 layers这种。所以看到显存没满但速度慢先看这行。坑二忽略 KV Cache 量化。很多人只关注权重量化忘了 KV Cache 也能量化。在长上下文场景下KV Cache 量化的收益比权重量化还大。坑三CUDA 版本和驱动不匹配。编译过了不代表能跑运行时报CUDA error: no kernel image基本都是架构或版本问题。用native架构编译最稳。坑四WSL2 下显存显示不准。WSL2 的nvidia-smi有时显示的是宿主机的总量进程占用要看nvidia-smi的 processes 部分或者用nvidia-smi --query-compute-appspid,used_memory --formatcsv。坑五多进程抢显存。同时跑 ComfyUI 和 llama.cpp两个进程都在抢OOM 是必然的。跑之前先nvidia-smi确认没有残留进程。4.3 低显存运行的核心思路如果你只有 6G 甚至 4G 显存核心思路是把权重尽量留在 CPU只把计算密集的部分放 GPU。具体做法-ngl设小一点比如 10~20上下文控制在 2048~4096KV Cache 量化到 q8_0 或 q4_0batch 设小比如 128用 Q4_K_M 或更低的量化这样速度会慢一些但能跑起来。我实测 6G 卡跑 7B Q4_K_M-ngl 20、-c 2048、KV q8_0显存稳定在 3.5GB 左右生成速度大概 8~12 token/s日常问答够用。5. 从这条日志延伸出去的几个认知5.1 显存和模型参数的关系不是线性的很多人问“7B 模型要多少显存”这个问题没有标准答案因为取决于量化等级、上下文、KV Cache 类型、-ngl设置。同样是 7BQ8_0 全上 GPU 加 8192 上下文可能要 12GBQ4_K_M 部分上 GPU 加 2048 上下文4GB 就能跑。显存需求是一个区间不是一个固定值。5.2 GGUF 的设计哲学GGUF 之所以能做到“文件大、显存小”核心在于它把模型权重、tokenizer、超参数、chat template 全部打包在一个文件里并且支持 mmap 和分片。这让推理引擎可以灵活决定哪些部分进显存、哪些留在内存。相比早期 PyTorch 的state_dictGGUF 对本地部署友好太多。5.3 量化不是免费的午餐量化省显存、省带宽但会掉精度。Q4_K_M 在大多数任务上和 FP16 差距很小但 Q2_K 在数学、代码、长链推理上掉点明显。我的建议是能上 Q5 就别用 Q4能上 Q4 就别用 Q3除非显存实在不够。另外不同模型的量化敏感度不一样有些模型 Q4 就很稳有些 Q5 都掉点最好自己跑几个测试用例对比。5.4 关于“低显存运行模型”的常见误区误区一模型文件多大就要多大显存。错mmap 和按需加载让显存可以远小于文件。误区二显存越大速度越快。不一定速度还取决于-ngl、batch、CPU 内存带宽。误区三量化等级越低越好。错太低会掉点要平衡。误区四KV Cache 不用管。错长上下文下它是显存大头。6. 一套可复用的显存估算方法最后给你一套我自己常用的估算流程不用跑起来就能大致算出显存需求算权重大小参数量 × 量化位数 / 8。比如 7B × 5.5bit / 8 ≈ 4.8GB。算 KV Cache2 × 层数 × 上下文 × 隐藏维度 × 字节数。FP16 是 2 字节Q8 是 1 字节。加 CUDA context约 0.3~0.5GB。加计算缓冲约 0.1~0.5GB看 batch。乘一个系数如果-ngl不是全部权重部分按比例算。举个例子7B Q5_K_M32 层隐藏 4096上下文 4096KV q8_0-ngl 99权重约 4.8GBKV2 × 32 × 4096 × 4096 × 1 ≈ 1.07GBcontext buffer约 0.6GB合计约 6.5GB如果-ngl 20权重只有 20/32 上 GPU约 3GB合计约 4.7GB。这就和实际观测对上了。我个人的体会是别被模型文件大小吓到先跑起来看日志再根据日志调参数。llama.cpp 的日志信息非常全看懂那几行比看十篇教程都管用。你要是也在折腾本地推理不妨把nvidia-smi和启动日志对着看一遍很多疑问自然就解开了。