8 月 1 日，由 HyperAI 主办的 Meet AI Compiler 技术沙龙第 9 期在北京中关村圆满落幕。本期沙龙一如既往的火热，来自业内的专家倾情讲解，汇聚智源研究院、TileRT 团队、腾讯、华为昇腾、智元创新等多家头部企业与科研机构的技术大咖，围绕 AI 编译领域的前沿技术、底层优化、开源生态与场景落地展开深度分享，为现场开发者、技术从业者带来了一场干货满满的技术盛宴。

现场，TileRT 团队核心成员马凌霄以「速度即智能——面向超低延迟大模型推理的计算探索与协同设计」为主题，深度介绍了 TileRT 的最新进展，从 AI 编译器、Runtime 架构演进到模型-系统协同设计，以及与智谱（Z.AI）、小米 MIMO、vLLM 等多家头部企业与技术社区的融合成果、实践案例，详细展示了面向超低延迟的大模型计算软件栈。

马凌霄老师与现场观众深度交流

HyperAI 在不违原意的前提下，对演讲分享进行了整理汇总，以下为演讲实录。

推理速度已成为高价值 AI 场景的核心竞争力

2022 年底至 2023 年初 ChatGPT 横空出世，其所展示出的能力让人瞠目结舌。然而回头再看，早期模型展现出的应用场景主要在于聊天、陪伴等方面，它所产生的实际价值相对来说远低于算力成本，大模型的输出只要跟上人的阅读速度即可。此时，大家所追求的不过是总系统的一个吞吐速度，而非模型的输出速度。

而从 2025 年年底至今，不到一年的时间中，类似 Claude Code 的这类 Coding agent 的出现，让大家发现大模型潜在海面之下的更多能力，比如真正帮助人们提升生产力，这时相比算力成本，它事实上已经产生出更高的实际价值。因此，最近大家也可以看到各种各样的算力需求暴增，这也是一个对高吞吐最直观的反映。

根据这一发展趋势展望未来，随着模型能力的日益增长，模型将毫无意外的参与到更多自动化的工作当中，比如 AI 工厂、量化决策、实时风控等项目，这时模型的输出对象将会是模型本身，因而也会产生一个 AI 自动化的工作流。在这一阶段，模型运行的越快，它的工作效率也将越高。极致的模型速度将会成为决定生产效率和体验的核心因素。

最新的相关行业新闻也在一个接一个的印证上述推测：

* 2025 年年底，英伟达斥巨资收购 Grop 布局高速推理；

* 2026 年 2 月，Anthropic 推出高速版 Claude Fast；

* 同月，OpenAI 联合 Cerebras 推出 GPT-Codex-Spark；

* 5 月份 Cerebras 又释放消息，称通过晶圆级芯片让 1T 级别模型实现了接近 1000 TPS 的推理速度；

* 另外就在两三周之前，OpenAI 又联合 Cerebras，使其最先进的旗舰模型 GPT-5.6-Sol 可提供 750 TPS 的高速版推理服务。

Test-Time Scaling（TTS）实际上就是增强模型效能的主要途径。假设现在有相同的时间窗口，比如以 10 秒为例，在一个较低速度的模型推理服务中，以 50 token/s 来说，它只能产生 500 token 的思考；如果将模型推理速度从 50 token 提升到 1000 token，它将会产生 10000 token 的思考。毫无疑问，在相同的时间窗口，推理速度将实现更好的模型智能。

那么，大家或许会有疑问，TTS 的实现方式有很多，比如 Best-of-N，只需要 batch 就可以实现更强的只能，为什么要去追求速度呢？这就需要将 TTS 进行拆解，分为深度和宽度两个维度来看，TTS 这类工作可以通过 batch 达到目的，但从长链的思维链或一系列 agent 的执行链路来看，这一方向模型是串行的模式运行，这是 batch 不可达的，串行的深度只有通过极致的推理速度才能够实现。

我们以一条 SWE-bench 的轨迹来看，这是一个 SWE-smith 轨迹统计上的例子，真实的运行轨迹显示它大概平均会产生 30 步左右的模型执行，生成 10K 个 token。如果在 50 token/s 的速度下完成这样一个工作，大概需要 200 秒，也就是 3 分钟多的时间。但假如将模型速度提升到 1000 tok/s，那它只需 10 秒即可完成任务。这将会是一个不同以往的体验，按照普通速度，大家或许会被等待的时间打断思考，但如果只需几秒就能完成，大家将会体验到完全实时的交互过程。

除此外我们再看其他场景，比如高频量化交易的场景通常要求 10 毫秒左右的量级给到反馈，实时语音通话可能需要几百毫秒给出反馈，而金融风控方面可能也需要给出秒级反馈，因此这些实时交互场景下的时间反馈大概在都在几秒到 10 秒间，如果无法满足这些时间门槛的要求，模型就无法在这些场景中真正落地。

