第 2 章 KV Cache 的内存困境
第 2 章 · KV Cache 的内存困境
章节摘要：本章的追因线只有一段：显存去哪了。我们先回答"自回归生成为什么绕不开 KV Cache"，再把它的大小公式逐项算给你看，最后拆解传统预留式分配造成的三重浪费——预留浪费、内部碎片与外部碎片。读完本章，你会明白为什么利用率长期徘徊在三成上下，以及为什么这个数字是第 3 章 PagedAttention 全部设计的靶子。
一条主线
继续第 1 章的主线场景：复盘会上，运维报出一个数字——一张 80 GB 的卡，模型权重占掉 16 GB，日志显示 KV Cache 相关显存分配了 50 GB，可同时在线的请求只有十几条，按第 1.2 节的公式粗算，十几条请求真实占用的 KV Cache 也就几个 GB。分配了五十个 GB，真实用了几个 GB——中间那四十多个 GB 的缺口就是本章要追的赃物。
追查按两步走：第一步搞清楚 KV Cache 是什么、为什么每条请求都必须有它（2.1）；第二步把显存账本摊开，区分"必要的开销"与"浪费的开销"（2.2）。两步走完，缺口的三笔去向就都现形了：为了"最坏情况"整块预留的浪费、块内用不满的内部碎片、块与块之间错位造成的外部碎片。
这一章不引入任何新工具——它只负责把问题钉死。你会看到，传统推理框架的困境是结构性的：只要 KV Cache 还按"连续、整块、预留"的方式管理，浪费就无法避免。理解了这一点，第 3 章引入块表时你几乎可以自己推导出那个设计。
沿途站点
- 2.1 为什么绕不开 KV Cache：从注意力机制的计算依赖讲起，弄明白"用空间换时间"这笔交易的原文——不缓存，每一步都要重算全部历史的键值，代价是计算量随序列长度平方增长；缓存了，显存占用随序列长度线性增长。这笔交易没有退出选项，只能优化管理方式。
- 2.2 显存账本与三重浪费：把 KV Cache 公式逐项过一遍（层数、KV 头数、head_dim、字节数、序列长度、批大小），算出几组有体感的数字；再拆解预留式分配下的三重浪费，解释"利用率三成"的由来。
拐点与结论
本章的拐点是视角转换：显存问题的本质不是"不够大"，而是"管得差"。容量焦虑的第一反应是换更大的卡，但算完账你会发现：80 GB 的卡真实利用率只有三成，问题不在容量，而在管理方式让六七成容量变成了"看得见摸不着"的死库存。
结论同样清晰：三重浪费中，预留浪费与内部碎片源于"按最大值分配"的思维定式，外部碎片源于"必须连续"的内存布局约束。要同时消灭三笔浪费，必须同时换掉这个思维定式与这个布局约束——按需分配小颗粒、允许物理上不连续。这正是操作系统虚拟内存用页表解决的问题，也是第 3 章 PagedAttention 的全部出发点。
读完你应该
- 向没有算法背景的同事解释清楚 KV Cache 缓存的是什么、为什么 decode 每步都离不开它；
- 默写出 KV Cache 显存公式，并代入任意模型配置手算单条请求的占用；
- 区分 GQA/MQA 对公式里哪一项做了削减，并解释为什么新模型都采用它；
- 说出三重浪费的定义、成因与大致量级；
- 拿到一张卡的显存分布日志，判断"死库存"占比有多严重；
- 用一句话向老板解释"为什么不必急着买更大的卡"：先算利用率，再谈扩容。
下一章的接力
账算清了，赃物定位了，接下来是追赃。第 3 章我们把操作系统课程请回现场：PagedAttention 如何把 KV Cache 切成 16 token 一块的"内存页"，用块表记录逻辑到物理的映射，把三笔浪费一并清空——并把利用率从三成抬到九成附近。