清华大学团队揭秘：让AI写GPU代码，到底哪里最容易"翻车"？

这项由清华大学相关团队主导的研究发布于2026年5月，预印本编号为arXiv:2605.04956，有兴趣深入了解的读者可以通过该编号查询完整论文。

在当今人工智能飞速发展的时代，训练一个大模型就像开一家超级工厂——不仅需要设计精妙的生产流程，还需要每一台机器都高效运转。GPU（图形处理器）就是这座工厂里最核心的"机器"，而控制这台机器的底层程序，就叫做"GPU内核"（GPU Kernel）。近年来，研究人员开始尝试让大型语言模型（LLM）——也就是类似ChatGPT这样的AI——自动编写这些底层程序，省去人工调优的巨大成本。

然而，一个关键问题长期悬而未决：这些AI到底在哪类任务上能写好，在哪类任务上会"翻车"，原因又是什么？这项研究的出发点正是回答这个问题。研究团队构建了一套名为KernelBenchX的评测框架，系统地测试了五种具有代表性的AI代码生成方法，覆盖176个任务、15个类别，并在六块不同型号的英伟达GPU上进行了全面测试。

一、为什么要让AI写GPU底层代码？

要理解这项研究的意义，先要搞清楚一件事：编写GPU底层代码有多难，又有多重要。

回到工厂的比喻：普通程序员写的代码，就像是给工厂下达"生产100个零件"的总指令；而GPU内核代码，则是精确到每一条流水线、每一个工人的排班表。写好了，工厂产能翻倍；写差了，机器空转，电费白花。DeepSeek-V3这类顶尖AI系统之所以能以更低的算力跑出更好的性能，很大程度上就得益于精心手写的底层内核代码。

手工优化这些代码需要极深的专业知识，不仅要懂数学算法，还要懂芯片架构、内存带宽、并行计算……这让很多研究团队开始想：能不能让AI来代劳？

目前主流的方法有几个方向：一是直接训练AI让它专门学会写这类代码（比如AutoTriton、TritonRL）；二是搭建一套"智能体"系统，让AI自己写、自己测、自己改（比如GEAK、STARK）；三是结合搜索和推理的混合方法（比如KernelEvolve、ReGraph）。与此同时，已有一些评测基准（如KernelBench、TritonBench）尝试衡量这些方法的效果，但它们都存在明显的局限性——缺乏对任务类别的细致划分，正确性验证不够严格，对硬件效率的衡量也比较有限。

KernelBenchX正是为了填补这些空白而生。

二、KernelBenchX是怎么设计的？

研究团队给KernelBenchX定下了三个核心目标：第一，把任务按照计算结构分门别类，看清楚哪类任务容易、哪类任务难；第二，用更严格的方式验证AI生成的代码是否真的"对"；第三，不只看速度，还要看代码对硬件资源的利用率。

在任务分类上，176个任务被划入15个类别，涵盖激活函数（Activation）、卷积（Convolution）、融合算子（Fusion）、索引操作（Index）、线性代数（LinearAlgebra）、损失函数（Loss）、数学运算（Math）、矩阵乘法（MatrixMultiply）、归一化（Normalization）、优化器（Optimizer）、池化（Pooling）、量化（Quantization）、随机操作（Random）、归约（Reduce）和空间操作（SpatialOps）。这些类别不是按照算子名称划分的，而是按照"需要什么类型的知识才能写对"来区分的——这个区分方式后来被证明非常有价值。

此外，研究还特别增加了两类难度较高的任务：一是fp16、bf16、int8等低精度数值格式的多精度变体，测试AI能否在低精度约束下生成正确代码；二是六个量化任务（W8A8和W4A16格式），专门测试AI能否手动实现量化逻辑——包括计算缩放系数、显式类型转换和反量化，而不是偷懒调用现成的高层API。

在正确性验证上，研究采用了"两阶段"策略。第一阶段检查代码能不能被编译运行，以及有没有违反任务约束（比如量化任务有没有调用被禁止的API）。第二阶段才是真正的执行正确性测试——不仅用正常分布的输入数据测试，还专门注入"异常值"（出现概率0.1%，幅度放大50倍的极端数据）来检验代码在边缘情况下是否依然正确。对于量化任务，更要求余弦相似度、L1相对误差、均方根误差三项指标同时达标，而不是简单比较输出是否一致。

