模型算法篇难度 3⏱ 9 分钟工具
01vLLM（高性能LLM推理引擎）
基于 PagedAttention 的高性能 LLM 推理引擎，显著提升吞吐量和内存利用率。
vLLM推理引擎PagedAttention高吞吐LLM部署
更新于 2026-03-25vllm
让大语言模型跑得更快、更省显存的专用软件引擎，是模型从训练到上线的关键一环
内容摘要
推理引擎是一类专门用来**加速大语言模型推理过程**的软件工具。模型训练完成后，不能直接拿来服务用户——它需要一个高效的"运行环境"来处理请求、生成回答。推理引擎就是这个运行环境，负责把模型的能力以低延迟、高吞吐的方式交付出去。
推理引擎是一类专门用来加速大语言模型推理过程的软件工具。模型训练完成后，不能直接拿来服务用户——它需要一个高效的"运行环境"来处理请求、生成回答。推理引擎就是这个运行环境，负责把模型的能力以低延迟、高吞吐的方式交付出去。
为什么需要专门的推理引擎？因为大语言模型的推理方式很特殊：它是逐个 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 推理引擎，显著提升吞吐量和内存利用率。
在个人电脑或私有服务器上运行大语言模型的核心概念与工具选择。
大模型从训练完成到上线服务的推理部署架构体系，覆盖内存管理、调度和扩展