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 服务需要高并发，同一张卡上要同时服务几十上百个请求；
• 私有化部署受限于显存，客户希望用更少的卡跑更大的模型。

而当时的开源推理栈普遍存在三个问题：

1. KV Cache 预分配浪费严重：transformers按max_length一次性预留显存，实际生成长度远小于上限，导致大量显存被闲置；
2. 批处理能力弱：静态 batch 需要等最慢的请求结束才能释放资源，长短请求混跑时 GPU 利用率极低；
3. 缺少统一的调度与内存管理抽象：每个项目各自造轮子，难以复用。

2.2 学术研究背景

vLLM 的思想并非凭空出现，它站在几条研究脉络的交汇处：

• Orca（OSDI 2022）提出了 iteration-level scheduling（连续批处理）的思想，让请求可以在每个解码步动态进出 batch；
• FlashAttention（2022）优化了注意力计算的内存访问模式，为长序列推理打下基础；
• 操作系统虚拟内存与分页机制：这是 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 利用率大幅提升。

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、Mixtral（MoE）、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 兼容 API：Chat Completions、Completions、Embeddings；
• 支持流式输出、结构化输出（guided decoding / JSON schema / 正则约束）；
• 引入 metrics（Prometheus）、健康检查、优雅退出等生产特性；
• 支持 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 更有价值——因为它的每一次取舍，背后都是对"推理系统到底在优化什么"这个问题的重新回答。