DeepSeek-V4-Flash MXFP4 推理显存异常：KV 缓存量化类型影响计算缓冲区约 3 倍
Reddit 用户在 llama.cpp 上测试 DeepSeek-V4-Flash MXFP4 量化版本时发现，仅切换…
近日，Reddit 用户在 r/LocalLLaMA 板块分享了一项针对 DeepSeek-V4-Flash（MXFP4 量化版）在 llama.cpp 中的显存占用测试，发现一个此前未被广泛记录的内存分配现象：在其他参数完全一致的情况下，仅切换 KV 缓存的量化类型，就会让 compute buffer（计算缓冲区）出现约 3 倍的差异，而 KV 缓存本体的缩减却相当有限。
测试环境与方法
测试使用 Bartowski 发布的 DeepSeek-V4-Flash-MXFP4 GGUF 版本，配合 llama.cpp 构建版本 9851（commit 0eca4d490），采用 deepseek4 架构。固定参数如下：
- n_ctx = 10240
- n_batch = n_ubatch = 8192
- 开启 Flash Attention
唯一变量为 -ctk / -ctv 参数指定的 KV 缓存量化类型。
关键数据对比
在相同上下文长度下，两组配置的表现差异显著：
- f16（默认，未设置 -ctk / -ctv）：KV 缓存（CUDA0）约 425 MiB；CUDA0 compute buffer 约 12,964 MiB。
- q8_0（设置 -ctk q8_0 -ctv q8_0）：KV 缓存（CUDA0）约 226 MiB；CUDA0 compute buffer 约 3,973 MiB。
实际 KV 缓存仅节省约 200 MiB，但 compute buffer 从 ~13 GB 降至 ~4 GB，缩放比例约 3.26 倍。发帖者表示，正是这一差异导致此前在 32 GB 显卡、ctx=32000 场景下出现的 OOM（显存溢出）问题——f16 缓存配置下 compute buffer 请求达到约 35.9 GB，超出显存上限；切换为 q8_0 缓存后即可正常加载。
现象解读与社区反馈
发帖者分析认为，DeepSeek-V4-Flash 内部的 CSA/HCA/lightning-indexer 等压缩缓存本身已较小，因此 f16 与 q8_0 在 KV 缓存本体的差距有限；但框架侧在分配 compute buffer 时，似乎仍按未量化语境预留额外显存，从而放大了缓存类型对总占用的影响。
该用户也在征求社区反馈，看是否有其他人在 DeepSeek-V4-Flash MXFP4 上观察到相近量级的 compute buffer 缩减。
实践建议
对于在消费级显卡上本地部署 DeepSeek-V4-Flash MXFP4 的用户而言，遇到高上下文长度下的 OOM 问题时，显式设置 -ctk q8_0 -ctv q8_0 是一个低成本的可行方案，预计可在不显著影响生成质量的前提下，把显存峰值压缩约三分之二。