KV Cache on KnightLi的博客

DeepSeek-V4 KV Cache 机制解析：为什么 1M 上下文更省显存

Mon, 18 May 2026 18:38:26 +0800

长上下文模型真正贵的地方，往往不是“能不能塞进 100 万 Token”，而是推理时 KV Cache 要占多少显存。

在 Transformer 解码过程中，每生成一个新 Token，模型都要保留历史 Token 对应的 Key 和 Value。上下文越长，KV Cache 越大；KV Cache 越大，显存、内存带宽、首字延迟和吞吐都会被拖慢。

DeepSeek-V4 的特别之处，是它没有只在注意力头数量上省缓存，而是把压缩进一步推进到序列长度维度。按照 Hugging Face 对 DeepSeek-V4 技术报告的解读，在 1M Token 场景下，DeepSeek-V4-Pro 的 KV Cache 约为 DeepSeek-V3.2 的 10%；如果和常见的 bf16 GQA 架构相比，约为其 2% 左右。

这就是 DeepSeek-V4 缓存机制最值得看的地方：它不是简单把 KV 存得更小，而是减少需要长期保存和检索的 KV 条目数量。

先看几代 KV Cache 优化路线

KV Cache 优化大致可以分成几条路线。

第一类是传统 MHA，也就是 Multi-Head Attention。每个 Query 头通常都有对应的 Key/Value 头。它结构直接，但长上下文下缓存随序列长度线性增长，显存压力最大。

第二类是 GQA，也就是 Grouped Query Attention。多个 Query 头共享较少的 Key/Value 头。LLaMA、Mistral、Qwen 等很多现代模型都采用类似思路。它能显著减少 KV 头数量，是当前主流长上下文模型的常见节省手段。

第三类是 MLA，也就是 Multi-head Latent Attention。DeepSeek-V2、DeepSeek-V3 使用这一路线，把 Key/Value 压缩成低秩潜在表示，从注意力头维度进一步降低缓存占用。

第四类就是 DeepSeek-V4 引入的混合压缩注意力。它把重点放到序列长度维度：不是只减少每个 Token 要存多少 KV，而是把多个历史 Token 压缩成更少的 KV 条目，再用稀疏或稠密方式检索。

可以粗略理解为：

MHA：每个头都认真记。
GQA：多个 Query 头共享一部分记忆。
MLA：把每个 Token 的 KV 表示压成潜在向量。
DeepSeek-V4：把很多历史 Token 聚合成更少的压缩记忆块。

DeepSeek-V4 的关键变化：从头维度压缩到序列维度压缩

GQA 和 MLA 主要是在“每个 Token 存多少 KV”上做优化。这个方向很有效，但当上下文长度来到 1M Token 时，问题会变得更极端：即使每个 Token 的缓存已经很小，Token 数量本身仍然太多。

DeepSeek-V4 选择把旧上下文压缩成块。也就是说，模型不一定要为每个很久以前的 Token 都保留完整 KV，而是让多个 Token 形成压缩条目。

这有点像读一本很长的书：刚读过的几页你会记得细节，前面几章则更多以摘要、主题和关键线索的形式保存。DeepSeek-V4 的注意力机制也有类似分工：近处保留细节，远处用压缩表示。

CSA：4 倍压缩加稀疏检索

CSA 全称是 Compressed Sparse Attention，可以理解为较细粒度的长程压缩机制。

在 CSA 中，模型会把序列中的若干相邻 Token 压缩成更少的 KV 条目。Hugging Face Transformers 文档里给出的默认压缩率是 m=4，也就是大致每 4 个 Token 形成一个压缩条目。

但它不是简单平均。CSA 使用带学习能力的压缩池，并结合重叠窗口，让模型在压缩时保留更有用的信息。压缩之后，查询并不会对所有历史压缩块都做完整注意力，而是先通过 Lightning Indexer 打分，挑出最相关的 top-k 压缩块，再进入核心注意力计算。

这个结构有两层收益：

历史 KV 条目数量先变少。
每次查询只看最相关的一部分压缩块。

所以 CSA 适合处理远距离但仍需要细节检索的上下文，比如代码库、长文档、工具调用历史里的关键信息。

HCA：128 倍压缩加稠密注意力

HCA 全称是 Heavily Compressed Attention，压缩更激进。

Transformers 文档里给出的默认压缩率是 m'=128。也就是说，HCA 会把更长的一段上下文压成一个压缩条目。压缩后的序列已经很短，因此它不需要像 CSA 那样再做稀疏 top-k 检索，而是让 Query 对所有压缩条目做稠密注意力。

