# vLLM 和 TileRT 开始共用一套服务，推理引擎从“谁跑得快”转向“该走哪条路”

> 原标题：vLLM x TileRT：两个目标相反的推理引擎，为什么开始共用一套服务

- 来源：Computing Life · Share · 鸭哥调研
- 发布时间：2026-07-17T00:00:00.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/45073
- 原文：https://yage.ai/share/vllm-tilert-specialized-inference-paths-20260717.html

## 摘要

vLLM 擅长把多个请求打包一起算，提高整体吞吐；TileRT 则专攻一次只处理一个请求的 decode，换取更低的逐 token 延迟。7 月 14 日，vLLM 官方博客公布了二者的解耦集成方案：vLLM 负责读提示词、做 prefill 并生成首 token，之后通过 MultiConnector 把标记为低延迟的请求转给 TileRT 完成后续...

## 推荐理由

vLLM 和 TileRT 的解耦集成把推理服务从单引擎比拼推到了按阶段分工的编排思路上，方案有具体机制和代码。不过这是官方博客的宣布稿，还没看到大规模生产环境的验证数据，实际能省多少延迟、多占多少资源都还不好说，这点先别太激动。

## 锐评

这条新闻最值得看的地方，不是vLLM又多接了一个后端，而是推理服务的思路在变。过去大家比的是哪个引擎综合分最高，现在开始承认一个引擎没法同时把高吞吐和低延迟都做到极致。vLLM和TileRT的解法很直接：不合并代码，而是分工。vLLM负责读提示词和生成第一个词，之后把标记为“低延迟”的请求转给TileRT做后续生成。连接器打通了路，但哪些请求该走这条快车道，还得平台自己定规则。

这里有几个数字得留意。TileRT 0.1.5在一个8卡B200的节点上，同一时间只处理一个请求。这解释了它为什么能把单请求延迟压得很低，但也说明这条路径的容量很有限，不能拿常规并发的算法去算账。另外，目前交接时只传递了temperature、top_p和top_k三个采样参数，其他采样功能还没验证过语义是否一致。

文章最大的信息缺口是成本账。官方给了TileRT路径的生成速度，但没有包含状态数据提取和跨节点传输的端到端测试。在生产环境里，搬KV缓存的开销可能会吃掉一部分算子优化的收益。只有高价值请求能填满专用容量时，低延迟才同时是一笔划算的经济账。这点先别太激动。