第 3 章 PagedAttention：向操作系统借来的答案
第 3 章 · PagedAttention：向操作系统借来的答案
章节摘要：本章的主线是把第 2 章钉死的病灶治好：取消"连续"与"按峰值预留"两条假设。我们先看块表怎么把 KV Cache 切成 16 token 一块、用逻辑到物理的映射换取按需分配的自由（3.1）；再看写时复制与前缀共享如何让相同开头只存一份（3.2）。读完本章，"显存利用率从三成到九成"不再是一句口号，而是一组可以推演的设计决策。
一条主线
接着第 2 章的账本走。账算清了：三笔浪费共享同一个病根——KV Cache 被当成"连续的、一次性给足的大数组"。治疗思路于是有两条硬要求：分配粒度要小（按真实增长付款，不按最坏情况付款）；物理布局要自由（零散空位也能用起来）。
有意思的是，这对要求在计算机科学里早有标准答案。上世纪六十年代，操作系统用虚拟内存解决了几乎一模一样的问题：进程要的地址空间可以很大且看似连续，物理内存却被切成固定大小的页帧，按需映射，页表负责逻辑地址到物理地址的翻译。vLLM 的 PagedAttention 做的事情如出一辙：把每条请求的 KV Cache 视为一张逻辑页序列，物理显存切成 16 token 一块的页块，块表负责映射。
本章沿主线的两站：3.1 讲块表本身——结构怎么组织、分配与回收怎么做、注意力算子怎么在非连续内存上算；3.2 讲块表带来的两个红利——写时复制让"共享后分叉"不花冤枉钱，前缀共享让相同开头只存一份。这一章是全册的技术枢纽：后面第 4 章的并发能力、第 5 章的前缀缓存，都踩在这枚齿轮上。
沿途站点
- 3.1 块表怎么切 KV Cache：从页块的物理结构讲到块表的数据组织，再到一次 decode 里的取数过程；算清 16 这个数字的取舍——块太大回到内部碎片老路，块太小管理开销失控。
- 3.2 写时复制与前缀共享：多条请求共享同一块物理页，读共享、写复制；系统提示词、few-shot 示例、多轮对话历史因此只算一遍、只存一份。
拐点与结论
本章的拐点在于约束的解除不是免费的，而是被算子层消化掉的。逻辑上连续、物理上零散，意味着注意力计算不能再假设 KV 是一整块连续张量——PagedAttention 的算子按块表逐块取数、在块内做注意力、把各块结果拼接，把间接寻址的开销压到可忽略。这是工程上"设计范式"与"内核实现"互相成就的典型：没有块表，算子无从优化；没有配套算子，块表只是漂亮的纸面设计。
结论可以量化：论文与传统系统对比，显存利用率从两到四成提升到九成附近，同等算力下并发能力翻数倍——第 1 章主线场景里"分配五十 GB、实用几个 GB"的缺口，到这里基本填平。
读完你应该
- 画出一条请求的块表结构：逻辑块序列、物理块号、块内填充位置；
- 解释为什么块大小选 16 token，而不是 1 token 或 256 token；
- 描述写时复制的触发时机，以及它为什么不会破坏生成结果的正确性；
- 算一笔账：给定时 长 分布的前缀雷同率，估算前缀共享能省多少显存；
- 说清楚 PagedAttention 与操作系统虚拟内存的对应关系及不同之处（缺页在推理里对应什么）；
- 理解为什么"利用率九成"直接转化为"并发翻数倍"。
下一章的接力
显存管好了，卡上第一次有了富余：能同时伺候的请求多了一个数量级。但资源多了，组织不好照样浪费——请求怎么进批、什么时候调度、批满了牺牲谁，是第 4 章连续批处理要回答的问题。