vLLM基础架构：核心组件、工作原理与框架对比

2.1 为什么需要重新思考推理服务架构

在大模型推理场景中，GPU 的算力利用率往往远低于预期。传统推理框架（如 HuggingFace Transformers 自带的 generate 接口）采用“请求独占”模式：每个请求独立申请显存、独立执行解码循环。这种模式在低并发时表现尚可，但一旦进入高并发场景，显存碎片化、KV Cache 重复分配、GPU 空闲等待等问题会迅速放大，导致吞吐量急剧下降。

vLLM 的核心设计目标，就是通过 PagedAttention 和 Continuous Batching 两大机制，将显存利用率和请求调度效率提升到接近理论极限。理解 vLLM 的架构，是后续进行吞吐调优、稳定性保障的前提。

先建立直觉：vLLM 不是简单地“加速单次推理”，而是“让 GPU 在单位时间内处理更多请求”。它把显存管理从“按请求预留”改为“按需分页”，把调度从“串行等待”改为“微批量连续调度”。

2.2 核心组件与工作原理

vLLM 的架构可以拆解为四个核心模块：KV Cache 管理器（PagedAttention 实现）、调度器（Scheduler）、执行引擎（Executor） 和 推理后端（Backend）。它们之间的协作关系如下图所示。

客户端请求 /v1/completions 调度器 Scheduler Continuous Batching 等待队列 + 抢占策略 KV Cache 管理器 PagedAttention 逻辑块 → 物理块映射 显存利用率 > 90% 执行引擎 Executor GPU worker 管理 张量并行 / 流水线并行 推理后端 Backend V1 / V2 引擎 算子融合 / CUDA Graph 支持量化模型 GPU 显存物理块 块大小 = 16 tokens 逻辑块表（每请求） Req A: 块0→物理2 Req A: 块1→物理5 Req B: 块0→物理1 等待队列（抢占/优先级） 流式输出 增量 token 实时返回 调度器决定“谁先跑”，KV Cache 管理器决定“显存怎么分”

2.2.1 PagedAttention：显存管理的核心创新

PagedAttention 借鉴了操作系统虚拟内存的分页思想。在传统实现中，每个请求的 KV Cache 需要一块连续的显存，且按最大序列长度预留。而 PagedAttention 将 KV Cache 划分为固定大小的物理块（Block），每个块默认存储 16 个 token 的 KV 状态。请求的 KV Cache 不再要求连续，而是通过逻辑块到物理块的映射表动态关联。

这样做带来三个直接收益：

  • 显存碎片化几乎消除：物理块可以分散在显存任意位置，不再需要“找一块足够大的连续空间”。
  • 按需分配：请求实际生成多少 token，就占用多少块，而不是预先按最大长度预留。
  • 块共享：多个请求（如并行采样）可以共享同一个物理块，进一步节省显存。

2.2.2 Continuous Batching：调度策略的升级

传统 Batching 是“同步批处理”：一个批次的所有请求都完成后，才开始下一批。这导致 GPU 在批次尾部出现大量空闲。vLLM 的 Continuous Batching 则采用迭代级调度：

  1. 每轮解码迭代（Decode Step）结束后，立即检查哪些请求已完成。
  2. 完成的请求退出批次，新等待的请求立即加入。
  3. GPU 每一轮都在处理“尽可能满”的批次。

这种机制将 GPU 利用率提升了 2~4 倍，尤其在请求长度差异较大的场景下效果显著。

2.3 请求处理全流程

一个典型请求从进入到返回，经历以下阶段：

客户端请求
   ↓
① 调度器接收，分配序列 ID，放入等待队列
   ↓
② 调度器检查显存空闲块，为请求分配初始 KV 块
   ↓
③ 执行引擎将请求加入当前迭代批次（Continuous Batching）
   ↓
④ 推理后端执行 Prefill（预填充）：处理输入 tokens，生成初始 KV Cache
   ↓
⑤ 进入 Decode 循环：每步生成 1 个 token，更新 KV Cache
   ↓
⑥ 若请求完成（遇到 EOS 或达到 max_tokens），释放 KV 块
   ↓
⑦ 流式返回最终结果
关键点：Prefill 阶段计算密集（处理整个输入），Decode 阶段访存密集（逐个生成 token）。vLLM 对两者采用不同的优化策略——Prefill 使用矩阵乘法优化，Decode 则依赖 KV Cache 的高效读取。

2.4 与常见推理框架的对比

为了更清晰地理解 vLLM 的定位，下表从多个维度对比了当前主流的推理框架：

维度 vLLM HuggingFace Transformers TGI (HF) TensorRT-LLM
显存管理 PagedAttention 分页 静态预留 连续缓存（类似分页） 显存池 + 静态规划
批处理策略 Continuous Batching 无（单请求） Continuous Batching In-flight Batching
吞吐量（高并发） 极高（领先） 低 高 极高（需编译优化）
易用性 高（类 HF API） 最高（原生） 中（需部署服务） 低（需模型转换）
模型支持 广（动态图） 最广 较广 需适配（静态图）
量化支持 GPTQ / AWQ / FP8 bitsandbytes GPTQ / AWQ INT4/INT8/FP8
适用场景 高并发在线服务 研究 / 原型验证 生产环境（HF 生态） 极致性能（固定形状）

2.5 案例：从 HF 迁移到 vLLM 的吞吐变化

某智能客服团队原先使用 HuggingFace Transformers 部署 Qwen2-7B 模型，压测结果如下：

  • 并发 8 路请求时，GPU 利用率仅 35%，平均每请求延迟 2.1s。
  • 显存占用 22GB（其中 KV Cache 预留 12GB，实际使用不到 4GB）。

迁移到 vLLM 后（相同 GPU、相同模型、相同并发）：

  • GPU 利用率提升至 82%，吞吐量从 120 tokens/s 提升至 680 tokens/s。
  • 显存占用降至 16GB，KV Cache 实际利用率超过 85%。

这一提升主要来自 PagedAttention 消除了显存浪费，以及 Continuous Batching 让 GPU 每轮都在处理满批次。

2.6 常见误区与复盘

误区一：认为 vLLM 只是“批处理优化”
实际上，PagedAttention 是更底层的创新。即使批处理策略相同，没有分页显存管理，长序列请求依然会导致大量显存碎片。vLLM 的吞吐优势是“调度 + 显存”双优化的结果。
误区二：忽略 Prefill 与 Decode 的资源竞争
在高并发下，如果同时到达大量长输入请求，Prefill 会占满 GPU 计算资源，导致正在 Decode 的请求延迟飙升。vLLM 后续版本引入了 Prefill/Decode 分离调度，但在早期版本中需要手动配置最大并发数来规避。
复盘建议：在压测 vLLM 时，不要只关注吞吐量，还要观察 KV Cache 命中率、等待队列长度、每轮迭代的 token 数。如果等待队列持续增长，说明调度器已成为瓶颈，应考虑增加实例或调整抢占策略。
← 上一章 📖 返回目录 下一章 →