Static Compilation for LLM Inference：从 ASIC Graph Compile 到 Persistent Engine Kernel #

1. 主题缘起 #

2018–2021 年间，AI 推理芯片（Habana Goya/Gaudi、Google TPU、Graphcore IPU）普遍采用 graph compilation 技术：编译期知道所有 tensor shape，静态规划执行流水，中间 activation 尽量驻留片上 SRAM。这一范式在 ASIC 上通过硬件支持（大 SRAM + 异构引擎 + 硬件 scheduler）获得了天然优势。

2024–2026 年，LLM 推理延迟成为核心指标后，多条路线在通用 GPU 上重新实现了这一范式。TileRT 通过 AOT 编译将整个模型展开为单个 Persistent Engine Kernel，以 tile 为调度粒度实现 compute-IO-comm 持续重叠 [tilert-speed-scaling-law]。TokenSpeed 用 C++ FSM 调度器 + Placement 编译器 + Blackwell MLA 内核在相同目标下取得了与 TRT-LLM 竞争的性能 [tokenspeed]。GPUOS 提出 persistent kernel + JIT operator injection 消除 kernel launch overhead [2604.17861]。Fleet 在 AMD chiplet GPU 上引入 Chiplet-task 抽象实现 L2 cache 协作复用 [2604.15379]。

与此同时，FlashAttention 系列（FA1→FA2→FA3→FA4）从 intra-operator tiling 出发，沿硬件代际演进逐步发展出完整的 hardware-algorithm co-design 方法论——从 A100 上的 IO-aware tiling [2205.14135] 到 Blackwell 上的 TMEM pipeline + 软件 exp 模拟 [2603.05451]，代表了 kernel 层面从"手写单 kernel"到"硬件约束驱动的系统化 pipeline 设计"的演进。这一演进与全模型静态编译路线（TileRT/Fleet）形成互补——前者解决单 attention kernel 的极致效率，后者解决跨 operator 的全模型编排。

从技术谱系看，这些方案与 2018 年 ASIC graph compile 同源：都是用编译期信息换运行时开销 [tile-ai-tilert]。这一 topic 横跨 kernel（算子融合、persistent kernel、warp specialization、auto-search）和 framework（graph compiler、静态调度、serving 系统架构），探讨的核心问题是：静态编译技术在 LLM inference 的适用边界、技术谱系和产业格局。

2. 覆盖的 category 分布 #

3. 时间线 #

4. 技术谱系 #

核心洞察：TileRT/TokenSpeed 不是全新范式的发明，而是 ASIC graph compile 原理（静态编译 + 片上驻留 + 异构 overlap）在通用 GPU 上的软件复现 [tilert-speed-scaling-law]。差异在于 GPU SMEM 极小（~228 KB vs ASIC 50+ MB），迫使采用 tile pipeline 作为 workaround。FlashAttention 系列是这一 tile pipeline 技术的原型和基础设施——FA1 确立了 IO-aware tiling 范式，FA4 展示了 hardware-algorithm co-design 如何随硬件代际演化 [2603.05451]。与此同时，AI-augmented kernel search（AVO、μCUTLASS、LoongFlow、TTT-Discover）从另一个方向逼近极限——用 agent/RL 自动搜索替代手动编写，且 TTT-Discover 已在 kernel 优化上超越人类冠军 [2601.16175]，但目前仅优化单 kernel 粒度，尚未扩展到全模型编排。

5. 技术线交错 #

5.1 ASIC 大 SRAM vs GPU 小 SMEM——同一目标的不同约束 #

ASIC 推理芯片拥有 50–900 MB 片上 SRAM，graph compiler 可以将完整 activation tensor 静态分配到 SRAM，中间结果全程不回 HBM。

GPU shared memory 仅 ~228 KB/SM（比 ASIC SRAM 小 200–4000 倍）。TileRT 无法放完整 activation，必须将其切成 tile，每次只在 SMEM 放一个 tile 的数据，处理完传给下一个 stage 仍在 SMEM，再换下一个 tile——这就是"tile pipeline"存在的根本原因 [tilert-speed-scaling-law]。

5.2 硬件异构引擎 vs 软件 Warp Specialization #

Gaudi 的 MME（矩阵引擎）+ TPC（通用引擎）+ DMA（数据搬运引擎）是物理上分离的，天然可以并行——graph compiler 只需排好时序。

TileRT 在同构的 NVIDIA SM 上，通过 warp group 分工模拟这种异构 [tilert-speed-scaling-law]：

