企业官网建设流程全解析

别问 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 / 硬件 / 生态 / 控制力 / 运维 / 成本分类的判断规则。

版本矩阵

LLM Serving 方案选择不能只问"哪个最快"。这个问题本身就容易误导。

不同框架解决的问题并不一样。vLLM 更像开放模型在线服务的通用默认选项;SGLang 更强调复杂生成程序、Agent、多分支和共享 prefix 复用;TGI 贴近 Hugging Face 生态与既有生产接口;TensorRT-LLM 是 NVIDIA GPU 上的深度性能工程路线;Triton Inference Server 则是通用推理服务平台,不只服务 LLM。

如果把它们放在同一张"速度排行榜"里,结论很容易失真。因为你真正要回答的不是"谁最快",而是:

1. 你的 workload 是普通 chat、RAG、长上下文、Agent、结构化生成,还是语音实时链路?
2. 你的硬件是 NVIDIA GPU、AMD、国产卡、CPU/Mac,还是多机多卡?
3. 你需要的是快速上线、生态兼容、极致吞吐、统一模型平台,还是复杂生成控制?
4. 团队能否承担 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,但你未必能从它的差异化能力里获得足够收益。

如果你的请求有大量重复结构,情况就不同了。例如:

1. 每个请求都带很长的 system prompt。
2. Agent 每轮都带固定工具描述和 schema。
3. few-shot 示例重复出现。
4. RAG 中有一批共享文档片段。
5. 多分支推理从同一个上下文分叉。
6. 代码助手反复使用同一仓库上下文。

这些场景下,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 仍然要根据自回归生成的特点单独选。

一个务实路径是:

1. vLLM 做默认基线。
2. SGLang 针对 Agent/prefix 复用做 A/B 压测。
3. TensorRT-LLM 只在明确大规模性能收益时进入。
4. 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: https://docs.vllm.ai/
• vLLM OpenAI-Compatible Server: https://docs.vllm.ai/en/stable/serving/openai_compatible_server.html
• vLLM Blog,Anatomy of a High-Throughput LLM Inference System: https://vllm.ai/blog/2025-09-05-anatomy-of-vllm
• SGLang Documentation: https://docs.sglang.ai/
• SGLang RadixAttention: https://docs.sglang.ai/advanced_features/radix_attention.html
• Hugging Face Text Generation Inference: https://huggingface.co/docs/text-generation-inference/
• NVIDIA TensorRT-LLM Documentation: https://nvidia.github.io/TensorRT-LLM/
• NVIDIA Triton Inference Server Documentation: https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/
• llama.cpp GitHub: https://github.com/ggml-org/llama.cpp
• Ollama Documentation: https://docs.ollama.com/

错误速查卡

作者:武子康的个人博客