vLLM

3 秒看懂

vLLM 是一个用于大语言模型（LLM）推理与服务的高吞吐量、低延迟开源框架，核心创新是 PagedAttention 算法。它将操作系统的分页内存管理引入 Transformer 的 KV 缓存，几乎消除显存碎片，使显存利用率提升至接近理论极限；配合连续批处理（continuous batching） 等调度优化，在同等硬件上可实现 10–20 倍的吞吐量提升。vLLM 已成为业界最主流的 LLM 服务引擎之一，也是诸多大模型 API 背后的基础设施选择。

3 分钟产业解释

传统 LLM 推理框架（如 HuggingFace Transformers）留给 KV 缓存的显存采用预分配连续区块，产生严重的内部与外部碎片，显存浪费常达 60%–80%，且请求必须按批次静态管理，显存复用效率低。vLLM 于 2023 年由 UC Berkeley 团队提出，其核心贡献在于：

• PagedAttention：将每层 Transformer 的键值缓存划分为固定大小的“页面”（对应于显存块），按需非连续分配，通过页表管理逻辑到物理的映射。这如同操作系统将虚拟内存分页，让 KV 缓存在显存中可以动态增长、共享和回收，将碎片降至极低，显存利用率可接近 100%，且天然支持显存共享（如 parallel sampling、beam search 等场景下多条序列共享同一 prompt 的 KV 缓存）。
• 连续批处理：不再等待批内所有请求完成才释放显存，而是细粒度地逐 token 调度，新请求可即时插入执行，实现了“准在线”的批处理效率，大幅提升 GPU 占用率。

由此，vLLM 在同等模型与硬件下，吞吐量较原生 PyTorch 或 HuggingFace 实现提升一个数量级以上，迅速被 LMSYS 的 Chatbot Arena、Anyscale、BentoML、Amazon SageMaker 等平台采用，并与 PyTorch 生态整合，成为事实上的高性能 LLM 服务标准。

15 分钟专家深入

vLLM 的架构可抽象为三层：中央调度器、分布式执行引擎与PagedAttention 显存管理器。

1. 中央调度器（Scheduler）：维护请求队列，预测每个请求所需页面数量，基于当前显存池状态决策可调度的请求序列。它采用抢占式调度：当新请求到达但显存不足时，可选择将部分已执行序列的 KV 缓存换出到 CPU 内存（swap out），待资源充足时再换回（swap in）。这一机制借鉴了操作系统虚拟内存管理，使系统可承受突发负载而不丢失已计算的中间结果。

2. PagedAttention 内存管理器：以固定大小的 block 为基本单位管理 KV 缓存。每个 block 存有固定数量 token 的键与值张量（如 block_size = 16）。推理过程中，为每个序列维护一个虚拟页表，记录每个逻辑 block 对应的物理 block 地址。写入时按需分配新 block；读取时通过 GPU 自定义核函数根据页表 gather 物理 block 的数据，执行注意力计算。该设计支持：

   • 物理共享：不同序列的 prompt 前缀共享同一物理 block，无需复制，节省大量内存。
   • 即时回收：序列结束后其占用的所有 block 立即被回收，不存在等待同批次其他序列完成导致的浪费。
   • 零碎片：物理 block 的大小统一，分配与回收不产生碎片。

3. 分布式执行引擎：兼容张量并行（tensor parallelism），PagedAttention 的核函数已重写以支持跨 GPU 分片操作。vLLM 提供与 OpenAI API 兼容的接口，方便即装即用。

工程上，vLLM 广泛使用 CUDA/C++ 定制 kernel，如分组查询注意力（GQA）的融合实现、FlashAttention 集成、用于 KV 缓存打包/解包的 high‑bandwidth 核函数，确保了极低的调度与通信开销。

技术原理

PagedAttention 的核心是将每一层 Transformer 的 KV 缓存以块为单位映射。下面用简化图说明注意力计算流程。

传统 KV 缓存：

序列:  [tok1][tok2][tok3] ... [tok N]
显存:  [----------- 连续 K/V 张量 ----------]

分配时必须预留最大长度，内部碎片严重，不同序列无法共享前缀。