Gaudi 硬件:              TileRT 软件模拟:
  MME → GEMM              Warp Group B → Tensor Core compute
  TPC → Activation        (融合进同一个 warp group)
  DMA → 数据搬运           Warp Group A → TMA async copy
  NIC → 通信              Warp Group C → NVLink comm
  ↑ 物理并行               ↑ 软件并行（争抢同一 SM 资源）

Fleet 在 AMD MI350 上面临不同约束：persistent megakernel 导致每 SIMD 只能跑 1 wave（register pressure 取所有 task 类型的联合最大值），L2 miss 直接 stall MFMA pipeline [2604.15379]。这使得 Fleet 的 L2 hit rate 从"锦上添花"升格为"生死攸关"。

AVO 在 NVIDIA Blackwell 上验证了 warp-specialized pipeline（MMA/Softmax/Correction/Load warps）可达 1668 TFLOPS [2603.24517]。HipKittens 在 AMD CDNA4 上明确拒绝 wave specialization（仅达 80% peak），转而采用 8-wave ping-pong [2511.08083]。结论：warp/wave specialization 的有效性是 architecture-dependent，不可跨 vendor 泛化。

5.3 FlashAttention 系列：从 IO-Aware Tiling 到 Hardware-Algorithm Co-Design #

FlashAttention 系列（FA1→FA2→FA3→FA4）是 GPU attention kernel 优化的主干线，其演进轨迹完整展示了 kernel 工程如何随硬件代际系统化升级：

[2205.14135] [2307.08691] [2407.08608] [2603.05451]

演进规律：每一代的核心瓶颈都不同——FA1 解决 IO，FA2 解决并行度，FA3 解决异步流水，FA4 解决非对称硬件 scaling。这意味着"下一代最重要的优化"完全由新硬件的 bottleneck profile 决定，不可从前一代外推。

对全模型编译的启示：

1. Tiling 基础设施：FA1 的 IO-aware tiling + online softmax 成为 TileRT 将 tiling 扩展到全 forward pass 的基础 [tilert-speed-scaling-law]。
2. Warp-specialization 范式：FA3 的 producer-consumer warp-spec 成为 GPUOS/Fleet 的直接先驱——证明了 GPU 上可以用 warp 分工模拟硬件异构引擎。
3. Hardware co-design 方法论：FA4 展示了 kernel 设计如何系统化地从硬件 roofline 出发——forward 的 MMA/SMEM/exp cycle 分析 → 针对性优化（TMEM 解耦、软件 exp、2-CTA 降 smem 流量）。这一方法论可推广到全模型 tile scheduler 设计。
4. 编译加速：FA4 用 CuTe-DSL（Python → PTX）替代 C++ templates，编译时间从 55s 降至 2.5s（22×）[2603.05451]——这对全模型编译系统（需要频繁迭代 kernel）具有工程层面的重大意义。

5.4 Auto Fusion (XLA/TVM) vs Manual Fusion (TileRT) vs AI-Augmented Fusion (μCUTLASS/AVO/LoongFlow/TTT-Discover) #

2018–2021 年的自动 fusion compiler 有结构性限制：

XLA/TVM 的假设	LLM bs=1 decode 的现实
GEMM 是 compute-bound → 不融合，调 cuBLAS	bs=1 时 GEMM 也 memory-bound → 应该融合
AllReduce 是黑盒 NCCL call	AllReduce 时间和 compute 可比 → 需要 overlap
同构执行 → 所有线程做相同的事	需要 warp specialization → 不同 warp 做不同事
Fusion 边界在 GEMM/control-flow 处切断	需要跨 Norm+GEMM+Attention+AllReduce 全融合

TileRT 的解法是放弃自动化，手写 25+ 巨型 fused kernel（如 rmsnorm_projx_wqkvia 1095 行），代价是完全不通用 [tile-ai-tilert]。

2025–2026 年出现的第三条路线——AI-augmented kernel generation——试图用 agent 弥合这一鸿沟，且方法论本身也在快速演进：

