推理运行时对比：vLLM、SGLang、TensorRT-LLM 与 llama.cpp

当你用 PyTorch 直接把模型 model.generate() 跑起来时，往往很快会撞到一堵墙：显存不够、吞吐上不去、请求排长队。这是因为「训练框架」和「推理服务」是两个不同的问题。本文对比四个主流大模型推理运行时，讲清它们各自的架构取舍，并给出一张按场景选型的决策表。

四个主角分别是：

vLLM：以 PagedAttention 解决显存碎片、主打高吞吐的开源引擎。
SGLang：以 RadixAttention 复用前缀、擅长结构化生成的高性能服务框架。
TensorRT-LLM：NVIDIA 官方出品、为自家 GPU 做极致内核优化的推理库。
llama.cpp：用纯 C/C++ 与 GGUF 格式把模型跑在笔记本、手机甚至嵌入式设备上的本地引擎。

它们没有绝对的优劣，只有适合与否。读完全文，你应该能回答一个问题：我的场景，到底该用哪一个。

为什么需要专用推理引擎

要理解四款运行时各自在优化什么，先要理解标准推理的三个痛点。

KV Cache 是显存大头

Transformer 自回归生成时，每生成一个新 token，都要用到前面所有 token 的注意力键值（Key/Value）。这些中间结果被缓存下来，称为 KV Cache。它的显存占用与「序列长度 × 层数 × 隐藏维度 × 批大小」成正比，常常比模型权重本身还吃显存。

问题在于，传统实现会为每条请求预先分配一段「最大可能长度」的连续显存。一旦分配，哪怕实际只用了其中一小段，其余部分也锁死不能给别人用。这种「预留式分配」带来严重的内部碎片与外部碎片，导致 GPU 显存利用率极低。

连续批处理（Continuous Batching）

训练批处理通常等一个批次的所有样本都完成才开始下一批。但推理场景中，不同请求的生成长度天差地别：有的三句话就结束，有的要写满两千字。如果等整批都完成，短请求就只能干等。

连续批处理（也称动态批处理）的做法是：每个解码步只挑「当前还活着」的请求组批。一旦某条请求生成了结束符，立刻把它移出批次，并把新到达的请求填进来。这样 GPU 始终满载，尾部延迟显著下降。这是现代推理引擎的标配能力。

PagedAttention：把显存当内存分页管理

PagedAttention 的思路借鉴操作系统的虚拟内存分页：不再为每条请求预留一整块连续显存，而是把 KV Cache 切成固定大小的「页」（block），按需分配、零散存放，再用一张映射表把逻辑页拼回连续视图。好处是：

显存按需增长，几乎消灭碎片；
不同请求可共享同一份前缀页（例如相同系统提示词），进一步省显存；
配合连续批处理，单卡可以并发远超权重大小的请求数。

PagedAttention 由 vLLM 率先提出并落地，后来成为行业事实标准，SGLang 的 RadixAttention、TensorRT-LLM 的 paged KV 也都沿用了「分页」这一基本思想。

量化与投机解码

除了显存与批处理，还有两条常见加速路径：

量化：用 INT8、INT4、FP8、FP4 等低精度存储权重与 KV Cache，换显存与带宽。
投机解码：用小草稿模型先猜一串 token，大模型一次性并行验收，无损提速（详见本站「投机解码」教程）。

理解这四点，再看四款运行时在「哪些维度上做到极致」，就清晰了。

vLLM：PagedAttention 与高吞吐

vLLM 最初由 UC Berkeley 的 Sky Computing Lab 发起，如今已是社区最活跃的开源推理项目之一，贡献者超过两千人。它的立身之本就是 PagedAttention，目标是「高吞吐且省显存的服务引擎」。

核心能力（均摘自官方仓库 README，已核验）：

PagedAttention：高效管理注意力的 Key/Value 显存，几乎消除碎片。
连续批处理（continuous batching）：动态组批在途请求。
分块预填充（chunked prefill）与前缀缓存（prefix caching）：缓解长输入的首 token 延迟，并复用相同前缀。
丰富的量化支持：FP8、MXFP8/MXFP4、NVFP4、INT8、INT4、GPTQ、AWQ、GGUF、compressed-tensors 等。
投机解码：支持 n-gram、suffix、EAGLE、DFlash 等草稿策略。
OpenAI 兼容 API 服务：开箱即用的 vllm serve，客户端无需改代码即可从 OpenAI 切过来。
分布式推理：张量并行、流水并行、数据并行、专家并行、上下文并行。
多 LoRA：同一底座上高效挂载多个 LoRA 适配器。
模型覆盖广：Decoder-only LLM（Llama、Qwen、Gemma 等）、MoE（Mixtral、DeepSeek-V3、Qwen-MoE 等）、多模态、嵌入与奖励模型。

