4、vLLM核心架构：PagedAttention、KV Cache管理、调度器与执行器的工作机制
vLLM之所以能在高并发推理场景下实现接近线性的大幅吞吐提升，其根本原因并非单纯依赖GPU算力，而是通过一套精密的系统级协同设计，将显存管理、请求调度与计算执行三个层面深度耦合。理解这一核心架构，是掌握动态批处理与延迟优化实战的前提。本章将深入剖析PagedAttention如何打破传统KV Cache的显存碎片化瓶颈，并揭示调度器与执行器如何像“交通指挥中心”与“高速公路收费站”一样协同工作，确保每一块显存和每一次GPU计算都被高效利用。
上图展示了vLLM三大核心组件（调度器、执行器、KV Cache管理器）之间的协作关系。与传统推理框架将KV Cache视为连续大块内存不同，vLLM通过PagedAttention机制将KV Cache划分为固定大小的“物理块”，并由调度器动态分配。这种设计不仅解决了显存碎片化问题，还使得“连续批处理”（Continuous Batching）成为可能——即一个序列完成生成后，其占用的物理块可立即被新请求复用，而无需等待整个批次结束。
4.1 PagedAttention：从操作系统分页中汲取的灵感
核心原理：逻辑块与物理块的映射
PagedAttention的核心思想借鉴了操作系统中的虚拟内存分页机制。在推理过程中，每个序列的KV Cache不再要求存储在连续的显存地址中，而是被切分为固定大小的逻辑块（Logical Blocks）。每个逻辑块默认存储16个token的Key和Value向量（可通过环境变量调整）。这些逻辑块通过一张块表（Block Table）映射到GPU显存中任意可用的物理块（Physical Blocks）。
这种映射关系带来了两个关键优势：第一，消除了显存碎片。传统方式下，即使显存总空闲空间充足，也可能因找不到连续大块内存而无法容纳新请求；而PagedAttention只需找到足够数量的空闲物理块即可。第二，实现了跨序列的块共享。在并行采样或Beam Search场景中，多个序列可能共享相同的前缀token，此时它们的逻辑块可以指向相同的物理块，仅当某个序列需要写入不同内容时才触发“写时复制”（Copy-on-Write），极大减少了显存占用。
| 对比维度 | 传统KV Cache管理 | PagedAttention |
|---|---|---|
| 显存分配单位 | 连续大块内存（按序列最大长度预留） | 固定大小物理块（默认16 token/块） |
| 显存利用率 | 60%~70%（受碎片和预分配浪费影响） | 95%以上（按需分配，即时回收） |
| 序列间共享 | 不支持 | 支持（通过块表引用计数） |
| 长序列处理 | 可能因显存不足而OOM | 可处理超长序列（如32K token） |
实战观察：在部署Llama-3-8B模型时，若使用传统HuggingFace实现，单卡A100-80G最多并发处理约10个长度为2048的序列；而使用vLLM后，相同硬件可并发处理30个以上同长度序列，且吞吐量提升约2~3倍。这主要归功于PagedAttention将KV Cache的显存开销从“按最大长度预留”优化为“按实际生成进度分配”。
4.2 KV Cache管理器：显存的高效“管家”
判断方法与操作流程：监控与调优
KV Cache管理器负责物理块的分配、释放、复制和回收。其核心数据结构包括：物理块池（Physical Block Pool）、块表（Block Table）以及引用计数表（Reference Count）。在实战中，我们通常通过以下指标判断KV Cache管理是否健康：
- GPU显存利用率：通过
nvidia-smi观察显存占用，若利用率长期低于85%，说明可能存在预分配浪费或批处理规模不足。 - 平均序列长度：若序列长度波动较大（如聊天场景），PagedAttention的优势更明显；若所有请求长度固定且较短，则优势相对有限。
- 块命中率：在共享前缀场景（如多轮对话），高命中率意味着更少的显存写入和更高的吞吐。
调优操作通常涉及两个参数：--max-num-seqs（最大并发序列数）和 --max-num-batched-tokens（单批次最大token数）。建议根据模型大小和显存容量进行网格搜索，找到吞吐量与延迟的最佳平衡点。
经验提醒：当显存充足时，适当增大 --max-num-seqs 可提升吞吐；但若显存紧张，过大的并发数会导致频繁的块交换（Swap）或抢占（Preemption），反而增加延迟。建议通过vLLM的 --gpu-memory-utilization 参数（默认0.9）预留部分显存给CUDA上下文和激活值。
4.3 调度器：动态批处理的“决策大脑”
核心原理：连续批处理与抢占策略
调度器是vLLM实现高吞吐的另一关键。它采用连续批处理（Continuous Batching）策略：不再等待整个批次的所有序列都完成生成后才释放资源，而是每当一个序列生成结束（或达到最大长度），立即将其从批次中移除，并插入新的等待序列。这种“边生成边补位”的模式，使得GPU始终在处理有效计算，避免了传统静态批处理中因“尾部效应”导致的算力浪费。
调度器还负责处理抢占（Preemption）。当新请求的优先级更高或显存不足时，调度器会选择将某些低优先级序列的KV Cache从GPU显存复制到CPU内存（Swap），待资源空闲后再恢复。vLLM支持两种抢占模式：按块交换（Swap）和按序列重组（Recomputation）。前者适合显存带宽充足的情况，后者适合CPU内存带宽有限但GPU算力富余的场景。
案例拆解：高并发聊天服务的调度优化
某在线客服平台部署了Qwen-7B模型，日均请求量约50万次，平均序列长度约800 token，但存在明显的波峰波谷（峰值QPS为500，谷值为50）。初始配置使用静态批处理，峰值时GPU利用率仅40%，且平均响应延迟高达3秒。
分析过程：通过监控发现，静态批处理在波峰时因批次大小固定（设为32），导致部分请求排队等待；而波谷时批次未满，GPU算力闲置。切换到vLLM后，设置 --max-num-seqs=64，并启用连续批处理。调度器在波峰时自动将批次填满至64个序列，波谷时则减少批次大小至10个左右，始终维持GPU利用率在85%以上。
操作步骤：① 将推理服务从HuggingFace迁移至vLLM；② 设置 --max-num-seqs=64 和 --gpu-memory-utilization=0.92；③ 启用 --enable-prefix-caching 以复用常见开场白（如“您好，请问有什么可以帮您？”）的KV Cache。
结果对比：平均响应延迟从3秒降至0.8秒，P95延迟从5秒降至1.5秒，GPU利用率从40%提升至88%。代价是CPU内存占用增加了约2GB（用于KV Cache交换），但整体收益显著。
风险提示：连续批处理虽然提升了吞吐，但可能导致单个请求的延迟抖动。若业务对延迟极其敏感（如金融交易），建议设置 --max-num-seqs 上限，并配合 --scheduling-policy=priority 为高优先级请求预留资源。
4.4 执行器：模型计算的“高效引擎”
核心原理：张量并行与流水线并行
执行器负责将调度器分配的批次实际送入GPU进行前向传播。vLLM的执行器支持多种并行策略：张量并行（Tensor Parallelism）将单个Transformer层的权重矩阵切分到多张GPU上，适合单机多卡场景；流水线并行（Pipeline Parallelism）将不同层分配到不同GPU，适合多机场景。执行器还通过CUDA Graph技术将多次小规模kernel启动合并为一次大kernel启动，显著减少CPU调度开销。
在实战中，执行器的性能瓶颈通常出现在Attention计算。vLLM针对PagedAttention实现了专用的CUDA kernel，该kernel直接操作物理块而非逻辑块，避免了数据拷贝。此外，执行器还支持FlashAttention-2等优化算法，进一步减少显存读写。
常见误区与总结复盘
- 误区一：认为显存越大越好。实际上，若调度器配置不当，大显存可能导致更大的预分配浪费。应始终以“显存利用率”而非“显存总量”为优化目标。
- 误区二：忽略CPU内存交换的影响。当GPU显存不足时，频繁的Swap操作会严重拖慢延迟。建议优先通过
--max-num-seqs控制并发，而非依赖Swap。 - 误区三：盲目追求最大批次。过大的批次会增加单次前向传播的计算时间，导致每个请求的延迟上升。需根据业务SLA（服务等级协议）权衡吞吐与延迟。