vLLM 和 TileRT 原本不像会走到一起的两个项目。
vLLM 擅长把多个请求放进同一批计算，尽量提高 GPU 利用率和整体吞吐。Tile-AI 团队开发的 TileRT 走的是另一条路：它专门优化 batch=1 的 decode，愿意少做一些并发，换取单个请求更低的逐 token 延迟。一个想让整套机器多干活，一个想让眼前这个请求更快。
2026 年 7 月 14 日，vLLM 官方博客公布了与 TileRT 的解耦推理集成，这项能力随 TileRT 0.1.5 一同发布。官方技术博客给出的办法是让两者分工：两套引擎不合并代码，而是通过公开连接器接进同一个系统。vLLM 先读取提示词、完成 prefill 并生成首 token，再把后续 decode 交给 TileRT 执行池。
我觉得这次集成最有意思的地方，不是 vLLM 又多了一个后端，而是两个目标相反的引擎开始共用一套服务。过去大家习惯比较哪一个引擎综合表现最好。现在，实时交互、长上下文和语音生成越走越远，同一个运行时越来越难照顾好所有请求。推理服务的竞争，正在从“单引擎综合最优”转向“专用执行路径的特化与编排”。
为什么一个引擎不能把两边都做好？问题要从模型生成一段回答的过程说起。
模型还没吐出第一个 token 时，GPU 要先读完整段输入，建立后续生成需要的 KV cache。这一步叫 prefill，通常更依赖计算能力，也直接影响首 token 延迟（TTFT）。第一个 token 出来以后，工作节奏就变了。模型进入 decode，一次只生成一个 token，每一步都要读取模型权重和已有 KV cache。它的计算强度比 prefill 低，显存带宽往往更早成为限制；用户感受到的逐 token 速度通常用 TPOT 衡量。
麻烦就在这里。高并发服务通常用批处理（batching）把多个请求放在一起执行，这样总体吞吐更高，但请求可能需要等候，也会受到同批工作的影响。如果改用 batch=1，排队和同批干扰少了，TPOT 可以更低，代价则是总体吞吐和硬件利用率通常也会下降。
所以，同一批硬件和同一套调度策略，很难同时做到高批量利用率和低排队、低干扰。文本负载相对单一时，通用引擎还能在两者之间找一个折中点。实时交互、长上下文和语音生成进入同一服务后，这个折中点就不够用了。
vLLM 与 TileRT 的答案是：既然很难折中，那就保留两个各自擅长的解，再通过控制面分段和分流。
vLLM 继续守在服务入口，负责 prefill、前缀缓存和调度。进入 decode 后，请求才开始分流：常规高并发请求留在原生 vLLM 实例池，标记为低延迟的请求则通过 vLLM V1 的公开连接器 MultiConnector 转给 TileRT。两个 decode pool 共用前面的 prefill 服务，整个接入不需要 fork 或 patch vLLM。
这里有个容易忽略的细节：请求必须先被标记，才会进入 TileRT。当前集成解决了两套引擎怎么共享 prefill、怎么交接生成状态，却没有替平台决定哪些请求应该走低延迟池。未标记的流量仍留在原生 pool。服务商还得结合产品等级、请求形态、排队时间和 TileRT 容量，自己制定分流策略。连接器打通了路，至于哪辆车该走哪条路，仍由上层系统决定。
这样一来，TileRT 只需要处理自己擅长的负载。我们在此前对 TileRT 的介绍文章中分析过，它针对 batch=1 场景，把细粒度算子、I/O 读写与卡间通信编排成连续执行流，尽量减少 kernel 之间的空档。目前这项集成已经支持 GLM-5/5.1 和 DeepSeek-V3.2 等模型。
速度的另一面是容量。在 TileRT 0.1.5 中，一个 8×B200 decode 节点同一时间只处理一个 in-flight request。这个限制解释了它为何能集中优化单请求延迟，也提醒我们：不能拿常规并发服务的容量算法，直接套在这条路径上。
接口看起来统一，功能却还没有完全对齐。根据开源代码，路由脚本
pd_router.py 在首 token 之后，只向 TileRT 传递
temperature、top_p 和 top_k
三个采样参数。其他采样能力目前还没有经过这条交接路径证明语义一致。
跨节点发送数据的 RDMA 操作在后台异步进行，但源节点提取 KV cache 等状态数据仍然同步执行。在生产网络中，搬移状态的开销可能抵消一部分算子优化收益。这次发布给出的数据是 8×B200 上的 generation speed，还没有独立的 connector 端到端测试。vLLM 官方的 disaggregated prefill 文档也明确说明，这类解耦部署不会自动提高整体吞吐，主要用途是分别配置两个阶段的资源，独立调节 TTFT、TPOT 和尾部延迟。
所以，现有数据能说明 TileRT decode 路径本身很快，却还不能直接回答生产系统每美元能服务多少请求。算这笔账时，prefill、状态提取、网络传输、排队和空闲节点都不能漏掉。只有高价值请求足以填充专用容量时，低延迟才可能同时成为合理的经济选择。
vLLM x TileRT 没有消除延迟与吞吐的冲突。它保留两条各自优化的路径，把选择移到了控制面的路由、容量规划和成本核算中。
如果专用路径只是把不同用户分开，事情还不算特别复杂。实时语音模型更进一步：同一个请求内部，就塞着几种节奏完全不同的计算。
一个语音回复通常要经过几个阶段：Thinker 生成低频的文本 token，Talker 生成高频的 codec token，最后由卷积网络 Vocoder 把编码还原成声音波形。Talker 每走一步，还要与多 token 预测模块 MTP 紧密反馈。它们串在同一个回复里，计算特征却并不相同。
Talker 和 MTP 的循环尤其麻烦。每一步计算都很轻，kernel 启动与卡间同步花掉的时间，反而可能超过算子本身。此时继续优化单个矩阵乘法，收益已经不大；真正该减少的是整条执行流里的空档。
如果把这些任务全塞进同一个调度器，某个阶段忙起来，其他阶段就只能跟着等。SGLang Omni 项目因此让 Thinker 和 Talker 使用独立 scheduler，同时把紧耦合的 Talker 与 MTP 留在同一个 forward 中，避免跨 stage 通信，最外层的 Coordinator 只管理 pipeline topology。
独立 scheduler 让每个阶段按自己的节奏组 batch、选择并行方式，不必等待整条语音流水线统一步调。阶段之间通过统一的 inbox、outbox 和 zero-copy shared memory 传递数据。这样既保留了多阶段模型的整体拓扑，也不用强迫所有阶段接受同一种执行策略。
这与 TileRT 指向同一个变化。正如 SGLang Omni 分析文章所指出的，每步计算较轻时，系统更需要减少 kernel 启动和同步的空档。专用执行路径开始从请求之间深入到一个多模态模型内部。
TileRT 是按延迟目标做特化，TensorRT-LLM 则展示了另一种选择：模型和硬件既然已经确定，不妨接受更多构建成本，把优化做得更深。
如果模型架构已经稳定，部署环境也确定使用 NVIDIA GPU，这笔交换就可能成立。团队付出模型构建、编译和调优成本，换取针对固定平台的优化。在 TensorRT-LLM 的解耦服务设计中，context，也就是 prefill，和 generation，也就是 decode，可以分配到不同 GPU 资源池，并采用不同的并行策略。
分池能减少两个阶段的资源争用，让团队分别调节 TTFT 和 TPOT。不过官方也指出，跨节点传输 KV cache 的开销不能忽略，收益取决于输入和输出的形态。长输入、中等输出的任务可能获得明显收益，短上下文交互则可能得不偿失。每个 context 或 generation 实例可以暴露 OpenAI-compatible server，再由外层 disaggregated server 通过 REST 接口协调。
这条路线的代价与 TileRT 不同。TileRT 把优化集中在 batch=1 decode，TensorRT-LLM 则让团队用更高的构建和平台绑定成本，换取稳定模型在 NVIDIA 硬件上的深度优化。它们都在放弃一部分通用性，只是选择了不同的边界。
路径多了以后，麻烦也跟着来了：平台怎么替每个请求选对那一条？
OpenAI-compatible API 可以统一客户端入口，却不保证后端功能一致。NVIDIA Dynamo 功能矩阵显示，不同后端对请求取消、多模态、LoRA 动态加载、投机采样和 KV cache 管理的支持并不相同。
请求到达网关时，路由器得先检查采样参数、工具调用、中途取消等要求。目标后端只要不支持其中一项，请求就不能送过去。统一 API 解决的是“怎么调用”，能力校验解决的是“换个后端以后，意思会不会变”。
能力匹配之后还要接续状态。一个请求在 vLLM 完成 prefill，再切到 TileRT 或 TensorRT-LLM 运行 decode，目标节点必须拿到继续生成所需的 KV cache、稀疏索引和 draft 状态。NIXL、Mooncake 等传输层可以负责搬运，但状态提取是否完整、传输需要多久，都会影响切换结果。
未来的推理网关不能只按连接数做负载均衡。它需要综合请求形态、后端队列长度、KV cache 亲和性和各后端实际支持的能力，估算哪条路径能按时完成请求。特化通道发生故障时，它还要把请求安全地退回通用通道。
出了问题以后，团队还得知道该从哪里查。平台不能只记录请求去了哪个节点，还要留下选路原因、状态搬运耗时、能力降级和回退结果。否则，即使平均性能变好了，一次慢请求究竟卡在排队、传输、执行还是错误选路，仍然很难说清。
以前聊推理引擎，最自然的问题是“哪个在 benchmark 上跑得最快”。接下来更常问的，可能会变成“这个请求此刻该走哪条执行路径”。
像 TileRT 这样特化的低延迟运行时是否会长期独立存在，目前还无法判断。vLLM、SGLang 或 TensorRT-LLM 也可能逐步吸收这些优化，自己覆盖更多执行路径。即便实现边界变化，工作负载已经分化这一前提不会消失。谁能覆盖更多专用路径，并让请求在这些路径之间正确、低成本地切换，谁就更接近下一代推理平台的核心位置。