AutoKernel: Autonomous GPU Kernel Optimization via Iterative Agent-Driven Search

arXiv ID: 2603.21331 | 日期: 2026-03 | 作者单位: RightNow AI | 重新解读: ✅

---

1. 一句话定位

GPU kernel 自动优化方向，单 agent 简单 keep/revert 循环 + Amdahl 排序 + 五阶段正确性验证，在 H100 上对 RMSNorm/softmax/cross-entropy 等 memory-bound kernel 取得 2–5× 相对 PyTorch eager 的加速。

2. TL;DR

• 架构极简：一个 agent 改一个文件 → 固定 benchmark 评估 → keep 或 revert，每轮 ~90s，每晚跑 300–400 次实验。论文核心论点是简单循环胜过复杂多 agent 框架。
• Amdahl 排序：先 profile 完整 PyTorch 模型，按端到端性能影响排序 kernel，把优化算力花在瓶颈上——这与 KernelBench 把 250 个 kernel 当独立问题看形成鲜明对比。
• 五阶段正确性门禁：smoke test → shape sweep（10+ 配置 × 3 dtype）→ numerical stability（对抗输入）→ determinism（3 次 bitwise 一致）→ edge case（非 2 的幂维度）；任一失败立即 reject，避免 benchmark gaming。
• 双后端：Triton（高层 DSL，1–5s 编译，适合快速迭代）+ CUDA C++（WMMA、warp shuffle、bank-conflict-free smem，触及 cuBLAS/CUTLASS 天花板），两者暴露同一 kernel_fn() 接口。
• 六层优化 playbook：把"专家经验"编码成 agent 可读的 markdown 文档，从 block size tuning → memory access → compute fusion → advanced（split-K、persistent）→ architecture-specific（TMA/WGMMA/cp.async）→ kernel-specific（online softmax、Welford）。
• memory-bound 强、compute-bound 弱：RMSNorm 5.29× vs eager / 2.83× vs torch.compile，cross-entropy 2.21×/2.94×，softmax 2.82×/3.44×；matmul 打不过 cuBLAS（starter 278 TFLOPS vs cuBLAS 800+ TFLOPS，~28% 峰值）。
• 开源 + 实战：GitHub 已开源（RightNow-AI/autokernel），社区用其在 B200 vectorsum_v2 leaderboard 上第一名，并产生了一个 3 分钟 single-prompt Triton FP4 matmul 超过 CUTLASS 1.63–2.15× 的案例。

3. 问题与动机

3.1 痛点场景

Transformer 模型在 GPU 上跑时，60–80% 时间花在 matmul（attention/FFN），剩下大部分是 normalization / softmax / 位置编码。vendor 库（cuBLAS、cuDNN）覆盖常规算子，但跟不上架构创新：grouped-query attention、SwiGLU、RMSNorm、rotary position embeddings 先在生产模型中部署，库支持数月后才跟进。

写一个 matmul kernel 需要数周专家调优：要懂 roofline、内存 coalescing、shared memory bank conflict、register pressure、tile size 与 L2 交互、warp 同步、tensor core 指令选择。一个 matmul kernel 可能 200+ 行代码、几十个相互依赖的超参数——这种专家稀缺，且调优过程不可扩展。

3.2 现有方法为什么不够（带具体方法名）

类别	代表方法	核心缺陷
基准评测	KernelBench (Ouyang et al. 2025)	只评估不优化；250 个问题独立看，不看端到端影响
多 agent 框架	GEAK, Astra, KernelSkill	多个 planner/coder/reviewer 协调 → 协调开销、共识延迟、单点失败
进化搜索	KernelFoundry (MAP-Elites), GPU Kernel Scientist	质量-多样性搜索 + meta-prompt evolution；耗时长，但不知道何时停止
硬件反馈 loop	CudaForge (coder + judge)	依赖 profiler 反馈，但对整个模型视角缺失
强化学习	CUDA-L1 (对比 RL), CUDA Agent (agentic RL)	需要大量训练数据 + GPU 时间；ICLR 2026 3.12× avg vs CUDA Agent 100% faster-than-torch.compile on L1/L2——但都是单 kernel 优化，无 Amdahl 视角
专家手工	FlashAttention-3, CUTLASS	性能天花板，但专家稀缺、不可扩展，且新算子永远赶不上模型创新

3.3 核心 insight

