部署开源大模型时，最纠结的问题往往是「用哪个推理引擎」。vLLM 名气最大，SGLang 说它更快，TensorRT-LLM 标称性能最高，LMDeploy 主打国产芯片，还有 Ollama、llama.cpp 这些「傻瓜式」方案——各说各话，到底怎么选？这篇文章基于 2026 年公开基准与社区实践，用一张对比表加一棵决策树把选型问题讲透。
对比对象的项目地址：vLLM、SGLang、TGI、LMDeploy、llama.cpp。
一、先搞清楚：推理引擎解决什么问题
模型权重训练好后，上线提供服务需要解决三个问题：吞吐（每秒能处理多少请求/token）、延迟（用户等多久拿到第一个 token）、显存效率（同样的卡能扛多少并发）。原生 Transformers 库只是「能跑」，并不为高并发优化；推理引擎在 KV Cache 管理、批处理调度、算子优化三个层面做文章，把硬件的潜力榨出来。2023 年 vLLM 的 PagedAttention 横空出世后，行业迅速进入「引擎军备竞赛」。
二、六大引擎逐个看
- vLLM（UC Berkeley Sky Computing + 社区）：Apache 2.0，PagedAttention + 连续批处理，支持 200+ 模型架构，OpenAI 兼容 API 开箱即用——2026 年生产环境的事实默认，社区最活跃、新架构支持最快；
- SGLang（UC Berkeley + LMSys）：Apache 2.0，核心是 RadixAttention 前缀缓存复用，在共享前缀场景（RAG、多轮对话）下吞吐领先，结构化输出与 MoE（专家混合）模型支持是它的强项；
- TensorRT-LLM（NVIDIA）：Apache 2.0，基于 TensorRT 深度优化，NVIDIA 显卡上绝对性能最高，但每个模型首次部署需要约 28 分钟的引擎编译，冷启动成本高；
- TGI（Hugging Face）：Apache 2.0（含附加条款），与 HF 生态集成最顺，曾是生产主流——但 2025 年 12 月已进入维护模式（不再积极开发），新项目不建议选它，HF 官方也建议迁移到 vLLM/SGLang；
- LMDeploy（上海 AI 实验室 + 阿里）：Apache 2.0，Turbomind 引擎 + W4A16 量化，对 Qwen 系列与国产芯片（华为昇腾等）深度优化，国内政企/国产硬件场景首选；
- llama.cpp / Ollama：MIT 协议，CPU/Apple Silicon/边缘设备友好，本地轻量使用首选，但不适合面向客户的高并发场景。
三、性能对比（H100 公开基准）
以下为 Llama 3.3 70B FP8 单卡 H100、100 并发下的公开基准数据（约 2026 年初）：
| 引擎 | 吞吐(tok/s) | 首字延迟 p95(ms) | 冷启动 |
|---|---|---|---|
| TensorRT-LLM | 约 2780 | 680/1280 | 约 28 分钟编译 |
| SGLang | 约 2460 | 710/1380 | 约 58 秒 |
| vLLM | 约 2400 | 740/1450 | 约 62 秒 |
| LMDeploy | 中等 | 良好 | 约 45 秒 |
| llama.cpp/Ollama | 低（约 155@50并发） | 波动大 | 约 5 秒 |
注：小模型场景差异更大——Llama 3.1 8B 单卡 H100 上，SGLang 约 16200 tok/s vs vLLM 约 12500 tok/s；TensorRT-LLM 有更高的理论峰值，但 28 分钟/模型的编译代价只适合「固定模型 + 长期高流量」的场景。
四、SGLang 的 RadixAttention 到底强在哪
理解了 PagedAttention 之后，SGLang 的差异化就很好懂了。PagedAttention 解决的是「显存碎片」问题，但默认只在单次请求内部复用 KV Cache，请求结束后缓存就被丢弃。而 SGLang 的 RadixAttention 更进一步：它把 KV Cache 组织成一棵基数树（radix tree），跨请求做前缀匹配——只要新请求和之前的某个请求共享相同的前缀（哪怕只共享一部分），就直接复用已算好的 KV 结果，不再重复计算。
这个机制配合「缓存感知调度」（cache-aware scheduling），会优先调度共享前缀更长的请求，近似对基数树做深度优先遍历，把缓存命中率拉满。真实业务中的命中率相当可观：
- 少样本提示（few-shot）：85-95%；
- 多轮对话：75-90%；
- 代码分析：60-80%；
- 混合生产流量：50-70%。
反直觉的一点是，vLLM 也有前缀缓存（Automatic Prefix Caching，APC），但它是「块级哈希」——把 KV Cache 切成固定块再哈希匹配，需要块边界对齐才能命中；而 SGLang 是「token 级基数树」，能自动发现任意长度的共享前缀，无需手动配置。所以同样是前缀缓存，在动态、多轮、RAG 这类场景里，SGLang 的命中率和收益通常更高。
五、SGLang vs vLLM：实战数据怎么看
这是社区争论最多的一对，把几组公开基准摆出来就清楚了：
- Llama 3.1 8B 单卡 H100：SGLang 总吞吐约 16200 tok/s vs vLLM 约 12500 tok/s（+29%）；输出 token 吞吐 SGLang 约 894 tok/s vs vLLM 约 413 tok/s（+117%）；首字时间（TTFT）SGLang 约 79ms vs vLLM 约 103ms（快约 23%）。
- Llama 3.3 70B FP8：差距收窄到个位数（约 2400 vs 2460 tok/s），说明模型越大、预填占比越低，RadixAttention 的优势越小。
- 前缀共享场景：缓存命中时 SGLang 吞吐最高可达 vLLM 的 6.4 倍；多轮对话实测 SGLang 稳定在 30-31 tok/s，vLLM 从 22 掉到 16 tok/s。
- DeepSeek V3/V4：SGLang 与 DeepSeek 官方合作，针对 MLA（多头潜在注意力）做了深度优化，推理速度可达 vLLM 的 3.1 倍。
- 无共享前缀的独立请求：两者几乎打平（差异 2-4% 以内），甚至 vLLM 在部分单轮唯一 prompt 场景反而略快（60 vs 52.7 tok/s）。
所以结论不是「谁吊打谁」，而是「看负载形态」：前缀越共享、越动态，SGLang 越占优；负载越独立、越固定，两者越接近，这时 vLLM 更大的社区和更广的硬件支持就更重要。结构化输出（JSON Schema 约束）也是 SGLang 的强项——它把 xgrammar 有限状态机直接集成进调度器，几乎零开销地做模式验证，而 vLLM 的传统 guided decoding 在高批量下开销更明显。
六、关键差异总结
- 缓存技术：vLLM 用 PagedAttention（分页 + 块级哈希 APC），SGLang 用 RadixAttention（token 级基数树），共享前缀越多 SGLang 优势越大；
- 维护状态（重要）：TGI 2025 年 12 月进入维护模式——选型时优先排除进入维护期的框架，否则安全补丁与新模型支持都会停滞；
- 硬件取向：NVIDIA 卡极致性能选 TensorRT-LLM，国产昇腾/寒武纪选 LMDeploy，Apple Silicon/CPU/边缘选 llama.cpp；
- 生态集成：与 HF 生态深度耦合选 TGI（存量）或 vLLM（新项目），与阿里云/PAI 集成选 LMDeploy，与 Azure/GitHub 工作流选 Azure AI 托管的 vLLM；
- 社区规模：vLLM 社区最大（GitHub Star 领先，17k+），SGLang 增长最快（15k+ 且持续扩张），二者都支持 OpenAI 兼容 API，中途切换基本不用改业务代码。
七、选型决策树
直接按你的场景对号入座：
- 个人/小团队，本地或低并发：Ollama（最简单）或 llama.cpp（要控制权）——别碰重型引擎；
- 生产 API 服务，模型类型杂、要省心：vLLM——社区最大、踩坑资料最多、新架构支持最快，是「不会错」的默认选项；
- RAG/多轮对话为主，或重度结构化输出（JSON Schema）：SGLang——前缀缓存与结构化生成是它的主场，实测共享前缀场景比 vLLM 快约 29%；
- 固定模型、长期满负荷、NVIDIA 全栈：TensorRT-LLM——接受首次编译成本换峰值性能；
- 国产芯片/政企合规、Qwen 系列为主：LMDeploy——昇腾等国产卡上表现最好；
- 已有 HF 存量部署：TGI 可继续用，但新需求迁移到 vLLM/SGLang 更稳妥。
八、给新手的组合建议
如果刚开始接触，最省心的路径是：本地试玩用 Ollama → 单机服务用 vLLM → 场景特殊再研究 SGLang/TensorRT-LLM/LMDeploy。vLLM 和 SGLang 都提供 OpenAI 兼容接口，中途换引擎不用改业务代码，试错成本很低。
最后提醒一点：任何基准数据都是特定硬件/模型/负载下的快照，选型前最好用你自己的模型和流量形态跑一轮压测（vLLM/SGLang 都内置了 benchmark 脚本），再拍板也不迟。
