课程导入:学习目标、课程结构、vLLM在LLM推理中的定位

欢迎进入《vLLM推理系统架构速览》课程。在正式拆解vLLM的源码与架构之前,我们首先需要回答三个根本性问题:这门课要带你走到哪里?课程如何组织?以及——为什么在2025年的今天,vLLM已经成为大模型推理领域无法绕开的基础设施? 只有把这些问题想清楚,后续对PagedAttention、Continuous Batching、分布式引擎等模块的深入剖析才有坐标系。

1.1 学习目标:从“能跑通”到“看得懂”

很多开发者已经通过 pip install vllm 跑通过推理服务,但停留在“调库”层面。本课程的目标是帮助你建立对vLLM推理系统的全栈认知,具体而言,完成本课程后,你将能够:

  • 理解核心机制:解释PagedAttention如何解决KV Cache显存碎片化问题,说明Continuous Batching为何能显著提升吞吐。
  • 掌握架构分层:清晰描述vLLM的模型层、调度层、分布式层、服务层之间的调用关系与数据流。
  • 具备调优能力:根据--max-num-seqs、--gpu-memory-utilization、--tensor-parallel-size等关键参数,预判推理性能瓶颈。
  • 看懂关键日志:能从vLLM启动日志中提取模型配置、显存分配、并行策略等关键信息。
学习提示: 本课程不要求你逐行阅读源码,但建议你准备好vLLM的GitHub仓库(或本地安装的包路径),在每章结束后对照源码文件结构进行“按图索骥”式的浏览,这比单纯看文档记忆深刻得多。

1.2 课程结构:四阶段递进式设计

整个课程共30章,分为四个递进阶段。每个阶段解决一个层次的问题,从“是什么”逐步走向“怎么改”。

阶段 章节范围 核心主题 能力产出
第一阶段:基础与架构 第1-8章 LLM推理痛点、vLLM整体架构、PagedAttention原理、Continuous Batching调度 能画出vLLM核心组件关系图,解释显存优化原理
第二阶段:核心引擎拆解 第9-16章 模型执行器、KV Cache管理器、调度器策略、采样与输出处理 能阅读关键源码路径,理解一次请求的完整生命周期
第三阶段:分布式与部署 第17-24章 张量并行、流水线并行、推理服务化(OpenAI兼容API)、性能调优 能部署多卡推理服务,并针对吞吐/延迟进行参数调优
第四阶段:进阶与实战 第25-30章 量化集成、LoRA适配、多模态扩展、故障排查与生产实践 能解决生产环境中的显存溢出、超时、负载不均等实际问题

这种设计遵循“原理→机制→实践→排障”的认知路径。前8章是地基,如果对PagedAttention和调度器理解不透彻,后续的分布式调优将无从下手。

1.3 vLLM在LLM推理生态中的定位

要理解vLLM的价值,必须先看清LLM推理的核心矛盾:大模型推理不仅是计算密集型任务,更是显存带宽与容量敏感型任务。一次推理请求中,模型权重(如70B参数约140GB显存)和KV Cache(随序列长度线性增长)共同争夺有限的GPU显存。传统推理框架(如简单的HF Transformers pipeline)存在两个致命问题:

  • 静态批处理:必须等一个batch的所有序列生成完毕才能释放显存,导致短序列被长序列拖累,GPU利用率低下。
  • KV Cache显存浪费:预分配固定大小的显存块,实际使用率往往不足60%,且碎片化严重。

vLLM的破局之道在于两项核心创新:

  1. PagedAttention:将KV Cache划分为固定大小的“页”(block),按需分配,类似操作系统虚拟内存管理,显存利用率接近100%。
  2. Continuous Batching:在请求级进行动态调度,一个序列完成即释放资源,新请求立即插入,实现“流水线式”吞吐。

下图展示了vLLM在推理栈中的位置及其与周边组件的关系:

vLLM 在 LLM 推理技术栈中的定位 应用层 OpenAI SDK / LangChain / LlamaIndex / 自定义HTTP客户端 vLLM 推理服务(本课程核心) OpenAI 兼容 API 服务器 · 请求调度器 · 采样器 · 模型执行器 PagedAttention 显存管理器 · Continuous Batching 动态批处理 (第 2-30 章逐一拆解) 模型权重层 LLM 权重(FP16/INT8/INT4) Tensor Parallel / Pipeline Parallel KV Cache 显存层 PagedAttention 页表管理 Block 分配 / 回收 / 复用 硬件资源层 NVIDIA GPU(H100/A100/L40S等) · 显存带宽 · NVLink / PCIe 互联 传统静态批处理 显存碎片化 · 等待长序列 · 利用率低 vLLM 动态批处理 按页分配 · 请求级调度 · 吞吐提升 2-4 倍

从上图可以看到,vLLM并非替代模型本身,而是位于应用框架与硬件资源之间的“推理操作系统”。它向下管理GPU显存和计算单元,向上提供标准的OpenAI兼容接口,使得上层应用无需关心底层复杂的显存分配和并行调度逻辑。

1.4 典型场景:为什么选择vLLM?

让我们通过一个具体场景来感受vLLM的价值。假设你在企业内部署一个文档问答助手,基于70B模型,使用2张A100(每张80GB显存)。

  • 朴素方案:使用HF Transformers的默认pipeline,设置batch size为4。当4个用户同时提问时,如果其中一个问题特别长(需要生成1000个token),其余3个短问题(生成50个token)必须等待其完成才能释放显存。GPU利用率在长序列生成期间可能降至30%以下。
  • vLLM方案:启用Continuous Batching后,短序列生成完毕立即释放显存,新请求立刻插入。同时PagedAttention将KV Cache按16个token一页分配,显存利用率从约50%提升至95%以上。实测吞吐量(requests/sec)提升2-4倍,且首个token延迟(TTFT)保持稳定。
经验之谈: 在长序列生成占比高的场景(如代码生成、长文档摘要)中,vLLM的显存优化效果尤为显著。如果你的业务中绝大多数请求都是短对话(<100 token),优化收益会相对有限,但仍能获得1.5倍以上的吞吐提升。

1.5 常见误区与学习建议

在开始后续章节前,先澄清几个初学者容易产生的误解:

误区一:vLLM只适合大模型。 实际上,vLLM对7B、13B等中小模型同样有效,只是显存压力较小,优化效果不如大模型明显。
误区二:PagedAttention是“缓存”技术。 它本质是显存管理技术,解决的是KV Cache的分配与复用问题,而非简单的数据缓存。
误区三:vLLM只能跑在NVIDIA GPU上。 虽然CUDA是主要后端,但vLLM已支持AMD ROCm、CPU(推理速度较慢)以及部分华为昇腾硬件。

最后,给出一条贯穿全课程的学习建议:每学完一个模块,回到vLLM的GitHub仓库中对应的源码目录,用10分钟浏览文件结构。 例如学完调度器章节后,打开 vllm/core/scheduler.py,找到你学过的关键类和方法。这种“概念→代码”的对照,能将抽象原理转化为具象记忆。