方法	搜索策略	学习能力	Kernel 成果	局限
AVO [2603.24517]	Agentic coding evolution	无（frozen LLM）	超越 cuDNN +3.5%，1668 TFLOPS	7 天 B200 + 500 方向，验证成本高
μCUTLASS [2603.29010]	DSL + SOL roofline guidance	无（frozen LLM in-context）	GPT-5-mini 1.56× speedup	仅单 kernel 粒度
LoongFlow [2512.24077]	Plan-Execute-Summarize + MAP-Elites	跨代累积 insight（lineage memory）	>60% efficiency over OpenEvolve	仅用于算法发现，未直接用于 kernel
TTT-Discover [2601.16175]	Entropic RL + PUCT state reuse	在线 RL 更新 LLM 权重	TriMul kernel 超人类 15.3%（1161μs vs 1371μs）	~$500/题，需要可微分 reward

关键技术演进：从 AVO（blind mutation + frozen LLM）→ LoongFlow（directed evolution + lineage memory）→ TTT-Discover（test-time learning + weight update），AI kernel search 的方法论正在从"搜索"走向"学习"。TTT-Discover 证明了一个重要节点：当 LLM 本身可以在 test-time 持续学习时，单 kernel 性能可以超越人类专家 [2601.16175]。

但所有方法目前仅优化单个 kernel 粒度，尚未触及跨 operator 的全模型编排——这正是 TileRT 手动做到但 auto-compiler 做不到的部分。

5.5 Graph Compile 的根本矛盾：静态编译 vs 动态 Serving #

LLM serving 需要的动态性与 graph compile 的静态假设根本冲突：

Graph Compile 前提	LLM Serving 现实
静态 shape	KV Cache 每 token 增长
静态计算图	MoE 动态路由（input-dependent）
单次执行	Continuous batching 动态拼 batch
确定性调度	Preemption、priority scheduling
编译一次	Prefix sharing 需要运行时判断

这是 XLA 在 LLM serving 走不通的根本原因，也是 vLLM/SGLang（动态 runtime + 单 kernel 优化）成为主流的原因。TileRT 通过限制场景（bs=1、模型固定、硬件固定）绕过了这些矛盾 [tile-ai-tilert]。TokenSpeed 走了中间路线：编译期用 Placement annotations 确定 SPMD 并行策略，运行时用 C++ FSM 调度器支持 prefill/decode 状态切换、retraction、speculative decoding 等动态行为 [tokenspeed]——静态编译骨架 + 动态运行时插槽的 hybrid 路线。

5.6 Persistent Kernel 的两极：轻量级 Dispatcher vs 重量级 Megakernel #

GPUOS 和 Fleet 代表了 persistent kernel 范式的两种极端设计选择 [2604.17861]：

	GPUOS	Fleet	TileRT
资源占用	每 SM 1 block（2-4% 线程）	256 CU 全占（减 3.1% scheduler）	全模型一个 CUDA graph
调度哲学	填谷：大 kernel 走传统路径	占满：所有 decode ops 融入 megakernel	全静态：编译期确定所有执行
动态性	极高：NVRTC JIT 零停机热更新	低：task graph 编译时确定	低：新模型需全栈重新编译
加速来源	消除 launch overhead（15.3× micro-ops）	L2 协作复用（bs=32 时 51% hit rate）	消除所有 kernel 间 idle
适用场景	动态 workload、研发阶段	AMD chiplet 低延迟 decode	固定模型、bs=1 生产极致

6. 共识与分歧 #

共识 #

Launch overhead 在 bs=1 decode 是真实瓶颈。 GPUOS 量化：null kernel launch 3–7 μs，100 ops/token 累计 300–700 μs [2604.17861]。TileRT 验证：理论 ~1000 tok/s vs 实际几十 tok/s，差距达 10× [tilert-speed-scaling-law]。Fleet 量化：每 token 250 次 kernel launch 在 MI350 上主导延迟 [2604.15379]。所有方案（CUDA Graphs、persistent kernel、megakernel、AOT engine）都以消除这一开销为目标。

静态编译可以有效消除 overhead，代价是动态性。 TileRT 达 600 tok/s（DeepSeek-V3.2）[tile-ai-tilert]，TokenSpeed Pareto 优于 TRT-LLM [tokenspeed]，Fleet bs=1 decode 1.56× [2604.15379]，GPUOS 15.3× micro-ops [2604.17861]——所有方案验证了同一结论：预先确定执行计划 → 运行时零调度 → latency 接近 compute 本身。

Prefill 阶段收益有限。 Prefill 是 compute-bound（大 seq_len GEMM），launch overhead 占比 <1%。静态编译/fusion 的主要收益在 decode 阶段（memory-bound、μs 级 kernel）[tilert-speed-scaling-law]。

