揭开 NVIDIA 驱动栈的面纱GPU 显存页表与 vLLM 中的 PagedAttention 是如何在底层协同的面向资深程序员的系统级技术拆解日期2026-07-17摘要PagedAttention 常被类比为操作系统分页但它并不是直接改写 NVIDIA GPU 的硬件页表。真正发生的是两层分页机制在不同抽象层上配合NVIDIA 驱动栈和 GPU MMU负责把 CUDA 虚拟地址翻译到物理显存。vLLM PagedAttention则在已经分配好的显存之上把 KV cache 切成逻辑块用 block table 将连续的 token 序列映射到非连续的 KV block。理解这两层边界才能看清 vLLM 为什么能提高显存利用率也能避免把应用层内存调度误解成硬件页表魔法。目录问题背景LLM 推理为什么卡在显存上NVIDIA 驱动栈从 cudaMalloc 到 GPU 页表GPU 显存页表到底解决什么问题vLLM PagedAttention应用层的 KV cache 分页两层分页如何“协同”又在哪里没有协同代码视角block table 如何把逻辑 token 找到物理 KV block性能含义碎片、TLB、访存合并与调度工程实践排查和优化 vLLM 显存问题结语真正的分层理解来自边界感1. 问题背景LLM 推理为什么卡在显存上大模型推理的瓶颈并不总是算力。尤其在decode 阶段每生成一个 token都要反复读取此前所有 token 的 Key/Value cache。模型参数是静态的KV cache 却随着请求长度、batch 组成、采样策略动态增长。这带来一个很工程化的问题请求长度不可预测。显存分配喜欢规则和连续。如果每个请求都预留最大上下文长度浪费会非常惊人。如果按需扩容又会遇到碎片、搬迁、同步和调度复杂度。vLLM 的 PagedAttention 正是在这个点上切入它把每个序列的 KV cache 拆成固定大小的块让逻辑上连续的上下文 token 可以落在物理上不连续的显存块里。这个思想借鉴了操作系统分页但运行位置是在深度学习框架和 CUDA kernel 之上。关键边界GPU 硬件页表管理的是“地址到显存页”的翻译PagedAttention 管理的是“序列 token 到 KV cache block”的翻译。前者是驱动和硬件层后者是推理系统和 kernel 层。2. NVIDIA 驱动栈从 cudaMalloc 到 GPU 页表从程序员视角看cudaMalloc返回一个 device pointer。从系统视角看这个指针处在 CUDA 进程的虚拟地址空间里。NVIDIA 官方文档描述了 Unified Virtual Addressing在支持的平台上主机内存和各 GPU 全局内存位于同一个进程级虚拟地址空间不同内存区域可以通过指针属性查询其归属。在更底层CUDA Driver API 的 Virtual Memory ManagementVMM把两件事拆开保留一段 GPU 可访问的虚拟地址范围。把物理显存 allocation 映射到这段虚拟地址上并设置访问权限。这和 CPU 操作系统里的 reserve/commit 思路相似只是对象变成了 GPU 可访问的地址空间。因此NVIDIA 驱动栈扮演的是资源仲裁者和地址空间管理者它和内核驱动、GPU firmware、硬件 MMU 一起维护上下文、显存分配、页表、权限、peer access、UVA/VMM 等机制。CUDA kernel 中的指针最终要经过 GPU 侧地址翻译才能访问实际的 HBM/GDDR 显存。3. GPU 显存页表到底解决什么问题GPU 显存页表解决的是地址空间层面的基础问题地址抽象kernel 使用虚拟地址而不是直接拼物理显存地址。隔离与权限不同 CUDA context、进程、MIG/虚拟化场景需要可控访问边界。非连续物理映射一段虚拟地址可以映射到底层非连续的物理页或显存对象。跨设备访问UVA、peer access、VMM 允许更细粒度地控制哪些 GPU 能访问哪些 allocation。运行时可管理性驱动可以延迟映射、重映射、设置访问权限构建更复杂的内存分配器。但是硬件页表并不知道“这是某个用户请求的第 37 个 token 的 K 向量”。它只知道某个虚拟地址应该翻译到哪个物理显存位置。语义层面的 token、sequence、KV cache、beam、prefix sharing全部是上层推理系统赋予的含义。4. vLLM PagedAttention应用层的 KV cache 分页vLLM 的原始博客把 PagedAttention 类比为操作系统虚拟内存操作系统虚拟内存vLLM PagedAttentionProcessSequencePageKV blockVirtual page numberLogical block idPhysical framePhysical KV blockPage tableBlock table这个类比非常有启发性但要记住它是应用层类比。PagedAttention 的核心做法是把每个请求的 KV cache 划分为固定 token 数量的 KV block。一个序列在逻辑上仍然是连续上下文但它的逻辑 block 可以映射到任意物理 KV block。随着新 token 生成调度器按需分配新的 block当多个序列共享 prefix 时还可以让多个逻辑 block 指向同一个物理 block并用引用计数和 Copy-on-Write 保护写入。在 CUDA kernel 内部PagedAttention 不再假设 K/V 在一段连续的大数组中顺序排列而是通过 block table 找到每个逻辑 block 对应的physical_block_number再按照k_cache/v_cache的布局计算实际地址。维度GPU 硬件/驱动页表vLLM PagedAttention block table管理对象虚拟地址页到物理显存页或内存对象sequence 的逻辑 token block 到 KV cache 物理 block维护者NVIDIA 驱动、OS、GPU MMU/firmwarevLLM scheduler、block manager、attention kernel可见语义地址、权限、设备归属、映射粒度token、sequence、prefix、beam、引用计数访问路径GPU load/store 触发地址翻译kernel 根据 block table 显式计算 K/V 指针优化目标隔离、映射灵活性、跨设备访问、虚拟内存抽象减少 KV cache 碎片、提高 batch 容量、支持共享与按需分配5. 两层分页如何“协同”又在哪里没有协同说二者协同是因为 PagedAttention 的物理 KV block 最终仍然落在 CUDA 分配出来的 GPU 虚拟地址范围里。无论 vLLM 怎样调度 blockkernel 中对k_cache/v_cache的访问都会经过 NVIDIA 驱动栈建立的地址翻译体系。但说二者没有直接协同也同样重要。PagedAttention 不是向 GPU 页表插入“token 页表项”也不是让驱动理解 KV cache。它通常是在一个或多个 CUDA allocation 上进行应用层分块然后在 kernel 中用 block table 做显式寻址。一个更准确的执行链路是vLLM 启动时根据显存预算创建或管理 KV cache 池底层显存来自 CUDA allocator。CUDA/NVIDIA 驱动为这些 allocation 建立 GPU 可访问的虚拟地址映射。请求进入后vLLM 为序列分配逻辑 KV block并映射到可用 physical block。attention kernel 读取 block table计算k_cache/v_cache中对应 block 的指针偏移。GPU 执行 load/store 时硬件 MMU/TLB 再把这些虚拟地址翻译到真实显存位置。一句话总结PagedAttention 是“在 CUDA 虚拟内存之上实现的 KV cache 虚拟内存”它借用了 paging 的思想但没有替代 NVIDIA 的 GPU 页表。6. 代码视角block table 如何把逻辑 token 找到物理 KV block下面是一个高度简化的伪代码用来表达 PagedAttention kernel 的寻址思想。真实 vLLM 内核会考虑 head size、向量化读取、warp/thread group、shared memory、softmax 分块归约等细节。# 伪代码从逻辑 token 位置找到 KV cache 中的物理 blockBLOCK_SIZE16deflocate_kv(logical_token_idx:int,block_table:list[int]):logical_block_idlogical_token_idx//BLOCK_SIZE offset_in_blocklogical_token_idx%BLOCK_SIZE physical_block_idblock_table[logical_block_id]returnphysical_block_id,offset_in_block# sequence 的逻辑 block 是连续的0, 1, 2, 3# 但可以映射到非连续的 KV cache 物理 block7, 42, 9, 103block_table[7,42,9,103]print(locate_kv(37,block_table))# (9, 5)在 CUDA kernel 中这个映射最终会变成对k_cache/v_cache的指针偏移。vLLM 文档中给出的 Key cache 指针计算可以抽象为// 概念化表达真实代码还会包含 head、stride、向量化、线程分工等参数constscalar_t*k_ptrk_cachephysical_block_number*kv_block_stridekv_head_idx*kv_head_stridephysical_block_offset*x;注意这里的physical_block_number是 vLLM 语义下的“物理 KV block 编号”不是 NVIDIA GPU 页表里的物理页号。它仍然只是一个数组/内存池中的块索引。7. 性能含义碎片、TLB、访存合并与调度7.1 碎片控制PagedAttention 把浪费限制在序列最后一个未填满的 block。相比为每个请求预留最大长度它能显著降低 KV cache 的内部碎片让同一张 GPU 承载更多并发序列。7.2 TLB 与地址翻译从硬件角度看PagedAttention 访问的仍是k_cache/v_cache的 CUDA 虚拟地址。只要这些 allocation 映射稳定GPU MMU/TLB 会像处理普通 global memory 一样处理地址翻译。PagedAttention 的 block table 查询不会绕过或替代这个过程。7.3 访存合并PagedAttention 让逻辑上下文可以分散在不同 block但 kernel 必须尽量让相邻线程读取相邻或规则地址避免把块化带来的灵活性变成访存发散。vLLM 的 kernel 文档强调了专门的内存布局和从 global memory 到 shared memory 的读取方式。7.4 调度和 batch 容量更高的显存利用率意味着 scheduler 可以把更多请求放进同一个 batch。LLM serving 的吞吐提升往往来自“能不能塞下更多有效 token 工作”而不只是单个 attention kernel 的速度。8. 工程实践排查和优化 vLLM 显存问题在实际部署里我会按下面几个方向看问题先区分 OOM 来源模型权重、activation、KV cache、临时 workspace、CUDA graph 捕获池可能都在抢显存。关注max_model_len、gpu_memory_utilization、max_num_seqs、block size、KV cache dtype 等参数它们会直接影响 KV cache 池规模。用nvidia-smi只能看到进程级显存占用要理解 vLLM 内部碎片需要结合 vLLM 日志、block 分配统计和请求长度分布。不要把所有非连续访问都归咎于 GPU 页表。PagedAttention 的主要收益和成本都发生在应用层 block table 与 attention kernel 访问模式上。当吞吐不随 batch 增长而提升时检查是否已经进入 memory bandwidth、kernel launch、调度开销或长尾请求阻塞。示例启动参数# 示例观察 vLLM server 的显存相关配置思路python-mvllm.entrypoints.openai.api_server\--modelmeta-llama/Llama-2-7b-hf\--gpu-memory-utilization0.90\--max-model-len8192\--max-num-seqs128\--kv-cache-dtype auto# 排查时建议同时记录# 1. 请求输入/输出长度分布# 2. OOM 发生时的并发序列数# 3. prefill 与 decode 阶段耗时# 4. vLLM 日志中的 KV cache / block 相关信息9. 结语真正的分层理解来自边界感PagedAttention 之所以漂亮不是因为它神秘地操纵了 GPU 硬件页表而是因为它把操作系统分页的思想准确移植到了 LLM serving 最痛的资源KV cache。NVIDIA 驱动栈提供了可靠的 GPU 虚拟地址、显存映射、权限和跨设备访问能力vLLM 则在这个基础设施之上为 token 序列建立了自己的逻辑地址空间。两层机制互相依赖但语义边界清晰。对资深程序员来说这个案例的价值不止在于理解 vLLM。它提醒我们真正的性能优化往往不是在某一层“用力”而是在正确的抽象层放置正确的数据结构并让它和底层硬件访问路径形成稳定的契合。参考资料NVIDIA CUDA Programming Guide: Virtual Memory ManagementNVIDIA CUDA Programming Guide: Unified Virtual Address SpaceNVIDIA CUDA Driver API: Unified AddressingvLLM Docs: Paged AttentionvLLM Blog: Easy, Fast, and Cheap LLM Serving with PagedAttentionHugging Face TGI Docs: PagedAttention资料访问日期2026-07-17。
揭开 NVIDIA 驱动栈的面纱GPU 显存页表与 vLLM 中的 PagedAttention 是如何在底层协同的面向资深程序员的系统级技术拆解日期2026-07-17摘要PagedAttention 常被类比为操作系统分页但它并不是直接改写 NVIDIA GPU 的硬件页表。真正发生的是两层分页机制在不同抽象层上配合NVIDIA 驱动栈和 GPU MMU负责把 CUDA 虚拟地址翻译到物理显存。vLLM PagedAttention则在已经分配好的显存之上把 KV cache 切成逻辑块用 block table 将连续的 token 序列映射到非连续的 KV block。理解这两层边界才能看清 vLLM 为什么能提高显存利用率也能避免把应用层内存调度误解成硬件页表魔法。目录问题背景LLM 推理为什么卡在显存上NVIDIA 驱动栈从 cudaMalloc 到 GPU 页表GPU 显存页表到底解决什么问题vLLM PagedAttention应用层的 KV cache 分页两层分页如何“协同”又在哪里没有协同代码视角block table 如何把逻辑 token 找到物理 KV block性能含义碎片、TLB、访存合并与调度工程实践排查和优化 vLLM 显存问题结语真正的分层理解来自边界感1. 问题背景LLM 推理为什么卡在显存上大模型推理的瓶颈并不总是算力。尤其在decode 阶段每生成一个 token都要反复读取此前所有 token 的 Key/Value cache。模型参数是静态的KV cache 却随着请求长度、batch 组成、采样策略动态增长。这带来一个很工程化的问题请求长度不可预测。显存分配喜欢规则和连续。如果每个请求都预留最大上下文长度浪费会非常惊人。如果按需扩容又会遇到碎片、搬迁、同步和调度复杂度。vLLM 的 PagedAttention 正是在这个点上切入它把每个序列的 KV cache 拆成固定大小的块让逻辑上连续的上下文 token 可以落在物理上不连续的显存块里。这个思想借鉴了操作系统分页但运行位置是在深度学习框架和 CUDA kernel 之上。关键边界GPU 硬件页表管理的是“地址到显存页”的翻译PagedAttention 管理的是“序列 token 到 KV cache block”的翻译。前者是驱动和硬件层后者是推理系统和 kernel 层。2. NVIDIA 驱动栈从 cudaMalloc 到 GPU 页表从程序员视角看cudaMalloc返回一个 device pointer。从系统视角看这个指针处在 CUDA 进程的虚拟地址空间里。NVIDIA 官方文档描述了 Unified Virtual Addressing在支持的平台上主机内存和各 GPU 全局内存位于同一个进程级虚拟地址空间不同内存区域可以通过指针属性查询其归属。在更底层CUDA Driver API 的 Virtual Memory ManagementVMM把两件事拆开保留一段 GPU 可访问的虚拟地址范围。把物理显存 allocation 映射到这段虚拟地址上并设置访问权限。这和 CPU 操作系统里的 reserve/commit 思路相似只是对象变成了 GPU 可访问的地址空间。因此NVIDIA 驱动栈扮演的是资源仲裁者和地址空间管理者它和内核驱动、GPU firmware、硬件 MMU 一起维护上下文、显存分配、页表、权限、peer access、UVA/VMM 等机制。CUDA kernel 中的指针最终要经过 GPU 侧地址翻译才能访问实际的 HBM/GDDR 显存。3. GPU 显存页表到底解决什么问题GPU 显存页表解决的是地址空间层面的基础问题地址抽象kernel 使用虚拟地址而不是直接拼物理显存地址。隔离与权限不同 CUDA context、进程、MIG/虚拟化场景需要可控访问边界。非连续物理映射一段虚拟地址可以映射到底层非连续的物理页或显存对象。跨设备访问UVA、peer access、VMM 允许更细粒度地控制哪些 GPU 能访问哪些 allocation。运行时可管理性驱动可以延迟映射、重映射、设置访问权限构建更复杂的内存分配器。但是硬件页表并不知道“这是某个用户请求的第 37 个 token 的 K 向量”。它只知道某个虚拟地址应该翻译到哪个物理显存位置。语义层面的 token、sequence、KV cache、beam、prefix sharing全部是上层推理系统赋予的含义。4. vLLM PagedAttention应用层的 KV cache 分页vLLM 的原始博客把 PagedAttention 类比为操作系统虚拟内存操作系统虚拟内存vLLM PagedAttentionProcessSequencePageKV blockVirtual page numberLogical block idPhysical framePhysical KV blockPage tableBlock table这个类比非常有启发性但要记住它是应用层类比。PagedAttention 的核心做法是把每个请求的 KV cache 划分为固定 token 数量的 KV block。一个序列在逻辑上仍然是连续上下文但它的逻辑 block 可以映射到任意物理 KV block。随着新 token 生成调度器按需分配新的 block当多个序列共享 prefix 时还可以让多个逻辑 block 指向同一个物理 block并用引用计数和 Copy-on-Write 保护写入。在 CUDA kernel 内部PagedAttention 不再假设 K/V 在一段连续的大数组中顺序排列而是通过 block table 找到每个逻辑 block 对应的physical_block_number再按照k_cache/v_cache的布局计算实际地址。维度GPU 硬件/驱动页表vLLM PagedAttention block table管理对象虚拟地址页到物理显存页或内存对象sequence 的逻辑 token block 到 KV cache 物理 block维护者NVIDIA 驱动、OS、GPU MMU/firmwarevLLM scheduler、block manager、attention kernel可见语义地址、权限、设备归属、映射粒度token、sequence、prefix、beam、引用计数访问路径GPU load/store 触发地址翻译kernel 根据 block table 显式计算 K/V 指针优化目标隔离、映射灵活性、跨设备访问、虚拟内存抽象减少 KV cache 碎片、提高 batch 容量、支持共享与按需分配5. 两层分页如何“协同”又在哪里没有协同说二者协同是因为 PagedAttention 的物理 KV block 最终仍然落在 CUDA 分配出来的 GPU 虚拟地址范围里。无论 vLLM 怎样调度 blockkernel 中对k_cache/v_cache的访问都会经过 NVIDIA 驱动栈建立的地址翻译体系。但说二者没有直接协同也同样重要。PagedAttention 不是向 GPU 页表插入“token 页表项”也不是让驱动理解 KV cache。它通常是在一个或多个 CUDA allocation 上进行应用层分块然后在 kernel 中用 block table 做显式寻址。一个更准确的执行链路是vLLM 启动时根据显存预算创建或管理 KV cache 池底层显存来自 CUDA allocator。CUDA/NVIDIA 驱动为这些 allocation 建立 GPU 可访问的虚拟地址映射。请求进入后vLLM 为序列分配逻辑 KV block并映射到可用 physical block。attention kernel 读取 block table计算k_cache/v_cache中对应 block 的指针偏移。GPU 执行 load/store 时硬件 MMU/TLB 再把这些虚拟地址翻译到真实显存位置。一句话总结PagedAttention 是“在 CUDA 虚拟内存之上实现的 KV cache 虚拟内存”它借用了 paging 的思想但没有替代 NVIDIA 的 GPU 页表。6. 代码视角block table 如何把逻辑 token 找到物理 KV block下面是一个高度简化的伪代码用来表达 PagedAttention kernel 的寻址思想。真实 vLLM 内核会考虑 head size、向量化读取、warp/thread group、shared memory、softmax 分块归约等细节。# 伪代码从逻辑 token 位置找到 KV cache 中的物理 blockBLOCK_SIZE16deflocate_kv(logical_token_idx:int,block_table:list[int]):logical_block_idlogical_token_idx//BLOCK_SIZE offset_in_blocklogical_token_idx%BLOCK_SIZE physical_block_idblock_table[logical_block_id]returnphysical_block_id,offset_in_block# sequence 的逻辑 block 是连续的0, 1, 2, 3# 但可以映射到非连续的 KV cache 物理 block7, 42, 9, 103block_table[7,42,9,103]print(locate_kv(37,block_table))# (9, 5)在 CUDA kernel 中这个映射最终会变成对k_cache/v_cache的指针偏移。vLLM 文档中给出的 Key cache 指针计算可以抽象为// 概念化表达真实代码还会包含 head、stride、向量化、线程分工等参数constscalar_t*k_ptrk_cachephysical_block_number*kv_block_stridekv_head_idx*kv_head_stridephysical_block_offset*x;注意这里的physical_block_number是 vLLM 语义下的“物理 KV block 编号”不是 NVIDIA GPU 页表里的物理页号。它仍然只是一个数组/内存池中的块索引。7. 性能含义碎片、TLB、访存合并与调度7.1 碎片控制PagedAttention 把浪费限制在序列最后一个未填满的 block。相比为每个请求预留最大长度它能显著降低 KV cache 的内部碎片让同一张 GPU 承载更多并发序列。7.2 TLB 与地址翻译从硬件角度看PagedAttention 访问的仍是k_cache/v_cache的 CUDA 虚拟地址。只要这些 allocation 映射稳定GPU MMU/TLB 会像处理普通 global memory 一样处理地址翻译。PagedAttention 的 block table 查询不会绕过或替代这个过程。7.3 访存合并PagedAttention 让逻辑上下文可以分散在不同 block但 kernel 必须尽量让相邻线程读取相邻或规则地址避免把块化带来的灵活性变成访存发散。vLLM 的 kernel 文档强调了专门的内存布局和从 global memory 到 shared memory 的读取方式。7.4 调度和 batch 容量更高的显存利用率意味着 scheduler 可以把更多请求放进同一个 batch。LLM serving 的吞吐提升往往来自“能不能塞下更多有效 token 工作”而不只是单个 attention kernel 的速度。8. 工程实践排查和优化 vLLM 显存问题在实际部署里我会按下面几个方向看问题先区分 OOM 来源模型权重、activation、KV cache、临时 workspace、CUDA graph 捕获池可能都在抢显存。关注max_model_len、gpu_memory_utilization、max_num_seqs、block size、KV cache dtype 等参数它们会直接影响 KV cache 池规模。用nvidia-smi只能看到进程级显存占用要理解 vLLM 内部碎片需要结合 vLLM 日志、block 分配统计和请求长度分布。不要把所有非连续访问都归咎于 GPU 页表。PagedAttention 的主要收益和成本都发生在应用层 block table 与 attention kernel 访问模式上。当吞吐不随 batch 增长而提升时检查是否已经进入 memory bandwidth、kernel launch、调度开销或长尾请求阻塞。示例启动参数# 示例观察 vLLM server 的显存相关配置思路python-mvllm.entrypoints.openai.api_server\--modelmeta-llama/Llama-2-7b-hf\--gpu-memory-utilization0.90\--max-model-len8192\--max-num-seqs128\--kv-cache-dtype auto# 排查时建议同时记录# 1. 请求输入/输出长度分布# 2. OOM 发生时的并发序列数# 3. prefill 与 decode 阶段耗时# 4. vLLM 日志中的 KV cache / block 相关信息9. 结语真正的分层理解来自边界感PagedAttention 之所以漂亮不是因为它神秘地操纵了 GPU 硬件页表而是因为它把操作系统分页的思想准确移植到了 LLM serving 最痛的资源KV cache。NVIDIA 驱动栈提供了可靠的 GPU 虚拟地址、显存映射、权限和跨设备访问能力vLLM 则在这个基础设施之上为 token 序列建立了自己的逻辑地址空间。两层机制互相依赖但语义边界清晰。对资深程序员来说这个案例的价值不止在于理解 vLLM。它提醒我们真正的性能优化往往不是在某一层“用力”而是在正确的抽象层放置正确的数据结构并让它和底层硬件访问路径形成稳定的契合。参考资料NVIDIA CUDA Programming Guide: Virtual Memory ManagementNVIDIA CUDA Programming Guide: Unified Virtual Address SpaceNVIDIA CUDA Driver API: Unified AddressingvLLM Docs: Paged AttentionvLLM Blog: Easy, Fast, and Cheap LLM Serving with PagedAttentionHugging Face TGI Docs: PagedAttention资料访问日期2026-07-17。
