vLLM 联合 TileRT 推出专用解码引擎，面向延迟敏感场景

分离式服务将计算受限的 prefill 阶段与内存带宽受限的 decode 阶段分开，已成为大规模服务大语言模型时日益标准的模式，vLLM 通过一等公民的连接器接口支持它。

这一架构转变带来一个容易被忽视的好处：一旦 prefill 和 decode 分离，decode 侧就变得可插拔。不同的服务场景需要不同的引擎设计。prefill 池、调度器、缓存层和服务 API 保持原样，而 decode 池则成为一个可以主动做出的选择。

今天，我们正是要推出这样一个选择：vLLM prefill 搭配 TileRT decode，通过 vLLM V1 的公共连接器接口集成，并随 TileRT 0.1.5 一同发布。对于延迟敏感型工作负载，这一组合带来 TileRT 原生的单用户 decode 速度，而部署的其他一切仍保持标准 vLLM。

为什么需要第二种 decode 选项？

vLLM 的原生 decode 现在是、将来也仍是正确的默认选择：它为跨大量模型和硬件的高吞吐批量服务而构建。但有一类工作负载正在增长，例如智能体循环、交互式编程助手、实时语音，其中关键指标不是总吞吐量，而是 token 到达每个单独用户的速度。这些工作负载受延迟约束，需要一种从一开始就专为该场景设计的 decode 引擎。原生 decode 和 TileRT 瞄准同一条吞吐量–延迟前沿上的不同点，这正是它们能够组合的原因。

TileRT 就是这样一个引擎：一个全新的推理运行时，围绕单一目标构建——将单用户 decode 速度推向硬件极限。我们已在别处撰文说明为何我们认为速度正在成为其自身的扩展维度。

不过，本文不是关于这个引擎的。它关乎一个更实际的问题：你能否采用一个专用 decode 引擎，而不放弃你所依赖的生态，例如 OpenAI 兼容 API、调度、前缀缓存、工具调用以及 vLLM 的运维成熟度？

这一集成旨在让这种取舍尽可能小：

Prefill 是 vLLM。调度、分块 prefill、前缀缓存——原封不动。
服务接口是 vLLM。相同的 API、相同的请求格式、相同的工具链。
只有 decode 发生变化，而且只针对你发送到那里的流量。与 TileRT 配对的栈与你现有的 vLLM 部署并行运行；每个工作负载选择自己的端点。

架构：设计上的共存

核心设计原则是对 vLLM 零改动：不 fork、不打补丁、不包装内部 worker。集成完全位于 vLLM V1 的公共扩展面之后：一个 KVConnectorBase_V1 实现，在 MultiConnector 下组合，并通过标准的 kv_connector_module_path 机制加载。这不仅仅关乎工程美学：添加 TileRT decode 池不会破坏你已运行的 vLLM 部署，升级 vLLM 也不意味着要重新移植一个 fork。

Coexistence by design: latency-critical traffic is marked by the TileRT PD router and claimed by the TileRT connector, while general traffic flows through the native disaggregation path, both served by a single stock vLLM prefill pool composed under MultiConnector. — 设计上的共存：延迟敏感型流量由 TileRT PD 路由器标记，并由 TileRT 连接器认领，而一般流量则流经原生分离路径，两者都由一个在 MultiConnector 下组合的标准 vLLM prefill 池提供服务。

路由。一个轻量级路由器位于 TileRT 池前端。对于每个请求，它设置 max_tokens=1（vLLM 执行 prefill 并输出第一个 token），并在标准透传字段中附加目标 decode 节点：kv_transfer_params = {"tilert_host": ..., "tilert_ctrl_port": ...}。原生池的流量则通过常规的分离代理流转，不做任何修改。

请求声明过滤。TileRT 连接器只认领带有该标记的请求，对其他所有请求都是严格的空操作，因此两个 decode 池可以共享同一个 prefill 实例（甚至同一个前向批次）：为部分流量采用 TileRT 不会对其余流量产生任何影响。

纯生产者。该连接器仅充当 kv_producer，从不干预调度或采样；它在 prefill 之后提取并发送状态。除此之外，该 prefill 实例就是一个原生的 vLLM 服务器。

交接如何工作

要让跨引擎分离变得实用，必须满足三个条件：传输必须快，不能拖慢 prefill 节点，并且 decode 引擎必须从 prefill 结束的地方精确接续。

数据平面。prefill 之后，请求的注意力状态（压缩 KV、稀疏注意力索引缓存以及少量元数据）以 RDMA 单边写入的方式传输到 decode 节点上预先注册的 GPU 缓冲区，传输引擎可以是 Mooncake 或 NIXL。没有中间序列化，也不经过主机内存暂存。交接协议本身独立于底层传输引擎，后者的职责只是搬运字节。

与 prefill 完全重叠。状态提取发生在前向窗口内：请求的状态在其缓存块被回收之前被复制到暂存缓冲区，并由后台发送器执行实际的网络传输。发往 TileRT 的请求永远不会阻塞下一次 prefill 迭代，包括共享同一批次的原生池请求。

