vAttention：无 PagedAttention 的 LLM 服务动态显存管理

• 生命周期：推理服务（单实例显存管理）
• 部署形态：vLLM 框架内集成 + CUDA VMM 按需物理页
• 目标硬件：NVIDIA A100 80GB（1–2 张、TP-2）/ H100（可移植，第 15 页）
• 核心资源：KV cache 虚拟连续性 · 物理页分配粒度 · CUDA VMM API 延迟
• 证据状态：P/R 主导 + 3 条编辑推断（I）；外部工件仅官方仓库（E）

一句话判断

对「长上下文、prefill 占比高、注意力内核迭代快、A100/H100 自托管」的 LLM 服务，vAttention 用 CUDA 虚拟内存管理（VMM）把 KV cache 做成虚拟地址连续、物理页按需分配：在保留 PagedAttention 级碎片控制的同时，免掉分页注意力内核改写与 Block-Table 维护。论文口径下：端到端吞吐较分页内核（FlashAttention-2 / FlashInfer）最高 1.23×，decode 吞吐较 vLLM 最高 1.99×，在线服务中位请求延迟最高降 42%，FlashAttention-3 这类无分页支持的新内核零改造接入并带来 1.26–1.5× 提升；代价是 CUDA 12.1 / PyTorch 2.3.0 / 修改版 NVIDIA 驱动的供应链绑定、VMM 调用延迟需要专门隐藏（每页组增长约 5 毫秒量级），以及「已完成请求的物理页直接交给新请求复用」带来的租户隔离新议题。全部数字为论文条件性结果，禁止跨论文横比。P R I（代价与适用面判断为编辑观点）

3 分钟速读

1. 问题：PagedAttention 用「用户态分页」解决 KV cache 碎片，代价是 KV 在虚拟地址上不再连续——注意力内核必须改写为按块寻址、框架要维护 Block-Table、CPU/GPU 关键路径都有开销。论文 Table 1（第 1 页）汇集证据：vLLM 分页 decode 内核比 FlashAttention-2 慢至 2.8×；块大小改变可使执行时间变化至 1.9×；FlashAttention-2 / FlashInfer 分页 prefill 内核分别慢至 37% / 42%。P
2. 机制：用 CUDA VMM API 解耦虚拟与物理内存——预先预留大段虚拟连续地址空间，物理页运行时按需映射；默认页大小 2MB，修改开源 NVIDIA 驱动后另支持 64KB 页（第 1–2 页）。P
3. 隐藏代价：VMM 调用走内核往返、延迟不低（第 6 页 Table 3：cuMemSetAccess 38µs 等）；vAttention 在 step 中于迭代开始前完成物理页映射（第 6 页），decode 期把映射与计算重叠、prefill 期延迟回收 + 急切分配（第 8 页）——给 Yi-34B 的 KV 增长一个页组约需 120 次 API 调用 ≈ 5 毫秒，必须移出关键路径。P
4. 结果：端到端吞吐较 FA2/FlashInfer 分页内核至 1.23×（第 1 页）；decode 较 vLLM 至 1.99×/1.58×/1.53×（Yi-6B/Llama-3-8B/Yi-34B，第 9–11 页）；在线中位延迟降 42%/28%/29%（第 11 页）；FA3 在 H100 上开箱即用、较分页 FA2 提升 1.26–1.5×（第 2 页；H100 可移植性第 15 页）。P R
5. 边界：decode 场景 vAttention 只是「与最优分页内核持平」（decode 是内存受限、分页开销可被掩盖）；收益随上下文长度与 P:D 比增大；64KB 页需修改驱动（供应链负担）；官方工件仓库为 github.com/microsoft/vattention（附录第 18–19 页锚定），本页不提供任何其他外部链接。P E I

论文声称的主要结果

术语与记号

CUDA VMM

CUDA 虚拟内存管理 API 族（cuMemAddressReserve / cuMemCreate / cuMemMap / cuMemSetAccess / cuMemUnmap …），允许虚拟地址预留与物理页分配分离——vAttention 的地基（第 1、6 页）。

虚拟连续（virtual contiguity）

每个请求的 K/V cache 在虚拟地址空间中是一段连续张量，注意力内核可像静态分配一样按平坦地址直接访问（第 1 页）。

page-group / 页大小

一次 VMM 调用分配的一个或多个物理页。CUDA API 仅支持 2MB 页；vAttention 修改开源驱动后支持 64KB/128KB/256KB 页组（第 2、6 页）。

