vLLM 与 LLM 推理部署实战：从 PagedAttention 到生产级服务架构

引言

随着大语言模型（LLM）从实验室走向生产环境，推理部署已从简单的模型调用演变为涉及内存管理、调度策略、并行计算和系统优化的复杂工程挑战。vLLM 作为当前最热门的开源 LLM 推理框架，通过 PagedAttention 技术重新定义了 KV Cache 的管理方式，将推理吞吐量提升了 2-4 倍。本文将深入剖析 vLLM 的核心原理，并系统梳理生产级 LLM 服务部署的完整技术栈。

一、KV Cache 的内存困境

理解 vLLM 的突破，首先要理解它解决了什么问题。在自回归生成过程中，Transformer 架构的每个解码步骤都需要访问之前所有 token 的 Key 和 Value 向量，这就是 KV Cache。

以 Llama-2-7B 模型为例：单层注意力头的 KV 维度为 num_heads × head_dim = 32 × 128 = 4096，共有 32 层。每个 token 的单层 KV 缓存大小为 2 × 4096 × 2 bytes (FP16) = 16KB。乘以 32 层，单个 token 的 KV Cache 为 512KB。一个支持 2048 token 上下文的请求就需要 1GB 显存仅用于 KV Cache。

传统方案中，每个请求的 KV Cache 是预分配的连续显存块，导致两个核心问题：约 60%-80% 的显存被浪费（内部碎片+外部碎片），且并发请求数受显存限制严重。当 GPU 显存为 80GB 时，实际可用的 KV Cache 空间可能仅能支撑不到 20 个并发长序列请求。

二、PagedAttention：显存的"操作系统级"革命

vLLM 借鉴了操作系统中虚拟内存的分页思想，提出了 PagedAttention 机制。其核心设计包括三个层次：

2.1 Block Manager 与逻辑-物理映射

KV Cache 被划分为固定大小的 block（通常 16 个 token 为一组）。Block Manager 维护两个核心数据结构：block table（逻辑到物理的映射）和 free block list（空闲物理块池）。这与操作系统的页表结构完全同构——逻辑页号对应 token 序列位置，物理页号对应 GPU 显存中的 block 索引。

当新请求到达时，Block Manager 并不预分配完整序列长度的 block（因为输出长度未知），而是按需分配——每次只分配当前需要的 block。这种"写时复制"的策略极大降低了内存浪费，将显存利用率从约 20-40% 提升至接近 100%。

2.2 Copy-on-Write 与共享前缀

在 Beam Search 或多轮对话场景中，多个推理请求可能共享相同的前缀 KV Cache。vLLM 通过引用计数实现 Copy-on-Write：当多个序列引用同一个 block 时，写入操作会触发该 block 的完整复制，确保各序列之间的隔离性。

在 Prefix Caching 场景中（如系统相同的 system prompt），如果检测到输入前缀的哈希与已缓存的 block 匹配，可以直接复用，避免重复计算。实测中，对于有共享 system prompt 的在线服务，Prefix Caching 可减少 30%-50% 的首 token 延迟。

2.3 非连续存储的计算兼容性

PagedAttention 的核心技术贡献在于修改了 FlashAttention 内核，使其支持从非连续的 block 中读取 KV 数据。这一修改对性能的影响极小——因为 attention 计算的本质是遍历所有 KV 对，内核只需根据 block table 索引跳转到正确的内存位置即可。实测表明，PagedAttention 引入的计算开销不到吞吐量的 2%。

三、Continuous Batching：请求级动态调度

传统 Static Batching 必须等待批次中最长的序列生成完毕才能释放 GPU，导致大量 GPU 空闲等待。vLLM 的 Continuous Batching（也称为 Iteration-Level Scheduling）在每个 decode 步骤都允许插入新请求或移除已完成请求。

调度策略的关键决策点包括：

• Prefill-Decode 分离：Prefill 阶段计算密集型（并行处理输入 tokens），Decode 阶段访存密集型（逐 token 生成）。混合调度会导致两类请求互相干扰。vLLM v0.4+ 支持将 Prefill 和 Decode 步骤分在不同 GPU 上的调度策略。
• Chunked Prefill：将长序列的 Prefill 分为多个 chunk 与 Decode 交替执行，避免长序列 Prefill 阻塞正在进行的 Decode 延迟。
• 抢占机制（Preemption）：当新请求到达但显存不足时，Block Manager 通过 Swapping（将 block 搬到 CPU 内存）或 Recomputation（丢弃 KV Cache 后续重算）来释放显存。

四、并行策略与模型切分

4.1 Tensor Parallelism

对于 70B+ 模型，单张 A100/H100 无法容纳所有参数。Tensor Parallelism (TP) 将模型的权重矩阵按列/行切分到多个 GPU 上，每个 GPU 只持有模型的一部分。

以注意力层的 QKV 投影矩阵为例，按列切分为 TP 份后，每个 GPU 计算自己负责的 head 子集，最后通过 AllReduce 汇总结果。vLLM 支持基于 Ray 的多 GPU 分布式部署，自动处理跨节点通信。

4.2 Pipeline Parallelism

Pipeline Parallelism (PP) 按模型层间切分——前半部分层在 GPU 0，后半部分在 GPU 1-PP-1。PP 的优势是通信量更小（只需传递激活值），但存在流水线气泡（bubble）问题。vLLM 在超大模型部署中支持 TP+PP 混合策略。

