3、vLLM核心概念：PagedAttention、Continuous Batching、KV Cache、吞吐量与延迟优化原理

在正式进入LangChain集成开发之前，必须深入理解vLLM的底层加速引擎。vLLM之所以能在高并发推理场景下实现数倍乃至数十倍的吞吐量提升，核心并非依赖更先进的GPU硬件，而是通过软件层面的三项关键创新：PagedAttention（分页注意力）、Continuous Batching（连续批处理）以及KV Cache（键值缓存）的精细化管理。这三者相互关联，共同决定了推理服务的吞吐量（Throughput）与延迟（Latency）表现。本章将逐一拆解这些核心概念，并揭示它们如何协同工作以优化GPU资源利用率。

上图展示了vLLM核心组件之间的协作关系：请求流首先进入连续批处理调度器，由调度器决定哪些序列参与本轮迭代计算；KV Cache管理器负责为每个序列分配物理显存块；PagedAttention则在非连续内存上执行注意力计算。三者协同，最终实现吞吐量提升与延迟降低的双重目标。

3.1 PagedAttention：打破显存碎片化的关键创新

核心原理

传统推理框架（如HuggingFace Transformers）在计算注意力时，需要为每个请求预先分配连续的KV Cache内存。这种静态分配方式存在两个致命问题：内部碎片（请求实际长度远小于最大长度，导致预留空间浪费）和外部碎片（不同请求的KV Cache大小不一，难以在连续内存中紧凑排列）。PagedAttention借鉴操作系统虚拟内存的分页机制，将KV Cache划分为固定大小的物理块（Block）（默认16KB，可容纳约128个token的键值向量），每个序列维护一张逻辑块表（Block Table），记录逻辑块到物理块的映射关系。这样，一个序列的KV Cache可以分散存储在非连续的物理块中，仅在计算时通过块表索引聚合。

判断方法

如何判断一个推理框架是否采用了类似PagedAttention的机制？可以通过以下特征识别：

• 内存分配粒度：是否以固定大小的块为单位分配显存，而非按请求长度动态分配连续空间。
• 序列间内存共享：是否支持多个序列共享同一个物理块（用于并行采样或前缀共享）。
• 显存碎片率：在长时间运行后，显存碎片率是否保持稳定（PagedAttention可将碎片率控制在5%以内）。

案例拆解：并行采样场景下的显存节省

假设使用GPT-3（175B参数）生成文本，设置 n=4（每个提示词并行生成4个候选序列）。传统框架需要为4个序列分别分配独立的KV Cache，而PagedAttention允许这4个序列在共享前缀阶段（即前100个token）复用同一组物理块。以输入提示词512 token、生成1024 token为例：

实际部署中，前缀共享还能配合RadixAttention（vLLM 0.4+版本支持）实现跨请求的自动前缀复用，在RAG（检索增强生成）场景中效果尤为显著。

3.2 Continuous Batching：从静态批处理到迭代级调度

核心原理

传统推理框架采用静态批处理（Static Batching）：将多个请求组成一个batch，等batch中所有序列都生成完毕后才释放资源。这导致两个问题：一是气泡时间（短序列提前结束，但GPU仍需等待长序列完成）；二是资源浪费（已结束序列占用的KV Cache无法及时释放）。Continuous Batching将调度粒度从“整个序列”细化为“每次解码迭代（Decode Step）”。在每个迭代步结束后，调度器立即将已完成的序列移出batch，并插入新的等待序列。这样，GPU始终在处理活跃序列，计算资源利用率大幅提升。

操作流程

1. 请求入队：新请求进入等待队列，由调度器根据优先级策略（如FCFS、最短序列优先）选择。
2. 迭代调度：在每个解码步开始前，调度器检查当前batch中是否有序列已生成<eos>或达到最大长度，将其移出并释放KV Cache。
3. 动态插入：从等待队列中选取新请求，为其分配物理块并加入当前batch。
4. 执行解码：GPU执行一次前向传播，为batch中所有序列生成下一个token。

案例拆解：混合负载下的吞吐量对比

某在线服务需要同时处理短查询（平均20 token）和长文档生成（平均500 token）。使用静态批处理时，若batch大小为8，且其中包含2个长序列，则整个batch需要等待最长序列完成后才能释放，导致短查询的响应时间被拉长至数秒。改用Continuous Batching后：

• 短查询在2-3次迭代内即可完成，立即释放资源。
• 长序列继续占用资源，但调度器可随时插入新的短查询。
• 实测吞吐量从静态批处理的 120 req/s 提升至 450 req/s，平均延迟从 2.1s 降至 0.8s。

