KV Cache 是什么?为什么它决定了大模型的推理速度?

token 序列 推理 显存 KVCache
发布于 2026-11-10
1

我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。

扫码阅读
手机扫码阅读

文章主旨:

文章认为,KV Cache 是 Transformer 自回归推理中的关键性能变量:它以显存换速度,避免重复计算历史 token 的 K、V,从而显著降低长序列生成延迟,但也带来显存线性膨胀和批量吞吐压力。

关键要点:

  1. 注意力机制中,每层 Attention 将 token 投影为 Q、K、V,并用注意力公式计算关注权重;自回归生成时,每生成一个新 token 都可能重算前序 token 的 K、V,导致计算量随序列长度呈平方级增长。
  2. KV Cache 将已计算好的 K、V 缓存并复用,生成新 token 时只计算新的 K、V 并追加到缓存,再用新 Q 与完整 K、V 缓存做注意力,使每步计算量近似从 O(n²) 降到 O(n)。
  3. KV Cache 的本质是以空间换时间,代价是显存占用随序列长度线性增长。原文以 Llama-3 70B 估算:每 token 的 KV 大小约 320 KB,4096 序列约 1.28 GB/请求,8 个并发请求超过 10 GB,进而限制批量大小与吞吐。
  4. 工业界的优化路径包括:GQA 减少 KV 头数、量化降低 KV Cache 精度、offloading 将不活跃缓存卸到 CPU 内存或 NVMe SSD,以及 vLLM 的 PagedAttention 通过分页管理减少显存碎片并提升批量推理吞吐。
  5. 作者判断:KV Cache 是理解大模型推理性能的一把钥匙;工程上的“加速”不是免费的,本质是资源置换和更精细地算账;开放问题是上下文窗口继续扩张时,现有手段是否还能压低存储开销,还是需要根本上不同的记忆机制。

内容结构:

1. 注意力机制在做什么

每一层 Attention 会把输入的 token 序列投影成 Query、Key、Value 三个矩阵,再计算每个 token 对其他 token 的关注程度。原文用“图书馆检索系统”类比:Q 是检索请求,K 是索引标签,V 是实际内容;匹配得越好,就从对应的 V 中取更多内容。该过程对模型理解上下文至关重要。

2. 自回归生成的隐藏代价

大语言模型采用自回归方式,每次只生成一个 token,并把它拼到序列末尾再生成下一个。若无缓存,生成第 n 个 token 时需要重新计算前 n-1 个 token 的 K 和 V;生成下一个 token 时又重算一遍,造成大量重复矩阵乘法,计算量随序列长度平方级增长,长文本推理会越来越慢。

3. KV Cache 做了一件很直接的事

KV Cache 把已经计算好的 K、V 矩阵缓存起来,下次生成新 token 时直接复用。生成第 n 个 token 时,只需计算第 n 个 token 对应的 K_n 和 V_n,将其追加到已有缓存,再用新的 Q 与完整 K、V 缓存做注意力计算。原文用“保留草稿纸”类比:无缓存是把草稿纸扔掉重新推导,有缓存是保留下来直接翻看。

4. 真正的工程代价与优化路径

KV Cache 的本质是以空间换时间,需要把每一层、每个注意力头的 K 和 V 矩阵留在 GPU 显存中。原文估算 Llama-3 70B 时给出:80 层、8 个 KV 头、每个头 128 维,每个 token 的 KV 大小约 320 KB;序列长度 4096 时约 1.28 GB/请求;8 个并发请求同时持有 KV Cache 就是 10 GB 多,序列再长会打满显存。

原文对比了有无 KV Cache 的差异:无缓存时,长序列推理延迟随序列平方增长,显存占用低,但每步要重算全部 K、V;有缓存时,延迟基本线性,显存占用高且随序列线性增长,每步只计算新 token。工业界为控制显存开销探索了多条路径:GQA 让多个 Query 头共享一组 K、V,把 KV 头数从 32 压到 8,显存占用约降 4 倍且效果损失极小;量化把 KV Cache 从 FP16 压到 INT8 甚至 INT4,降低显存但有轻微精度下降;offloading 把不活跃的 KV Cache 卸到 CPU 内存甚至 NVMe SSD,长上下文场景可救急,但会受 PCIe 带宽和延迟控制制约;vLLM 的 PagedAttention 借鉴操作系统虚拟内存分页思想,把 KV Cache 切成固定大小的“页”管理,避免显存碎片化并提升批量推理吞吐,已成为多数推理框架的标配。

5. 作者判断与开放问题

作者认为,不理解 KV Cache 就很难真正看懂为什么某些模型在长上下文下掉速严重,也很难判断推理框架的优化思路是否言之有物。同时,工程上的“加速”从来不是免费的,KV Cache 用显存换速度,后续优化本质上是在不同资源之间做更精细的置换。文章最后提出开放问题:如果上下文窗口继续扩张,KV Cache 的存储开销还能靠现有手段压下去吗,还是需要一种根本上不同的记忆机制。

文章总结:

全文以 KV Cache 为线索解释大模型推理性能的收益与代价,调性偏工程分析:应将其视为显存与速度之间的资源置换问题,并继续关注长上下文下的记忆机制演进。

猿圈奇妙屋

C站博客专家,掘金年度人气作者Top40,华为云十佳博主,掘金/InfoQ/华为云等平台优质创作者;全网粉丝合计20w+;硬核公众号「猿圈奇妙屋」,欢迎你的加入,免费白嫖最新BAT互联网公司面试真题、4000G电子书籍、简历模板等海量资料。

97 篇文章
浏览 143.2K

还在用多套工具管项目?

一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。

加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线