TileRT 开源代码仓库（tile-ai/TileRT）处于一个独特的位置：它是 persistent execution paradigm 在生产级推理引擎中的第一个可审计实例，但其核心调度逻辑封装在闭源 C++ 库中，仅 Python 编排层开源。围绕它的 4 个相关 entity 构成了一个完整的比对网格：
这四者在 persistent execution paradigm 维度上形成一个谱系：GPUOS（通用原语）→ Fleet（学术 megakernel）→ TileRT 博客叙事（生产 persistent engine）→ TileRT 代码（??? 真相待审）→ TokenSpeed（non-persistent 替代方案）。
TileRT 博客宣称 "AOT 编译将整个模型静态展开为单个 Persistent Engine Kernel，host 仅启动一次" [tilert-speed-scaling-law]。但代码仓库揭示的执行模型与此叙事存在关键偏差：
| 博客声称 | 代码实际 | 裂缝评估 |
|---|---|---|
| 单个 Persistent Engine Kernel | dsa_show_hands_prepare_money() 捕获 CUDA graph，dsa_show_hands() 回放 [tile-ai-tilert] | CUDA graph ≠ persistent kernel。Graph 是录制-回放模型，kernel 在 graph replay 时仍会逐个被硬件 scheduler 调度；persistent kernel 是 GPU 端常驻执行，永不退出。二者的 host-device 交互模型根本不同 |
| Warp/Block/GPU 三级特化 | Python 层完全不可见；所有 fused op 的 tilert_forward() 最终 dispatch 到 torch.ops.tilert.* C++ 算子 [tile-ai-tilert] | C++ 黑盒中可能确实存在 warp specialization，但开源代码无法验证 |
| AOT 编译期将整个模型静态展开 | 代码构建路径是 Python 动态注册 register_op() → 运行时 init_tilert_weights() → prepare_money() CUDA graph capture [tile-ai-tilert] | 看不到 AOT 编译器 IR、不可见的编译期优化；Python 层展示的是运行时组装 + 图捕获模式 |
| GPU-resident orchestration，通信从 NCCL 迁入 persistent kernel | 每个 fused op 带 AllReduce 后缀（UnProjOAllReduce, ExpertDownAllReduce），但 AllReduce 实现完全在 C++ 中 [tile-ai-tilert] | 通信原语的实现不可审计；是否真正绕过 NCCL 无法从开源代码确认 |
| Heterogeneous Workers: GPU0 = Sparse Indexer, GPU1-7 = MLA Workers | 代码中 num_devices=8 硬编码对称 TP，所有 8 个 GPU 构建相同的 Dsa 模型栈 [tile-ai-tilert] | 对称 vs 非对称直接冲突。博客描述的 GPU0 异构角色在开源 Python 代码中完全没有体现 |
核心判断：博客叙事是 TileRT v0.1.4（生产版）的设计目标或内部实现的技术营销描述，但开源代码仓库（截至 v0.1.3/v0.1.4-dev）展示的是一个更保守的执行模型——CUDA graph 录制-回放 + 闭源 C++ tile 调度。"Persistent Engine Kernel"可能存在于 C++ 黑盒中（CUDA graph capture 内部的 C++ kernel 可以是 persistent 的），但从可审计的 Python 层无法确认。
| 维度 | TileRT | GPUOS |
|---|---|---|
| 设计目标 | 单模型极致延迟 (batch=1) | 通用微操作加速 |
| kernel 策略 | 整图 CUDA graph + 闭源 tile scheduler | Persistent kernel + ring buffer + dynamic dispatch [2604.17861] |
| 可审计性 | Python 壳 + C++ 黑盒 | 3793 行全开源 [2604.17861] |
| 动态性 | update_sampling_config() 需完全 teardown + re-capture [tile-ai-tilert] | NVRTC JIT 零停机热更新 [2604.17861] |
| 硬件绑定 | 8×B200 硬编码 | H100/RTX 5090/GB10 三平台 [2604.17861] |
| batching | batch=1 only | hybrid：小 op 走 GPUOS，大 GEMM 走传统 launch |
| 生产状态 | Z.ai 生产部署 | 学术原型 |
GPUOS 的根本优势在于可组合性——它是 PyTorch TorchDispatch 层的透明加速，不需要重写模型 [2604.17861]。TileRT 的根本优势在于端到端极致——把 Norm+Proj+Quant+Comm 四类操作跨边界融合为 20+ fused ops [tile-ai-tilert]，是 GPUOS per-op dispatch 做不到的。但 GPUOS 的 3793 行全开源在学术可信度上完全碾压 TileRT 的闭源黑盒。
Fleet 的核心创新是 Chiplet-task 抽象——把"一颗 XCD + 其 4 MB L2"作为显式调度单元 [2604.15379]。TileRT 没有等价的硬件拓扑感知概念（代码中不可见 SM/GPC 级调度逻辑），其 tile 调度完全在 C++ 黑盒中。但 Fleet 在 bs=1 时加速仅来自 dispatch 压缩（L2 hit 16.9% ≈ baseline 的 16.4%）[2604.15379]，而 TileRT 在 bs=1 达到 600 tok/s [tile-ai-tilert]——暗示 TileRT 的 tile 级计算-通信重叠在 bs=1 场景下远比 Fleet 的 L2 协作更有效。
TokenSpeed 选择了与 TileRT 完全对立的工程哲学 [tokenspeed]：
| 维度 | TileRT | TokenSpeed |
|---|---|---|
| 调度器 | C++ 黑盒 tile scheduler | C++ FSM 13 状态 + RAII 类型安全，全开源 |
| 模型定义 | 手写 fused ops per model | Placement 注解 + 编译器自动通信 |
| 内核 | 闭源 tile-level 融合 | 5-band 内核注册表 + 插件化 |
| 并行模式 | 8-way 对称 TP 硬编码 | 不对称 TP（ATTN_TP ≠ MoE_TP），编译器自动 resharding |
| batching | batch=1 only | 连续 batching + retraction |
| 目标 | 单请求极致 TPOT | Pareto: latency × throughput |
TokenSpeed 的 MLA q-head 折叠使 agent 典型 decode 延迟近乎减半 [tokenspeed]——这是一种可审计、可复现的 kernel 优化，与 TileRT 的闭源 tile 调度形成鲜明对比。
博客宣称 TileRT 是 "Persistent Engine Kernel" [tilert-speed-scaling-law]，代码显示是 CUDA graph capture/replay [tile-ai-tilert]。这是两种根本不同的执行模型：
可能的调和解释：TileRT 的 C++ 自定义算子内部可能是一个 persistent kernel，被包装为单个 CUDA graph node。这在技术上可行（persistent kernel 可以被 graph capture），但意味着"persistent"的粒度不是"整个模型"，而是"单个 C++ 算子内部"——这与博客叙事的宏大叙事有质的差异。无法从开源代码验证。
博客详细描述 GPU0 = Sparse Indexer Worker，GPU1-7 = MLA Workers [tilert-speed-scaling-law]。但代码中 8 个 GPU 构建完全相同的 Dsa 模型栈，权重加载循环 for device_id in range(self.num_devices) 对所有设备一视同仁 [tile-ai-tilert]。稀疏注意力的 sparse_index 操作在每个 GPU 上都有对应的 fused op [tile-ai-tilert]，未见到 GPU0 独占 sparse indexing 的逻辑。
可能解释：(a) Heterogeneous Workers 仅在 GLM-5.1 的 C++ 后端实现，Python 层不体现；(b) 博客描述的是 v0.1.4 目标架构，v0.1.3 代码尚未实现。无论哪种，开源代码与博客声称不一致是事实。
TileRT 声称 DeepSeek-V3.2 达 600 tok/s，GLM-5 达 500 tok/s [tile-ai-tilert]。但：
.so 发布为 Docker 镜像中的 pip wheel——无法从源码复现构建对比 GPUOS 的 3793 行全开源 + Table 2 多平台基准 [2604.17861]，和 Fleet 的 rocprofiler L2 hit 数据 + HBM 流量逐 batch 对比 [2604.15379]，TileRT 的性能声称缺乏最基本的可验证性。TokenSpeed 同样在 preview 状态，但至少公开了 Kimi K2.5 的 Pareto 曲线图 [tokenspeed]。
ModelArgs.max_batch_size = 1 和 FlashSparseMLA 的 assert batch == 1 将 TileRT 限制在纯 TPOT 优化 [tile-ai-tilert]。这意味着：
TokenSpeed 的 retraction FSM 展示了如何在内存压力下优雅处理长 context agent 请求 [tokenspeed]，而 TileRT 的 batch=1 硬编码完全避开了这类系统设计难题。
update_sampling_config() 的生产脆弱性 #变更 temperature/top_p/top_k 时需完全 teardown + re-capture 整个 forward pass 的 CUDA graph [tile-ai-tilert]。在生产 serving 中，不同用户请求常有不同的 sampling 参数——每次切换就是一次完整的 graph re-capture。GPUOS 的 persistent kernel 天然支持动态 workload 且性能不退化 [2604.17861]。
TileRT 代码中的 sparse_index（64 个 index heads, top-2048 KV 位置选择）被 L2 蒸馏标注为"独立于 DeepSeek 原始论文的 TileRT 特有优化" [tile-ai-tilert]。但权重名称 self_attn.indexer.wk 直接出现在 DeepSeek-V3.2 的 model checkpoint 中——这些权重不是 TileRT 训练的，而是模型本身带的。TileRT 的贡献是在 batch=1 decode 下高效实现了这种稀疏注意力（将 160K 位置缩减为 2048，KV 读取量降低 ~78×），而非发明了这种机制。
通用性 ←————————————————————————→ 极致性
GPUOS Fleet TileRT (code)
(任意 op) (单模型 AMD) (单模型×单硬件 NVIDIA)
3793 行全开源 学术原型未开源 Python 壳 + C++ 黑盒
15.3× element 1.56× bs=1 600 tok/s bs=1
Z.ai 生产部署
TileRT 占据了一个独特生态位：唯一在生产中验证 persistent execution 理念的系统。GPUOS 是学术原型（无 multi-GPU）[2604.17861]；Fleet 是学术验证（单模型单卡）[2604.15379]；TokenSpeed 走了 non-persistent 路线 [tokenspeed]。TileRT 虽然开源程度最低，但"Z.ai 生产部署"这一事实给了它不可替代的验证价值。
将 TileRT 放入更大的范式演进主线 [2604.15379]：
| 范式 | 被显式化的隐式约束 | 代表系统 |
|---|---|---|
| PagedAttention (2023) | KV cache 连续分配假设 | vLLM |
| FlashAttention (2022) | HBM 带宽约束 | FA1/FA2/FA3 |
| Chiplet-task (2026) | L2 物理分区 | Fleet |
| Tile-level fusion (2025-2026) | kernel launch 边界 | TileRT |
| FSM type-safe scheduling (2026) | KV cache 资源安全 | TokenSpeed |
TileRT 的贡献是将"kernel 间的执行边界"从隐式约束变为显式优化目标——通过 tile-level fused ops 消除 RMSNorm/GEMM/AllReduce 之间的边界 [tile-ai-tilert]。博客将这个贡献叙述为 "Persistent Engine Kernel" [tilert-speed-scaling-law]，代码实现为 "20+ fused ops + CUDA graph"——形式不同，但解决的根本问题一致：消除 kernel boundary overhead。
TileRT 博客-代码裂缝本身是一个有价值的生态信号。它揭示了 persistent execution paradigm 的成熟度阶梯：
从概念到生产的差距暗示：即使 TileRT 团队，也需要在"理想的 persistent kernel 架构"和"可以发货的 CUDA graph + fused ops 组合"之间做工程妥协。这对后续研究者是重要的参考——persistent kernel 的完整愿景（GPUOS/Fleet 描绘的那种）在生产中可能仍需要大量工程折衷。
GPUOS 的 NVRTC JIT + dual-slot aliasing 实现零停机热更新 [2604.17861]，TileRT 的 update_sampling_config() 需完全 re-capture CUDA graph [tile-ai-tilert]。如果将 GPUOS 的 dynamic injection 机制引入 TileRT 的 tile scheduler——在 persistent kernel 内部支持运行时 operator 更新——可以消除 sampling config 变更时的 graph teardown 开销，同时保留 tile-level fusion 的延迟优势。这是 GPUOS 的通用性与 TileRT 的极致性的直接组合。
Fleet 证明了 chiplet-aware scheduling 在 AMD MI350 上的价值 [2604.15379]。NVIDIA Blackwell 是双 die 架构（逻辑上相干但物理 NUMA），TileRT 在 B200 上运行但完全不可见是否有 die-aware 调度。将 Fleet 的 Chiplet-task 概念（把"一个 die + 其 L2 分区"作为调度单元）引入 TileRT 的 tile scheduler，可能在 batch>1 扩展时释放额外性能——但首先需要 TileRT 突破 batch=1 硬编码。
TileRT 当前 20+ fused ops 是手写的 Python 壳 + 闭源 C++ 实现。TokenSpeed 的内核注册表展示了 5-band 优先级插件化设计 [tokenspeed]。如果将 TileRT 的 fused op 规格（如 RMSNormProjxWqkvia = RMSNorm + QKV + FP8 解量化）表达为可编程的 tile-level DSL（类似 TileLang/Triton 但支持跨算子融合描述），社区可以审计、复现、扩展这些融合模式，而非依赖闭源 C++ 黑盒。TileRT 的参考内核已混合使用 TileLang 和 Triton [tile-ai-tilert]——这暗示 TileLang 生态可能是实现可审计 tile fusion DSL 的自然载体。
Fleet 的 Chiplet-task 对 MoE 不直接适用（M-major 协作假设被 expert routing 打破），但 MoE 的 expert 稀疏激活与 chiplet 私有 L2 天然亲和 [2604.15379]。TileRT 已实现 MoE routing 的 tile-level fusion（ExpertSelectUpGateSiLU 融合选择+投影+激活为单 kernel）[tile-ai-tilert]。组合两者：在 chiplet-aware 调度框架中，将 expert 按亲和性绑定到特定 XCD/die 的 L2，同时在每个 XCD 内部使用 TileRT 式 tile-level MoE fusion——这是 persistent execution paradigm 在 MoE 场景的自然延伸，但目前无论 Fleet 还是 TileRT 都没有探索。
TileRT 的 inject_cache() API 接受外部 prefill 系统的 KV cache [tile-ai-tilert]，TokenSpeed 的 FSM 用 RAII 保证 KV cache 资源安全 [tokenspeed]。一个未探索的组合是：prefill engine（SGLang/TokenSpeed，支持连续 batching + 高吞吐）生产 KV cache，通过 type-safe 序列化协议传递给 decode engine（TileRT，batch=1 极致延迟），TokenSpeed 的 FSM 状态机保证 KV 页面在跨引擎传递时不会双重释放或遗漏。当前 TileRT 的 inject_cache() 接受裸 tensor tuple，无任何资源安全保证——这是 P/D 分离部署中的真实风险点。