注入运行中的引擎。状态到达后会被转换为 TileRT 的原生布局，并直接注入正在运行的引擎；解码立即开始，从第一步起就启用多 token 投机解码。

评估

GLM-5.1-FP8 token generation speed on 8× NVIDIA B200 with TileRT v0.1.5. Output length 1K, input length 1K–192K. Bars compare TileRT without MTP, with MTP at average acceptance length 3.2, and the peak under best-case MTP acceptance 4.0. — 在 8× NVIDIA B200 上使用 TileRT v0.1.5 的 GLM-5.1-FP8 token 生成速度。输出长度 1K，输入长度 1K–192K。柱状图对比了不带 MTP 的 TileRT、平均接受长度为 3.2 的 MTP，以及最佳情况下 MTP 接受长度 4.0 时的峰值。

选择你的 decode 池

当每用户 token 速度是硬性约束时，路由到 TileRT decode，例如交互式智能体、实时助手、延迟 SLO 推理，且模型是 TileRT 支持的模型。

对于最大聚合吞吐量、高并发批处理以及通用 decode 所覆盖的长尾模型和功能，则继续使用 原生 vLLM decode。

两个栈都暴露相同的 OpenAI 兼容接口，因此在它们之间迁移工作负载只是路由变更，而非客户端变更。

当前限制。在此版本中，一个 TileRT decode 节点一次只服务一个进行中的请求，由路由器提供门控分发和背压。此版本支持的模型为 GLM-5/5.1 和 DeepSeek-V3.2，后续还会增加更多。

快速上手

TileRT 0.1.5 已在 PyPI（pip install tilert；Python 3.12、CUDA 13 wheel）和 TileRT 仓库上提供。请在 prefill 和 decode 节点上都安装它；prefill 端需要它来运行连接器插件。

# 0. One-time: convert the HF checkpoint to TileRT's weight format
python -m tilert.models.preprocess.weight_converter \
    --model_type glm-5 \
    --model_dir /path/to/GLM-5.1 \
    --save_dir /path/to/tilert-glm5.1-weights
 
# 1. TileRT decode node
python -m tilert.pd_vllm.decode_server \
    --engine tilert --model glm5 \
    --model-weights-dir /path/to/tilert-glm5.1-weights \
    --with-mtp --max-seq-len 202752 \
    --kv-cache-dtype fp8 \
    --ctrl-port 5556 --http-port 5557
 
# 2. vLLM prefill (stock vLLM; the connector loads as a plugin).
#    The MTP speculative config is required: prefill populates the
#    draft-layer KV that decode-side speculation resumes from.
vllm serve /path/to/GLM-5.1 \
    --served-model-name glm5.1 \
    --port 8000 \
    --tensor-parallel-size 8 \
    --enforce-eager \
    --trust-remote-code \
    --return-tokens-as-token-ids \
    --gpu-memory-utilization 0.8 \
    --kv-cache-dtype fp8_ds_mla \
    --speculative-config '{"method": "mtp", "num_speculative_tokens": 1}' \
    --kv-transfer-config '{
        "kv_connector": "TileRTConnector",
        "kv_connector_module_path": "tilert.pd_vllm.prefill_connector",
        "kv_role": "kv_producer",
        "kv_connector_extra_config":{
            "tilert_host":"[TILERT_DECODE_SERVER_IP]",
            "tilert_ctrl_port":5556,
            "tilert_model":"glm5",
            "tilert_max_seq_len":202752
        }
    }'
 
# 3. Router: OpenAI-compatible ingress for the TileRT pool
python -m tilert.pd_vllm.pd_router \
    --vllm-url http://prefill-node:8000 \
    --decode decode-node:5556:5557 \
    --model-path /path/to/GLM-5.1 \
    --port 23333

要在一个共享的 prefill 实例后面同时运行 TileRT 池和原生 vLLM decode 池，请在 MultiConnector 下组合两个连接器。我们验证过的配置端到端运行 NIXL（原生池使用 vLLM 标准的 NixlConnector，TileRT 池使用 NIXL 模式下的 TileRT 连接器），因此共享 prefill 使用单一的传输库；只有 prefill 的 --kv-transfer-config 会发生变化。

展望未来

我们认为解耦正在悄然改变推理栈的本质：它不再是一个单一的引擎，而更像是共享服务层背后多个专用引擎的组合。vLLM 的连接器接口正是今天实现这种组合的关键，而这次集成就是一个具体的例子。这也是为什么像 TileRT 这样的引擎能够如此深入地进行专用化：在服务层共享、接口开放的情况下，深入优化某一个维度不再意味着要重建其他所有部分。

我们非常希望听到社区的反馈：关于集成接口、关于这能帮助哪些工作负载，以及接下来应该支持哪些模型。

致谢

我们感谢 vLLM 社区设计了 V1 连接器接口，使零修改集成成为可能，也感谢 Mooncake 和 NIXL 项目提供的 RDMA 传输引擎。我们还要感谢 Inferact Inc. 合作改进 vLLM-TileRT 集成。