NPUEval: Optimizing NPU Kernels with LLMs and Open Source Compilers 【AMD 2025报告】一、这篇文章在做什么这篇文章讨论的不是一般的软件代码生成而是一个更窄、也更难的问题大语言模型能不能为 NPU 写出“既能跑、又真正高效”的 kernel 代码作者提出了一个 benchmark叫 NPUEval。它的目标不是只测模型能不能写出编译通过、功能正确的代码而是进一步测- 代码是否能在真实 NPU 硬件上运行- 结果是否正确- 是否真正利用了 NPU 的向量执行单元也就是写出了高质量 vectorized kernel这篇文章的出发点很准确。因为很多代码 benchmark 只看 pass/fail但在硬件加速器场景里能跑不等于有用。一个完全标量化、逐元素 for-loop 的 kernel 就算结果对也几乎没有体现 NPU 的价值。所以这篇论文实际上是在问一个更苛刻、更贴近工程现实的问题LLM 会不会“写特定硬件上的高性能代码”而不仅是“写能通过测试的代码”。二、为什么 NPU kernel generation 比普通代码生成难很多NPU 里的计算单元通常非常适合并行处理一批数据。如果你只是写一个普通 for 循环一次处理一个元素那虽然逻辑对但根本没有把硬件的并行能力用起来。作者在第二节特别强调对 AMD AIE 类架构来说一个 tile 内既有 vector processing unit也有 scalar unit。真正高效的 kernel应该尽量把计算推到 VPU 上而不是在 scalar 单元上慢慢循环。所以问题难就难在LLM 不仅要理解功能还要理解特定硬件 API、intrinsics、数据类型、数据搬运方式、编译器习惯和向量化写法。这和写 Python 函数完全不是一个难度层级。一、INTRO图 1作者用一个非常简单的例子把“标量代码”和“向量化代码”的差别讲清楚了图 1(a) 给的是一个 passthrough kernel 的标量版本本质就是- 遍历 512 个字节- 一个一个复制到输出图 1(b) 给的是向量化版本- 一次 load 一个 64-byte 向量- 再一次 store 回输出- 指针整体往后移动这张图的意义非常大因为它把“vectorization”从抽象概念变成了可见代码差异。两者功能一样但吞吐完全不同。二、NPUEval 数据集第三节介绍了 NPUEval 数据集。它包含 102 个常见机器学习算子对每个 kernel 都提供- Prompt类似 HumanEval 风格的任务描述和函数签名- Data movement information输入输出大小、tile 级别数据流信息- Behavioral modelNumPy/Python 参考实现- 可选 canonical C solution图 2 展示了一个示例 prompt比如 relu6_bfloat16 这样的 kernel除了功能说明外还会给出输入输出大小。这点很重要因为在 NPU 编程里kernel 不只是一个纯函数它往往还和数据大小、tile 级数据流密切相关。作者也明确说了data movement 信息必须提供否则底层图和 buffer 配置没法正确生成。所以 NPUEval 比普通代码 benchmark 更接近真实硬件开发环境它不只是“写函数”而是在写一个能嵌进硬件运行栈的 kernel。这个 benchmark 为什么有意义NPUEval 的价值主要有三层。第一它补上了 NPU 方向 benchmark 的空白。之前很多 kernel generation 工作都集中在 GPU、CUDA、Triton 这些生态更成熟的平台上。NPU 编程社区小、生态碎、公开样例少LLM 在预训练里见过的相关代码也少所以这个方向天然更难也更缺 benchmark。第二它把“功能正确”和“性能质量”同时纳入评价。这是这篇论文最重要的地方。很多 benchmark 到 pass/fail 就停了但作者进一步看 vectorization score这才逼近硬件代码生成的真实需求。第三它尽量建立在开放工具链和可复现实验上。作者用的是 AMD NPU、LLVM-AIE、MLIR-AIE、开源 driver 和 open-source compiler stack。相比很多只能在专有内部环境复现的工作这一点是明显优点。数据集构建细节1. 数据类型支持作者专门处理了 bfloat16 这类机器学习常用、但 Python 生态并不天然支持好的类型用了 ml_dtypes 去构建行为模型。这说明 benchmark 不是只盯整数 toy cases。2. 浮点误差评估作者承认不同实现可能在低精度浮点上有轻微差异因此设了不同容忍度比如 1e-2、2e-2、3e-2。这是合理的因为在硬件 kernel 里用不同近似方式求 tanh、sin 或 softmax本来就可能和参考模型不完全逐位一致。3. 数据搬运作者强调AIE 编程中 data movement 信息是编译和 buffer 分配的关键组成部分。这个点很“硬件”。普通代码 benchmark 很少会把这类信息作为 prompt 的组成部分但这里必须有。4. 硬件可获取性作者刻意选了 AMD client NPU因为它能跑在普通 laptop 上降低复现门槛。这一点很务实也让 benchmark 更容易被社区接住。图 3 展示了 NPUEval 的整体评测流程- 输入是 prompt、behavioral model、test vectors- 先把 LLM 生成的 C kernel 送进编译器- 再把 kernel 放到真实 NPU 上跑- 输出和 Python behavioral model 对比- 同时收集执行时间、误差、vectorization 等信息这比很多仅靠编译/单元测试的 benchmark 更严格。而且作者还专门强调 supplementary metrics 可以反馈给 agent 做迭代比如- 编译失败时给错误信息- 功能偏差时给 max absolute error / relative error- 性能太差时看 VPU 利用率这说明 NPUEval 其实不只是 benchmark也天然适合后续 agent 优化工作接入。generation pipeline这部分方法不算复杂但很实用主要包括三件事1. System prompt作者要求模型- 只输出单个 kernel 的完整 C 代码- 不要解释- 不要 main()- 函数名必须精确匹配这看起来像小事但在自动评测里很关键。很多模型最容易在格式层面添乱。2. RAG作者从开源 AIE kernel 仓库里抽取向量化样例构建向量数据库为每个 prompt 提供两个检索到的例子。3. Compiler feedback如果代码编译失败就把 LLVM-AIE 的错误信息反馈给模型让它重试最多 10 次。这三步组合起来是一个非常典型的“现代 LLM codegen baseline pipeline”prompt 约束 领域样例 compiler-in-the-loop。这篇文章虽然主要卖点是 benchmark但它给出的 generation pipeline 其实也很有参考价值。因为它正好代表了当前很多硬件代码生成工作的现实做法- 不再迷信零样本一步到位- 用 RAG 补足预训练语料空白- 用 compiler feedback 修正 hallucination 和 API 错误三、实验零样本结果图 4 分成两部分- (a) Functional correctness- (b) Vectorization score这个图对应的是 out-of-the-box也就是只加 system prompt不加额外反馈时的 baseline 表现。作者想强调的核心事实是- 模型写出“可运行、功能对”的代码并非完全做不到- 但写出“高向量化、真正像 NPU kernel”的代码非常难这也是全文最关键的基调NPUEval 不是一个会轻松被现有模型刷爆的 benchmark。Table 1 给了不同模型在不同重编译轮次下的 pass rate并区分了 NoRAG 和 RAG 两种设置。先看 NoRAG、0 次 recompilation 的零样本结果- GPT-4o Mini58.8%- Qwen2.5-Coder50.0%- LLaMA3.1-405B38.2%- GPT-4o36.3%- Claude Haiku 3.534.3%- GPT-4.129.4%- Claude Sonnet 3.721.6%- DeepSeek R120.6%- DeepSeek V30.0%这组结果很反直觉因为一些“更强”的模型反而不如小模型。作者给出的解释很合理小模型往往更保守倾向于写普通 scalar C 循环虽然不高效但更容易功能正确强模型则更敢尝试 vectorized 写法但因为对 NPU 生态不够熟反而更容易 hallucinate API、写错 intrinsic、用错 pragma。这其实揭示了一个很重要的问题在这种专业硬件代码生成任务里“更聪明”未必直接等于“更稳”。还是看 Table 1如果允许重编译和反馈很多模型的正确率会显著上升。例如 NoRAG 下从 0 次到 5 次 recompilation- Claude Sonnet 3.721.6% - 73.5%- GPT-4.129.4% - 71.6%- DeepSeek V30.0% - 60.8%- GPT-4o36.3% - 49.0%说明很多错误不是“模型完全不会做这个 kernel”而是第一步常常会被格式错误、错误 include、错误 API 调用卡住。一旦编译器把错误直接指出来模型会明显修正。DeepSeek V3 的例子尤其典型。作者说它经常第一版就加上不存在于当前工具链中的 adf.h所以 0 次 recompilation 时几乎全灭但编译反馈后正确率立刻大幅上升。这很能说明硬件代码生成里 compiler feedback 的现实价值。看 Table 1 会发现一个很有意思的现象加入 RAG 后很多模型的 correctness 并没有提升甚至变差。例如- GPT-4.1 在 5 次 recompilation 下从 71.6% 降到 58.8%- GPT-4o Mini 从 66.7% 降到 35.3%- Qwen2.5-Coder 从 68.6% 降到 13.7%这说明一件非常关键的事向量化示例虽然能激励模型写“更像优化代码”的东西但也可能让它更容易偏离最稳妥的功能正确解。换句话说RAG 在这里不是单调增益它会把模型从“安全但朴素”的标量实现推向“更激进但更容易错”的向量实现。这个现象非常真实也让论文显得更可信因为作者没有强行把 RAG 描述成万能补药。图 5 报告的是 vectorization results。作者定义的 vectorization score本质上是- VPU 执行周期数 / 总执行周期数也就是看代码到底有多少时间是在真正使用向量单元。作者特别强调一点功能测试没通过的 kernelvectorization score 直接记 0。这很重要因为它避免了“写了一堆很花哨但错的向量代码性能还看起来挺高”的假象。图 5 给出的主要结论包括- 总体平均分都不高- 即使是表现较好的模型全数据集平均也大约只有 10% 左右量级- 但在部分 kernel 上像 DeepSeek R1 这种 reasoning model 可以达到 50% 的向量化这说明现有 frontier 模型在少数题目上已经开始摸到高性能 NPU kernel 的门槛但整体远远没有稳定掌握这类能力。为什么作者说“分数看起来低但其实并不意味着 benchmark 不合理”作者特别提醒当前开源 SoTA kernel 的 vectorization factor 通常也就在 10%-30% 之间不是说人写的代码就全都是 90%。这点很重要。因为初看图 5 你可能会觉得“平均 10% 也太差了”但在这种 specialized NPU kernel 场景里这已经不是一个完全没意义的数字。真正应该得出的结论不是“模型彻底不会”而是- benchmark 很难- 当前模型还远没有稳定掌握这类优化- 但已经开始出现零星有价值能力作者说把开源 AIE 向量化 kernel 做成 RAG 之后整体 VPU utilization 是提升的其中 GPT-4.1 的提升尤其明显。但又有一个非常有趣的例外DeepSeek R1 加了 RAG 反而变差了而且它在不用 RAG 时仍然保持了最佳平均得分。作者分析原因是RAG 数据库里有些代码带有特定编译器 pragma而当前评测用的是 LLVM-AIE。不同编译器对 pragma 的支持方式不同所以 RAG 反而把 DeepSeek R1 从“原本有一套自己会用的低层优化写法”拉偏了。这个点很有研究价值。它说明- RAG 不是只要“有相似代码”就好- 硬件代码生成的知识检索必须高度关注 backend/compiler compatibility- 对 NPU 这种生态碎片化平台compiler-specific RAG 可能比 generic RAG 更重要图 6 展示了三类很典型的 LLM 错误。1. 图 6(a)功能对但彻底不高效例如 GPT-4o 写出的代码虽然可能调用了 aie::abs 之类 API但仍然在标量循环里一个元素一个元素处理。这类错误说明模型知道“应该用某些 AIE API”但没真正理解怎么组织成向量化计算。2. 图 6(b)幻觉 API例如 Llama-3.1-70B 生成了看起来很高级的 aie::compute(...) 等写法但实际上并不存在或不适用。这类错误是最典型的“强模型试图优化但知识不扎实”。3. 图 6(c)意识到要分块但还是在标量内层循环里处理Claude 3.7 Sonnet 知道应该设 vector_size 16也知道要把输入切成块但内部处理仍是逐元素 if/else。这类错误比单纯幻觉更有意思因为它说明模型已经“接近理解”但还没有跨过“真正写成向量 kernel”的最后那一步。图 6 的价值非常高因为它把“为什么难”说得很具体不是模型完全不知道要优化而是它常常停在一个半懂不懂的中间状态。附录中作者还做了 prompt construction study图 7 和 Table 2 研究 GPT-4.1 在不同 docstring 构造下的表现。虽然正文没有展开太多但这个实验说明一点prompt 里的示例、输入输出描述、数据大小等信息会显著影响功能正确率和向量化效果。这再次说明 NPUEval 不只是“模型能力测试”也是一个很适合研究 prompt design、RAG strategy、compiler feedback policy 的平台。个人看法优点第一它抓住了一个真实而被忽视的问题。GPU kernel generation 现在很热但 NPU kernel generation 更难也更缺 benchmark。作者在这个点上切入很准。第二它把评价标准拉回了硬件工程现实。只看 pass/fail 不够必须看 vectorization必须看真实硬件执行。第三它的评测栈是开放且可复现的。LLVM-AIE、MLIR-AIE、AMD client NPU、开源 driver这让后续研究更容易建立在这个 benchmark 之上。第四它的结果很诚实。作者没有把“有些 kernel 能做到 50% 向量化”包装成“大模型已经会写 NPU 优化代码”而是明确指出全局平均仍然只有约 10%难度很高。缺点第一它目前主要针对 AMD AIE/NPU 架构。虽然方法论可迁移但 benchmark 本体仍然有明显平台依赖。第二vectorization score 虽然有价值但它不是性能的全部。真正 kernel 优化还涉及内存访问、bank 分配、pipeline、pragma 使用、延迟隐藏等vectorization 只是一个重要代理指标不是完整性能画像。第三RAG 数据库和 compiler backend 的匹配问题说明 benchmark 结果对工具链很敏感。换编译器后某些“优化写法”的价值可能会变。第四这篇论文还没有给出很强的人类 expert baseline。作者自己也承认NPU 方向公开高质量 kernel 还不够多。第五它当前主要还是单 kernel 级 benchmark不涉及更复杂的图级优化、多 kernel 组合和完整模型执行路径。总体结论NPUEval 是一篇很有价值的 benchmark 论文。它抓住了 NPU 编程这个正在快速变重要、但生态还很稀疏的领域提出了一个不再满足于“代码能跑”的评测框架而是进一步要求“代码真的利用了 NPU 向量硬件”。图 1 把向量化问题讲得很清楚图 3 给出了可信的真实硬件评测流程Table 1 和图 5 则把一个关键事实摆到了台面上现有 LLM 在功能正确性上已经开始有一定能力但在稳定生成高质量 vectorized NPU kernel 方面仍然很弱。小模型更保守往往更容易写出能跑但很慢的标量代码强模型更敢优化却也更容易 hallucinate。RAG 和 compiler feedback 有帮助但远远不足以彻底解决问题。