TileRT 的核心主张——将整个模型 AOT 编译为单个 Persistent Engine Kernel 并以 tile 为调度粒度消除 inter-kernel idle——处于 2026 年"持续执行 GPU 编程"浪潮的交汇点。四篇相关工作分别从不同角度切入这一问题空间：
这四篇工作构成一个谱系：从最细粒度的 intra-kernel NUMA 调度（2511.02132）→ 单 GPU persistent kernel（GPUOS）→ chiplet-aware megakernel（Fleet）→ 全模型 AOT persistent engine（TileRT），解决问题的粒度逐级上升。
GPUOS 的设计哲学是"透明加速"——保留 PyTorch eager semantics，通过 TorchDispatch hook 自动路由微操作到 persistent kernel，大操作仍走传统 launch [2604.17861]。TileRT 采取对立策略：AOT 将完整 transformer 编译为单个 Engine Kernel，运行时不存在 host-device 交互。
| 维度 | GPUOS | TileRT |
|---|---|---|
| 编译策略 | JIT (NVRTC per-operator) | AOT (full model static) |
| 覆盖范围 | 微操作（element-wise, small reduction） | 全模型（attention + FFN + communication） |
| Host 参与度 | Host 持续写 ring buffer descriptor | Host 仅 launch once，全程 GPU-resident |
| 动态性 | 完全支持动态 shape/operator | 静态 shape（需 recompile for different configs） |
| 通信处理 | 未涉及 multi-GPU | NVLink 通信嵌入 tile pipeline |
| Speedup 来源 | 消除 launch overhead 的算术效果 | 消除 launch + 跨 operator 数据驻留 + 通信重叠 |
GPUOS 在 H100 上 element-wise 达 15.3× [2604.17861]，但其加速仅在"launch overhead 占比 > compute 本身"的操作上成立——大 GEMM 仍走传统路径。TileRT 的野心更大：将大 GEMM、attention、communication 全部纳入 persistent pipeline，消除的不只是 launch gap，还包括 cross-kernel global memory round-trip 和跨 operator 的数据局部性损失 [tilert-speed-scaling-law]。
代价是 TileRT 放弃了动态性——GPUOS 的 dual-slot aliasing 支持零停机热更新 [2604.17861]，而 TileRT 的模型结构变更需要 recompile。这是两条路线的根本性分叉。
TileRT 和 Fleet 在最高层次上做了相同的事——persistent kernel + 异构 worker assignment——但解决的硬件约束完全不同：
Fleet 的 Heterogeneous Workers 是 XCD 粒度（同 GPU 内 8 个 XCD 分工），TileRT 的 Heterogeneous Workers 是 GPU 粒度（8 块 GPU 分工）。两者的异构特化思路相通但作用域差异一个数量级。
Fleet 有完整的性能模型——Eq.(1) L2 hit = (R-1)/R 在 bs=32 精准命中 51% [2604.15379]，TileRT 博客未提供任何解析性能模型，这是科学严谨性的显著差距。
DeepSeek-V4 的 hybrid CSA+HCA attention 引入了高度异构的计算图：CSA 层需要先 4× 压缩、再 Lightning Indexer sparse top-k、再 MQA；HCA 层需要 128× 压缩后 dense attention；两种层 interleaved 排列 [deepseek-v4]。这种结构与 TileRT 的 AOT 静态编译之间存在结构性张力：
TileRT 声称服务 GLM-5.1（MoE 模型） [tilert-speed-scaling-law]，说明其 AOT 编译已具备处理 MoE 的能力，但博客未说明如何处理 routing 动态性——这是最关键的 delta 之一。
2511.02132 的 Swizzled Head-first Mapping 是单 kernel 内的调度优化，解决 workgroup-to-XCD 亲和性 [2511.02132]。TileRT 消除了 kernel 边界本身——当整个 attention 层成为 Engine Kernel 内的一段 tile pipeline 时，workgroup 调度不再由硬件 dispatcher 决定，而由 AOT 编译器静态规划。两者在逻辑上互补：TileRT 的 Engine Kernel 内部仍然需要 tile-to-SM 的合理映射，此时 NUMA-aware 原则依然适用。
TileRT 博客声称弥合"理论 ~1000 tok/s 与实际几十 tok/s"的量级差距 [tilert-speed-scaling-law]，但未提供：
对比 GPUOS 提供了完整的 speedup 矩阵（H100: element-wise 15.3×, attention 8.7×, mixed 23.1×）[2604.17861] 和 Fleet 提供了 per-batch-size TPOT 对比 [2604.15379]，TileRT 的证据标准远低于同领域论文。
TileRT 将"完整模型 AOT 编译为单个 kernel"——但现代 LLM 的动态性不断增加：
GPUOS 正面承认了这一 trade-off：其 hybrid execution 让大 GEMM 走传统路径 [2604.17861]。TileRT 声称"全部纳入"但未说明如何处理动态性的工程复杂度。
TileRT 将 GPU0 特化为 Sparse Indexer Worker（Top-K + routing），GPU1-7 为 MLA Workers [tilert-speed-scaling-law]。这一设计隐含假设：
如果模型规模或 attention 结构变化（如 V4 的 CSA/HCA interleaved 层在不同层有不同计算量），固定的 1:7 分配可能成为瓶颈。Fleet 面临类似问题但通过软件 scheduler 动态调整 [2604.15379]，TileRT 的 AOT 方式是否允许运行时重平衡未知。
TileRT 的叙事线——"推理速度是新的 scaling 维度"——建立在"固定延迟预算下更快推理 = 更多 rollout"的推理 [tilert-speed-scaling-law]。但这一逻辑成立的前提是：
当 batch size 增大时（bs ≥ 16），传统框架的 launch overhead 占比急剧下降，TileRT 的加速幅度可能大幅缩水——正如 Fleet 在 bs ≥ 64 时被 vLLM 反超 [2604.15379]。
TileRT 自称"从零共同设计 compiler IR、tile scheduler、通信原语和执行模型" [tilert-speed-scaling-law]。这意味着每次模型架构更新都需要：
对比 GPUOS 的 3793 行轻量实现 [2604.17861] 和 Fleet 基于 Mirage 的增量扩展 [2604.15379]，TileRT 的全栈自研路线带来的维护成本远高于增量式方案。
TileRT 代表了推理系统优化的"最大主义"极端——把整个模型视为单个 GPU 程序，从编译器到运行时全栈重写。在以下谱系中占据右端：
operator fusion (XLA/TVM) → graph compilation (torch.compile) → persistent kernel (GPUOS) →
chiplet-aware megakernel (Fleet) → full-model AOT engine (TileRT)
每一步向右，优化边界扩大但灵活性降低。TileRT 是这条路线的逻辑极限——再往右就只剩硬件定制芯片了。
TileRT 的部署前提极为严苛：
这定位了 TileRT 在"模型厂商自研推理引擎"的生态位——类似 Google 的 TPU 推理栈或 Tesla 的 FSD 推理系统，而非通用社区框架。
| 维度 | vLLM/SGLang | TRT-LLM | GPUOS | Fleet | TileRT |
|---|---|---|---|---|---|
| 开发者 | 社区 | NVIDIA | 学术 | AMD Research | 模型厂商 |
| 灵活性 | 高 | 中 | 高 | 低 | 极低 |
| 极限性能 | 中 | 中-高 | 高(微操作) | 高(小BS) | 理论极高 |
| 维护成本 | 低 | 中 | 低 | 高 | 极高 |
| 部署门槛 | 低 | 中 | 低 | 高(AMD-only) | 极高 |
TileRT 声称已驱动 GLM-5.1 在 MaaS 平台上线 [tilert-speed-scaling-law]，这是持续执行范式首次在生产规模的验证。相比之下，GPUOS 停留在 benchmark 验证 [2604.17861]，Fleet 停留在 AMD research 实验室阶段 [2604.15379]。TileRT 的生产部署经验（KV 碎片化、MTP 动态 reshape 等稳定性挑战）[tilert-speed-scaling-law] 是其最独特的贡献——即使没有定量数据，"在生产流量下跑通了"本身就是重要信号。
TileRT 的静态 AOT 和 GPUOS 的动态 JIT 可以组合：对模型的确定性骨架（linear layers、fixed-topology attention）用 AOT 编译为 persistent pipeline，对动态部分（MoE routing、variable-length KV compression）在 pipeline 内保留 JIT injection 插槽。GPUOS 的 dual-slot aliasing [2604.17861] 可作为 pipeline 内的动态更新原语，实现"骨架持续执行 + 节点可热替换"。
TileRT 当前运行在 NVLink 域（H200 NVL），但未来 GPU 不可避免地走向 chiplet [2604.15379]。将 Fleet 的 Chiplet-task 抽象 [2604.15379] 嵌入 TileRT 的 Engine Kernel——让 tile pipeline 在 XCD 边界感知 L2 分区，tile 的 producer-consumer 关系对齐 XCD affinity——是未来 AMD/NVIDIA chiplet GPU 上 TileRT 方案的自然演进。
DeepSeek-V4 的 CSA "先压缩再稀疏"和 HCA "极致压缩后 dense" [deepseek-v4] 在 persistent engine 内有独特优化机会：
当 TileRT 的 Engine Kernel 运行在 chiplet GPU（MI350 或 Blackwell）上时，tile-to-SM 的分配需要遵循 NUMA 原则 [2511.02132]。AOT 编译器可在编译期生成 tile routing table：同一"attention compute cluster"的 tiles 被静态绑定到同一 XCD/die，权重 tiles 按 M-major 顺序编排以最大化 intra-XCD L2 复用。这将 2511.02132 的 swizzle 思想从 per-kernel 运行时决策提升为编译期静态保证。
Fleet 在 bs ≥ 64 时被 hipBLASLt 反超 [2604.15379]——compute-bound 区间单 kernel 极致调优优于跨 kernel 持久化。TileRT 的 Engine Kernel 可引入"运行时反馈驱动的 fusion 粒度切换"：tile pipeline 内携带轻量级 occupancy counter，当检测到 MFMA pipeline 饱和（compute-bound 信号）时，将特定 GEMM tile 委托给高度优化的 vendor library（cuBLAS/hipBLASLt），在 pipeline 内部实现 persistent ↔ standalone 的动态切换。