推理框架的“分家”革命：vLLM 把解码交给 TileRT，延迟关键服务迎来新范式

起因：为什么推理引擎要“分家”？ 近来，LLM 的应用形态已从离线批处理转向在线实时交互。Agent 循环、交互式编码助手、语音对话等场景，对延迟的要求近乎苛刻——不是“总吞吐有多高”，而是“每个用户的每个 token 有多快”。传统的一体化推理引擎为了吞吐量做了大量批处理优化，却在单个请求的尾部延迟上捉襟见肘。vLLM 作为最主流的开源推理框架，早已支持解耦式服务（Disaggregated Serving），即将计算密集的预填充（Prefill）与内存带宽密集的解码（Decode）分开部署。而这次与 TileRT 的深度集成，则把这一架构的潜力推向新高度：解码端不再锁定 vLLM 原生引擎，而是可以按需“插拔”——这正是本篇文章宣布的核心变化。

拆解：不在同一赛道竞争，而是各取所长 想象一下餐厅后厨：预填充好比是大厨集中备菜（计算密集型，做好可复用的半成品），解码则是服务员按每桌需求快速上菜（内存密集型，响应要快）。传统厨房里大厨也负责上菜，虽然能兼顾，但在客流高峰时难以保证每桌的快速响应。vLLM 的解决方案是：大厨（预填充）继续用 vLLM，而服务员（解码）换成 TileRT——一个全新的推理运行时，其设计目标只有一个：把每用户的解码速度压榨到硬件极限。

这一替换并非重造轮子。集成完全基于 vLLM V1 的公开扩展接口 KVConnectorBase_V1，通过标准的多连接器机制加载，无需修改 vLLM 一行源码。对开发者而言，服务面依然是 vLLM（OpenAI 兼容 API、前缀缓存、调度策略、工具调用等原封不动），只是特定的低延迟流量会被路由到 TileRT 解码池。架构上两者可以共存于同一集群，各取所需的端点。这意味着，你不需要在“先进生态”和“极致性能”之间做非此即彼的选择。

趋势洞察：速度成为新的扩展维度 TileRT 团队曾在其博客中提出一个观点：在 LLM 应用领域，速度本身正在成为一种独立的扩展维度（scaling dimension）——过去我们关注模型参数规模、上下文长度、吞吐量，现在，端到端交互时的每 token 延迟已变得同等重要。这背后是 AI 应用从“跑分”走向“跑体验”的必然。当 Agent 需要连续多轮推理，当用户对着屏幕等待代码补全，低延迟不再是锦上添花，而是生死线。

这一案例揭示了一个更大的趋势：推理引擎正从“大一统”走向“专业化分工”。类似 CPU 与 GPU 的分化，未来可能出现针对不同阶段的多种专用引擎，它们通过标准化接口自由组合，为不同工作负载拼出最优方案。vLLM 与 TileRT 的这次合作，正是这种生态雏形的首次落地。

实用价值：谁该关心，如何开始？ 如果你的应用对首次 token 时间（TTFT）或每 token 间隔（TPOT）极其敏感——比如在线客服、实时翻译、语音助手、AI 编程伴侣——这个混合方案值得探索。你可以继续用 vLLM 管理预填充、调度和缓存，然后通过简单配置将解码流量指向 TileRT。目前 TileRT 0.1.5 已发布，vLLM 的集成文档也已上线。不过值得注意的是，TileRT 专为特定延迟需求设计，在纯批处理、追求总吞吐的场景中，vLLM 原生解码仍是正确默认值。关键在于根据不同流量特点，选择不同端口，而非一刀切迁移。

反常识：优化延迟不一定要推倒重来 很多团队以为要获得低延迟就必须抛弃现有框架，重新设计一套推理服务。但 vLLM 的这次实践表明，通过解耦架构和标准化接口，你可以保留 90% 的成熟能力，只替换瓶颈部分。这是一种“组合优于替换”的思路——在合适的层次上做混合，远比从头造轮子更务实，也更符合工程演进逻辑。或许，未来所有的推理服务都会走向这种“可组合”形态，而这次的 TileRT 集成，不过是第一块多米诺骨牌。

原文地址: vLLM x TileRT: Specialized Decode for Latency-Critical Serving