vLLM 为什么快？PagedAttention、continuous batching 解决什么？

vLLM 快主要靠两个机制。

PagedAttention 借鉴了操作系统的虚拟内存分页。传统实现会给每条请求预留一整块连续显存，而且要按"它最多可能生成多长"来预留，导致大量显存被浪费掉。PagedAttention 把 KV Cache 切成固定大小的 block 按需分配，还能让共享前缀的请求指向同一批 block，大幅提高了显存利用率。显存省下来了，就能放更多并发请求，吞吐自然上去了。

continuous batching（连续批处理）解决的是批处理的等待问题。传统的静态批处理要等一整批请求全部生成完才能开始下一批，先完成的请求会白白占着坑位；连续批处理把调度粒度降到每一次迭代，谁生成完谁就退出，空出的位置立刻给新请求。

论文里说这两个优化加起来能带来最高 24 倍的吞吐提升。

为什么只有 60 分：机制描述是对的，比方也用对了，但有三个明显短板——一是报了 24 倍却没说跟谁比；二是没提这两个优化各自的适用边界（continuous batching 在输出长度整齐的负载上几乎没收益）；三是知识停在 2023 年的论文，完全没有 2026 的现状。

我会先把它拆成两种不同的浪费，因为这两个机制解决的根本不是同一件事。

continuous batching 消灭的是"等"的浪费。 静态批处理像跟团游，一车人得等最慢的那位逛完才能一起走；连续批处理像急诊分诊，谁看完谁走，坑位立刻给下一个。它的源头是 Orca 那篇论文，机制是把调度粒度从"一次请求"降到"一次迭代"，再配上选择性批处理绕开序列长度不齐的问题。

但这里有个必须说出来的条件：它的收益完全取决于输出长度的方差。经典测评里那个"约 8 倍"是在输出长度上限从 32 到 1536 的极端方差下测出来的；如果你的场景里所有请求输出长度都差不多（比如固定格式的分类任务），静态批处理本来也没浪费多少，换成连续批处理提升有限。

PagedAttention 消灭的是"占"的浪费。 论文测出当时的系统里真正存住 token 状态的显存只占 20% 到 38%，剩下的是三类：为未来生成预留的槽位、按最大长度分配的内部碎片、分配器造成的外部碎片。分页之后官方的说法是浪费降到 4% 以下。

报倍数之前一定要问"跟谁比"，这是这道题最容易翻车的地方：跟裸 HuggingFace Transformers 比是最高 24 倍——但对方连 continuous batching 都没有；跟已经有 continuous batching 的 TGI 比是 3.5 倍；论文正文里跟 Orca 比只有 1.7 到 2.7 倍。能主动拆开"内存管理贡献了多少、批处理贡献了多少"，比背住任何一个数字都值钱。

然后是 2026 的现状，这部分我觉得更重要。 这两个机制早就不是"优化项"了，是所有主流引擎的地基——vLLM、SGLang、TensorRT-LLM 三家都有。现在真正在动的是后面这几层：

• chunked prefill：长 prompt 的预填充是个高延迟大算子，会插队打断正在解码的请求，造成尾延迟尖峰。切成固定大小的块跟解码请求混批，正好利用了"预填充卡算力、解码卡带宽"的互补性。代价是单请求的首字延迟会变长，max_num_batched_tokens 是个真实的跷跷板：调小首字延迟差、吐字间隔好，调大反过来。
• 前缀缓存：现在是默认开启的，因为命中率为 0 时吞吐损失也小于 1%。但分布式下真正的杀手是路由——负载均衡器把同前缀的请求打散到不同实例，缓存局部性就没了。
• 投机解码：官方说得很明确，它只在中低 QPS、内存带宽受限的负载下有效。高 QPS 下解码已经变成卡算力了，多出来的验证开销就是纯亏。
• 预填充与解码分离：这里有个必须记住的官方原话——它不提升吞吐。它买的是"首字延迟和吐字间隔可以独立调、尾延迟可控"，卖的是 KV 跨实例传输带宽、额外一跳、两池资源利用率下降。而且 vLLM 内建的这块至今标着 experimental，真正生产化的是集群编排那一层。

还有一个反转值得一提（截至 2026-08）：vLLM 在今年 7 月的一个版本里把自己那份 PagedAttention 的 CUDA 内核删掉了，因为 FlashAttention/FlashInfer 生态里的分页变体更快。但分块 KV 管理机制完全健在——block pool、KV cache manager、block table 全都在，只是改由上游注意力库消费 block table。准确的说法是：概念赢了并成了行业地基，那份专用内核输给了上游生态。 说"vLLM 不用 PagedAttention 了"是错的。