vLLM(高性能LLM推理引擎)
基于 PagedAttention 的高性能 LLM 推理引擎,显著提升吞吐量和内存利用率。
让大语言模型跑得更快、更省显存的专用软件引擎,是模型从训练到上线的关键一环
内容摘要
推理引擎是一类专门用来**加速大语言模型推理过程**的软件工具。模型训练完成后,不能直接拿来服务用户——它需要一个高效的"运行环境"来处理请求、生成回答。推理引擎就是这个运行环境,负责把模型的能力以低延迟、高吞吐的方式交付出去。
推理引擎是一类专门用来加速大语言模型推理过程的软件工具。模型训练完成后,不能直接拿来服务用户——它需要一个高效的"运行环境"来处理请求、生成回答。推理引擎就是这个运行环境,负责把模型的能力以低延迟、高吞吐的方式交付出去。
为什么需要专门的推理引擎?因为大语言模型的推理方式很特殊:它是逐个 Token(词元)生成的。生成一段 200 字的回答,模型可能要跑几百次前向计算,每一次都要保存之前所有 Token 的中间状态(KV 缓存)。如果不做任何优化,一个 70B 参数的模型光放权重就需要 140GB 显存(FP16),再加上 KV 缓存和计算中间值,单张 GPU 根本装不下。
推理引擎通过量化(Quantization,权重压缩)、连续批处理(Continuous Batching,动态调度请求)、分页注意力(PagedAttention,高效管理显存)等技术,把原本"跑不动、跑得慢、跑不起"的模型变成能在生产环境中高效服务的推理服务。
推理引擎内部的优化可以从四个层面理解:
| 层面 | 核心技术 | 解决的问题 |
|---|---|---|
| 显存压缩 | 量化(FP8 / INT4) | 模型太大,GPU 装不下 |
| 请求调度 | 连续批处理 | 多用户请求排队等太久 |
| 缓存管理 | PagedAttention / RadixAttention | KV 缓存碎片化浪费显存 |
| 生成加速 | 推测解码(Speculative Decoding) | 逐 Token 生成太慢 |
量化的核心思路是降低数值精度。模型权重原本用 FP16(16 位浮点数)存储,量化后改用 FP8(8 位)或 INT4(4 位整数)。一个 70B 模型从 FP16 的 140GB 压缩到 INT4 只需约 35GB,就能塞进单张 80GB 的 A100 显卡。现代量化方案(如 AWQ、GPTQ)可以把精度损失控制在 0.5% 以内,实际使用几乎无感。
传统批处理(Static Batching)要等凑齐一批请求才一起算,先到的请求得等后到的。连续批处理打破了这个限制:新请求随时插入,完成的请求随时退出。好比餐厅从"满桌才上菜"变成"点一道上一道",GPU 利用率可以提升 10-20 倍。
生成每个 Token 时,模型都要保存之前所有 Token 的 Key 和 Value 矩阵,这就是 KV 缓存。传统方式为每个请求预分配一大块连续显存,实际往往只用一部分,浪费 60-80%。PagedAttention 借鉴操作系统的虚拟内存机制,把 KV 缓存切成固定大小的"页",按需分配、用完回收,显存利用率提升 30-40%。
逐个 Token 生成的瓶颈在于每次只产出一个 Token。推测解码的做法是:先用一个小的"草稿模型"快速猜测接下来 5-10 个 Token,再让大模型一次性验证。猜对的直接保留,猜错的重新生成。这样一轮就能产出多个 Token,吞吐量可提升 2-3 倍。
推理引擎处理一个用户请求的完整流程:
关键认知:Prefill 和 Decode 两个阶段的计算特征完全不同,这就是为什么有些引擎(如 SGLang)会做"预填充-解码分离"(PD Disaggregation),用不同的 GPU 分别处理两个阶段以获得最佳性能。
图中有三个关键节点需要注意:
| 概念 | 与推理引擎的区别 | 更适合关注的重点 |
|---|---|---|
| 推理框架(如 PyTorch) | PyTorch 是通用深度学习框架,推理引擎是专门为 LLM 推理场景优化的服务系统 | 通用计算图执行 |
| 模型服务框架(如 Triton) | Triton 是通用模型部署平台,可以把推理引擎作为后端集成 | 多模型统一管理和路由 |
| 模型压缩 | 量化只是推理引擎的一个子技术,推理引擎还包括调度、缓存、并行等一整套优化 | 单纯减小模型体积 |
| 训练框架(如 DeepSpeed) | 训练框架优化的是前向 + 反向传播,推理引擎只做前向传播的推理优化 | 梯度计算和参数更新 |
核心区别:
截至 2026 年 3 月的生态格局。
| 引擎 | 开发方 | 核心优势 | 硬件要求 | 适合场景 |
|---|---|---|---|---|
| vLLM | UC Berkeley | PagedAttention,并发稳定性好 | NVIDIA / AMD GPU | 通用生产部署(默认选择) |
| SGLang | UC Berkeley / LMSYS | RadixAttention,结构化输出和多轮对话极快 | NVIDIA / AMD GPU | RAG、多轮对话、结构化生成 |
| TensorRT-LLM | NVIDIA | 深度硬件优化,极致吞吐 | 仅 NVIDIA GPU | 追求最高性能的大规模服务 |
| llama.cpp | 社区 | 纯 C++ 无依赖,CPU/GPU 通吃 | CPU / GPU 均可 | 本地部署、边缘设备、个人使用 |
| Ollama | Ollama Inc | 一行命令运行模型,开箱即用 | CPU / GPU 均可 | 快速原型、本地实验 |
几个关键判断依据:
注意:Hugging Face 的 TGI(Text Generation Inference)已于 2025 年 12 月进入维护模式,不再接受新功能开发。如果你正在使用 TGI,官方建议迁移到 vLLM 或 SGLang。
以下数据综合多方基准测试,仅供量级参考,实际表现受模型大小、硬件配置、请求模式影响很大:
| 指标 | vLLM(H100) | SGLang(H100) | TensorRT-LLM(H100) | llama.cpp(CPU) |
|---|---|---|---|---|
| 吞吐量(tok/s) | ~12,500 | ~16,200 | ~18,000+ | ~50-80 |
| 首 Token 延迟 | 50-80ms | 40-60ms | 30-50ms | 500ms+ |
| 显存利用率 | 高 | 高 | 最高 | 不适用 |
| 配置难度 | 低 | 低-中 | 高 | 低 |
| 常见误区 | 正确理解 |
|---|---|
| "量化一定会大幅降低模型质量" | 现代量化方案(AWQ、GPTQ、FP8)在精心校准后,精度损失可控制在 0.5% 以内,绝大多数应用场景无感知差异 |
| "推理引擎只在 GPU 上有用" | llama.cpp 专门为 CPU 优化,7B 模型量化后在普通笔记本上可达 50+ tok/s,完全可用 |
| "vLLM 一定比 TensorRT-LLM 慢" | vLLM 在高并发场景下的延迟稳定性优于 TensorRT-LLM;SGLang 在多轮对话场景下吞吐量反而更高。没有"绝对最快"的引擎,只有"最适合当前场景"的引擎 |
| "Ollama 和 llama.cpp 是两个完全不同的东西" | Ollama 底层就是 llama.cpp,它是 llama.cpp 的封装。不过 Ollama 正在逐步开发自己的推理后端,两者未来可能分化 |
参考答案:
连续分配有两个问题:一是需要预估最大长度提前分配,实际生成往往远短于最大长度,造成大量显存浪费;二是不同请求释放时间不同,频繁分配释放会造成显存碎片化。PagedAttention 把 KV 缓存切成固定大小的页,按需分配,用完即回收,就像操作系统用分页机制管理内存一样,既避免了浪费,又消除了碎片化。
参考答案:
选 SGLang。因为 1000 个请求共享同一篇文档作为上下文前缀,SGLang 的 RadixAttention 会用 Radix Tree 自动缓存这个共同前缀的 KV 缓存,只需计算一次就能被所有请求复用。vLLM 虽然也支持前缀缓存(Automatic Prefix Caching),但 SGLang 的实现在这种"大量请求共享长前缀"的场景下效率更高,官方基准测试显示可达 3-6 倍吞吐提升。
参考答案:
PD Disaggregation 把 Prefill 和 Decode 分配到不同的 GPU 上执行。Prefill GPU 配置高算力(充分利用计算单元处理输入),Decode GPU 配置高显存带宽(充分利用带宽逐 Token 读取 KV 缓存)。这样两类 GPU 各自发挥硬件优势,避免了混合执行时的互相干扰。代价是:需要在两组 GPU 之间传输 KV 缓存,增加了网络通信开销;同时需要更多 GPU 和更复杂的集群调度,适合大规模部署但不适合小规模场景。
优先展示同分类且标签更接近的内容,方便继续串联学习。
基于 PagedAttention 的高性能 LLM 推理引擎,显著提升吞吐量和内存利用率。
在个人电脑或私有服务器上运行大语言模型的核心概念与工具选择。
大模型从训练完成到上线服务的推理部署架构体系,覆盖内存管理、调度和扩展