3.3 KV Cache管理与显存优化策略

核心原理

KV Cache是Transformer解码过程中存储历史键值向量的缓存，其大小与序列长度、模型维度、层数成正比。以LLaMA-7B为例，每个token的KV Cache占用 2 × 32层 × 4096维 × 2字节 = 512KB。生成1024个token需要约512MB显存。vLLM通过以下策略优化KV Cache管理：

• 预分配与按需分配结合：初始阶段为每个序列分配少量物理块（如4块），后续按需追加。
• 前缀共享：多个序列共享相同前缀的KV Cache（如系统提示词、Few-shot示例）。
• Swap机制：当GPU显存不足时，将不活跃序列的KV Cache换出到CPU内存（通过 --swap-space 参数控制）。

判断方法

通过 vllm serve 启动服务时，可观察以下指标评估KV Cache效率：

实战场景：长文本生成的内存规划

假设使用A100 80GB GPU部署LLaMA-13B模型（权重占用约26GB），可用显存约54GB。若目标最大生成长度为4096 token，每个序列的KV Cache占用 4096 × 512KB = 2GB。理论上最多支持27个并发序列。但考虑到PagedAttention的块级分配，实际可支持约30个序列（因为部分序列可能提前结束）。通过 --gpu-memory-utilization 0.92 设置，可确保KV Cache获得最大可用显存。

3.4 吞吐量与延迟的权衡艺术

核心原理

吞吐量（Tokens/s）与延迟（首token延迟、端到端延迟）存在天然矛盾。增大batch size可提升吞吐量，但会增加每个请求的排队时间和计算等待时间。vLLM通过Continuous Batching和PagedAttention，将这一权衡曲线整体向“高吞吐、低延迟”方向移动。具体而言：

• 首token延迟（TTFT）：主要受prefill阶段计算量影响，与batch size关系不大。
• 端到端延迟：受解码阶段每个token的生成时间影响，batch越大，单token生成时间越长。
• 吞吐量：等于batch size除以单token平均生成时间。

判断方法

使用 vllm bench 工具进行压测时，应关注以下指标组合：

# 压测命令示例
python -m vllm.benchmarks.benchmark_serving \
  --model meta-llama/Llama-2-7b-chat-hf \
  --tokenizer meta-llama/Llama-2-7b-chat-hf \
  --num-prompts 200 \
  --request-rate 10 \
  --max-num-seqs 64

输出结果中，Throughput (req/s) 和 Mean latency per token (ms) 是核心指标。若吞吐量高但延迟也高，说明batch过大；若延迟低但吞吐量低，说明batch过小或GPU利用率不足。

案例拆解：在线聊天机器人的参数调优

某客服机器人需要处理平均50 token的输入，生成平均150 token的回复，SLA要求P95延迟小于2秒。初始配置 --max-num-seqs 128，压测结果：吞吐量 320 req/s，但P95延迟达到3.5秒。分析发现，128个序列中大部分是短请求，但长请求拖慢了整体batch。调整策略：

1. 将 --max-num-seqs 降至64，减少batch内长尾效应。
2. 启用 --enable-prefix-caching，复用常见问候语的KV Cache。
3. 设置 --max-model-len 2048，限制最大序列长度。

调整后：吞吐量降至280 req/s（-12.5%），但P95延迟降至1.2秒（-65.7%），满足SLA要求。此案例说明，吞吐量与延迟的取舍需以业务SLA为准绳。

3.5 常见误区与性能调优复盘

误区一：盲目追求最大batch size

许多开发者认为batch越大越好，但忽略了显存墙和计算墙。当batch size超过GPU计算能力时，单token生成时间急剧上升，导致吞吐量不升反降。vLLM的调度器会自动限制batch大小，但手动设置过大的 max-num-seqs 会导致请求排队时间过长。

误区二：忽略prefill与decode的差异

prefill阶段（处理输入token）是计算密集型，decode阶段（逐个生成token）是访存密集型。vLLM虽然统一调度，但不同阶段的GPU利用率差异显著。若输入token极长（如RAG场景），prefill时间可能占据端到端延迟的80%以上。此时应优化检索策略，减少输入长度，而非单纯调整batch。

误区三：KV Cache设置越大越好

增大 gpu-memory-utilization 虽然能容纳更多序列，但会挤压激活值（Activation）的显存空间。当激活值不足时，vLLM会触发显存交换（Swap），反而降低性能。建议通过 nvidia-smi 监控显存分配，确保KV Cache使用率不超过90%。

调优复盘清单