SemiAnalysis 研报：TileRT

• 原文标题：Ultra-High Interactivity On NVIDIA GPUs? - TilerT InferenceX
• 作者：Bryan Shan / Daniel Nishball / Cam Quilic / Kimbo Chen / Alec Ibarra / Dylan Patel
• 内参日期：2026-08-11
• 来源类型：blog
• 标签：ai 硬件

同一篇 TileRT 分析的 PDF 版本，4278 字、六位作者署名完整，比网页版更适合精读和划线。与本区上一条是同一内容的两个载体，二轮精选时留一个即可。

导读

SemiAnalysis 付费研报。

核心观点

• 超低延迟推理长期被认为是 GPU 的结构性短板，是 Cerebras、Groq LPU、SambaNova 这类数据流芯片赖以立足的市场。TileRT 用纯软件的方式在 NVIDIA GPU 上把这块短板补上了一大截：在 InferenceX 的 GLM-5.1 744B 基准上，单台 8 卡 B200 decode 服务器达到 340 tok/s/user（8k/1k）与 494.2 tok/s/user（1k/1k），比 GB300 NVL72 上的传统推理引擎快 1.9× 到 3.6×。
• GPU 在超高交互性上跑不动，卡点不在带宽而在延迟。8 卡 HGX B200 聚合 HBM 带宽 64 TB/s，GLM-5 在 NVFP4、批大小 1 下每生成一个 token 只需读约 21 GB 活跃参数，带宽 roofline 理论上支持 3,047 tok/s/user——现实中差得远，差距来自成千上万个 kernel 的启动、同步、调度开销，以及每个 kernel 边界把半成品写回 HBM。
• TileRT 的答案不是优化 kernel 启动，而是取消 kernel 作为执行单位：把整张 decode 图 AoT 静态编译成一个常驻的持久化 Engine Kernel，host 只启动一次，执行在整个 decode 生命周期里驻留在 GPU 上，绝大部分运行时编排前移到编译期。CUDA graph 优化的是启动，TileRT 废掉的是边界。
• 真正的产业含义不在跑分，而在形态：TileRT 不替换 vLLM，只接管延迟敏感的 decode，于是厂商不必采购新硬件，就能从既有 GPU 集群里"切"出一层速度层。小米的 MiMo V2.5 Pro UltraSpeed 和 Z.ai 的 GLM-5.1 HighSpeed 都已在生产中这样跑。
• 因此专用芯片面对的不再是笨拙的 kernel 启动器，而是自己的执行模型跑在可自由调配的硬件上、由一个配置文件重新分配。SRAM roofline 依然更高，软件能逼近 roofline 却抬不高它——但对多数买家来说，需要的本来就不是一台速度机器，而是一层速度容量。

为什么超高交互性突然值钱了

• 溢价"快速模式"证明了用户愿意为更低延迟、更快 token 付更多钱，且可能带来更高毛利。前沿实验室（如 OpenAI）因此在评估专用推理系统，包括 Cerebras 与 NVIDIA Groq LPU 这类以超高交互性优先、而非最大批量吞吐优先的方案。
• 超低延迟最要紧的是交互式负载：实时助理、全双工语音。OpenAI GPT-Live 能一边听一边说，响应延迟被用户直接感知，原文形容那种体验像钢铁侠的 JARVIS。
• 每个推理系统都要在两个相互竞争的目标之间取舍：
• 交互性（tok/s/user）：单个用户拿到 token 的速度，是 TPOT（每输出 token 时间）的倒数，决定回答"跟手"还是"迟钝"。
  • 吞吐（tok/s/GPU）：系统对全部用户产出的 token 总量，很大程度上决定每 token 成本。
• 攒批（batching）提高聚合吞吐但让每个用户等更久；小批相反，提升单用户速度却让每张 GPU 完成的有效工作变少。原文用了一个很好的比喻：公交车把成本摊给很多乘客但每个人都要陪着停站，赛车只载一两个人却跑得快、单位成本高。
• 这条曲线的陡峭程度是量级级别的：在文中给出的配置里，交互性从约 25 提到 260 tok/s/user，单卡吞吐从约 5,900 掉到 200 tok/s/GPU——单用户速度提升 10 倍，聚合吞吐损失约 30 倍。没有一个操作点适合所有人。

GPU 的瓶颈不在带宽，在延迟

