Towards Automated Kernel Generation in the Era of LLMs：把 GPU kernel 自动生成从一次性代码补全推进到「LLM + Agent + 反馈闭环」的综述

关联论文：2601.15727
作者：flyP
更新：2026-07-07

一句话结论

这是一篇 IJCAI 2026 综述（9 页正文 + 持续维护的 GitHub 资源库 flagos-ai/awesome-LLM-driven-kernel-generation），把过去两年 LLM 与 Agent 驱动的 GPU kernel 自动生成 / 优化研究系统化为两条主线——LLM 直出（监督微调与强化学习） 与 Agent 闭环（迭代反馈、多智能体、记忆与硬件 profiling 整合）——并配套整理了训练数据集与 benchmark 资源；它本身不提出新算法，但给出了一个足够清晰的分类坐标，让「LLM 写 CUDA 还能再往哪儿走」第一次有了可对照的地图。

解决什么真问题

现代 AI 系统在 GPU / NPU 上跑得多快，主要不取决于硬件峰值 FLOPS，而取决于底层 kernel（GEMM、attention、convolution、sparse ops 等）能不能榨干硬件。现代 kernel 工程的痛点有三个：

专家知识门槛高：要写出接近 cuBLAS 性能的 kernel 需要精通硬件架构、内存层级、warp 调度等细节，工程师稀缺。
不可扩展：同一份优化往往绑死特定 GPU 代次 / 厂商，换硬件就要重写。
编译器自动调优受限：Halide / TVM / Ansor 这类 schedule-based autotuning 虽然能搜，但搜索空间、调度原语、优化先验都是人写的，覆盖不了真正的「开放空间」。

LLM 的出现带来了新的可能性：它能「压缩」大量散落在 GitHub、技术博客、教科书里的硬件感知编程知识；Agent 又能把 kernel 开发重写成迭代、反馈驱动的循环，从而做到 fatigue-free 的长视野探索。这正是综述要回答的核心问题：这个新范式目前长什么样？哪些方法属于哪一类？还有哪些没解决的问题？

核心方法 / 分类框架

综述的核心贡献是分类法，而不是单一算法。下面是论文使用的两层切分。

第一层：LLM 直出（Section 3）—— 把 LLM 本身调成 kernel 专家

包含两类后训练（post-training）方法：

1. Supervised Fine-Tuning（SFT）

KernelLLM：用 Triton 编译器生成 PyTorch–Triton 对齐样本，通过结构化 prompt 把计算语义与 kernel 结构显式编码，做指令微调。
ConCuR：认为推理 trace 的结构与清晰度强烈影响 kernel 正确性与性能，于是对 reasoning traces 做高质量筛选与整理；得到的 KernelCoder 在 KernelBench Level 1 上达到 fast1 = 17%。
InCoder-32B：面向工业软件需求做三阶段数据流水线（pre-training → mid-training → post-training），fast1 = 22.2%。

SFT 的共同模式是「先造一份计算语义 ↔ kernel 实现的对齐数据，再用结构化 prompt / 推理 trace 增强质量」。门槛在于数据生成与筛选成本。

2. Reinforcement Learning（RL）

CUDA 方向：Kevin Baronio 等用 multi-turn 优化 + 跨轮 reward 归因；CUDA-L1 用 contrastive RL + LLM-as-a-judge 做密集反馈；CUDA-L2 在它之上声称在评测 workload 上超过 cuBLAS；SparseRL 专注稀疏矩阵 kernel。
Triton 方向：AutoTriton 用结构化评估 + 执行 runtime reward 缓解奖励稀疏；TritonRL 做 hierarchical reward decomposition 并显式校验中间 trace；Kernel-Smith 给出 evolution-oriented post-training 配方，在 KernelBench Level 1 上 fast1 = 70%；Dr. Kernel 引入分布式 GPU 环境和多轮 RL 缓解 biased policy gradient。
跨硬件：AscendKernelGen 把同一范式扩展到华为 Ascend NPU，生成 AscendC kernel，用 CoT-SFT + DPO 组合。
CUDA Agent：在大规模 agentic RL 系统中设计 skill-augmented CUDA 开发环境，用自动 verification 与 profiling 提供 reward signal，在 KernelBench Level 1 上比 PyTorch Eager 快 99%（论文报告 SOTA）。

