19.5GB模型塞进24GB显卡，为什么还是卡？

在 Hugging Face 上找到一个看起来很能打的代码模型，GGUF 文件大约 19.5 GB，你的显卡有 24 GB 显存。账面上看，装得下。可一跑起来，模型慢得像在爬。

问题不在权重，在 KV 缓存。模型装进去了，工作负载没装进去——这就是所谓的「KV 缓存悬崖」。

按 64 层、8 个 KV 头、每头 128 维、32768 上下文来算，FP16 精度的 KV 缓存要吃掉约 8.00 GiB（约 8.59 GB）。再加上 CUDA 和计算缓冲区、推理运行时本身的开销，24 GB 的余量被迅速填满。

一个 32B 的 Q4_K_M 模型，权重大概 19.5 GB，已经占掉 24 GB 显卡的大半。32K 上下文再要 8 GiB 左右的 FP16 缓存，剩下的空间就不够摆下整套运行时了。

写代码的场景更容易踩坑。用 Cursor、Cline 这类 IDE 助手时，一次请求里塞进去的不只是你刚问的那句话，还可能包括此前交换的消息、打开的文件和相关代码片段、项目结构、工具执行结果和终端输出、仓库里的指令说明。在真实仓库上干活的助手，上下文消耗远高于普通聊天。

还有一个常被忽略的点：Ollama 的默认上下文长度通常是 4096 token，除非另行配置。部分应用和 API 客户端会显式请求更大的上下文（num_ctx）。别默认每个代码助手都在用 32K，得去看实际的上下文配置和请求内容。

在把模型权重从 Q4_K_M 降到更小、可能更弱的量化版本之前，先试试量化 KV 缓存。Ollama 支持不同的 KV 缓存精度，对很多本地推理负载来说，q8_0 是个实用的起点：缓存内存大约减半，质量保留得比 q4_0 好得多。

具体做法是在启动 Ollama 服务前配置这几个环境变量：

• OLLAMA_FLASH_ATTENTION=1：确保开启 Flash Attention，KV 缓存量化需要它。
• OLLAMA_KV_CACHE_TYPE=q8_0：用 8 位量化缓存替代 FP16，缓存显存大约减半。
• OLLAMA_NUM_PARALLEL=1：避免在单用户机器上把缓存分配复制到多个并发序列槽。

如果 Ollama 已经作为后台服务在跑（Linux 上的 systemd，或 macOS/Windows 应用），要带着这些环境变量重启那个服务。在无关的终端里 export 一下，改不了正在运行的守护进程。

上下文长度也要显式设定，别分配超过硬件能留在显存里的窗口。可以写一个 Modelfile，指定 num_ctx 16384，构建成自定义变体再运行。注意发起 API 请求的客户端仍可能在请求选项里覆盖 num_ctx，服务端默认值则由 OLLAMA_CONTEXT_LENGTH 控制。用 ollama ps 和 nvidia-smi 验证实际运行行为，别假设 Modelfile 一定说了算。

目标是让模型执行保持 100% GPU，同时给桌面和编码上下文留出足够的显存余量。

需要直接控制时，llama.cpp 提供更细的选项：用 llama-server 加载模型，指定上下文长度、把键和值的缓存类型都设为 q8_0、开启 Flash Attention、把 GPU 层数拉满。具体支持情况取决于你的 llama.cpp 构建、GPU 后端和硬件。如果还是超出显存，先降上下文，或者试试 q4_0 缓存，再考虑放弃当前的权重量化。

一个常见的错误是：看一眼 GGUF 文件大小，跟显卡显存比一比，就认定能流畅跑。下载 20 到 40 GB 的模型之前，至少要算上这些：

• 模型权重内存
• KV 缓存精度（f16、q8_0、q4_0）
• 目标上下文长度
• 运行时开销和计算缓冲区
• 显示器、IDE 和其他应用已占用的显存
• 并发序列数量
• 注意力架构（比如 GQA 与 MLA）

以 Qwen2.5-Coder-32B（Q4_K_M，19.5 GB 权重）在 24 GB 的 RTX 4090 上配 q8_0 缓存为例：从 32K 上下文（约 4.29 GB 缓存，总计约 25.22 GB，溢出到系统内存）降到 16K 上下文（约 2.15 GB 缓存，总计估算约 23.08 GB），差别就是 CPU 卸载和塞进 24 GB 之间。

模型跑得慢，先别急着买新显卡或换更小的模型，按这份清单过一遍：

1. 跑 ollama ps，确认是 100% GPU 还是 CPU/GPU 混合。
2. 跑 nvidia-smi，看实际显存占用和后台占显卡的应用。
3. 核实 IDE 或客户端请求的实际上下文长度。
4. 确认 Flash Attention 已开启。
5. 把 KV 缓存精度从 f16 换成 q8_0。
6. 任务不需要 32K 以上时，调低上下文长度。
7. 测单用户速度时设 OLLAMA_NUM_PARALLEL=1。
8. 每次改动前后对比 tokens/sec。
9. 把提示处理（prefill）和 token 生成分开测量。

如果模型已经是 100% GPU 却还是慢，那就去看显存带宽、计算利用率、提示长度、批处理和 backend 设置。不是每个慢吞吞的本地模型都卡在 KV 缓存上。

跑本地代码大模型，从来不只是权重能不能塞进显存的问题，而是把整套运行时——权重、KV 缓存、缓冲区、IDE 上下文——一起装进显卡内存。在牺牲模型质量之前，先调上下文长度、试 q8_0 缓存量化，用 ollama ps 和 nvidia-smi 实测，找到你这张卡最舒服的那个点。