• 带宽账算下来是宽裕的。8 卡 HGX B200 聚合 HBM 带宽 64 TB/s；GLM-5 在 NVFP4、批大小 1 下每 token 只需约 21 GB 的活跃参数流量。按带宽 roofline 推，不用投机解码也该跑到 3,047 tok/s/user。实际远远够不着。
• 换一台机器结论一样：单台 HGX H200 聚合 38.4 TB/s，MXFP8 下每 token 活跃参数带宽 42 GB，理论上应能到 1,000 tok/s/user——现实世界显然不是这样。
• 差距来自延迟而非带宽。传统 GPU 编程模型要启动并同步成千上万个独立 kernel，每个 kernel 的 setup 与 teardown 开销在常规服务速度下不显眼，但当 TPOT 逼近亚毫秒级时就成了主导项，即便上了 CUDA graph 也一样。更糟的是每个 kernel 都要把半成品写回 HBM；小批下 kernel 本身不够大，摊不掉启动延迟、同步与调度开销。
• 而且这个方向没有硬件红利可等：GPU 显存带宽每代大约提升 2–3 倍，内存延迟则完全没有改善，同时 HBM 价格还在持续上涨。

InferenceX 实测：TileRT 把 B200 推到另一个量级

• InferenceX 是 SemiAnalysis 开源、厂商中立、持续更新的推理基准与研究平台，沿着延迟-吞吐帕累托前沿测量主流模型、推理框架与硬件，追踪真实推理性能与经济性随时间的改善。基准已被从 Google Cloud、Microsoft Azure、Oracle 到 Meta 的几乎所有主要算力买家复现或支持，也得到 vLLM、LMCache、SGLang、PyTorch、Huggingface 等社区与 OpenAI、MiniMax、ZAI、Qwen、Moonshot Kimi 等实验室的支持。

• 8k/1k 输入输出场景：TileRT 在 8 卡 B200 节点上达到 340 tok/s/user。此前数据集中最快是 GB300 NVL72 配 NVFP4 + MTP 的 181.4 tok/s/user，TileRT 快 1.9×；同精度下最快的 FP8 结果是 B300 配 MTP 的 113.6 tok/s/user，TileRT 快 3.0×。

• 值得注意的是这是批大小 1 的比较——GB300 NVL72 为搭起复杂铜背板付出的那些代价，在提升交互性这件事上完全用不上。

• 1k/1k 输入输出场景：TileRT FP8 达到 494.2 tok/s/user，是最佳传统结果（FP4，256.3 tok/s/user）的 1.9×，是最佳传统 FP8 结果（136.3 tok/s/user）的 3.6×。TileRT 目前还不支持 FP4，却已经打过了非 TileRT 的 FP4 实现。而且它来自 8 卡 B200 节点，不是 GB200 / GB300 NVL72 的 72 卡 NVLink scale-up 域。这个比较只针对单用户交互性，不涉及聚合吞吐或成本。

• 端到端延迟：TileRT FP8 在 1k/1k 上比此前最好的 GLM-5.1 结果快 4.5×，8k/1k 上快 3.0×。它的首 token 时间（TTFT）不错但不出彩，决定性优势来自 decode 尾部——3.01 秒，对比最佳 NVFP4 + MTP 竞品的 6.54 秒和 MI355X 的 18.18 秒。

• 代价同样明确：TileRT 的交互性优势换来的是更低的聚合吞吐。传统引擎能随并发上升把权重加载和固定 kernel 成本摊给更多用户——8k/1k 下 GB300 FP4 + MTP 在并发 12 时给出约 240 tok/s/GPU 总吞吐、同时维持 154 tok/s/user；TileRT 是 160.4 tok/s/GPU 配 340 tok/s/user。

• 截至发文，TileRT 每个 decode 节点只服务一个在途请求，这是一个刻意特化的操作点而非通用吞吐配置。原文的说法很到位：TileRT 不只是赛车，更像一艘只坐一个人的私人火箭；让它多载几位乘客也许可行，但目标很激进。

TileRT 到底是什么：取消 kernel 作为执行单位

• 传统服务引擎以成千上万个彼此独立、依次启动的 GPU kernel 运行，GPU 因此花掉大量时间在等待；每个 kernel 还把半成品写回 HBM。低到中等交互性下这些成本不显眼，超高交互性（即低延迟推理）下它们就是主导项。

• TileRT 的做法是让 GPU 持续执行一条持久化流水线：把整个模型 AoT 静态编译成一个持久化 Engine Kernel——host 只启动一次，执行在整个 decode 生命周期驻留在 GPU 上，绝大多数运行时编排被前移到编译期。

