别问 LLM Serving 谁最快:vLLM / SGLang / TGI / TensorRT-LLM / Triton 的真实分工
TL;DR
- 场景:团队在为 LLM 在线服务选 inference engine / serving platform 时,经常被"哪个最快"误导,把不同层、不同定位的框架放进同一张速度榜。
- 结论:框架选型不是排名题,是匹配题------vLLM 是默认基线,SGLang 吃复杂生成和 prefix 复用,TGI 走 HF 生态存量路线但已进入维护模式,TensorRT-LLM 是 NVIDIA 极致性能工程,Triton 是多模型统一平台。
- 产出:一张"先分诊、再压测"的决策清单 + 一组按 workload / 硬件 / 生态 / 控制力 / 运维 / 成本分类的判断规则。
版本矩阵
| 功能 / 框架 | 状态 | 说明 |
|---|---|---|
| vLLM OpenAI-Compatible Server | ✅ 已验证 | vLLM 文档稳定支持,提供 /v1/chat/completions 兼容接口与流式输出 |
| vLLM PagedAttention + Continuous Batching | ✅ 已验证 | vLLM 核心机制,KV Cache 分页管理 + 连续批处理 |
| vLLM Prefix Caching + Chunked Prefill | ✅ 已验证 | vLLM 文档支持 prefix cache 与 chunked prefill,降低重复 prefill 成本 |
| vLLM Data Parallel | ✅ 已验证 | vLLM 0.7+ 引入多副本 serving,Router 分发请求到不同副本 |
| SGLang RadixAttention | ✅ 已验证 | SGLang 文档明确支持 radix tree 管理与复用共享前缀的 KV Cache |
| SGLang 结构化生成 / 多分支 | ✅ 已验证 | SGLang 提供面向复杂生成程序的 API,支持多分支采样与结构化输出 |
| Hugging Face TGI | ⚠️ 维护模式 | HF 官方文档对 TGI 定位更谨慎,bug 修复 / 文档优化为主,官方推荐转向 vLLM / SGLang / llama.cpp / MLX |
| TensorRT-LLM Engine / Quantization | ✅ 已验证 | NVIDIA 官方文档支持 kernel 优化、量化、in-flight batching、paged attention、多 GPU/多节点 |
| TensorRT-LLM Expert Parallelism | ✅ 已验证 | NVIDIA 官方支持 MoE 的 expert 切分 |
| Triton Inference Server 多 backend | ✅ 已验证 | Triton 文档支持 TensorRT / PyTorch / ONNX / Python 等多种 backend,支持 ensemble pipeline |
| Triton LLM 专属能力 | ⚠️ 场景相关 | Triton 适合多模型统一平台,但其 LLM 专属能力需要依赖 TensorRT-LLM / vLLM 等 backend |
| Ollama / llama.cpp | ✅ 已验证 | Ollama 与 llama.cpp 文档稳定,适合本地 / 桌面 / 边缘低并发场景 |
LLM Serving 方案选择不能只问"哪个最快"。这个问题本身就容易误导。
不同框架解决的问题并不一样。vLLM 更像开放模型在线服务的通用默认选项;SGLang 更强调复杂生成程序、Agent、多分支和共享 prefix 复用;TGI 贴近 Hugging Face 生态与既有生产接口;TensorRT-LLM 是 NVIDIA GPU 上的深度性能工程路线;Triton Inference Server 则是通用推理服务平台,不只服务 LLM。
如果把它们放在同一张"速度排行榜"里,结论很容易失真。因为你真正要回答的不是"谁最快",而是:
- 你的 workload 是普通 chat、RAG、长上下文、Agent、结构化生成,还是语音实时链路?
- 你的硬件是 NVIDIA GPU、AMD、国产卡、CPU/Mac,还是多机多卡?
- 你需要的是快速上线、生态兼容、极致吞吐、统一模型平台,还是复杂生成控制?
- 团队能否承担 CUDA、TensorRT engine、版本兼容、监控、调度和故障恢复的工程成本?
框架选型不是跟风,也不是一次性押注。更好的方式是先建立一个稳定基线,再用真实压测决定是否升级到更复杂的路线。
一、先把框架放回它所在的层
LLM Serving 系统至少可以分成几层。
最底层是硬件和通信:GPU、显存、NVLink、PCIe、网络、驱动、CUDA、容器运行环境。
再往上是推理引擎:它负责模型加载、KV Cache 管理、prefill/decode 调度、continuous batching、prefix caching、多 GPU 并行、流式输出等能力。vLLM、SGLang、TGI、TensorRT-LLM 都主要在这个层面竞争,只是侧重点不同。
再往上是 serving 平台和编排层:路由、扩缩容、灰度、租户隔离、模型版本管理、Kubernetes 集成、流量治理、监控告警。Triton、KServe、Ray Serve、BentoML、Kubernetes、API Gateway 往往在这一层出现。
最上层才是业务应用:聊天、RAG、Agent、代码助手、语音机器人、内容生成、企业知识库、多模态交互。
很多选型混乱,是因为把这些层混成了一个问题。例如,vLLM 解决的是 GPU 内部的自回归 LLM 调度与 serving;KServe 解决的是 Kubernetes 上的服务生命周期;Triton 是通用推理服务平台,可以承载多种 backend;TensorRT-LLM 是 NVIDIA 深度优化的 LLM 推理库和部署路线。它们可以组合,但不能简单互相替代。
因此,选框架的第一步不是列功能表,而是先问:我现在缺的是底层推理效率,还是服务编排能力?是单模型 LLM serving,还是多模型统一平台?是快速上线,还是追求硬件极限?
二、vLLM:大多数开放模型在线服务的合理起点
对多数团队来说,如果不知道先选什么,vLLM 是合理起点。
它的优势不是某一个单点功能,而是工程组合比较完整:OpenAI-compatible API、流式输出、PagedAttention、continuous batching、prefix caching、chunked prefill、多 GPU 并行、LoRA、量化、多种模型支持,以及活跃社区和生态。
这让 vLLM 很适合承担"默认 LLM Serving 基线"的角色。你可以先用它把 Qwen、Llama、Mistral、DeepSeek 等开放模型稳定服务起来,建立 TTFT、TPOT、tokens/s、GPU util、KV Cache usage、错误率等指标,再决定下一步是否需要更强的 Agent 控制、更深的 NVIDIA 优化,或者更完整的平台编排。
vLLM 适合几类场景:
第一,普通 chat completion 和 OpenAI API 兼容服务。接入成本低,业务层迁移更容易。
第二,需要较高吞吐和流式输出的在线服务。continuous batching 与 KV Cache 管理是这类系统的核心。
第三,希望快速验证模型和业务,而不是一开始就投入复杂 engine 构建。
第四,需要社区活跃、文档丰富、框架更新快。
但 vLLM 不是所有问题的终点。当你的 workload 里有大量共享 prefix、复杂 Agent workflow、多分支生成、严格结构化控制,SGLang 可能更值得评估。当你的线上规模足够大,每一点吞吐优化都能省钱,且团队愿意承担 engine 构建和版本兼容成本,TensorRT-LLM 可能更有价值。当你的系统不只服务 LLM,还要统一管理 CV、ASR、TTS、Embedding、传统模型,Triton 或更完整的模型平台会进入视野。
所以 vLLM 的定位更像:先把 80% 的 LLM serving 问题跑稳,再用真实瓶颈决定是否升级路线。
三、SGLang:复杂生成、Agent、多分支和 prefix 复用更值得看
SGLang 的核心价值不只是"又一个 serving 框架"。它更适合从生成程序和复杂请求结构角度理解。
SGLang 强调高性能 LLM 和多模态模型 serving,同时提供面向复杂生成程序的能力。它的 RadixAttention 用 radix tree 管理和复用共享前缀的 KV Cache,这对 Agent、few-shot、多轮对话、固定系统提示词、工具 schema、RAG 文档复用、代码助手仓库上下文等场景尤其有意义。
如果你的请求大多是普通聊天,并且 prompt 差异很大,SGLang 的 prefix 复用优势不一定能完全体现。它仍然可以 serving,但你未必能从它的差异化能力里获得足够收益。
如果你的请求有大量重复结构,情况就不同了。例如:
- 每个请求都带很长的 system prompt。
- Agent 每轮都带固定工具描述和 schema。
- few-shot 示例重复出现。
- RAG 中有一批共享文档片段。
- 多分支推理从同一个上下文分叉。
- 代码助手反复使用同一仓库上下文。
这些场景下,prefix 复用不只是优化项,而可能直接影响 TTFT、吞吐和成本。
SGLang 也更适合需要生成控制的系统:结构化输出、多步生成、多分支采样、程序化约束、复杂 workflow。相比把所有控制都塞进 prompt,SGLang 的思路更接近把生成过程作为程序来组织。
所以可以这样判断:如果你的核心是"稳定服务普通开放模型",vLLM 往往更直接;如果你的核心是"复杂生成程序 + 大量共享 prefix + Agent workflow",SGLang 值得认真压测。
四、TGI、TensorRT-LLM、Triton:三个名字经常被放在一起,但层次不同
TGI、TensorRT-LLM、Triton 经常被一起讨论,但它们的位置并不相同。
TGI,也就是 Hugging Face Text Generation Inference,是 Hugging Face 生态里的文本生成服务路线。它强调生产部署、token streaming、continuous batching、tensor parallelism、监控与追踪等能力。对已经深度使用 Hugging Face 模型、镜像、部署习惯和运维体系的团队来说,TGI 仍然有现实意义。需要注意的是,Hugging Face 当前文档对 TGI 的定位更加谨慎,选型时要结合项目维护状态、团队已有基础和长期演进路线,而不是只按旧印象判断。
TensorRT-LLM 是另一条路线。它更接近 NVIDIA GPU 上的深度性能工程。它关注 kernel、quantization、in-flight batching、paged attention、KV Cache 管理、多 GPU 多节点、engine 构建、Triton backend 等能力。它适合明确使用 NVIDIA GPU、追求极致性能、流量规模足够大、并且团队有能力处理构建、版本、部署和调优复杂度的场景。
TensorRT-LLM 的问题不是能力弱,而是工程门槛更高。如果只是想快速把 Qwen 14B 服务起来,vLLM 往往更快;如果你已经有稳定大流量,每一点 tokens/s 和延迟优化都能转化为成本收益,TensorRT-LLM 才更值得投入。
Triton Inference Server 则是通用推理服务平台。它支持多种 backend、模型仓库、模型版本、动态 batching、ensemble pipeline、多模型统一 serving。它不仅服务 LLM,也可以服务 CV、ASR、TTS、Embedding、传统深度学习模型。
Triton 的价值在于平台化和统一管理,而不是它天然等同于一个完整的自回归 LLM serving 引擎。实际系统中,Triton 可以和 TensorRT-LLM 结合,也可以作为多模型服务平台的一部分;但如果你的问题是"我要快速部署一个开放 LLM 并做好 KV Cache、continuous batching、流式输出",vLLM 或 SGLang 这类 LLM engine 往往更贴近问题本身。
五、不要把编排层和推理引擎混为一谈
除了上述框架,还经常有人把 Ray Serve、KServe、BentoML、Kubernetes、Triton、vLLM 放在同一张表里比较。这种比较需要小心。
Ray Serve、KServe、BentoML 更像部署和服务管理层。它们可以负责模型部署、路由、扩缩容、Kubernetes 集成、服务生命周期和流量管理。但它们通常不会替代底层 LLM engine。
一个现实架构可能长这样:
Kubernetes 负责编排资源。
KServe 或 Ray Serve 负责服务部署、扩缩容和流量管理。
vLLM、SGLang、TGI 或 TensorRT-LLM 负责单模型推理引擎。
Triton 负责统一多模型推理平台或承载特定 backend。
Prometheus、Grafana、OpenTelemetry 负责监控和追踪。
API Gateway 负责鉴权、限流、多租户和审计。
这几层都重要,但解决的问题不一样。不要因为已经用了 Kubernetes,就以为解决了 LLM serving 调度;也不要因为用了 vLLM,就以为已经拥有完整的平台编排能力。
选型时应该明确边界:哪一层负责 GPU 内部调度,哪一层负责服务生命周期,哪一层负责多租户,哪一层负责观测,哪一层负责业务协议。边界清楚,系统才容易演进。
六、Ollama 和 llama.cpp:本地轻量,不是高并发主线
Ollama 和 llama.cpp 也常出现在对比里。它们很重要,但定位不同。
Ollama 和 llama.cpp 适合本地开发、个人工具、小模型、CPU/Mac、消费级 GPU、低并发服务。它们的优势是简单、轻量、部署快,尤其适合桌面应用、本地助手、离线工具、边缘端实验。
但如果目标是大量在线请求、高并发、GPU 集群、严格 TTFT/TPOT SLO、KV Cache 监控、多副本路由、多租户隔离,它们通常不是主路线。
这不是说它们不好,而是不要让定位错位:
本地体验优先:Ollama / llama.cpp。
生产高并发开放模型:vLLM / SGLang / TGI / TensorRT-LLM。
多模型统一平台:Triton / KServe / Ray Serve / BentoML 与底层 engine 组合。
把轻量工具强行当成高并发 serving 平台,会在并发、观测、调度、故障隔离上补很多工程债。反过来,把 TensorRT-LLM 这种性能工程路线拿来做早期小规模验证,也可能是过度复杂。
七、对语音机器人和 Agent 场景的实际建议
如果目标是 ASR -> LLM -> TTS 的机器人语音链路,本地或私有化 Qwen 模型,A6000 或多卡服务器,我建议把路线拆成三层。
第一层,用 vLLM 建立 LLM serving 基线。先把模型、上下文长度、流式输出、TTFT、TPOT、KV Cache、batching、GPU util、错误率跑清楚。不要一开始就上最复杂路线。
第二层,如果 Agent 请求大量复用系统提示词、工具 schema、固定格式、多轮上下文,单独评估 SGLang。重点看 prefix 复用是否真的降低 TTFT 和成本,多分支/结构化生成是否减少业务层胶水代码。
第三层,如果线上规模足够大,vLLM 或 SGLang 的成本/延迟已经明确不达标,再评估 TensorRT-LLM。这里要把工程成本算进去:engine 构建、模型支持、量化、版本兼容、部署链、监控、故障恢复。
ASR 和 TTS 不要随便和 LLM 混在同一张 GPU 上。它们的延迟结构不同,互相干扰后问题很难排查。语音链路尤其关心首字延迟和流式稳定性,平均 tokens/s 并不能代表用户体验。
如果系统还有大量非 LLM 模型,比如 ASR、TTS、Embedding、视觉模型、传统分类模型,Triton 或更完整的模型服务平台可以作为统一管理层评估。但底层 LLM engine 仍然要根据自回归生成的特点单独选。
一个务实路径是:
- vLLM 做默认基线。
- SGLang 针对 Agent/prefix 复用做 A/B 压测。
- TensorRT-LLM 只在明确大规模性能收益时进入。
- Triton/KServe/Ray Serve 放在平台层讨论,不和 LLM engine 混成一个选项。
八、最终决策树:别问谁最快,问谁匹配
可以用下面这棵决策树做初筛:
如果你不知道选什么,先用 vLLM 建立稳定基线。
如果你强依赖 Hugging Face 生态、已有 TGI 部署或运维习惯,再评估 TGI 是否仍是合适路线。
如果你的核心是复杂 Agent、多分支、共享 prefix、结构化生成,重点评估 SGLang。
如果你在 NVIDIA GPU 上追求极致性能,并且团队能承担 engine、kernel、量化和部署复杂度,评估 TensorRT-LLM。
如果你要统一服务很多非 LLM 模型,或者已有多模型推理平台,考虑 Triton。
如果只是本地个人使用、桌面应用、低并发工具,Ollama/llama.cpp 更轻。
如果你要的是 Kubernetes 上的服务生命周期、扩缩容、流量管理,讨论 KServe、Ray Serve、BentoML,而不是把它们当成底层 LLM engine。
最终结论很简单:框架选型不是排名题,而是匹配题。
vLLM 是通用默认选项。
SGLang 更适合复杂生成和共享 prefix。
TGI 适合 Hugging Face 生态和既有生产路线,但要关注维护状态。
TensorRT-LLM 适合 NVIDIA 极致性能工程。
Triton 适合通用模型服务平台。
Ollama/llama.cpp 适合本地轻量场景。
先用 vLLM 建立稳定 baseline,再根据真实 workload 和压测结果决定是否引入 SGLang、TensorRT-LLM 或更复杂的平台化 serving。不要一开始就追求最强框架,先追求最容易解释、最容易验证、最能持续演进的系统。
参考资料
- vLLM Documentation: docs.vllm.ai/
- vLLM OpenAI-Compatible Server: docs.vllm.ai/en/stable/s...
- vLLM Blog, Anatomy of a High-Throughput LLM Inference System : vllm.ai/blog/2025-0...
- SGLang Documentation: docs.sglang.ai/
- SGLang RadixAttention: docs.sglang.ai/advanced_fe...
- Hugging Face Text Generation Inference: huggingface.co/docs/text-g...
- NVIDIA TensorRT-LLM Documentation: nvidia.github.io/TensorRT-LL...
- NVIDIA Triton Inference Server Documentation: docs.nvidia.com/deeplearnin...
- llama.cpp GitHub: github.com/ggml-org/ll...
- Ollama Documentation: docs.ollama.com/
错误速查卡
| 症状 | 根因 | 定位 | 修复 |
|---|---|---|---|
| 把 vLLM、SGLang、TGI、TRT-LLM、Triton 放进同一张速度榜比较 | 五个框架不在同一层------Triton 是平台、TRT-LLM 是 NVIDIA 深度性能工程、TGI 已进入维护模式、SGLang 侧重 prefix 与复杂生成、vLLM 是通用 LLM engine | 列各框架职责清单,确认目标问题层 | 按层选型:engine 层先 vLLM 跑 baseline,再视场景引入 SGLang/TRT-LLM |
| 用 TGI 部署新模型,但发现版本兼容和 bug 修复变慢 | TGI 已进入 Hugging Face 官方维护模式,只接受 bug 修复与文档优化 | 查 HF 官方 TGI 文档与 release notes | 新项目默认走 vLLM / SGLang;TGI 仅在已有生产链路且迁移成本高时保留 |
| 强 prefix 复用业务(Agent / RAG / 代码助手)用 vLLM 没拿到 prefix 收益 | vLLM 虽有 prefix caching,但与 SGLang 的 RadixAttention 在多分支/共享 KV 上仍有差距 | A/B vLLM vs SGLang,看 prefix 命中率与 TTFT 分布 | 引入 SGLang,显式接入 RadixAttention |
| TensorRT-LLM engine 装好后线上 P99 抖动很大 | engine 构建、量化、版本兼容、kernel 选型任一环节与硬件/驱动不匹配 | 看 engine build 日志、driver / CUDA / TensorRT 版本矩阵 | 重建 engine,锁定 CUDA / TensorRT / driver 版本,加监控 |
| 用了 vLLM 觉得"够用",就没建立基线指标 | 团队没有 baseline 概念,出问题才压测 | 看监控里是否有 TTFT / TPOT / tokens/s / GPU util / KV usage 持续记录 | 先跑一周 baseline,记录 P50/P95/P99,再谈优化 |
| ASR / LLM / TTS 混在同一张 GPU 上,首字延迟和流式不稳定 | 三种负载延迟结构不同,互相干扰后无法解释抖动 | 分卡跑同 workload,看 TTFT / token interval 抖动 | ASR / LLM / TTS 分卡部署,避免抢占 KV / compute |
| Ollama 撑高并发生产,排队与 P95 很差 | Ollama 设计目标是本地轻量,不是高并发 serving | 看 running / waiting / KV usage / context 数 | 把 LLM serving 切到 vLLM / SGLang,Ollama 留作本地/开发 |
| Triton 当成完整 LLM engine 直接用,prefix / batching 不达标 | Triton 是通用推理平台,LLM 专属能力需要靠 backend | 看 Triton backend 选型与 continuous batching 配置 | Triton + TensorRT-LLM / vLLM backend 组合使用,不要裸跑 |
| Kubernetes 已经上了,以为 LLM serving 调度问题解决了 | K8s 解决资源编排,GPU 调度 + 路由 + prefix 仍要 engine 层 | 看 K8s 上是否跑了 vLLM/SGLang,Router 是不是单独的 | 在 K8s 之上明确部署 LLM engine + Router + autoscaler |
| 选了 RTX-LLM 但 engine 没人维护,模型升级断层 | TensorRT-LLM engine 与模型版本强绑定,模型一升就要重建 | 查模型升级 PR / engine rebuild SLA | 把 engine 重建 + 验证流程纳入 CI,固定版本矩阵 |
| vLLM OpenAI 兼容接口调用业务,偶尔 token 流断流 | 客户端读流方式与 vLLM streaming 协议不匹配 | 看 client SDK 是不是 vLLM 推荐版本,看 chunk 类型是否解析对 | 用 vLLM 官方 SDK 或标准 OpenAI 客户端,设置正确的 stream 选项 |
作者:武子康的个人博客