深入解析vLLM：PagedAttention如何革新LLM推理的显存管理与吞吐量

1. 项目概述：为什么我们要深入vLLM的内核？

如果你最近在折腾大语言模型（LLM）的推理部署，那么“vLLM”这个名字大概率已经在你耳边出现过无数次了。它几乎成了高性能LLM服务的事实标准，无论是OpenAI的Compatible API，还是众多开源项目，都在用它作为推理引擎。但很多时候，我们只是把它当作一个黑盒：pip install vllm，然后启动服务，看着吞吐量飙升，感叹一句“真快”。至于它为什么能这么快，内部到底是怎么运作的，很多人可能就止步于此了。

这个系列，我打算和你一起，亲手把这个黑盒撬开，看看里面的精密齿轮是如何咬合的。这不是一篇简单的使用教程，市面上已经有很多了。我想做的是，从一个系统开发者的视角，去拆解vLLM最核心的设计思想、数据结构和调度算法。我们会从最根本的问题出发：当模型参数已经固定，推理的瓶颈到底在哪？答案是显存，更具体地说，是注意力（Attention）机制中Key和Value Cache的显存管理与访问效率。vLLM的“v”是“virtual”的意思，其革命性的“PagedAttention”思想，正是借鉴了操作系统虚拟内存和分页的思想，来高效管理这个动态增长且极其消耗显存的KV Cache。

在接下来的内容里，我不会只停留在概念描述。我们会一起看源码（以vLLM 0.4.1版本为主要参考），分析关键数据结构，甚至用简化的代码示例来模拟其核心逻辑。目标是让你读完，不仅能说出vLLM为什么快，更能理解它每一个性能优化背后的权衡与精妙设计，从而在你自己的项目中，也能借鉴这些思想去解决类似的系统瓶颈。

2. 核心问题拆解：LLM推理的吞吐量瓶颈究竟在哪？

要理解vLLM的价值，我们必须先搞清楚它要解决的核心痛点。假设我们有一个70B参数的模型，已经用量化技术压缩到了4比特，模型权重本身可能只占40GB显存。现在我们要部署一个API服务，同时处理来自多个用户的、长度不一的聊天请求。

2.1 传统服务模式的显存困境

在vLLM出现之前，常见的做法是每个请求预先分配一个最大长度的缓存。比如，设定对话最大长度为4096个token。那么对于每个请求，无论它实际生成了1个token还是100个token，我们都需要在显存中为其预留一个足以容纳4096个token的Key和Value张量。这就是所谓的“静态批处理”或“预分配”模式。

这种模式的浪费是惊人的。想象一下，一个刚刚开始的对话和一個已经进行了几十轮的对话，它们占用的显存资源是一样的。更糟糕的是，为了同时处理多个请求（提高吞吐量），你需要为每一个并发的请求都预留这份“最大可能”的显存。这直接导致了显存利用率极低，服务器能同时支持的并发请求数（吞吐量）被严重限制。你的8张80GB A100显卡，可能大部分显存都在“空转”，等着可能永远用不完的空间。

2.2 KV Cache：被忽视的性能关键点

LLM推理分为两个阶段：预填充（Prefill）和解码（Decode）。

• 预填充阶段：处理用户的输入提示（Prompt）。这个阶段是计算密集型的，需要为整个提示序列计算注意力。但它的计算是一次性的，对整体吞吐量影响相对固定。
• 解码阶段：自回归地生成每一个回答的token。这是吞吐量的真正瓶颈所在。这个阶段，模型权重是只读的，大部分计算量在于读取权重和进行矩阵乘。而注意力计算需要用到之前所有已生成token的Key和Value（即KV Cache）。

因此，解码阶段的性能，高度依赖于KV Cache的读取效率。如果KV Cache在显存中是连续存储的，那么内存访问效率就高；如果碎片化严重，就会导致大量的内存延迟，拖慢整个生成过程。传统预分配模式虽然保证了每个请求内部的连续性，却造成了请求间显存的巨大碎片化（因为每个请求占用的是一大块固定空间，中间有很多空闲）。

2.3 PagedAttention的核心思想类比

vLLM的解决方案PagedAttention，其灵感直接来源于操作系统的虚拟内存。