• 这和 CUDA graph 不是一回事。CUDA graph 捕获 kernel 启动与 memcpy 构成的有向无环图，然后用一次 cudaGraphLaunch 重放，但 kernel 本身仍是独立 kernel，边界仍带设备侧成本，片上状态在每个边界被抹掉。原文一句话点破：CUDA graph 优化的是 kernel 的启动，TileRT 废除的是 kernel 这个执行单位。

• 第二层是 tile 级任务分解加 warp 与 block 专业化：运行时把计算、I/O、通信高度重叠地动态重排。Engine Kernel 内部不同 warp group 承担不同工种——异步数据搬运、张量计算、通信重叠。原来串行的"load → barrier → compute → barrier"变成在 tile 粒度上重叠，中间结果通过寄存器、共享内存和 L2 向前流动，而不是反复外溢到全局内存。每个 CTA（协作线程阵列）因此更像一座异构的小工厂，而不是一个均质的 SIMT 工人。

• 第三层是把专业化从 warp 推广到整张 GPU。多数张量并行框架假定所有 rank 同步执行相同逻辑，但稀疏路由、Top-K 选择、动态索引、长上下文注意力和 MTP 并不适合同质 scale-out：它们不重计算却依赖全局信息，强迫每个 rank 都跑一遍只会带来冗余工作和同步放大。既然 warp 能专业化，GPU 也能——在 GLM-5.1 的注意力层里，GPU 0 成为 Sparse Indexer worker，负责 Top-K 选择、稀疏索引构建与路由，GPU 1 到 7 作为 MLA worker 执行 RMSNorm、GEMM、flash sparse attention 和 AllReduce。

• 最后，通信不再被当作外部阶段：广播、归约与同步直接在 tile 级流内执行。有了 TileRT，整个注意力层在 host 侧只对应一次 kernel 启动，执行形态从"compute → sync → compute"转向持续重叠的"compute ↔︎ communication ↔︎ compute"流水线。

• 身世上，TileRT 出自与广受欢迎的 TileLang DSL 同一个社区维护组织；作者也感谢了 vLLM 社区在 V1 connector 上的设计。

PD 分离：vLLM 留守 prefill，TileRT 只接管 decode

• LLM 推理有两个性质迥异的阶段：prefill 并行处理输入提示、以计算密集为主，关键指标是聚合吞吐；decode 顺序生成 token 并反复访问不断增长的 KV cache，是内存密集型且对每 token 延迟极其敏感。
• TileRT 不替换 vLLM。vLLM 继续做高吞吐的 prefill 引擎和外围服务层，包括调度器、chunked prefill、前缀缓存、兼容 OpenAI 的 API 与运维工具；只有延迟关键的 decode 流量交给 TileRT。原文的比喻延续得很干净：TileRT 是单人火箭，vLLM 仍是飞机、汽车、公交和火车。
• prefill 与 decode 可以拆到不同节点，于是一个共享的 vLLM prefill 池能同时喂两个完全不同的 decode 池：
• Pool A（TileRT 的超高交互性 decode）：延迟关键请求经 TileRT PD Router，由它指示 vLLM 生成首 token，并在 kv_transfer_params 里标记目标 TileRT 节点。
  • Pool B（vLLM 的低到中等交互性 decode）：一般流量继续走 vLLM 原生的分离代理，进常规 vLLM decode 池。
• 实现走 vLLM 的 MultiConnector API，把 TileRTConnector 与原生 connector 组合起来：TileRTConnector 只认领被标记为高交互性流量类的请求，对其他一切是 no-op，因此两类流量可以共用同一个 prefill 服务器。prefill 与 decode 之间的 KV cache 由 Mooncake Transfer Engine 和 NIXL Transfer Engine 搬运。
• 在 TileRT v0.1.5 中，每个 decode 节点同一时刻只服务一个在途请求；router 负责门控派发，节点被占用时施加背压。

对比 Cerebras / Groq / SambaNova：软件能逼近 roofline，但抬不高它

• 专用推理厂商多年前就识别出了同一个执行瓶颈，只是把更多解法编码进了硬件。Groq 用确定性的、编译器编排的执行加上大容量片上 SRAM 层级；Cerebras 把计算在晶圆级处理器上做空间映射，CS-3 提供约 900,000 个核、44 GB 片上 SRAM 和 21 PB/s 内存带宽；SambaNova 把模型图映射到可重构数据流单元，背后是 SRAM、HBM 与 DDR 的分层内存系统。

