Ultra-High Interactivity on NVIDIA GPUs? - TileRT InferenceX

高价“快速模式”证明，用户愿意为更低延迟和更快的 Token 生成速度支付更多费用。这可能带来更高的毛利率。因此，OpenAI 等前沿 AI 实验室正在评估专用推理系统，例如 Cerebras 和 NVIDIA Groq LPU。这些系统优先考虑超高交互性，而非最大化的批量吞吐量。在交互式工作负载中，超低延迟至关重要。这类工作负载包括实时助手和全双工语音。例如，OpenAI GPT-Live 可以同时听和说。这让用户能立即感知到响应延迟，体验如同钢铁侠的 JARVIS。

GPU 在高吞吐量和中低交互性场景下表现出色，但其架构不太适合超低延迟推理。一台 8-GPU HGX B200 服务器提供的理论 HBM 内存总带宽为 64 TB/s。在批大小为 1 时，NVFP4 格式的 GLM-5 每生成一个 Token 仅需约 21 GB 的活跃参数流量。因此，根据 B200 的 HBM 带宽上限，在不使用投机解码的情况下，速度可达每用户 3,047 tokens/s。但在实际应用中，GPU 远未达到这一极限。

这种差距源于延迟，而非带宽。传统的 GPU 编程模型会启动并同步许多独立的 kernel。在超高交互性级别下，这些 kernel 的建立与销毁开销变得非常显著。虽然这些延迟成本在常规服务速度下不太明显，但即使使用 CUDA graphs，当 Token 延迟接近亚毫秒级的单输出 Token 耗时（TPOT）范围时，它们就会成为主导因素。此外，尽管 GPU 内存带宽每代大约提升 2-3 倍，内存延迟却完全没有改善。

虽然使用替代硬件很受欢迎，但也有办法用 GPU 来实现这一目标。这就是 TileRT 持久化引擎发挥作用的地方。TileRT 将整个解码图静态编译为 NVIDIA GPU 上的单个持久化 kernel。从而最大化计算、内存加载与存储以及通信之间的重叠。在单台 B200 解码服务器上运行的 InferenceX GLM5 FP8 744B 基准测试中，TileRT 被验证可达每用户 500 tokens/s。这比运行传统推理引擎的 GB300 NVL72 快约 3 倍。在单输出 Token 成本相同的情况下，TileRT 的交互速度比传统引擎快达 2 倍。

我们感谢 TileRT 的维护者在 TileRT InferenceX 基准测试上的协作。同时，也总体感谢 vLLM 社区在 V1 连接器上的出色设计。TileRT 出自构建了广受欢迎的 TileLang DSL 的同一社区维护者组织。

借助 PD 分离推理技术，高度专用的 TileRT 引擎负责处理对延迟敏感的 decode 阶段，而 vLLM 和 SGLang 等吞吐量优化引擎则继续负责 prefill 阶段。TileRT decode 引擎目前已在小米投入生产环境，用于 MiMo V2.5 Pro UltraSpeed，并在 ZAI 用于 GLM 5.1 HighSpeed。

在本文中，我们将深入探讨 TileRT InferenceX 的评测结果，介绍 TileRT 的概念，以及它如何与现有的推理生态相融合，同时分析 TileRT 带来的权衡与面临的挑战。

我们还将详细阐述在标准 GPU 与 Nvidia Groq LPU、Cerebras 及 Sambanova 等超低延迟专用芯片上使用 TileRT 的权衡差异。并探讨运行在 GPU 上的 TileRT 软件是否有潜力颠覆这些专用芯片的总潜在市场（TAM）。SemiAnalysis 加速器模型提供了 Nvidia LPU30、LPU40、Cerebras WSE-3 及 WSE-4 出货量的逐季度预测等更多信息。

InferenceX

InferenceX 是我们开源、厂商中立且持续更新的 AI 推理基准测试与研究平台。我们在延迟与吞吐量的帕累托前沿上，对领先的模型、推理框架和硬件进行评测。追踪真实世界的推理性能与经济效益如何随时间推移而提升。

