速度革命：TileRT如何让大模型推理延迟骤降，开启Scaling Law新纪元

本文深度剖析了TileRT这一高性能推理引擎，并指出在大模型推理领域，速度正成为全新的Scaling Law。文章梳理了AI推理发展的三个阶段，揭示了行业需求正从模型质量、Token吞吐量，逐步转向对低延迟响应的极致追求。

当前主流推理框架均以吞吐量为核心设计目标，导致大量算力在算子切换、跨卡同步、内存往返等执行边界上被白白消耗，硬件性能难以有效转化为实际响应速度。

TileRT彻底重构了推理的执行模型。它通过编译期常驻内核、瓦片级流水线以及线程专属化等技术，大幅削减了单卡执行过程中的空耗。同时，创新的异构工作器（Heterogeneous Worker）机制，能够拆分GPU的计算职责，完美适配GLM-5.1模型中的稀疏注意力计算场景。

该引擎现已正式上线并承载着真实的生产流量。经过多轮版本迭代，它在长尾延迟、动态路径以及长上下文负载等问题上得到了持续优化。

这充分表明，单纯的算子优化已逼近其性能天花板。未来的发展方向，必然是推进模型、编译器与硬件的深度协同设计，通过极致的推理速度，赋能智能体、实时交互等更高级的AI应用。

本文目录

• 一、延迟正在成为新的智能
  • AI 推理三阶段演进
• 二、推理性能与硬件上限之间的鸿沟
  • Runtime 开始进入关键路径
• 三、TileRT：重新思考推理引擎
  • 从 Runtime Scheduling 到 Persistent Execution
  • Warp Specialization 与 Tile-Level Pipeline
  • TileRT 想解决的，其实是 Execution Gap
  • 从算子 Runtime 到 GPU 驻留式调度
• 四、从 Warp Specialization 到 Heterogeneous Worker
  • 把 Specialization 从 SM 扩展到整个 NVL 域
  • GLM-5.1 中的异构执行
  • 通信开始进入 Tile Flow
• 五、Production-Ready：从实验室极速版到真实流量
  • 从“跑得快”到“持续跑得快”
  • 真正困难的问题，开始越来越“系统”
• 六、下一阶段：协同设计
  • 模型、编译器与硬件开始重新耦合
  • TileRT 只是开始
• 七、The speed is all you need
  • 合作交流

一、延迟正在成为新的智能

自从LLM服务化以来，推理系统的核心矛盾已经经历了数次迁移。

最初的核心问题，是如何让超大规模模型真正地“跑起来”。随后，行业的焦点转向了在单位成本下追求更高的请求吞吐量。更大的batch、更深的队列以及多级KV缓存，逐渐成为推理系统设计的主轴。

然而，实时AI交互正在彻底改变这一局面。

AI 推理三阶段演进

• 2023 — 2024 · Chat Era 代表产品：ChatGPT 经济特征：value < cost 核心诉求：model quality
• 2025 — Now · Agentic Era 代表产品：Cursor、Claude Code、Codex 经济特征：value ≈ cost 核心诉求：token throughput
• Next two years · Autonomous Era 应用场景：工厂智能体、金融、车载系统 经济特征：value »» cost 核心诉求：SPEED

AI推理的三个时代 — 从模型质量，到token吞吐，再到速度，它正成为下一个Scaling维度。

随着Agent、语音交互、代码补全、工具调用以及Test-Time Scaling的兴起，推理系统正被重新推向“延迟优先”的时代。用户不再仅仅关心系统总共能生成多少token，而是开始关注下一次响应是否足够快。这意味着，那些过去被高吞吐所掩盖的固定开销，如今正重新回到性能的关键路径上。

与此同时，Test-Time Scaling也让系统速度直接影响了模型的能力：在固定的延迟预算下，更快的推理意味着能进行更多的rollout、探索更深的推理路径，并拥有更强的自验证能力。

然而，现有的绝大多数推理系统，并非围绕这一目标而设计。