• 硅片不同，但系统层面的想法是同一个：延迟敏感的推理受益于减少运行时调度、算子边界、同步与不必要的外部内存搬运。大批量下这些成本容易摊掉；批大小 1 下它们在每个 token 的延迟里占比大得多。

• TileRT 是把若干数据流思想的软件对应物搬进 GPU：AoT 调度、持久化执行、专业化 worker、更紧的通信与计算重叠。相似是架构层面的而非字面的——它仍然跑在一台带动态 warp 调度器、SIMT 模型和 HBM 的机器上，靠一份模型专属的编译调度。

• 但 TileRT 终究只是软件：数据流被强加在一台从未为它设计的机器上。GPU 带着动态 warp 调度器、SIMT 模型和 HBM 层级，TileRT 靠巨量编译器投入——静态展开的持久 kernel、手工雕琢的 warp 专业化、针对钉死驱动栈的逐模型编译——去说服这套机制模仿一条空间流水线。原生数据流硅片不必和自己的基底较劲。这就是为什么 Cerebras 服务一个稠密 70B 的速度是任何 8 卡节点都够不到的，无论调度多聪明：软件可以逼近 HBM roofline，但抬不高它。

• 而市场给出的早期答案是：纯粹性可以谈判。TileRT 的 decode 引擎已经跑在小米 MiMo V2.5 Pro UltraSpeed 和 Z.ai GLM-5.1 HighSpeed 背后，部署方式才是关键信号——两家都没有采购新的数据流芯片，而是从自己已经在跑的加速器集群里切出一层速度容量，vLLM 保留 prefill、调度与 API，TileRT 在同一个端点背后接管 decode。跑在你已经拥有的硬件上的"够好"，往往胜过要你另外掏钱买的"架构纯粹"。

• 更深的结构性问题是 prefill-decode 配比的可替换性与灵活性。GPU 池是一份流动的资源：prefill 出色，中高批 decode 出色，如今在超交互 decode 上也算有了可信实力，而容量在这些角色之间的移动只是一个软件调度决策，可以按小时跟随需求。ASIC 机队正相反：速度层容量与其他容量的比例，在采购单签字那天就被硬件固定；改变实体机队的比例要花几个月重新上架和布线。

• 如果负载结构稳定且已知，这没问题。可惜"需要普通对话延迟的用户"与"愿意为极端交互性 SLO 付费的用户（越来越多是 agent）"之间的分野，估算时变量太多。用 GPU 猜错了在软件里再平衡；用专用硅猜错了，要么把资本搁浅在闲置的速度机器上，要么拒掉你当初正是为之买单的高价流量。何况需求会随时间漂移，猜对也只在有限窗口内有效。

• 回到共享 prefill 池：供应商不必为所有流量支付 TileRT 溢价，一般请求留在吞吐优化的 vLLM 或 SGLang decode 池，只有延迟关键请求被路由到 TileRT decode 池。

• 这并不杀死速度市场的顶端。SRAM roofline 依然更好，某些模型尺寸依然更适合它，某些负载永远愿意不计代价换最高 token 速率。但 TileRT 重新定义了多数买家真正需要的东西：不是一台速度机器，而是一层速度容量，从他们本来就要买的机队里动态供给。Cerebras、Groq 和 SambaNova 面对的不再是笨拙的 kernel 启动器，而是自己的执行模型跑在可自由调配的硬件上、由一个配置文件重新分配。原文的收尾比喻很妙：TileRT 也许是单人火箭，但它让供应商可以给自己的公交车绑上固体助推器，而不必去设计一整套新的运载工具。

成本账：同价位下 1.9 倍交互性

• 成本只有在系统满足延迟目标之后才有意义。在 339 tok/s/user 这个门槛上，作者测得的 GLM-5.1 GPU 结果中，可行集里只剩下 TileRT——最快的传统点是 176 tok/s/user，最快的传统分离式 FP8 点（GB300 配 SGLang 与 MTP）只有 108.0 tok/s/user。
• 8k/1k 下 TileRT 达到 340 tok/s/user，同时每张 B200 交付 35.4 输出 tok/s，折合每百万输出 token 13.56 美元。
• 交互性最高的 FP4 分离式 decode 配置是 GB200 FP4 + MTP、并发 5，约 286 tok/s/GPU 总吞吐、维持约 176 tok/s/user；按 1.86 美元每 GB200 小时算，是每百万输出 token 13.4 美元。也就是说 TileRT 每 token 只贵 1%，却给出 1.9 倍交互性。作者顺手做了个对照：这比 Claude Code 的 fast mode 划算得多——后者最多 2.5 倍交互性，但每 token 价格翻倍。
• 同精度比较更悬殊：最快的传统 FP8 结果是 GB300 FP8 + MTP 的 108 tok/s/user，其端点成本为每百万输出 token 35 美元；TileRT 以每百万 13.56 美元达到 340 tok/s/user，即每输出 token 便宜 61%，同时交互性是 3.1 倍。