感谢阅读 SemiAnalysis！本文为公开文章，欢迎分享。

我们的基准测试已被广泛复现、验证并获得支持。支持方几乎涵盖所有主要的算力买家，从 Google Cloud 到 Microsoft Azure，再到 Oracle 和 Meta 等。此外，它还获得了机器学习社区的支持，包括 vLLM、LMCache、SGLang、PyTorch 和 Huggingface。同时也得到了 OpenAI、MiniMax、ZAI、Qwen、Moonshot Kimi 等主要实验室的鼎力支持。

如果您觉得该开源基准测试与数据有用，请在 GitHub 上为 InferenceX 仓库点 Star！如前所述，Nvidia 已承诺向 InferenceX 提交可验证的 Vera Rubin 数据。我们很快也将发布 Google TPUv7 的测试结果，AMD 同样承诺在今年内提交 MI455X UALoE72 的数据。

吞吐量与交互性曲线

每个推理系统都必须在两个相互竞争的目标之间取得平衡。

批处理通过同时处理更多请求来提高总吞吐量。但每个用户通常需要为每个 token 等待更长时间。小批次的效果则相反：它能提升单用户体验到的速度，但会减少每块 GPU 总体完成的实际有效工作量。

公交车将成本分摊给许多乘客，但每位乘客都需要等待共享的停靠站。赛车只能搭载一两个人，能更快到达目的地，但每位乘客的成本要高得多。推理也面临着同样的权衡：批处理可以提高总体吞吐量并降低每个 token 的成本，而小批量则能提升单用户的响应速度。这里没有放之四海而皆准的运行点。

在下面展示的配置中，将交互性从约 25 tokens/s/用户提高到 260 tokens/s/用户，会使单 GPU 吞吐量从约 5,900 tokens/s/GPU 降至 200 tokens/s/GPU。这相当于单用户速度提升了 10 倍，而总体吞吐量却下降了约 30 倍。

TileRT 结果

正如我们在下一节所述，GPU 在高吞吐量场景下表现优异，但在高交互性场景中却显得力不从心。这一弱点为数据流芯片开辟了全新的市场细分领域。TileRT 正是针对这一弱点，因此它专注于高交互性的运行点。

SemiAnalysis 是一份读者支持的出版物。若要接收新文章并支持我们的工作，请考虑成为订阅者。

B200 上的 TileRT 独树一帜。在 8k/1k 输入/输出 token 场景下，TileRT 在一个 8-GPU B200 节点上达到了 340 tokens/s/用户。当前数据集中此前的最快记录是 GB300 NVL72 上使用 NVFP4 和 MTP 达到的 181.4 tokens/s/用户，这使得 TileRT 在该指标上快了 1.9 倍。当然，这是在 Batch Size 1 下的表现。在这种情况下，为 GB300 NVL72 搭建复杂铜背板所付出的额外努力，对提升交互性完全没有发挥作用。

与此同时，最快的 FP8 结果是在使用 MTP 的 B300 上达到的 113.6 tokens/s/用户，这使得 TileRT 在相同精度下快了 3.0 倍。

在 1k/1k 输入/输出下，TileRT FP8 达到了 494.2 tokens/s/用户。这是使用 FP4 达到的最佳传统结果（256.3 tokens/s/用户）的 1.9 倍，也是最佳传统 FP8 结果（136.3 tokens/s/用户）的 3.6 倍。TileRT 尚不支持 FP4，但它已经击败了非 TileRT 的 FP4 实现！这一结果同样引人注目，因为它出自一个 8-GPU B200 节点，而非 GB200 或 GB300 NVL72 的 72-GPU NVLink 扩展域。此比较关注的是单用户交互性，而非总体吞吐量或成本。

然而，推理总是伴随着权衡！TileRT 的交互性优势是以较低的总体吞吐量为代价的。随着并发量增加，传统引擎可以将权重加载和固定 kernel 成本分摊给更多用户。在 8K/1K 输入/输出下，并发量为 12 的 GB300 FP4+MTP 运行点在保持 154 tokens/s/用户的同时，可提供约 240 总 tokens/s/GPU。而 TileRT 在达到 340 tokens/s/用户的同时，提供了 160.4 总 tokens/s/GPU。