所以，我们将推理速度提升到极限，一方面是希望我们可以赋能到更多的应用场景中，另一方面，也是希望能够赋能产生出更强大的模型智能。

协同算法、系统和硬件三驾马车实现速度极致提升

那么，如何将模型的 decode（解码）速度提升到极限呢？这其实由三方面决定。第一是硬件本身的性能，包括算力、带宽和互联，它决定了解码速度的上限；第二是软件系统的效率，也就是如何尽可能发挥硬件提供的性能；第三是算法，例如通过量化减少计算和访存，或者通过投机解码等方法，让一次前向计算产生更多 token。

首先来看系统效率。从第一性原理出发，模型推理的实际速度与硬件所能提供的理论上限之间仍有明显差距。其原因在于，执行过程中除了计算本身，还存在 Kernel 启动、调度、同步和通信等固定开销。随着硬件性能不断提升，这些开销愈发突出，逐渐成为低延迟推理的关键瓶颈。

对于减少这些固定开销，其实已经有很多现成技术，比如 CUDA Graph、PDL 等。CUDA Graph 主要降低 Kernel Launch 的开销，PDL 可以让前后两个 Kernel 提前建立依赖和流水，但本质上只能做一跳的 overlap。对于想要达到极致性能来说，这还远远不够。更进一步，我们需要打破 Kernel 本身形成的执行边界，把调度粒度进一步下沉，让原本被不同 Kernel 隔开的计算、访存和通信能够更充分地 overlap。

事实上，Kernel Fusion（算子融合）并非一个新鲜事物，早在 DNN 时代已有很多探索工作。围绕跨算子调度、内核生成、内存访问、动态控制流、低精度计算和软件流水等问题，我们此前开展了 Rammer、Roller、Welder、Cocktailer、Ladder 和 PipeThreader 等一系列探索，逐步形成了从图级优化到 Tile 级细粒度执行的编译能力，并在多类硬件和实际场景中进行了验证。

但这些能力并不能直接平移到大模型推理。相比传统 DNN，LLM 时代带来了三方面新的挑战：硬件性能提升使调度、通信等固定开销更加突出；MoE 路由、稀疏计算和投机解码等机制增加了运行时动态性；模型规模扩大，也让跨卡、跨机协同更为常见。因此，面向 LLM 的编译系统需要同时处理细粒度执行、动态调度和分布式协同。

面对这些挑战，TileRT 的核心思路是，不再把 Kernel 作为软件调度的基本边界，而是进一步打破这个边界，把执行拆解到更细粒度，从全局视角重新编排计算、访存和通信。

我们首先来看现有框架的调度过程。对于一个大模型，它通常被描述成计算图，再按照 OP-by-OP、Kernel-by-Kernel 的方式发射到硬件上执行。每个 Kernel 都有自己的启动、计算和同步过程，同时 Kernel 的边界也限制了不同阶段之间进一步 overlap 的空间。

TileRT 希望打破的正是这一层边界。通过把 Kernel 内部的计算进一步拆解到更细的 Tile 级任务，软件可以跨越原有 Kernel 边界重新安排执行顺序，让后续已经满足依赖的计算、访存和通信更早开始，并形成更紧密的流水。本质上，我们不是简单地把多个 Kernel 融合成一个更大的 Kernel，而是打破 Kernel 对调度空间的限制，从而获得更多原本无法实现的 overlap。

TileRT 用实战案例验证技术可行性

TileRT 首先将模型表示为数据流图，并进一步生成 Tile 级微内核；随后完成细粒度编译与调度，生成执行引擎。该引擎协同编排计算、访存与通信，并将任务映射到不同硬件单元，以充分释放设备性能。

通过这套方法，TileRT 已经在真实生产服务中完成了验证。今年 5 月，我们与智谱 GLM 团队联合推出了 GLM-5.1-HighSpeed 高速推理服务，实现了 400 tokens/s 的生产级输出速度。其中，一个很有代表性的优化是针对 GLM-5.1 的 Sparse Attention。传统 Tensor Parallel 通常让不同 GPU 执行相同的计算逻辑，而 TileRT 将其拆分为不同的异构 Worker：由一张 GPU 负责 Sparse Indexer、Top-K 选择和路由，其余七张 GPU 负责 MLA 与 Attention 等计算密集型任务，并将通信、归约和同步进一步融入 Tile 级流水线。这使不同阶段能够采用更适合自身特点的扩展方式，减少重复计算和同步等待。在不启用 MTP 时，短序列生成速度约为 300 tokens/s，长序列约 200 tokens/s；启用 MTP-3、平均接收长度为 3.2 时，短序列可以超过 600 tokens/s，长序列约 400 tokens/s。

如果我们想要更高的速度，还需要去优化每字节 token 的产出效率。而想要优化每字节的 token 产出，其实有两方面考量：一方面是希望每步产生更多的 token，那我们就可以用 MTP 或更激进的 DFlash 或者 DSpark 的投机解码方案；另一方面，可以降低每 token 所需的数据量，采用一些量化的方法将数据量降下来。