在硬件效率评估上，研究团队引入了两个归一化指标：IOU（内存带宽利用率，即实际用到的带宽占硬件峰值带宽的比例）和MFU（计算资源利用率，即实际完成的浮点运算占硬件峰值算力的比例）。由于不同任务有的是"内存瓶颈型"（瓶颈在数据搬运），有的是"算力瓶颈型"（瓶颈在计算），研究取两者中的较大值作为综合效率代表。代码质量方面则用可维护性指数（MI）和圈复杂度（CC）来衡量。

三、参赛选手：五种AI方法各显神通

研究团队选取了五种具有代表性的方法进行横向比较，覆盖了从"专门训练的专家"到"通用模型零样本挑战"的整个谱系。

第一位是AutoTriton，这是一个专门针对Triton编程（一种用于编写GPU内核的中间语言）训练的模型，训练方式结合了监督微调和强化学习，相当于经过了专门的"职业技能培训"，以单次生成模式参与测试。

第二位是GEAK，一个具备生成、评估、反思和优化四个模块的智能体框架，底层使用DeepSeek-V3.2-Chat模型。它运行三轮迭代，每轮生成四个候选方案，并保留历史上最好的五个实现作为参考，相当于有一套"自我复盘"机制的选手。

第三位是KernelAgent，同样是多智能体系统，采用"生成—验证—精炼"的工作流，底层也是DeepSeek-V3.2-Chat。它使用3个并行工作进程，每个工作进程最多进行5轮精炼，温度参数设为0.4（意味着生成结果更稳定保守）。

第四位是Claude，一个强大的通用大模型，以单次生成模式参与测试，代表"聪明的通才"。

第五位是DeepSeek-Coder（论文中称KernelLLM），一个通用代码模型，作为"零专业化基线"参与测试，代表"没有经过任何专项训练的普通代码助手"。

四、总体成绩单：三关各显差异

研究的第一个重大发现来自总体结果表格。编译成功、语义正确、实际加速，这三道关卡是完全独立的——通过了上一关，并不意味着能通过下一关。

KernelAgent有64.2%的代码能成功编译，看起来不错；但在这些编译成功的代码里，只有10.8%真正计算结果正确，也就是说"编译通过率到正确率"的转化率只有16.8%。这就像一家工厂的机器能启动（编译通过），但大部分产品其实是次品（执行结果错误）。

表现最好的GEAK，正确率也只有30.7%；Claude为22.7%；AutoTriton为17.0%。DeepSeek-Coder几乎全军覆没，编译率只有1.7%，正确率为0。最让人意外的是，KernelAgent的高编译率配上低正确率，说明"能写出看起来像样的代码"和"能写出真正正确的代码"是两回事。

这个结果让研究团队意识到：与其纠结于谁的总分最高，不如深挖"在哪类任务上为什么失败"——于是引出了三个核心发现。

五、第一个发现：任务的结构，比方法的设计更重要

如果把五种方法比作五位厨师，把任务类别比作不同菜系，研究发现：决定一道菜能不能做好的，与其说是厨师的厨艺差异，不如说是菜系本身的难度。

研究团队用统计方法量化了"方法身份"和"任务类别"各自能解释多少正确率的差异。结果非常明确：在语义正确率上，任务类别能解释9.4%的变异，而方法身份只能解释3.3%——类别的影响力接近方法的三倍。换句话说，你把一道极难的菜交给任何一位厨师，大概率都做不好；而一道简单的菜，任何厨师都能做出来。

从数据上看，Math（数学运算）和Activation（激活函数）这类任务，平均编译率分别达72.2%和70%，正确率分别为40.3%和32.5%，"编译转正确"的比例接近46%到56%。而Fusion（融合算子）和MatrixMultiply（矩阵乘法）的"编译转正确"比例只有约25%。最极端的是Quantization（量化）和SpatialOps（空间操作）：编译率不低（量化为41.7%，空间操作为25%），但正确率统统为0——五种方法、30次尝试，无一成功。

为什么会这样？研究团队发现，失败集中在那些"需要维护全局一致性"的任务上。简单任务（如激活函数）的特点是：每个输出只依赖于一个输入，计算是完全局部的，不需要跨越不同的并行执行单元进行协调。而困难任务（如融合算子）的特点恰恰相反：正确性要求在多个维度、多种内存布局、多个并行执行实例之间维持一致的张量语义——这种"全局契约"靠局部修补根本无法弥补。

研究团队还尝试用代码静态复杂度指标（比如圈复杂度、中间赋值数量、融合调用次数）来预测失败率，结果相关系数最高只有约0.21，远不足以解释失败的根本原因。这确认了：失败不是因为代码太长太复杂，而是因为存在一道真正的语义理解边界。