Warp/wave specialization 的有效性依赖硬件架构。 AVO 在 NVIDIA Blackwell 上 warp-specialized pipeline 达 1668 TFLOPS [2603.24517]。FA3 在 H100 上 producer-consumer warp-spec 贡献 +2.1%（570→582 TFLOPs/s），2-stage pipelining 贡献 +13.6% [2407.08608]。HipKittens 在 AMD CDNA4 上明确拒绝 wave specialization，转用 8-wave ping-pong 达到匹配手写汇编的效果 [2511.08083]。这是硬件差异（NVIDIA 动态 register 分配 vs AMD 静态分配）的直接后果。

Attention kernel 效率随硬件代际逼近但永不达到 matmul peak。 FA1 在 A100 上 ~50%，FA2 达 73%，FA3 在 H100 上达 75%，FA4 在 B200 上达 71% [2205.14135] [2307.08691] [2407.08608] [2603.05451]。Gap 的根因是 softmax 中的非 matmul 操作（exp/sum/max）——matmul vs non-matmul 吞吐差从 A100 的 16× 扩大到 H100 的 253× 再到 B200 的 512×，使这一 gap 成为物理约束而非工程问题。

分歧 #

自动 vs 手动 vs AI-augmented fusion。 XLA/TVM 走自动 fusion（通用但浅），TileRT 走手动 fusion（极致但不通用）[tile-ai-tilert]，μCUTLASS/AVO/LoongFlow/TTT-Discover 走 AI-augmented（单 kernel 极致但未扩展到全模型）[2603.29010] [2603.24517] [2512.24077] [2601.16175]。中间地带——AI agent 自动生成 TileRT 级全模型 fused kernel——目前空白。

"新范式" vs "旧酒新瓶"。 TileRT 博客将 Persistent Engine Kernel 定位为推理系统的范式转移 [tilert-speed-scaling-law]。从 ASIC graph compile 的历史视角看，核心原理（静态编译 + 片上驻留 + 异构 overlap）至少追溯到 2018 年 Goya/TPU。TileRT 的增量贡献是在通用 GPU 上用软件复现了这些效果，而实际开源代码仍是 CUDAGraph + 25+ fused ops [tile-ai-tilert]。

是否需要 rewrite everything。 TileRT 路线要求全栈重写（compiler IR + tile scheduler + 通信原语）[tile-ai-tilert]。TokenSpeed 走中间路线——复用 FluentLLM runtime 基础 + 自研 kernel registry + Placement 编译器，代价是不如 TileRT 极致但换取了更快的模型适配 [tokenspeed]。对立观点：FlashAttention + CUDAGraph + 少量 fused kernel 已经覆盖了 80% 收益。

静态 megakernel vs 动态 persistent dispatch。 Fleet 的静态 megakernel 在编译时确定所有 operator，获得更好的编译器优化（跨 operator 寄存器分配）但添加新 op 需重编译 [2604.15379]。GPUOS 的 JIT persistent kernel 支持零停机热更新但仅覆盖 micro-ops [2604.17861]。两者在 production ML 快速迭代（每 2 周新模型）vs 生产稳定性的取舍上代表不同答案 [2604.17861]。

Frozen-LLM search vs test-time learning for kernel optimization。 AVO/LoongFlow 用冻结 LLM 做搜索（不修改模型权重），TTT-Discover 在 test-time 通过 RL 更新 LLM 权重 [2601.16175]。前者更轻量且不依赖可微分 reward，后者在困难问题上优势明显（TriMul kernel 提速 15.3% vs AVO 3.5%）但成本更高（~$500/题）。是否值得 test-time training 取决于问题难度和单次优化的经济价值。

7. 根本性困难 #

7.1 静态编译 vs 动态 serving 的不可调和 #

KV Cache 动态增长、continuous batching、MoE 动态路由、prefix sharing 等 serving 核心特性都依赖运行时决策。Graph compile 路线必须放弃这些能力或引入复杂的 workaround（bucketed compilation、padding、conditional graph）。

目前无解：要么极端静态化（TileRT 的 bs=1 固定模型路线 [tile-ai-tilert]），要么放弃 graph compile（vLLM/SGLang 路线）。TokenSpeed 的 FSM hybrid 是最接近中间地带的尝试——编译期确定并行策略，运行时保留状态转移和 retraction 能力 [tokenspeed]——但其 batch 调度仍远不如 vLLM 灵活（不支持跨请求动态拼 batch）。

