第 2 章 — KV Cache 的挑战

发布于: 2026-04-24 最后更新于: 2026-07-08 版本: 1
第 2 章 — KV Cache 的挑战

第 2 章 — KV Cache 的挑战

LLM Primer VI: Scaling AI Systems》章节走读的第二篇。这一章要说的是:在权重来得及吃光你显存之前,先把每一个 serving 系统的显存吃光的,是另一个数据结构。


这一章为什么存在

第 1 章那个自回归循环,靠"记住"来避免二次方级的重复计算。每一次 decoding 步,模型都要 attend 到之前的每一个 token;如果每次都从头做,那等于每一步都把整个 prefill 重新跑一遍 —— 一段回答的长度,就是这个倍数。KV cache 是把这段算术省下来的那个工作区。它存下每一层里每一个 token 的 K 和 V 投影,让后面的 token 只算自己的 K、V,把前面的读回来。这个 cache 是 decoding 保持在大约 O(N) 而不是 O(N²) 的原因。它同时,在我看过的每一个生产系统里,都是 VRAM 的最大单一消费者。第 2 章走的是决定它大小的那道公式、那些能把它缩小的架构变体、以及一种朴素分配方式所带来的碎片化问题。

一句话:KV cache 是拿算术换内存,而这份内存的大小同时随 batch、序列长度、层数、head 数、每 head 维度一起放大 —— 这也是为什么 serving 集群总是先耗尽 VRAM,而不是先耗尽别的什么。

2.1 决定 cache 大小的那道公式

单条序列的 KV 内存是 2 × L × H_kv × D × S × bytes:两份张量(K 和 V)、L 层、H_kv 个 key/value head、每 head 维度 D、序列长度 S、每元素的字节数。乘上 batch 就是整个 fleet 的数字。每一个轴都是乘法关系。Llama-3-70B,L=80、H_kv=8(GQA)、D=128,S=8,192、BF16,单条序列的 cache 大约 40 GB —— 还没算 batch。batch 32 时,cache 单项就接近 1.3 TB,是权重本身的好几倍,也是一块 H100 的 VRAM 的好几倍。Llama-2-70B —— 最后一个主流的 MHA 模型 —— 的 H_kv 是 64 而不是 8,同样配置下 cache 大 8 倍。这道公式不是花边知识;是它决定了一块芯片能装下多少并发用户。box 上其他每一份内存预算 —— 激活值、框架开销、临时 buffer —— 都得围着它挤。

2.2 MHA、GQA、MQA 是关于 cache 大小的架构决策

H_kv 是现代架构一直在往下压的那个项。多头注意力(MHA)每个 query head 都配一份 K、V head;cache 胖,质量最好,每个 head 可以特化各自的关注模式。多查询注意力(MQA)塌成一份共享的 K、V head;cache 缩小 H 倍,但 head 失去特化,长 context 上可测量的质量会掉。分组查询注意力(GQA),2023 年提出、目前 Llama-3、Mistral、Mixtral、Qwen、DeepSeek 的默认选项,把 query head 分成 G 个组共享 K、V;一个典型的 G = H/8 能把 cache 缩到八分之一,而质量代价小到评估集合基本抓不到。GQA 不是零成本 —— 它顺带减少了 K/V 投影的参数数,那份预算被重新分配到模型别处 —— 但经验上这份重分配基本不伤模型。MLA(multi-latent attention,DeepSeek-V2)靠低秩潜变量 cache 再往前走了一步;那是研究方向,但 2026 年生产部署里 GQA 仍然占主导。

2.3 朴素分配方式浪费掉大部分预算

最直接的 KV 分配方式 —— 每条序列预留一块连续的板,按最大可能长度分配 —— 一碰到真实流量就崩。多数请求远远短于最大长度;预留的尾巴就是死内存。Llama-3-70B 上限 32K 时,一段 1,000 token 的回答浪费掉 31 板 KV。batch 32、上限 8K、平均长度 800 时,任何时刻大约 90% 的预留 KV cache 都是闲置的。更糟的是布局是死的:新到的请求没办法用另一条序列的尾巴,因为那条尾巴已经占住了。并发能到多少,取决于最坏情况的预算,而不是平均流量能撑起的水平。问题就是内部碎片化 —— 操作系统在 1960 年代靠分页解决过的同一个失败模式。第 8 章会讲 PagedAttention 怎么把这套解决方案搬过来。

值得记住:KV cache —— 而不是权重 —— 是 serving 集群并发触顶的原因。任何能缩小它的技术(GQA、MLA、量化 KV、滑动窗口、分页)按它换回的内存,同比换回并发。

第 2 章为下面铺了什么

这道 cache 公式和它的几个轴,后面每次要推理"一块 GPU 能装几个用户"时都会浮上来。第 3 章用它解释"为什么挑 serving GPU 时 VRAM 容量比 FLOPs 更重要"。第 7 章用它解释"为什么 continuous batching 的上限是 KV cache 而不是模型"。第 8 章用它去为 PagedAttention、H2O 淘汰、前缀缓存这三个技术辩护 —— 这三个技术的全部目的都是让 cache 表现得更像分页虚拟内存,少像一大板预留字节。这道公式是后面所有内存论证的语法。


下一章 — 第 3 章:面向生成式 AI 的数据中心 GPU那块既要装下权重又要装下 KV cache 的硅片,靠机制而不是靠规格表来读。

想看完整的全貌?书里这一章包括 KV 公式的完整推导、带 cache 的解码步伪代码、Llama-3-70B 在 S=8,192、batch 32 时的一份具体数值例子,以及把 MHA、GQA、MQA 比作三种档案柜策略的那份 In Plain English 边栏。在 Amazon 上查看 LLM Primer VI →

下田 昌平
下田 昌平
作为株式会社Receipt Roller的CEO兼CTO,目前负责开发电子收据服务以及自动将对话分类并生成行动任务的系统「ACTIONBRIDGE」。从小便接触编程,1996年参与开发测量仪器的相关程序,始终保持着对技术的深刻探索与热情。 在此前的职业生涯中,曾担任日本最大呼叫中心行业企业的子公司——一家研究开发公司的CEO/CTO,领导了多个技术开发项目。目前,我依然活跃在编程的最前沿,持续书写代码。