无论是传统的推理框架，还是长期专注于单个Kernel优化的编译器栈，其底层执行假设本质上仍是“吞吐优先”。它们在请求充足时能够有效摊薄开销，但在实时交互场景下，却很难将硬件性能真正转化为端到端的响应速度。

正是在此背景下，TileRT首次赋能GLM-5.1模型，在其官方极速版推理服务MaaS平台上线部署。从最初的实验性原型系统，到如今承载真实的生产流量，TileRT迈出了关键一步。这不仅是一次从prototype到production的跃迁，更代表着我们对大模型推理执行模型的一次系统性重构。

二、推理性能与硬件上限之间的鸿沟

今天，一台8×H200 NVL服务器的聚合内存带宽已接近38 TB/s。

对于GLM-5.1模型而言，单次decode过程中实际激活的参数量约为42 GB。仅从理论带宽估算，在不启用MTP的情况下，token生成速度的理论上限接近1000 token/s。

然而，在真实系统中，端到端的速度往往只有几十token/s，与理论上限之间仍隔着一个数量级的性能鸿沟。正是从这一巨大落差出发，TileRT团队开始追问：问题的根源究竟在哪里？

起初，我们以为问题仅仅在于kernel不够快。直到profiler揭示了一些反直觉的现象：GPU利用率并不低，理论FLOPS表现也不差，但token延迟依然居高不下。

这意味着，GPU并非缺乏算力。真正的问题在于，算力被困在了一道道执行边界之间。

Runtime 开始进入关键路径

今天的大多数推理框架，仍然沿用一种经典执行模型：模型被拆解成一连串独立的算子，每个operator单独启动、同步，并完成各自的内存往返。这套抽象在训练时代非常成功，因为kernel足够“大”，计算能够自然掩盖launch、同步与runtime调度的固定成本。

但decode改变了这一时间尺度。

在追求极低延迟（latency-first）的苛刻要求下，每一个单独 kernel 的生命周期已经缩短至微秒级别。过去在吞吐量优先场景中能被轻松摊薄或掩盖的固定开销，如今重新浮出水面，成为不可忽视的瓶颈：包括 kernel 启动（launch）、跨 kernel 的同步屏障（barrier）、全局内存的溢出（spill），以及网络通信的同步延迟。这些因素全部踏入了端到端延迟的关键路径。

在进行性能剖析时，我们频繁观察到一种反直觉的现象：许多 kernel 甚至还没来得及“热机”，就已经执行完毕。

GPU 被迫不断重复着如下僵化的执行流程：

launch → load → compute → store → synchronize  

每一次 kernel 执行的边界，都会粗暴地打断数据流，破坏数据的局部性，并强制所有执行单元重新同步。很多时候，真正限制系统速度的，并非某个 GEMM 核心运算本身的快慢，而是另一个更致命的问题：下一次计算究竟何时才能开始？

在过去，运行时系统（runtime）是 GPU 编程的便利层；但在超低延迟推理的语境下，它正日益成为性能瓶颈本身。问题的核心不再局限于 kernel 内部，而是转移到了：kernel 与 kernel 之间的间隙。

这也正是 TileRT 诞生的起点。

unsetunset三、TileRT：重新构想推理引擎unsetunset

TileRT 的核心判断是：当运行时系统的任务编排开始占据延迟的关键路径时，解决方案或许不再是“继续优化运行时系统”，而是从根本上重新设计推理系统的执行模型。

在传统的推理框架中，GPU 执行的是一个个彼此孤立的 kernel。执行流被 kernel 启动、同步操作、算子边界以及频繁的内存往返（memory round-trip）切割得支离破碎。

而在 TileRT 中，我们尝试了一条截然不同的道路：GPU 不再执行一串离散的 kernel，而是持续运行一个长期驻留的任务流水线。

从运行时调度到持久化执行

TileRT 在编译期（AOT）将整个模型静态展开，生成一个常驻的 Engine Kernel。

Tile-level Task Scheduling：算子被拆解为 tile 级别的任务，调度到 warp group 上。CTA 通过 warp/block specialization 机制，转变为异构的工作单元（heterogeneous worker）。算子被分解为 tile，任务被调度到 warp group，CTA 通过 warp/block specialization 成为异构的 worker。

