vLLM架构深度解析：PagedAttention如何实现高吞吐LLM推理

引言：为什么LLM推理需要专门的系统

随着大语言模型（LLM）在生产环境的广泛部署，推理性能已经成为决定服务成本与用户体验的关键因素。训练一个模型固然昂贵，但真正持续消耗算力和资金的，往往是模型上线后每天数以亿计的推理请求。如何在有限的GPU资源下服务更多用户、降低单次请求成本，成为工程团队必须直面的挑战。

vLLM正是在这一背景下诞生的开源推理引擎。它由加州大学伯克利分校的研究团队提出，凭借创新的内存管理机制和调度策略，在吞吐量上相比传统方案实现了数倍提升。本文将结合"vLLM: Anatomy of a High-Throughput LLM Inference System"的技术剖析，拆解vLLM高吞吐背后的核心设计原理。

LLM推理的瓶颈：KV Cache内存管理难题

自回归生成的内存开销

理解vLLM的设计，首先要理解LLM推理的独特之处。Transformer架构的自回归生成过程中，每生成一个新token都需要访问此前所有token的键值对（Key-Value）。为了避免重复计算，系统会将这些KV缓存在显存中，即所谓的KV Cache。

具体来说，Transformer中的自注意力（Self-Attention）机制要求每个新生成的token与序列中所有先前token进行注意力计算。在每个注意力层中，输入token会被投影为Query、Key、Value三个向量。生成第t个token时，需要用当前token的Query与前t-1个token的所有Key计算注意力权重，再用这些权重对所有Value做加权求和。如果不缓存历史的Key和Value，每生成一个token就需要重新计算整个序列的前向传播，计算复杂度从O(n)退化为O(n²)。因此KV Cache是自回归推理中的必要优化，但代价是显存占用随序列长度和批量大小呈线性增长。对于一个具有L层、隐藏维度为d、注意力头数为h的模型，单个token的KV Cache占用为2×L×d×sizeof(float16)字节——一个2048 token序列在70B参数模型上可能占用数GB显存。

问题在于，KV Cache的大小会随着序列长度线性增长，并且不同请求的序列长度差异巨大。传统推理系统通常为每个请求预分配一块连续的显存空间，按照可能的最大序列长度来预留。这种做法带来了严重的内存浪费——研究表明，传统方案的显存利用率往往只有20%-40%，大量显存因内部碎片和过度预留而闲置。

显存浪费的三种形式

具体来看，传统KV Cache管理存在三类浪费：

内部碎片：为最大长度预留但实际未用满的空间
外部碎片：不同请求释放后留下的不连续空隙难以复用
预留浪费：为尚未生成的未来token提前占用的空间

这些浪费直接限制了系统能够同时处理的请求批量（batch size），进而制约了整体吞吐量。

PagedAttention：借鉴操作系统的虚拟内存分页思想

PagedAttention的核心创新

vLLM最具突破性的贡献是PagedAttention机制。这一设计的灵感直接来源于操作系统中经典的虚拟内存分页（paging）技术。既然操作系统能通过分页机制高效管理物理内存并消除碎片，那么同样的思路也可以应用到KV Cache管理上。

操作系统的虚拟内存系统是计算机科学中最优雅的抽象之一。其核心思想是将物理内存划分为固定大小的页帧（通常为4KB），同时为每个进程提供一个连续的虚拟地址空间。页表（Page Table）负责将虚拟页号映射到物理页帧号，使得进程看到的连续内存在物理上可以分散存储。这种设计解决了内存碎片问题（因为分配单位是固定大小的页），支持内存超额分配（通过页面置换将不活跃页换出到磁盘），并实现了进程间的内存隔离与共享。

PagedAttention直接借鉴了这一范式：将KV Cache切分成固定大小的块（block），每个块存储固定数量token的键值对（通常为16个token）。这些块在物理显存中无需连续存放，而是通过一张**块表（block table）**来维护逻辑序列到物理块的映射关系。KV Cache块对应物理页帧，逻辑序列的token位置对应虚拟地址，块表对应页表——这种类比不仅在概念上成立，在解决的问题类型上也高度一致，都是在有限物理资源上为多个并发消费者提供高效、灵活的内存管理。

PagedAttention带来的性能收益

这种分页设计带来了立竿见影的效果：

按需分配：只有在实际生成token时才占用新块，彻底消除了预留浪费
复用空间：固定块大小让释放的空间可以被任意请求复用，几乎消灭了外部碎片
碎片可控：内部碎片被限制在单个块大小的范围内，通常不到一个块

实测显示，vLLM能将显存浪费控制在4%以下，显存利用率的大幅提升直接转化为更大的批处理能力和更高的推理吞吐量。

KV Cache内存共享：让并发生成更高效

分页机制还解锁了一个此前难以实现的能力——KV Cache内存共享。在很多实际场景中，多个请求会共享相同的前缀。例如，同一个系统提示词（system prompt）被多个用户请求复用，或者在并行采样（parallel sampling）和束搜索（beam search）中，多个候选序列共享相同的历史。

