从极致速度到可组合性：TileRT × vLLM 异构 PD 分离方案

在目前的生产部署中，Prefill 和 Decode 两个阶段的资源瓶颈是不同的：Prefill 主要消耗算力，Decode 则受限于显存带宽。将它们进行物理上的解耦（PD 分离），是为了防止这两种任务在同一个执行窗口内互相拖累。

但在具体落地时，用户面临着一个很实际的工程选择：TileRT 的底层 Decode 速度很快，但大家手里已经有了一整套基于 vLLM 的成熟生态，比如现成的中央调度、Prefix Caching 以及写好的标准 API。如果为了引入 TileRT 的 Decode 低延迟而重构上层的推理服务栈，往往意味着很高的改造代价。

而 TileRT × vLLM PD 分离方案，就是为了在不破坏原生 vLLM 生态的前提下，提供一种将两者组合使用的方法。

简单来说，就是由一个轻量的外部 Router 接入流量，vLLM 负责 Prefill 阶段的调度与计算，TileRT 专门在后端接力跑 Decode。两个引擎各做自己最擅长的事，通过官方的开放接口进行协作。用户不需要在“原生生态”和“极致速度”之间做二选一。

TileRT × vLLM PD 分离整体架构：两类流量共享同一个 vLLM Prefill 池，由 MultiConnector 分流至 TileRT 与原生 Decode 池 — 整体架构 — 两类流量共享同一个 vLLM Prefill 池；MultiConnector 按请求标记分流，Decode 分别由 TileRT 池与原生 vLLM 池承接。

零修改：基于官方扩展点的插件化挂载

为了不影响 vLLM 原生代码的整洁度与后续升级，本方案没有修改 vLLM 的核心源码，完全基于 vLLM 从 V1 架构开始提供的官方稳定扩展点：KVConnectorBase_V1。

我们在 tilert_serve/pd_vllm/prefill_connector.py 中实现了自定义的 TileRTConnector（承载 kv_producer 角色）。在服务启动时，通过标准的 vLLM 启动命令注入如下的 --kv-transfer-config 参数即可完成模块的动态加载：

--kv-transfer-config '{
    "kv_connector": "TileRTConnector",
    "kv_connector_module_path": "tilert_serve.pd_vllm.prefill_connector",
    "kv_role": "kv_producer",
    "kv_connector_extra_config": {
        "tilert_host": "YOUR_TILERT_HOST",
        "tilert_ctrl_port": 5556,
        "tilert_model": "glm5",
        "tilert_max_seq_len": 202752
    }
}'

在 vLLM 的中央调度器视角下，TileRT 接入层被视作符合标准生命周期契约的传输插件，随插随用。

另外一个必要的配置：由于 Decode 侧从第一步起就运行多 Token 投机解码（MTP），Prefill 端还需要带上对应的投机解码配置（--speculative-config '{"method": "mtp", "num_speculative_tokens": 1}'）——draft 层的 KV 由 vLLM 在 Prefill 阶段填充，Decode 侧的投机解码正是从这里接续。

状态传递：Mooncake RDMA 异步数据面，Forward 零阻塞

Prefill 节点计算完成后，需要将请求的注意力状态（压缩 KV、稀疏注意力的索引缓存以及少量元数据）传递给背后的 TileRT Decode 节点。在超低延迟场景下，跨引擎的网络同步和数据搬运极易带来执行开销与耗时抖动。

为了把通信开销压到最低，系统在数据面与时序上做了两层设计：

RDMA 单边写，不落主机内存：数据面支持 Mooncake 与 NIXL 两种传输引擎。vLLM 侧计算完成后，状态以 RDMA 单边 WRITE 的方式直接写入 TileRT Decode 节点预先注册好的 GPU 显存，全程没有中间序列化，也不经过主机内存中转。握手协议本身与底层传输引擎解耦，传输引擎只负责搬运字节。
不阻塞 Forward 窗口：在 vLLM 正常的 Forward 执行窗口内，只做状态的快速抽取至 Staging Buffer——赶在对应的 Cache Block 被回收之前完成。随后数据立即交付给后台独立的异步 Sender 去触发实际的网络传输，Forward 流程本身不挂起等待网络。这保证了一个发往 TileRT 的请求不会拖累同 Batch 内其他原生请求的执行速度，规避了排队等网络的风险。

状态恢复：注入正在运行的引擎

状态数据送达 TileRT 侧后，会先被转换成 TileRT 原生的内存布局（Layout），然后直接注入一个正在运行的引擎实例。注入完成后 Decode 立即开跑，且从第一步起就启用多 Token 投机解码（MTP），中间没有引擎冷启动，也没有调度气泡。

路由隔离：多池共存与自适应 Claim 机制

在实际的集群部署中，原生的 vLLM Decode 池和 TileRT Decode 池需要在同一个集群、甚至同一个 Forward Batch 内安全共存。

为了达成这一目标，我们没有选择去修改 vLLM 原生的中央调度器，而是通过一套自适应的 Claim Filter 机制在 vLLM 内部做请求归属隔离：

外部 Router 路由决策：路由决策发生在 vLLM 之外，由外部部署的 Router 完成。Router 收到请求后，会将其转发给 vLLM 做 Prefill，但会强制把 max_tokens 改成 1（只让 vLLM 做完 Prefill 并输出第一个 Token）。同时，在请求里塞一个特殊的透传标记：kv_transfer_params = {"tilert_host": ..., "tilert_ctrl_port": ...}。
精准的 Claim 过滤：在 vLLM 内部，我们利用官方的 MultiConnector 将原生的传输插件与我们的 TileRTConnector 并列。我们的 Connector 提供了一个静态过滤方法 _claim：它只认领带 tilert_host 标记的请求；只要不带这个标记，它就严格执行 No-op（静默不干预）。

通过这种设计，两边的标记互斥、命名空间不相交。带标记的走 TileRT，不带标记的走原生池，它们可以在同一个 Forward Batch 里混跑而互不干扰。同时，在 Decode 侧，TileRT 池拥有独立的 Gated Dispatch 机制控制反压，与 vLLM 池的无限队列调度完全隔离，规避了由于后端请求积压带来的延迟恶化。

小结

整条链路我们已经在真实模型上端到端验证：状态注入后，Decode 侧完整保持了 TileRT 原生的单流生成速度，MTP 从第一步起即生效，跨引擎的交接没有引入可感知的性能损失。当前版本支持的模型为 GLM-5/5.1 与 DeepSeek-V3.2，更多模型正在适配中。

这次 TileRT × vLLM 的协作提供了一个参考样本：Prefill 阶段的并发优化、前缀缓存和标准 API 交给 vLLM，Decode 阶段的极限延迟压榨交给 TileRT。两端通过开放、规范的接口进行解耦分工，在保留主流生态的同时，最大化地释放底层硬件的性能。

合作交流

TileRT 团队将持续探索高性能 AI 系统的底层构建与性能极限，我们也非常欢迎大模型团队和 AI 应用团队与我们深度合作。

如果你对 GPU 架构、编译优化、分布式或大规模推理系统有兴趣，也欢迎加入我们。

GitHub repo： github.com/tile-ai/TileRT
交流/加入我们： contact@tilert.ai