reqId / 虚拟张量

框架启动时按「最大批 × 最大上下文」预留 2×N 个虚拟张量（N 为层数）；每个请求以唯一 reqId 占据其中不重叠的子区域（正文 §5，门控外转述）。I

Block-Table

PagedAttention 体系里框架维护的「逻辑块 → 物理块」映射表，注意力内核按它寻址非连续 KV——vAttention 的虚拟连续设计免除了它（第 1 页 Table 1 论证）。

论文出处

《vAttention: Dynamic Memory Management for Serving LLMs without PagedAttention》，ASPLOS '25（DOI 10.1145/3669940.3707256，第 1 页印刷信息）；本地文件 04_vAttention_2405.04437.pdf。

问题背景

KV cache 的显存的两难：碎片 vs 连续

每个请求的 KV cache 随 decode 每迭代增长一个 token，且总长度（输出多少 token）事先未知：按模型最大上下文静态预留（如 Yi-34B-200K 的 200K）会造成严重内部碎片，压低批大小与吞吐（第 1–2 页）。P vLLM 的 PagedAttention 借鉴操作系统按需分页，把 KV cache 切成小块按需分配，近乎完美地解决了碎片，已成为 TensorRT-LLM、HuggingFace TGI、LightLLM 等系统的事实标准（第 1 页）。P

PagedAttention 的根本代价：虚拟连续性丧失

动态分配的对象不保证连续——PagedAttention 在按需分配物理内存的同时，把 KV cache 的虚拟地址布局从连续改成了非连续（第 1 页）。由此产生三类问题：P

• 内核必须改写：注意力算子要为非连续 KV 块重写寻址逻辑，跟进新内核研究的成本变高；vLLM 分页 decode 内核已比 FlashAttention-2 慢至 2.8×（第 1 页 Table 1 / Table 7 口径）。P
• 框架冗余：服务框架要自建「块表管理器」，重复操作系统本已完成的虚→实地址翻译（第 1 页 Figure 1 论证）。P
• 运行时开销：分页 prefill 内核在 FlashAttention-2 / FlashInfer 中分别慢至 37% / 42%，decode 慢至 12%；块大小选择敏感（至 1.9× 波动）；CPU 侧 Block-Table 准备在 vLLM 早期实验中曾占 decode 迭代延迟约三成、修复后仍可达一成，TensorRT-LLM 亦报告过 >10% 吞吐回退（第 1 页 Table 1；CPU 侧数字出自正文 §3.3.2 第 4 页——台账门控外，此处仅定性转述）。P I（门控外转述标注）

底层症结：预留式 GPU 分配

cudaMalloc 一类的预留式分配会把虚拟与物理内存一次性锁死——即使虚拟地址没被访问，物理页也已占用。这与操作系统的按需分页（demand paging）相反。论文主张：把虚拟与物理内存的分配分开，才能同时保住碎片控制与虚拟连续性（第 1–2 页）。P

本页使用的延迟/吞吐口径

与全站一致，跨请求延迟类指标以 TTFT/TBT 讨论为站内通识口径；但需要注意：vAttention 论文未定义 TTFT/TBT 型 SLO 数值——其在线实验以固定 QPS（泊松到达）下的「请求端到端执行延迟 CDF / 中位数」与吞吐为准（第 11 页）。两套口径不可混用。P I

核心机制

1 · 虚拟连续 + 物理按需：一对分离的分配策略（第 1 页，台账 P1）

vAttention 为 KV cache 预先预留一段大的虚拟连续缓冲（像 PagedAttention 之前的系统），而把物理内存的分配推迟到运行时按需进行（像 PagedAttention）。虚拟地址的浪费无所谓——现代 64 位系统的进程虚拟地址空间极其充裕；物理页则只在 KV 真正增长时才映射进去。由此物理内存不碎片化，虚拟地址保持连续，未修改的注意力内核开箱即用（第 1–2 页）。P

2 · CUDA VMM API 与页大小（第 2、6 页，台账 P2/P3）

解耦依赖 CUDA VMM：cuMemAddressReserve 预留虚拟段、cuMemCreate 分配物理句柄、cuMemMap + cuMemSetAccess 把物理页映射进虚拟段并授权访问、cuMemUnmap / cuMemRelease 逆向回收。CUDA 原生只支持 2MB 大页——直接用会产生内部碎片；vAttention 修改开源的 NVIDIA 统一虚拟内存驱动，新增支持 64KB（以及 128KB/256KB）页组的自定义 vMem API 族；评测未发现 64KB 页拖慢注意力内核，即没有 TLB 抖动证据（第 2 页）。两套 API 的实测延迟见 数据路径 的表 B2。P I（综合表述）

