<aside> 🤩 博客地址：nicooo-wang.github.io

</aside>

1. 课程目标

• 理解 vLLM 的核心设计理念：为什么要专门搞一个推理引擎，而不是直接拿 PyTorch 写个 generate 循环就完事？这背后涉及到传统方法遇到的实实在在的性能瓶颈，以及 vLLM 如何用一套受操作系统启发的设计来解决这些问题。
• 理清推理流程的全生命周期：一个 prompt 进来之后，到底经历了哪些步骤才变成最终输出？
• 大致了解 vllm/nano-vllm 的核心架构：nano-vllm 是一个轻量级的 vLLM 实现，用大约 1200 行 Python 代码实现了可读性很强的代码库，同时保持了与 vLLM 相当的推理速度。我们会了解它的核心模块划分以及各模块之间的协作关系。

2. 核心内容

一、vLLM 解决的核心痛点

不知道你有没有测试过手写pytorch做LLM的推理，或者我猜更多人用的是 Hugging Face Transformers 做推理，如果详细分析过性能数据，可能会发现一个尴尬的现象：GPU 显存占用很高，但实际利用率却时高时低，吞吐量也上不去。这不是你的代码有问题，而是传统推理方式本身就存在几个根本性的局限。

1.1 传统推理的三大痛点

痛点一：KV Cache 的显存碎片化

在llm 推理过程中，每个 token 都会生成对应的 Key 和 Value 向量，这些缓存需要保存在 GPU 显存中。传统方法为每个请求分配一块连续的内存空间。

问题在于，当某些请求完成并释放内存后，会在显存中留下不连续的"空洞"。新来的请求如果需要比这些空洞更大的连续空间，就无法利用这些已释放的内存——这与早期操作系统面临的内存碎片化问题如出一辙。

痛点二：静态批处理的低效

传统的批处理方式是"静态"的：凑齐一批请求，等整个 batch 全部完成，再接收下一批。问题是，不同请求的输出长度差异可能非常大——有的请求生成 10 个 token 就结束了，有的要生成 500 个。

这导致了一个荒谬的局面：先完成的请求不得不"陪跑"，占着显存干等其他请求。GPU 利用率随着请求逐个完成而不断下降，直到整个 batch 结束后才能恢复。

痛点三：预分配造成的浪费