• 物理块（Physical Block）：在显存中预先划分好一系列固定大小（比如16个token）的连续空间块。这就像内存的“页框”。
• 逻辑块（Logical Block）：每个请求的KV Cache被看成是一个逻辑上连续的序列。这就像进程的“虚拟地址空间”。
• 页表（Block Table）：系统为每个请求维护一个“页表”，记录该请求的逻辑块对应到了哪些物理块上。一个请求的KV序列可能分布在多个不连续的物理块中。

通过这种方式，物理显存块（页框）可以被所有请求共享和按需分配。一个刚开始的短请求可能只占用1个块，而一个长对话可能占用几十个块。当请求结束时，它占用的块被释放，可以立即分配给新的请求。这完美解决了显存碎片化和利用率低下的问题。

注意：这里的“页”指的是KV Cache的存储单元，与CPU/GPU的硬件内存页（通常4KB）不是一回事。这是一个软件层面的抽象管理机制。

3. vLLM系统架构全景

理解了核心问题后，我们俯瞰一下vLLM的整体架构。它不是一个简单的库，而是一个完整的推理服务系统，主要分为控制面（Controller）和数据面（Worker）两大部分。

3.1 核心组件与职责划分

调度器（Scheduler）： 这是系统的大脑。它维护着所有待处理请求的队列，并决定在每一次模型前向传播（即每一次解码步骤）中，哪些请求的哪些token应该被一起计算。它的决策直接影响了吞吐量和延迟。vLLM主要实现了两种调度策略：

1. 先来先服务（FIFO）：简单，但可能因为一个长请求阻塞后面所有请求。
2. 迭代级调度（Iteration-level Scheduling）：这是vLLM高性能的关键。它能在每个解码步（iteration）动态选择一组可以一起计算的请求，即使这些请求处于生成的不同阶段。这就要求调度器能精细地管理每个请求的KV Cache物理块映射关系。

块管理器（Block Manager）： 这是PagedAttention思想的具体执行者。它管理着GPU显存中所有的物理块（Block），负责块的分配、释放和映射。当调度器决定要运行一批请求时，块管理器需要快速地为这些请求准备好它们所需的物理块信息，并组装成模型能够高效计算的张量格式。

模型执行器（Model Executor）： 这是系统的肌肉。它接收调度器送来的一批token和块管理器送来的KV Cache物理块信息，调用底层（如PyTorch、CUDA）的核函数执行真正的计算。vLLM在这里做了大量优化，比如将不连续的物理块数据通过索引（Gather）操作组装成连续的张量，以适配高度优化的注意力核函数（如FlashAttention）。

注意力层改造（Attention Layer）： 这是算法实现的核心。vLLM修改了Transformer注意力层的实现，使其能够接受“块表”和“块内偏移”作为输入，而不是一个普通的连续KV张量。它需要根据这些信息，在计算注意力分数时，正确地找到每个query对应的key和value所在物理块中的位置。

3.2 请求处理的生命周期

让我们跟踪一个用户请求“Hello, how are you?”在vLLM中的旅程：

1. 接收与拆分：API服务器收到请求，将其提示词“Hello, how are you?” token化。假设被分成5个token[T1, T2, T3, T4, T5]。调度器将此请求加入队列。
2. 预填充调度：调度器发现当前GPU有空闲计算资源，决定执行这个请求的预填充阶段。它向块管理器申请存储这5个token的KV Cache所需的物理块（可能不到一个块）。块管理器分配物理块，并建立该请求的逻辑块到物理块的映射表。
3. 预填充执行：模型执行器拿到这5个token和块映射信息，运行一次完整的前向传播，计算出第一个输出token “I’m”，并为[T1...T5]生成KV Cache，存入分配的物理块中。
4. 解码调度：请求进入解码循环。调度器不会让这个请求独占GPU。假设此时有其他请求也在解码，调度器会尝试将当前可以生成的请求（即前一个token已生成完毕的请求）打包到一起。例如，将请求A的下一个token和请求B的下一个token组成一个微批（Micro-batch）。
5. 解码执行：对于这个微批，块管理器需要收集每个请求的KV Cache映射情况。由于采用了分块，即使请求A的Cache在物理块[0, 5, 10]，请求B的在[2, 7]，模型执行器也能通过索引高效地获取数据，并计算注意力，生成下一个token。
6. 循环与完成：重复步骤4和5，直到请求生成结束符或达到最大长度。此时，调度器通知块管理器，该请求占用的所有物理块被释放，可供后续请求使用。

