LLM 推理引擎选型矩阵：vLLM、SGLang、TensorRT-LLM 各自赢在哪张牌上，以及那张牌什么时候不是你的牌

“哪个推理引擎最快”是一个错误的问题。2026 年关于推理引擎的公开材料已经形成了一个清晰的共识：性能差距高度依赖负载形状，脱离负载谈吞吐数字，和脱离路况谈百公里加速一样没有意义。

先把三个引擎的结构性优势摆清楚。vLLM 的核心是 PagedAttention 加 continuous batching，把 GPU 显存利用率从 pre-vLLM 时代的 20%—40% 拉到接近饱和，相比 HuggingFace Transformers 有 14—24 倍的吞吐提升。它的定位是通用生产默认：供应商中立、模型覆盖最广、OpenAI 兼容接口可以直接替换 base_url。SGLang 的核心是 RadixAttention 前缀树，它缓存的粒度比 vLLM 基于哈希的 APC 更细，在请求共享前缀的工作负载上——聊天机器人、Agent、RAG——有约 29% 的吞吐优势。TensorRT-LLM 的核心是 NVIDIA 的深度内核优化，在 NVIDIA-only 的高并发场景下比 vLLM 高 30%—50%，但每个模型的搭建需要 1—2 周，模型、精度、最大 batch、最大序列长度任何一个变化都要重建引擎，而且使用 NVIDIA 的专有许可证。

这些数字的适用边界比数字本身更重要。SGLang 的 29% 优势只在“前缀共享比例高”时成立；纯 batch 工作负载上它和 vLLM 打平。TensorRT-LLM 的 30%—50% 优势是在 NVIDIA 硬件、高并发、已经完成深度调优的配置下测出来的；如果你的团队没有 1—2 周的 per-model setup 预算，这个数字不会自动出现在你的集群里。vLLM 的 14—24 倍提升是相对于 Transformers 的，不是相对于 SGLang 或 TensorRT-LLM 的；在一个已经跑着 vLLM 的系统里，“换成 vLLM”不产生任何收益。

还有一个容易被忽略的维度是硬件拓扑。Tensor parallel 在每一层之后都需要做 all-reduce，PCIe Gen4 x16 的约 32 GB/s 带宽比 NVLink 的约 900 GB/s 慢约 28 倍；仅靠 PCIe 做 TP，扩展会崩溃，应该改用 pipeline parallelism 或独立副本。同节点内的跨 NUMA all-reduce 和 PCIe-only 一样糟糕。这意味着引擎选型不能脱离硬件拓扑：一个在 NVLink 集群上跑得很好的 TP 配置，搬到 PCIe 集群上可能完全不可用。

一个可操作的选型矩阵是这样的。硬件锁定在 NVIDIA、模型组合稳定、团队有 1—2 周的 per-model 调优预算、并且确实需要把单副本吞吐压到极限，TensorRT-LLM 是候选。多模型混跑、需要快速适配新模型、想要最宽的生态覆盖，vLLM 是默认。多轮对话、RAG、Agent 工具链、前缀共享比例高，SGLang 的结构性收益值得认真测。如果三者都不是你的形状——比如你只是偶尔跑几个模型、QPS 不高——Ollama 的开发体验很好，但在生产环境超过 10 QPS 时会浪费 80%—95% 的 GPU；把 Ollama 留在开发环境、vLLM 留在生产，是一个更诚实的组合。

推理引擎的选型不是“选最强的”，是“选和你的请求形状、硬件拓扑、团队预算最匹配的”。先把自己的请求画清楚，再看引擎，顺序反了，选谁都会后悔。