HCA 的作用更像全局摘要。它不追求保留每个细节，而是用极低成本覆盖很长的历史范围，让模型对全局背景、长程主题和远处信息保持感知。

如果把 CSA 比作“可检索的压缩笔记”，HCA 更像“全局目录和摘要”。

滑动窗口：最近上下文仍保留细节

DeepSeek-V4 并不是把所有上下文都压缩掉。

在 CSA 和 HCA 之外，它还保留了滑动窗口分支，用来处理最近的一段未压缩上下文。Transformers 文档里提到，DeepSeek-V4 的 attention block 会把长程压缩分支与滑动窗口 K/V 拼接在一起。

这个设计很重要。生成下一个 Token 时，最近几十到几百个 Token 往往最关键：变量名、函数签名、正在写的句子、刚返回的工具结果、最近用户要求。它们如果被过度压缩，输出质量会明显下降。

所以 DeepSeek-V4 的思路不是“全部压缩”，而是：

近处：保留未压缩细节。
中远处：用 CSA 做可检索压缩。
更远处：用 HCA 做重度全局压缩。

混合层栈：不同层做不同注意力

DeepSeek-V4 不是在所有层里使用同一种注意力。

Hugging Face 的 DeepSeek-V4 文章提到，V4-Pro 的 61 层结构中，前两层使用 HCA，之后的层在 CSA 和 HCA 之间交替，末尾的 MTP block 使用滑动窗口。Transformers 文档也说明，V4-Pro 默认是 2 层 HCA bootstrap 加交替 CSA/HCA。

这说明 DeepSeek-V4 把注意力机制当成分层系统来设计。不同层承担不同信息流角色：有的层更偏全局压缩，有的层更偏稀疏检索，有的部分保留局部窗口。

相比所有层统一使用一种注意力，这种混合结构更复杂，但也更适合 1M Token 这种极长上下文。

FP8 和 FP4 进一步降低缓存成本

DeepSeek-V4 的缓存节省不只来自压缩率。

Hugging Face 的文章提到，V4 的大部分 KV 条目使用 FP8 存储，RoPE 相关维度保留 BF16，而 CSA 里的 Lightning Indexer 使用 FP4。压缩比例、低精度存储、稀疏检索叠加在一起，才形成了非常低的 KV Cache 占用。

这也提醒我们：不要只看“上下文长度 1M”这个宣传数字。真正决定可部署性的，是长上下文下的显存占用、带宽压力、推理延迟和工程实现。

和其他模型的差异

与传统 MHA 相比，DeepSeek-V4 不再为长历史里每个 Token 保留完整注意力记忆，缓存压力下降非常明显。

与 GQA 相比，DeepSeek-V4 不只是减少 KV head 数量，还减少长历史的 KV 条目数量。GQA 仍然要随序列长度线性积累缓存，而 V4 会把远处上下文压成块。

与 DeepSeek-V3 的 MLA 相比，V4 的重点从“每个 Token 的表示更紧凑”进一步扩展到“历史 Token 数量也被压缩”。MLA 已经大幅降低单 Token KV 占用，但面对百万级上下文时，序列长度本身仍是压力来源。

与普通稀疏注意力相比，DeepSeek-V4 的 CSA 是先压缩再稀疏检索，索引器面对的是更短的压缩序列；HCA 则通过 128 倍压缩让全量稠密注意力也变得便宜。

对 Agent 和长任务有什么意义

Agent 工作流特别吃长上下文：它会读文件、调用工具、接收工具返回、生成计划、修正计划、继续调用工具。上下文越长，KV Cache 越容易成为瓶颈。

DeepSeek-V4 这种缓存机制的潜在价值在于：

更容易承载长代码库、长文档、多轮工具调用历史。
首字延迟和吞吐更不容易被 KV Cache 拖垮。
同等硬件上可以跑更长上下文或更多并发请求。
对百万 Token 场景，部署成本更接近实际可用，而不是只停留在论文指标。

不过也要注意，压缩注意力不是免费午餐。把历史 Token 压缩成块，必然涉及信息取舍。模型需要在“省显存”和“保留可检索细节”之间做平衡。真正效果还要看任务类型：代码定位、法律文档、长篇问答、Agent 工具链，对细节召回的要求并不一样。

不要把 2% 理解成所有成本都降到 2%