这个过程中，迭代级调度和物理块共享是提升吞吐量的魔法。GPU的计算单元几乎时刻处于忙碌状态，显存也被高效利用。

4. PagedAttention 算法深度解析

现在，我们深入到最核心的PagedAttention算法。理解它，就理解了vLLM的灵魂。

4.1 数据结构定义

首先，我们需要在代码层面定义几个关键结构。以下是一个高度简化的概念性代码，帮助你理解其设计。

# 概念性代码，用于说明数据结构 class PhysicalBlock: """一个物理块，对应显存中的一块连续空间，用于存储固定数量token的K和V。""" def __init__(self, block_id: int, device: str, block_size: int): self.block_id = block_id self.device = device self.block_size = block_size # 例如，能存16个token的K和V # 实际存储K和V数据的张量 [num_layers, 2, num_heads, block_size, head_dim] self.data = None self.ref_count = 0 # 引用计数，用于垃圾回收 class LogicalBlock: """逻辑块，是请求KV序列的一个逻辑片段。""" def __init__(self, logical_id: int): self.logical_id = logical_id self.physical_block: PhysicalBlock = None # 映射到的物理块 self.block_offset: int = 0 # 在该物理块内的起始偏移（通常为0，因为块是分配的单位） class Sequence: """代表一个请求的序列。""" def __init__(self, seq_id: str): self.seq_id = seq_id self.logical_blocks: List[LogicalBlock] = [] # 按顺序排列的逻辑块列表 self.block_table: Dict[int, PhysicalBlock] = {} # 逻辑块ID -> 物理块的映射表

在实际的vLLM源码中（如vllm/core/block_manager.py），Block的管理要复杂得多，它需要处理多GPU的情况，以及更高效的内存分配策略。

4.2 注意力计算的重映射过程

标准的注意力计算公式是：Attention(Q, K, V) = softmax(QK^T / sqrt(d)) V。其中K和V是形状为[seq_len, num_heads, head_dim]的张量。

在PagedAttention下，一个序列的K和V不再是连续的[seq_len, ...]张量，而是分散在多个物理块中。假设一个序列的逻辑块列表是[逻辑块0, 逻辑块1, 逻辑块2]，分别映射到物理块[物理块5, 物理块2, 物理块8]，每个块存16个token。

那么，当计算当前query（对应第33个token，即逻辑块2的第1个token）与所有历史key的注意力时，模型需要：

1. 通过block_table找到逻辑块0对应物理块5，取出其中16个key向量。
2. 找到逻辑块1对应物理块2，取出其中16个key向量。
3. 找到逻辑块2对应物理块8，但只取出当前位置之前的所有key向量（本例中是前1个）。
4. 将这些从不同物理块、不同偏移取出的key向量，在内存中重新拼接成一个逻辑上连续的key张量，才能进行QK^T计算。

这个过程就是“重映射”。vLLM通过预计算一个复杂的索引张量来实现高效的数据收集（Gather），而不是在运行时进行低效的循环拷贝。

4.3 块大小（Block Size）的选择艺术

块大小是一个关键的权衡参数，它不是一个固定值，需要在启动vLLM时通过--block-size指定。

• 块太小（如4）：管理开销巨大。每个请求需要更多的逻辑块和映射关系，block_table会变得庞大，索引计算更复杂，可能抵消掉连续性带来的好处。
• 块太大（如128）：内部碎片严重。一个只生成了3个token的短请求也会独占一个128-token的块，导致显存浪费，回到了老问题。

如何选择？这取决于你的典型工作负载。

• 多轮短对话场景（如客服机器人）：请求长度短且差异不大。可以选择较小的块（如16），以减少碎片。
• 长文本生成场景（如写小说、代码生成）：请求可能非常长。选择较大的块（如32或64），可以减少块表的大小和管理开销，对于长序列更友好。

实操心得：没有一个放之四海而皆准的值。最好的方法是使用你实际的请求分布（prompt长度+生成长度的历史数据）进行模拟测试。可以写一个简单的脚本，在不同块大小下，计算显存利用率和理论上的最大并发数。通常，从32开始调整是一个不错的起点。

5. 性能优化技巧与源码导读

