让 AI 自己写 GPU kernel：从「写一行 CUDA」到「闭环优化」的两年跃迁——一篇 IJCAI 2026 综述讲清楚 LLM 怎么重塑底层性能工程

关联论文：2601.15727

你有没有想过这种画面：

你跟一个 AI 说「帮我写一个跑得比 cuBLAS 还快的矩阵乘」；
它没急着回你代码，而是先读 GPU 架构手册、再 profile 你的 shape、然后迭代十几次自己 debug；
最后扔给你一份「性能 -5%、功能 100% 正确」的 Triton kernel，旁边还附一份诊断报告。

这画面在 2025 年还是 demo 级别的玩具，但 IJCAI 2026 这篇 9 页综述（arXiv 2601.15727）告诉我们：这玩意现在已经有了可对照的地图——它把过去两年「LLM 写 GPU kernel」的研究系统整理成了两条主线、四个维度、一个开源资源库。

换句话说：LLM 写 kernel 这件事，第一次有了正经的学术坐标轴。

为什么这件事值得大众关注

大多数人不知道，现代 AI 跑得快不快，根本不取决于 GPU 标称的算力峰值，而是取决于底层那段叫「kernel」的代码能不能榨干硬件：

GEMM（矩阵乘）、attention、convolution、sparse ops —— 每个深度学习算子在 GPU 上都要重写一遍优化版；
写一个接近 cuBLAS 性能的 kernel，需要精通硬件架构、内存层级、warp 调度，工程师稀缺到「千金难求」；
同一种优化往往绑死特定 GPU 代次，换卡就要重写，工程师再稀缺也补不上硬件迭代速度。

更尴尬的是，过去二十年业界试图用「编译器自动调优」（Halide、TVM、Ansor）解决——但这些工具的搜索空间、调度原语、优化先验都是人写的，覆盖不了真正的「开放空间」。

LLM 的出现改写了这一切：

它能「压缩」散落在 GitHub、技术博客、教科书里的硬件感知编程知识；
Agent 框架能把 kernel 开发重写成「迭代 + 反馈」的循环，让 AI 能 fatigue-free 地长视野探索。

这篇综述就是要把这个新范式讲清楚：现在长什么样？哪些方法属于哪一类？还有哪些没解决的问题？

这篇论文核心讲了什么

一条主线一：让 LLM 本人变成 kernel 专家

这是「后训练（post-training）」流派，直接调教 LLM 让它吐代码。分两派：

A. 监督微调（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 增强质量。门槛在数据生成与筛选成本。

B. 强化学习（RL）派

RL 派的核心洞见是：必须有可执行 + 可度量的反馈。

CUDA 方向：CUDA-L1 用 contrastive RL + LLM-as-a-judge 做密集反馈；CUDA-L2 在它之上声称在某些 workload 上超过 cuBLAS。
Triton 方向：Kernel-Smith 给出 evolution-oriented post-training 配方，在 KernelBench Level 1 上 fast1 = 70%；Dr. Kernel 引入分布式 GPU 环境缓解 biased policy gradient。
跨硬件：AscendKernelGen 把同一范式扩展到华为 Ascend NPU，用 CoT-SFT + DPO 组合生成 AscendC kernel。
CUDA Agent：在大规模 agentic RL 系统里设计 skill-augmented CUDA 开发环境，用自动 verification 与 profiling 提供 reward signal，在 KernelBench Level 1 上相对 PyTorch Eager 提速 99%（论文报告 SOTA）。

RL 的共同套路：reward 既来自运行时性能，也来自结构化检查；多轮 / hierarchical / 多 agent 是缓解 reward sparse 的关键技巧。

主线二：让 Agent 闭环把整个流程接管

这是「Agentic 工作流」流派，不直接训 LLM，而是搭建一套「规划 + 工具 + 评估」的系统。论文把它拆成四个维度：

1. 学习机制（Learning Mechanisms）