“KV Cache 约为 GQA 的 2%”很容易被误读。

它主要指 KV Cache 显存规模，不等于总推理成本只剩 2%，也不等于所有场景速度都会提升 50 倍。推理还包括模型权重读取、MoE 路由、前馈网络、注意力计算、调度开销、通信开销等。

Hugging Face 的文章里也把两个数字分开讲：在 1M Token 场景，DeepSeek-V4-Pro 相对 DeepSeek-V3.2 的单 Token 推理 FLOPs 是 27%，KV Cache 是 10%。这说明缓存和计算是两个不同维度。

所以更稳妥的说法是：DeepSeek-V4 让超长上下文的 KV Cache 压力显著降低，从而改善百万 Token 场景的部署可行性；但具体吞吐和延迟仍取决于实现、硬件、批处理、量化和推理框架。

小结

DeepSeek-V4 的缓存机制和其他大模型最大的不同，是它把 KV Cache 优化从注意力头维度推进到了序列维度。

GQA 是少存一些 KV 头，MLA 是把每个 Token 的 KV 表示压得更紧，DeepSeek-V4 则进一步把远处 Token 聚合成压缩块，并通过 CSA、HCA、滑动窗口和低精度存储组合起来，让百万 Token 上下文不再被 KV Cache 轻易卡死。

这不是单一技巧，而是一整套长上下文推理架构：近处保细节，远处做压缩，需要细节时稀疏检索，需要全局时重度摘要。

对开发者和 Agent 应用来说，它的意义很直接：长上下文不只是“能输入更多”，还要“跑得起、跑得稳、成本能接受”。DeepSeek-V4 真正改变的，正是这一点。

参考资料

8G 显存跑 llama.cpp 怎么调：32K 更稳，64K 要开 KV Cache 量化

Thu, 23 Apr 2026 12:13:04 +0800

8G 显存到底还能不能把本地大模型跑顺，尤其是在长上下文场景下还能不能保住速度，这是很多人在折腾 llama.cpp 时都会遇到的问题。

核心结论可以先记住三条：

对 8G 显存来说，32K 上下文通常是更稳的平衡点
如果一定要跑 64K，KV Cache 量化基本是必选项
在全显卡运行场景里，盲目拉高 CPU 线程数，反而可能让速度明显下降

一、先解释清楚：32K、64K 和 KV Cache 是什么

很多人第一次看这类调优文章，最容易卡住的就是这三个词。

32K 和 64K 说的是上下文长度，也就是模型一次最多能处理多少 token。这里的 K 就是千，32K 大约是 32000 token，64K 大约是 64000 token。上下文越长，模型一次能看到的历史内容越多，适合长文档问答、长对话和多轮分析。

KV Cache 则是模型为了加速连续生成而保留的一份中间结果缓存。你可以把它理解成：模型已经读过、算过的一部分内容，不会每次都从头重算，而是把关键结果先存起来，后面继续接着用。这里的 K 和 V，来自 Transformer 里的 Key 和 Value。

为什么这三个词总是一起出现？因为：

32K、64K 决定你想让模型一次记住多长内容
KV Cache 决定为了维持这段记忆，要额外占多少显存
上下文越长，KV Cache 通常越大，显存压力也越高

所以很多长上下文变慢的问题，本质上并不是模型“不会算”，而是缓存太大，把显存挤到了临界点。

二、为什么 32K 和 64K 的速度会差这么多

这里用《三体》大约 3 万字的文本做压力测试，对比 32K 和 64K 两种上下文设置。结果很夸张：在文档长度接近的情况下，64K 模式的速度显著下降，总耗时也明显拉长。

问题不在模型突然变笨，而在显存边界被撞到了。

当 32K 模式下，模型权重加缓存还能基本塞进 8G 显存里，数据大多走显卡显存带宽，速度还能维持在比较可用的区间。但一旦切到 64K，缓存体积继续上涨，总占用逼近甚至超过显存上限，系统就会把部分数据挤到内存里。

这时候真正掉下去的，不是算力，而是带宽。

也就是说，很多人看到的是“上下文翻倍后速度暴跌”，本质上其实是数据路径从显存掉到了共享内存或系统内存，推理链路不再跑在高速通道上。

三、64K 还能不能跑，关键在 KV Cache 量化

第二个很关键的结论，是 KV Cache 量化对 8G 显存用户特别重要。