了解了原理，我们来看看vLLM在工程上是如何实现极致性能的。我们可以结合源码中的一些关键设计来探讨。

5.1 连续批处理（Continuous Batching）的实现

连续批处理是vLLM高吞吐的基石。它的核心在于，每次前向传播的“批”是动态变化的。我们可以在vllm/engine/llm_engine.py的_schedule函数和vllm/core/scheduler.py中找到其核心逻辑。

调度器维护着多个队列：等待队列、运行队列等。在每个解码步（step）中，它会：

1. 选择可运行的请求：从运行队列中，找出那些前一个token已生成完毕、且未达到停止条件的请求。
2. 打包（Batching）：将这些请求的“下一个要生成的token”打包成一个列表。这里有一个关键优化：即使请求长度不同，它们下一个token的计算是独立的，可以并行。因为注意力机制允许每个query只访问它自己序列的KV Cache。
3. 处理新请求：如果有空闲的“槽位”（由块管理器和计算资源决定），调度器会从等待队列中取出新的请求，进行预填充，然后加入运行队列。

这种机制确保了GPU永远不会因为某个请求在等待输入（如用户打字）而空闲，也避免了因为等待一个慢请求而阻塞整个批处理。

5.2 内存管理与垃圾回收

块管理器的另一个重要职责是垃圾回收。在vllm/core/block_manager.py中，BlockAllocator类负责管理物理块。它采用了一种类似内存池的分配策略。

• 引用计数：每个PhysicalBlock都有一个ref_count。当被一个序列映射时，计数+1；当序列结束或该逻辑块被释放（由于滑动窗口等机制）时，计数-1。
• 空闲列表：引用计数为0的块会被放入空闲列表，供后续分配使用。这避免了频繁地向CUDA申请和释放显存，后者是昂贵的操作。
• 碎片整理：vLLM目前版本的块管理器相对简单，没有复杂的碎片整理（如紧凑化）。因为块是固定大小的，碎片化只表现为空闲块的数量，而不是大小不一的空洞。当空闲块耗尽时，系统就无法分配新请求了。

5.3 与FlashAttention等内核的协作

vLLM的性能离不开底层高效算子的支持，尤其是FlashAttention。FlashAttention通过IO感知的算法，在SRAM级别进行优化，大幅降低了注意力计算对HBM（高带宽内存）的访问次数。

vLLM需要将自己的分块数据“适配”到FlashAttention的接口上。FlashAttention期望的K和V是连续的张量。因此，在调用FlashAttention之前，vLLM需要执行一个“Gather”操作：根据block_table和每个序列的逻辑位置，将分散在各个物理块中的数据收集到一个临时的连续缓冲区中。

这个过程本身有开销。因此，vLLM的优化目标就是让块管理的收益（更高的显存利用率和并发度）远大于数据重排（Gather）的开销。在实际中，由于GPU内存带宽极高，而计算注意力本身更耗时，这种Gather开销在大多数情况下是完全可以接受的，从而换来了吞吐量数倍的提升。

6. 实践部署中的常见问题与调优

理论很美好，但把vLLM用在实际生产环境中，总会遇到各种问题。下面分享一些我踩过的坑和调优经验。

6.1 吞吐量上不去？检查这些点

1. 瓶颈在IO还是计算？使用nvtop或nvidia-smi dmon观察GPU利用率和显存带宽。如果GPU利用率（Volatile GPU-Util）长期低于70%，而你的批处理大小（max_num_seqs）设置得并不小，那么瓶颈可能不在计算，而在数据准备或调度。

   • 可能原因A：块大小不匹配。块大小设置不合理导致内部碎片严重，实际有效并发请求数少。
   • 可能原因B：提示词过长。预填充阶段是计算密集型，如果每个请求的提示词都很长（如上万token），那么系统大部分时间都在做预填充，解码阶段的吞吐优势就体现不出来。考虑使用提示词缓存（Prompt Cache）技术，或对长提示进行拆分处理。

2. max_num_seqs参数：这个参数控制调度器每次尝试打包的最大序列数。设置太小，无法充分利用GPU；设置太大，会增加调度延迟，并可能导致更多的内存交换。这是一个需要根据你的GPU型号（显存大小）和模型大小来权衡的参数。通常可以先设置为GPU能容纳的最大理论序列数（总显存/每个序列预估显存），然后逐步下调，观察吞吐量变化，找到一个峰值点。