在整个解码生命周期中：

• Host 端仅启动一次
• 任务执行流（execution flow）持续驻留在 GPU 内部
• 大量的运行时调度工作被前移至编译期完成

传统的执行模型更接近于“算子接算子”的连续调度，而在 TileRT 中，任务执行流被进一步组织成一个持续推进的 tile 计算流水线。

在这里，tile 的意义远不止是更细粒度的任务划分。它本质上是一种全新的任务调度抽象：计算、通信与异步 I/O 被统一拆解为 tile 级别的任务，并在 GPU 内部持续向前推进。

Warp Specialization 与 Tile-Level Pipeline

为了维持这种持续执行的模式，TileRT 在 Engine Kernel 内部采用了更为激进的 Warp / Block Specialization 策略。

不同的 warp group 被赋予不同的职责：

• 一部分负责异步数据搬运
• 一部分负责张量计算
• 一部分负责通信与计算的重叠

过去，许多执行阶段必须串行推进：

load → barrier → compute → barrier  

而在 TileRT 中，数据搬运、张量计算与通信开始以 tile 为粒度持续重叠。大量的中间结果不再需要反复写回全局内存（global memory），而是直接停留在寄存器、共享内存（shared memory）以及 L2 缓存中，继续向后流动。

从性能分析器（profiler）的角度看，这种变化非常显著：GPU 不再表现得像“不断启动新 kernel”，而更像一个持续运行的执行流水线。

TileRT 的核心目标：消除 Execution Gap

随着解码（decode）延迟被不断压缩，我们逐渐发现，真正吞噬延迟的很多时候并非计算本身，而是：

• kernel 与 kernel 之间的等待时间
• 通信与计算之间的停顿
• 运行时系统与设备之间的同步开销

TileRT 的诸多设计——持久化 kernel、tile 流水线、warp specialization——本质上都围绕着同一个目标：尽可能压缩执行间隙（execution gap）。

从算子运行时到 GPU 驻留式调度

当越来越多的调度逻辑被下沉到 kernel 内部后，推理系统本身也开始呈现出一种与传统推理运行时截然不同的形态。

过去的执行模式：

• 调度发生在 host 端运行时
• 同步发生在算子边界
• 通信由外部框架组织

当前的执行模式：
越来越多的执行编排（execution orchestration）开始驻留在 GPU 内部。

运行时不再需要不断地“驱动 GPU”，而是更像在初始化并维护一个持续运行的执行流水线。

unsetunset四、从 Warp Specialization 到异构工作单元unsetunset

持久化执行流解决了单卡内部的大量执行空泡。然而，当系统扩展到 8×NVL 规模后，我们遇到了另一种边界：同构并行抽象本身的局限性。

今天的大多数张量并行（TP）框架，都默认所有 GPU rank 执行相同的逻辑，并通过同步来共同推进执行流。这种方式在稠密训练时代非常自然，但推理场景开始改变这一点。

随着稀疏路由、Top-K 选择、动态索引、长上下文注意力机制以及 MTP 执行不断引入系统，越来越多的执行阶段开始表现出一种新特征：它们并不天然适合同构扩展。

很多阶段本身计算量不大，但高度依赖全局信息、动态依赖和同步。如果仍然强行让所有 rank 执行相同逻辑，往往会引入大量重复计算、广播和同步放大。

将 Specialization 从 SM 扩展到整个 NVL 域

我们后来意识到：既然 warp 可以实现 specialization，GPU 本身为什么不可以？

于是，TileRT 开始进一步将 specialization 的思想从 SM 内部向外扩展：

warp specialization → block specialization → GPU specialization  

不同的 GPU 不再被视为完全对称的执行单元，而是根据计算密度、通信成本与数据依赖关系，承担不同的职责。从某种意义上说，异构工作单元（Heterogeneous Worker）本质上是 Warp Specialization 在更大尺度上的延伸。

GLM-5.1 中的异构执行