借助块表的间接映射，vLLM可以让多个逻辑序列指向同一个物理块，从而实现KV Cache的零拷贝共享。当某个序列需要修改共享块时，系统采用**写时复制（copy-on-write）**策略，只在真正发生分歧时才复制数据。

写时复制（Copy-on-Write, COW）最初是Unix操作系统中fork()系统调用的核心优化。当父进程fork出子进程时，两者最初共享相同的物理内存页，只有当其中一方尝试写入某页时，系统才会真正复制该页并更新页表映射。在vLLM中，这一机制的应用场景是并行采样和束搜索：多个候选序列在分歧点之前共享完全相同的KV Cache。系统通过引用计数追踪每个物理块被多少逻辑序列引用。当引用计数大于1且某序列需要向该块追加新的KV对时，系统才会分配新块、复制数据、更新块表。这避免了在束搜索的早期阶段为每个beam都维护独立的完整KV Cache副本，在beam width为4-8的典型配置下，共享比例可达60-80%。

这一机制在束搜索等场景下可以节省高达55%的显存，进一步提升了资源利用率。

连续批处理：调度层的吞吐量优化

从静态批处理到连续批处理

除了内存层面的创新，vLLM在请求调度上也做了关键优化。传统的**静态批处理（static batching）**需要等待整个批次中最长的请求生成完毕才能返回结果并接收新请求，这导致已经完成的短请求白白占用资源等待，GPU利用率低下。

静态批处理的低效根源在于请求间生成长度的高度异质性。在真实的LLM服务场景中，不同请求的输出长度可能从几个token到数千token不等，服从长尾分布。假设一个批次中最短请求生成10个token、最长生成500个token，那么最短请求完成后仍需等待490步迭代才能释放其GPU计算槽位和显存，造成了严重的资源浪费。

vLLM采用连续批处理（continuous batching），也称迭代级调度（iteration-level scheduling）。系统在每一次生成迭代后都会重新评估批次组成：已完成的请求立即释放资源并返回，新到达的请求可以随时加入正在运行的批次。这种细粒度的动态调度让GPU始终保持高负载运转，显著提升了整体吞吐量。

Orica（2022年发表的论文）首先提出了迭代级调度的概念。vLLM在此基础上的独特贡献是将连续批处理与PagedAttention的动态内存管理相结合——因为请求可以随时加入和离开批次，其KV Cache也需要能够灵活地分配和回收，而分页机制恰好提供了这种灵活性。两者的协同设计是vLLM性能优势的关键所在。

抢占与恢复机制

当显存不足以容纳所有活跃请求时，vLLM还引入了抢占机制。系统可以选择将部分请求的KV Cache临时换出，优先保证其他请求的推进，待资源释放后再恢复被抢占的请求。

vLLM的抢占恢复机制提供了两种互补策略来处理显存压力。第一种是重计算（Recomputation）：被抢占请求的KV Cache直接丢弃，当该请求被重新调度时，系统重新运行其prompt的前向传播来重建KV Cache。这种方式不需要额外的存储空间，但恢复延迟较高，适用于prompt较短的场景。第二种是交换（Swapping）：将被抢占请求的KV Cache块通过PCIe总线从GPU显存转移到CPU内存中暂存，恢复时再换回。这种方式恢复更快，但受限于PCIe带宽（通常为32-64 GB/s，远低于GPU显存带宽的1-3 TB/s）和CPU内存容量。

vLLM的调度器会根据当前系统状态和请求特征选择最优策略，这种设计哲学与操作系统中的页面置换算法（如LRU）和进程调度器的优先级策略一脉相承，保证了系统在高负载下的稳定性和公平性。

vLLM架构总览与工程价值

综合来看，vLLM的高吞吐能力建立在三大技术支柱之上：

技术模块	解决的问题	核心效果
PagedAttention	显存碎片与浪费	显存利用率提升至96%以上
KV Cache内存共享	重复前缀的冗余存储	节省高达55%显存
连续批处理	GPU空闲等待	最大化GPU利用率

三者协同作用，使vLLM在相同硬件条件下的吞吐量相比早期方案可达数倍甚至十几倍的提升。

从工程实践角度，vLLM的成功也印证了一个重要观点：许多看似前沿的AI系统难题，其解决方案往往能从计算机科学的经典理论中找到灵感。操作系统数十年积累的内存管理智慧，被巧妙地迁移到了LLM推理场景，产生了巨大的实际价值。

结语

vLLM如今已成为业界事实上的标准推理引擎之一，被众多企业和开源项目广泛采用。理解其内部架构，不仅有助于工程师更好地部署和调优LLM推理服务，也能启发我们思考如何将成熟的系统设计思想应用到新兴的AI基础设施中。随着模型规模的持续增长和长上下文需求的爆发，KV Cache管理和推理调度的重要性只会与日俱增，vLLM所开创的这套方法论，仍将持续演进并影响整个行业。