KV缓存压缩技术发展简史A brief history of KV cache compression developments

尽管人们的注意力主要集中在模型的改进上，但 KV cache 压缩效率也迎来了突破性的提升。我很想知道这些改进到底有多大，以及为什么我认为它如此重要。

核心数据是：自 2017 年以来，存储单个 token 上下文所需的内存大约下降了 100 倍。同一时期，顶级数据中心 GPU 的内存从 16GB 增加到了 288GB——提升了 18 倍。AI 领域的“内存墙”问题主要是通过数学算法解决的，而不是靠硅片硬件。

什么是 KV cache？

当你使用 LLM 时——无论是通过 ChatGPT 等网页端，还是通过 Claude Code 进行智能体交互——你的“上下文”都存储在 KV cache 中。这一过程一直极其消耗内存，从而对会话长度造成了硬性限制。

简而言之，你与 LLM 的“对话”越长，所需的 KV cache 就越多。更高效的 KV cache 能让你在相同的内存空间内输入更多内容——包括对话、代码、参考文档和图像。

一个不太严谨的类比是音视频文件的压缩。正是 MP3 算法使得 90 年代后期的音频文件得以充分压缩，从而让 Napster（几乎）能够正常运行。同样地，MPEG2 让数字电视得以运作，而后续的 H.264 等算法则让 Netflix 能够在（较）慢的宽带连接下流畅运行。

如果没有现代的视频压缩编解码器，Netflix 的 4K 视频流将需要（许）多 Gbps 的带宽才能运行。而有了压缩编解码器，它可以被压缩到 15Mbit/秒的带宽分配中——压缩比超过 100 倍。

这种效率的提升往往能让你超越硬件的改进速度。毫无疑问，宽带连接速度最终会在某个节点快到足以传输未压缩的 4K 视频流，但压缩技术能让你以更快的速度将改进推广到更广阔的市场。

KV cache 的诞生

当 Transformer 在 2017 年左右刚问世时，如果使用 MHA，一个 128K token 的上下文窗口（大约 10 万个英文单词）在单次对话中需要约 340GB 的 GPU 内存。这是在假设使用 16 位精度、70B 级别稠密模型的前提下——这意味着对话中每个 token 需要消耗约 2.6MB 的内存。

在 2017 年，像 Tesla V100 这样绝对顶尖的数据中心 GPU 配备了 16GB 的 HBM2 内存。因此，在那种架构下，你需要大约 20 块顶级 GPU 才能维持一次对话——这在如今看来是非常局限的。

虽然这是一种事后诸葛亮式的假设——因为在当时你根本无法与 transformer 进行任何对话——但它确实说明了当时的硬件条件和运行效率有多么落后。

第一次重大飞跃是 2019 年由 Google 的 Noam Shazeer 提出的 MQA。它通过在所有查询头（query heads）之间共享单个 KV 头（KV head），实现了高达 64 倍的惊人缩减（在具有 64 个注意力头的模型上）。然而，这种方法存在重大缺点——模型质量受到严重影响，训练变得不那么稳定，并且长程记忆能力显著下降。它确实得到了一些采用（例如 PaLM 和 Falcon 使用了它），但很明显这种压缩过于激进。

GQA

随着 LLM 的能力开始大幅提升，上下文窗口成为了一个巨大的问题。GPT3.5 的上下文窗口限制仅为 4K token——勉强只够输入几页文档。这无疑是由于其庞大的内存需求所致。

这种局限性有多大，怎么说都不为过。尽管模型仍处于非常早期的阶段，但如果上下文窗口的效率没有进一步发展，LLM 将被限制在非常简短的问答会话中。任何类型的智能体工作流，无论模型质量如何，都会受到极大的限制——即使在现在，在 Claude Code 中仅仅定义智能体可访问的工具就需要消耗 2 万个 token，这还是在没有任何输入或输出之前。

LLM 提供商解决这一问题的核心方式就是删除会话中的消息。ChatGPT 可能只会截取你的第一条消息，以及上下文窗口能容纳的最近 n 条消息。这导致了极其糟糕的结果，因为它会瞬间忘记自己几条消息之前刚说过的话。对于任何严肃的文档处理工作来说，这完全是行不通的。

GQA 于 2023 年问世，它允许多组查询头共享 KV 头——这是介于 MHA 和 MQA 之间的一种折中方案。使用 8 个 KV 头组可以实现 8 倍的压缩——并且随着会话变长，质量损失微乎其微。Llama 2 70B 和 Mistral 几乎立即采用了它，它也迅速成为开源模型的默认标准。

