LLM 推理引擎的跨框架选型：vLLM、SGLang、TensorRT-LLM 各自赢在哪张牌上

“哪个推理引擎最快”是一个错误的问题。2026 年的工程共识已经收敛成一句话：引擎选择是（硬件 × 负载 × 约束）的函数，而不是“谁最快”的函数。把三个主流框架放在一起看，它们各自赢的是完全不同类型的负载。

vLLM 的核心资产是 PagedAttention 和生态广度。PagedAttention 把 KV Cache 映射到非连续物理块，按需分配，消除连续预留造成的内部和外部碎片。它的定位是“通用生产默认”：供应商中立、模型覆盖最广、OpenAI 兼容接口可以直接替换 base_url。2026 年 10 月的版本已经让 V1 统一调度覆盖 prefix caching、chunked prefill 和 speculative decoding。如果你的痛点是“模型迭代太快，推理栈跟不上”，vLLM 通常是最省心的起点。

SGLang 赢的是共享前缀负载。它的 RadixAttention 用基数树管理 KV Cache，当多个请求共享相同的 system prompt、同一批 RAG 文档或同一组工具定义时，直接复用已缓存的前缀，跳过重复的 prefill。在共享前缀工作负载上，SGLang 相对 vLLM 大约有 29% 的优势，结构化生成场景也有专门的优化。SGLang 的 Rust 前缀缓存核心已经默认启用，PD 实例支持运行时切换角色。如果你做的是多轮对话、RAG 问答或 Agent 工具链，请求之间的前缀复用率很高，SGLang 的结构性收益会比通用吞吐数字更明显。

TensorRT-LLM 赢的是饱和状态下的 NVIDIA 吞吐。它用 NVIDIA 的优化内核做深度联合优化，在某些配置下相对 vLLM 有 30% 到 50% 的吞吐优势，代价是 1 到 2 周的搭建时间和供应商锁定。它的 PyTorch 后端已经成为唯一执行后端，旧 TensorRT execution backend 被移除。如果你的硬件和模型都锁在 NVIDIA 生态里、团队有工程预算做深度调优、并且确实需要把 GPU 压到极限，TensorRT-LLM 值得认真评估；但它不是一个“装上就快”的默认选项。

一个可操作的决策顺序是：先看硬件和模型锁定情况，再判断请求前缀的复用程度，最后看团队运维半径。硬件受限、多模型混跑，vLLM；多轮对话或 RAG 高吞吐，认真测 SGLang；模型和硬件都落在 NVIDIA 优化栈里、且有工程预算，再看 TensorRT-LLM。TGI 已经进入维护模式，2026 年的新项目不应该再选它。推理引擎选型不是“选最强的”，是“选和你的请求形状、硬件约束、团队能力最匹配的”。