Tools

2026 LLM 推理引擎横评:vLLM、SGLang、TensorRT-LLM 到底选谁

4 min read ·

💡 一句话总结:TGI 退场后,生产级推理是「vLLM 求稳、SGLang 求吞吐、TensorRT-LLM 求极致延迟」三选一,外加 MAX 解异构、llama.cpp 管本地。当推理占了 85% 的 AI 算力账单,这个选择直接写在毛利率上。

一、为什么引擎选型突然变重要了

两年前,把模型跑起来用哪个引擎,是个无关紧要的技术细节。2026 年,它成了财务问题。

原因在上一篇推理经济学里讲过:推理已占企业 AI 算力支出的约 85%。当推理是大头,引擎效率就直接挂钩成本——同一张卡、同一个模型,不同引擎的吞吐能差三成以上,意味着服务同样的流量,GPU 数量和月账单也差三成。

格局也在 2025 年底定型:Hugging Face 把 TGI 转入维护模式,并建议用户迁往 vLLM 或 SGLang。一个时代结束,剩下三个主角加两个变量。逐个看。

二、vLLM:最稳的默认选项

vLLM 是当下事实上的默认引擎,靠 PagedAttention 和连续批处理(continuous batching)成名。它的优势不在某个跑分第一,而在全面

它不是每项都最快,但「最不容易出错、最容易上手」本身就是生产环境最稀缺的属性。没有特别诉求时,从 vLLM 开始。

三、SGLang:吞吐之王

SGLang 是这两年最猛的挑战者,核心武器是 RadixAttention(前缀缓存复用)和高效调度。在实测里它的吞吐常常领先:

这三成在高并发、大批量的离线/批处理场景里是实打实的省钱。代价是生态和文档不如 vLLM 厚,新模型/新硬件适配可能慢半拍。负载是高吞吐批处理、团队扛得住踩坑,选 SGLang。

四、TensorRT-LLM:延迟天花板

TensorRT-LLM 是 NVIDIA 的官方答案,把模型编译成针对特定 GPU 优化的引擎,换来极致性能:

但它的强是有门槛的:编译链复杂、调参陡峭、换硬件或换模型常要重新编译,且基本锁定 NVIDIA 生态。规模大到省下的推理成本远超运维投入、硬件固定 NVIDIA、有硬性 p95 SLA,才值得上 TensorRT-LLM。

五、两个变量:MAX 与 llama.cpp

Modular MAX 是图编译型引擎,卖点是一套 Mojo kernel 同时覆盖 CUDA、ROCm、Apple Metal。如果你被 NVIDIA 单一生态锁定所困、想在 AMD 或苹果芯片上拿到接近的性能,它值得评估——这是异构硬件场景的解药。

llama.cpp 站在另一极:主打 CPU、消费级 GPU、边缘和本地设备,量化支持极强(GGUF 生态)。Ollama 这类本地工具底层就靠它。本地、边缘、个人设备部署,看 llama.cpp。

六、横向对比

引擎强项短板硬件上手难度最适合
vLLM生态最广、最稳单项非最快多厂商通用生产、默认起点
SGLang吞吐最高(约 +33%)生态较薄主 NVIDIA高并发批处理
TensorRT-LLMp95 延迟最优编译复杂、锁 NVIDIANVIDIA大规模在线、硬 SLA
Modular MAX跨 CUDA/ROCm/Metal较新、生态待长异构摆脱单一硬件锁定
llama.cpp本地/边缘、量化强非高并发服务向CPU/消费级本地、边缘、个人

⚠️ 警告:所有这些数字都依赖具体模型、精度、批大小和请求分布。别照搬厂商榜单——用你自己的真实流量各压一遍,才知道哪个引擎在你的账单上最省。

七、一棵选型决策树