TileRT 为什么进展慢，以及下一步

• TileRT 继承了 ASIC 厂商最大的弱点。静态 AoT 编译意味着模型目录极小（当前 GLM-5/5.1 与 DeepSeek-V3.2）、依赖被硬钉死、每种新架构都要投入真实工程量。MiMo-V2.5-Pro-UltraSpeed 是协同设计合作的产物，尚未开源；而 GLM-5.1 已经落后一代，在 InferenceX 主线上被弃用。

• 没有完全通用的路径：持久化 Engine Kernel 意味着模型被提前静态展开成一个常驻程序，于是 tile 形状、流水线深度、缓冲在寄存器 / 共享内存 / L2 之间的驻留、warp group 在加载与计算与通信之间的划分、集合通信在哪里融进 tile 流、哪几张 GPU 承担像 GLM-5.1 专用稀疏索引 rank 这样的特殊角色，全都得预先定死。换掉注意力机制或路由方案，大部分调度就作废了。数据流芯片同样面对这个问题——好编译器出了名地难做。

• 减负工作在进行中，尤其是软件开发可以被 AI 加速。TileOPs 就是为降低这个负担而设计：每个算子用机器可读的 manifest 声明签名、工作负载与 roofline 模型，manifest 驱动代码生成、测试和对硬件上界（而不只是对更早的实现）做基准。

• 但有两个卡点：AI 编码 agent 能在已知模板内加速调参，真正新颖的变换仍需专家判断；而单体式持久 kernel 也削弱了传统逐 kernel profiler 时间线的作用，让自动化反馈回路更难建立。

• 下一步一：把 TileRT 的基准从 InferenceX 的单轮 8k/1k 推向新的 agentic 编码基准 AgentX。它重放真实的 Claude Code 与 Codex 轨迹，带长上下文、多轮请求、真实的子 agent 活动与动态工具调用延迟；中位输入长度 140k tokens，理论中位缓存命中率上界达 99.2%。这将检验整个 TileRT 与 vLLM 系统，而不只是 decode 速度，包括增量 KV 传输、前缀缓存复用、缓存保留与卸载、路由与调度。关键问题是：TileRT 能否在轮次之间只传输新增的上下文，同时保住它的超高交互性优势。

• 下一步二：走出批大小 1，在批大小 2、4、8 上做基准，目标是描出它的吞吐-交互性帕累托前沿，找出持久化 Engine Kernel 的延迟优势开始变平的那个点。

概念网络

关键概念

交互性（tok/s/user）

context：全文的第一性指标。原文定义它"measures how quickly a single user receives tokens, the inverse of time per output token (TPOT)"，并说它决定一次回答"feels snappy or sluggish"。TileRT 的全部跑分（340、494.2 tok/s/user）都是这个维度上的数字。

费曼一下：就是"你一个人看到字往外蹦的速度"。它和"这台机器一共能吐多少字"是两回事——后者是老板关心的产能，前者是你坐在屏幕前的体感。

吞吐（tok/s/GPU）

context：与交互性对立的另一极，"measures how many tokens the system produces in total across all users"，很大程度上决定每 token 成本。TileRT 在 8k/1k 下是 160.4 tok/s/GPU，低于 GB300 并发 12 时的约 240。

费曼一下：一张 GPU 一秒总共产出多少字。它决定的是单价。交互性是给用户的体验，吞吐是给财务的账。

吞吐-交互性帕累托前沿

context：原文用公交车与赛车的比喻描述这条曲线，并给出一个量级化的实例：交互性从约 25 提到 260 tok/s/user，单卡吞吐从约 5,900 掉到 200，"roughly a 30× reduction in aggregate throughput for a 10× increase in per-user speed"，且明言"There is no one-size-fits-all operating point"。

费曼一下：一条你只能沿着走、不能跳过去的曲线。想让一个人更快，就得放弃一大票人的产能，而且不是等比例交换——买 10 倍速度要付 30 倍产能。所有推理系统的设计都是在这条线上选一个点站着。

批大小 1（batch size 1）