"Optimize what matters. Profile the whole model, rank kernels by Amdahl's law impact, then put the agent loop on the bottleneck." — §1

两个子论点：

1. 简单循环胜过复杂架构：expert kernel engineer 的工作流本身就是 write→benchmark→refine 循环，机械化这个循环比设计多 agent 系统更鲁棒——参考 Karpathy autoresearch 在 LLM training code 上的成功（700 实验 2 天找到 20 个优化）。
2. kernel 选择遵循 Amdahl：60% 占比的 kernel 拿到 1.5× 加速，端到端 1.25×；5% 占比的同样 1.5× 只能 1.03×。算力分配的优先级 = 端到端影响，不是 raw speedup。

核心论断：在 LLM-based kernel 生成赛道里，AutoKernel 的赢面不在 agent 复杂度，而在端到端视角 + 工程化简单性。

4. 方法详解

4.1 架构总览

图 1：AutoKernel 三阶段架构。Phase A：profile PyTorch model + 提取 bottleneck kernels；Phase B：核心 agent 循环（edit → 5-stage benchmark → keep/revert），~40 iter/hour，300+ per run；Phase C：end-to-end 验证。蓝色=Phase A、橙色=Phase B loop、绿色=Phase C。Figure 1 of paper.

:::

4.2 Phase A：模型 profiling 与 kernel 提取

Profiler（profile.py，1,125 行）接受本地 Python 文件、HuggingFace 模型 ID 或自定义模型类，用 torch.profiler + shape recording 捕获 per-kernel GPU 时间。支持 9 类 operation（matmul / flash_attn / fused_mlp / softmax / layernorm / rmsnorm / cross_ent / rotary_emb / reduce），通过模式匹配 CUDA kernel 名称分类——cuBLAS GEMM、CUTLASS、Triton-compiled、ATen 各自有独立的命名模式。

GPU 检测覆盖 NVIDIA（H100/A100/L40S/L4/A10/RTX 4090/4080/3090/3080）和 AMD（MI300X/MI325X/MI350X/MI355X），未知 GPU 用 SM 数 × 时钟 × compute capability 估算峰值 FP16 吞吐。AMD GPU 检测走 gcnArchName（ROCm 行为）。

Extractor（extract.py，648 行）过滤 supported operation，生成 standalone kernel 文件，包含：

• starter implementation
• 三种 shape variant（primary / half-scale / double-scale）
• FLOPS + bytes 公式（用于 roofline 计算）
• dtype-specific tolerances

按 Amdahl's law impact 排序，并生成 1.5×/2×/3×/5× 速度下的端到端 what-if 预测。

4.3 Phase B：核心 agent 循环

Agent 的核心是 Algorithm 1：

