已发表的这几个项目之间的对比，把胜者的优势从 29% 一路给到 6.4 倍——同一档硬件、同样的模型。两个数字大概都是诚实的，而它们之所以能差出两个数量级，是因为两者都没说清那个真正决定智能体负载的参数：每个请求里有多大一部分，是你已经付过算力去算的前缀。照这个来挑，你就会发现这场对比里那件让人不太舒服的事——这四者里三个是引擎、一个是路由器，而当你跑起第二个副本的那一刻，你的缓存命中率就压根不再是引擎的性质了。
一眼看全
四个被当作同类来比较的项目，其中三个确实是同类。
| 项目 | 它是什么 | 最新发布 | 你真正在挑的是什么 |
|---|---|---|---|
| vLLM | 推理引擎 | v0.31.0，2026 年 10 月 5 日（大约每两周一次） | 广度：硬件、模型覆盖，以及别人都照着集成的那个默认项 |
| SGLang | 推理引擎 | v0.5.21，2026 年 10 月 2 日（大约每两周一次） | 前缀缓存之上的词元级基数树，如今默认跑在一个 Rust 内核上 |
| TensorRT-LLM | 编译式推理引擎，仅 NVIDIA | 1.3.0rc 这条线，截至 2026 年 9 月下旬仍为 rc | 单卡峰值性能，代价是搭建时间与厂商锁定 |
| Dynamo | 架在这些引擎之上的路由器与服务平台 | v1.5.0，其第 18 个功能版本 | 请求落在哪个 worker 上——也就是前缀缓存到底命不命中 |
Hugging Face 的 TGI 曾是这张表里的第四个引擎，而它的缺席是眼下最有信息量的一个数据点。它在 2025 年 12 月进入维护模式，仓库于 2026 年 3 月 21 日被归档为只读，而它自己的 README 现在把读者指向 vLLM 与 SGLang。它的吞吐没有任何一项变差。是那根坐标轴挪了。
这四者里有一个不是引擎
Dynamo 该排在另一行上，最清楚的证据来自它自己的发布说明：v1.5.0 把 SGLang v0.5.18、TensorRT-LLM v1.3.0rc25 与 vLLM v0.28.0 钉为后端。它跑的就是另外那三个。拿每秒词元数去跟它们比，是一次范畴错误；而不说清上面架着什么就拿另外三个互比，则是更常见、也更昂贵的那一次。
那份版本钉死清单还带着第二笔更安静的成本，值得在采用这个平台之前先给它定价：截至 2026 年 10 月初，上游 vLLM 已到 v0.31.0、SGLang 已到 v0.5.21，比 v1.5.0 所钉的版本领先好几个发布。拿下这个路由器，就意味着一并拿下这个路由器的引擎日历——而在两周一发的节奏下，它落后上游好几个版本。如果你之所以用自托管栈，恰恰是因为你需要上个半月才落地的某个模型或某个算子，那这段落差就是你正在做的那笔交易，而它不会出现在任何一份基准测试里。
已发表的对比为何能差出 6 倍
翻几份 2026 年的头对头对比，那个离散度相当惊人。一份报告称，在 80% 共享前缀、50 并发下，TTFT 中位数从 310 毫秒降到 195 毫秒。另一份报告称，在前缀密集的流量上吞吐最高可达 6.4 倍，同时顺带提到：同一族测试里那个 29% 的数字，适用的是最不利于胜者的那种负载。第三份发现，在缓存压力之下，一个引擎的多轮吞吐塌了下去，而另一个稳住了。
这些不是互相矛盾的结果；它们是三种不同的负载披着同一个标签。缺掉的那根轴是前缀复用——每个请求的词元中，服务端已经为某个更早的请求算过的那一部分。智能体流量就坐在这根轴的极端：系统提示词、工具清单与不断变长的对话历史在每一轮都被重新发一遍，所以边际请求基本上就是一段前缀。有一份文章把「每个请求都带着同样工具定义」的智能体负载放在 75% 到 95% 的复用区间；那个具体数字追不到一次测量上，但形状并无争议，而 NVIDIA 自己那个编码智能体的例子报告称：后续调用只要落到同一个 worker 上，缓存命中率在 85% 到 97% 之间。
于是那个真能替你定下选择的基准测试，恰恰是没人发表的那一个，因为它是你的：你的词元里有多大比例是前缀，而你当前的命中率是多少？两者都已经在你的服务端指标里了。一场在 0% 复用下跑出来的引擎对比，衡量的是你的智能体从不身处的工况；而一场在 90% 复用下跑出来的引擎对比，衡量的主要是缓存实现——这正是同样两个项目会随着「谁跑的测试」而互换位次的原因。
你的缓存是在第二个副本上丢掉的
下面这一段会把整个决策重排一遍。前缀缓存是某个 worker 进程本地的东西。只有一个副本时，一个会话的每一轮必然会遇上前一轮填进去的那份缓存，于是你拿到的就是那些头条命中率。而在一个普通负载均衡器后面挂 N 个副本时，第二轮落到持有第一轮前缀的那个 worker 上的概率大约是 1/N——这是 NVIDIA 自己对基线的表述，是对随机投放的一个近似而非一次测量，但方向上恰好正确。
这意味着横向扩容会主动摧毁你当初为之选引擎的那条性质。四个副本、轮转分发，一个本来 90% 是前缀的负载，现在大部分时间都在重算那大部分前缀。你的吞吐曲线上去了，因为你加了 GPU；你的每任务成本也上去了，而引擎对比里没有任何东西提醒过你。
缓存感知路由是解法，而它是一层，不是一个开关。Dynamo 的路由器维护一份「哪些 KV 块在哪个 worker 上」的全局索引，为每个候选 worker 对来访请求算一个重叠得分，然后挑那个把「缓存未命中的代价」与「该 worker 当前解码负载」之和降到最低的那一个。一份第三方测试——Baseten 在 Qwen3 Coder 上、输入约 5 万词元——报告称四副本上命中率 89%，首词元时延降低 50%、每输出词元时间降低 34%。这些是贴着厂商的数字、是最有利的那种负载，但机制是站得住的，而它所胜过的那条基线是算术，不是观点。
在你开始依赖这一层之前，关于它有三件事你该知道：
- 黏性与负载均衡在设计上就是对立的。那个重叠权重是可调的，而 NVIDIA 把它的默认值称为「一个合理的起点」而非一个最优解；把它往缓存亲和那边推，你就会把流量集中到那些「缓存富裕」的 worker 上。没有哪个设置能让你两头都要。
- 平分时按随机打破。当两个 worker 得分完全相同时，路由器会在它们之间随机挑一个；而确实有一份公开报告讲的正是这种情形：一个多轮聊天场景、两个解码 worker、持有相匹配的块。在一个双副本部署里，「得分完全相同」可不是个稀罕状态。
- 多层缓存只给部分分数。在 CPU 卸载缓存里找到的重叠，只按 GPU 常驻重叠的一个折扣计分，而磁盘或 NVMe 上的折扣更狠。你的有效命中率不是一个数字。
引擎这一层真正的差别在哪
把路由这件事算进去之后，引擎之间的差别就变小、也变得更可读了。两个开源引擎都缓存前缀；它们的差别在于如何索引它们。vLLM 对定长块做哈希，简单、查表便宜，而且与它的分页分配器对齐。SGLang 维护一棵词元级的基数树，能更细地共享部分前缀——而它一直在这个方向上投入：在 v0.5.21 里把前缀缓存默认挪到了一个 Rust 内核上，而在那之前的两个版本里统一了基数树。在「前缀彼此很像但又不完全相同」的流量上，更细的共享值真金白银；而在「前缀要么完全相同、要么完全不同」的流量上，两种机制会收敛到一处。
广度则是反着走的。vLLM 是新硬件、新模型架构与第三方集成最先落地的地方，也是其他大多数工具默认假定的那个引擎。SGLang 的发布说明读起来像一个在某一个方向上拼命优化的项目——这既是一句赞美，也同时是一份风险评估。TensorRT-LLM 是 NVIDIA 芯片上的峰值性能选项，代价是一个编译步骤、一两周的搭建，以及接受单一厂商的硬件；截至 2026 年 9 月下旬，它的 1.3 这条线仍在以候选发布标签交付；如果你的变更管理流程希望钉一个稳定版本号，这件事值得知道。
什么时候该挑哪一个
| 情形 | 挑 | 为什么 |
|---|---|---|
| 一两张 GPU、一个模型、智能体流量 | vLLM | 在单副本规模下缓存默认就会命中；拿下那份广度与两周一发的节奏，把注意力花在别处 |
| 前缀密集、且存在大量部分重叠的变体 | SGLang | 词元级基数共享正是匹配那种负载的机制，而项目也正在往那儿投入 |
| 模型固定、NVIDIA 机群、延迟就是产品 | TensorRT-LLM | 单卡峰值数字是真的；把搭建成本算进预算，并接受硬件锁定 |
| 三个及以上副本在服务会话或智能体 | 在上述任一之上架 Dynamo | 超过两个副本之后，主导项是路由而不是引擎——而没有哪个引擎选择能把 1/N 的命中率救回来 |
| 还在用 TGI | 迁移 | 自 2026 年 3 月起已归档为只读；它自己的 README 就把你送去 vLLM 或 SGLang |
常见问题
Dynamo 是 vLLM 或 SGLang 的替代品吗？
不是。它把它们当后端来跑——v1.5.0 钉死了 SGLang、TensorRT-LLM 与 vLLM 的特定版本——而它的职责是路由、预填／解码分离与机群层面的事。如果你看到有人拿它去跟某个引擎头对头做基准测试，那场对比衡量的是一个栈，不是一个同类。
对智能体负载来说哪个引擎最快？
不给出你的前缀复用率就无法回答，而这正是已发表的答案能从 29% 跨到 6.4 倍的原因。先量出你的词元里有多大比例是前缀、以及你当前的缓存命中率；在两个副本以下，引擎选择占主导，而在那之上是路由占主导。
只有两个副本也需要缓存感知路由吗？
对会话型负载大概需要，而那条附带条件很重要：在 N=2 时，均匀分发大约会让你损失一半的潜在命中率；但这也正是「重叠得分完全相同」最常出现的配置，而路由器在平分时按随机打破。启用之后请去核实你实际的命中率，而不是想当然。
TGI 死了吗？
实质上是。2025 年 12 月起进入维护模式，仓库于 2026 年 3 月 21 日归档为只读，而 Hugging Face 自己的文档现在推荐 vLLM 与 SGLang。既有部署照样能跑；新工作不该从那里起步。
TensorRT-LLM 为什么没有一个稳定的 1.3.0？
截至 2026 年 9 月下旬，它的 1.3 这条线仍在以候选发布标签交付，而 Dynamo 也是把一个 rc 构建钉为后端。对这个项目的节奏来说这很正常，但如果你的发布流程要求钉一个非 rc 的版本，那它确实是一处真实的摩擦。
在做选择之前，我该量的那一个数字是什么？
前缀缓存命中率，按副本数切开看，在你自己的流量上量。这里每个引擎都已经把它导出来了，它正是所有公开基准测试都没说明的那个参数，而一个偏低的值告诉你的是：先去修路由，再去换引擎。
延伸阅读
本站相关：
- 上下文缓存的经济学——命中率背后的成本模型。
- 提示词缓存——同一套机制，作为托管 API 的一项功能。
- 面向智能体的自托管推理——什么时候自己跑服务栈才值得。
- 服务智能体流量——为什么智能体的请求形状会把面向请求的容量规划打破。
- 预填与解码——被分离部署拆开的那两个阶段。
- 推理供应商——这一切的托管替代方案。
项目来源：
- vLLM——发布记录与引擎文档。
- SGLang——发布说明，含 v0.5.21 的 Rust 前缀缓存。
- TensorRT-LLM——发布标签。
- NVIDIA Dynamo——路由器设计、KV 感知路由与后端版本钉死。
- Text Generation Inference——已归档，含它自己的迁移建议。