一个最小启动示例：

# 安装
uv pip install vllm

# 启动兼容 OpenAI 的本地服务
vllm serve Qwen/Qwen2.5-7B-Instruct --gpu-memory-utilization 0.9

# 客户端用 OpenAI SDK 调用即可
# from openai import OpenAI
# client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")

用文字概括 vLLM 的定位：如果你要在云端提供高并发、多模型、又要易用和兼容 OpenAI 接口，vLLM 通常是首选。

SGLang：RadixAttention 与结构化生成

SGLang（Serve + Generation Language）是另一款高性能服务框架，名字就点明了它的两个关注点：服务（serving）与生成语言（generation language）。它在吞吐上不输 vLLM，但真正差异化的武器是 RadixAttention。

RadixAttention：自动复用前缀

很多真实负载里，不同请求共享大量相同前缀：同一个系统提示词、同一段少量样本（few-shot）、同一条知识库检索结果。RadixAttention 用一棵基数树（radix tree）把已计算的 KV Cache 按前缀建索引，新请求到来时先查树，命中的前缀直接复用，不必重算。官方数据称部分场景可带来最多约 5 倍推理加速。

这带来两个直接好处：

多租户共享系统提示词时，显存与算力都只花一次。
结构化生成、多轮对话、Agent 反复调用同一上下文时，重复计算被大幅压缩。

结构化生成

SGLang 对「结构化输出」做了深度优化，官方称通过压缩有限状态机（compressed finite state machine）做 JSON 解码，可比普通方式快约 3 倍。它配套一个前端 DSL，让你用程序化方式描述「先调用工具、再解析、再生成」的多步流程，框架负责把控制流与生成调度好。

其他已核验的核心能力：

零开销批调度器（Zero-Overhead Batch Scheduler）：把批处理调度本身的开销压到极低。
缓存感知负载均衡器（Cache-Aware Load Balancer）：在分布式部署时，把请求路由到已缓存相关前缀的节点。
Prefill-Decode 分离（PD Disaggregation）、大规模专家并行（EP）。
多后端：除 GPU 外，还有面向 TPU 的 SGLang-Jax 后端。

最小启动示例：

# 安装
pip install sglang

# 启动服务
python -m sglang.launch_server --model-path Qwen/Qwen2.5-7B-Instruct --port 30000

用文字概括 SGLang 的定位：如果你的负载有大量共享前缀、需要稳定可验证的 JSON/结构化输出、或在做复杂的多步 Agent 流程，SGLang 的 RadixAttention 与结构化生成会非常划算。

TensorRT-LLM：面向 NVIDIA GPU 的极致优化

TensorRT-LLM 是 NVIDIA 官方开源的推理库，专为在 NVIDIA GPU 上做高效推理而设计。它的哲学与前面两者不同：不追求跨硬件通用，而是把「在 NVIDIA 卡上跑得最快」做到极致。

已核验的核心能力（摘自官方仓库 README）：

面向 NVIDIA GPU 的优化：从单卡到多卡、多节点部署，利用 Tensor Core 等硬件特性。
自定义与专用内核（custom/specialized kernels）：为注意力、GEMM、MoE 等常见推理操作手写高效内核。
量化：支持 FP8、FP4 等低精度，官方提供量化后的模型集合（例如 DeepSeek FP4）。
运行时算法优化：包含 Prefill-Decode 分离、宽专家并行（Wide Expert Parallelism）、投机解码等。
生态集成：与 NVIDIA Triton Inference Server、NVIDIA Dynamo 无缝衔接；另有 AutoDeploy（beta）后端用于简化 PyTorch 模型部署。

典型工作流是先「构建」再「服务」：用 trtllm-build 把模型编译成优化引擎，再交给 Triton 或直接用 Python API 加载。示意如下：

# 1) 用官方镜像进入构建环境
docker run --gpus all -it --rm -v $PWD:/work nvcr.io/nvidia/tensorrt-llm:latest

# 2) 把检查点转换为 TRT-LLM 格式并构建引擎（示意）
trtllm-build --checkpoint_dir /work/ckpt \
             --output_dir /work/engine \
             --gemm_plugin float16

# 3) 通过 Triton 或直接 API 加载 engine 提供推理

需要说明的一点：TensorRT-LLM 的批处理方式在官方文档中常被称作 in-flight batching（与连续批处理同义），但本次核验所读取的 README 正文未直接出现该术语，此处列为待核实。

用文字概括 TensorRT-LLM 的定位：当你锁定 NVIDIA 硬件、追求单卡或集群的极限延迟与吞吐、并且愿意接受较高的工程复杂度与较长的前期构建流程，它是天花板级别的选择。

llama.cpp：GGUF 与跨平台本地推理

