前言

2023 年，加州大学伯克利分校的一间实验室里，几个研究生正盯着 GPU 利用率监控面板发愁。他们在用 HuggingFace Transformers 部署一个 13B 参数的语言模型，GPU 显存利用率不到 40%——大量显存被浪费在碎片化的 KV Cache 分配上。请求排队，延迟飙升，但 GPU 其实在"发呆"。

"操作系统早就解决了这个问题，"其中一个人说，"内存分页。"

这句话成了一切的起点。

他们把操作系统中虚拟内存的分页机制引入到 KV Cache 管理中，设计了 PagedAttention 算法。KV Cache 不再按请求整块分配，而是被切分为固定大小的"页"，按需映射，动态回收。就像操作系统管理物理内存一样优雅。

这个想法最终凝结成一篇论文和一个开源项目——vLLM。

论文发表后不到一年，vLLM 的 GitHub 星标突破了 60,000。从硅谷创业公司到国内大厂，从学术实验室到生产集群，几乎所有认真对待 LLM 推理效率的团队都在用它。它成为了 LLM 推理基础设施的事实标准。

为什么需要这本书

vLLM 的文档告诉你怎么用，但不会告诉你为什么这样设计。

GitHub 上的 Issue 和 PR 记录了每一次变更，但缺乏一根串联全局的线索。你可能读过 PagedAttention 的论文，理解了核心思想，却发现真正的代码库比论文复杂十倍——因为工程实践中要处理的边界情况远比论文描述的多得多。

这本书试图填补这个空白。

我们不只是阅读源码，而是追问每一个设计决策背后的动机：为什么 V1 引擎要从单进程改为多进程？为什么调度器要消除预填充和解码的区分？为什么前缀缓存可以做到零开销？这些"为什么"比"怎么做"重要得多——理解了动机，你就能在自己的系统中做出类似的判断。

本书的源码版本

本书基于 vLLM v0.8.x，这是一个里程碑版本：V1 引擎在这个版本中正式成为默认架构。V1 是对整个推理引擎的重新设计——多进程架构、统一 Token 调度、零开销前缀缓存、分段 CUDA 图——几乎每个核心子系统都被重写。

选择 v0.8.x 而非更早版本，是因为 V1 代表了 vLLM 团队对"推理引擎应该长什么样"这个问题的最新思考。理解 V1，就是理解 LLM 推理引擎设计的前沿。

书中的所有源码引用都标注了具体的文件路径和行号，例如 vllm/v1/engine/core.py:42。我建议你在阅读时打开一份源码对照查看：

# 获取本书分析的 vLLM 版本
git clone --branch v0.8.5 https://github.com/vllm-project/vllm.git
cd vllm

# 核心源码目录
ls vllm/v1/          # V1 引擎核心
ls vllm/v1/core/     # 调度器、KV Cache 管理
ls vllm/v1/worker/   # Worker、ModelRunner
ls vllm/model_executor/  # 模型加载、量化、并行层

纸上得来终觉浅，亲手翻源码才能真正内化。

为什么是 vLLM

在 vLLM 之前，LLM 推理领域并不缺少方案：HuggingFace 的 Transformers 可以直接推理，NVIDIA 的 TensorRT-LLM 提供了极致优化，还有 DeepSpeed-Inference、CTranslate2、llama.cpp 等各具特色的框架。

vLLM 的独特之处在于它找到了一个黄金平衡点：

• 比 Transformers 快 14-24 倍——通过 PagedAttention 和连续批处理
• 比 TensorRT-LLM 易用得多——纯 Python 接口，pip install vllm 即可使用，不需要模型转换
• 开源且社区驱动——Apache 2.0 协议，2000+ 贡献者，快速迭代

更重要的是，vLLM 的设计决策具有教育价值。它的每一个优化都基于清晰的动机，每一个架构选择都可以追溯到具体的性能瓶颈。阅读 vLLM 的源码，不仅是学一个工具，更是学习如何设计高性能系统。

TensorRT-LLM 的代码以 C++ 为主，读起来门槛高。llama.cpp 专注于本地推理，架构相对简单。vLLM 用 Python（配合少量 CUDA 内核）实现了生产级的推理引擎，代码可读性和系统复杂度的比例恰到好处——足够复杂到能教会你真实的工程权衡，又足够清晰到能在一两个小时内读懂一个子系统。

本书的读者

这本书为以下读者而写：

• AI 工程师——你在生产环境中部署 LLM 服务，想理解推理引擎的内部机制以便做出更好的调优决策
• 系统开发者——你正在构建或改进推理系统，想学习 vLLM 的架构设计和工程实践
• 研究者——你在探索推理优化算法，需要理解工程实现与论文描述之间的差距
• 好奇者——你对"这个每天处理数十亿 Token 的系统是怎么工作的"这个问题感到好奇

你不需要精通 CUDA 编程，但需要对 Python 和基本的深度学习概念有一定了解。对 Transformer 架构的注意力机制有基本认知会让你读起来更顺畅。

本书的组织

全书分为五篇，按照从外到内的顺序组织：

第一篇：全景（第 1 章）从一个推理请求的完整生命旅程出发，建立对整个系统的直觉。这是后续所有章节的地图。

第二篇：引擎核心（第 2-5 章）深入 vLLM 的心脏——EngineCore、调度器、PagedAttention 和 KV Cache 管理。这四章是理解 vLLM 的基石。

第三篇：执行层（第 6-9 章）探索 GPU 上的实际计算过程——Worker 如何执行前向传播、模型如何加载、CUDA 图如何加速、采样如何工作。

第四篇：性能优化（第 10-13 章）剖析让 vLLM 快人一步的四把利器——前缀缓存、分块预填充、投机解码和量化。

第五篇：分布式与工程（第 14-18 章）讨论多卡/多机部署、多模态推理、LoRA 适配、API 服务器，以及贯穿全书的设计哲学总结。

每一章都遵循同样的节奏：先讲"为什么需要"，再讲"怎么设计"，最后回到源码"怎么实现"。理论→设计→代码，循环往复，螺旋上升。

一点私心

写这本书有一点私心。

推理引擎是 AI 基础设施中最"隐形"的一层——用户看到的是 ChatGPT 的流畅输出，开发者看到的是 OpenAI 兼容的 API，但很少有人关注中间那个把 Token 一个一个"挤"出来的引擎在做什么。它就像自来水管道——打开水龙头就有水，但没人想过水是怎么从水库送到你家的。

我希望这本书能让更多人看到管道里面的风景。

不是因为每个人都需要自己造管道，而是因为理解管道的人，才能在需要时修好它、改进它，甚至设计出更好的管道。

在 AI 大规模落地的今天，推理效率决定了 AI 能服务多少人。理解推理引擎，就是理解 AI 普惠的底层逻辑。

在写这本书的过程中，我反复阅读了 vLLM 的源码，每次都有新的发现。有些设计第一遍看觉得"为什么要这么复杂"，第二遍看才理解"原来这里在解决这个问题"，第三遍看会感叹"这个方案真优雅"。我希望这本书能帮你跳过前两遍的困惑，直接进入第三遍的愉悦。

源码是不会骗人的。框架在变，API 在变，但好的设计思想不会过时。vLLM 今天用 PagedAttention，明天可能有更好的算法替代它——但"用操作系统的思想管理 GPU 资源"这个跨领域思维，会在你未来的工程生涯中反复发挥价值。

让我们开始这段旅程。

杨艺韬2026 年 4 月，于北京