六、第二个发现：多轮迭代让代码"更对"，但不让它"更快"

GEAK这类"智能体"方法的核心卖点就是多轮迭代——写了改，改了再测，测完再改。研究详细追踪了GEAK三轮迭代的全过程，结果既令人振奋又令人警醒。

振奋的部分：编译率从第0轮的52.3%上升到第2轮的68.8%，正确率从18.2%上升到30.7%，迭代确实在持续修复错误。

令人警醒的部分：平均加速比（相对于PyTorch基线的速度提升）却从第0轮的1.58倍下降到第2轮的1.44倍；综合评分也从62.7%下降到53.3%。也就是说，代码越来越"对"了，但跑得越来越"慢"了。

为什么会这样？研究团队深入分析了352对相邻轮次的代码差异，找到了答案。这些修改里，"没有实质性改动"有102处，"掩码修复"有101处，"引入或移除委托操作"有65处，"数据类型和类型转换修复"有36处——真正面向性能优化的代码重写则寥寥无几。

这揭示了一个结构性不对称：错误修复依赖的是显式的、局部的错误信号（编译报错、形状不匹配、输出数值错误），而性能优化需要的是对"分块策略、内存布局、内核边界"的整体性决策，这类信息根本不会出现在正确性反馈里。

新被"救活"的正确内核（第0到第1轮新增正确的那些）平均加速比只有1.16倍，评分只有43.7%；而从一开始就正确的内核平均加速比达1.58倍，评分62.9%。第1到第2轮新增的正确内核也类似：1.32倍对比1.46倍。这说明，迭代优先找到那些"容易被救活"的代码，而这些代码恰恰是性能较弱的那批。

案例印证了这一点：在Index/expand_where这个任务上，GEAK第0轮代码无法编译，第1轮编译通过但结果错误，第2轮终于正确——但实测加速比只有0.076倍，也就是说比PyTorch慢了13倍以上。迭代把它救活了，但救出来的是一个极其低效的实现。

七、第三个发现："写对了"不等于"跑得快"

即便排除掉所有错误的代码，只看那些通过了正确性验证的内核，性能表现也相当令人失望。

在所有正确的内核里，有46.6%的速度比PyTorch的即时执行模式还要慢。全部正确内核的加速比中位数只有1.0008倍——几乎没有任何提升。这相当于花了大量精力手工调制了一道菜，结果味道和速冻食品差不多。

跨硬件可移植性的问题更严重。同一个内核在不同GPU上的最大加速比与最小加速比之间的比值，中位数为2.15倍，均值为2.73倍，最极端的情况达到了21.4倍。同一段代码，在A100上只有18%的正确内核比PyTorch慢，在L20上这个比例飙升到76%。这说明AI生成的内核往往只是在某种"假想的通用硬件"上优化，换一块真实的不同GPU，性能就可能崩溃。

研究团队分析了背后的三个根本原因。第一，训练数据缺乏性能标注——现有LLM的训练语料把代码当成语义文本来学，而不是硬件行为的描述，模型能学会写出"看起来像高效内核"的代码，但不会理解它为什么快或慢。第二，提示词不包含硬件上下文——现有方法都没有把目标硬件的规格（显存大小、带宽、计算单元数量）作为输入提供给模型，模型自然无法针对特定硬件做出合理的分块、并发、内存访问决策。第三，迭代反馈无法驱动性能优化——因为编译错误和正确性反馈都不能告诉模型"这段代码是内存瓶颈还是计算瓶颈"，而性能优化恰恰需要这类信息。

八、量化任务：一个特殊的失败案例

量化任务值得单独说明，因为它的失败方式与其他困难类别不同。

所谓量化（Quantization），是指把模型的权重和激活值从高精度浮点数（如32位）压缩到低精度整数（如8位或4位），以节省内存和提升速度。这是当前大模型部署中的关键技术。KernelBenchX中的六个量化任务（包括matmul_w8a8、bmm_w8a8、conv2d_w8a8、layernorm_w8a8、attention_w8a8和linear_w4a16）要求AI必须手动实现量化逻辑，包括计算缩放系数、显式类型转换和反量化，而不能调用现成的高层API。