RL 的共同模式是「必须有可执行 + 可度量的反馈」——reward 既来自运行时性能，也来自结构化检查；多轮 / hierarchical / 多 agent 是缓解 reward sparse 的关键技巧。

第二层：LLM Agent 闭环（Section 4）—— 围绕「规划 + 工具 + 评估」做系统化

论文把 agentic 工作拆成四个维度，结构非常值得借鉴：

1. 学习机制（Learning Mechanisms）

迭代式精炼：Caesar（KernelBench 内）、Inference-Time Scaling（Chen 2025b）通过 test-time scaling 与 reflection 提升 kernel 质量；PEAK 用模块化 step-wise refinement；AutoKernel 先 profile 整个模型定位瓶颈再优化；MaxCode 把迭代搜索统一进 max-reward RL 框架，配自然语言 critique 模型把执行反馈翻译成诊断洞见；K-Search 把 LLM 当 world model 用，把高层算法规划与低层程序实例化解耦。
针对特定模型的迭代：DiffAgent 加速 diffusion 模型 kernel；TritonX 在 state machine 内迭代覆盖完整 PyTorch ATen backend；KernelGen 用 test-time scaling + reflection 覆盖多芯片 backend。AKO 是这篇综述里值得高亮的工作：它把 Claude Code / OpenCode 这类通用 CLI coding agent 包了一层 harness，让通用 coding agent 也能做 agentic kernel 优化，并在多个 hard benchmark 上达到 SOTA——这是「通用 coding agent 反向赋能垂直领域」的一个清晰范例。
基于种群的进化搜索：Lange et al. 用 mutation + crossover 优化翻译 CUDA；FM Agent 用多样性保留 / 自适应进化 / 多种群动力学的演化阶段；EvoEngineer 把遍历技巧与种群管理解耦；GPU Kernel Scientist 用多阶段进化工作流优化 AMD HIP kernel；cuPilot 通过高层语义策略引导进化。

2. 外部记忆（External Memory Management）

复杂 kernel 优化要调用大量 CUDA API / 硬件指令集，LLM 容易幻觉或遗忘，因此需要外部「技能库 / 知识库」。代表工作：

KernelEvolve：异构 AI accelerator 专用硬件知识库。
ReGraphT：把 reasoning graph 作为外部结构化记忆，小模型可在图上导航检索。
KernelBlaster：累积经验到可检索的持久化 CUDA 知识库。
EvoKernel：value-driven memory，按优先级检索历史经验 / 轨迹。
KernelSkill：双层记忆架构，长期记忆里维护可复用专家技能。

3. 硬件 profiling 整合（Hardware Profiling Integration）

通用 LLM 不懂硬件，需要把硬件 spec 显式注入 prompt 并迭代 reason over profile：

QiMeng 系列：TensorOp 从硬件文档里蒸馏提示；GEMM 提供通用模板；Attention 把高层思考语言转成低层 CUDA，在不同 GPU 上实现高性能 FlashAttention。
SwizzlePerf：专注 swizzling 模式优化 L2 命中率，把架构 spec 注入 prompt、限定搜索空间。
CUDA-LLM：把 warp size、cache size 等 GPU spec 注入 prompt，配合编译日志与运行时 metric。
TritonForge：profiling-guided feedback loop 迭代定位瓶颈。

4. 多智能体编排（Multi-Agent Orchestration）

把整个工作流拆给多个专职 agent 协作。综述指出这一维度还在早期，相关工作多为原型。

第三层：资源基础设施（Resource Infrastructure）

