TileRT 用 AOT 编译将模型静态展开为单个 Persistent Engine Kernel，以 tile 为调度粒度、warp/block/GPU 三级特化持续重叠 load/compute/communication，消除近 BS=1 decode 下的 inter-kernel idle，弥合 8×H200 NVL 理论 ~1000 tok/s 与实际几十 tok/s 的量级差距。
近 BS=1 decode 下，attention kernel 执行时间压缩到 μs 级，但 kernel 间的 launch gap、cross-kernel barrier、global memory round-trip 和 TP synchronization 重新进入关键路径。8×H200 NVL 聚合内存带宽 ~38 TB/s，GLM-5.1 每 decode token 激活参数量 ~42 GB，纯带宽约束下理论吞吐可达 ~1000 tok/s，而实际系统仅输出几十 tok/s——差距达一个数量级。
根因不是算力不足，而是执行边界：GPU 反复执行 launch→load→compute→store→synchronize 循环，每次 kernel boundary 打断数据流、销毁局部性、强制重新同步。Profiler trace 显示 kernel 在"热身完成前就已结束"。
Persistent Engine Kernel：AOT 编译期将整个模型静态展开为单个持续驻留的 Engine Kernel。Host 仅启动一次，GPU 执行在整个 decode 生命周期内保持驻留。运行时编排逻辑大部分迁入编译期。
Tile-level scheduling：operator 分解为 tile，tile 成为调度抽象本身——compute、communication、async I/O 均为 tile-level task，在 GPU 内部持续推进。中间结果驻留寄存器、shared memory 和 L2 cache，不 spill 到 global memory。
Warp / Block / GPU 三级特化：Engine Kernel 内部，不同 warp group 承担不同职责（异步数据搬运 / tensor 计算 / 通信重叠）。原来的串行 load→barrier→compute→barrier 变为 tile 粒度持续重叠。这一特化向上扩展到 GPU 级别（Heterogeneous Workers）：在 GLM-5.1 attention 层中，GPU0 运行 Sparse Indexer Worker（Top-K 选择、sparse index 构建、路由决策），GPU1–7 运行 MLA Workers（RMSNorm、GEMM、Flash Sparse Attention、AllReduce）。
GPU-resident orchestration：调度、同步、通信从 host runtime 迁入 persistent kernel。整个 attention 层 = 单次 Engine Kernel launch，broadcast/reduce/synchronization 在 tile pipeline 内部执行，取代 NCCL 式外部编排。
核心技术壁垒：AOT 将完整 transformer 模型静态展开为单个 persistent Engine Kernel，并在其中实现 warp/block/GPU 三级异构特化。这不是在现有 operator fusion 或 graph compilation 上的增量改进——需要从零共同设计 compiler IR、tile scheduler、通信原语和执行模型，工程表面积极大。与 GPUOS 的 persistent kernel 管理和 Fleet 的 megakernel 方向相关，但 TileRT 将持续执行与异构特化结合到了产品级。
TileRT 驱动 GLM-5.1 在 MaaS 平台的原生超快推理服务——首个由 TileRT 驱动的模型厂商上线。博客未提供与基线系统的定量性能对比，但展示了在真实生产流量下（混合序列长度、KV 碎片化、MTP 动态 reshape）的部署稳定性。
传统模型将推理拆为独立 operator，每个 operator 启动独立 kernel，kernel 之间经过 host synchronization 和 global memory 往返。TileRT 将整个模型 AOT 编译为单个 Persistent Engine Kernel，内部以 tile 为调度粒度，warp group 分工执行数据搬运、张量计算、通信，三者在 tile pipeline 内持续重叠。
Heterogeneous Workers 将 warp specialization 从 SM 内扩展到 NVL 域：
GPU0 集中处理全局依赖重的 Top-K 选择和路由决策（同步/全局信息密集），GPU1–7 并行执行计算密集的 MLA 前向（天然适合 TP 分发）。通信不经 NCCL 外部编排，而是直接嵌入 tile pipeline 内部执行——整个 attention 层从 host 视角仅为一次 Engine Kernel launch。
无形式化作者证明 — 仅实证。
本文为技术博客，未提供数学模型、性能方程或形式化推导。论证完全基于定性分析和架构描述。
| 检查项 | 状态 |
|---|---|
| 理论带宽 vs 实际性能的量级差距计算 | 提供具体数字（38 TB/s → ~1000 tok/s 理论 vs 几十 tok/s 实际），推导合理 |
| Profiler trace 证据 | 引用但未公开原始 trace 数据 |
| 性能模型 / 解析方程 | 无 |
| 消融实验 | 无（未隔离各优化的单独贡献） |
| 定量基线对比 | 无（未与 vLLM/TRT-LLM/SGLang 定量比较） |
| 生产部署验证 | 声称 GLM-5/5.1 生产上线，未提供延迟/吞吐 SLA 数据 |
如果存在性能模型，应刻画：persistent kernel 消除的 idle time 占比 $f_{\text{idle}}(B)$ 作为 batch size $B$ 的函数；tile pipeline overlap efficiency 与 operator 粒度的关系；heterogeneous worker vs homogeneous TP 的通信量 $C_{\text{hetero}} / C_{\text{homo}}$ 缩减比。
博客未提供对照实验或基准测试数据，仅给出以下关键数据点和定性描述。
| 数据点 | 值 | 来源/上下文 |
|---|---|---|
| 硬件平台 | 8×H200 NVL | 聚合内存带宽 ~38 TB/s |
| 目标模型 | GLM-5.1 | 每 decode token 激活参数量 ~42 GB |
| 理论 decode 吞吐（带宽约束） | ~1000 tok/s | 无 MTP，纯带宽除以参数量 |
| 实际 decode 吞吐（传统框架） | 几十 tok/s | 未指明具体框架和配置 |
| 性能差距 | ~10× | inter-kernel overhead 归因 |
| 生产部署模型 | GLM-5, GLM-5.1 | MaaS 平台，首个 TileRT 驱动的模型厂商上线 |
| # | 论证步骤 | 支撑证据 | 推出 |
|---|---|---|---|
| 1 | AI 推理需求从质量→吞吐→速度演进，Agent/TTS/voice 场景推动近 BS=1 延迟优先工作负载 | 产品趋势观察（ChatGPT → Cursor/Claude Code → 自主系统） | 批处理摊销空间被压缩，原来隐藏在大 batch 中的固定开销进入关键路径 |
| 2 | Test-Time Scaling 使推理速度直接影响推理能力：固定延迟预算下，更快推理 = 更多 rollout / 更深推理链 | TTS 机制推理 | 速度不再只影响成本，而是决定推理深度——速度成为 scaling 维度 |
| 3 | 8×H200 NVL 理论带宽 ~38 TB/s 应支持 ~1000 tok/s，实际仅几十 tok/s，差距达 10× | 硬件规格 + GLM-5.1 参数量 42 GB 的带宽约束计算 | 性能瓶颈不在计算能力，在 kernel 间的执行边界 |
| 4 | Profiler 显示 BS≈1 下 kernel 执行仅 μs 级，"热身完成前就已结束"，launch/sync 开销占比反超 | 引用 profiler trace 观察 | 优化单个 kernel 不够，必须消除 kernel 之间的 overhead |
| 5 | TileRT 用 AOT 将模型静态展开为单个 Persistent Engine Kernel，host 仅启动一次 | 架构设计 | 消除所有 inter-kernel launch gap 和 host-device synchronization |
| 6 | Tile-level scheduling + warp specialization 使 load/compute/comm 在 tile 粒度持续重叠 | 架构设计 | 中间结果驻留寄存器/SMEM/L2，不 spill 到 global memory |
| 7 | Warp specialization 扩展到 GPU 级别：GPU0 = Sparse Indexer, GPU1–7 = MLA Workers | GLM-5.1 attention 层部署实例 | 打破对称 TP 假设，按通信代价和数据依赖分配异构角色 |
| 8 | 通信从 NCCL 外部编排迁入 tile pipeline 内部，整个 attention 层 = 单次 kernel launch | 架构设计 | compute ↔ communication 持续重叠，不再有 compute→sync→compute 串行瓶颈 |
| 9 | 生产流量下维持稳定性比峰值性能更重要（KV 碎片、MTP reshape、混合负载） | GLM-5/5.1 上线经验 | 接近硬件极限后，最难的问题从 kernel 优化转为执行稳定性和系统全栈共同设计 |
开源仓库：github.com/tile-ai/TileRT（选择性模块开源，博客未说明开源范围和具体模块）。
细节 1 — Tile pipeline 内的异步数据搬运与计算重叠：Persistent Engine Kernel 内部将 TMA 异步 copy 与 tensor core 计算在 warp group 级别交错执行。pipeline 深度（同时 in-flight 的 tile 数量）必须足够覆盖 TMA latency，否则 compute warp 仍会 stall——这直接受限于 shared memory 容量和 register pressure，是 tile size 选择的核心约束。
细节 2 — Heterogeneous Worker 间的 in-pipeline 通信：GPU0（Sparse Indexer）与 GPU1–7（MLA Workers）之间的 broadcast/reduce 不走 NCCL collective call，而是嵌入 tile pipeline 作为 tile-level 通信任务执行。这要求 AOT 编译期静态规划 GPU 间通信的 tile 对齐和数据依赖，运行时无法动态调整 GPU 角色分配或通信拓扑。
| 维度 | 具体情况 |
|---|---|
| 服务阶段 | 以 decode 为主（latency-first），prefill 细节未展开 |
| 并发模式 | 近 BS=1 低并发（博客论述核心场景） |
| 硬件亲和性 | 8×H200 NVL（NVLink 域内 persistent kernel + heterogeneous workers） |
| 生态集成 | 独立推理系统，非 vLLM/SGLang/TRT-LLM 插件 |
| 迁移路径 | 完整框架替换，非增量配置变更 |
TileRT 的软件复杂度暗示以下硬件原语如果存在将大幅简化实现：