3. 量化模型的影响：如果你使用了GPTQ、AWQ等量化模型，确保vLLM的版本支持该量化格式，并且加载正确。量化本身会引入少量的精度损失和解压开销，但通常带来的显存节省和带宽收益远大于开销。

6.2 长文本生成中的“内存泄漏”

有时你会发现，处理长文本生成任务时，显存占用会缓慢增长，即使请求结束了也不释放。这通常不是真正的泄漏，而是以下原因：

• 缓存未及时释放：确认请求是否真正发送了结束信号（如生成了<|endoftext|>token）。有些客户端超时或中断连接，可能没有通知服务器终止序列。
• 块管理器的空闲块未重用：虽然块被释放回空闲列表，但如果后续的请求长度模式变化，可能导致空闲块无法被有效合并或重用。vLLM目前没有自动的碎片整理，在极端的长短请求交替场景下，可能需要重启服务来“重置”显存状态。
• 监控工具差异：nvidia-smi显示的显存是进程向CUDA申请的总量，不一定代表即时使用量。CUDA有自己的内存缓存机制。更准确的观察方式是使用vLLM自带的vllm.engine.metrics或通过API查询/metrics端点。

6.3 与外部系统集成的注意事项

1. API兼容性：vLLM提供了与OpenAI API高度兼容的接口，这大大方便了集成。但需要注意一些细微差别，比如参数名（vllm可能支持一些额外参数）、响应格式的扩展字段等。务必对你的客户端进行测试。
2. 流式输出（Streaming）：vLLM完美支持流式输出。在部署时，确保你的网络网关或负载均衡器支持HTTP流式传输（如保持长连接），避免因为缓冲而导致客户端延迟感知变差。
3. 监控与告警：除了基础的GPU监控，建议监控vLLM的关键指标：每个请求的首次Token时间（TTFT）、Token生成速度、队列等待长度、当前活跃序列数、物理块使用率等。这些指标能帮助你及时发现容量瓶颈和异常。

7. 从vLLM设计中汲取的系统设计思想

最后，跳出vLLM本身，我认为它的成功给我们这些系统软件开发者带来了几点非常重要的启发：

1. 定义真正的瓶颈，并敢于进行跨领域借鉴。vLLM团队没有局限于深度学习框架的常规优化手段（如算子融合、图优化），而是准确地识别出KV Cache管理是核心瓶颈。他们大胆地从操作系统这个看似不相关的领域，借鉴了虚拟内存和分页这个历经几十年考验的经典思想，并成功地将其适配到GPU显存管理这个新场景。这告诉我们，解决复杂系统问题，视野一定要开阔。

2. 在软件层解决硬件限制问题。GPU的显存是静态、连续且有限的物理资源。直接管理它非常僵硬。vLLM通过引入一个“块”的抽象层，在软件层面创造了一个“虚拟化”的、可灵活分配和共享的KV Cache空间。这相当于在硬件之上构建了一个更高效、更灵活的“内存管理系统”。这种通过增加抽象层来提升底层资源利用率的设计模式，在分布式系统、数据库等领域同样常见。

3. 权衡是系统设计的永恒主题。PagedAttention不是没有代价的。它引入了块表的管理开销、数据Gather的额外拷贝开销、以及可能更复杂的调度逻辑。vLLM的设计精髓就在于，它通过精心的工程实现，确保了这些开销远小于它带来的收益（极高的显存利用率和并发度）。这完美诠释了系统设计中的权衡艺术：接受可控的、局部的复杂度增加，以换取全局的、数量级的性能提升。

4. 面向特定工作负载的深度优化。vLLM不是万能的。它在处理超长序列、且请求长度差异极大的流式解码场景下，威力最大。如果你的场景是固定的、已知长度的批处理推理，可能更传统的静态批处理工具就足够了。理解你所要服务的工作负载的特定模式，并据此进行深度优化，才能做出最有竞争力的系统。

研究vLLM，就像在观摩一位顶尖系统架构师的杰作。它不仅仅是一个工具，更是一本关于如何分析瓶颈、跨界思考和精细权衡的教科书。希望这个系列的前言，能为你打开这扇门。在接下来的文章中，我们将一行行代码地深入其调度器、块管理器和注意力内核，把每一个精妙的设计细节都摊开来看明白。