为什么根本性困难：不是"没人做"，而是静态确定性与动态自适应在信息论层面矛盾——编译期无法获得运行时才存在的信息（哪个请求先到、context 多长、prefix 是否命中）。任何 hybrid 方案本质上是在两端之间寻找帕累托前沿，不存在"两全"的解。

需要哪些 category 协作：framework（调度策略）+ kernel（可变粒度执行）+ hardware（硬件支持的动态 dispatch 原语）。

已有尝试及不足：TileRT 和 TokenSpeed 都回避了这一矛盾而非解决它——前者限制 bs=1，后者限制为单节点。Fleet 更极端——persistent megakernel 占满 GPU 不释放，multi-tenancy 和 preemption 完全不可能 [2604.15379]。

预计难度：3-5 年。NVIDIA GB10 的硬件 launch 优化 [2604.17861] 暗示硬件层面可能提供部分解法。

7.2 Auto Fusion 到全模型编排的扩展 #

μCUTLASS 证明 170-line DSL 可以让中等 LLM 自动优化单个 kernel 至 1.56× [2603.29010]。AVO 证明 agent 可以在单 kernel 上超越人类极限 [2603.24517]。TTT-Discover 更进一步，证明 test-time RL 可在 kernel 上超越人类冠军 15.3% [2601.16175]。但从单 kernel 优化到全模型编排（TileRT 做到的）之间存在组合爆炸——需要同时决定：哪些 op 融合、tile size 如何选择、通信在哪里重叠、GPU 间角色如何分配。

为什么根本性困难：TileRT 的 25+ fused kernel 每个平均 ~500 行 [tile-ai-tilert]，加上 tile scheduler、通信原语和跨 GPU 异构角色分配，总搜索空间超出当前 LLM agent 的规划能力。μCUTLASS 的实验显示编译/运行/profiling 占迭代时间的 79% [2603.29010]——对于全模型级搜索，每次迭代的验证成本成为 bottleneck。LoongFlow 的 Plan-Execute-Summarize 范式 [2512.24077] 和 TTT-Discover 的 PUCT state reuse [2601.16175] 提供了部分解法（directed search + state reuse 减少冗余探索），但两者尚未在全模型粒度验证。

需要哪些 category 协作：kernel（DSL 设计）+ framework（全模型 cost model）+ 新的 agent 架构（分层规划 + 局部搜索）。

预计难度：2-4 年。TileLang/TileScale（TileRT 团队规划的编译器）可能是这个方向的尝试 [tile-ai-tilert]。

7.3 GPU 片上内存的物理限制 #

GPU SMEM 容量受 die area 约束，短期内不会增长到 ASIC SRAM 水平。Tile pipeline 的深度受限于 SMEM 容量和 register pressure——这是物理限制而非工程限制。Fleet 的实验直接证明了这一点：persistent megakernel 的 register pressure 导致每 SIMD 只能跑 1 wave，L2 miss 直接 stall MFMA pipeline [2604.15379]。

FlashAttention-4 的经验进一步佐证：Blackwell 的 TMEM（256 KB/SM）部分缓解了寄存器压力，但 SMEM 带宽（128 bytes/clock）未随 MMA 吞吐 scaling——若 MMA 再翻倍，smem 将成为绝对瓶颈 [2603.05451]。

为什么根本性困难：除非 GPU 架构发生根本变化（如 NVIDIA 引入大容量可编程 scratchpad），否则 tile pipeline 的复杂度无法从根本上简化。NVIDIA GB10 的 launch optimization [2604.17861] 暗示了硬件可能提供部分解法，但 SMEM 容量的物理约束不在此列。

预计难度：取决于硬件代际，5+ 年。

7.4 跨 Vendor 抽象的缺失 #

Fleet 绑定 AMD CDNA3/4 的 per-instruction scope 位和 XCD 拓扑 [2604.15379]。GPUOS 绑定 NVIDIA 的 NVRTC/PTX/CUDA Driver API [2604.17861]。TileRT 绑定 NVIDIA B200 的 TMA 和 warp specialization [tilert-speed-scaling-law]。FA4 绑定 Blackwell 特有的 TMEM 和 2-CTA cooperative MMA [2603.05451]。HipKittens 提供了跨 vendor 的 tile API 抽象 [2511.08083]，但仅覆盖单 kernel 粒度，未触及全模型编排。