论文配套维护一份开源 GitHub 仓库（flagos-ai/awesome-LLM-driven-kernel-generation），核心贡献是：

把分散的训练数据（PyTorch ↔ Triton ↔ CUDA）按结构化组织；
提供面向 RAG 的文献集合，方便后续工作把已有成果作为检索增强的输入。

这两项资源基础设施是综述最具长期价值的部分——它把「想做 LLM-for-kernel 的新人需要找数据集、找 baseline、找论文」的痛点一次性解决。

关键实验与数据

综述本身不做新实验，但论文里复述了被引工作的关键 SOTA 数字，可以作为读者进一步调研的入口：

类别	代表方法	评测 / 数字
CUDA SFT	KernelCoder (ConCuR)	KernelBench L1 fast1 = 17%
CUDA SFT	InCoder-32B	KernelBench L1 fast1 = 22.2%
CUDA RL	CUDA Agent	KernelBench L1 相对 PyTorch Eager 提速 99%（SOTA）
Triton RL	Kernel-Smith	KernelBench L1 fast1 = 70%
CUDA-L2	（CUDA-L1 之上）	论文报告在评测 workload 上性能超过 cuBLAS

另外，文中引用 K-Search 在多样化与复杂 kernel 上表现强；AKO 通过 coding agent harness 在多个 hard benchmark 上达到 SOTA。这些数字都需要回到原文核对，但综述给出的索引价值很大。

亮点与局限

亮点 1. 分类法干净：把 LLM 直出（Section 3）与 Agent 闭环（Section 4）分清楚，又在 Agent 内部用「学习机制 / 外部记忆 / 硬件 profiling / 多 agent」四象限拆解；这套坐标轴对未来工作的定位非常友好。 2. 资源库先行：GitHub awesome-list 与结构化数据集 / RAG 文献集一起发布，对领域新人极其友好。 3. 覆盖广：从 SFT、RL、agentic loop、进化搜索、到跨硬件（CUDA / Triton / AscendC / HIP）都有涉及。 4. 指出现实痛点：明确点出 reward 稀疏、biased policy gradient、lazy optimization 等 RL 训练中的具体问题。

局限 1. IJCAI 9 页正文 的篇幅限制下，方法部分偏「列工作 + 简述」，缺乏深入的对比表格（论文本身也没给出统一 benchmark 对比表），读者需要回到原文才能比较细节。 2. 多智能体编排维度偏薄，相关工作还少，分类意义大于实证意义。 3. 资源库靠社区维护，存在条目滞后 / 标准不统一的风险；论文未给出一个可机器读的 schema。 4. 评测本身的不统一问题没有解决：不同工作用 KernelBench 不同 level、不同 baseline、不同 metric（fast1 / runtime / 相对 PyTorch 提速）比较，跨论文数字难以直接对齐；综述提到这点但未提出统一评测协议。 5. 论文 9 页 + 1 figure 的体量，附录与实验细节明显压缩；评测 baseline 与统计显著性等关键工程细节，原文未明确给出。

对工程落地的启发

企业级 GPU infra 团队：可以参考 AKO 的范式，把内部已有的 Claude Code / Cursor / Copilot CLI agent 包一层 harness，让通用 coding agent 也能调优 kernel——这是「用通用 agent 解决垂直问题」的最经济路径。
训练 LLM-for-kernel 的团队：ConCuR 的推理 trace 筛选、InCoder-32B 的三阶段数据流水线、Kernel-Smith 的 evolution post-training，是三条可直接借鉴的训练配方。
kernel benchmark 与 CI：建议在 CI 中引入 KernelBench L1/L2/L3 三个 level，并同时报告 fast1（功能正确性）与相对 runtime；否则无法横向比较。
硬件知识库：KernelEvolve / ReGraphT / KernelSkill 提示我们应该把架构 spec、API 文档、性能优化 pattern 做成结构化外部记忆，而不是塞进 prompt。
测试时 scaling：Inference-Time Scaling（Chen 2025b）和 MaxCode 的实践表明，在 kernel 任务上做 test-time scaling 也能拿到显著提升，值得在生产 kernel 编译 pipeline 中试验。

