从内存分页理解 vLLM 的显存管理

高并发部署 LLM，卡住服务的未必是算力，也可能是 KV Cache 把显存占满了。原文介绍的 vLLM 突破，是把操作系统的虚拟内存分页思路搬到推理服务中：按需分配缓存，让物理上不连续的显存也能高效参与注意力计算。

这篇值得读的地方，是它解释了一个工程问题：模型不变，为什么调整缓存管理就能容纳更多并发请求？不过，文中几组醒目的收益数字缺少测试条件，理解机制和接受结论，需要分开看。

为什么还没生成多少内容，显存就被占住了

LLM 自回归生成时，每次接着已有内容生成下一个 token。为了避免反复计算历史 token 的 Key、Value，服务会把它们保存为 KV Cache。请求越长、同时处理的请求越多，这部分缓存就越大。

原文认为，在高吞吐服务中，GPU 高带宽显存（VRAM）往往比浮点算力（FLOPs）更先成为瓶颈。它将传统分配方式的问题归结为：不知道请求何时输出 <EOS> 停止标记，只好提前预留一段连续空间，例如按最大长度 2,048 或 4,096 tokens 分配。

这里有两种浪费：

• 内部碎片：为一个请求预留 2,048 tokens，实际生成到 150 tokens 就结束，剩余 1,898 个位置仍被占着。
• 外部碎片：请求不断进入和结束，显存里留下零散空洞。空闲容量加起来可能够用，却找不到足够大的连续区域接纳新请求。

前者是「领了用不完」，后者是「剩下的拼不起来」。两者都会限制可同时处理的请求数量。

原文称，2023 年 PagedAttention 出现之前，HuggingFace 和文中所谓「v1 inference engines」等传统系统浪费了 60% 至 80% 的 GPU 显存。但它没有明确引擎版本、显存统计口径和测试负载，这个范围不能直接套到所有部署上。

分页怎样让零散显存也能算注意力

PagedAttention 借用了约 50 年前的操作系统思路：程序看到的连续地址，不必对应物理上连续的存储。

具体到 KV Cache，它做了三件事：

• 把缓存切成固定大小的物理块，原文举例为每块 16 tokens。
• 用块表（Block Table）记录逻辑 token 位置与物理显存块的映射，作用类似操作系统页表。
• 随着 token 生成逐块分配空间，不必一开始就占满最大请求长度。

逻辑顺序保持连续，物理存储可以分散。

关键不只是多了一张映射表。计算新 token 的注意力时，定制 CUDA kernel 要查询块表，再从不连续的地址读取 Key、Value。内存管理方式和计算内核必须一起配合，普通连续内存内核不会自动获得这种能力。

分页也没有让碎片完全消失。固定大小的块仍可能没被填满，但浪费被限制在更小的分配单位内。

原文还介绍了写时复制（Copy-on-Write，COW）。同一个 prompt 需要并行采样多个答案，或者执行束搜索（beam search）时，各分支可以共享 prompt 对应的物理 KV 块；分支生成各自内容时，再分配私有块。

共享的是相同前缀的缓存，不是不同答案的后续状态。原文没有展开部分填满的共享块如何处理，也没有给出相关实现代码。

我的判断

这篇最有价值的判断是：推理服务的容量问题，值得先从缓存分配和复用方式排查。它展示了系统工程如何改善模型服务，而不需要修改模型本身。

但「标准自注意力要求物理连续存储」说得过满。结合文章后面的方案，更准确的理解是：文中讨论的传统实现依赖连续布局来方便 CUDA kernel 高效执行，连续布局不是注意力算法不可改变的前提。

收益数字也要保留条件。原文称，显存浪费可从 80% 降至不足 4%，活跃批次规模可扩大到 2 倍或 4 倍，却没有提供硬件、模型、序列长度、对照引擎和测量方法。这些是文章报告的效果，不能当成一般团队的性能承诺；批次变大，也不能直接推导出单个请求响应更快。

相较于预留最大长度的连续空间，分页的优势在于按需分配和减少碎片；涉及共享 prompt 时，还能减少重复缓存。但文章没有量化块表查询和非连续访问的开销，尚不足以完整比较两种实现的成本。

能拿来做什么

• 如果你维护 Node 接入层背后的自部署 LLM 服务，遇到显存满、并发上不去时，可以先检查 KV Cache 的分配方式，以及最大请求长度是否造成大量预留。
• 如果业务会为同一个 prompt 生成多个候选答案，可以核实推理引擎是否支持前缀 KV 块共享和 COW，而不是默认每个分支都要复制整份缓存。
• 评估 vLLM 时，用自己的输入长度、输出长度和并发请求验证效果，同时观察吞吐、响应延迟与显存占用；原文的 2 倍或 4 倍适合作为待验证的收益，不能直接写进容量预算。