为什么根本性困难：persistent kernel 依赖的同步原语（NVIDIA 的 cluster barrier + DSMEM vs AMD 的 buffer_wbl2 + flat_atomic_add sc0|sc1）在 ISA 层面完全不兼容。跨 vendor 的 persistent execution 抽象需要一个新的中间表示——目前不存在。

7.5 非对称硬件 Scaling 的持续挑战 #

FA4 揭示了一个将持续存在的困难：硬件各组件的 scaling 不均匀 [2603.05451]。Hopper → Blackwell 中 MMA 翻倍但 SMEM bandwidth 和 MUFU exp 不变。每一代新硬件都会创造新的非对称 bottleneck，迫使 kernel 完全重写。

量化：A100 matmul/non-matmul = 16×；H100 matmul/special-function = 253×；B200 MMA/MUFU = 512×。这一差距正在加速扩大——意味着 softmax 中的非 matmul 操作在未来每一代硬件上都将更加突出，且解法（如 FA4 的软件 exp 模拟）在下一代可能失效。

预计难度：永久性——每代硬件都需要新的 co-design 方案。这使得自动化 kernel generation（LoongFlow/TTT-Discover 方向）的战略价值更加凸显。

8. 成熟度判断 #

路线	成熟度	趋势	证据
ASIC graph compile (Gaudi/TPU)	生产成熟，但 LLM serving 市场份额极低	停滞	NVIDIA GPU 生态垄断
XLA for LLM inference	不适用——结构性限制无法解决	被 vLLM/SGLang 替代	见 §5.4 表格
CUDA Graphs	生产就绪，vLLM 已集成	稳定	作为 optimization pass 而非完整方案
vLLM/SGLang (动态路线)	社区主流，生产广泛部署	持续加速	32 个 framework 论文中过半以其为基线 [framework]
FlashAttention 系列	FA2 生产标配；FA3 H100 部署；FA4 Blackwell 就绪	加速	每代硬件对应一代 FA，已成为 attention 基础设施 [2205.14135] [2603.05451]
TileRT (极端静态路线)	单一模型厂商生产部署	细分赛道	Z.ai 生产上线 [tile-ai-tilert]
TokenSpeed (hybrid 路线)	已被 vLLM 部分采纳	加速	MLA kernel 被 vLLM PR #41778 采纳 [tokenspeed]
Fleet (AMD chiplet)	AMD research 原型	观望	未开源，依赖 Mirage MPK [2604.15379]
GPUOS (dynamic persistent)	学术原型，3793 行	观望	GB10 暗示硬件层面可能解决 [2604.17861]
AI-augmented kernel (AVO/μCUTLASS)	研究验证	加速	单 kernel 超越人类极限 [2603.24517]，但全模型未达
Directed evolutionary search (LoongFlow)	研究验证	加速	>60% efficiency over baselines，MAP-Elites 防 diversity collapse [2512.24077]
Test-time learning for kernel (TTT-Discover)	研究验证	观望/加速	Kernel SOTA（超人类 15.3%），但 ~$500/题 成本 [2601.16175]
Auto-compiler for LLM decode	规划阶段	观望	TileLang/TileScale 规划中 [tile-ai-tilert]

整体判断：静态编译路线在 LLM inference 的适用范围仍然较窄（bs=1、模型固定、硬件固定），短期不会成为通用方案。其价值集中在"模型厂商极致优化自有模型"的场景——类似 Google 用 TPU 服务自家模型。通用 serving 市场将继续由动态 runtime (vLLM/SGLang) 主导。但 hybrid 路线（TokenSpeed 式静态骨架 + 动态调度）正在模糊这一边界，可能在 2-3 年内成为新的均衡点。

FlashAttention 系列已确立为 attention kernel 的基础设施层——每代新 GPU 都对应一代 FA，且 FA4 的 CuTe-DSL 实现暗示这一迭代周期可能加速。AI-augmented kernel generation 是值得关注的加速器——TTT-Discover 证明 test-time learning 可以在单 kernel 上超越人类极限 [2601.16175]，当这一能力扩展到全模型编排时（LoongFlow 的 directed evolution + TTT-Discover 的 adaptive learning 结合），手动 fusion 的人力瓶颈将被打破。

9. 模型厂商自建推理 Infra 的战略分析 #

9.1 头部厂商已经在自建 #

TileRT 和 TokenSpeed 不是孤例——头部模型厂商普遍在自建推理基础设施 [tile-ai-tilert] [tokenspeed]：