迭代式精炼：Caesar、PEAK、AutoKernel、MaxCode、K-Search 等，通过 test-time scaling 与 reflection 提升 kernel 质量；
针对特定模型的迭代：DiffAgent 加速 diffusion kernel；TritonX 覆盖完整 PyTorch ATen backend；
AKO 是本综述的明星工作：把 Claude Code / OpenCode 这类通用 CLI coding agent 包一层 harness，让通用 coding agent 也能做 agentic kernel 优化，在多个 hard benchmark 上达到 SOTA。这是「通用 agent 反向赋能垂直领域」的清晰范例。
基于种群的进化搜索：FM Agent、EvoEngineer、GPU Kernel Scientist、cuPilot 用 mutation + crossover + 多种群管理做长视野探索。

2. 外部记忆（External Memory Management）

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

KernelEvolve：异构 AI accelerator 专用硬件知识库；
ReGraphT：把 reasoning graph 作为外部结构化记忆；
KernelBlaster：累积经验到可检索的持久化 CUDA 知识库；
KernelSkill：双层记忆架构，长期记忆里维护可复用专家技能。

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

通用 LLM 不懂硬件，需要把硬件 spec 显式注入 prompt：

QiMeng 系列：TensorOp 从硬件文档蒸馏提示；GEMM 提供通用模板；Attention 把高层思考转成低层 CUDA FlashAttention；
SwizzlePerf：专注 swizzling 模式优化 L2 命中率；
CUDA-LLM：把 warp size、cache size 等 GPU spec 注入 prompt。

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

把整个工作流拆给多个专职 agent 协作。这一维度还在早期，分类意义大于实证意义。

一个杀手锏：开源资源库

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

把分散的训练数据（PyTorch ↔ Triton ↔ CUDA）按结构化组织；
提供面向 RAG 的文献集合。

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

为什么这件事对 2026 年的 AI 工程至关重要

如果你是下面任一种角色，这篇综述几乎是必读：

AI Infra 平台工程师：评估「是否投入 LLM 自动 kernel 优化」时，它提供了当前 SOTA 水平与生态成熟度的整体判断；
GPU kernel / 性能优化工程师：可作为「我现在能把哪些活儿交给 LLM / Agent」的地图；
RL + code 方向研究者：kernel benchmark 上的 reward design 是值得复用的范本；
企业 CTO / 技术决策者：用一篇综述建立完整的技术雷达，避免被零散论文误导。

更关键的是，它给出了一个干净的方法分类坐标：

LLM 直出 vs Agent 闭环；
Agent 内部分成「学习机制 / 外部记忆 / 硬件 profiling / 多 agent」四象限；
覆盖广到 SFT、RL、agentic loop、进化搜索、跨硬件（CUDA / Triton / AscendC / HIP）。

下次再看到「LLM 写 CUDA」的新论文，你只需要把它往这套坐标轴上一放——它属于哪一类、解决了哪一环、还有什么空白，三秒钟就能定位。

三处落地风险别踩

风险 1：fast1 数字别轻信

论文里复述的「fast1 = 70%」「提速 99%」等数字都源自被引工作的原文，评测口径在不同论文里差异极大（KernelBench 各 level、PyTorch Eager vs cuBLAS baseline 都不同）。工程上不要拿这些数字做性能承诺，必须自己跑分验证。

风险 2：多智能体编排维度偏薄

论文指出「Multi-Agent Orchestration」分类意义大于实证意义。如果你的方案依赖多 agent 编排，不要把综述当依据——它只是告诉你「这个方向被关注」，没告诉你「哪个实现能用」。

风险 3：跨论文评测不可对齐

不同工作用 KernelBench 不同 level、不同 baseline、不同 metric（fast1 / runtime / 相对 PyTorch 提速）比较，综述提到这点但未提出统一评测协议。这意味着你看到的 SOTA 数字可能根本不能横向比。

写在最后

这篇综述最有价值的，不是某一个数字或某一个方法，而是它把一个混乱的领域第一次拉到了同一张地图上：

两条主线（LLM 直出 / Agent 闭环）；
四个维度（学习机制 / 外部记忆 / 硬件 profiling / 多 agent）；
一个开源资源库（数据集 + baseline + 论文索引）。

下次有人跟你说「我们用 LLM 自动优化 kernel」，你只需要问三个问题：

「你的方法是 LLM 直出还是 Agent 闭环？」「你的 reward signal 来自运行时性能还是结构化检查？」「你的 fast1 数字是在 KernelBench 哪个 level、对比哪个 baseline 跑出来的？」