在下图中，GLM-5.1 的注意力机制被拆解为异构 worker：GPU 1–7 运行 MLA（包括 Projection、Q/K/V、Selection、Attention、All Reduce），GPU 0 运行 Sparse Indexer（包括 Index Q/K、Sparse Index Score、Top-K、Broadcast、All Reduce）。Sparse Index 的结果反馈给 Selection。

GLM-5.1 中注意力机制的异构拆分 — GPU 0 运行稀疏索引 Worker，GPU 1–7 运行 MLA Worker。

在 GLM-5.1 的执行流中，我们最终将 attention layer 拆解为两类异构工作单元。

GPU0：稀疏索引 Worker

GPU1–7：MLA Worker

稀疏索引 Worker 专司 Top-K 筛选、稀疏索引构建以及路由决策；而 MLA Worker 则承担 RMSNorm、GEMM、Flash Sparse Attention 与 AllReduce 等计算密集型环节。

这一拆分的核心价值，远不止于“功能划分”。更关键的是，不同的执行环节从此拥有了差异化的扩展策略。某些阶段对全局信息依赖极强，同步开销主导了计算，因此更适合集中式执行；另一些阶段则天然适配张量并行。

通信开始融入 Tile Flow

在传统推理框架中，通信通常仍然是执行流之外的独立阶段。但在 TileRT 中，通信被进一步下沉到执行流水线内部。整个 attention layer 在 host 侧仅对应一次 Engine Kernel 启动，大量广播、归约与同步直接在 tile 级任务流水线内部完成。

传统执行逻辑

compute → sync → compute

TileRT 重叠执行逻辑

compute ↔ communication ↔ compute

形成持续重叠的执行流水线。

五、Production-Ready：从实验室极速版到真实流量

极致的 benchmark 往往是脆弱的。

真正困难的问题，从来不是如何在实验室里跑出一个漂亮数字，而是如何让系统在真实生产流量下，持续稳定地逼近硬件极限。

从 prototype 走向 production 的过程中，TileRT 让我们愈发清晰地感受到：超低延迟推理，本质上是对执行流水线持续推进能力的极限维护。许多在 benchmark 环境下不会暴露的问题，一旦进入真实流量就会被迅速放大。在 benchmark 中，序列长度通常相对稳定，路由模式更理想，请求到达更规整，KV cache 生命周期也较短。

但真实生产流完全不同。

长短上下文会持续交织，KV cache 会不断增长、碎片化与迁移，不同请求间的路由模式也会持续波动。而在 MTP 场景下，accept/reject path 甚至会不断改变执行流本身。

从“跑得快”到“持续跑得快”

过去半年里，TileRT 经历了数轮关键的执行模型重构。但这些重构的核心目标，并非继续推高峰值速度，而是解决一个在真实生产环境中更为棘手的难题：如何让执行流持续稳定地运行下去。

在 v0.1.1 版本中，我们进一步压缩了执行流水线的空泡，引入了更细粒度的 overlap，并对 Engine Kernel 内部调度方式进行了重新组织。这类优化未必会显著抬高理论计算性能上限，却能切实改善端到端延迟，尤其是 tail latency。因为在真实服务中，用户感知到的往往是“最慢的那几次”，而非“最快的那一次”。

到了 v0.1.2-alpha.1，MTP（Multi-Token Prediction）开始融入 TileRT 的执行流。表面上看，MTP 是为了“一次生成更多 token”；但从系统视角看，它带来的真正挑战是执行流开始变得动态。accept/reject path 会持续改变 pipeline 的推进方式，而 draft/verify 之间也会引入新的 synchronization dependency。换句话说，系统不仅要跑得快，还要在执行路径不断变化时，依然保持流水线不断流。

当 v0.1.3 正式支持 GLM-5 模型后，新的系统问题进一步浮现。随着 FP8 与超长上下文场景进入生产环境，KV cache 压力、访存局部性、communication amplification 开始成为影响稳定低延迟的关键因素。此时，瓶颈已不再只是某个 kernel 是否足够快，而是整个系统能否在复杂负载下持续维持执行流的持续推进。

