拆解 vLLM 高吞吐推理架构

dev.to · AI#vLLM#LLM推理#性能优化

Editor brief · 编辑速览

文章从推理受内存带宽制约讲起，解析 vLLM 如何利用 PagedAttention、连续批处理和优化 CUDA 内核提升吞吐。重点说明分页式 KV Cache 如何减少预分配浪费与内存碎片。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

vLLM 本周凭借一篇架构深度解析登上了 Hacker News 首页。如果你正在运行生产级 LLM 工作负载，就很有必要理解 vLLM 是如何实现如此高吞吐量的。下面来看看它的特别之处。

传统的 LLM 推理受限于内存，而不是计算能力。GPU 大部分时间都在等待模型权重从内存中传输过来，而不是真正在执行计算。这就是为什么你无法简单地通过增加 GPU 来解决问题——瓶颈在于内存带宽，而不是 FLOPs。

vLLM 从多个角度解决这个问题：通过 PagedAttention 提升内存效率，通过连续批处理提高吞吐量，并利用经过优化的 CUDA kernel 提升速度。

vLLM 最大的创新是 PagedAttention。它管理 KV cache（模型在生成过程中存储中间状态的内存）的方式，与操作系统管理虚拟内存的方式相同。

在传统推理中，每个请求都会为自己的 KV cache 分配一块连续内存。这意味着：

PagedAttention 将 KV cache 划分为固定大小的页（block）。每个请求的 KV cache 都由一组页组成，而不是一块连续内存。这意味着：

最终结果是：在使用相同 GPU 的情况下，vLLM 能够支持的并发请求数量是 HuggingFace 默认推理引擎的 2～4 倍。

传统推理采用静态批处理：先等待凑齐 N 个请求，把它们组成一个 batch，为所有请求各生成一个 token，然后不断重复。如果某个请求提前完成，它仍要等待其他请求。如果一个新请求在 batch 执行过程中到达，它就必须等待下一个 batch。

连续批处理则是动态的：请求可以在任意 token 边界加入或离开 batch。当一个请求完成时，它会立即退出（无需等待）；当新请求到达时，它会加入当前 batch（无需等待下一个 batch）。

这能显著降低短请求的延迟，并提高混合工作负载的吞吐量。在生产环境中，请求长度往往差异极大——可能是一句话的回答，也可能是一篇 2000 字的文章。此时，连续批处理足以让整体吞吐量从每秒 10 个 token 提升至每秒 100 多个 token。

安装过程非常简单：

pip install vllm

只需一条命令即可启动模型服务：

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --tensor-parallel-size 1 \
  --max-model-len 8192

执行后，你会在 8000 端口获得一个兼容 OpenAI 的 API。只需将现有 OpenAI client 指向 http://localhost:8000/v1，即可直接使用。

在以下情况使用 TGI（HuggingFace）：

在以下情况使用专有 API（OpenAI、Anthropic）：

在单张 A100（80GB）上，以 1K 上下文长度服务 Llama 3.1 8B：

实际结果会因模型大小、上下文长度和硬件而异，但整体规律不变：vLLM 的吞吐量始终比替代方案高出 2～5 倍。

vLLM 代表了 AI 基础设施领域的一次转变：软件层与硬件同等重要。你可以花 30,000 美元购买一张 H100，但如果推理引擎浪费了其中 60% 的内存，你最终得到的性能只相当于一张价值 12,000 美元的 GPU。

随着推理成本逐渐成为 AI 应用支出的主要部分，像 vLLM 这样高效的推理引擎，可能决定一种商业模式究竟能够成立，还是只会不断烧钱。最终赢得 AI 竞争的公司，不会只拥有最好的模型——它们还会拥有最高效的模型服务基础设施。

原始分析灵感来自 Aleksa Gordic 的《Inside vLLM》（HN：74 分）。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。