context：TileRT 当前唯一支持的操作点，也是它跑分与代价的共同来源。原文写"TileRT as of publication also serves only one in-flight request per decode node, making this a deliberately specialized operating point rather than a general throughput configuration"，并称它"not just a race car, but more like a private rocket ship with room for just one passenger"。

费曼一下：一次只伺候一个人。所有能被"摊薄"的固定成本此时都摊不掉了，于是那些平时看不见的开销全部浮到水面——这既是延迟问题最尖锐的地方，也是最能显出功夫的地方。

HBM 带宽 roofline

context：全文用来区分"理论上界"与"现实性能"的标尺。8 卡 B200 的 64 TB/s 对上 GLM-5 NVFP4 每 token 约 21 GB 活跃参数，推出 3,047 tok/s/user 的上界；单台 H200 的 38.4 TB/s 对上 MXFP8 每 token 42 GB，推出约 1,000 tok/s/user。原文强调"In practice, GPUs come nowhere close to this limit"。

费曼一下：按"每生成一个字要把多少数据从显存读一遍"算出来的速度天花板。它告诉你这台机器理论上能有多快；如果实际速度离它很远，说明问题不在管道粗细，而在别处。

kernel 启动与同步开销

context：GPU 在超高交互性下跑不动的真正原因。原文写传统引擎"launches and synchronizes many individual kernels, whose setup and teardown overhead becomes significant at ultra-high levels of interactivity"，且"even with CUDA graphs, they dominate as token latency approaches the sub-millisecond TPOT range"；同时每个 kernel 把半成品写回 HBM。

费曼一下：GPU 像一个必须被反复叫醒、每次只干一小件事的工人，每件事开头结尾都有固定手续。活儿大的时候手续可以忽略，活儿小到亚毫秒级时，手续本身就是全部时间。

持久化 Engine Kernel

context：TileRT 的核心机制。原文描述为"statically compiling the whole model ahead of time into a persistent Engine Kernel: the host launches once, execution stays resident on the GPU for the whole decode lifecycle, and most runtime orchestration moves into compile time"。

费曼一下：不再让 GPU 一件件接活儿，而是一次性把整条产线烧进去让它一直转。开工手续只办一次，之后所有工序在同一个"车间"里连续流动。

AoT 静态编译（ahead-of-time）

context：持久化 Engine Kernel 得以成立的前提，也是 TileRT 全部代价的来源。原文指出它带来"a tiny model catalog (currently GLM-5/5.1 and DeepSeek-V3.2), hard-pinned dependencies, and real engineering effort per new architecture"，并列举必须提前定死的决策：tile 形状、流水线深度、缓冲驻留、warp group 划分、集合通信融合位置、GPU 专用角色。

费曼一下：把所有临场判断提前到出厂前做完。跑得快是因为现场不用再想，但代价是换个模型就得重新想一遍——这正是专用芯片一直被诟病的那种僵硬。

CUDA graph 与"取消 kernel 作为执行单位"的分野

context：原文用来界定 TileRT 独特性的关键对照。CUDA graph"captures the DAGs of kernel launches and memcpys once, then replays it with a single cudaGraphLaunch"，但 kernel 仍是独立 kernel，边界仍有设备侧成本、片上状态在每个边界被抹掉。作者的判词是：CUDA graph 优化 kernel 的启动，TileRT 废除 kernel 这个执行单位。

费曼一下：一个是把一叠工单打包一次递进去，另一个是干脆不再有"工单"这个东西。前者省了递单子的时间，后者连每次交接时清空工作台的动作都不存在了。

tile 级任务调度与 warp 专业化

context：Engine Kernel 内部的组织方式。原文写不同 warp group 分别承担异步数据搬运、张量计算与通信重叠，原本串行的"load → barrier → compute → barrier"改为在 tile 粒度重叠，中间结果流经寄存器、共享内存和 L2 而非反复外溢到全局内存；每个 CTA"becomes a small heterogeneous factory rather than a uniform SIMT worker"。

费曼一下：把一群本来在做同样动作的工人拆成搬运工、加工工和传话工，让他们同时干、把半成品从手里直接递过去，而不是每人做完都放回仓库再取。

GPU 级角色专业化

context：把 warp 专业化的思路推到整卡粒度。原文指出稀疏路由、Top-K 选择、动态索引、长上下文注意力与 MTP"are not compute-heavy but depend on global information"，让每个 rank 都跑一遍只会造成冗余与同步放大；于是 GLM-5.1 注意力层中 GPU 0 成为 Sparse Indexer worker，GPU 1 到 7 作为 MLA worker。

