vLLM vs SGLang vs TGI：推理引擎选型完全指南
大模型推理的吞吐差距，往往不在模型本身，而在 KV cache 怎么管。这篇讲清三种引擎的底层差异。
开篇：连续批处理只是入场券
vLLM、SGLang、TGI 都能提供 OpenAI 兼容接口，都能跑 GPU，都能做连续批处理（continuous batching）——动态把在途请求打包进 GPU 填充算力空位。
在这个维度上三者打成平手。
真正的分水岭只有一个：KV cache 策略。
KV cache 是每个请求的注意力键值缓存，它占据了推理期间 GPU 显存的大头，也直接决定了你同时能服务多少请求。
硬指标对比
维度 | vLLM | TGI | SGLang |
|---|
出身 | UC Berkeley Sky Lab | Hugging Face Research | LMSYS Sky Lab | 签名技术 | PagedAttention | 生产级封装服务 | RadixAttention | KV cache | 分页，低碎片 | 标准，调优良好 | 基数树跨请求共享 | 默认端口 | 8000 | 12434 | 30000 | 结构化输出 | xgrammar / guidance | 支持 | 一等公民 | 并行方式 | 张量/流水线/数据/专家/上下文 | 同类 | 同类 | 许可 | Apache 2.0 | Apache 2.0 | Apache 2.0 |
三者都是 Apache 2.0，都支持 AWQ / GPTQ / FP8 量化。 一、PagedAttention（vLLM 的方案）PagedAttention 借鉴了操作系统的虚拟内存分页思想。 传统做法是为每个请求分配一块连续显存存 KV cache。问题在于：序列长度不一、请求陆续结束，会产生严重的外部碎片。你申请 1GB 连续空间，实际可能只用 40%。 vLLM 的做法是把 KV cache 切成固定大小的页块，物理显存无需连续，通过 block table 完成虚拟地址到物理显存的映射。 请求 A: [页3][页7][页2][页9] ← 物理上分散，逻辑上连续
请求 B: [页3][页5] ← 共享页3？取决于实现
收益：碎片率极低，可用的 KV 显存更多 → 有效 batch 更大 → 吞吐更高。这就是 vLLM 成为默认选择的原因。 它引自 2023 年的论文《Efficient Memory Management for Large Language Model Serving with PagedAttention》(Kwon et al.)，该论文称相比当时 SOTA 系统吞吐可达 6.4 倍。 二、RadixAttention（SGLang 的方案）RadixAttention 解决的是另一种浪费：重复计算。 设想一个真实场景：1000 个请求共用同一个 5000 token 的系统提示词和 few-shot 示例。 前缀只算一次，之后所有请求复用。 这在以下场景收益巨大： 论文来自 LMSYS 2024 年 1 月 17 日的博文，称在 agent 控制、逻辑推理、few-shot、JSON 解码、RAG、多轮对话等场景有显著优势。 三、两种思路的本质区别这是理解两者最关键的一点： | PagedAttention | RadixAttention |
|---|
消除的浪费 | 碎片浪费（内存排布松散） | 重复浪费（前缀被反复计算） | 手段 | 分页，紧凑打包 | 基数树，共享前缀 | 收益条件 | 几乎所有工作负载都有收益 | 仅当请求间有公共前缀 |
一个是 packing，一个是 sharing。 这就是为什么"哪个更快"这个问题必须先描述你的流量特征。 四、按流量特征选型你的流量特征 | 选谁 | 原因 |
|---|
共享长 system prompt（数千请求） | SGLang | 基数树自动复用，零配置 | 多轮对话，每轮重发历史 | SGLang | 每轮都是上一轮的前缀命中 | Agent 循环、树搜索 | SGLang | 分支共享祖先，正是基数树强项 | RL rollout / RLHF 权重同步 | SGLang | 内置 Miles、slime、verl 集成 | 批量任务，每个 prompt 都唯一 | vLLM | 没前缀可复用，杠杆在显存 | 显存受限（batch size 被卡住） | vLLM | 分页正是为消除显存浪费而生 | TPU / Trainium / Gaudi / CPU | vLLM | SGLang 不支持这些后端 | 编码器-解码器模型（T5、BART） | vLLM | 不在 SGLang 支持矩阵内 | 需要多 LoRA 服务 | vLLM | 对 dense 和 MoE 层都支持 | 需要 Anthropic Messages API 兼容 | vLLM | 原生支持 |
注意一个重要变化：vLLM 现在也内置了自动前缀缓存（automatic prefix caching），两者差距在缩小。而且两者都支持 prefill/decode 分离部署。 五、TGI 的定位不同TGI 的目标不是刷吞吐排行榜，而是做一个生产级服务器： 与 Hugging Face Hub 深度集成 模型加载与配置体验成熟 生态完整，运维工具齐全
如果你已经在 HF 生态里，TGI 是稳妥选择。这是一个不同的优化目标——它优化的是"可靠性和集成体验"，而不是合成 benchmark 上的峰值。 六、按路由而非按引擎做决策实务中最常见的情况是流量混合。此时按引擎分流的收益高于选一个引擎吃全部。 请求进入
│
├─ 含长公共前缀？ ──是──► SGLang 实例池
│
└─ 唯一 prompt / 特殊硬件？ ──► vLLM 实例池
两个引擎可以部署在同一套网关后面，网关按请求特征路由。这样既吃到基数树的复用收益，又保留 vLLM 的硬件覆盖广度。 七、容易被误解的性能问题问题一：为什么我看到别人的 benchmark 比我的快好几倍？ 因为 benchmark 几乎总是只测一种工作负载。SGLang 的论文数字来自前缀密集场景，vLLM 的数字来自通用混合流量。用单一场景的数字外推到你的场景是无效的。 问题二：流式输出能降成本吗？ 不能。流式改变的是响应送达方式，不改变模型生成多少 token。两者的计费完全一样。流式用来改善感知延迟，降本要靠限制输出长度。 问题三：编码器-解码器模型怎么办？ 用 vLLM。SGLang 的支持矩阵里没有 T5 / BART 这类架构。 问题四：换引擎要重写多少代码？ 几乎不用。两者都提供 OpenAI 兼容接口。切换主要是改启动参数。 八、启动命令参考# vLLM
pip install vllm
vllm serve meta-llama/Llama-3.1-8B --port 8000
# SGLang
pip install --prerelease=allow sglang
python -m sglang.launch_server --model-path meta-llama/Llama-3.1-8B --port 30000
# TGI
docker run --gpus all -p 12434:80 \
-v $PWD/data:/data \
ghcr.io/huggingface/text-generation-inference:latest \
--model-id meta-llama/Llama-3.1-8B
vLLM 和 SGLang 都支持多 LoRA、投机解码、结构化输出。两者都不直接加载 GGUF——那是 llama.cpp 的地盘，且从 GGUF 转回 safetensors 会丢元数据并降低质量。 九、上生产前的检查项项 | vLLM | SGLang | TGI |
|---|
Docker 镜像 | 官方 | 官方 | 官方 | Helm chart | 官方 | 社区维护 | 社区 | 健康探针 | 官方 | 社区 | 官方 | Prometheus 指标 | 有 | 社区 | 有 | | | | |
| 版本发布节奏 | 双周点版本 | 相对少 | 跟随 HF |
|---|
版本上要做的事：两者都存在升级引入回归的风险，生产环境请锁定容器 digest，不要用 latest。
十、一句话结论
默认选 vLLM —— 覆盖面最广、社区最大、默认最稳
前缀复用是主要杠杆时换 SGLang —— Agent、多轮、few-shot 场景
HF 生态决定性时用 TGI —— 生产成熟度和集成体验
流量混合就分流 —— 两个引擎并存，网关路由
参考资料
vLLM 官方仓库 — https://github.com/vllm-project/vllm
SGLang 官方仓库 — https://github.com/sgl-project/sglang
TGI 官方文档 — https://huggingface.co/docs/text-generation-inference
Kwon et al., *Efficient Memory Management for LLM Serving with PagedAttention* — https://arxiv.org/abs/2309.06180
LMSYS, *SGLang: Efficient Execution of Structured Language Model Programs* — https://arxiv.org/abs/2312.07104
LMSYS Blog, *RadixAttention* 介绍 — https://lmsys.org/blog/2024-01-17-sglang/