因此，权衡如下：TileRT 提供了更高的单用户速度，而传统 GB300 节点在每个 GPU 上能完成更多的总工作量。截至发文时，TileRT 每个 decode 节点仅处理一个进行中的请求，这使其成为一个刻意设计的特化运行点，而非通用的吞吐量配置。因此，由于仅支持 batch size 为 1 个用户，TileRT 不仅是一辆赛车，更像是一艘仅容一名乘客的私人火箭。通过工程优化让 TileRT 支持更多乘客也许可行，但这无疑是一个雄心勃勃的目标。

Star InferenceX GitHub

在端到端延迟方面，采用 FP8 的 TileRT 在 1k/1k 场景下比此前记录的最佳 GLM-5.1 结果快 4.5 倍，在 8k/1k 场景下快 3.0 倍。不出所料，TileRT 的首字时间（TTFT）表现不错，但也算不上惊艳。决定性优势来自 decode 尾部延迟：仅为 3.01 秒，而采用 NVFP4 + MTP 的最佳竞争对手为 6.54 秒，MI355X 则为 18.18 秒。

但 TileRT 究竟是什么？

我们简要介绍了 TileRT 的功能，并展示了一些基准测试结果，但让我们稍作停顿，更深入地解释 TileRT 是什么以及它是如何工作的。传统的推理引擎会运行数千个独立的 GPU 程序 kernel，这些 kernel 一个接一个地启动。所有的启动和销毁过程意味着，GPU 会花费大量时间在等待上。虽然这种启动/销毁时间对于中低交互性推理可能无关紧要，但对于超高交互性推理（即低延迟推理）却至关重要。更糟糕的是，每个 kernel 都会将其未完成的工作写入 HBM。在 batch size 较小时，这会成为一个更大的问题，因为 kernel 规模不足以摊销启动延迟、同步和调度开销。

SemiAnalysis 是一家靠读者支持的出版机构。如需接收新文章并支持我们的工作，请考虑成为订阅者。

如前所述，在 batch size 为 1 的情况下运行 TileRT 时，对于单台 HGX H200 服务器（总 HBM 内存带宽为 38.4TB/s），在 MXFP8 格式下每个 token 的活跃参数内存带宽为 42GB。理论上，如果仅受限于内存带宽，那么即使没有投机解码，推理也应该能达到高达 1,000 tok/s/user 的交互速度。然而在现实世界中显然并非如此！障碍在于，GPU 的编程和架构模型传统上并非为低延迟而构建。尽管每代 GPU 的内存带宽增加了 2-3 倍，但内存延迟却毫无改善，即便 HBM 价格还在持续上涨！

TileRT 没有不断启动 kernel，而是让 GPU 持续执行一个常驻流水线。它将整个模型提前静态编译为一个常驻 Engine Kernel：host 端只需启动一次，执行过程便会在整个 decode 生命周期内常驻于 GPU 上，并且大部分运行时编排都转移到了编译阶段。

这与 CUDA graphs 不同。CUDA graphs 会一次性捕获 kernel 启动和 memcpy 的 DAG（有向无环图），然后通过单次 cudaGraphLaunch 进行回放。但这些 kernel 本身依然是独立的。kernel 之间的边界会带来设备端的额外开销，并且片上状态在每次跨越边界时都会被清除。CUDA graph 优化的是 kernel 的启动过程，而 TileRT 则彻底取消了将 kernel 作为执行单元的设计。

此外，通过将任务分解为具有 warp 和 block 专一化特性的 tile 级任务，运行时能够以高度重叠的方式动态重新调度计算、I/O 和通信。在 Engine Kernel 内部，不同的 warp group 承担不同的工作：异步数据传输、张量计算与通信相互重叠。以往各个阶段以 load → barrier → compute → barrier 的方式串行执行，如今它们在 tile 粒度上实现重叠。中间结果通过寄存器、共享内存和 L2 缓存向前传递，无需反复写回全局内存。实际上，每个 CTA（Cooperative Thread Array）都变成了一个小型异构工厂，而非单纯的 SIMT（Single Instruction Multiple Threads）工作单元。