这六个任务的编译率不低（GEAK为50%，KernelAgent为83.3%），说明AI能写出可以编译的代码；但正确率为零——五种方法加起来30次尝试，全部失败。这不是简单的语法错误，而是AI对"数值计算契约"存在系统性误解：它不理解量化过程中精度损失的边界条件，不理解缩放系数的计算规范，也不理解量化误差的可接受范围。就像一个厨师能写出食谱（代码可以编译），但根本不理解食材配比的化学反应（数值行为），自然做不出合格的菜。

九、对未来的启示

研究团队认为，当前LLM生成GPU内核的能力边界，不是一堵单一的墙，而是一段连续的台阶：可编译性、语义正确性、硬件效率、跨平台可移植性，每一级台阶都需要不同的方法才能跨越。

靠提示词工程和迭代精炼能跨越第一级（可编译性），也能部分跨越第二级（语义正确性），但结构上无法解决第三、四级的问题。

研究团队提出了几个可能的改进方向。对于正确性，需要让模型真正理解跨并行实例的张量语义和归约语义，而不仅仅是模仿局部代码片段。对于性能，需要明确的硬件感知生成机制，例如把硬件规格作为输入提供给模型，或者引入性能反馈信号（如屋顶线分析、带宽利用率）到迭代循环中。对于量化，需要让模型的训练信号真正奖励数值精度，而不仅仅奖励输出形似。

研究团队还特别提出了两个具体方向：一是基于性能剖析的超参数搜索（在已经正确的内核上调整块大小、线程束数量等硬件敏感参数，找到更优的配置）；二是硬件感知训练（在训练时把硬件规格和跨平台性能结果一起暴露给模型，让它学会理解实现选择与不同处理器之间的交互关系）。

研究团队还公开发布了评测过程中收集的"错误修复对"和"优化对"数据集，也就是那些从错误到正确、从低效到高效的代码变化记录，希望能支持后续的专项训练和推理改进研究。

说到底，这项研究做的事情，是给当前最先进的AI代码生成方法做了一次全面、系统的"体检"——不是为了捧谁或黑谁，而是找出真正的短板在哪里。结果显示，AI写GPU代码这件事，在某些特定类型的简单任务上已经相当可靠，但在需要理解全局逻辑、跨实例协调、数值精度契约的复杂任务上，依然存在系统性的理解盲区。更关键的是，就算AI写"对"了，也并不意味着写得"好"——在真实硬件上跑得快，是完全另一个层次的挑战。

这对普通人意味着什么？短期内，AI辅助GPU编程会更多地承担"能跑通"的工作，而"跑得快"依然需要人类专家介入。对于关心AI发展速度和算力成本的人来说，这项研究指出了一条清晰的路：不是拼命堆更多迭代轮次，而是从根本上改变训练信号和生成机制。读完这项研究，或许你也会思考：当AI成为写代码的助手，谁来验证它真的理解了背后的"物理规律"，而不只是在模仿表面的语言模式？

如有兴趣深入了解，完整论文可通过预印本编号arXiv:2605.04956查阅。

Q&A

Q1：KernelBenchX和其他GPU内核评测基准（如KernelBench、TritonBench）有什么本质区别？

A：KernelBenchX主要在三个方面进行了改进。其一是采用两阶段正确性验证，不只测试正常输入，还专门注入极端异常值来防止代码"蒙混过关"。其二是建立了基于计算结构的15类任务分类体系，而非简单按算子名称分类，从而能定位系统性失败模式。其三是引入了硬件效率指标（内存带宽利用率IOU和计算利用率MFU），并在六块不同型号GPU上测试了跨硬件可移植性。

Q2：量化任务为什么所有方法都以0%正确率失败，而编译率却不低？

A：量化任务的编译率不低（部分方法超过50%甚至80%），说明AI能写出语法正确、可以运行的代码。但正确率为零，说明失败不在语法层面，而在于模型对量化的数值计算契约存在系统性误解——它不理解缩放系数的计算规范、类型转换的精度边界以及量化误差的可接受范围，导致代码运行后输出结果完全不符合要求。这是一种深层的语义理解缺失，而非表面的代码错误。

Q3：GEAK多轮迭代为什么会让平均加速比下降？

A：迭代过程优先修复那些有明确错误信号（如编译报错、输出数值错误）的代码，这些"容易被救活"的代码往往本身性能就较弱。新被修复的正确内核平均加速比只有1.16倍，而从一开始就正确的内核平均为1.58倍。分析352对代码差异后发现，迭代修改以掩码修复、类型转换修复等局部操作为主，缺乏面向分块策略和内存布局的整体性性能优化，所以整体平均加速比随迭代轮次下降。