高溢价的"极速模式"正在证明，用户愿意为更低的延迟和更快的 Token 生成速度支付更多，这可能带来更高的毛利率。因此，OpenAI 等前沿 AI 实验室正在评估专门构建的推理系统，包括将超高交互性置于最大批量吞吐之上的 Cerebras 和 NVIDIA Groq LPU。超低延迟在交互式工作负载中最为重要，包括实时助手和全双工语音。例如，OpenAI GPT-Live 可以同时听和说，响应延迟对用户来说立即可感知，被描述为感觉像钢铁侠的 JARVIS。
GPU 在高吞吐和低到中等交互性场景下表现极为出色，但其架构并不那么适合超低延迟推理。一台 8 GPU 的 HGX B200 服务器合计提供 64 TB/s 的理论 HBM 内存带宽。在批大小为 1 时，NVFP4 精度下的 GLM-5 每个生成 Token 仅需约 21 GB 的活跃参数流量。因此，B200 的 HBM 带宽上限（roofline）意味着，在不使用投机解码（speculative decoding）的情况下，单用户最高可达 3,047 tokens/s。而在实践中，GPU 远达不到这个极限。
差距来自延迟而非带宽。传统的 GPU 编程模型会启动并同步大量独立的 kernel，在超高交互性水平下，这些 kernel 的启动与收尾开销变得非常显著。虽然在常规服务速度下这些延迟成本不太显眼，但即便使用了 CUDA Graphs，当 Token 延迟逼近亚毫秒级每输出 Token 时间（TPOT）区间时，它们也会成为主导因素。此外，尽管 GPU 内存带宽每代大约提升 2–3 倍，内存延迟却完全没有改善。
虽然改用替代硬件是主流做法，但也有办法用 GPU 实现同样的效果。这正是 TileRT 持久引擎（persistent engine）的用武之地。TileRT 在 NVIDIA GPU 上将整个解码图静态编译为单个持久 kernel，最大化计算、内存读写与通信之间的重叠。在 InferenceX 的 GLM5 FP8 744B 基准测试中，使用单台 B200 解码服务器，TileRT 已被验证可达到最高 500 tokens/s/user，大约是运行传统推理引擎的 GB300 NVL72 的 3 倍。在每输出 Token 等成本（iso-cost）下，TileRT 的交互性最高可比传统引擎快 2 倍。
我们感谢 TileRT 维护者们在 TileRT InferenceX 基准测试上的合作，同时也感谢 vLLM 社区在 V1 connector 上的出色设计。TileRT 来自构建了广受欢迎的 TileLang DSL 的同一个社区维护者组织。
借助 PD 分离（PD disaggregation）推理技术，高度特化的 TileRT 引擎负责对延迟敏感的 decode，而 vLLM、SGLang 等吞吐优化的引擎继续承担 prefill。TileRT 解码引擎已在小米的 MiMo V2.5 Pro UltraSpeed 和 ZAI 的 GLM 5.1 HighSpeed 上投入生产部署。
本文将深入探讨 TileRT InferenceX 的结果、TileRT 是什么、它如何与现有推理生态协同工作，以及 TileRT 的取舍与挑战。
我们还将详细阐述在标准 GPU 上使用 TileRT 与使用 Nvidia Groq LPU、Cerebras 和 SambaNova 等超低延迟专用芯片之间的取舍，评估运行在 GPU 上的 TileRT 软件是否有潜力颠覆这些专用芯片的市场规模（TAM）。SemiAnalysis Accelerator Model 提供了 Nvidia LPU30、LPU40、Cerebras WSE-3 和 WSE-4 出货量等的逐季度估算。
每个推理系统都必须在两个相互竞争的目标之间取得平衡。
交互性（tok/s/user）衡量单个用户接收 Token 的速度，即每输出 Token 时间（TPOT）的倒数。它决定了响应是流畅还是迟缓。
吞吐量（tok/s/GPU）衡量系统为所有用户总共生成多少 Token。它大体上决定了每个 Token 的成本。
批处理（batching）通过同时处理更多请求来提高总吞吐量，但每个用户通常需要为每个 Token 等待更长时间。小批次则相反：它提升单用户速度，同时降低了每块 GPU 在总体上完成的有效工作量。
大巴把成本分摊到许多乘客身上，却让每位乘客在共享站点等待。赛车只载一两个人，到达目的地更快，但每位乘客的成本高得多。推理也存在同样的取舍：批处理改善总吞吐量和每 Token 成本，而小批次改善单用户响应性。不存在放之四海而皆准的运行点。
在下方所示的配置中，将交互性从约 25 提升到 260 tokens/s/user，单 GPU 吞吐量从约 5,900 降到 200 tokens/s/GPU。也就是说，单用户速度提升 10 倍，换来的是总吞吐量约 30 倍的下降。
来源：SemiAnalysis
正如我们在下一节所述，GPU 在高吞吐场景下表现良好，但在高交互性场景下力不从心。这一弱点催生了数据流芯片（dataflow chips）的整个细分市场。TileRT 瞄准的正是这一弱点，因此它只专注于高交互性运行点。
B200 上的 TileRT 自成一档。在 8k/1k 输入/输出 Token 场景下，TileRT 在八 GPU 的 B200 节点上达到了 340 tokens/s/user。当前数据集中此前的最高纪录是 GB300 NVL72 在 NVFP4 + MTP 下的 181.4 tokens/s/user，TileRT 在这项指标上快 1.9 倍。当然，这是在批大小为 1 的情况下——GB300 NVL72 为搭建复杂铜背板（copper backplane）所做的那番额外功夫，在提升交互性上完全派不上用场。
与此同时，最快的 FP8 结果是 B300 + MTP 下的 113.6 tokens/s/user，而 TileRT 在同一精度下快 3.0 倍。
来源：InferenceX
在 1k/1k 输入/输出下，TileRT FP8 达到了 494.2 tokens/s/user。这是最佳传统结果（FP4 下的 256.3 tokens/s/user）的 1.9 倍，是最佳传统 FP8 结果（136.3 tokens/s/user）的 3.6 倍。TileRT 尚不支持 FP4，但它已经在击败非 TileRT 的 FP4 实现！这一结果同样值得注意，因为它来自八 GPU 的 B200 节点，而不是 GB200 或 GB300 NVL72 那种 72 GPU 的 NVLink scale-up 域。这一比较关乎的是单用户交互性，而非总吞吐量或成本。
来源：InferenceX
来源：InferenceX
然而——推理总免不了有取舍！TileRT 的交互性优势伴随着更低的总吞吐量。随着并发度上升，传统引擎可以把权重加载和固定 kernel 成本分摊给更多用户。在 8K/1K 输入/输出下，GB300 FP4+MTP 在并发度 12 时提供约 240 tokens/s/GPU 的总吞吐，同时保持 154 tokens/s/user。而 TileRT 在达到 340 tokens/s/user 的同时，总吞吐为 160.4 tokens/s/GPU。
因此，取舍在于：TileRT 提供高得多的单用户速度，但传统的 GB300 运行点让每块 GPU 完成的总工作量更多。截至本文发布，TileRT 每个解码节点也只服务一个在途（in-flight）请求，这使其成为一个刻意特化的运行点，而非通用的吞吐配置。因此，由于只支持批大小为 1 的用户，TileRT 不只是赛车，更像是只有一位乘客座位的私人火箭飞船。要通过工程手段让 TileRT 容纳更多乘客或许可行，但这是一个雄心勃勃的目标。
就端到端延迟而言，FP8 的 TileRT 在 1k/1k 下比此前记录的最佳 GLM-5.1 结果快 4.5 倍，在 8k/1k 下快 3.0 倍。不出所料，TileRT 的首 Token 时间（TTFT）不错但并非出类拔萃。决定性优势来自解码尾段：3.01 秒，而最佳 NVFP4 + MTP 竞品为 6.54 秒，MI355X 为 18.18 秒。
来源：InferenceX
我们简要介绍了 TileRT 做什么，并展示了一些基准测试结果，但让我们停下来，更深入地解释 TileRT 是什么以及它是如何工作的。传统服务引擎以成千上万个独立 GPU 程序 kernel 的形式运行，一个接一个地启动。所有这些启动与收尾意味着 GPU 花费了大量时间等待，而这种启动/收尾时间对于低到中等交互性推理或许无关紧要，但对于超高交互性推理（即低延迟推理）绝对至关重要。更糟的是，每个 kernel 都会把只完成了一半的工作写回 HBM。在小批大小下，这个问题更严重，因为 kernel 规模不足以摊销启动延迟、同步和调度开销。
如前所述，当 TileRT 以批大小 1 运行时，仅一台 HGX H200 服务器（38.4 TB/s 的总 HBM 内存带宽），在 MXFP8 下每个 Token 的活跃参数内存带宽需求为 42 GB。理论上，如果我们只受内存带宽约束，那么即便没有投机解码（spec decoding），推理的交互性也应该能达到 1,000 tok/s/user。现实世界显然不是这样！障碍在于，GPU 的编程与架构模型传统上就不是为低延迟而设计的。尽管每块 GPU 的内存带宽每代提升 2-3 倍，内存延迟却完全没有改善，即便 HBM 的价格还在持续上涨！
来源：SemiAnalysis、Nvidia
不同于持续不断地启动 kernel，TileRT 让 GPU 持续执行一条持久流水线（persistent pipeline），提前把整个模型静态编译进一个持久引擎 kernel（Engine Kernel）：宿主机只启动一次，执行在整个解码生命周期内常驻 GPU，大部分运行时编排都被搬到了编译期。
这与 CUDA Graphs 不同——CUDA Graphs 会一次性捕获 kernel 启动和 memcpy 的有向无环图（DAG），然后用一次 cudaGraphLaunch 重放。但其中的 kernel 本身仍是相互独立的 kernel，kernel 之间的边界会带来设备侧开销，并且片上状态在每个边界处都会被清空。CUDA Graph 优化的是 kernel 的启动，而 TileRT 则彻底废除了以 kernel 为执行单位。
来源：SemiAnalysis
此外，通过把工作分解为 tile 级任务，并采用 warp 和 block 特化（specialization），运行时会以高度重叠的方式动态重排计算、I/O 和通信。在引擎 kernel 内部，不同的 warp 组承担不同的工作：异步数据搬运、张量计算和通信相互重叠。过去各阶段以 load → barrier → compute → barrier 的方式串行执行，如今它们以 tile 为粒度相互重叠，中间结果通过寄存器、共享内存和 L2 向前流动，而不是反复溢写（spill）到全局内存。实际上，每个 CTA（协作线程阵列，Cooperative Thread Array）都变成了一个小小的异构工厂，而非一个整齐划一的 SIMT（单指令多线程，Single Instruction Multiple Threads）工人。
来源：TileRT
TileRT 引入的下一个优化，是把特化扩展到整块 GPU。大多数 TP（张量并行）框架假定所有 rank 同步执行相同的逻辑，但稀疏路由（sparse routing）、Top-K 选择、动态索引、长上下文注意力和 MTP 并不适合同质化的水平扩展（scale-out）；它们并非计算密集，却依赖全局信息，因此让每个 rank 都跑一遍这些逻辑，只会增加冗余工作和同步放大。既然 warp 可以特化，GPU 也可以。在 GLM-5.1 的注意力层中，GPU 0 成为承担 Top-K 选择、稀疏索引构建和路由的 Sparse Indexer 工作者，而 GPU 1 到 7 运行执行 RMSNorm、GEMM、flash sparse attention 和 AllReduce 的 MLA 工作者。
来源：TileRT
最后，TileRT 不再把通信当作外部阶段，广播、规约和同步直接在 tile 级流程内执行；借助 TileRT，整个注意力层在宿主机上只对应一次 kernel 启动，执行方式从 compute → sync → compute 转向 compute ↔ communication ↔ compute 的持续重叠流水线。
LLM 推理包含两个截然不同的阶段：prefill 和 decode。prefill 并行处理输入提示（prompt），主要属于计算密集型，总吞吐量是关键性能指标。decode 顺序生成 Token，并反复访问不断增长的 KV cache，属于内存密集型，对每个 Token 的延迟高度敏感。
来源：DistServe
TileRT 不会取代 vLLM——vLLM 仍然是高吞吐的 prefill 引擎以及周边的服务层，包括其调度器（scheduler）、分块预填充（chunked prefill）、前缀缓存（prefix caching）、兼容 OpenAI 的 API 和运维工具。只有对延迟关键的 decode 流量才会转移到 TileRT。TileRT 被设计成单乘客的火箭飞船，而 vLLM 仍是飞机、汽车、大巴和火车。
prefill 和 decode 阶段可以分离（disaggregate）到不同的节点上。借助分离架构，一个共享的 vLLM prefill 池可以为两个完全不同的 decode 池供流。
Pool A：由 TileRT 提供超高交互性 decode。对延迟关键的请求经过 TileRT PD Router，它会指示 vLLM 生成第一个 Token，并在 kv_transfer_params 中给请求打上目标 TileRT 节点的标记。
Pool B：由 vLLM decode 提供常规低到中等交互性 decode。常规流量继续经由 vLLM 原生的分离代理（disaggregation proxy）流向传统的 vLLM decode 池。
来源：vLLM 与 TileRT
这是通过 vLLM 的 MultiConnector API 实现的，它将 TileRTConnector 与 vLLM 原生的 connector 组合在一起。TileRT connector 只认领被标记为高交互性流量类别的请求，对其它请求则是空操作（no-op），这意味着两类流量可以共享同一个 prefill 服务器。在 prefill 和 decode 之间，TileRT 使用 Mooncake Transfer Engine 和 NIXL Transfer Engine 搬运 KVCache。在 TileRT v0.1.5 中，每个 decode 节点一次只服务一个在途请求。路由器会对调度进行门控，并在节点被占用时施加背压（back-pressure）。
专门构建推理产品的厂商多年前就识别出了同样的执行瓶颈，但他们把更多的解决方案固化进了硬件。SemiAnalysis Accelerator Model 收录了我们关于 NVIDIA LPU30、LPU40、Cerebras WSE-3 和 WSE-4 出货量的逐季度估算。
Groq 采用确定性、由编译器编排的执行方式，并配有一大套片上 SRAM 层级。Cerebras 把计算在晶圆级处理器（wafer-scale processor）上做空间映射；CS-3 提供约 90 万个核心、44 GB 片上 SRAM 和 21 PB/s 的内存带宽。SambaNova 把模型图映射到可重构的数据流单元（dataflow units）上，底层是 SRAM、HBM 和 DDR 分层的内存系统。
硅片各不相同，但这些系统共享同一个理念：对延迟敏感的推理，受益于减少运行时调度、算子边界、同步以及不必要的片外内存搬移。在大的批大小下，这些成本更容易摊销。在批大小 1 时，它们在每个 Token 的延迟中占的份额要大得多。
来源：SemiAnalysis
TileRT 引入了若干数据流理念的软件对应物：AoT（预先）调度、持久执行、特化工作者，以及通信与计算之间更紧密的重叠。这种相似性是架构层面的，而非字面上的。TileRT 仍然运行在带有动态硬件调度、HBM 和模型特定编译调度的 SIMT GPU 上。
然而，TileRT 终究只是软件：它把数据流强加在一台从未为它专门设计的机器上。GPU 带有动态 warp 调度器、SIMT 模型和 HBM 层级，而 TileRT 之所以能跑出这些数字，靠的是耗费巨大的编译器工程，让这套机器通过静态展开的持久 kernel、手工雕琢的 warp 特化，以及针对固定驱动栈的逐模型编译，去扮演一条空间流水线。原生数据流硅片从不需要与自己的底层硬件较劲。专门构建的加速器把更多执行模型固化在硬件里，可以规避一些 TileRT 不得不用软件去掩盖的开销。它们的优势仍然取决于模型、精度、内存层级、编译器质量、系统规模和部署配置。这正是为什么 Cerebras 能以任何八 GPU 节点无论怎么调度都达不到的速度服务一个稠密（dense）70B 模型：软件可以逼近 HBM 的上限（roofline），但无法抬高它。
来源：SemiAnalysis
市场早期的答案是：纯粹（purity）是可以谈判的。TileRT 的解码引擎已经在小米的 MiMo V2.5 Pro UltraSpeed 和 Z.ai 的 GLM-5.1 HighSpeed 背后投入生产，部署模式本身就很能说明问题。两家公司都没有采购新的数据流芯片。他们从自己已在运行的加速器集群里切出了一个速度档位：vLLM 继续负责 prefill、调度和 API，而 TileRT 在同一个端点背后接管 decode。在你已拥有的硬件上"足够好"，往往胜过在你还得掏钱买的硬件上"架构纯粹"。
这指向更深层的结构性问题：prefill-decode（PD）配比的可替代性（fungibility）与灵活性。
GPU 池是一种流动性资源：擅长 prefill，擅长高到中批次 decode，如今在超交互性 decode 上也有了几分可信的竞争力，容量可以在这些角色之间流动——这只是软件调度器的决策，可以逐小时跟随需求。ASIC 集群则恰恰相反：速度档位容量与其它一切的配比，在签下采购订单的那一天就被硬件固定死了。改变物理集群的配比，需要花数月时间重新上架、重新布线。如果工作负载构成是稳定且已知的，那倒还好。遗憾的是，需要普通对话级延迟的用户，与愿意为极致交互性 SLO 付费的用户（如今越来越多是 agent），这两者之间的划分在估算时牵涉大量不同变量。用 GPU 猜错了，在软件里重新平衡即可；用专用硅片猜错了，要么把资本困在闲置的速度机器上，要么把当初为它买来的那些优质流量拒之门外。更糟的是，需求还可能随时间推移而变化，所以一个正确的猜测也只能对一段有限的时间成立。
回到前面提到的共享 prefill 池：服务商不需要为所有流量支付 TileRT 的溢价。常规请求可以留在吞吐优化的 vLLM 或 SGLang decode 池，只有对延迟关键的请求被路由到 TileRT decode 池。
来源：SemiAnalysis
这些都不会摧毁速度市场的顶端。SRAM 的上限仍然更高，某些尺寸的模型仍然更青睐它，而且总有一些工作负载愿意不惜代价换取每秒最大的 Token 数。但 TileRT 重新定义了大多数买家的需求：不是一台速度机器，而是一个速度档位，从他们反正都要拥有的集群中动态调配出来。Cerebras、Groq 和 SambaNova 现在面对的竞争对手，不再是一个笨拙的 kernel 启动器。他们面对的是自己那套执行模型——跑在可替代的硬件上，靠一个配置文件就能重新分配。TileRT 也许只是单乘客的火箭飞船，但它让服务商可以给你们的城市公交绑上固体火箭助推器，而不用设计一款全新的运载火箭。
GLM5.1 落后了一代，而且已经在主线的 InferenceX 上被弃用。TileRT 的模型目录非常有限，目前支持 GLM-5/5.1、DeepSeek-V3.2。MiMo-V2.5-Pro-UltraSpeed 是联合设计（co-design）合作的产物，尚未开源。
TileRT 继承了 ASIC 厂商最大的弱点。静态的提前编译意味着极小的模型目录（目前只有 GLM-5/5.1 和 DeepSeek-V3.2）、被死死钉住的依赖，以及每个新架构都要付出实打实的工程投入。没有完全通用的路径——持久引擎 kernel 意味着模型会被提前静态展开成一个常驻程序，因此必须做出大量决策：tile 的形状、流水线深度、缓冲区在寄存器/共享内存/L2 中的驻留分配、warp 组如何在加载、计算和通信之间划分、集合通信在何处融入 tile 流程，以及哪些 GPU 承担像 GLM-5.1 专用稀疏索引 rank 那样的特化角色。改动注意力机制或路由方案，就会让这套调度中的大部分失效。数据流芯片也面临同样的问题——好的编译器出了名地难做。
简化这项工作的工作正在进行中，尤其是因为软件开发可以用 AI 加速。TileOPs 正是为了减轻这一负担而设计的。每个算子都在一份机器可读的清单（manifest）中声明，注明其签名、工作负载和 roofline 模型。这份清单驱动代码生成、测试，以及对照硬件上限（而非仅对照早期实现）的基准测试。
AI 编程 agent 可以在已知模板内加速调优，但新颖的变换仍然需要专家判断。此外，单体式的持久 kernel 也削弱了传统逐 kernel profiler 时间线的用处，让自动化反馈回路变得更困难。
我们正在积极推进把 TileRT 基准测试从 InferenceX 的单轮 8k/1k 场景，迁移到我们新的 agentic 编码基准测试上，我们称之为 AgentX。该场景会重放真实的 Claude Code 和 Codex 轨迹，包含长上下文、多轮请求、拟真的子 agent 活动，以及动态的工具调用延迟。其中位输入长度为 140k Token，理论上中位缓存命中率的上限（roofline）可达 99.2%。
来源：SemiAnalysis
这一工作负载将考验整个 TileRT<>vLLM 系统，而不只是解码速度，包括增量 KV 传输、前缀缓存复用、缓存驻留与卸载、路由和调度。关键问题在于，TileRT 能否在轮次之间只传输新引入的上下文，同时保持其超高交互性的优势。
来源：DeepSeek
第二步是超越批大小 1。我们还将在批大小 2、4 和 8 下对 TileRT 进行基准测试，目标是绘制它的吞吐–交互性 Pareto 前沿，并找出持久引擎 kernel 的延迟优势开始趋于平缓的那个点。