TileRT 引入的下一项优化，是将专一化扩展到整个 GPU 层面。大多数 TP 框架假设所有 rank 同步执行相同的逻辑。但稀疏路由、Top-K 选择、动态索引、长上下文 attention 以及 MTP 并不适合同构的横向扩展。这些操作计算量不大，却高度依赖全局信息。强制每个 rank 都去执行这些操作，不仅会产生冗余工作，还会加剧同步放大问题。既然 warp 可以实现专一化，GPU 同样可以。在 GLM-5.1 的 attention 层中，GPU 0 作为 Sparse Indexer worker，负责处理 Top-K 选择、稀疏索引构建和路由；而 GPU 1 到 7 则作为 MLA worker 运行，执行 RMSNorm、GEMM、flash sparse attention 和 AllReduce。

最后，TileRT 不再将通信视为一个外部阶段，而是将广播、规约和同步操作直接放在 tile 级数据流中执行。在 TileRT 的支持下，宿主机端只需启动一次 kernel 即可完成整个 attention 层的运算。执行模式也从“计算 → 同步 → 计算”转变为“计算 ↔ 通信 ↔ 计算”的持续重叠流水线。

基于 vLLM<>TileRT 的 PD 分离引擎

LLM 推理包含两个截然不同的阶段：prefill 和 decode。Prefill 阶段并行处理输入 prompt，主要属于计算密集型任务，因此聚合吞吐量是关键性能指标。Decode 阶段则按顺序生成 token，并反复访问不断增长的 KV cache，属于访存密集型操作，对单 token 延迟极为敏感。

TileRT 并非要替代 vLLM。vLLM 依然是提供高吞吐量的 prefill 引擎以及周边的服务层，涵盖其调度器、分块 prefill、前缀缓存、兼容 OpenAI 的 API 以及运维工具。只有对延迟敏感的 decode 流量会转移至 TileRT。TileRT 被设计成一艘单乘客火箭飞船，而 vLLM 则继续担当飞机、汽车、巴士和火车的角色。

Star InferenceX Github

Prefill 和 decode 阶段可以拆分到独立的节点中。通过这种分离架构，一个共享的 vLLM prefill 资源池可以为两个完全不同的 decode 资源池提供数据。

这是通过 vLLM 的 MultiConnector API 实现的，该 API 将 TileRTConnector 与其原生连接器组合在一起。TileRT 连接器仅接管被标记为高交互性流量类的请求，对其他所有请求则不执行任何操作，这意味着两种流量类型可以共享同一个 prefill 服务器。在 Prefill 和 Decode 之间，TileRT 使用 Mooncake Transfer Engine 和 NIXL Transfer Engine 来传输 KVCache。在 TileRT v0.1.5 版本中，每个 decode 节点一次只处理一个正在执行的请求。当节点被占用时，路由器会控制分发请求的节奏，并施加背压机制。

感谢阅读 SemiAnalysis！本文是公开的，欢迎分享。

TileRT 与 Cerebras/Groq/SambaNova 相比如何？

专门构建的推理厂商在多年前就发现了相同的执行瓶颈，但他们将更多的解决方案固化到了硬件中。SemiAnalysis 加速器模型包含了我们对 NVIDIA LPU30、LPU40、Cerebras WSE-3 及 WSE-4 出货量的季度预测。

Groq 采用确定性的、由编译器编排的执行方式，并使用大容量片上 SRAM 层级结构。Cerebras 在晶圆级处理器上以空间映射的方式进行计算；CS-3 提供了约 90 万个核心、44 GB 的片上 SRAM 以及 21 PB/s 的内存带宽。SambaNova 则将模型计算图映射到可重构的数据流单元上，并由分层式的 SRAM、HBM 和 DDR 内存系统作为支撑。

SemiAnalysis 是一个读者支持的出版物。若要接收最新文章并支持我们的工作，请考虑成为订阅者。