厂商	自有推理栈	通用方案状态
Google	TPU + XLA + Pathways (自有 serving)	完全不用 vLLM
OpenAI	自研推理系统（未公开）	不用社区方案
DeepSeek	自研 serving + 自研通信库	不用 vLLM
智谱 (GLM)	TileRT [tile-ai-tilert]	对自有模型定制到极致
Moonshot (Kimi)	TokenSpeed [tokenspeed]	开源 MIT，但核心调度仍内部优化
Meta	自研 + 部分回馈开源 (FAIR infra)	贡献了 PyTorch 但内部跑自研

9.2 经济学逻辑：何时自建划算 #

通用方案为支持所有模型必须保持灵活性，灵活性带来运行时决策开销（launch overhead + 无法极致融合），距离硬件极限有 30-70% 的性能 gap。自建推理栈通过限定单一模型（shape 固定、架构固定、硬件固定），可以把这 30-70% 的性能捡回来——在 token 经济下直接转化为利润。

Break-even 计算：假设 8xH200 月租 $150K，通用方案 50 tok/s/卡，自研方案 150 tok/s/卡（3x speedup，TileRT 声称的量级 [tilert-speed-scaling-law]）。同样的卡数，自研方案吞吐 3x，等效硬件成本降低 67%。一个 1000 卡集群月省 $100K+。自研团队 10 人 x $30K/月 = $30K/月。300 卡以上规模就 break even。

9.3 做得起的条件与做不起的玩家 #

做得起的条件：(1) 模型架构稳定——每月大改一次架构则 AOT + 手写 fusion 投入归零；(2) 部署规模足够大——几百卡以上才能 justify 团队成本；(3) 有顶尖 GPU 系统人才——能写 1095 行 fused kernel 的人全球可能不到 100 个 [tile-ai-tilert]；(4) 模型和 infra 协同设计——模型架构反过来适配推理效率。

做不起的玩家：中小模型公司（模型还在频繁迭代）、模型代理商（跑别人的模型无法定制）、多模型平台（必须通用）、开源/学术社区（模型多样性太高）。

9.4 未来三层格局 #

• 头部 3-5 家（完全自建）：Google, OpenAI, DeepSeek 等。自有模型 + 自有芯片/集群 + 自有推理栈。
• 次头部 10-20 家（半定制）：智谱, Moonshot, Mistral 等。自有模型 + NVIDIA GPU + 定制推理引擎（TileRT/TokenSpeed 层）。
• 长尾（通用方案）：所有其他人。各种模型 + NVIDIA GPU + vLLM/SGLang。够用，不追求极限。

9.5 AI-augmented kernel 对格局的潜在冲击 #

μCUTLASS 证明 170-line DSL + SOL guidance 可以让中等 LLM 自动生成接近专家水平的 kernel [2603.29010]。TTT-Discover 证明 test-time RL 可以在 kernel 上超越人类冠军 15.3% [2601.16175]。LoongFlow 证明 directed evolution + lineage memory 可以 >60% 提升搜索效率 [2512.24077]。如果这些路线扩展到全模型编排，"能写 1095 行 fused kernel 的人全球不到 100 个"这一人才瓶颈可能在 2-4 年内被打破。这将降低自建推理栈的门槛——从"需要顶尖 GPU 系统团队"变为"需要 AI kernel agent + 领域 DSL"。

但成本瓶颈正在转移：AVO 需要 7 天 B200 计算时间 + 500+ 方向探索 [2603.24517]；TTT-Discover 每题 ~$500 [2601.16175]。即使 agent 能替代人类工程师，验证（编译 + profiling + 正确性测试）的硬件成本可能成为新的 gating factor。LoongFlow 的 directed evolution 提供了部分解法——通过 Plan-Execute-Summarize 认知循环和 lineage memory 减少无效探索 [2512.24077]，但尚需在 kernel 优化场景直接验证。

9.6 对通用方案 (vLLM/SGLang) 的影响 #

vLLM/SGLang 不会死——它们服务的是长尾市场：(1) 多模型平台（需要跑 100+ 不同模型）；(2) 研发阶段（模型还在迭代，不值得定制）；(3) 中小规模部署（< 100 卡，定制不划算）；(4) 开源/学术（需要灵活性）。但通用方案会越来越像"开发环境"而非"生产环境"——头部的生产流量跑在自研栈上，通用方案用于 prototyping 和小规模服务。

值得注意的是 TokenSpeed 的策略——MIT 开源 + vLLM 集成（MLA kernel PR #41778）[tokenspeed]——暗示了一种"自研核心 + 回馈社区"的中间路线，可能比 TileRT 的完全闭源路线有更大的生态影响力。