费曼一下：既然一张卡内部可以分工，八张卡之间当然也可以。让一张卡专门做那件"只需要一份、但所有人都要等它"的活儿，剩下七张专心算，比八张卡各算一遍同样的东西再互相等要快。

PD 分离（prefill-decode disaggregation）

context：TileRT 与既有生态共存的接口。prefill"is primarily compute-intensive"、decode"memory-intensive and highly sensitive to per-token latency"，因此可以拆到不同节点；一个共享的 vLLM prefill 池可以同时喂 TileRT decode 池与常规 vLLM decode 池，通过 MultiConnector API 与 kv_transfer_params 标记完成分流。

费曼一下：把"读题"和"答题"拆成两班人马。读题要的是马力，答题要的是反应速度，那就让擅长各自那件事的机器去做，中间只把笔记本传过去。

数据流芯片（dataflow silicon）

context：TileRT 的参照系与竞争对象。Groq 用确定性、编译器编排的执行加大容量片上 SRAM；Cerebras CS-3 提供约 900,000 核、44 GB 片上 SRAM 与 21 PB/s 带宽；SambaNova 用可重构数据流单元。作者的判断是三者"share the same idea"，但"encoded more of the solution in hardware"。

费曼一下：把模型的形状直接刻进硬件布局，让数据像在流水线上一样流过去，权重根本不用来回搬。TileRT 做的是同一件事的软件版——像不像是架构上的像，底子还是那台通用 GPU。

算力池的可替换性（fungibility）

context：作者认为比跑分更重要的结构性论点。GPU 池是"one liquid resource"，速度层容量与其他容量的比例是软件调度决策、可按小时跟随需求；ASIC 机队则"the ratio is fixed in hardware the day the purchase order is signed"，改变要花几个月重新上架布线。

费曼一下：同一批机器今天能当快车用、明天能当货车用，猜错了改个配置就行；而专用机队一旦买定，猜错就只能眼看着机器闲置，或者把最赚钱的客人往外推。

速度层（speed tier）

context：全文最锋利的重构。原文写 TileRT"reframes what most buyers need: not a speed machine, but a speed tier, provisioned dynamically out of the fleet they were going to own anyway"，并以小米与 Z.ai 的部署为证——两家都没买新芯片，而是从既有集群里切出速度容量。

费曼一下：客户要的从来不是"一台最快的机器"，而是"我这里能提供一档更快的服务"。前者是采购问题，后者是配置问题——一旦能用配置解决，采购这条路的说服力就塌了一半。

软件逼近 roofline 与硬件抬高 roofline

context：作者给这场竞争划定的边界。TileRT 用"enormous compiler effort convincing that machinery to impersonate a spatial pipeline"，而"Native dataflow silicon never fights its own substrate"；结论是 Cerebras 服务稠密 70B 的速度"no eight-GPU node can reach regardless of scheduling: software can approach the HBM roofline, but it cannot raise it"。

费曼一下：再好的调度也只能让你把已有的管子用满，不能把管子变粗。所以速度市场的最顶端不会消失，消失的是它下面那一大片"其实也不需要那么极致"的中间地带。

概念网络

graph TD
C1["超高交互性市场"]
C2["吞吐与交互性取舍曲线"]
C3["kernel 启动与同步开销"]
C4["HBM 带宽 roofline"]
C5["持久化 Engine Kernel"]
C6["AoT 静态编译"]
C7["tile 级调度与 warp 专业化"]
C8["GPU 级角色专业化"]
C9["PD 分离架构"]
C10["批大小 1"]
C11["数据流专用芯片"]
C12["GPU 池的可替换性"]
C13["速度层而非速度机器"]
C14["模型目录狭窄"]
C15["同价位 1.9 倍交互性"]
C1 -->|催生| C11
C1 -->|要求| C10
C10 -->|放大| C3
C3 -->|阻挡| C4
C4 -->|设上界| C5
C5 -->|取消| C3
C6 -->|支撑| C5
C7 -->|支撑| C5
C8 -->|支撑| C5
C5 -->|组合| C9
C9 -->|支撑| C13
C12 -->|支撑| C13
C13 ---|对立| C11
C6 -->|代价| C14
C5 -->|带来| C15
C15 -->|支撑| C13
C2 ---|张力| C15
C10 ---|张力| C2

