KernelCraft: Benchmarking for Agentic Close-to-Metal Kernel Generation on Emerging Hardware 【剑桥AMD的26年paper】这篇文章在做什么这篇文章的核心提出了一个新的 benchmark 和 agent 评测框架KernelCraft。它关心的问题是对于那些“刚出现、生态不成熟、ISA 也很新”的硬件平台LLM agent 能不能在几乎没有现成编程样例的情况下直接生成 close-to-metal 的低层 kernel甚至还能进一步优化性能这里的“close-to-metal”可以理解成不是写 Triton、CUDA 这种相对高层的 DSL而是更贴近底层硬件指令、寄存器、内存布局和执行约束的代码文中主要是 assembly 级别汇编级别。1. 什么是 kernelkernel 可以理解成运行在硬件上的一个底层计算程序。比如1. GEMM2. Softmax3. LayerNorm4. Attention5. Conv2D这些在高层框架里可能只是一行算子调用但在底层都要靠 kernel 来真正执行。2. 什么是 ISAISA 是 instruction set architecture也就是指令集架构。你可以把它理解成“这块硬件允许你说什么底层命令以及这些命令怎么执行”。如果你写高层 Python平时完全不用关心 ISA但如果你写 assembly kernel就必须知道1. 有哪些指令。2. 指令的参数格式是什么。3. 数据放在哪里。4. 寄存器怎么用。5. 内存层次和搬运方式是什么。3. 为什么“新硬件 新 ISA”很难成熟平台比如 CUDA GPU已经有1. 很多教程和样例。2. 成熟编译器。3. 大量社区代码。4. 比较稳定的优化套路。但新硬件通常没有这些。于是开发者就得手写大量低层 kernel这会带来几个问题1. 开发慢。2. 易错。3. 很依赖少数专家。4. 软件栈成熟速度跟不上硬件演进速度。一、INTRO新 AI 加速器常常要求开发者手工写低层 kernel而这个过程既慢又痛苦还不容易规模化。作者认为过去 LLM for kernel generation 的结果主要发生在成熟 GPU 生态里但对于 emerging hardware这个问题还没有被认真 benchmark。Figure 1 其实就是整篇文章最核心的概念图之一。它把 KernelCraft 的整体结构压缩成一个框架输入给 agent 的有三类信息1. Generation task任务本身例如 primitive op、composite op、end-to-end op。2. ISA specification目标硬件的指令集说明。3. Hardware configuration内存大小、阵列规模等硬件参数。然后 agent 在工具帮助下不断生成、调试、修正最后输出 valid, high-performance kernel code。这张图要表达的重点是作者明确把任务难点定义为“从自然语言 workload ISA 文档 硬件配置到低层 assembly kernel”的跨层映射问题。自己和已有 benchmark 的差异Table 1 比较了 KernelBench、TritonBench、NPUEval、BackendBench、MultiKernelBench 和 KernelCraft。最值得注意的不是它有没有更多列而是它的“Target Language”是 Assembly。这意味着1. 它不是评估高层算子实现。2. 它不是评估编译器 backend。3. 它是直接评估贴近 ISA 的 kernel 编写能力。不过也要客观看越往底层走benchmark 的平台绑定性就越强结果也越难横向比较。所以它的独特性很强但通用性会相对弱一些。二、方法Figure 2 把整个 diagnosis-and-repair loop 画得很直观。流程大致是1. 输入任务描述、ISA 说明、硬件配置。2. 模型先生成初版 assembly code。3. 调 write code 存盘。4. 调 check syntax 做语法/编译检查。5. 调 run evaluation 看功能是否正确。6. 如果错了再看 memory diff、文档 grep 等工具反馈。7. 再改代码。8. 正确后继续优化性能。这和现实很接近。真实工程里没人指望一次写对 assembly kernel更多是1. 先写个能跑的版本。2. 再修 bug。3. 再看延迟。4. 再继续做优化。因此KernelCraft 的 agent loop 比很多只做“生成然后测一次”的 benchmark 更像真正开发过程。文中 Table 2 列了 KernelCraft 可用的工具。1. write code2. check syntax3. run evaluation4. 文档/指令查询类工具5. 内存查看、输出查看等调试类工具这意味着 benchmark 不只是问“模型知道答案吗”而是问“模型会不会像开发者一样使用工具”。这也是文章后面专门讨论 tool-use failure 的原因。因为在这个 benchmark 里模型不会调工具几乎就直接废掉了。Table 3 给出了目标平台主要包括1. PLENA2. AMD NPU3. Coral NPU4. 另外还有 BOOM 用于 CPU 侧扩展实验这里的三类 accelerator 很有代表性1. 有完全自定义 ISA 的。2. 有依赖现实硬件和专有工具链的。3. 有基于更开放 ISA / RTL 仿真的。这种组合让 benchmark 不会只适合某一种平台风格。Table 4 则把 ML kernel 任务分成三层1. Level 1primitive operations比如 SiLU、Softmax、GEMM。2. Level 2composite operations比如 FFN、SwiGLU、MHA、GQA、MQA。3. Level 3end-to-end system比如 DecoderBlock、ConvBlock。三、Evaluation核心指标是1. Success rate是否生成了功能正确的 kernel。2. Kernel performance相对平台编译器基线的速度提升。这里 success 的定义很重要。不是“能编译”也不是“输出看起来像”而是功能正确。由于低层执行里存在不同平台、不同量化、不同累积顺序带来的数值差异作者采用 tolerance-based validation而不是强行 exact match。这一点是合理的不然很多实际上正确的低层实现也会被误判为错。Table 5 给出了不同模型在三类 accelerator 上的成功率。模型包括1. GPT-5.22. Gemini-3-Flash3. Sonnet 44. DeepSeek R1这里最值得看的不是某个单点成绩而是整体趋势。第一GPT-5.2 明显最好。文中总结1. 在 PLENA 上总成功率 55%2. 在 AMD NPU 上 17%3. 在 Coral NPU 上 47%Gemini-3-Flash 次之Sonnet 4 和 DeepSeek R1 明显弱很多DeepSeek R1 几乎每个平台只成功了一个 kernel。这个结果有两个含义1. frontier reasoning model 确实已经有一定能力在陌生 ISA 上做 close-to-metal 生成。2. 但模型能力差距非常大这个 benchmark 很能拉开前沿模型与一般模型的差别。第二任务复杂度一上来成功率掉得很厉害。例如 GPT-5.21. Level 1 在 PLENA 上可以做到 37/50。2. Level 2 掉到 18/40。3. Level 3 直接 0/10。AMDNPU 更难GPT-5.2 在 Level 2 只有 3/35Level 3 也是 0。Coral NPU 上 primitive 还行但 composite 和 end-to-end 也基本崩掉。这说明一个非常关键的事实agent 可以在新 ISA 上学会写一部分 primitive kernel但离稳定搞定复杂 end-to-end 模块还差得很远。第三平台差异很大。作者把一部分原因归因于文档质量Table 6 对这一点提供了支撑。Table 6 给出了不同平台 system prompt 和工具描述的 token 分布。最显眼的是1. PLENA 的 system prompt 总长 15.1k2. AMD NPU 是 5.5k3. Coral NPU 是 5.3k其中 PLENA 的 ISA 文档部分尤其长。作者据此推断PLENA 成功率较高部分原因可能是文档更完整、更详细。这个判断是有道理的因为在“新 ISA 低层 assembly”这种任务里模型很大程度上就是靠文档活着的。但也要保持谨慎1. prompt 长并不自动等于信息更好2. 平台难度本身也不同3. 编译器、模拟器、执行环境差异也会影响成功率。所以 Table 6 提供的是一个合理解释但不是严格因果证明。Figure 3 展示的是最优 KernelCraft agent 相对编译器基线的 speedup。文章总结了几个重要观察1. 在 PLENA 上一些 normalization 任务能稳定做到 1.06x 到 1.22x。2. 某些 elementwise task 在大规模配置上反而退化。3. 某些任务上 agent 生成的 kernel 不只是正确而且能接近或超过编译器。这个图的真正价值在于提醒你即使模型已经能写对 kernel性能也不是自动就会好。低层 assembly kernel 的性能高度依赖1. loop 结构2. tiling3. 指令调度4. memory access5. quantization / 数据表示细节所以如果只看 success不看 speedup就会高估模型的实用性。Table 7 做的是 GPT-5.2 在 Level 2 上的消融比较 no thinking 和 medium thinking。结果非常直接1. 不开 thinking tokens 时复杂任务成功率基本是 0/5。2. 开了 reasoning 以后Attention、MHA、FFN、SwiGLU 都能到 3/5 或 4/5。这说明对 close-to-metal kernel 这种任务extended reasoning 不是锦上添花而是几乎决定成败。原因很容易理解。模型不是在补全一小段代码而是在做1. 内存布局规划2. 指令选型3. 地址计算4. 调试错误来源5. 再把新信息融回下一轮修改这天然需要更长链条的推理。Table 8 比较了 zero-shot 和 one-shot给了 PLENA 和 AMD NPU 上 Level 2 任务的一些例子。比如1. PLENA 上 MHA 从 3/5 到 4/5。2. PLENA 上 MQA 从 1/5 到 4/5。3. AMD NPU 上 FFN 从 0/5 到 2/5。这说明如果给模型一个相关 workload 的示例它确实更容易学会如何适配新任务。但作者也指出这种收益是 model-dependent 的。Gemini 3 Flash 的提升就有限。所以 one-shot 可以帮助复杂 kernel 生成但不能把它理解成“给个样例就基本解决了”。文章专门分析了 tool-use 效率和失败模式指出1. 某些模型会在第一次写完代码后直接停止不继续调工具。2. 某些 chat 版本模型甚至根本不会真正调用工具只是把 assembly 文本直接输出在回答里。这说明在 KernelCraft 里tool use 不是辅助能力而是基础能力。换句话说这个 benchmark 测出来的并不只是“模型懂不懂 assembly”还测1. 模型是否会组织自己的调试流程2. 是否会读取工具反馈3. 是否会继续多轮修复。这也是为什么作者强调不需要外部手工搭特别复杂的 agent loop只要模型本身的 tool-calling 足够强就能把闭环跑起来。Case Study 1优化 compiler templateSection 5.1 很有意思。作者发现 KernelCraft 不只是能从零写 kernel还能拿现成 compiler template 做二次优化。在 PLENA 的 FFN kernel template 上agent 识别到 fully unrolled projection loops 带来了很多额外标量指针开销于是1. 利用硬件 loop 指令2. 预计算 loop-invariant pointers3. 改进 tiling 顺序最后把指令数大幅减少延迟提升 2.9%。这个 case 的意义在于KernelCraft 不是只能做“白纸起稿”也可以做“已有模板优化器”。这对现实工程可能更有价值因为很多平台已经有一套不够成熟的 compiler templates而不是完全没东西。Case Study 2CPU 扩展实验Table 10 给了 CPU kernel generation 结果用 GPT-5.2 在 BOOM/RISC-V 相关环境上测试。结果很整齐1. Level 1 五个 primitive task 全成功。2. Level 2 三个 algorithmic task 全成功。3. Level 3 两个 system workload 也全成功。4. 总计 10/10。而且不少任务还有 1.1x、1.5x、1.63x、1.68x 这类 speedup。这说明什么不是说 CPU kernel 比 NPU 更“高级”而是说明对于更成熟、更常见、更接近模型已有知识的 ISAKernelCraft 的 workflow 能更顺利地发挥作用。这也侧面印证了文章的一个核心观点问题不只是“写汇编很难”而是“写陌生 ISA 的汇编非常难”。Case Study 3与 human expert kernel 比较Table 11 比较了 KernelCraft 和人类专家、编译器在 depthwise convolution 上的 cycle count。结果很能说明问题1. KernelCraft 能生成功能正确的复杂 kernel。2. 但和 fully optimized 的 human expert 手写版本比差距仍然明显。例如1. C1 配置下HumanExpert 是 33327 cycles而 KernelCraft 是 269239 cycles。2. C2、C3 下KernelCraft 甚至还不如 compiler baseline。这张表很关键因为它防止我们对论文产生过度乐观解读。作者自己也承认对这类复杂、深度手工优化过的 kernelagent 目前还远远达不到专家水平。这使得论文的整体叙事更可信。因为如果只报“有些任务超过编译器”很容易让人误以为 agent 已经接近专家但 Table 11 告诉你复杂深度优化场景仍然非常难。Case Study 4ISA co-designSection 5.4 讲了一个更大胆的 case当 agent 在 PLENA 上遇到 diffusion language model 采样 kernel 时发现当前 ISA 不够好用于是它开始主动提出新指令建议。这个案例很吸引人因为它把 agent 的角色从“写代码的人”推进到“参与 ISA 设计的人”。但这部分要非常谨慎解读。它更像一个探索性 demonstration而不是充分验证过的方法结论。因为1. 这里有人类专家介入。2. 最终指令设计并不是 agent 完全独立定稿。3. 这是个 case study不是大规模系统评测。我其实有个问题 生成isa 但是你生成kernel是纯软件工作 isa是软硬结合 你需要改rtl这符合逻辑吗如果你要做生成kernel 那你应该无视/认为硬件配置是固定的而不是去更改硬件优化你的流程。否则就会出现一个逻辑漏洞你到底是在证明 agent 会写 kernel还是在证明 agent 会通过修改硬件来让 kernel 更容易写Figure 4 和 Figure 5 展示了不同模型在 PLENA 和 Coral NPU 上每个 workload 的 token 使用情况拆成1. system prompt2. message input3. reasoning4. output这些图的意义不是告诉你“谁更省 token”而是帮助理解1. 复杂任务往往需要更多 reasoning 和更多迭代2. 成功率和 token 使用之间不是简单线性关系3. 某些模型看起来输出很多但并不一定真能完成任务。