10. 邻接 topic #

persistent-execution-paradigm：本 topic 的子集，专注于 persistent kernel vs megakernel 的横向对比。本 topic 增加了历史纵深（ASIC graph compile 的源流）、FlashAttention 演进线、AI-augmented fusion 对比和产业格局分析。

cluster-llm-deployment：本 topic 解释了为什么 cluster-level serving 系统（PD 分离、continuous batching、multi-tenant）与 graph compile 路线天然矛盾。framework L3 survey 中的 PD 分离主线（DualPath/PrfaaS/DynaServe）[framework] 是这一矛盾的直接产物。

attention-optimization：FlashAttention 系列（FA1→FA2→FA3→FA4）构成独立的 attention kernel 演进主线 [2205.14135] [2307.08691] [2407.08608] [2603.05451]。本 topic 与之的交叉在于：(1) FA 系列是 TileRT/Fleet 需要融合的核心 op；(2) FA4 的 hardware co-design 方法论可推广到全模型 tile scheduler；(3) AVO/TTT-Discover 的极致单 kernel 优化与 TileRT 的全模型编排代表了不同粒度的极致路线。

ai-augmented-code-generation：LoongFlow 和 TTT-Discover 代表了 AI-driven code optimization 的前沿——前者通过 directed evolutionary search 提升搜索效率 [2512.24077]，后者通过 test-time learning 突破 frozen-LLM 搜索的天花板 [2601.16175]。当这两条路线与 kernel DSL（μCUTLASS）结合时，可能催生"自动 tile-level compiler"的新方向。

潜在演化：如果 AI-augmented kernel generation（μCUTLASS + TTT-Discover 路线）扩展到全模型编排，本 topic 可能拆分为"手动 fusion 的生产实践"（TileRT/TokenSpeed 历史）和"自动 tile-level compiler"（新方向）两个 sub-topic。FlashAttention 系列可能独立为"attention kernel 硬件 co-design"sub-topic。

11. 参考 #

Entity	Categories	Role	Key contribution
[tilert-speed-scaling-law]	framework	主要分析目标	AOT Engine Kernel + tile pipeline + 三级特化，声称新范式
[tile-ai-tilert]	framework	代码验证	实际为 CUDAGraph + 25+ fused ops，揭示 blog-code gap
[tokenspeed]	framework	对照与补充	FSM 调度 + Placement 编译器，hybrid 路线代表
[2604.17861]	kernel	对照	Persistent kernel JIT 路线，量化 launch overhead
[2604.15379]	framework	对照	Chiplet megakernel，硬件约束驱动的持续执行
[2603.24517]	kernel	AI-augmented 对照	Agentic evolution 超越 cuDNN，单 kernel 极限上界
[2603.29010]	kernel	AI-augmented 对照	170-line DSL + SOL，model-tier substitution
[2511.08083]	kernel	跨 vendor 对照	AMD tile DSL，warp specialization 的硬件依赖性
[2205.14135]	kernel	FlashAttention 演进	IO-aware tiling + online softmax，attention kernel 基础范式
[2307.08691]	kernel	FlashAttention 演进	序列维度并行 + split-Q，A100 73% peak
[2407.08608]	kernel	FlashAttention 演进	Hopper async warp-spec + 2-stage pipelining，H100 75% peak
[2603.05451]	kernel	FlashAttention 演进	Blackwell TMEM pipeline + software exp + 2-CTA，B200 71% peak
[2512.24077]	agent	AI-augmented 对照	Directed evolutionary search，Plan-Execute-Summarize + MAP-Elites
[2601.16175]	algorithm	AI-augmented 对照	Test-time RL for kernel discovery，entropic objective + PUCT
[tile-ai-tilert]	framework	跨篇分析	Blog vs code 差距，工程表面积挑战
[tile-ai-tilert]	framework	跨篇分析	历史谱系定位——ASIC graph compile 的 GPU 复现
[2604.17861]	kernel	跨篇分析	Persistent kernel 两极对比（轻量 vs 重量）
[framework]	framework	category survey	PD 分离主线，与 graph compile 的矛盾
(外部) Habana Goya/Gaudi	hardware	历史源流	ASIC graph compile 的硬件基础，大 SRAM + 异构引擎
(外部) XLA / TVM / Glow	framework	历史源流	自动 op fusion 的上限和结构性限制