虽然底层硅片有所不同，但这些系统共享相同的核心理念：对于延迟敏感的推理任务，减少运行时调度、算子边界、同步操作以及不必要的外部内存数据搬运，能够显著提升性能。在 batch size 较大时，这些开销更容易被分摊。而在 batch size 为 1 时，它们在单个 token 的延迟中占据了更大的比例。

TileRT 引入了若干数据流理念的软件类比方案，包括 AoT 调度、持久化执行、专用工作线程，以及通信与计算之间更紧密的重叠。这种相似性是架构层面上的，而非字面意义上的。TileRT 依然运行在具备动态硬件调度、HBM 以及针对特定模型编译的调度策略的 SIMT GPU 上。

Star InferenceX GitHub

然而，TileRT 依然纯粹是软件层面的方案：它将数据流架构强加于一种从未为其专门设计的硬件上。GPU 搭载了动态 warp 调度器、SIMT 模型和 HBM 层级结构。TileRT 能够取得出色的性能数据，主要归功于其投入了巨大的编译器研发精力，通过静态扩展的持久化内核、手工定制的 warp 特化，以及针对固定驱动程序栈的逐模型编译，促使底层硬件去模拟空间流水线。原生数据流芯片则不需要与其自身底层硬件架构作对抗。专用加速器将更多执行模型直接固化在硬件中，从而避免了 TileRT 必须在软件中隐藏的某些开销。不过，它们的优势依然取决于模型、精度、内存层级、编译器质量、系统规模以及服务部署配置。这正是 Cerebras 能够在服务高密度的 70B 模型时，达到任何八 GPU 节点都无法企及速度的原因：软件可以逼近 HBM 带宽的极限，但无法突破它本身的天花板。

市场给出的早期答案是：架构纯粹性是可以妥协的。TileRT 的解码引擎已经在 Xiaomi 的 MiMo V2.5 Pro UltraSpeed 和 Z.ai 的 GLM-5.1 HighSpeed 背后投入生产环境，其部署模式揭示了这一趋势。这两家公司都没有采购全新的数据流芯片。它们在现有的加速器集群中划分出了一个高速处理层。在该架构中，vLLM 继续负责 prefill、调度和 API 服务，而 TileRT 则在相同的接口端点背后接管 decode 任务。在现有硬件上实现“足够好”的效果，往往胜过为了追求架构纯粹性而去采购全新的硬件。

这指向了一个更深层的结构性问题：prefill 与 decode（PD）比例的互换性与灵活性。

GPU 资源池是一种弹性资源。它擅长处理 prefill，擅长处理中高批量的 decode。现在在超交互式 decode 方面也具备了相当不错的实力。其算力可以在这些角色之间灵活切换，软件调度器能够按小时跟随需求变化进行调整。ASIC 集群则恰恰相反。从签署采购订单的那天起，其高速层级算力与其他算力的比例就固定在硬件中了。想要改变物理集群的算力比例，需要耗费数月时间重新装机和布线。如果工作负载构成稳定且已知，这并不是问题。但现实并非如此。在评估需求时，普通会话延迟用户与愿意为极致交互式 SLO 付费的用户（ increasingly agents）之间的划分受到许多变量的影响。使用 GPU 时，如果预估错误，只需通过软件重新平衡即可。使用专用芯片时，如果预估错误，要么导致高速机器闲置造成资金浪费，要么直接流失掉当初专门为其购买的高溢价流量。更糟的是，需求会随时间变化。因此，即使预估正确，也只会在有限时期内保持有效。

回到前面提到的共享 prefill 池，服务商并不需要为所有流量支付 TileRT 的高溢价。普通请求可以继续留在吞吐量优化的 vLLM 或 SGLang decode 池中处理。只有对延迟敏感的请求才会被路由到 TileRT decode 池。