——三个问题就能把对方的方案放到这套坐标轴上判断。

LLM 写 CUDA 这件事，从 2025 年的 demo，正式进入了 2026 年的工程图谱。

延伸阅读 - 论文：arXiv 2601.15727（IJCAI 2026 综述：Towards Automated Kernel Generation in the Era of LLMs） - 开源资源库：https://github.com/flagos-ai/awesome-LLM-driven-kernel-generation - 同方向工作：CUDA-L1 / CUDA-L2（RL 派代表）、Kernel-Smith（Triton RL 代表）、AKO（通用 coding agent 接入 kernel 优化的范例）、AscendKernelGen（跨硬件 AscendC 范例） - 工程模板：AKO harness（Claude Code / OpenCode + kernel test harness）是当下工程可行性最高的 entry point

三个标题变体

让 AI 自己写 GPU kernel：从「写一行 CUDA」到「闭环优化」的两年跃迁——一篇 IJCAI 2026 综述讲清楚 LLM 怎么重塑底层性能工程
别再手写 CUDA 了！IJCAI 2026 这篇 9 页综述告诉你：LLM 写 kernel 现在长什么样、还有哪些坑
一篇综述把 LLM 写 GPU kernel 的地图画全了：从 SFT 到 RL，从单 agent 到多 agent，从 CUDA 到 AscendC

小红书风格卡片文案（可直接发布）

🤖 你让 AI 写 CUDA，它会听话吗？

IJCAI 2026 有篇 9 页综述 📄（arXiv 2601.15727）把过去两年「LLM 写 GPU kernel」的所有研究拉到了同一张地图上 ✨

画了两条主线：

🔹 主线一：让 LLM 本人变 kernel 专家 - SFT 派：KernelLLM / KernelCoder / InCoder-32B - RL 派：CUDA-L1、CUDA-L2、Kernel-Smith、CUDA Agent - 跨硬件：AscendKernelGen（Ascend NPU）

🔹 主线二：让 Agent 闭环接管整个流程 拆成四个维度： 1️⃣ 学习机制（迭代精炼 / 进化搜索） 2️⃣ 外部记忆（KernelEvolve / KernelSkill） 3️⃣ 硬件 profiling（QiMeng / SwizzlePerf） 4️⃣ 多 agent 编排（还在早期 ⚠️）

最值得高亮的工作 💡：

CUDA Agent：KernelBench L1 相对 PyTorch Eager 提速 99%（SOTA 报告）
Kernel-Smith：Triton RL 在 KernelBench L1 达到 fast1 = 70%
AKO：把 Claude Code 包一层 harness 直接做 kernel 优化，通用 coding agent 反向赋能垂直领域的清晰范例

配套的 GitHub 仓库 flagos-ai/awesome-LLM-driven-kernel-generation 是杀手锏 🔥： - 数据集、baseline、论文索引一次齐 - 想要入坑 LLM-for-kernel 的新人再也不愁找资料

工程落地点 🛠️：

1️⃣ 别从零训模型——先用 AKO harness 接入 Claude Code，把 KernelBench L1 接到 CI 2️⃣ 代码正确性优先——CI 里必须跑 numerical correctness test（vs cuBLAS 误差 < 1e-5） 3️⃣ 别轻信 fast1 数字——必须同时报告相对 cuBLAS / FlashAttention 的 runtime ratio 4️⃣ 硬件知识库是护城河——把 CUDA programming guide + internal benchmark log 做成 RAG 5️⃣ 跨硬件落地顺序：CUDA → HIP → AscendC（成熟度递减）

⚠️ 必须警惕的边界： - 论文复述的 fast1 数字源自被引原文，未逐一回溯，引用前请核对各原文献 - 多智能体编排维度论证偏薄，分类意义大于实证意义 - 跨论文评测口径不一致，fast1 / runtime / 相对 PyTorch 提速不能直接对齐 - 综述本身不提供参考实现，工程可行性必须独立验证 - 资源库靠社区维护，存在条目滞后风险

📎 论文 ID：2601.15727

💬 评论区聊聊：你觉得「LLM 自动写 kernel」这件事，2027 年能进生产环境吗？🤔