3 · 迭代前映射：step 语义（第 6 页，台账 P3）

服务框架每迭代调用一次 step（传入各请求当前上下文长度）；vAttention 保证所有活跃请求的 KV 子张量在迭代开始前已由物理页支撑，然后才把执行权交回框架派发 GPU 内核。物理页不够时返回失败，框架可抢占请求以保证前进（与 vLLM 默认行为类似）。P

4 · 把 VMM 延迟移出关键路径（第 8 页，台账 P4）

给 Yi-34B（60 层）的一个请求增长一个页组需要 120 次 cuMemMap + cuMemSetAccess、每次约 40µs——合计约 5 毫秒，绝不能同步做。两个优化：P（第 8 页）

• decode：映射与计算重叠。decode 每迭代每请求只产出 1 个 token，下一迭代是否需要新页组是可预测的——vAttention 用后台线程在上一个迭代执行期间完成下一迭代的物理页映射。P
• prefill：延迟回收 + 急切分配。请求 R1 完成后不急于收回物理页，而是把它的 reqId 连同已映射页面直接交给新请求 R2 复用（R2 上下文更长才需追加分配）；同时常备一个「预热」的空闲 reqId，新请求到达即接管，再为下一个急切预映射。仅当缓存的页组低于 GPU 显存约 10% 时才真正触发回收。P
• 推断：综合 P3+P4——内存增长被设计为「提前映射 + 计算期隐藏」，重映射不应阻塞服务主循环；这是本页的解读而非论文印刷声明。I（台账 I1）

GPU / 系统数据路径

端到端文字序列

1. ① 请求进入：客户端请求到达 vLLM API 服务器（论文实现以 vLLM 为承载框架，第 2 页）。P
2. ② 调度与 step：vLLM 调度器接纳请求；框架调用 vAttention 的 step，确保各活跃请求的 KV 空间在本迭代开始前已就绪（第 6 页）。P
3. ③ 虚拟连续预留：每个请求在虚拟地址空间中占据一段连续、对齐的 KV 区段（init 时按最大批 × 最大上下文预留，reqId 定位子区域；布局细节为正文转述）。P I（细节转述）
4. ④ CUDA VMM 映射/解除映射：映射走 cuMemCreate + cuMemMap + cuMemSetAccess，回收走 cuMemUnmap；vMem 扩展把后两步合并以支持 64KB 页组（第 6 页 Table 3）。P
5. ⑤ 物理页按需分配：只有当 KV 随 token 增长耗尽已映射页时，才映射新的 64KB 物理页——物理显存哪里有空就落哪里，与虚拟布局无关（第 1、2、6 页）。P
6. ⑥ 注意力内核直接访问：FlashAttention-2 / FlashInfer / FA3 等未修改内核把 KV 当作普通连续张量，经平坦虚拟地址由 GPU MMU 完成到散布物理页的翻译——无需 Block-Table（第 1 页；内核对照见第 9–11 页）。P R
7. ⑦ token 流式返回：采样 token 回传客户端；decode 期下一迭代所需的新页映射已由后台线程与计算重叠完成（第 8 页）。P

量级感受：给 Yi-34B（60 层 → 120 个 K/V 张量）的一个请求增长一个页组 ≈ 120 次 Map+SetAccess × 约 40µs ≈ 5 毫秒——这就是必须做重叠与延迟回收的原因（第 8 页）。P

架构权衡

云上部署映射

本节为部署映射：论文硬件事实标 P/R，云产品对应标 E（仅作厂商中立示例，参数与价格以云厂商文档为准，本站未联网核验），运维建议/推断标 I。

成本 / 性能 / SLO

SLO 与实验口径（论文定义）

容量规划变量