vLLM PagedAttention：

逻辑序列（虚拟页号）：VP0  VP1  VP2  VP3
                      ↓    ↓    ↓    ↓
页表映射：            [0 → P3, 1 → P1, 2 → P5, 3 → P2]
物理显存块（block）： P0(空)  P1(占)  P2(占)  P3(占)  P4(空)  P5(占)

注意力核心：给定 Q（查询 token），根据页表将对应的 K、V 块拼接成完整序列，再执行 Scaled Dot-Product Attention。算法伪代码如下：

function PagedAttention(Q, page_table, key_cache, value_cache, block_size):
    # Q: [num_heads, head_dim]
    # page_table: list of physical block indices for this sequence
    num_blocks = len(page_table)
    K_all = []
    V_all = []
    for blk in page_table:
        # 从 key_cache[blk] 读取 [block_size, num_heads, head_dim]
        K_all.append(key_cache[blk])
        V_all.append(value_cache[blk])
    K = concat(K_all, dim=0)   # [sequence_length, num_heads, head_dim]
    V = concat(V_all, dim=0)
    # 执行标准注意力
    scores = matmul(Q, K.T) / sqrt(head_dim)
    attention = softmax(scores)
    output = matmul(attention, V)
    return output

实际实现使用融合核函数，直接在 GPU 上按页表收集并计算，避免了中间的拼接与高带宽内存交换。对于 GQA（分组查询注意力），KV 头数少于 Q 头数，共享机制进一步降低显存压力。

前置条件：

• Transformer 模型必须使用 KV 缓存，且支持按 token 增量推理。
• 显存分配粒度需与 block_size 对齐（典型值 16、32）。
• 需要模型权重的高效显存布局与自定义 CUDA kernel。

连续批处理机制：调度器遍历待处理请求，每步迭代只让每个请求前进一个 token，完成一个 token 后立即检查是否有显存可容纳新请求，并动态插入；已完成序列当即释放资源，使每个 GPU 内核周期都能被充分利用。

技术演进史

• 2022 年前：LLM 推理主流使用 HuggingFace Transformers 等框架，KV 缓存为原始 Tensor 分配，显存利用率仅 30%–40%，吞吐量受限于批处理静态管理。
• 2022 年：FasterTransformer、DeepSpeed-Inference 等出现，引入了核函数融合、张量并行等优化，但 KV 缓存管理仍无根本变革。
• 2023 年 9 月：UC Berkeley 团队发布论文《vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention》，提出 PagedAttention 算法和 vLLM 系统，开源代码。首次将虚拟内存思想应用到推理引擎，吞吐量比 HuggingFace 高出 24 倍（据论文数据）。
• 2023 下半年：快速迭代，增加对 Falcon、Llama 2、Mixtral 等模型的支持，整合 FlashAttention‑2，性能进一步提升。
• 2024 年：prefix caching、推测解码（speculative decoding）等特性集成；增加对 Gemma 等模型的支持；成为多家云厂商的默认推理引擎；vLLM 进入 PyTorch 生态，与 torch.compile 结合探索。
• 2025 年（截至知识截止）：社区活跃，支持数百种模型架构，多模态模型（LLaVA 等）也已适配。竞争框架如 SGLang、TGI 也在持续演进，但 vLLM 在开放性与生态整合上保持领先。

技术路线对比

下面表格展示主流 LLM 服务框架的核心差异（部分数值为定性估算或基于公开基准性能）。

注：吞吐量对比高度依赖于模型大小、序列长度分布、硬件配置，且各框架版本迭代迅速。表中数据基于公开评测与社区反馈，非严格定量科学测试。

上下游

上游——依赖与资源：

• 硬件：NVIDIA GPU（支持 Ampere 以上架构为佳），依赖 CUDA、高带宽显存；对 HBM 容量敏感，vLLM 的高显存利用率变相降低了对显存总量的需求。
• 模型格式：依赖 PyTorch 模型定义，通常从 HuggingFace Hub 加载；支持 GPTQ/AWQ 等量化后的模型。
• 基础软件：PyTorch、CUDA Toolkit、FlashAttention 库、自定义 C++ 扩展。

