vLLM 推理加速：PagedAttention、FlashAttention 与动态批处理

vLLM 把 LLM 推理当成资源调度问题来做，而不是“算一次就完事的前向传播”。

vLLM 架构

vLLM 的架构有以下特点：

• 架构分层清晰：从用户 API 到调度器，再到核心执行引擎，最后统一返回。
• 关键创新点：
  • Continuous Batching：动态合并请求，提升吞吐。
  • PagedAttention：分页存储 KV Cache，提高显存利用率和并发能力。
• 易用性：兼容 OpenAI API，不需要开发者修改代码即可切换到本地推理。

下图展示了 vLLM 的架构。

vLLM 的分层架构说明：

1. 用户请求层
   • 应用通过 OpenAI API 格式（/v1/completions 或 /v1/chat/completions）发送请求。
   • vLLM 内置一个 API Server，兼容 OpenAI 协议，方便集成。
2. 调度与批处理层
   • 请求调度器（Scheduler）：收集多个用户请求，决定哪些请求可以一起处理。
   • 连续批处理（Continuous Batching）：即使请求长度不同，也能动态合并，避免 padding 浪费。
3. PagedAttention 引擎 & 执行层
   • 管理 KV Cache，采用分页存储（Page Pool）。
   • 类似“虚拟内存”，显存利用率高，支持高并发。
   • 基于 PyTorch / CUDA 内核运行 Transformer 模型。
   • 支持 vLLM 的优化算子，如高效 KV 管理、并行解码。
4. 输出层
   • 生成结果返回给 API Server。
   • 响应格式与 OpenAI 保持一致，开发者无缝切换。

LLM 推理的核心瓶颈是什么？

大语言模型（LLM）推理的性能瓶颈主要体现在以下几个方面：

• 注意力计算（Q × Kᵀ）带来的算力瓶颈
• 重复计算历史 K/V，导致效率低下（可通过 KV Cache 优化）
• 显存管理不合理，容易碎片化和 OOM
• GPU 计算不并行，影响并发和吞吐
• 算子效率低（如传统 PyTorch），浪费大量 FLOPs

vLLM 的加速，核心解决的是 KV Cache、并发调度和高效注意力。

FlashAttention：注意力加速算子

传统 Attention 算法在复杂度和显存访问上都存在低效问题。FlashAttention 的核心创新包括：

• IO-Aware，减少显存读写
• Tile-based 分块计算
• 避免中间矩阵落盘
• 速度提升 2~4 倍

它不是“更快的注意力”，而是“显存访问最优的一种注意力”。

vLLM、SGLang、TensorRT 等推理引擎都实现了各自的 FlashAttention 优化版本。

PagedAttention：vLLM 最关键的创新（GPU 虚拟内存）

PagedAttention 是 vLLM 的核心创新之一，解决了传统 KV Cache 显存分配的难题。

• KV Cache 是显存中最大的结构（数 GB）
• 传统 Transformers 需要连续显存块，容易 OOM 或碎片化
• 多并发、长上下文场景下尤为突出

PagedAttention 的本质是：在 GPU 上实现类似操作系统的内存分页机制。

下图展示了 PagedAttention 的工作机制：

在该机制下：

• 显存碎片从大块分配变成小页分配
• 多并发请求不再相互阻塞
• 支持超长上下文（100k+）
• 动态分配显存，极大提升利用率

吞吐量可提升 5~20 倍。

Attention vs PagedAttention

在大模型推理中，Attention 机制 是核心计算模块，而 KV Cache（Key-Value 缓存）用于存储中间计算结果以加速生成过程。传统的 Attention KV Cache 需要为每个请求分配一块连续的显存，这在高并发场景下容易导致显存碎片化，影响性能。

下图展示了 传统 Attention KV Cache 和 vLLM 的 PagedAttention 对比。

• 左边（PagedAttention）：把 KV Cache 拆成小的 page，集中放到“Page 池”里统一调度。不同请求只需要维护一个“页表映射”，就能复用显存，极大提高并发吞吐。
• 右边（传统方式）：每个请求都要一整块连续显存来存 KV Cache，随着请求数量和长度增加，很快会出现碎片，导致显存浪费。

TensorRT-LLM：编译器 + 低精度优化

TensorRT-LLM 采用编译器优化和低精度算子（如 FP8/INT8）进一步提升推理速度。

• FP8/INT8 低精度推理，大幅提升速度
• 离线编译（fusion、kernel tuning）
• 针对 NVIDIA GPU 极致调优
• 适合企业高吞吐场景（API 服务）

缺点：

• 编译慢
• 模型兼容性差
• 调优复杂
• 不适合频繁更新模型或多模型共存

总结：

• 企业生产推荐 TensorRT
• 开发、多租户、在线服务推荐 vLLM

多批次并行：动态 Batch（vLLM/SGLang 的核心能力）

动态批处理是 vLLM 和 SGLang 的核心能力之一，极大提升了推理吞吐。

传统 Transformers：

• 一个请求生成过程中，其它请求必须等待（串行）
• 不能把不同用户的 decode batch 合并

vLLM & SGLang:

• 动态 batch，将多个请求的 decode 步骤混合执行
• 单 GPU 支持成百上千个并发
• 推理吞吐从几十 QPS 提升到几千 QPS

下图展示了动态批处理的调度流程：

核心思想：

• decode 阶段不依赖上下文顺序
• 多个请求的 token 可以一起算

架构差异：vLLM vs Transformers vs TensorRT vs SGLang

下表对比了主流推理引擎的核心架构与特性：

总结：

• Transformers → 教科书实现
• vLLM → 工程优化之王：动态调度 + PagedAttention
• SGLang → 工程优化 + 结构化输出最强
• TensorRT → GPU 编译器极限优化，吞吐第一

为什么 vLLM 比 HuggingFace 快这么多（总结）

核心原因一句话：

vLLM 把 LLM 推理当成“资源调度问题”来做，而不是“算一次就完事的前向传播”。

具体包括：

• PagedAttention → 显存虚拟化
• 动态批处理（并发极强）
• 高效 KV Cache 管理
• FlashAttention 优化算子
• 专为 API 服务设计

所以：

• HF Transformers：模型结构解释器
• vLLM：高性能推理操作系统（LLM Serving OS）

总结

vLLM 之所以能实现远超 HuggingFace Transformers 的推理加速，核心在于其工程创新：PagedAttention 显存分页、动态批处理、KV Cache 管理和高效注意力算子。它将 LLM 推理视为资源调度问题，极大提升了吞吐和并发，是现代大模型推理的事实标准。