• 上下文长度与 P:D 比：论文明确「收益与上下文长度、prefill:decode token 比成正比」——prefill 占比越高，vAttention 相对分页内核越有利（第 11 页）；R
• 注意力内核选择：vAttention 的价值在「随时换上最快的非分页内核」——内核层的进步直接转化为服务层收益（如 FA3，第 2 页）；P
• 页组粒度：2MB 与 64KB 档分别面向延迟敏感与吞吐型负载，影响可支撑的最大批大小（第 6 页页组配置；具体批上限数字在台账门控外，本页不展开）；P I
• 分配延迟余量：VMM 分配带宽远高于 decode 期 KV 增长需求（摘要文件同口径记录），分配速度本身不构成瓶颈——瓶颈在单次页组增长的延迟隐藏。I

成本模型（参数化，非论文结论）

论文不含任何成本数据（仅吞吐/延迟）。架构师可用下式估算（I，价格项为参数）：

每百万生成 token 成本 ≈ ( p_gpu × N_GPU ) ÷ ( T_gen × (1 − φ) ) × 10⁶ …（公式 1）

• p_gpu：单卡时租价（A100/H100，按查询日云价代入，E）；
• N_GPU：实例卡数（论文口径 1–2 张起，TP-2 时为 2，R）；
• T_gen：实测生成吞吐（token/s）——内核选择、批上限、P:D 比、页组策略共同决定；可按论文相对收益作修正（如 prefill 主导负载对分页基线 ×1.13–1.23，R）；
• φ：显存浪费率（内部碎片 + 预留损耗）——2MB 档高于 64KB 档；64KB 需驱动支持。I

敏感项：负载 P:D 比升高 → T_gen 相对基线的收益放大（第 11 页 R）；页组从 2MB 换 64KB → φ 下降但映射调用增多、依赖驱动 fork（第 2、6 页 P）；换用更新内核（FA3/H100）→ T_gen 抬升 1.26–1.5×（第 2 页 P）。

安全与可运维性

论文披露范围

• 核验门控内论文未涉及安全、隐私、多租户与故障恢复议题——以下部署要点除标注论文事实外均为编辑推断。I
• 官方工件仓库：github.com/microsoft/vattention——论文内唯一锚点是附录（第 18–19 页）；仓库自身的可用性/内容属外部事实，本次未联网核验，本页亦不提供任何其他外部链接。E（台账 E1）
• 复现环境明确要求特权容器（docker --cap-add=SYS_ADMIN）与 HuggingFace 令牌（HF_TOKEN）访问 Llama-3-8B（第 19 页附录）。E

论文未披露、部署方必须自行覆盖的项

适用 / 不适用场景

适用（触发条件 → 理由）

1. 长上下文 / prefill 占比高的负载：触发条件——输入数万 token 起、P:D 比高（如摘要、文档问答、代码补全的长前缀场景）。理由——论文明确收益与上下文长度和 P:D 比正相关，实测离线吞吐较分页内核 1.13–1.23×、在线中位延迟至 −42%（第 11 页）。R
2. 注意力内核快速迭代的团队：触发条件——希望随时接入最新非分页内核（FA2 → FlashInfer → FA3）而不维护分页移植。理由——虚拟连续 KV 让未修改内核开箱即用；FA3 发布时无 PagedAttention 支持，vAttention 零内核改动接入并带来 1.26–1.5× 提升（第 1–2 页）。P
3. A100/H100 自托管、软件栈可控的服务：触发条件——能用自家镜像管理驱动与 CUDA 版本。理由——论文在 A100 上完成主要评测并验证 H100 可移植（第 9–11、15 页），硬件路线与主流云 GPU 实例族吻合。R
4. 被分页内核开销困住的 vLLM 类部署：触发条件——profile 显示 Block-Table/分页分支开销或块大小敏感性问题（至 1.9× 波动，第 1 页）。理由——同一框架内把分页内核换成「非分页内核 + vAttention」即可消除该层开销，decode 吞吐较 vLLM 内核至 1.99×（第 9–11 页）。P R

不适用（触发条件 → 理由）

