在大模型推理中，“快”并不是一个单一指标。
对服务商来说，最重要的通常是吞吐量，即每张GPU每秒能够处理多少Token，因为这直接影响单位Token成本。但对用户来说，更直观的体验来自交互速度，即单个用户每秒能够收到多少Token。实时助手、语音对话、代码Agent等场景对交互速度尤其敏感：即使系统整体吞吐很高，只要单个响应生成得慢，用户仍然会感到迟滞。
SemiAnalysis今天发布的报告《Ultra-High Interactivity on NVIDIA GPUs? – TileRT InferenceX》，讨论了这个问题：GPU能否在不更换专用硬件的情况下，进入过去主要由Cerebras、Groq、SambaNova等专用推理芯片覆盖的超低延迟市场？
报告给出的答案是：在特定条件下，可以。TileRT通过重新设计GPU解码执行方式，在部分Benchmark中显著提高了单用户Token生成速度。但它并不是传统推理引擎的直接替代品，而是一种面向“高交互速度层”的专用方案。
GPU为什么不擅长超低延迟推理
从硬件参数看，GPU似乎不应该慢。
报告以8卡HGX B200服务器为例，其聚合HBM带宽理论值约为64TB/s。在Batch Size为1、GLM-5采用NVFP4的场景下，每生成一个Token大约需要访问21GB活跃参数。如果推理只受显存带宽限制，理论上单用户速度可以达到约3047 Token/s。
但实际系统远达不到这个水平。
原因不只是带宽，而是延迟。传统GPU推理引擎需要不断启动、同步和切换大量Kernel。每一次Kernel启动都有开销，相邻Kernel之间还需要同步，中间结果也经常要写回HBM。在Batch较大时，这些开销可以分摊到更多请求上；但在Batch Size为1、追求亚毫秒级单Token延迟时，它们会占据越来越大的时间比例。
更重要的是，GPU显存带宽每一代大约提升2—3倍，但显存访问延迟并没有同步改善。因此，单纯依靠新一代GPU，并不能自然解决超低延迟问题。
这正是专用推理芯片厂商看到的机会。Groq、Cerebras和SambaNova虽然采用了不同的硬件路线，但核心思路相近：减少运行时调度、减少算子边界、减少同步，以及减少中间结果在外部存储器之间的移动。
TileRT的不同之处在于，它试图通过软件在现有GPU上实现类似目标。
TileRT做了什么
TileRT的核心设计，是将整个Decode计算图静态编译为一个持续运行的Persistent Engine Kernel。
传统推理引擎会按顺序启动大量Kernel；CUDA Graph虽然可以把一组Kernel启动过程录制下来并整体回放，但Kernel之间的边界仍然存在。TileRT则进一步取消了“Kernel”作为主要执行单元：宿主机只启动一次，随后计算流程驻留在GPU内部运行，大量原本发生在运行时的调度被前移到编译阶段。
在这个持续运行的Kernel内部，TileRT还进行了多层级的任务分工：
在Warp和Block层面，不同计算单元分别负责数据搬运、张量计算和通信；
计算、内存读写和芯片间通信以Tile为粒度进行重叠；
中间结果尽可能通过寄存器、共享内存和L2缓存传递，而不是反复写入HBM；
在多GPU场景下，不同GPU也可以承担不同角色。例如在GLM-5.1的注意力层中，GPU 0负责稀疏索引和Top-K选择，其余GPU执行RMSNorm、GEMM、稀疏注意力和AllReduce等任务。
因此，TileRT并不是简单地对现有Kernel做融合，而是试图把GPU改造成一个由软件调度的持续流水线。
不过，这种流水线并非通过硬件天然实现，而是依赖静态编译、手工优化和针对特定模型的调度设计。这一点也决定了它后面的优势与限制。
Benchmark结果：单用户速度明显提高
在InferenceX的GLM-5.1测试中，TileRT在8卡B200节点上取得了较高的单用户交互速度。
在8K输入、1K输出场景中，TileRT FP8达到340 Token/s/user。作为对比，报告所列此前最快的常规结果为GB300 NVL72上的181.4 Token/s/user，后者采用FP4并配合MTP；最快的常规FP8结果为B300上的113.6 Token/s/user。
也就是说，TileRT在这项测试中，比此前最快的FP4结果快约1.9倍，比最快的FP8结果快约3倍。需要注意的是，这些对比涉及不同硬件平台、精度和并发条件，不能简单理解为所有场景下的普遍性能差距。
在1K输入、1K输出场景中，TileRT FP8达到494.2 Token/s/user。报告列出的最快常规FP4结果为256.3 Token/s/user，最快常规FP8结果为136.3 Token/s/user。
从端到端延迟看，TileRT的优势主要来自Decode阶段。报告数据显示，其Decode尾部耗时为3.01秒，而表现最好的NVFP4加MTP方案为6.54秒，MI355X为18.18秒。TileRT的首Token延迟表现不错，但并不是最突出的部分；真正拉开差距的是后续Token的持续生成速度。
代价：总吞吐量下降
TileRT的提升并不是没有代价。
传统推理引擎可以通过提高并发，把权重加载和固定Kernel开销分摊给更多用户，从而提高单GPU总吞吐。TileRT则专注于Batch Size为1的高交互场景，目前每个Decode节点同一时间只服务一个请求。
在8K输入、1K输出场景中，报告给出的对比是：
GB300 FP4加MTP方案在并发为12时，每GPU总吞吐约为240 Token/s，同时保持154 Token/s/user；
TileRT每GPU总吞吐约为160.4 Token/s，但单用户速度达到340 Token/s/user。
因此，TileRT并不是在所有指标上全面优于传统推理引擎。它牺牲了一部分总吞吐，以换取更高的单用户速度。对普通对话流量而言，传统高吞吐Decode仍然更合适；对实时语音、交互式Agent和高价值低延迟请求，TileRT这类方案才更有意义。
这也是报告强调“速度分层”而不是“全面替代”的原因。
与vLLM配合，而不是取代vLLM
大模型推理可以分为Prefill和Decode两个阶段。Prefill并行处理输入Prompt，通常更偏计算密集；Decode逐Token生成输出，更依赖内存访问，也对单Token延迟更敏感。
TileRT的部署方式是将两个阶段拆分开来：vLLM继续负责高吞吐Prefill、调度、Prefix Caching、API和服务管理，TileRT只接管对延迟最敏感的Decode流量。
在这种架构下，同共享的Prefill资源池可以服务两类Decode节点：
一类是使用vLLM的常规Decode资源池，处理普通请求；
另一类是使用TileRT的高交互Decode资源池，处理对延迟敏感的请求。
KV Cache可以通过Mooncake Transfer Engine和NIXL Transfer Engine在Prefill与Decode节点之间传输。由于TileRT目前每个Decode节点只处理一个进行中请求，路由器还需要在节点占用时进行限流和背压控制。
这种设计使服务商不必为所有流量支付高交互Decode的成本，而可以把TileRT作为现有GPU集群中的一个“速度层”。
成本指标为什么值得关注
报告还使用SemiAnalysis的AI TCO模型，比较了特定延迟目标下的每百万输出Token成本。
在8K输入、1K输出场景中，TileRT在B200上达到340 Token/s/user，对应每百万输出Token成本约为13.56美元。报告所列GB200 FP4加MTP方案在并发为5时，单用户速度约为176 Token/s/user，对应成本约为13.4美元。
换句话说，在这组假设下，TileRT的Token成本只高约1%，但交互速度约为前者的1.9倍。
同精度对比更明显。报告列出的最快常规FP8方案是GB300加MTP，单用户速度为108 Token/s，成本约为每百万输出Token 35美元。TileRT在相同精度下达到340 Token/s/user，对应成本为13.56美元，即Token成本低约61%，交互速度约为3.1倍。
这些数字高度依赖报告的硬件价格、利用率、功耗和Benchmark假设，不能直接外推到所有生产环境。但它们说明了一个重要变化：超低延迟不一定意味着成倍增加Token成本。在部分场景中，它可能只是要求服务商重新安排现有GPU资源的用途。
对专用推理芯片意味着什么
TileRT并不会因此取代Cerebras、Groq或SambaNova。
专用芯片仍然拥有明确的硬件优势。例如，更大的片上SRAM、更高的片内带宽，以及从硬件层面支持的数据流执行模型。对于某些模型规模、精度配置和极限速度需求，专用芯片仍可能是更优选择。软件可以尽量接近GPU的显存带宽上限，但无法改变这个上限本身。
TileRT真正改变的是竞争条件。
如果服务商已经拥有大规模GPU集群，那么通过软件将其中一部分GPU临时配置为高交互Decode节点，通常比采购一套新的专用硬件更灵活。GPU资源池可以根据需求在Prefill、普通Decode和高交互Decode之间动态调整；专用芯片集群的速度层容量，则通常在采购时就已经固定。
当未来高交互请求占比不确定时，这种可调度性具有实际价值。需求估计错误时，GPU集群可以通过软件重新分配；专用硬件则可能面临部分资源闲置，或者在高峰期缺少足够的低延迟容量。
报告提到，TileRT Decode引擎已经用于小米MiMo V2.5 Pro UltraSpeed和Z.ai GLM-5.1 HighSpeed的生产部署。两者都没有为此采购新的数据流芯片，而是在现有GPU基础设施上划出了更高速度的推理层。
TileRT目前的主要限制
TileRT面临的最大问题不是Benchmark成绩，而是工程通用性。
由于整个模型需要提前静态展开并编译为持续运行的Engine Kernel，每支持一个新模型，都可能需要重新决定Tile形状、流水线深度、寄存器和共享内存中的缓冲区驻留方式、Warp任务分工、通信融合位置，以及不同GPU的专用角色。
一旦模型的注意力机制或路由方式发生变化，原有调度方案可能就需要重新设计。报告也指出，TileRT目前主要支持GLM-5/5.1和DeepSeek-V3.2，模型目录仍然有限，并且存在依赖版本固定等问题。MiMo V2.5 Pro UltraSpeed则来自联合设计，尚未开源。
这意味着TileRT在一定程度上继承了专用芯片厂商同样面临的问题：编译器和模型适配成本很高。静态编译可以换来低延迟，但会牺牲一部分通用性。
此外，单一的大型Persistent Kernel也会降低传统按Kernel分析性能的工具的可用性，使性能调试和自动优化更加困难。TileRT团队正在通过TileOPs等方式降低这一负担，但新模型和新结构仍需要较多专家工程投入。
结语：重点不是“GPU击败ASIC”
这篇报告最有价值的地方，不在于证明GPU一定比专用推理芯片更快，而在于它改变了超低延迟推理的供给方式。
过去，服务商如果要提供极高的单用户Token速度，往往需要评估专用硬件。TileRT展示了另一条路径：通过Persistent Kernel、静态编译、通信与计算重叠，以及Prefill-Decode分离，在现有GPU集群中构建一个可按需调配的高交互速度层。
它目前仍是一个高度专用的方案：Batch Size有限，模型支持范围较窄，工程适配成本较高，总吞吐也低于传统高并发Decode。因此，它更适合作为高价值低延迟流量的补充，而不是通用推理引擎的替代品。
接下来值得关注的是三个问题：TileRT能否支持更多模型，能否扩展到Batch Size 2、4、8并保持优势，以及在长上下文、多轮Agent和真实生产调度中，能否继续降低端到端延迟。
如果这些问题得到解决，超低延迟推理的竞争重点可能会从“购买什么专用芯片”，转向“如何把现有算力更精细地分层和调度”。
END
