跳转至

Deep Research: [45] vLLM：推理吞吐为什么能上去

  • Source: https://arxiv.org/abs/2309.06180
  • Note: ../notes/ref-045-vllm.md
  • Snapshot: ../sources/md/arxiv-org-abs-2309-06180-ef8b5f9fca84.md

TL;DR

vLLM 通过引入受操作系统虚拟内存启发的 PagedAttention 算法，将大模型推理中的 KV Cache 从传统的连续预分配改为按需切块（Block）存储，在物理显存非连续的情况下实现逻辑连续，彻底解决了显存碎片化和预分配浪费问题，从而在相同硬件成本下将并发吞吐量提升 2-4 倍。

核心观点

  1. 显存管理是推理吞吐的瓶颈：LLM 推理在大并发下的瓶颈往往不在计算算力，而在显存容量（Memory-bound）。显存限制了能同时处理的请求数量（Batch Size）。
  2. 传统预分配机制效率极低：现有系统（如 FasterTransformer）要求 KV Cache 必须物理连续，且必须按最大序列长度（如 2048）预分配。由于实际请求长度参差不齐，导致内部碎片和外部碎片严重，实际显存有效利用率仅 20%-40%。
  3. PagedAttention 算法：借鉴 OS 的虚拟内存分页机制，将 KV Cache 切分为固定大小的块（Block，如 16 或 32 tokens）。这些块在物理显存中可以是不连续的，通过页表映射。
  4. 按需分配，零浪费：显存仅在生成新 Token 需要时才分配一个新的 Block，完全消除了因预估最大长度带来的预留但未用的浪费，将显存浪费率降至 4% 以下。
  5. 原生支持内存共享：基于块的存储结构使得内存共享变得极低成本。对于 Parallel Sampling（一问多答）或 Beam Search，系统可以共享 Prompt 阶段的物理块，仅在生成内容分叉时进行 Copy-on-Write（写时复制）。
  6. 吞吐量显著提升：在相同的延迟水平下，vLLM 相比 SOTA 系统实现了 2-4 倍的吞吐量提升。
  7. 对长文本和复杂解码更友好：序列越长、模型越大、解码算法越复杂（如需要维护多条候选序列），vLLM 的显存优势越明显。
  8. 弹性的调度机制：当显存耗尽时，vLLM 支持将暂时不活跃请求的 KV Blocks 换出（Swap）到 CPU 内存，待显存充裕时再换回，保证系统不会 OOM 崩溃。

可落地做法

工程侧

  1. 替换推理后端：在生产环境中，对于 LLaMA、GPT 等主流结构模型，应优先使用 vLLM 替代原始 HuggingFace 或简单的 PyTorch 推理服务。
  2. 配置调优：
    • Block Size：针对特定 GPU（如 A100/H100）进行基准测试，通常设置为 16 或 32 能获得最佳性能（太小增加寻址开销，太大增加碎片）。
    • Max Number of Seqs：逐步调大允许的最大并发序列数，直到显存利用率稳定在 90% 以上。
  3. 显存监控：建立详细的显存监控面板，不仅看总量，更要看 KV Cache 的占用比例，确保 vLLM 的 Cache Manager 正在有效工作。

产品侧

  1. 利用共享前缀（Prefix Caching）：在 RAG 或企业知识库场景中，设计 System Prompt 时尽量保持头部固定。vLLM 可以自动识别并复用这部分 KV Cache，大幅降低首字延迟（TTFT）并节省显存。
  2. 并发预估重算：在计算 GPU 资源成本时，使用 vLLM 后的单卡并发承载能力应按传统方案的 2-3 倍进行预估，从而节省硬件预算。

检查清单：vLLM 推理服务上线自查

  • [ ] 模型适配性：目标模型架构是否在 vLLM 官方支持列表中？（若为非标模型，需评估自定义 PagedAttention Kernel 的开发成本）
  • [ ] 显存利用率基线：在压力测试下，GPU 显存占用率是否能达到 90% 以上且不发生 OOM？
  • [ ] Block Size 选择：是否测试过不同 Block Size（16 vs 32）下的吞吐量差异？
  • [ ] Prefix Caching 验证：对于固定 Prompt 前缀的场景，是否观察到了显存占用的减少和 TTFT 的降低？
  • [ ] Swap 机制测试：模拟超高并发场景，验证当显存不足时，请求是否正确触发 Swap 或排队，而不是导致服务崩溃。
  • [ ] 解码参数对齐：在使用 Parallel Sampling (n>1) 时，是否确认显存增长符合共享 Prompt的预期（即不应成倍增长）？

常见坑与对策

  1. 误区：vLLM 能降低单请求延迟
    • 真相：vLLM 主要优化的是吞吐量（Throughput）。在低并发下，由于分页管理的开销，单请求延迟可能与传统方案持平甚至微涨。
    • 对策：管理产品预期，强调 vLLM 是为了在同一时间服务更多用户，而非让单个用户更快。
  2. 陷阱：过度依赖 Swap 导致性能骤降
    • 真相：虽然支持 Swap 到 CPU 内存，但 PCIe 带宽是瓶颈。频繁 Swap 会导致严重的推理停顿。
    • 对策：Swap 应作为防止 OOM 的最后一道防线，而非日常运行状态。应通过合理的 Request Limit 限制并发，尽量让活跃请求都在 GPU 显存中。
  3. 陷阱：忽略了 CPU 的开销
    • 真相：vLLM 的调度器和 Block Manager 运行在 CPU 上，极高并发下 CPU 可能成为瓶颈。
    • 对策：部署时确保 CPU 核心数充足，避免 CPU 满载导致 GPU 空转。

可用于丰富《AI 辅助软件产品》的写作点

  • 第 11 章（推理加速与部署） - 原理部分：
    • 使用图书馆书架 vs 活页笔记本的比喻来解释显存管理。传统方式像固定书架，不管书（句子）写没写完都得占位置；vLLM 像活页本，写满一页加一页，且不同人的笔记（Parallel Sampling）可以共享前面相同的页。
    • 强调软件定义硬件效率：在硬件（显存容量）锁死的情况下，通过优秀的软件算法（PagedAttention）挖掘出了数倍的性能潜力。这是工程优化的核心价值。
  • 第 11 章 - RAG 架构优化：
    • 重点介绍 Prefix Caching。在 RAG 场景中，检索到的长文档往往作为 Context 被多个后续问题复用。vLLM 使得这种复用在底层显存级别自动完成，是 RAG 降本增效的关键技术点。
  • 第 10 章（Agent 与 RAG） - 多 Agent 协作：
    • 当多个 Agent 共享同一段背景设定或长文档时，vLLM 的内存共享机制能显著降低多 Agent 运行时的显存开销。