大约在同一时间，另一种技巧也并行出现：滑动窗口注意力机制。在这种机制下，某些层只关注固定窗口内的最近 token，因此它们对应的 KV cache 占用量会完全停止增长。Mistral 在 2023 年发布了该特性，随后 Google 的 Gemma 模型将局部和全局注意力层交错使用，达到了类似的效果。

一旦这类方法变得普遍，我们就开始看到上下文窗口长度快速增加——毫无疑问，这也得益于可用内存的增加。GPT3.5-Turbo 支持 16k 的上下文窗口，虽然最初的 GPT4 发布时只有 8k（还有一个昂贵的 32k 版本），但到 2023 年底，GPT4-Turbo 将其大幅扩展到了 128k。

MLA —— DeepSeek 带来的惊喜

下一次重大飞跃来自 DeepSeek 在 2024 年提出的 MLA。MLA 没有在查询头之间共享 KV 头，而是将键和值压缩成一个更小的潜在向量，并将解压缩步骤融合到周边的投影矩阵中，因此根本不需要完全实例化所有的键和值。DeepSeek 在其 V2 论文中声称 KV cache 大小减少了 93%——同时还在质量基准测试上有所提升，而不仅仅是保持稳定。

这是一个重要的证明点。MQA 表明，如果接受质量下降，你可以进行高强度的压缩；GQA 表明几乎在质量无损的情况下可以实现适度的压缩——而 MLA 则表明，你可以在没有任何损失的情况下，将压缩率比 GQA 再提高一个数量级。这也是 DeepSeek 能够以极低成本提供模型服务的重要原因之一，以至于在 2025 年初的一天之内，他们让 Nvidia 的市值蒸发了近 6000 亿美元。

与此同时，KV cache 本身的量化——以 8 位甚至 4 位精度而不是 16 位精度来存储键和值——变得越来越标准化，这在此前所有改进的基础上，又大致将有效容量翻了一倍或两番。像 Google 的 TurboQuant 等更新的方法更是将其推向了新的高度。

（此外还有一个完整的并行领域是服务端的改进，比如 vLLM 的 PagedAttention——但这关乎如何管理 KV 内存而不是压缩它，所以我在这里不将其纳入讨论范围。）

智能体能力

从2023年底到2025年，模型在上下文窗口大小上多少陷入了“停滞”状态，OpenAI 和 Anthropic 提供的模型 token 长度大约在 128k 到 200k 之间。客观地说，这些上下文长度并不算太糟——它们足以应对编程任务和中等复杂的文档处理。但是，随着真正的编程智能体开始普及，这变得极其受限。

在这段时间里，如果你在构建或使用智能体，就不得不花大量时间考虑这个问题。读取太多大型文件会撑爆上下文窗口，从而导致令人头疼的“压缩（compaction）”过程——这是一种相当粗暴的方法，试图总结智能体所能访问的所有内容。

2025年左右的下一个重大突破是线性注意力混合模型——像 Qwen3-Next 和 Kimi Linear 这样的模型，用线性注意力取代了大部分的全注意力层，这种机制为每一层保留一个较小且固定大小的状态，而不是不断增长的缓存。只有少数层保留了完整的 KV cache。这种（无疑还有其他鲜为人知的）方法使得上下文窗口能够扩大到 1M tokens，且质量几乎没有下降。这大概就是为什么 Anthropic 今年早些时候能够推出 1M 上下文窗口，甚至没有为此收取额外费用的主要原因。

上下文中每个 token 的 KV cache 内存（对数坐标）。在同一时期，GPU 内存仅提升了约 18 倍。

未来

目前没有任何迹象表明这种趋势会放缓。研究越来越倾向于彻底摆脱二次复杂度注意力的瓶颈——即无论上下文增长多长，都能保持固定大小状态的纯线性和循环方法。它们能否在质量上完全媲美注意力机制仍然是一个悬而未决的问题，但混合模型已经证明，你并不需要每一层都付出全量代价。

不过，我觉得最有趣的事情是：在大约九年里实现了约 100 倍的压缩收益，但令人惊讶的是，其中很少一部分体现为价格的降低。当然，Token 价格确实下降了，但大部分的效率提升都被用于支持更长的上下文窗口。4K 变成了 128K，又变成了 1M。就像视频编解码器的进步被用于追求更高分辨率而不是更小的文件一样，我们不断将内存效率的收益用于构建更强大的智能体。而且随着内存成为当前 AI 扩展中最棘手的瓶颈之一，我预计这种情况还会继续。

一如既往，在这个领域，这篇文章的一半内容很可能在一年内就会过时。目前有巨额资金投入到降低上下文成本的研究中——我绝对敢断言，未来还会出现另一个 100 倍的提升。