• 全文的起点是一个需求侧事实：超高交互性开始值钱了。它同时长出两条枝——一条通向数据流专用芯片（Cerebras、Groq、SambaNova），一条把推理系统逼到批大小 1 这个极端操作点。这两条枝在文章末尾会正面相撞。
• 中段是一条因果链：批大小 1 放大了 kernel 启动与同步开销，这些开销挡住了系统去逼近 HBM 带宽 roofline。注意这里的层级关系——roofline 是上界，开销是障碍，两者不是同一类东西。作者反复强调"the gap comes from latency rather than bandwidth"，正是为了把这两者分开：带宽是硬件给的，延迟是编程模型欠的。
• 持久化 Engine Kernel 处在整张网络的枢纽位置，它与 kernel 开销之间是"取消"关系而非"优化"关系——这正是 TileRT 与 CUDA graph 的分野。它由三条并行的支撑构成：AoT 静态编译（把编排前移到编译期）、tile 级调度与 warp 专业化（卡内分工与重叠）、GPU 级角色专业化（卡间分工）。三者层级不同但方向一致，都是"提前定死、现场只管流"。
• AoT 静态编译同时是支撑也是代价，这是全文最有张力的一处：同一个机制既让持久化 Engine Kernel 成为可能，又直接产出模型目录狭窄、依赖硬钉、每种新架构都要重来的后果。TileRT 因此"继承了 ASIC 厂商最大的弱点"——它模仿数据流芯片的执行模型，连带也模仿了它的僵硬。
• 吞吐与交互性取舍曲线和同价位 1.9 倍交互性之间是张力关系而非矛盾：TileRT 并没有跳出那条曲线，它的聚合吞吐（160.4 tok/s/GPU）确实低于传统点（约 240）。它做到的是在曲线的极右端把可达点整体外推，于是在"必须满足 339 tok/s/user"这个约束下，可行集里只剩它一个，成本比较才第一次对它有利。
• 最后一层是产业层面的重组：持久化 Engine Kernel 通过 PD 分离与 vLLM 组合，加上 GPU 池天然的可替换性，共同支撑起"速度层而非速度机器"这个结论；而这个结论与数据流专用芯片构成直接对立——不是性能上的对立（SRAM roofline 仍更高），而是采购形态上的对立。文章真正的论点不是"GPU 追上了 ASIC"，而是"当速度可以由配置文件供给时，为速度单独买一批硬件这件事本身失去了大部分理由"。

费曼 x3

一个行业里最贵的东西，往往是被公认"结构上做不到"的那件事。超低延迟推理长期就是这样一件事：GPU 擅长吞吐、不擅长反应速度，这几乎是共识，也正是晶圆级和数据流芯片得以存在的理由。共识之所以危险，在于它常常把"当前实现的局限"错认成"硬件的局限"。

把账算一遍就知道差在哪儿。八卡 B200 的聚合显存带宽是 64 TB/s，批大小 1 下生成一个 token 只需要读约 21 GB 的活跃参数——按这个比例，理论上该跑到三千多 tok/s/user。现实里连零头都够不着。差距不在带宽，而在延迟：传统引擎要启动并同步成千上万个独立 kernel，每个都有开工与收工的手续，每个都把半成品写回显存。这些成本在常规速度下藏得很好，一旦每 token 的时间逼近亚毫秒，它们就是全部。更值得注意的是，显存带宽每代涨两三倍，内存延迟一点没改善——这条路上没有硬件红利可等。

TileRT 的做法之所以有意思，不是因为它把 kernel 启动优化得更好，而是因为它拒绝在那个层面竞争。CUDA graph 优化的是 kernel 的启动，TileRT 废除的是 kernel 这个执行单位：整张 decode 图被提前静态编译成一个常驻的引擎内核，host 只启动一次，执行在整个解码生命周期里驻留在卡上，运行时的编排被前移到编译期。这是一种典型的换维度解法——当你在既定框架里怎么优化都撞墙时，往往该问的是这个框架本身是不是可选项。

代价来得同样诚实。提前定死意味着模型目录只有寥寥几个、依赖被硬钉死、换个注意力机制大半调度就作废。TileRT 因此继承了专用芯片最大的弱点：它模仿了数据流的执行模型，连带也模仿了它的僵硬。软件可以逼近显存带宽的天花板，但抬不高它。

真正的转折不在跑分，而在部署形态。小米和 Z.ai 都没有为速度采购新硬件，而是从已有的加速器集群里切出一层速度容量，让 vLLM 保留预填充与调度，TileRT 在同一个端点背后接管解码。买家要的从来不是一台速度机器，而是一档速度服务。当这件事可以由一个配置文件供给时，为它单独买一批硅片的理由就塌掉了大半——不是因为专用硬件不够快，而是因为它猜错了就改不了。