下游——应用场景：

• 云推理服务：Anyscale Endpoints、AWS SageMaker JumpStart、BentoML 等均基于 vLLM 提供 LLM API。
• 对话系统：LMSYS Chatbot Arena（用于模型竞技场推理）长期使用 vLLM 实现高并发服务。
• 企业内部部署：支持离线批量推理（如数据标注、评估）和在线服务（聊天机器人、代码助手）。
• 多模态应用：LLaVA 等集成了 vLLM 的推理后端。

关键指标

评价 vLLM 部署的关键性能与资源指标：

• 吞吐量（tokens/s）：单位时间生成的输出 token 数。受模型尺寸、批处理效率、序列长度影响。
• 延迟（ms）：首 token 延迟（TTFT）和每个输出 token 的时间。连续批处理可降低 TTFT。
• 显存占用与利用率：GPU 显存峰值使用量与理论可用量的比值。vLLM 可稳定在 95% 以上。
• 可扩展性：张量并行度（多卡）、流水线并行度等对吞吐的线性度。
• 系统鲁棒性：面对请求爆发、超长序列时的 swap 频率和重计算开销（当显存不足时 evict 已计算 KV 缓存导致需重计算）。

具体数字因部署而异，无固定公式。业界部分标杆：使用单张 A100 服务 Llama2‑70B（量化后）达到数十 tokens/s 的吞吐是 vLLM 的典型能力。

供需与市场数据

由于无法检索最新市场报告，以下提供定性趋势分析（截至 2025 年中知识）：

• 需求端：生成式 AI 应用爆发，LLM 推理需求急剧增长。企业出于成本与数据隐私考虑，倾向于自建推理服务，对高吞吐、低延迟框架的需求强劲。vLLM 作为开源首选，占据生态关键位置。
• 供应端：vLLM 由社区和 UC Berkeley Sky Lab 等学术机构维护，无单一供应商控制；贡献者包括多家云厂商与初创公司。该开源模型保障了长期可用性，但商业支持（如托管服务）则通过 Anyscale 等公司提供。
• 市场规模：整体 LLM 推理市场正在高速增长，相关推理软件与服务市场预计数十亿美元级别（各方预测，无精确单一定量）。vLLM 在其中作为基础软件栈，直接收入难以量化，但通过赋能云服务间接贡献巨大。
• 竞争格局：类似开源项目包括 TGI、SGLang 等；商业产品有 NVIDIA Triton Inference Server with TensorRT-LLM、Amazon Bedrock 的内部引擎等。vLLM 凭借 PagedAttention 的先发优势、广泛兼容性与活跃社区保持领先，但性能优势可能随时间被追赶。

代表公司与资本映射

vLLM 是开源项目，其商业价值呈现在生态体系中：

1. Anyscale：由 Ray 团队创办，资助了 vLLM 的早期研发，并提供 Anyscale Endpoints（基于 vLLM 的 LLM 服务）作为商业化产品。已获多轮融资，投资方包括 A16Z、NEA 等。
2. BentoML：提供 ML 模型部署平台，深度集成 vLLM 为其模型服务的核心 runtime。完成种子轮/ A 轮融资。
3. 云厂商：AWS、Azure、Google Cloud 等通过各自 AI Platfrom 支持 vLLM 部署，或在其推理产品中使用类似技术（但通常为自研或集成开源）。
4. 芯片厂商：NVIDIA 自身 Triton Inference Server 与 vLLM 定位有重叠，但 vLLM 的开放性更受开源社区偏爱。AMD、Intel 等也在推动 vLLM 对其硬件的适配，以进入 LLM 推理生态。
5. 初创企业：众多 AIGC 初创公司将 vLLM 作为推理栈核心，间接推高了对推理软件的需求。

资本映射上，投资推理引擎开源项目并非直接，更多是布局能够利用 vLLM 提供差异化服务的上层应用或云平台。专注于推理优化的方向也是风投关注点（如推测解码、硬件加速）。

投资逻辑

若将 vLLM 视作产业链基础件，其投资逻辑可归纳为：