llama.cpp 由 Georgi Gerganov 发起，如今仓库位于 ggml-org/llama.cpp（由原 ggerganov 组织迁移而来）。它的目标与前面三款截然相反：不追云端高并发，而是用纯 C/C++ 把大模型塞进「任何设备」。

已核验的核心事实（依据仓库元数据、目录与提交记录）：

模型格式：GGUF（GPT-Generated Unified Format），自带 gguf-py 转换工具与 convert-hf-to-gguf.py 脚本，把 Hugging Face 模型转成单文件 GGUF。
实现语言：C/C++ 推理，无 Python 运行时依赖，便于嵌入各类原生应用。
跨平台：覆盖 Linux、Windows、macOS、iOS、tvOS、visionOS、Web（WASM/WebGPU），甚至 s390x 等架构；构建脚本含 iOS/macOS 的 XCFramework。
多后端：除 CPU 外，支持 CUDA、HIP/ROCm、Metal、Vulkan、WebGPU 等 GPU 后端。
量化：支持 MXFP4、Q2_K 等多种 GGUF 量化格式，可在几乎不损精度的情况下把模型压到几 GB。
本地部署：自带 server（兼容 OpenAI 接口风格）与本地 Web UI（tools/ui），可完全离线运行。

最小使用示意：

# 1) 克隆并构建（CPU 版）
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build && cmake --build build --config Release

# 2) 用 GGUF 模型交互式对话
./build/bin/llama-cli -m ./models/Qwen2.5-7B-Instruct-Q4_K_M.gguf -p "用一句话解释什么是 KV Cache"

# 3) 启动本地服务（默认 8080 端口，兼容 OpenAI 接口风格）
./build/bin/llama-server -m ./models/Qwen2.5-7B-Instruct-Q4_K_M.gguf

用文字概括 llama.cpp 的定位：当你没有数据中心 GPU、想在笔记本/手机/树莓派上离线跑模型、或要做端侧嵌入应用，llama.cpp 几乎是唯一现实选择。它的代价是单实例吞吐远低于前述三款服务端引擎，不适合高并发线上服务。

选型决策表

把四个维度摊开对比，便于直接拍板：

维度	vLLM	SGLang	TensorRT-LLM	llama.cpp
核心创新	PagedAttention	RadixAttention	专用内核 + 运行时优化	GGUF + C/C++ 引擎
主要目标	高吞吐服务	高吞吐 + 结构化生成	NVIDIA 极限性能	跨平台本地推理
硬件依赖	NVIDIA/AMD GPU	NVIDIA/AMD GPU（含 TPU 后端）	仅 NVIDIA GPU	CPU 及各类 GPU，含端侧
易用性	高，OpenAI 兼容	高，OpenAI 兼容	中低，需构建引擎	高，单文件即跑
量化支持	丰富（FP8/INT4/GPTQ/AWQ 等）	丰富	FP8/FP4 等	丰富（GGUF 系列）
共享前缀复用	前缀缓存	RadixAttention 基数树	前缀缓存	有限
典型场景	云端多模型高并发	共享前缀/Agent/结构化输出	极致延迟与吞吐	本地、离线、端侧
工程复杂度	低	低到中	高	低

再浓缩成一句话建议：

云端通用高并发 API 服务，且要 OpenAI 兼容：选 vLLM。
大量共享前缀、JSON/结构化输出、复杂多步流程：选 SGLang。
锁定 NVIDIA、要榨干硬件极限、能接受构建成本：选 TensorRT-LLM。
本地离线、端侧设备、无 GPU 也能跑：选 llama.cpp。

小结

大模型推理不是「把权重加载进来就能跑」这么简单。显存被 KV Cache 吞噬、请求长短不一拖垮批处理、不同硬件各有最优内核，这些才是真实瓶颈。四款运行时分别从不同角度解题：

vLLM 用 PagedAttention 把显存管理做到极致，是云端高并发的默认答案。
SGLang 用 RadixAttention 自动复用前缀，在共享上下文与结构化生成场景更省。
TensorRT-LLM 放弃通用性换极限性能，是 NVIDIA 硬件上的性能天花板。
llama.cpp 用 GGUF 与 C/C++ 把模型带进笔记本和手机，是本地与端侧的不二之选。

选型没有银弹：先锁定你的硬件边界与服务形态，再让上面的决策表替你做减法。

参考与延伸阅读

vLLM 官方仓库与文档：https://github.com/vllm-project/vllm
SGLang 官方仓库与文档：https://github.com/sgl-project/sglang
NVIDIA TensorRT-LLM 官方仓库：https://github.com/NVIDIA/TensorRT-LLM
llama.cpp 官方仓库（GGUF 格式与转换工具）：https://github.com/ggml-org/llama.cpp
延伸：本站「投机解码」教程，了解无损加速生成的另一种路径。

本文累计阅读 — 次