把上面浓缩成可执行的判断:

  1. 本地 / 边缘 / 个人设备? → llama.cpp(或基于它的 Ollama)。
  2. 要在非 NVIDIA(AMD/苹果)硬件上跑出性能? → Modular MAX。
  3. 生产服务,先求稳? → vLLM,把业务跑通,再看瓶颈。
  4. 瓶颈是吞吐(高并发/批处理)? → 换 SGLang,约三成吞吐提升直接省卡。
  5. 瓶颈是延迟(硬 p95 SLA)且全是 NVIDIA 卡、规模够大? → 上 TensorRT-LLM。

结语

推理引擎不再是「随便选一个能跑就行」的细节。当它占了 AI 账单的大头,选型就是成本决策。务实的路径是:用 vLLM 快速跑通、用真实负载压测、按瓶颈类型升级——吞吐瓶颈走 SGLang,延迟瓶颈走 TensorRT-LLM,异构走 MAX,本地走 llama.cpp。记住最后一句:会出现在你账单上的,不是榜单上的数字,是你自己流量下的每百万 token 成本。

Frequently asked questions

TGI 都进维护模式了,现在生产部署到底该从哪个引擎入手?
如果没有特别强的诉求,从 vLLM 入手最稳。它社区最大、文档最全、对各种模型和硬件的支持最广,OpenAI 兼容接口开箱即用,遇到问题最容易搜到答案。先用 vLLM 把服务跑起来、把业务跑通,再根据实测瓶颈决定要不要换:吞吐不够换 SGLang,延迟卡 SLA 且全是 NVIDIA 卡就上 TensorRT-LLM。先能用,再最优,别一上来就为了榜单数字去啃 TensorRT-LLM 的编译链。
SGLang 吞吐领先 vLLM 三成左右,是不是无脑选 SGLang?
不是。三成的吞吐优势在高并发、大批量的离线/批处理场景很值钱,但它有代价:SGLang 的生态和文档不如 vLLM 厚,对一些新模型、新硬件的适配可能慢半拍,团队踩坑的成本更高。如果你的负载是低并发、强调单请求延迟、或要频繁上新模型,vLLM 的稳妥往往比 SGLang 的吞吐更重要。吞吐领先是真的,但「领先多少能转化成你省的钱」要看你的实际负载形态。
TensorRT-LLM 性能最强,为什么不是所有人都用它?
因为它的强是有门槛的强。TensorRT-LLM 靠把模型编译成针对特定 GPU 优化的引擎拿到极致延迟和吞吐,但这条编译链复杂、调参陡峭、换硬件或换模型常要重新编译,且基本只服务 NVIDIA 生态。它适合规模大到「省下的推理成本远超运维投入」、硬件固定为 NVIDIA、且对 p95 延迟有硬性 SLA 的团队。对中小规模或要灵活换模型的团队,这套复杂度往往不划算。
Modular MAX 和 llama.cpp 这两个「变量」分别适合什么场景?
Modular MAX 是图编译型引擎,最大卖点是用一套 Mojo kernel 同时覆盖 CUDA、ROCm、Apple Metal——如果你被 NVIDIA 单一生态锁定的处境困扰、想在 AMD 或苹果芯片上拿到接近的性能,它值得评估。llama.cpp 则是另一极:主打 CPU、消费级 GPU、边缘和本地设备,量化支持极强,Ollama 这类本地工具底层就靠它。简单说,跨异构硬件看 MAX,本地/边缘/个人设备看 llama.cpp。
选引擎对成本的影响真有那么大吗?该怎么量化?
影响很直接。同一张 H100、同一个模型,不同引擎的吞吐能差三成以上,意味着达到同样 QPS 你需要的 GPU 数量差三成,月度账单就差三成。量化方法很务实:拿你真实的请求分布(输入/输出长度、并发数)在候选引擎上各压一遍,记录达到目标 SLA 时的单卡吞吐,再换算成「服务你全部流量需要几张卡」,乘以卡的月成本。别看厂商榜单,看你自己负载下的每百万 token 成本,那才是会出现在账单上的数字。
// next.txt ›

Some outbound links in this post are affiliate links — see disclosure.