• 赋能型平台价值：vLLM 降低了 LLM 部署的算力门槛，使更多中小企业可以负担大模型推理。这有利于 AI 应用的渗透率提升，间接利好整个 AI 应用层公司。
• 订阅与托管服务：基于 vLLM 的商业推理 API（如 Anyscale）可以实现按调用量收费，商业模式清晰。关注此类公司的增长与客户留存。
• 硬件替代风险：vLLM 的高显存利用率减少了单位吞吐所需的 GPU 数量，可能对 GPU 总需求产生轻微负面替代效应，但更多是推动应用爆发从而抵消。
• 护城河：PagedAttention 算法思想并非不可模仿（如 SGLang 的 RadixAttention、LightLLM 等），但 vLLM 拥有最大的社区、模型兼容矩阵和先发优势，短期内难以被替代。竞争可能导致性能趋同，但生态锁定效应强。
• 风险点：开源项目缺乏专属商业实体，方向依赖社区共识；若主要维护方转向或竞争框架在性能上大幅领先，vLLM 可能被边缘化。此外，底层 LLM 架构变革（如放弃 KV 缓存）可能动摇 PagedAttention 的根本假设。

常见误读纠偏

误读1：“vLLM 是一个模型，或者 vLLM 和 LLaMA 一类。”

• 纠正：vLLM 是推理引擎，不是模型。它本身不包含模型权重，只负责加载模型并高效地提供服务。类似于数据库管理系统之于数据，vLLM 是模型的“操作系统”。

误读2：“PagedAttention 就是普通的分块注意力（block‑wise attention）。”

• 纠正：分块注意力通常指为了节省计算或显存将序列切块计算注意力矩阵，但其 KV 缓存依然是连续或静态分配的。PagedAttention 的关键在于动态虚拟内存映射与页表管理，解决了显存共享、碎片与回收问题，并天然支持物理块共享，这是分块注意力不具备的系统性设计。

学习路径

对于想深入了解 vLLM 的读者：

1. 入门：阅读 vLLM 官方文档 (docs.vllm.ai) 的 “Quickstart” 与 “Serving” 部分，尝试在本地部署 Llama 等模型，体验基本命令。
2. 核心论文：细读《vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention》（arXiv:2309.06180），理解 PagedAttention 的设计空间与调度逻辑。
3. 源码阅读：从 vllm/worker 和 vllm/core/scheduler.py 切入，跟踪一次请求的完整生命周期；接着看 vllm/attention/ops/paged_attn.py 中的定制核函数。
4. 扩展知识：对比学习其他框架如 SGLang（arXiv:2312.07104）的 RadixAttention、TensorRT‑LLM 的 inflight batching，理解不同设计取舍。
5. 系统优化：研究 vLLM 中的 swap 机制、prefix caching、推测解码实现，探索如何在特定硬件上调优 block_size 和并行策略。

一句话总结

vLLM 用操作系统的分页思想，把 GPU 显存当作虚拟内存来管理 LLM 的推理缓存，让大模型服务几乎零资源浪费，把高吞吐推理变成了开箱即用的事。

延伸阅读与来源

• Kwon, W. et al. “vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention.” arXiv preprint arXiv:2309.06180, 2023. 【论文原始来源】
• vLLM 官方 GitHub: https://github.com/vllm-project/vllm 【项目仓库与文档】
• vLLM 官方文档: https://docs.vllm.ai 【安装、配置、模型支持】
• LMSYS Org 技术博客: “How We Made Chatbot Arena Fast and Cost-Efficient” 等文章，阐述了 vLLM 的应用。
• 各云厂商技术博客（AWS、Anyscale、BentoML 等）中关于 vLLM 部署的案例分析。
• SGLang 论文: “Efficiently Programming Large Language Models using SGLang” (arXiv:2312.07104) 提供了与 vLLM 的技术对比视角。

说明：本文写作时依赖作者对 vLLM 项目的公开知识，所有技术细节均基于开源论文与代码，市场数据与竞争格局基于行业定性认知。因搜索功能不可用，未引用最新具体数字报告，相关数值已注明“估算”或“定性”。