我们在 6 月与小米 MiMo 团队基于这一思路展开了模型与系统的协同设计。在量化方面，MiMo-V2.5-Pro 的 MoE Expert 占据了模型参数的主体，因此只对 Expert 进行 FP4 QAT 量化，而其他模块保持原精度。Benchmark 显示，量化后的模型能力整体接近原始 FP8 模型，同时显著降低了模型体积和访存压力。在投机解码方面，DFlash 使用块级并行预测，在一次前向中生成一组候选 token，再交由主模型统一验证，从而减少传统自回归 Draft 的串行开销。

通过这些模型与系统协同优化，MiMo-V2.5-Pro-UltraSpeed 最终在单个通用 8-GPU 节点上实现了 1T 模型超过 1000 tokens/s 的生成速度。更重要的是，这一结果并未依赖晶圆级或其他专用推理芯片，说明通过充分的模型与系统协同，通用 GPU 甚至可以超越过去由专用硬件才能实现的极致推理速度区间。这个结果说明，当系统性能逐渐逼近硬件上限后，进一步提升速度已经不只是推理引擎自身的问题，而需要模型结构、编译系统与硬件执行方式共同演进。

当然，仅仅追求极致的解码速度还不够。一个真正可用的大模型服务，还需要 OpenAI-compatible API、请求调度、Prefix Cache、工具调用以及成熟的运维能力。如果为了接入一个高速解码引擎，就要重新搭建整套服务体系，工程成本显然难以接受。因此，我们与 vLLM 社区合作，让 TileRT 专注于低延迟解码，同时复用 vLLM 已经成熟的生态。

PD 分离为这种组合提供了很好的基础。Prefill 和 Decode 解耦之后，Decode 侧就可以成为可插拔的执行引擎。在 TileRT 与 vLLM 的联合方案中，Prefill、请求调度、Chunked Prefill、Prefix Cache 和服务 API 都继续由原生 vLLM 提供，只有对单用户生成速度要求较高的请求，才会进入 TileRT 解码池。这样既保留了 vLLM 完整的生态能力，也能引入 TileRT 的超低延迟解码性能。

在实现上，TileRT 完全通过 vLLM 公开的 Connector 接口接入，不需要修改或 Fork vLLM，也不需要侵入其内部 Worker。路由层会对延迟敏感的请求进行标记，TileRT Connector 只接收这些请求，其余请求仍然沿用原生 vLLM 的处理路径。两个解码池可以共享同一套 vLLM Prefill 服务，Prefill 产生的状态则通过 NIXL 或 Mooncake 等传输引擎交接给对应的解码节点，并与后续 Prefill 过程并行执行。

因此，在同一套部署中，实时 Agent、交互式 Coding 等延迟敏感型请求可以路由到 TileRT；面向高并发和总体吞吐的常规请求，则继续由 vLLM 原生解码引擎处理。两条路径对外提供相同的 OpenAI-compatible API，服务在二者之间切换，只需要调整路由策略。这使 TileRT 与 vLLM 形成了真正共存、各取所长的异构推理服务架构。

TileRT 生态系统正在逐步壮大

目前，TileRT 已经支持多款模型和多个生态部署：

在去年年底，我们最早已经发布了 DeepSeek v3.2 的原型适配，可以达到 500 TPS 的推理速度；

今年五月份，我们和智谱推出了高速版的 GLM-5.1，实现了 400 到 600 TPS 的推理服务；

今年六月，我们又和小米 MIMO 进行了合作，实现了 1T 级别模型首次突破 1000 TPS，打破了全球推理速度记录；

之后，我们与 MIND LAB 合作，发布了首个支持高速多 Lora 推理的平台，支持 5s 内实时 UI 生产；

最后，我们与 vLLM 社区联合发布了共存式异构 PD 分离部署方案，完全零修改，支持生态兼容。

最后，是目前 Tile-AI 社区方面的最新进展。Tile-AI 社区是我们根据 Tile 抽象出来面向大模型和新型硬件架构全新设计的一套软件生态，包括大家已经熟知的 TileLang。TileScale 则是我们面向分布式架构设计的一套编程和编译框架，它面向的硬件结构包括带内的分布式 Core 结构，也包括 Die-to-Die 的互联、Chip-to-Chip 的互联，亦或者多机互联等。我们将这样多层次的分布式结构统一抽象在了 Tile 的描述中，设计了这样一套框架。TileRT 则是上述所介绍的面向极限速度的推理引擎。

除此之外，我们最近也发布了 TileFoundry 和 TileOPs，TileFoundry 是 AI 驱动的算子自动生成框架，它的输出结果就是 TileOPs——一个面向大模型的 TileLang 算子库。与此同时，我们也即将发布 TileSight 性能分析模型，主要用于 Tile 级性能建模，为 Tile 级程序性能优化和架构探索分析提供指导。