这些并不会颠覆高速市场的顶端。SRAM roofline 依然更具优势，特定规模的模型依然倾向于使用它，部分工作负载也始终会不计成本地追求极致的每秒 token 生成量。但 TileRT 重新定义了大多数买家的需求：他们需要的不是一台速度机器，而是一个动态分配的速度层级，且该层级是从他们本就要拥有的集群中调配出来的。Cerebras、Groq 和 SambaNova 不再与笨拙的 kernel-launcher 竞争。它们的对手变成了自身运行在同质化硬件上的执行模型，只需通过配置文件即可重新分配算力。TileRT 或许只是一艘“单乘客火箭”。但它允许服务商在普通的“ Metro Bus”上捆绑固体火箭助推器，而无需从头设计一款全新的运载工具。

为什么 TileRT 的开发进度缓慢？

GLM5.1 已是上一代产品，并且在主线 InferenceX 上已被弃用。TileRT 的模型目录非常有限，目前仅支持 GLM-5/5.1 和 DeepSeek-V3.2。MiMo-V2.5-Pro-UltraSpeed 是一项协同设计合作的产物，尚未开源。

TileRT 继承了 ASIC 厂商最大的弱点。静态的提前编译意味着模型目录很小（目前仅支持 GLM-5/5.1 和 DeepSeek-V3.2），依赖关系被硬性锁定，而且针对每种新架构都需要投入实质性的工程努力。目前没有完全通用的实现路径。持久化的引擎内核意味着模型会提前静态展开为一个常驻程序。因此，必须在以下几个方面做出决策：Tile 的形状、流水线深度、缓冲区在寄存器/共享内存/L2 中的驻留方式、Warp 组如何在加载、计算和通信之间进行分配、集合通信在何处融合到 Tile 数据流中，以及哪些 GPU 承担专用角色（例如 GLM-5.1 专用的稀疏索引器 rank）。只要改变注意力机制或路由方案，大部分调度方案就会失效。数据流芯片同样面临这个问题，优秀的编译器开发起来难度极大是众所周知的。

业界正在努力简化这一过程，尤其是考虑到 AI 可以加速软件开发。TileOPs 旨在减轻这种负担。每个算子都在一个机器可读的清单中进行声明，指定其函数签名、工作负载和 Roofline 模型。该清单驱动着代码生成、测试和基准测试，并且是基于硬件边界进行评估，而不仅仅是与早期实现进行对比。

AI 编码智能体能够加速已知模板内的调优过程，但全新的变换仍然需要专家的判断。此外，整体式持久内核也降低了传统基于单内核的剖析器时间线的实用性，使得自动化反馈循环变得更加困难。

TileRT<>InferenceX 的后续步骤

我们正在积极推进将 TileRT 的基准测试从 InferenceX 的单轮 8k/1k 扩展到我们全新的智能体编码基准测试（我们称之为 AgentX）。该场景会重放真实的 Claude Code 和 Codex 轨迹，包含长上下文、多轮请求、真实的子智能体活动以及动态的工具使用延迟。其中位数输入长度为 140k tokens，而理论上的中位缓存命中率理论上限可达 99.2%。

该工作负载将测试整个 TileRT<> vLLM 系统，而不仅仅是解码速度。测试内容涵盖增量 KV 传输、前缀缓存复用、缓存保留和卸载、路由以及调度。关键问题在于，TileRT 能否在多轮对话之间仅传输新增的上下文，同时保持其超高交互性的优势。

第二步是突破仅限于 Batch Size 为 1 的限制。我们还将在 Batch Size 为 2、4 和 8 的情况下对 TileRT 进行基准测试。目标是描绘其吞吐量与交互性的 Pareto 前沿，并找出持久化引擎内核的延迟优势开始趋于平缓的临界点。

SemiAnalysis 是一份依靠读者支持的出版物。如需接收最新文章并支持我们的工作，请考虑成为订阅者。

TileRT Ultra Fast Speed 的单位 TCO 性能

接下来，我们深入分析了 TileRT 在超高交互性与正常较低交互性工作点下，每百万输出 token 成本的差异。结果非常有趣：在成本相同的情况下，TileRT 的交互速度最高可达传统引擎的 1.9 倍。我们使用 AI TCO 模型作为基准，来计算每款芯片 SKU 的资本支出（capex）和运营支出（opex）。