NVIDIA GPU的极致交互推理？TileRT InferenceX解析
高价“快速模式”证明，用户愿意为更低延迟和更快的代币支付更多费用，从而可能带来更高的毛利率。前沿人工智能实验室，如因此，OpenAI正在评估专门构建的推理系统，包括Cerebras和NVIDIA Groq LPUs。
优先考虑超高交互性，而非最大批量吞吐量。超低延迟在交互工作负载中尤为重要，包括实时助手和全双工语音。例如，OpenAI GPT-Live可以同时听说，使响应延迟对用户能立即感知，被形容为像钢铁侠JARVIS的感觉.
GPU在高吞吐量和低至中等交互性下表现优异，但其架构不适合超低延迟推断。一台8GPU的HGX B200服务器理论上可提供64 TB/s的HBM内存带宽。
在批次大小为1时，NVFP4下的GLM-5只需每个生成令牌约21 GB的主动参数流量。因此，B200 HBM带宽的车顶线建议在不进行投机解码的情况下，每用户最多获得3,047个代币/秒。
实际上，GPU远远没有达到这个极限。
差距来自延迟，而非带宽。传统的GPU编程模型启动并同步多个独立内核，在超高交互性水平下，其设置和拆除开销变得显著。虽然这些延迟成本在传统服务速度下不那么明显，但即使是CUDA图，但当代币延迟接近亚毫秒级的输出时间（TPOT）范围时，延迟成本依然占主导地位。
此外，尽管GPU内存带宽每代增加约2–3×但内存延迟并未改善。
虽然使用替代硬件很受欢迎，但也有方法用GPU来实现这一点。这里是TileRT 的持久引擎进来了。TileRT 在 NVIDIA GPU 上静态编译整个译码图到单个持久内核中，最大化计算、内存加载和存储以及通信的重叠。在单个B200解码服务器上的InferenceX GLM5 FP8 744B基准测试中，tileRT已被验证可达到每用户500个token/s，约比运行传统推理引擎的GB300 NVL72快3×。通过每个输出代币的等成本计算，TileRT 的交互性速度可比传统引擎快达 2 倍。
我们感谢TileRT维护者在TileRT InferenceX基准测试上的合作，也感谢vLLM社区在V1连接器上做出的精彩设计。TileRT 来自同一个构建广受欢迎的 TileLang DSL.
通过PD拆分推理技术，超专业化的TileRT引擎处理延迟敏感的解码，而吞吐量优化的引擎如vLLM和SGLang继续服务预填充。TileRT 译码引擎已经在生产环境中部署小米 MiMo V2.5 Pro UltraSpeed以及ZAI搭载GLM 5.1高速发动机。
本文将深入探讨TileRT InferenceX的结果、TileRT是什么、它如何与现有推理生态系统结合，以及TileRT的权衡与挑战。
我们还将详细说明在标准GPU上使用TileRT与使用Nvidia Groq LPU、Cerebras和Sambanova等超低延迟专用芯片之间的权衡，并对运行在GPU上的TileRT软件是否可能干扰这些专业芯片的TAM（分析）发表看法。
半分析加速器模型提供了英伟达LPU30、LPU40、Cerebras WSE-3和WSE-4出货量等季度估算。
InferenceX
InferenceX 是我们开源、供应商中立、持续更新的 AI 推理基准测试和研究平台。我们衡量了帕累托延迟吞吐前沿的领先模型、推理框架和硬件，跟踪现实世界的推理性能和经济性随时间的提升。
感谢阅读SemiAnalysis！这篇帖子是公开的，欢迎大家分享。
我们的基准已被几乎所有主要买家广泛复制、验证和/或支持计算由谷歌云到Microsoft Azure到神谕者，到元文化以及更多。此外，它具有支持机器学习社区，包括vLLM、LMCache、SGLang、PyTorch、Huggingface以及支持像OpenAI、MiniMax、ZAI、Qwen、Moonshot Kimi等大型实验室。
如果你觉得开源基准和数据有用，给InferenceX GitHub仓库点星！.如前所述，英伟达已承诺向InferenceX提交可验证的Vera Rubin数据。
我们很快会有Google TPUv7的结果，AMD今年也承诺推出MI455X UALoE72。
吞吐量与交互性曲线
每个推理系统都必须平衡两个相互竞争的目标。
- 交互性（tok/s/用户）衡量单个用户接收令牌的速度，即每个输出令牌时间（TPOT）的倒数。它决定了回复是快节奏还是慢节奏。
- 吞吐量（tok/s/GPU）衡量系统在所有用户中总共产生多少代币。它在很大程度上决定了每个代币的成本。
批处理通过同时处理更多请求来提高聚合吞吐量，但每个用户通常等待每个令牌的时间更长。小批量则相反：它们提高了每个用户的速度，同时减少了每个GPU总计完成的有用工作量。
公交车将费用摊销给许多乘客，但让每个乘客都得在共享站点等待。赛车只载一到两个人，能更快到达目的地，但每位乘客的成本要高得多。
推理同样有权衡：批处理提升了总吞吐量和每枚代币的成本，而小批量则提高了每个用户的响应速度。没有放诸四海而皆准的操作方法。
在下面的配置中，将交互性从大约25个token/s/s/s/用户提升到260个token/user，会使每个GPU的吞吐量从大约5900个token/s/gup减少到200个。
这大约意味着总吞吐量减少30×，但每个用户速度提升10×。
TileRT 结果
正如我们在下一节所描述的，GPU在高吞吐量场景中表现良好，但在高交互性场景中表现不佳。这一弱点催生了数据流芯片的整个市场细分。
TileRT针对同样的弱点，因此专注于高交互性操作点。
SemiAnalysis 是一份由读者支持的刊物。想接收新文章并支持我们的工作，请考虑成为订阅者。
B200上的TileRT独树一帜。在8k/1k输入/输出令牌场景中，TileRT在一个八GPU的B200节点上达到了每用户340个令牌。当前数据集中最快的结果是 GB300 NVL72 搭配 NVFP4 和 MTP 的 181.4 tokens/s/user，使得 TileRT 1.9× 更快。
当然——这是在批次 1 阶段，GB300 NVL72 复杂铜背板设置的额外麻烦根本不会影响交互性。
与此同时，最快的FP8结果是B300带MTP的每用户113.6令牌，使得TileRT 3.0×在相同精度下更快。
在1k/1k输入/输出时，TileRT FP8达到494.2令牌/秒/用户。这是1.9×最佳常规结果，使用FP4时为256.3个令牌/秒/用户，3.6×为最佳常规FP8结果，为136.3个令牌/秒/用户。
TileRT 目前还没有 FP4 支持，但它已经超越了非 TileRT FP4 的实现！这一结果也值得注意，因为它来自一个八GPU的B200节点，而非GB200或GB300 NVL72的72GPUNVLink扩展域。
这种比较关注的是每个用户的交互性，而非总吞吐量或成本。
然而——推理总有权衡！TileRT的交互性优势在于较低的总吞吐量。传统引擎可以随着并发率提升，将权重负载和固定内核成本摊销给更多用户。
在8K/1K输入/输出时，GB300 FP4+MTP点在并发12时可提供约240个总token/s/GPU值，同时保持154个token/s/用户值。TileRT 提供 160.4 个 token/s/GPU 服务，同时达到 340 token/s/用户。
因此，权衡是：TileRT提供更高的用户速度，但传统的GB300点在GPU上完成的总工作量更多。截至发布时，TileRT每个译码节点只提供一个在运行中的请求，使其成为一个专门的操作点，而非通用的吞吐量配置。
因此，TileRT仅支持一批1人用户，它不仅仅是一辆赛车，更像是一艘只容纳一名乘客的私人火箭。通过工程技术支持更多乘客或许可以实现，但这是一个雄心勃勃的目标。
在端到端延迟方面，FP8的TileRT比此前最佳GLM-5.1成绩高出4.5×1k/1k时高出3.0×。正如预期，TileRT的首个代币时间（TTFT）不错，但并不特别出色。
决定性的优势来自解码尾部：3.01秒，而最佳NVFP4 + MTP竞争对手为6.54秒，MI355X为18.18秒。
但TileRT到底是什么？
我们简要介绍了TileRT的工作内容并展示了一些基准测试结果，但让我们暂停一下，更深入地解释一下TileRT是什么以及它是如何工作的。
传统的服务引擎以成千上万个独立的GPU程序内核顺序启动运行。所有这些设置和拆解意味着GPU需要花费大量等待时间，虽然对于低到中等交互性推断可能无关紧要，但对于超高交互性推断（也就是低延迟推断）来说，这点时间肯定重要。
更糟的是，每个内核都把半成品写给了HBM。在小批量时，问题更大，因为内核容量不足以摊销启动延迟、同步和调度开销。
SemiAnalysis 是一份由读者支持的刊物。想接收新文章并支持我们的工作，请考虑成为订阅者。
如前所述，当以批次大小1运行TileRT时对于单个 HGX H200 服务器（38.4TB/s 的 HBM 总内存带宽），在 MXFP8 下，主动参数内存带宽为每个令牌 42GB。
理论上，如果我们只受限于内存带宽，即使不做规格解码，推断也应该能达到1000 tok/s/用户交互性。现实中显然不是这样！障碍在于GPU的编程和架构模型传统上并非为低延迟设计。
尽管每代GPU内存带宽增加了2-3倍，内存延迟却丝毫没有改善，尽管HBM价格持续上涨！
TileRT 不连续启动内核，而是让 GPU 持续执行持久流水线，静态提前将整个模型编译成持久引擎内核：主机启动一次，执行过程在整个解码生命周期内保持在 GPU 上，大多数运行时编排进入编译时。
这与CUDA图不同，CUDA图只捕捉一次内核启动和memcpy的有向无环图，然后用单一cudaGraphLaunch重放。但内核本身仍然是独立的内核，内核之间的边界带来了设备端成本，且片上状态在每个边界处都会被清除。
CUDA 图优化了内核的启动，而 TileRT 则废除了内核作为执行单位。
此外，通过将工作分解为具有曲速和块专用的瓦片级任务，运行时能够动态重新调度计算、输入输出和通信，实现高度重叠。在引擎内核内部，不同的曲速组承担不同的任务：异步数据移动、张量计算和通信重叠。
过去阶段作为负载→障碍→计算→障碍串行运行，现在它们在瓦片粒度上重叠，中间结果通过寄存器、共享内存和L2向前流动，而不再反复溢出到全局内存。
实际上，每个CTA（协作线程数组）都变成了一个小型异构工厂，而不是统一的SIMT（单指令多线程）工作单元。
TileRT 引入的下一个优化是将专用化扩展到整个 GPU。大多数TP框架假设所有秩同步执行相同逻辑，但稀疏路由、Top-K选择、动态索引、长上下文关注和MTP并不适合同质规模;它们计算量不大，但依赖全局信息，所以强制每个等级通过它们会增加冗余工作和同步放大。
所以，如果Warp可以专门化，GPU也可以。在GLM-5.1的注意力层中，GPU 0成为一个稀疏索引器工作者，负责Top-K选择、稀疏索引构建和路由，而GPU 1至7则运行执行RMSNorm、GEMM、闪烁稀疏注意力和AllReduce的MLA工作者。
最后，广播、简化和同步直接在瓦片层级流程中执行，而非将通信视为外部阶段;而TileRT则对应主机的单一内核启动，执行方式从计算→同步→计算转向连续重叠的计算↔通信↔流水线。
带有vLLM的PD分解引擎<>TileRT
LLM推理包括两个不同的阶段：预填充和解码。预填充并行处理输入提示，主要计算密集型，因此汇总吞吐量是关键性能指标。Decode按顺序且反复地生成代币，访问不断增长的KV缓存，使其内存密集且对每个代币延迟高度敏感。
TileRT 并未取代 vLLM，vLLM 依然是高吞吐量的预填充引擎及其周边的服务层，包括其调度器、分块预填充、前缀缓存、兼容 OpenAI 的 API 以及运营工具。
只有对延迟至关重要的解码流量会转移到TileRT。TileRT被设计为单人火箭飞船，vLLM依然是飞机、汽车、公交和火车。
预填充和解码阶段可以被拆分成独立的节点。使用disagg，一个共享的vLLM预填充池可以同时供给两个完全不同的解码池。
- 池A：与TileRT实现超高交互性解码
- 延迟关键请求会通过 TileRT PD 路由器，该路由器指示 vLLM 生成第一个令牌，并将请求标记为目标 TileRT 节点kv_transfer_params。
- 池B：通用低至中等交互性解码，配合vLLM解码
- 一般流量通过vLLM的本地拆分代理继续进入传统的vLLM解码池。
这通过 vLLM 的 MultiConnector API 实现，该 API 将 TileRTConnector 及其原生连接器组合在一起。TileRT 连接器声称只标记了高交互性流量类别请求，其他所有请求都变成了禁用，这意味着两个流量类别可以共享同一预填充服务器。
在预填充和解码之间，TileRT 使用 Mooncake Transfer Engine 和 NIXL Transfer Engine 来移动 KVCache。在 TileRT v0.1.5 中，每个译码节点一次只提供一个在飞行中的请求。
路由器在节点被占据时进行门分发并施加反压。
感谢阅读SemiAnalysis！这篇帖子是公开的，欢迎大家分享。
TileRT和Cerebras/Groq/SambaNova相比如何？
专门设计的推理厂商多年前就发现了同样的执行瓶颈，但更多地将解决方案编码在硬件中。半分析加速器模型包含我们对NVIDIA LPU30、LPU40、Cerebras WSE-3和WSE-4出货的季度估算。
Groq 采用确定性编译器编排执行和庞大的片上 SRAM 层级结构。Cerebras 在晶圆级处理器上空间映射计算;CS-3 提供约 900,000 个核心、44 GB 片上 SRAM 和 21 PB/s 的内存带宽。
SambaNova 将模型图映射到可重构的数据流单元上，这些单元由分层 SRAM、HBM 和 DDR 内存系统支持。
SemiAnalysis 是一份由读者支持的刊物。如需接收新文章并支持我们的工作，请考虑成为订阅者。
硅片不同，但两系统共享相同理念：延迟敏感推断通过减少运行时调度、操作员边界、同步以及外部内存中的不必要移动而受益。在大批量时，这些成本更容易摊销。
在批次大小1时，它们占据每个代币延迟的份额更大。
TileRT 导入了多个数据流理念的软件对应物：AoT 调度、持久执行、专用工作者，以及通信与计算之间的更紧密重叠。这种相似性更多是建筑上的，而非字面上的。
TileRT 仍然运行在带有动态硬件调度、HBM 和特定型号编译调度的 SIMT GPU 上。
然而，TileRT 仍然是纯软件：数据流被强加在一台从未专门设计过的数据流机器上。GPU承载动态曲速调度器、SIMT模型和HBM层级结构，TileRT通过投入大量编译器工作，说服该机制通过静态扩展的持久内核、手工雕刻的曲速专用化以及针对钉定驱动栈的逐模型编译来模拟空间流水线。
原生数据流硅片从不与自身基底发生冲突。专门设计的加速器在硬件中编码了更多执行模型，并能避免TileRT在软件中隐藏的一些开销。
它们的优势仍取决于型号、精度、内存层级、编译器质量、系统规模和服务配置。这就是为什么Cerebras以任何八GPU节点无论调度如何都无法达到的速度，提供密集的70B：软件可以接近HBM的车顶线，但无法提升。
市场早期的答案是纯度是可以协商的。TileRT的解码引擎已经在小米的MiMo V2.5 Pro UltraSpeed和Z.ai而部署模式就是关键。两家公司都未采购新的数据流芯片。
他们从已经运行的加速器集群中划出了一个速度层级，vLLM 保留预填充、调度和 API，而 TileRT 则负责同一端点的解码。在你已有的硬件上表现足够好，往往比你必须购买的硬件架构纯粹的还要好。
这也指出了更深层的结构性问题：预填充-解码（PD）比例的可替代性和灵活性。
GPU池是一个液态资源，预填充时表现优异，高批次到中批次解码时表现优异，现在在Ultra-Interactive Decode上表现得相当强劲容量在这些角色之间通过软件调度器决策在这些角色之间流动，可以按小时跟踪需求。
ASIC车队则相反：速度级容量与其他所有设备的比率在购买订单签署当天硬件中确定。改变实体车队的比例需要数月时间才能物理重新机架和重新布线。
如果工作量组合稳定且明确，那还好。不幸的是，需要普通对话延迟的用户与越来越多的客服人员（愿意为极具交互性的SLO付费）之间的差异，在估算时涉及许多不同的变量。
如果GPU判断错了，软件里就得重新平衡。如果用独立硅片猜错了，你要么把资本留在闲置速度机器上，要么拒绝你买来的高端流量。此外，需求可能会随着时间变化，所以正确猜测只能在有限的时间内正确。
回到前面提到的共享预填充池，服务提供商无需为所有流量支付TileRT溢价。通用请求可以保留在吞吐量优化的 vLLM 或 SGLang 解码池中，而只有延迟关键的请求会被路由到 TileRT 解码池。
这些都不会扼杀速度市场的顶尖。SRAM 屋顶线依然更好，某些尺寸的型号仍然偏好它，而且有些工作负载无论价格如何都要求每秒最大令牌数。
但TileRT重新定义了大多数买家的需求：不是速度机器，而是速度等级，动态配置出他们本来就要拥有的车队。Cerebras、Groq 和 SambaNova 不再是笨拙的内核发射器竞争。
它们是在与自己的执行模型竞争，运行在可替代硬件上，通过配置文件重新分配。TileRT虽然是单人火箭，但它允许供应商将固体火箭助推器绑在地铁公交车上，而无需设计全新的运载火箭。
为什么 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）、硬钉的依赖关系，以及每个新架构的实际工程投入。
没有完全通用的路径，持久引擎内核意味着模型会提前静态扩展成一个常驻程序，因此必须在磁砖形状、流水线深度、寄存器/共享内存/L2 间的缓冲区驻留、warp 组如何在加载、计算和通信之间分配，以及集体如何融合到磁砖流中做出决策， 以及哪些GPU承担了如GLM-5.1专用稀疏索引等级等专门角色。
改变注意力机制或路由方案，许多时间表就会失效。数据流芯片也面临同样的问题，优秀的编译器往往很难制作。
目前正在努力简化这一过程，尤其是随着人工智能加快软件开发的进程。TileOPs旨在减轻这一负担。每个操作员在机器可读的清单中声明，指定其签名、工作负载和屋顶线模型。
清单驱动代码生成、测试和基于硬件边界的基准测试，而不仅仅是针对早期实现。
AI编码代理加速了已知模板内的调优，但新颖的转换仍需专家判断。单体持久内核还降低了传统每核分析器时间线的实用性，使自动化反馈循环更加困难。
TileRT<>InferenceX 的下一步
我们正在积极推动将 TileRT 的基准测试从 InferenceX 的单回合 8k/1k 以及我们新的代理编码基准——AgentX 中迁移出来。该场景重现真实的Claude代码和Codex轨迹，包含长上下文、多回合请求、真实子代理活动以及动态工具使用延迟。
其中位输入长度为14万个代币，理论中位缓存命中率屋顶线可达99.2%。
该工作负载将测试整个 TileRT<> vLLM 系统，而不仅仅是解码速度，包括增量 KV 传输、前缀缓存重用、缓存保留与卸载、路由和调度。
关键问题是 TileRT 是否能在回合间仅传递新引入的上下文，同时保持其超高交互性优势。
第二步是超越批量大小。我们还将在批次大小2、4和8时对TileRT进行基准测试。目标是绘制其吞吐量-交互性帕累托边界，并识别持久引擎内核延迟优势开始趋于平稳的点。
SemiAnalysis 是一份由读者支持的刊物。想接收新文章并支持我们的工作，请考虑成为订阅者。
TileRT 超高速的每总总成本性能
接下来，我们深入分析了TileRT在超高交互性下每百万输出代币的成本与正常低交互性操作点下的译码。结果相当有趣，TileRT在与传统引擎进行等价后，交互性提升了1.9倍。
我们以AI总有成本模型作为每个芯片SKU的资本支出和运营支出基线。
点赞
收藏
点踩
分享