vLLM：PagedAttention 与 continuous batching
推理瓶颈分两段：prefill 算力密集、decode 带宽密集。PagedAttention 把 KV Cache 按页管理，消灭预分配造成的显存碎片；continuous batching 让请求在 decode 的每一步进出批次，不等最长的那条。chunked prefill 把长 prefill 切片混进 decode 步，平衡两段。
也叫：vLLM · PagedAttention · continuous batching · chunked prefill · 推理引擎 · 吞吐与延迟
三、PagedAttention 与 continuous batching 各解决什么出自 T6-1
这两件事常被混为一谈，其实解决的是两个不同的浪费。
continuous batching 解决"等"的浪费。
static batching（旧） req A ████████████░░░░░░░░ ← 早就完事了，但坑位不释放 req B ████░░░░░░░░░░░░░░░░ req C ████████████████████ ← 全车人等它 新请求 ......................（只能等下一批） continuous batching（现在） req A ████████████→ 走人，坑位立刻给 D req B ████→ 走人，坑位立刻给 E req C ████████████████████ req D ████████████ req E ████████
源头是 Orca（OSDI 2022），机制是迭代级调度 + 选择性批处理。Anyscale 那篇经典测评给的是相对朴素 static batching 约 8 倍吞吐，但有个必须说出来的条件：增益只在输出长度方差大时成立——如果所有请求输出长度都差不多，static batching 本来也没浪费多少。
PagedAttention 解决"占"的浪费。 论文（SOSP 2023）测出当时系统里真正存住 token 状态的显存只占 20.4%–38.2%，其余是三类浪费：为未来生成预留的槽位、按最大长度分配的内部碎片、分配器造成的外部碎片。分页后官方博客的说法是浪费降到"低于 4%"。
报倍数之前必须先问"跟谁比"，这是这道题最有效的过滤器：
| 对比对象 | 倍数 |
|---|---|
| vs 裸 HuggingFace Transformers | 最高 24× |
| vs HuggingFace TGI（已有 continuous batching） | 最高 3.5× |
| vs Orca（论文正文） | 1.7–2.7× |
张口就是"vLLM 快 24 倍"的人，等于承认自己没看过论文正文。
一个 2026 年的反转（截至 2026-08）。 vLLM 在 v0.25.0（2026-07-11）的 release notes 里写着「PagedAttention has been removed」——那份 V0 时代手写的 paged_attention_*.cu 内核确实被删了，因为 FlashAttention / FlashInfer 生态里的 paged 变体更快。但分块 KV 管理机制完全健在（block_pool、kv_cache_manager、block_table 全都在），只是改由上游注意力库消费 block table。准确的说法是：概念赢了并成为行业地基，那份专用内核输给了上游生态。 说"vLLM 不用 PagedAttention 了"是错的。
以上节选自T6-1 推理服务：自建还是调 API，以及 KV Cache 这本账，读全文能看到前后语境。