首页 / 资讯中心 / 文章详情

vLLM 前世今生:从 PagedAttention 到分布式推理引擎的演进之路

vLLM 前世今生:从 PagedAttention 到分布式推理引擎的演进之路 ★ FEATURED ARTICLE
1. 引言为什么需要 vLLM大模型落地到生产环境时推理服务往往是最先遇到瓶颈的一环。一个 7B 参数的模型在单张 A100 上跑起来并不难难的是在并发请求下把吞吐量做上去、把首 token 延迟压下来、把显存用满又不 OOM。2023 年之前主流方案要么依赖 HuggingFacetransformers的朴素实现吞吐低、显存浪费严重要么使用各家闭源的推理服务开源社区缺少一个既能高效利用显存、又足够通用易用的推理引擎。vLLM 正是在这个背景下出现的。它由加州大学伯克利分校的 Sky Computing Lab 团队提出核心贡献是PagedAttention——把操作系统的虚拟内存分页思想引入 KV Cache 管理一举把显存利用率从 20%~40% 提升到 90% 以上在相同硬件上把吞吐量提升 2~4 倍。本文会从设计动机、行业背景讲起梳理 vLLM 的演进脉络它坚持了什么、放弃了什么、后来又长出了哪些能力以及当前社区最热的方向和未来的可能走向。2. 诞生之前大模型推理的行业环境与研究背景2.1 2022—2023 年的行业环境2022 年底 ChatGPT 发布后大模型从研究走向产品推理成本迅速成为核心矛盾。当时的典型场景是对话类应用需要长上下文、多轮交互KV Cache 占用随序列长度线性增长API 服务需要高并发同一张卡上要同时服务几十上百个请求私有化部署受限于显存客户希望用更少的卡跑更大的模型。而当时的开源推理栈普遍存在三个问题KV Cache 预分配浪费严重transformers按max_length一次性预留显存实际生成长度远小于上限导致大量显存被闲置批处理能力弱静态 batch 需要等最慢的请求结束才能释放资源长短请求混跑时 GPU 利用率极低缺少统一的调度与内存管理抽象每个项目各自造轮子难以复用。2.2 学术研究背景vLLM 的思想并非凭空出现它站在几条研究脉络的交汇处OrcaOSDI 2022提出了 iteration-level scheduling连续批处理的思想让请求可以在每个解码步动态进出 batchFlashAttention2022优化了注意力计算的内存访问模式为长序列推理打下基础操作系统虚拟内存与分页机制这是 PagedAttention 最直接的思想来源——把 KV Cache 切成固定大小的 block用类似页表的结构做逻辑到物理的映射。论文《Efficient Memory Management for Large Language Model Serving with PagedAttention》SOSP 2023系统阐述了这套设计vLLM 就是它的开源实现。3. 设计动机vLLM 想解决什么问题3.1 核心洞察显存是推理吞吐的第一约束在自回归解码中每生成一个 token 都要读取全部模型权重和 KV Cache。当 batch 增大时权重读取被摊薄瓶颈就转移到 KV Cache 的显存占用上。因此能同时容纳多少个请求的 KV Cache直接决定了吞吐上限。论文中的测量显示已有系统里真正用于存储有效 token 的 KV Cache 只占显存的 20%~40%其余被碎片、预留和内部浪费吃掉。3.2 PagedAttention 的设计PagedAttention 把每个序列的 KV Cache 划分为固定大小的 block默认 16 个 token物理 block 不必连续通过 block table 做映射。带来的好处是按需分配只有实际写入 token 时才分配 block几乎消除预留浪费消除外部碎片所有 block 等大不存在大小不一导致的碎片支持共享并行采样、beam search、前缀共享等场景可以让多个序列指向同一物理 block配合 copy-on-write 实现内存复用。3.3 连续批处理与调度在内存管理之上vLLM 引入了 iteration-level 的调度器每个解码步重新决定哪些请求进入本轮 batch新请求可以随时加入完成的请求立即释放 block。这让长短请求混跑时的 GPU 利用率大幅提升。请求队列调度器 SchedulerBlock Manager 分配物理块PagedAttention 计算输出 token释放已完成序列的块4. 早期版本一个快但窄的推理引擎vLLM 最初发布时2023 年上半年定位非常聚焦做一个高吞吐的离线/在线推理引擎。它的能力边界大致是支持 LLaMA、OPT、GPT-NeoX 等少数模型架构只支持 NVIDIA GPU CUDA提供 OpenAI 兼容的 API Server 和离线LLM类两种入口量化支持有限主要是 AWQ/GPTQ 的初步接入没有分布式张量并行之外的并行能力多机多卡支持较弱。这个阶段的 vLLM 用一句话概括把 PagedAttention 这件事做到极致其他先不管。也正因为聚焦它在吞吐 benchmark 上一鸣惊人迅速在开源社区传播开来。5. 发展历程vLLM 增加了什么从 2023 年下半年到 2024 年vLLM 进入快速扩张期几乎每个月都有重要能力落地。可以按几个维度来看。5.1 模型与架构支持从最初的几个架构扩展到几乎覆盖主流开源模型Qwen、Llama 2/3、Mistral、MixtralMoE、DeepSeek、Gemma、Phi、Yi 等支持多模态模型LLaVA、Qwen-VL 等引入多模态输入处理管线支持 MoE 架构的专家并行与高效路由支持投机解码Speculative Decoding包括 draft model、Medusa、EAGLE、n-gram 等多种方案。5.2 量化与显存优化支持 AWQ、GPTQ、SqueezeLLM、FP8含 W8A8、INT8 等多种量化格式引入 KV Cache 量化FP8 KV Cache进一步压缩长上下文显存支持 prefix caching对共享系统提示词的场景可显著降低首 token 延迟。5.3 分布式与规模化张量并行TP单机多卡切分权重流水线并行PP跨机切分层支持更大模型数据并行DP多副本提升吞吐专家并行EP面向 MoE 模型的专家切分与 Ray 集成支持多节点部署与自动扩缩容。5.4 工程化与服务能力更完善的 OpenAI 兼容 APIChat Completions、Completions、Embeddings支持流式输出、结构化输出guided decoding / JSON schema / 正则约束引入 metricsPrometheus、健康检查、优雅退出等生产特性支持 LoRA 多适配器动态加载与切换支持 chunked prefill把长 prompt 的 prefill 拆块与 decode 交错执行改善尾延迟。5.5 硬件生态扩展从纯 NVIDIA 扩展到 AMD ROCm、Intel CPU/GPU、Google TPU、AWS Trainium/Inferentia、华为昇腾等逐步走向硬件无关的推理层。6. 坚持与取舍vLLM 放弃了什么一个项目能长期保持竞争力往往不在于它加了多少而在于它守住了什么、又果断放弃了什么。6.1 始终坚持的东西以显存效率为第一性原理无论加多少功能PagedAttention 式的分块 KV Cache 管理始终是底座高吞吐优先在吞吐与单请求延迟冲突时默认策略偏向整体吞吐OpenAI 兼容接口让用户几乎零成本从其他服务迁移过来开源与社区驱动Apache 2.0 协议模型支持主要靠社区 PR 推动Python 优先的易用性离线LLM类 在线 API Server 双入口的设计一直保留。6.2 主动放弃或弱化的方向放弃只做研究原型的定位早期代码追求简洁后来为了性能大量引入 CUDA/C 自定义 kernel可读性让位于性能放弃对冷门/实验性架构的长期维护部分早期支持的模型架构在后续版本中被移除或降级为社区维护放弃单一后端路线不再只绑定 CUDA而是抽象出平台层代价是不同硬件上的功能对齐存在滞后弱化对 CPU-only 场景的优化CPU 推理更多是能跑而非跑得好不再追求一个引擎通吃所有场景训练侧交给其他框架vLLM 专注推理。7. 当前热点V1 引擎与社区最关注的方向2025 年初vLLM 推出了V1 引擎这是一次架构级重构也是当前社区讨论最集中的话题。7.1 V1 引擎为性能重新设计V1 的核心变化包括更彻底的调度与执行解耦把调度器、KV Cache 管理、执行器拆成更清晰的组件统一的前缀缓存prefix caching 从可选特性变成默认能力且实现更高效更激进的异步与流水线CPU 侧调度与 GPU 侧计算重叠减少空泡更简洁的代码路径去掉历史包袱降低新模型接入成本。7.2 结构化输出与 Agent 场景随着 Agent 应用爆发vLLM 在 guided decoding 上持续投入JSON Schema、正则、语法约束、工具调用tool calling解析等目标是让模型输出可以直接被程序消费。7.3 长上下文与 KV Cache 压缩长上下文是当前最热的战场之一。相关方向包括FP8 KV Cache 的普及KV Cache 的 offload 到 CPU/SSD稀疏注意力、KV 压缩如 MLA 类结构的适配chunked prefill 与 disaggregated prefill/decode 分离部署。7.4 PD 分离Prefill-Decode Disaggregation把 prefill 和 decode 拆到不同实例上执行是 2024—2025 年推理系统的重要趋势。vLLM 已提供相关支持配合 KV Cache 传输层如 NIXL、Mooncake 等可以在保证 TTFT 的同时提升整体吞吐。7.5 生态与上层集成vLLM 已成为大量上层框架的默认推理后端LangChain、LlamaIndex、OpenLLM、KServe、Ray Serve、各类模型网关等。它也在与 Kubernetes 生态如 llm-d、Gateway API Inference Extension结合向推理基础设施标准件演进。8. 未来方向vLLM 想走向哪里结合社区 roadmap 与近期的讨论可以大致勾勒出几条主线。8.1 更极致的性能从高吞吐到低延迟 高吞吐更细粒度的调度策略针对不同 SLA 做差异化调度更完善的投机解码组合降低 decode 阶段的单位 token 成本编译优化torch.compile、自定义 kernel 融合持续深入。8.2 更开放的硬件后端统一抽象层让新硬件接入成本进一步降低在非 NVIDIA 平台上补齐量化、投机解码等高级特性面向国产芯片的适配与性能调优。8.3 面向 Agent 与多模态的原生支持更完善的多模态输入管线图像、音频、视频原生支持工具调用、结构化输出、多轮会话状态管理与 MCP 等协议生态的对接。8.4 分布式推理的标准化PD 分离的标准化接口与 KV 传输协议与 Kubernetes、服务网格的深度集成弹性扩缩容与故障恢复能力。8.5 可观测性与运维友好更细粒度的 metrics按请求、按阶段、按硬件更完善的 tracing 与 profiling 工具面向多租户的配额、隔离与计费能力。9. 总结回顾 vLLM 的发展可以提炼出一条清晰的主线以显存效率为起点以吞吐为目标逐步长成一个通用的推理基础设施。诞生时它用 PagedAttention 解决了 KV Cache 浪费这个最痛的问题发展期它不断扩展模型、量化、并行、硬件支持从快但窄走向全而稳当下V1 引擎、PD 分离、结构化输出、长上下文是社区最热的方向未来它想成为硬件无关、场景无关的推理标准层。对于使用者来说理解 vLLM 的演进逻辑比记住它的 API 更有价值——因为它的每一次取舍背后都是对推理系统到底在优化什么这个问题的重新回答。
阅读完成 · 觉得有帮助?
咨询建站