与同方向工作的关系

与 手工 kernel 库（CUTLASS、CUTLASS 3.x、TileLang） 是互补关系：手工库提供「专家 baseline」，LLM 系工作把这些 baseline 当作性能天花板去逼近甚至超越。
与 编译器自动调优（Halide、TVM/Ansor、Triton-AOT） 关系微妙：编译器系提供可执行编译流水线，LLM 系把上游「搜索空间定义 / 调度原语设计」环节接管；二者未来可能融合，例如 LLM 生成调度原语 + TVM 实际搜索。
与 通用 coding agent（Claude Code、Cursor、OpenCode）：AKO 是首个把这些通用 agent 接入 kernel 优化的代表性工作，提示了一个新的「agentic verticalization」方向。
与 既有 kernel benchmark（KernelBench、Rodinia、PolyBench）：综述以 KernelBench 为主参照系，但仍缺少跨硬件 / 跨后端的统一评测。

适合谁读

GPU kernel 工程师 / 性能优化工程师：可作为「我现在能把哪些活儿交给 LLM / Agent」的地图。
AI Infra 平台团队：了解 LLM 在 infra 自动化上的边界与可行路径。
LLM-for-code 研究者：kernel 是一个有强可执行反馈的代码子领域，比通用 HumanEval 更适合做 RL/agentic 训练场。
RL + code 方向研究者：kernel benchmark 上的 reward design 是值得复用的范本。
企业 CTO / 技术决策者：评估「是否投入 LLM 自动 kernel 优化」时，这篇综述提供了当前 SOTA 水平与生态成熟度的整体判断。

不确定处： - 综述复述的 fast1 / 提速 99% / fast1 = 70% 等数字源自被引工作的原文，本解读未逐一回溯原论文确认实验设置；引用前建议核对各原文献。 - 多智能体编排（Multi-Agent Orchestration）维度在论文中相对简略，原文未明确给出代表工作的统一对比。 - 资源库的长期维护质量、条目更新频率，原文未明确，仅承诺「持续维护」。

工程落地与核查（Jay）

事实核查注记

原始结论	核查结论	备注
CUDA Agent 在 KernelBench L1 提速 99% vs PyTorch Eager	需原文核对：未明确是 vs PyTorch Eager 还是 vs cuBLAS；两者差距极大（PyTorch Eager vs cuBLAS 差距约 10–50×），建议以 KernelBench 官方 leaderboard 为准	PyTorch Eager 在 kernel 场景本来就极慢，99% 提速如果 vs cuBLAS 则存疑
KernelCoder fast1 = 17%，InCoder-32B fast1 = 22.2%	数字需回溯原文：综述引用自 ConCuR 论文，未逐篇核实；KernelBench 各 level 难度差异大，同一方法跨 level 性能可能差 3–5×	以 flagos-ai/awesome-LLM-driven-kernel-generation 或 KernelBench 官网最新数据为准
CUDA-L2 在评测 workload 上超过 cuBLAS	存疑程度中等：cuBLAS 是高度手工调优的 GEMM 库，RL 方法在特定 workload 上超过有可能，但泛化性未经验证	如用于生产 kernel 生成 pipeline，必须在目标硬件 + 目标 shape 上复测
AKO 在多个 hard benchmark 上 SOTA	值得跟进：AKO 代表「通用 coding agent → 垂直 kernel」的路径工程上最可落地	但原文未给出具体 NDCG 数字，需回溯
fast1 = 70%（Kernel-Smith）	需原文核对：KernelBench Level 1 的 70% fast1 已经很高（cuBLAS 在 L1 约 85–90%），需要确认 L1 定义和 baseline	fast1 是功能正确性比例，非性能指标