$$ k_{\text{best}}, t_{\text{best}} \leftarrow k, B(k) $$ $$ \forall i: \quad k' \leftarrow A.\text{edit}(k_{\text{best}}, \text{history}, \text{roofline}) $$ $$ (\text{pass}, t') \leftarrow B(k') $$ $$ \text{if } \text{pass} \land t' > 1.01 \cdot t_{\text{best}}: \quad k_{\text{best}} \leftarrow k' \quad \text{(keep)} $$ $$ \text{else}: \quad \texttt{git reset --hard HEAD\textasciitilde 1} \quad \text{(revert)} $$

关键设计决策：

• 单文件不变性：agent 只改一个文件 → diff 小、revert 干净、regression 易定位。
• 固定 evaluator + 可变 code：benchmark 不被 agent 改 → 防止 gaming（candidate generator 同时控制 scorer 是真实风险）。
• Git as experiment tracking：每次实验对应一个 commit；keep 推进 branch，revert 用 git reset 抹掉。
• 90s/iter 时序分配：30s 正确性 + 30s triton.do_bench 性能 + 30s agent 推理与代码生成。
• 1% 阈值：保留需要 >1.01× 加速，避免噪声。

4.4 六层优化 playbook（program.md，909 行）

Tier	名称	预期加速	关键技巧
1	Block size tuning	10–50%	powers of 2 扫描 tile 维度、rectangular tile、num_warps、num_stages
2	Memory access	10–30%	coalesced load、software prefetch、L2 swizzling、shared memory padding
3	Compute	5–15%	TF32 累加、epilogue fusion、loop invariant hoisting
4	Advanced	5–20%	split-K、persistent kernel、Triton autotune、warp specialization
5	Architecture-specific	5–15%	Hopper TMA、Ampere cp.async、L4/RTX 调整大小
6	Kernel-specific	varies	online softmax（attention）、Welford（norm）、split-K（tall-skinny matmul）

表 1：六层优化 playbook 的预期加速区间。注意 Tier 1 已经能拿到 50% 加速——block size 是最便宜的优化空间。

4.5 Multi-Kernel Orchestration：Amdahl's Law

$$ S = \frac{1}{(1 - f) + f/s} $$

其中 $f$ 是 kernel 占总 GPU 时间比例，$s$ 是该 kernel 的加速比。

Move-on 判据（任一触发即停止当前 kernel）：

1. 连续 5 次 revert
2. 达到 GPU 峰值 90%
3. 已用 2 小时
4. 已达到 2× 加速

设计动机：避免 agent 在收益递减的 kernel 上浪费实验预算；让系统自动在"易优化"和"高影响"之间切换。

4.6 五阶段正确性验证

图 2：五阶段 correctness pipeline。任何失败立即 REJECT；仅当全部通过后才进入 Benchmark 测吞吐。Figure 2 of paper.

:::

Stage	内容	时间	抓的 bug 类
1. Smoke test	单个 small input（$128 \times 128$）	<1s	编译错误、shape mismatch、明显数值 bug
2. Shape sweep	8–10 配置 × 3 dtype（FP16/BF16/FP32）	varies	size-dependent bug、tile remainder、dtype 特异问题
3. Numerical stability	对抗输入（overflow、underflow、near-zero variance）	varies	FP edge case
4. Determinism	同输入 3 次，bitwise identical	varies	parallel reduction race condition、非确定性 atomic
5. Edge case	非 2 的幂维度（1023、4097、1537）	varies	masking bug、tile remainder

Tolerances：FP16 用 $\text{atol} = 10^{-2}$，BF16 用 $2 \times 10^{-2}$，FP32 用 $10^{-4}$。

4.7 Dual Backend：Triton + CUDA C++

	Triton	CUDA C++
抽象层	Python-like DSL，tile 级	显式 thread/warp/CTA
编译时间	1–5s（JIT）	较慢（load_inline + hash cache）
可达性能	80–95% cuBLAS matmul	cuBLAS/CUTLASS 级
能改的旋钮	block size、warps、stages、accumulator precision、loop	WMMA API、__shfl_xor_sync、float4/half2、bank-conflict-free smem、double buffering、__launch_bounds__
架构支持	自动	显式 cp.async、TMA、WGMMA

两者暴露同一 kernel_fn() 接口，benchmark 完全一致——agent 不用关心后端。

4.8 Kernel Coverage

9 种 kernel 类型（表 2）覆盖 transformer 主要算子：

Kernel	Regime	Metric	Starter 技巧
matmul	Compute	TFLOPS	$128 \times 128$ tile、WMMA、double-buffered smem
flash_attn	Compute	TFLOPS	tiled online softmax、causal masking
fused_mlp	Compute	TFLOPS	SwiGLU gate-up fusion
softmax	Memory	GB/s	warp-shuffle reduction、half2 load
layernorm	Memory	GB/s	Welford single-pass、float4 load
rmsnorm	Memory	GB/s	warp shuffle cascade、fast rsqrt
cross_ent	Memory	GB/s	online log-sum-exp、fused NLL
rotary_emb	Memory	GB/s	interleaved rotation、sincosf
reduce	Memory	GB/s	hierarchical warp shuffle

表 2：9 种 kernel 类型的性能 regime 与 starter 实现技巧。Memory-bound kernel 占 6/9——这解释了为什么 AutoKernel 在 RMSNorm/softmax/cross-entropy 上赢面大。

每个 kernel 有 PyTorch reference（reference.py）作为 correctness oracle。系统自带 4 个 self-contained 模型（GPT-2 124M、LLaMA 160M/7B、BERT-base 110M、custom template）——无需 transformers 依赖。

4.9 关键超参与训练开销

不需要训练——这是 agent-driven 而非 learned 系统。算力开销 = 实验次数 × 单次成本：

项目	数量
Python 代码	9,200+ 行（14 个核心脚本）
起始 kernel	18（9 Triton + 9 CUDA C++）
Agent 指令	909 行 program.md
每次 iter	~90s（30s correctness + 30s benchmark + 30s agent reasoning）
每晚跑实验	300–400
单 GPU	1× H100 80GB HBM3（132 SM，compute capability 9.0，CUDA 12.8）
实验总 wall-clock	<10 min 跑完 7 kernel × 34 配置 benchmark

5. 实验结果

5.1 主结果表（H100 FP16）

表 3：H100 上 FP16 性能对比。三基线：PyTorch eager、torch.compile (max-autotune)、AutoKernel Triton starter。展示 16/34 配置（其余全部通过 correctness）。完整跑 <10 min。

$2048^3$ $4096^3$ $8192^3$ $4096^2$ $8192^2$ $4096 \times 5120$ $8192 \times 4096$ $4096^2$ $8192 \times 4096$ $8192^2$ $4096 \times 32k$ $8192 \times 32k$ $8192^2$ $16384 \times 4096$ $2 \times 32 \times 2k \times 128$ $2 \times 32 \times 4k \times 128$

Kernel	Size	Eager (μs)	Compiled (μs)	Ours (μs)	vs Eager	vs Compiled	Thru.
matmul	28.1	101.2	65.3	0.43×	1.55×	263 TF/s
matmul	182.8	257.8	494.2	0.37×	0.52×	278 TF/s
matmul	1679.5	1916.1	5773.1	0.29×	0.33×	190 TF/s
softmax	58.9	96.1	40.1	1.47×	2.40×	1675 GB/s
softmax	270.4	330.0	95.9	2.82×	3.44×	2800 GB/s
layernorm	45.6	105.5	42.5	1.07×	2.48×	1974 GB/s
layernorm	64.7	166.8	51.9	1.25×	3.21×	2586 GB/s
rmsnorm	142.8	99.9	39.1	3.65×	2.56×	1716 GB/s
rmsnorm	262.4	138.1	51.2	5.12×	2.70×	2619 GB/s
rmsnorm	509.6	272.1	96.3	5.29×	2.83×	2788 GB/s
cross_ent	295.6	386.3	134.9	2.19×	2.86×	1943 GB/s
cross_ent	559.7	745.1	253.3	2.21×	2.94×	2070 GB/s
reduce	60.7	185.2	62.2	0.98×	2.98×	2156 GB/s
reduce	50.4	185.9	52.8	0.95×	3.52×	2542 GB/s
rotary	211.4	106.9	117.4	1.80×	0.91×	576 GB/s
rotary	394.9	136.0	223.0	1.77×	0.61×	607 GB/s

5.2 核心发现

1. Memory-bound kernel 拿到最大加速：RMSNorm $8192^2$ 达 2,788 GB/s（H100 峰值的 83%），5.29× vs eager / 2.83× vs torch.compile。Cross-entropy 2,070 GB/s，softmax 2,800 GB/s。赢面来自融合 ATen 多 op decomposition 成 single-pass Triton kernel，最小化 HBM 流量。

2. 对 torch.compile 12/16 胜出：尽管 torch.compile max-autotune 也跑自己的 Triton autotuning，TorchInductor 的通用 fusion + autotuning 不总能找到 kernel-specific 的专用 tiling 和 reduction 策略。

3. Matmul 是硬骨头：PyTorch 的 cuBLAS 后端按 GPU 架构深度调优。AutoKernel Triton starter 达 278 TFLOPS（H100 989.5 TFLOPS 峰值的 28%），远低于 cuBLAS。但在 $2048^3$ 大小下仍比 torch.compile 快 1.55×——证明 TorchInductor 的 matmul autotuning 也不总是最优。

4. 正确性 100%：34 配置全部通过五阶段验证，零失败。

5.3 社区部署结果

B200 vectorsum_v2 leaderboard 第一名：latency 44.086 μs，vs 第二名 44.249 μs / 第三名 46.553 μs。一晚跑出来的优化探索了 block size、warp-level shuffle reduction、vectorized memory access。

Triton FP4 matmul vs CUTLASS：单个 3 分钟 prompt 产出的 Triton FP4 matmul kernel 超过 CUTLASS fused kernel 1.63–2.15×，最高达 2,898 TFLOPS（$2048 \times 18432 \times 3072$）。

$128 \times 3072 \times 3072$ $128 \times 18432 \times 3072$ $1024 \times 3072 \times 3072$ $1024 \times 18432 \times 3072$ $2048 \times 3072 \times 3072$ $2048 \times 18432 \times 3072$ $4096 \times 3072 \times 3072$

Shape (M×N×K)	Triton (TF/s, ms)	CUTLASS (TF/s, ms)	Speedup
186 TF, 0.013	100 TF, 0.024	1.86×
1105 TF, 0.013	550 TF, 0.026	2.01×
1477 TF, 0.013	686 TF, 0.028	2.15×
2777 TF, 0.042	1609 TF, 0.072	1.73×
1662 TF, 0.023	964 TF, 0.040	1.72×
2898 TF, 0.080	1777 TF, 0.130	1.63×
2443 TF, 0.032	1405 TF, 0.055	1.74×

表 4：社区报告 FP4 matmul 结果（H100）——AutoKernel Triton kernel（3 分钟 single prompt 生成）vs CUTLASS fused baseline。值得注意：Triton kernel 超过手工优化 C++ 模板代码。

5.4 优化循环动态（基于 playbook）

典型 memory-bound kernel（如 RMSNorm）的轨迹：

1. Tier 1（block size）：扫 BLOCK_SIZE 256→4096，前 5–10 实验拿 10–30%。
2. Tier 2（memory）：向量化 load + coalescing 修复，再 10–20 实验加 10–20%。
3. Tier 3（compute）：epilogue 融合 weight multiplication，省一次 global memory round-trip，5–10%。
4. Plateau：30–50 实验后，连续 revert 增加，接近硬件极限，orchestrator 触发 move-on。

典型 compute-bound kernel（如 matmul）的轨迹：Tier 1 影响更大（278 TFLOPS vs cuBLAS 800+ TFLOPS 差距很大），但每次改进需要更多实验，因为 tile 维度、warp 数、pipeline stage、accumulator precision 的搜索空间更大。

Amdahl 示例：matmul 占 62% GPU 时间，RMSNorm 占 5%。matmul 即使只 1.3× 改进，端到端贡献也超过 RMSNorm 已经 5.29×。

6. 横向对比

6.1 与代表性工作的对比

维度	AutoKernel	KernelBench	GEAK	CudaForge	CUDA-L1	CUDA Agent	KernelSkill
方法	单 agent keep/revert 循环	静态评测	多 agent（Triton）	Coder + Judge	SFT + 对比 RL	Agentic RL	多 agent + dual-level memory
后端	Triton + CUDA C++	Multi-DSL	Triton	CUDA	CUDA	CUDA	CUDA
Model-level profiling	✅	❌	❌	❌	❌	❌	❌
Iterative	✅	❌	✅	✅	✅	✅	✅
开源	✅	✅	✅	✅	✅（ICLR 2026）	—	—
Hardware 覆盖	H100/A100/L40S/L4/RTX/MI300X 系列	多	AMD	NVIDIA	NVIDIA	NVIDIA	NVIDIA
平均加速	2–5×（memory-bound）	—	—	—	3.12× avg	100% L1/L2 faster	5.44× L1
正确性验证	5-stage 门禁	单一对比	—	—	—	—	—
Amdahl 排序	✅	❌	❌	❌	❌	❌	❌
KernelBench 集成	✅	本身	—	—	—	—	—

表 5：AutoKernel 与 6 个代表性工作的对比。AutoKernel 唯一同时具备 model-level profiling + 双 backend + iterative + open-source。

6.2 定位总结

AutoKernel 在 KernelBench / GEAK / CudaForge / CUDA-L1 / CUDA Agent / KernelSkill 主导的"LLM 写 kernel"赛道里，处于"换了赛道的破局者 + 工程化落地版"的位置：

• 不是同一赛道的 SOTA：KernelBench/CUDA-L1 在"kernel 上拿平均加速"上更强（CUDA-L1 3.12× avg、CUDA Agent 100% faster-than-torch.compile L1/L2）。
• 换了赛道：AutoKernel 不和他们在"独立 kernel 优化"上竞争，转向完整 PyTorch 模型的端到端优化——这是绝大多数真实部署场景。
• 工程化落地版：9000+ 行 Python 全开源、KernelBench bridge、HuggingFace Kernels 导出、B200 leaderboard 第一、单 prompt FP4 matmul 超过 CUTLASS——这是"能用"的系统，不是"评分高"的 demo。

与 FlashInfer-Bench 的对比视角（重要）：

• FlashInfer-Bench：标准化评测 + 闭环部署（评测驱动）
• AutoKernel：单 agent 循环 + 实战部署（agent 驱动）
• 两者解决同一问题（LLM 生成 kernel），思路不同：
  • FlashInfer-Bench 面向评测生态——"如何公平评估 LLM 生成的 kernel"
  • AutoKernel 面向生产部署——"如何用 LLM 持续优化真实模型"
• 互补大于竞争：AutoKernel 的优化结果可以提交到 FlashInfer-Bench 评估；FlashInfer-Bench 的评测结果可以指导 AutoKernel 选哪些 kernel 优先优化。

6.3 与 Karpathy autoresearch 的对比

"AutoKernel transplants autoresearch's keep/revert loop to kernel code: the search space becomes the space of possible kernel implementations, and the evaluation function is a correctness-gated benchmark rather than validation loss." — §1

维度	Karpathy autoresearch	AutoKernel
搜索空间	LLM 训练代码（630 行训练脚本）	GPU kernel 实现（Triton/CUDA）
评估函数	5 分钟 validation loss	30s correctness + 30s benchmark
运行规模	700 实验 / 2 天 / 单 GPU	300–400 实验 / 10 小时 / 单 GPU
发现优化数	20+ 训练优化	论文未具体数（仅"hundreds of experiments"）
应用领域	LLM 训练	GPU kernel

洞察：autoresearch 是 AutoKernel 的方法论原型。简单循环 + 固定 evaluator + keep/revert 在不同领域都能 work——这本身是个可迁移的 agent 设计模式。

7. 批判性局限性

7.1 LLM 选择未披露（影响可复现性）

问题陈述：论文用"an LLM agent"指代 agent backend，未透露使用哪个模型（GPT-4? Claude? Gemini?）。社区 leaderboard 结果和 CUTLASS-超过案例都是闭源 LLM + 闭源 prompt生成的，无法独立验证。对比基线 KernelBench/GEAK 论文都明确指定 LLM。

证据：abstract + §3.3 都写"the agent"而非具体模型名；GitHub README 应该有但论文没引用。

影响范围：所有"x × vs y"的 speedup 数字都依赖未披露的 LLM；单 prompt FP4 matmul 超 CUTLASS 的结果无法在 2026 年的模型下复现。

7.2 "几百次实验"的成本不透明（影响经济性）

问题陈述：论文说"300 to 400 experiments across multiple kernels" per overnight run，但未公开：总实验次数、单次成本（GPU 小时）、总 API 成本（LLM 调用）、与基线对比的算力开销（vs FlashInfer-Bench 静态评测 / vs cuBLAS 手工调优）。

证据：§3.3 只说"overnight run produces 300 to 400 experiments"；没有成本分析、cost-per-speedup-point、没有与 expert 调优时间的对比。

影响范围：无法判断 AutoKernel 是"工程上经济"还是"research toy"；与 CUDA-L1 的"训练一次"相比，AutoKernel 每模型都要从头跑。

7.3 5.29× speedup 局限在 memory-bound kernel（影响方法有效性）

问题陈述：RMSNorm 5.29× vs eager 是真实加速，但这个赢面是因为 PyTorch 的 RMSNorm 实现没有充分融合——同一论文中 matmul 输给 cuBLAS 3×（0.29× vs eager），说明 starter kernel 没有超越高度优化的 vendor 库。论文承认"Matmul remains hard"（§6.3）。

证据：表 3 matmul 行 $4096^3$/$8192^3$ 显示 starter 0.37×/0.29× vs eager，0.52×/0.33× vs torch.compile。

影响范围：对于已经是 compute-bound 且被 vendor 库覆盖的 kernel（matmul、conv、attention），AutoKernel 当前不赢。在生产模型中 matmul 占 60–80% GPU 时间——这意味着 AutoKernel 优化的是次要 20–40%，端到端加速受 Amdahl 约束。

7.4 无跨硬件泛化（H100 only 实验）

问题陈述：所有实验在 H100 80GB HBM3 单 GPU 上做，CUDA 12.8，FP16 精度。没有 B100/RTX 5090/AMD MI300X 的对比数据——尽管 profiler 支持检测这些 GPU，但优化 playbook 的六层策略没有在多硬件上验证。

证据：§6 仅说"on an NVIDIA H100"，表 3 全部用 H100 数据；社区 leaderboard（B200）只是 vectorsum_v2 一个例子，未系统对比 AutoKernel 在不同 GPU 上的性能。

影响范围：不同 GPU 架构（H100 vs A100 vs MI300X）需要不同的 tier 5 (architecture-specific) 策略；agent 是否能跨硬件自适应，论文未给证据。

7.5 与学术工作（AlphaTensor、KernelBench）的边界模糊

问题陈述：论文没有明确和 AlphaTensor（DeepMind 2022，RL 发现新 matmul 算法）做对比——AlphaTensor 在小矩阵上发现过超越人类专家的算法，AutoKernel 是否能在 $4096^3$ 这种大矩阵上超越 cuBLAS？论文没有正面回答。

证据：§2 只比较 LLM-based kernel 系统，没和 AlphaTensor、PolyBench 等更基础的算子发现工作做对比。

影响范围：AutoKernel 主要是工程化系统，不是新算法发现——这是合理选择，但学术 novelty 上不如 AlphaTensor。

7.6 单文件不变性约束可能限制优化空间（设计局限）

问题陈述："Single-file invariant" 让 agent 只改一个文件，但某些跨 kernel 优化（如 matmul + residual fusion）需要改多个文件。论文承认"Complex techniques like software pipelining, custom PTX emission, and multi-CTA cooperative strategies may exceed current agent abilities"（§10 Limitations）。

证据：§3.3 "Single-file invariant" 段；§10 限制承认复杂技术超出当前 agent 能力。

影响范围：单文件不变性是工程便利，但可能错过跨 kernel 融合机会——这是 FlashAttention 成功的关键（fuse attention 全流程）。

8. 可复用启发 / 关键 takeaway

8.1 给"做 LLM agent 系统"的人

简单循环胜过复杂架构——一个 keep/revert loop 在 LLM training 上 work（Karpathy autoresearch），在 GPU kernel 上 work（AutoKernel）。不要默认上多 agent 框架。当任务可以机械化一个专家工作流时，单 agent + 固定 evaluator 通常更鲁棒、更易调试、更经济。

8.2 给"做 GPU kernel 优化"的人

先 profile 再优化——AutoKernel 的 Amdahl 排序是最便宜的优化决策：让端到端影响驱动 kernel 选择，而不是"哪个 kernel 听起来 cool"。这同样适用于人做 kernel 调优：先看 torch.profiler 再决定优化哪个 kernel。

8.3 给"做正确性验证"的人

五阶段门禁的工程价值——smoke test → shape sweep → numerical stability → determinism → edge case 这种分层验证是 "防止 benchmark gaming"的标准模板。任何 LLM-based 代码生成系统都应该有等价物。关键不是正确性 100%，而是"通过五阶段 = 性能可比较"。

8.4 给"做 benchmark"的人

单一基线不够——AutoKernel 同时比 PyTorch eager 和 torch.compile max-autotune。因为 PyTorch 和 torch.compile 在不同 kernel 上赢面不同——在 RMSNorm/softmax/cross-entropy 上 AutoKernel 赢 eager 但 torch.compile 也接近 cuBLAS 水平。单一 baseline 会误导。

8.5 给"做工程化研究"的人

可复现性 > 新颖性——论文未透露 LLM、未公开实验次数、未公开成本。对照：FlashAttention-3 论文明确写了硬件配置和测试协议。AutoKernel 的"3 分钟单 prompt 超 CUTLASS"案例很震撼但无法独立验证——这是论文最大的可复现性短板。

8.6 给"做端到端优化"的人

优化的是系统，不是单点——AutoKernel 的核心 insight 是优化完整 PyTorch 模型的 kernel而不是独立的 kernel benchmark。这与绝大多数 LLM-kernel 工作（KernelBench、CUDA-L1、CUDA Agent）形成鲜明对比。端到端视角让 AutoKernel 在生产部署中更有价值，但在学术 novelty 上吃亏。

---

附录：报告自检

• 章节数：8（符合 v5.0 模板）
• 公式数：5+（Amdahl's law、决策阈值、迭代次数估算、tolerances、$S$ 表达式）
• 表格数：7（六大方法对比表、playbook 表、kernel coverage 表、主结果表、社区 FP4 结果表、相关工作对比表、autoresearch 对比表）
• 横向对比方法数：6+（KernelBench、GEAK、CudaForge、CUDA-L1、CUDA Agent、KernelSkill、Karpathy autoresearch、FlashInfer-Bench）
• 局限性条数：6（LLM 选择未披露、成本不透明、memory-bound only、无跨硬件、与 AlphaTensor 边界模糊、单文件不变性约束）
• 关键图引用：2（图 1 架构、图 2 五阶段正确性）