Target: 2512.22219 (MPK: A Compiler and Runtime for Mega-Kernelizing Tensor Programs)
Category: kernel · Mode A (per-paper vs 8 peers)
MPK 站在 kernel category 的一个特殊象限：它不是"写一个更快的 kernel"，而是"自动把整个模型编译成一个 kernel"。因此它与 8 篇相关论文的关系不是同台竞速，而是抽象层级的正交——它们优化 kernel 内部，MPK 优化 kernel 边界。
8 篇 peers 按与 MPK 的关系分三簇：
簇 A — 被 MPK 消费/取代的 per-operator attention kernel（FlashAttention 家族）
这四篇是 MPK 的 下游依赖：MPK 的 attention task 需要一个高性能 thread-block 级实现，而 MPK 靠 Mirage superoptimizer 生成，理论上生成的正是 FlashAttention 式 tiled kernel。SGLang/vLLM baseline 内部也正是用 FlashInfer/FlashAttention [2512.22219]，所以 MPK 的 1.0–1.7× 是"在 FA 已经打包进 baseline 之后"的额外增益。
簇 B — 低精度 attention（正交于 MPK）
簇 C — kernel 生成的"自动化"路线（与 MPK 竞争同一目标：减少手工工程）
簇 C 与 MPK 共享同一"高层痛点"——手写高性能 kernel 工程量巨大、不可规模化——但走了完全相反的路：簇 C 用 DSL/agent/搜索生成更好的单 kernel，MPK 用 compiler 消除 kernel 边界本身。这是 kernel category 内最深的分野，也是本篇 delta 的核心。
§2.1 相对 FlashAttention 家族 — 新在"边界"，不在"内部"
FA1→FA4 的整条主线都是把一个算子（attention）在单 kernel 内做到极致：FA1 消除中间物化 [2205.14135]，FA2 提并行度 [2307.08691]，FA3 用异步原语打满 Hopper [2407.08608]，FA4 应对 Blackwell 非对称 scaling [2603.05451]。它们的"融合范围"是明确划定的——softmax + matmul，不含 RoPE/QKV projection/O projection [2407.08608]。
MPK 的 delta 是把融合范围推到整个模型：不是 attention 一个 kernel，而是 attention + MatMul + AllReduce + RMSNorm + ... 全部在一个 persistent kernel 内，用 SM-level tGraph 表达跨算子依赖 [2512.22219]。FA 家族解决"kernel 内部利用率"，MPK 解决"kernel 之间 的 barrier / launch / CPU 调度开销"。二者是接力而非竞争。
关键 delta 的量化：FA 家族的收益是 kernel 级利用率（FA3 35%→75% [2407.08608]，FA4 71% [2603.05451]）；MPK 的收益是端到端延迟 1.0–1.7×，且明确说明收益来自 overhead removal 而非更高 FLOP 利用——最大增益出现在 小模型 + 新 GPU，因为此时 launch/CPU 调度开销相对计算占比最大 [2512.22219]。
§2.2 相对簇 C（HipKittens / AVO / μCUTLASS）— 同问题，反方向
三篇都承认"手写 kernel 不可规模化"这一痛点，但：
MPK 的 delta：它是这几篇里唯一改变执行模型（kernel-per-operator → mega-kernel）的，而不是在既有执行模型内把单 kernel 做得更快。换言之簇 C 优化"每个 kernel 多快"，MPK 优化"要不要有那么多 kernel"。
§2.3 相对 SageAttention2 — 完全正交、可叠加
SageAttention2 是数值维度（量化）[2411.10958]，MPK 是调度维度。无冲突：MPK 的 per-task Mirage codegen 原则上可生成量化 attention task。这是本篇唯一一个"纯增量、无竞争"的关系。
§2.4 增量 vs 真正新颖
MPK 的 idea（mega-kernel）不新——L2 明确承认 FlashDMoE、Spector et al. 已手写过 mega-kernel [2512.22219]。真正新颖的是自动化的、无间接寻址的执行 substrate：event fusion → normalization（每 task ≤1 dep/trig event）→ BFS linearization（event fan-out 编码为 [first,last]），使 in-kernel 调度只需 atomicAdd 和局部 scheduler state [2512.22219]。这是本篇的核心技术壁垒，也是与所有 peers 都不重叠的贡献。
攻击 1 — "close to hardware limits" 名不副实
MPK 声称把 LLM inference 推近硬件极限 [2512.22219]，但自报数据显示 Qwen3-8B/A100 只达 12.5 ms，而带宽 roofline 是 ~10 ms（16 GB / 1.6 TB/s）——即仍在 roofline 之上约 25%，只跑到带宽上限的 ~80% [2512.22219]。对比 FA 家族在 compute-bound 场景的 71–75% 利用率是对 compute peak 而言 [2407.08608]，MPK 的 80% 是对 bandwidth peak 而言且 regime 不同（decode memory-bound），两个"利用率"不可直接比较。"close to limits" 更应表述为"close to the bandwidth ceiling in the small-batch decode regime"。
攻击 2 — 1.0× 下界暴露适用面狭窄
1.0–1.7× 区间的下界 1.0× 意味着在大模型 / 老 GPU 上 MPK 相对 SGLang/vLLM 无增益 [2512.22219]。由于增益本质是 overhead removal，而 overhead 相对计算的占比随模型增大而趋零，MPK 的价值曲线在生产级大模型（如 70B+）上会收敛到 parity。这与 FA 家族形成对比：FA 的收益是 compute 利用率提升，在大模型上不会衰减。
攻击 3 — "deep not wide" 假设的脆弱性
normalization overhead <1% 的论据依赖"real models are deep not wide"的经验断言 [2512.22219]。但 MoE、multi-branch、speculative decoding、以及并行 expert routing 恰恰是"宽"图。MPK 自己的 MoE case study 需要专门的 hybrid balancer + fused gather-GEMM 来处理 expert 并行 [2512.22219]，间接说明"宽"结构确实带来了 normalization 之外的额外复杂度——即 <1% 的乐观数字对未来更并行的架构未必成立。
攻击 4 — 84K 行 CUDA 与"自动 compiler"叙事的张力
MPK 自称"自动 compiler，few lines of code"，但实现含 84K 行手写 CUDA runtime [2512.22219]。这与簇 C 的批评（手写 kernel 不可规模化）自相矛盾：MPK 把 per-operator 的手写工作转移成了一个巨型的、per-architecture 的手写 runtime。HipKittens 的 48 行 FP8 GEMM [2511.08083] 和 μCUTLASS 的 10–20 行 spec [2603.29010] 在"工程量可规模化"这一点上论据其实更硬。MPK 只是把壁垒从"每个算子"挪到"整个 runtime substrate"。
攻击 5 — 与 FA4 的可移植性对撞
FA4 的核心优化（TMEM pipeline、2-CTA MMA）是 Blackwell-specific，不可移植 [2603.05451]；MPK 声称 graph-level machinery 架构中立、只有 gather-GEMM 和 NVSHMEM 需要重写 [2512.22219]。但 MPK 的 per-task 代码由 Mirage 生成，而要在 B200 上达到 FA4 级别的 attention task 性能，Mirage 必须重现 FA4 的 TMEM/软件-exp 技巧——这些正是 FA4 花数月人工调优（AVO 又花 7 天进化才小幅超越 [2603.24517]）才得到的。MPK 的"架构中立"只对调度层成立，对 per-task 峰值性能不成立：它把最难的部分外包给了 Mirage superoptimizer，而 Mirage 能否自动追平人类/agent 数月的调优成果，本篇没有证据。
范式定位：kernel category 存在一条隐含的抽象阶梯——
MPK 是这条阶梯上唯一到达第 4 级的。它是 mega-kernel 从"手工艺"（FlashDMoE、Spector）迈向"编译产物"的第一步——类比 TVM/Halide 之于手写 kernel，MPK 之于手写 mega-kernel。
范式转移是否真实发生：证据有限但明确——
github.com/mirage-project/mirage；作者阵容与 Mirage/TVM/FlashInfer 生态高度重叠（Tianqi Chen、Zhihao Jia、Zihao Ye 等），说明有生态承接能力 [2512.22219]。采用摩擦：MPK 要求整条 pipeline（含 continuous batching、paged attention、page allocation、request scheduling）都搬进 mega-kernel [2512.22219]，这是重量级的架构承诺；而 FA/SageAttention 是 drop-in 替换 [2411.10958]。生态位上 MPK 属于"高天花板、高迁移成本"，FA 属于"稳态、低摩擦"——短期内 MPK 更可能作为 latency-critical 小模型 serving 的专用后端存在，而非通用替代。
方向 1 — MPK × SageAttention2（融合层 × 量化层）
MPK 的 per-task Mirage codegen 目前只生成 bf16 task [2512.22219]，而 SageAttention2 的 INT4/FP8 attention 与 MPK 完全正交 [2411.10958]。让 Mirage 生成 SageAttention 风格的量化 attention task，即可在"消除 launch/barrier 开销"之上叠加"低精度 tensor core 吞吐"——两个正交增益相乘。目前无人做，技术上只需 Mirage backend 支持量化 codegen。
方向 2 — MPK × FA4 pipeline 技巧的 per-task 移植
MPK 的 attention task 若要在 Blackwell 上不落后，需把 FA4 的 TMEM pipeline / 软件 exp / conditional rescaling [2603.05451] 编码进 Mirage 的 thread-block 搜索空间。这是"把手工调优的 pipeline 知识蒸馏进 superoptimizer"的方向——AVO 已证明 agent 能在 7 天内进化出这些优化 [2603.24517]，理论上可用 AVO/agentic 搜索为 MPK 的每个 task 生成 Blackwell-optimal 实现，把"MPK 自动融合"与"AVO 自动调优 per-task"两层自动化拼接。
方向 3 — MPK 移植到 AMD（graph substrate × HipKittens per-task）
MPK 的图层机制架构中立，卡点在 TMA-gather-GEMM 和 NVSHMEM [2512.22219]。HipKittens 已提供 CDNA4 上匹配汇编的 GEMM/attention primitive 和 buffer_load/LDS/8-wave 调度 [2511.08083]。用 HipKittens 作为 MPK 在 AMD 上的 per-task 后端（替代 Mirage 的 NVIDIA codegen），加 RCCL/ROCm-SHMEM 替代 NVSHMEM，是把 mega-kernel 范式带到 MI355X 的最短路径。MPK 自己也把这归为"Mirage-backend 问题而非 MPK-runtime 问题" [2512.22219]，HipKittens 恰好是那个 backend。
方向 4 — SOL/roofline 引导 MPK 的调度决策
MPK 的 JIT/AOT 分类目前是启发式（data-dependent 算子标 JIT，其余 AOT [2512.22219]），scheduler warp 数固定为 16。μCUTLASS 的 SOL gap 信号 $g=t_{best}/t_{SOL}$ [2603.29010] 可用于动态决定 worker/scheduler 划分和 JIT/AOT 比例——当某 tGraph 段远离 roofline 时增派 worker，接近时省 scheduler。把 SOL headroom 从"agent 预算调度"迁移到"in-kernel 资源划分"是尚未探索的组合。
方向 5 — adaptive normalization（应对"宽"图）
"deep not wide" 假设 [2512.22219] 在 MoE / 并行 expert / multi-branch 上会失效。一个自适应方向：对"宽"子图不做全量 normalization（避免 empty-task 爆炸），而是对高 fan-out event 保留变长元数据 + 局部间接寻址，只对"深"主干做 [first,last] 编码——即混合表示，按子图宽度切换编码策略。这直接针对攻击 3 的脆弱点，技术上可解。
2512.22219 (self) — L1: knowledge/L1/paper/2512.22219.md · L2: knowledge/L2/paper/2512.22219.md2205.14135 FlashAttention — [2205.14135]2307.08691 FlashAttention-2 — [2307.08691]2407.08608 FlashAttention-3 — [2407.08608]2411.10958 SageAttention2 — [2411.10958]2511.08083 HipKittens — [2511.08083]2603.05451 FlashAttention-4 — [2603.05451]2603.24517 AVO — [2603.24517]2603.29010 μCUTLASS + SOL — [2603.29010]