接下来，我们将公布 v0.1.4 版本。这个版本将进一步面向超长上下文生产环境进行优化，并引入全新的 Heterogeneous Worker 执行模型。它的目标，是让 TileRT 不仅能在理想条件下跑出漂亮数字，更能在真实流量、动态路径、长上下文和复杂通信模式交织的生产环境中，持续稳定地保持高效。

真正困难的问题，开始越来越“系统”

随着性能不断逼近硬件边界，我们愈发清晰地感受到，真正困难的问题已不再只是 GEMM 优化、kernel 调优或 operator 融合。

很多时候，系统不是“算得不够快”，而是任务执行流水线无法持续稳定地流动。

今天，TileRT 已正式承担 GLM-5 / GLM-5.1 的生产流量。但我们越来越觉得，benchmark 其实只是整个系统问题中相对容易的部分。真正困难的问题，开始越来越接近：

• runtime architecture
• distributed scheduling
• memory system behavior
• model-system co-design

而这，也正在推动推理系统从“算子优化”逐渐演化为真正的 AI execution infrastructure。

六、下一阶段：协同设计

当系统性能开始逼近硬件边界后，我们愈发清晰地感受到，许多问题已无法继续通过局部优化解决。

过去几年，大模型系统优化的大部分工作，本质上都发生在算子/kernel 层：更快的 GEMM、更激进的融合、更高效的 communication overlap，以及更复杂的 scheduling policy。但许多 bottleneck 已不再局限于某个 operator，而是存在于整个任务流水线本身。

我们开始越来越频繁地撞上“结构性边界”：

• memory hierarchy 与模型结构之间的不匹配
• communication topology 与 routing pattern 的冲突
• KV cache 增长与 locality 之间的矛盾
• dynamic sparsity 对传统同构并行 abstraction 的破坏

这些问题有一个共同点：它们已无法仅靠 runtime 修复。

很多时候，系统本身已非常接近硬件极限，但模型结构仍会不断制造新的执行流碎片。于是我们逐渐意识到：未来的极致性能，不可能只来自推理框架本身，而必须来自更深层次的协同设计。

模型、编译器与硬件开始重新耦合

过去，模型、编译器与硬件之间更像一种单向适配关系：

model → compiler → hardware

模型先被设计出来，然后 compiler 尝试 lowering，runtime 尝试调度，kernel 工程师再去“补救”执行效率问题。

但在超低延迟推理场景下，这种方式开始越来越困难。随着执行流水线被不断压缩，任何访存局部性被破坏、communication amplification 或 synchronization expansion，都可能直接进入延迟关键路径。

模型结构本身，也开始越来越直接地影响系统执行行为。

TileRT 只是开始

TileRT 并非这个方向的终点，它更像一次尝试：我们开始不再把推理系统视为“一串被 launch 的 kernel”，而是将其视为一个持续流动的任务流水线。

过去，大模型 Scaling Law 讨论的是参数量、数据量与训练算力；但当推理开始成为 AI 产品真正的核心环节后，速度本身也开始成为一种新的 Scaling Law。

因为推理速度开始越来越直接地影响模型在固定延迟预算内能够完成的推理深度、交互质量与 Agent 响应能力。

七、The speed is all you need

回顾过去十年，GPU的主要使命是最大化大规模并行计算的效率。然而，展望未来，它将越来越多地承担起另一项职责：在极为严苛的延迟预算内，持续维持任务流水线的顺畅运转。

这一转变将迫使模型架构、编译器、运行时系统以及硬件设计协同进化。

因为，速度正在直接且深刻地影响着：

• 推理的深度
• 交互的体验质量
• Agent的响应敏捷性
• 真实世界中的生产力水平

而TileRT，正是沿着这一方向迈出的关键一步。

合作交流

TileRT团队正致力于高性能AI系统的底层架构构建与性能极限探索。

如果你对GPU架构、编译器优化、分布式执行或大规模推理系统抱有浓厚兴趣，欢迎与我们交流或加入我们。

• 开源代码库（部分模块）：github.com/tile-ai/TileRT
• 技术与合作交流：tile-ai@outlook.com

The speed is all you need.