生产落地路径与避坑

1. AKO 范式是当前最可落地的 entry point 不推荐从零训 LLM-for-kernel 模型。推荐路径： 1. 拿 AKO harness（Claude Code / OpenCode + kernel 测试 harness） 2. 接内部 CI：每次 commit 跑 KernelBench L1/L2，report fast1 + runtime 3. 通用 coding agent 在 L1 能稳定到 fast1 > 60% 后，再考虑 RL post-training 冲 L2/L3

2. KernelBench 的正确用法 - L1（Level 1）：简单 kernel（GEMV、ReLU、Softmax 等），fast1 > 60% 是基操 - L2（Level 2）：中等复杂（tiled GEMM、attention、group normalization 等），fast1 > 30% 是合理目标 - L3（Level 3）：复杂 kernel（fused kernel、variable-shape 等），fast1 > 10% 是当前上限

不要只看 fast1，必须同时看相对 cuBLAS / FlashAttention 的 runtime ratio；一个 fast1=90% 但比 cuBLAS 慢 2× 的 kernel 没有实际价值。

3. RL 训练 cost 必须提前算清楚 Kernel-Smith 的 evolution-oriented post-training 和 CUDA-L2 的 RL 训练： - 估算 cost：1 次完整 RL 训练run ≈ 200–800 GPU-hours（A100 8卡机），取决于数据规模和 reward 复杂度 - 如果只服务内部 3–5 个固定 kernel 形状，RL 训练 ROI 不合算；直接手写或用 CUTLASS 模板更划算 - RL 方法适合：kernel 类型多、硬件平台多（NVIDIA + AMD + Ascend）、需要跨代次快速生成 baseline 的场景

4. 硬件知识库是长期护城河 KernelEvolve / KernelSkill 的思路值得借鉴，建议： - 短期：把 CUDA programming guide、GPU spec sheet（warp size / shared mem / registers）做成 RAG knowledge base - 中期：积累内部历史 kernel 优化 case（什么 shape、什么 GPU、用了什么 tile 大小、最终性能） - 长期：训专门领域的 kernel embedding model，做相似 shape → tile config 推荐

5. 代码正确性永远优先于性能 LLM 生成 kernel 最怕的是「看起来对、跑起来不对」或「小 shape 对、大 shape 崩」： - 必须在 CI 里强制跑 numerical correctness test（对比 cuBLAS / FlashAttention 输出误差 < 1e-5） - 性能回归测试可以放 CI 第二天跑，但 correctness 是每次 PR 的守门员 - 警惕「比 PyTorch Eager 快 99%」这种基线——PyTorch Eager 的正确性本身没问题，但很多 LLM kernel 生成工具的正确性根本没保证

6. 跨硬件（CUDA ↔ HIP ↔ AscendC）落地顺序 当前 LLM kernel 生成能力成熟度：NVIDIA CUDA > AMD HIP >> Ascend AscendC - 第一步：CUDA 上跑通 CI，积累 RAG 知识库 - 第二步：HIP（AMD）可以复用大部分 RAG 知识，只需额外注入 CDNA/RDNA 架构 spec - 第三步：AscendC 生态最薄，AscendKernelGen 的路线（CoT-SFT + DPO）需要额外数据积累

快速上手 Checklist

[ ] 接入 KernelBench L1 到 CI（每次 PR 必须通过）
[ ] 建立 numerical correctness test suite（对比金标准库）
[ ] 评估是否值得 RL 训练：若 kernel 类型 <10 个 shape，手写优先；若 >50 个 shape 或多硬件，RL 路线开始合算
[ ] 搭建硬件 spec RAG knowledge base（CUDA programming guide + internal benchmark log）
[ ] 关注 AKO 和 Kernel-Smith 的开源进度，这两个是当前工程可行性最高的
[ ] 不要用 fast1 数字做性能承诺，必须报告 runtime ratio vs cuBLAS/FlashAttention