五、量化技术：精度与性能的平衡

vLLM 对 INT8 (SmoothQuant)、GPTQ、AWQ 和 FP8 量化均提供完善支持。生产环境中推荐使用 AWQ，其在 4 位权重下仍能保持较好的生成质量。

六、推理优化技术栈

6.1 Speculative Decoding

使用一个小型草稿模型（如 70M 参数的 TinyLLaMA）先行推测生成多个 token，再由大模型一次性验证。如果草稿模型命中率高（通常对特定领域可达 70%+），等效于将解码速度提升 2-3 倍，且不损失输出分布。vLLM 支持配置独立的小模型作为 draft model。

6.2 KV Cache 量化与分页调度联合优化

将 KV Cache 量化为 INT8 或 FP8 可将每个 token 的显存占用减半。结合 PagedAttention 的分页机制，总并发请求数可翻倍。需要注意的是量化可能引入 attention 计算误差，建议通过 perplexity 测试确定可接受的量化位宽。

6.3 CUDA Graph 优化

vLLM 将多个 decode steps 封装为 CUDA Graph 执行，消除 Python 解释器开销和 CUDA kernel launch 延迟。对于短序列场景，CUDA Graph 可提升吞吐量 15%-25%。限制是 batch size 需预先确定，Dynamic batching 场景下需要按最大 batch size 捕获 graph 后选择性执行。

6.4 多 LoRA 动态加载

生产环境中常需要为不同租户/任务加载不同的 LoRA adapter。vLLM 支持 LoRA 的按需加载和缓存，同一基础模型可共享 KV Cache block 和参数内存，仅在 attention 层注入 LoRA 旁路计算。这种方式可在单张 A100 上同时服务数十个微调模型实例。

七、生产级部署架构

一个完整的 LLM 推理服务需要以下组件协同工作：

┌─────────────────────────────────────────────────┐
│                   Load Balancer                  │
│              (请求路由 + 限流 + 认证)              │
└──────────────────────┬──────────────────────────┘
                       │
         ┌─────────────┼─────────────┐
         ▼             ▼             ▼
   ┌──────────┐  ┌──────────┐  ┌──────────┐
   │ vLLM     │  │ vLLM     │  │ vLLM     │
   │ Instance │  │ Instance │  │ Instance │
   │ (GPU 0)  │  │ (GPU 1)  │  │ (GPU 2)  │
   └──────────┘  └──────────┘  └──────────┘
         │             │             │
         └─────────────┼─────────────┘
                       ▼
              ┌─────────────────┐
              │  Monitor/Metric │
              │  (TTFT/TBOT/TPOT)│
              └─────────────────┘

关键生产指标包括：

• TTFT (Time To First Token)：首个 token 的生成时间，受 Prefill 阶段延迟影响，目标 < 200ms
• TPOT (Time Per Output Token)：每个输出 token 的间隔，受 Decode 阶段延迟影响，目标 < 50ms（约 20 TPS）
• 吞吐量 (tokens/sec)：单位时间处理的 token 数，取决于 batch size 和 KV Cache 容量
• 并发请求数：同时处理的请求数，受 KV Cache 显存和调度策略限制

八、性能调优实战案例

案例：Llama-2-70B 在 4×H100 上的部署优化

初始配置下（FP16 + 基础 vLLM），吞吐量仅为 80 tokens/sec，TTFT 为 520ms。经过以下优化后达到生产可用水平：

1. 切换为 FP8 量化（利用 H100 原生 FP8 支持），KV Cache 减少 50%
2. 启用 Chunked Prefill（chunk_size=512），TTFT 降至 180ms
3. 设置 max_num_seqs=256，利用 PagedAttention 提高并发
4. 开启 Prefix Caching，对共享 system prompt 的请求减少重复计算
5. 优化后的实测结果：吞吐量提升至 350 tokens/sec，TTFT 降至 80ms（短输入），并发请求数从 8 提升至 64

调优参数速查表

九、未来演进方向

LLM 推理部署领域仍在快速演进，几个值得关注的方向：

• Disaggregated Serving：Prefill 和 Decode 阶段分离到不同 GPU 甚至不同节点上，彻底解决两类计算互相干扰的问题。NVIDIA 和 vLLM 社区已在推进该方案。
• 异构内存扩展：将部分 KV Cache 从 GPU HBM 扩展到 CPU DDR5 甚至 NVMe SSD，支持超长上下文（百万级 token）推理。
• MLA (Multi-head Latent Attention)：DeepSeek 提出的注意力优化方案，通过将 KV 压缩为隐变量，将推理显存占用降低到传统 MHA 的 1/5 以下。
• MoE 推理优化：针对 Mixtral/Jamba 等 MoE 架构的稀疏激活特点，实现 expert-parallel 的动态路由与内存管理。

总结

vLLM 的成功证明了将系统思维带入 ML 推理领域的巨大价值。PagedAttention、Continuous Batching 和 Prefix Caching 三大技术叠加，将 LLM 服务的吞吐量提升了数倍。对于开发者而言，理解这些底层原理不仅有助于调优自己的推理服务，也能在选择部署方案时做出更合理的权衡。随着硬件（H200/B200）和软件栈（FlashInfer、TensorRT-LLM）的演进，LLM 推理效率将持续提升，但 PagedAttention 所代表的分页与虚拟化管理思想，将在很长一段时间内保持其基础地位。