如果不改变模型本身，只针对缓存做量化，长上下文下最直接的收益就是把缓存占用压缩下来，让原本已经溢出的那部分重新回到显存里。这样一来，64K 模式虽然依然比 32K 更吃资源，但至少不会直接跌进最慢的区间。

换句话说：

32K 更像是 8G 显存的默认推荐区间
64K 不是完全不能跑
但如果不上缓存量化，性能很容易从“能用”直接掉到“很难用”

如果你的目标是尽量稳定地跑长上下文，那优先级通常应该是：

先确认显存是否已经逼近上限
再决定是否开启 KV Cache 量化
最后才去继续尝试更激进的吞吐量参数

四、GPU 占用不高，不代表显卡没干活

这是一个很容易打破直觉的点。

很多人看到任务管理器里 GPU 使用率只有二三十，就会怀疑：

是不是参数没设对
是不是模型没真正跑到显卡上
是不是显卡根本没吃满

但这组测试给出的判断是，llama.cpp 这类推理很多时候首先卡的不是核心算力，而是显存读写速度。

也就是说，显卡核心可能很快就把一批计算做完了，但后面还得等下一批权重和缓存数据搬过来。于是你看到的现象就会变成：

核心占用不算高
但整体速度还是上不去

这不是显卡在偷懒，而是数据通路太窄。

所以看本地大模型速度时，不能只盯着 GPU Usage。显存容量、显存带宽、缓存是否溢出，往往更影响最终体验。

五、调大吞吐量参数，确实可能再快一截

这里还做了一个思路很清晰的测试：既然显卡核心并没有完全忙满，那能不能通过调大吞吐量相关参数，让显卡一次处理更多数据，把并行能力进一步压出来。

测试结果表明，这种做法确实有机会把速度再往上拉一段。

但这里也有一个前提：显存还得扛得住。

因为吞吐量相关参数调大之后，往往会带来额外显存占用。如果你本来就在 64K、高缓存、显存见底的状态下继续往上推，就很容易出现两种情况：

直接崩溃
没崩，但被迫进入更慢的共享内存模式

所以更稳妥的顺序通常不是“先把参数拉满”，而是：

先守住显存边界
再考虑吞吐量优化
每调一步都重新看速度和稳定性

六、CPU 线程不是越多越好

这也是整篇内容里最值得记住的坑点之一。

很多人做本地推理调优时，容易下意识觉得线程越多越快，既然机器有那么多线程，不用满就像浪费。但实测给出的结果恰恰相反：在模型已经主要跑在显卡上的情况下，强行把 CPU 线程拉高，性能反而会明显变差。

原因不复杂。

在全显卡运行时，CPU 更像是调度者和预处理协作者，而不是主力计算单元。这时候如果开太多线程，CPU 端的线程竞争、调度切换和上下文切换开销都会变重，最终把本来应该更流畅的数据流打乱。

结果就是：

CPU 更忙了
但整体速度变慢了

所以在这种场景下，默认设置或者较低线程数，往往比一味拉满更靠谱。

七、对 8G 显存用户更实用的一套思路

如果把上面的结论压成一套更容易执行的思路，大概可以整理成这样：

1. 先把 32K 当成默认目标

如果你用的是 8G 显存显卡，先别急着追 64K。32K 往往是速度、稳定性和显存占用之间更现实的平衡点。

2. 想上 64K，先处理缓存问题

不要先想“还能不能再榨一点速度”，而是先确认 KV Cache 有没有量化、显存是不是已经压线。

3. 不要用 GPU 占用率判断一切

低占用不一定代表设置错了，也可能只是显存带宽在拖后腿。

4. 吞吐量优化可以做，但别越过显存边界

这类参数确实能带来收益，但前提是显存还有余量。

5. CPU 线程先保守，再逐步测试

如果模型已经基本跑在显卡上，CPU 线程并不是越高越好。先用默认值或低线程值测试，再看是否值得继续调整。

结语

这组内容最有价值的地方，不只是给出几个测试数字，而是把一个经常被忽略的事实讲清楚了：

本地大模型调优，很多时候拼的不是“有没有把所有参数开到最大”，而是你有没有搞清楚瓶颈到底在算力、显存容量、显存带宽，还是在 CPU 调度。

对 8G 显存用户来说，真正更稳的思路通常不是硬冲最长上下文，而是先守住显存边界，再决定要不要继续往上加。

如果只记一句话，那就是：

32K 往往是 8G 显存更稳的工作区间；64K 不是不能跑，但前提是你已经把 KV Cache 和显存占用管住了。