1. decode 主导、短上下文负载：触发条件——输出远长于输入、上下文短（闲聊式短对话）。理由——decode 是内存受限，分页开销可被访存停顿掩盖，vAttention 仅与最优分页内核持平（第 11 页），收益有限（按论文条件反推）。R I
2. 不可修改 GPU 驱动的受管环境：触发条件——托管 K8s 节点池/托管 GPU 服务不允许替换驱动，或无驱动 fork 维护能力。理由——64KB 细粒度页依赖修改版开源驱动（第 2 页），退回 2MB 默认档则碎片与批上限受限，机制收益打折。P I
3. 硬多租户隔离 / 强合规业务：触发条件——跨租户数据严格不可见、KV 残留须可审计清除。理由——跨请求物理页复用是机制默认（第 8 页），需关闭复用或分域部署，性能前提随之改变；论文未提供隔离机制。P（机制） I（缺口判断）
4. 非 CUDA / 旧 CUDA 生态：触发条件——非 NVIDIA GPU，或驱动/CUDA 版本无法锁定在经验证组合（附录口径 CUDA 12.1，更高版本不保证可用，第 18 页）。理由——整套机制立在 CUDA VMM 与开源驱动改动之上。E I
5. 期待调度/多实例优化的团队：触发条件——诉求是过载准入、prefill/decode 分离、跨实例缓存复用。理由——vAttention 只解决单实例内 KV 显存管理，不含调度器；这类诉求应对照本站 DistServe / Sarathi-Serve / Mooncake 页。I

实验与指标

复现实验的完整条件（论文核验门控内）

关键结果（均带条件）

公平性限制与已知差异

• 全部数字为对门控页的转述；精确引用请回查 PDF 原文（摘要文件同此声明）。P I
• 基线时点：对照基于 vLLM v0.2.7（论文发表时点的「公平比较」口径，第 9 页）；当前 vLLM 及各内核库已持续演进，绝对数字不能外推到今日版本栈。R（论文口径） I（时效判断）
• 精度未明示：实验 dtype 论文未明确披露，本页不臆测；仅正文尺寸计算以 P=2（FP16/BF16）举例（第 6 页）。P
• 数字不可与 Mooncake、DistServe 等其他论文横比（硬件、负载、口径均不同；本论文亦无 TTFT/TBT SLO 口径）。I

核对 / 复现路径（附录第 18–19 页，台账 E1）

论文提供完整工件附录；以下步骤均出自附录原文（E，页码 18–19），顺序编排为编辑建议（I）：

1. 克隆官方仓库 github.com/microsoft/vattention（唯一官方来源；归档 DOI 10.5281/zenodo.14048692，本页不作链接）；
2. 环境：conda（Python 3.10）+ CUDA 12.1 + PyTorch 2.3.0；或直接用预装 Docker 镜像 rnp1910/vattention:asplos_25_pytorch_run（需 --cap-add=SYS_ADMIN 特权）；
3. huggingface-cli login 提供 HF_TOKEN 以访问 Llama-3-8B；
4. 硬件：2 张 NVLink 互联 A100 80GB、200GB 磁盘；准备约 1 小时，实验 1–2 天（Fig.2/3/11 数分钟，Fig.4/7 约 1 小时，Fig.8/9 各 12 小时以上）；
5. ./run_all.sh 或按图运行 run_figure_*.sh，输出落在 logs/ 与 plots/，图格式与论文一致但绝对数字随环境浮动。

论文 / 链接 / 延伸阅读

论文引用的关联工作（vLLM、FlashAttention、GMLake 等）仅按门控页转述；除官方仓库外本页不提供任何外部链接。上一篇：Mooncake（03）；下一篇：FlashInfer（05）；或从首页目录进入。

给架构师的决策清单

证据台账

分级（本论文台账 schema：sources/vattention.evidence.json，schema evidence-ledger/v1）：P = 论文原理/机制主张（锚定 PDF 页码/章节）；R = 论文报告的实验结果（锚定 PDF 页码）；E = 外部工件（官方仓库，论文附录仅作锚点，仓库内容未联网核验）；I = 编辑推断（显式标注不确定性，非论文印刷主张）。编号与台账文件一致（P1–P4、R1–R2、E1、I1–I3）；定位均为真实 PDF 页码。注意：本页 R 级含义为「论文实验结果」，与站内部分页面「R = 仓库声明」的用法不同，以各页台账 schema 为准。最后核验日期：2026-09-14。

数据与文件说明：本页全部性能数字与机制描述均取自论文《vAttention: Dynamic Memory Management for Serving LLMs without PagedAttention》（ASPLOS '25）已核验门控页（第 1、2、6、8、9–11、15、18–19 页），并通过 sources/vattention.summary.json 与 sources/vattention.evidence.json 逐条对应；台账 fabrication_policy 明确：不捏造任何台账之外的数字、arXiv 号、作者、出处或日期。编辑推断与部署建议已用 I 标注；本页唯一外链为官方仓库 microsoft/vattention。数据路径图 assets/diagrams/vattention-data-path.svg（含 title/desc 无障碍描述）。