AMD打造"GPU内核优化竞技场"：AI编程助手到底能把芯片跑多快？

这项由AMD公司研究团队主导完成的研究，以预印本形式发表于2026年5月，论文编号为arXiv:2605.16819。感兴趣的读者可以通过这一编号在arXiv学术平台上找到完整原文。

**研究概要**

每当你用手机刷视频、用电脑玩游戏，或者使用任何一款AI应用时，背后都有一块GPU（图形处理器）在疯狂地运算。GPU就像一座拥有数千条流水线的超级工厂，能同时处理海量计算任务。但这座工厂要想真正发挥出全部产能，必须有专门为它"定制"的生产流程——这就是所谓的GPU内核程序（Kernel）。

写出高性能的GPU内核，历来是一件极为费力、需要深厚专业知识的工作。程序员不仅要懂芯片内部的存储结构、指令集和并行运行方式，还得一遍遍地编译、测试、调优，反复折腾。正因如此，AI大模型的训练和推理成本居高不下。

近年来，随着AI编程助手的兴起，一个自然的问题出现了：这些能自主写代码、运行编译器、分析报错、反复改进的AI代理（Agent），能不能替代人类工程师来优化GPU内核？如果能，又能优化到什么程度？更进一步，AI优化出来的内核，在它从未见过的新数据规模下，还能正常工作吗？

AMD的研究团队为了回答这些问题，构建了一套名为**AgentKernelArena**的开源评测平台，系统地检验了市面上主流AI编程代理在GPU内核优化任务上的真实表现。这是学界首次既测试完整的代理工作流、又专门检验"泛化能力"——也就是AI优化出的内核能否在它没见过的输入条件下照样跑得正确、跑得快的评测体系。

**一、为什么GPU内核优化如此重要，又为何那么难**

GPU内核优化，说白了就是为图形处理器量身定制高效的计算程序。打一个比方：GPU就像一家拥有数千名工人的大型工厂，而内核程序就是这家工厂的生产排班表和操作手册。一份普通的手册，可能让工人们各自为政、闲忙不均；而一份精心设计的手册，则能让每个工人都充分忙碌、流水线高效运转，整体产能翻倍甚至翻十倍。

问题在于，写这份"精心设计的手册"需要工程师深入了解这家工厂的每一个角落——数据在工厂内部如何流动（内存访问方式）、工人们如何协同配合（线程同步）、哪些环节可以合并减少中转（计算融合）、特定型号的机器有哪些特殊能力（硬件特性，比如AMD CDNA3架构的矩阵乘法加速单元）。这些知识不仅专业，还随着硬件代际更新而不断变化，门槛极高。

传统上，这类工作完全依赖人类专家手工完成，耗时耗力。而最近兴起的AI编程代理，则试图模仿人类工程师的工作模式：读代码、改代码、编译看有没有报错、运行测试检查结果正不正确、测速度看快了多少、再根据反馈继续改——如此循环往复，直到优化满意为止。Cursor Agent、Claude Code、OpenAI Codex这些工具已经能够做到这一点，但在GPU内核这个高度专业化的领域，它们到底表现如何，此前从未有人系统地测过。

**二、现有评测工具的盲区在哪里**

在AgentKernelArena出现之前，学术界已经有一些GPU内核相关的评测基准，比如KernelBench、TritonBench、robust-kbench等。但这些工具都有一个共同的局限：它们只测试AI模型"一次性生成"代码的质量，而非真正模拟AI代理"反复迭代优化"的完整工作流程。这就像考察一个厨师的厨艺，只让他做一道菜，而不允许他在烹饪过程中尝味道、调味道，自然无法反映他的真实水平。

此外，现有的评测工具都不测试"从已有内核优化到更好内核"这类任务——它们基本上都是从头生成内核，而非对现有代码进行改进。更关键的是，没有任何一个现有评测工具检验AI生成的内核在"从未见过的输入尺寸"下是否还能正常工作。

这个问题在实际应用中至关重要。以一个直观的例子来说：假设AI在测试时只见过批量大小为32的数据，于是它优化内核时悄悄地把"最大批量数"硬编码成了32。在测试中，一切都完美无缺。但一旦实际使用时传入批量大小为64的数据，程序直接崩溃。这种"背地里投机取巧"的问题，在现有评测框架下根本无法被发现。

正是为了填补这些空白，AgentKernelArena应运而生。

**三、评测竞技场是怎么搭建的**

AgentKernelArena共收录了196个优化任务，涵盖三种不同类型的挑战，分别针对不同层次的难度和能力。

第一类称为"HIP转HIP"，共24个任务。HIP是AMD为GPU开发的一种底层编程语言。在这类任务中，AI代理拿到的是一段已经能跑起来的HIP内核代码，任务是想办法把它变得更快。涵盖的运算类型包括各种激活函数（GELU、SiLU、Sigmoid等）、多头注意力机制、层归一化、矩阵乘法以及各种损失函数，均来自GPU Mode开源社区。这类任务的难点在于，代理需要真正理解底层代码，并施加有意义的优化，而不是随意乱改。

第二类称为"Triton转Triton"，共148个任务，是三类中任务数量最多的。Triton是一种相对高层的GPU编程语言，由OpenAI开发，它的编程模型更像是"告诉GPU每次处理多大的数据块"，而非细致操控每一个线程。在这类任务中，代理拿到一段Triton内核，目标同样是提速。任务来源包括两部分：118个来自vLLM推理引擎（一个广泛用于部署大语言模型的开源系统），涵盖混合专家路由、量化计算、分页注意力、矩阵乘法等核心运算；另有30个来自ROCmBench基准套件，覆盖元素级运算、归约、归一化、GEMM变体等。这类任务的优化空间主要集中在自动调优参数（比如每个数据块的大小、线程束数量、流水线阶段数）以及AMD专属的调度参数上。

第三类称为"PyTorch转HIP"，共24个任务，是难度最高的一类。PyTorch是一个广泛使用的深度学习框架，用它写代码非常简洁，但运行效率往往不如手写GPU内核。在这类任务中，代理拿到的是一个用PyTorch写的模块，任务是凭空写出一个功能等价的HIP内核来替代它。这要求代理不仅要理解高层代码的语义，还要自己设计线程分配方案、管理显存、编写Python绑定接口——整个过程如同把一张建筑设计草图直接转化为施工现场可用的精确施工图，难度大幅提升。

每一个任务都是一个完全独立的"工作间"，包含内核源代码、评测脚本和配置文件。AI代理在这个隔离的工作间里拥有完整的命令行权限，可以自由编译、测试、测速，但无法访问其他任务或其他代理的结果。每次实验都创建一个带时间戳的独立副本，确保结果可复现、不互相污染。

评测流程分三个门控阶段依次进行：首先检查内核能否成功编译；编译通过后才运行正确性检验，确认输出结果与参考实现在允许误差范围内吻合；正确性通过后才进行性能测试，用10次预热加100次正式计时来精确测量执行时间。最终速度提升比例的计算方式是用原始基准时间除以优化后时间——比值越大，代表优化效果越好。任何一个门控阶段失败，后续阶段就不再执行。

评分规则也经过精心设计：成功编译得20分，正确性通过得100分，在此基础上再叠加100乘以速度提升比例的分数。这样设计的好处是，哪怕一个内核跑出了所谓的高速度，只要它产出的结果是错的，就永远比不过任何一个结果正确但速度平平的内核——杜绝了靠"取巧"刷分的可能性。

**四、泛化能力测试：揭开速度背后的秘密**

AgentKernelArena最独特、也最有价值的一项设计，就是"未见配置泛化评估"。

具体做法是这样的：对每一个任务，研究团队额外生成了8个AI代理从未见过的输入规格，涵盖六大类型。第一类是边界极端情况，比如批量大小为1，或者某个维度恰好等于内核里定义的数据块大小。第二类是放大规模，维度扩大两到四倍以上。第三类是缩小规模，维度缩减到原来的几分之一。第四类是"对齐压力测试"，使用质数或非2的幂次方的维度，比如37、131、4003——这些数字会让很多依赖"2的幂次方假设"的内核出现问题。第五类是极端宽高比，比如行数为1但列数达到65536。第六类是生产环境中真实Transformer模型使用的典型数据形状。

这些未见配置的具体数值不对外公开，以防止未来的参评者根据这些数值进行针对性训练；但生成这些配置所用的脚本是开源的，任何人都可以复现这一测试协议、检验其偏差，或者扩展到新的任务类型上。

评估时，系统会把相同的未见配置同时注入两个工作间副本——一个跑优化后的内核，一个跑原始内核——然后比较两者的正确性和速度。每个任务的结果被归入四个象限之一：两者都通过、优化反而出错（退步）、两者都失败（说明这个配置超出了内核的设计范围）、或者优化后反而更健壮（进步）。核心指标是"条件正确率"，即在原始内核本来就能正确处理某个配置的前提下，优化后的内核能否同样正确处理——这个指标排除了配置本身超出内核能力范围的干扰，聚焦于优化行为本身是否引入了新的脆弱性。

**五、实验结果：AI代理的真实成绩单**

研究团队在AMD Instinct MI300X这块高端GPU上，使用ROCm 7.1.1软件栈，对三款主流AI代理——Cursor Agent、Claude Code和Codex Agent——进行了全面测试，每种代理使用多个不同的底层大语言模型，每个配置在每个任务上独立运行三次，取平均值后再汇总统计。每个代理的最长运行时间为3600秒，每次任务最多迭代三轮优化。

在编译率和正确率方面，几乎所有配置都表现出色，编译成功率接近100%，大多数配置在HIP转HIP和Triton转Triton类别上的正确率都在91%以上。唯一的明显例外是Cursor Agent搭配GPT-5.4模型在PyTorch转HIP任务上，编译率骤降至约69%，24个任务中大约有7个反复出现编译失败，主要是因为这个模型在生成Python绑定接口时容易遗漏或写错关键的模块入口函数。相比之下，Claude Code的Opus和Sonnet系列、Cursor的Opus系列以及Codex Agent在同样的PyTorch转HIP任务上都能保持95%到100%的编译率，说明正确处理底层绑定代码的能力在不同模型之间差异显著。

在速度提升方面，三类任务的表现有明显的层次差异。

PyTorch转HIP类别的速度提升最为亮眼，各配置的平均加速比在3.74倍到6.89倍之间，几何平均数在2.19倍到4.64倍之间。这一成绩看起来惊人，但背后有一个重要原因：PyTorch eager执行本身是一个相对低效的基准，AI手写的HIP内核绕过了PyTorch的许多开销，自然容易大幅领先。在这一类别中，Cursor Agent搭配Opus 4.6（6.89倍平均加速）和Opus 4.7（6.65倍）是最强组合，100%的任务达到了超越基准速度的目标，75%以上的任务实现了两倍以上的加速。

HIP转HIP类别的加速效果参差不齐，平均在1.44倍到6.69倍之间，几何平均数在1.33倍到3.31倍之间，标准差很大。这反映了一个现实：有些内核本来就已经相当高效，优化空间非常有限；而另一些内核（比如注意力机制相关的实现）存在明显的改进余地，AI代理能够施展更多手脚。在这一类别中，Claude Code搭配Opus 4.6达到了最高的6.69倍平均加速，在多个指标上领先其他配置。高能力模型普遍采用了向量化加载（一次读取四个浮点数）、Warp级别的规约操作、内核融合以及启动参数调优等优化手段；而能力较弱的模型则主要停留在调整线程块大小和循环展开层面。

Triton转Triton类别是最难啃的硬骨头，各配置的平均加速比只有1.59倍到2.13倍，几何平均数更是低至1.01倍到1.31倍，达到两倍加速的任务比例在所有配置中都低于11%。这并非AI代理能力不足，而是Triton语言本身的特性使然——Triton的编译器已经做了相当多的自动优化，留给手动干预的空间本来就不大。在这一类别中，Cursor Agent的Opus 4.7是最强配置，平均加速2.13倍；Claude Code的Opus 4.6以2.11倍紧随其后。这类任务的主要优化手段集中在自动调优配置文件的调整上：修改数据块大小、线程束数量、流水线阶段数，以及AMD MI300X特有的waves_per_eu（每个计算单元的波阵面数）和matrix_instr_nonkdim（矩阵指令的非K维度）等参数。

从agent平台和模型两个维度来看，Claude Code的Opus 4.6在HIP转HIP任务上拿下最高分，在其他两类也极具竞争力。Cursor Agent的Opus 4.7是Cursor平台最强配置，在Triton转Triton上位居第一，在PyTorch转HIP上的几何平均加速也最高。Codex Agent搭配GPT-5.3-Codex的表现相当均衡，在三类任务上分别取得3.61倍、1.68倍和5.20倍的加速，与使用类似模型的Cursor Agent大体相当。从token消耗量来看，Claude Code是最"话多"的代理，每个任务平均输出3.9万到8.6万个token；Cursor Agent居中，每任务约0.8万到2.5万token；Codex Agent最为简练，每任务约1.3万到1.7万token。token消耗量与速度提升效果大体上正相关，但这种关联并非线性——多说话不一定成比例地多获益。

**六、泛化测试揭示的惊人差距**

未见配置的泛化测试结果，把三类任务的真实可靠性差距彻底暴露出来，也是整个研究最有冲击力的发现。

HIP转HIP类别在泛化测试中表现最为稳健，条件正确率在93.6%到100%之间。不仅如此，有几个配置在未见配置上的速度提升比例反而比已见配置更高，说明这些优化策略本身具有良好的通用性，有时甚至能在更大的数据规模上发挥出更多潜力（因为更大的问题规模能够更充分地利用GPU的并行资源）。Cursor搭配Opus 4.7在这一类别达到了100%的条件正确率、零退步，堪称完美。

Triton转Triton类别的泛化也相当可靠，条件正确率在90.9%到99.4%之间，速度提升的泛化缺口（已见配置加速比与未见配置加速比之间的差距）在所有配置上都小于10%。这与Triton语言的设计哲学契合：Triton的编程模型天然是以"数据块"为单位的，对数据形状的依赖性相对较低，只要块大小参数设置合理，针对不同形状的数据都能正确运行。

然而，PyTorch转HIP类别在泛化测试中遭遇了明显滑铁卢，条件正确率跌落至59.7%到90.3%之间，有些配置的测试退步率高达40%。这意味着：即使一个AI代理在已见配置上实现了完美的正确性和可观的加速，也可能有将近一半的任务在换了输入形状后就会失效。

失败的根本原因在于"硬编码假设"。AI代理在从PyTorch代码从头生成HIP内核时，往往会根据测试集里出现的具体数值来设置内部常量，而不是写成通用的动态计算逻辑。比如测试集里批量大小最大是32，代理就把"MAX_ROWS = 32"写死在共享内存分配里；测试集里通道数最大是32，代理就把"MAX_C = 32"写死在数组声明里。在测试集范围内，一切运行正常。但一旦出现批量大小为64或通道数为37的未见配置，程序要么直接崩溃，要么默默产出错误的结果。

从模型维度来看，Cursor搭配GPT-5.4 High是最容易出现这类问题的配置，8到11个任务（约54%到67%）在未见配置上退步；Cursor搭配Opus 4.6 High表现最好，保持了92%的条件正确率；Codex搭配GPT-5.3-Codex也达到了88%到92%。有趣的是，这个排名与编译成功率的排名高度一致——越是容易在编译阶段出问题的模型，越是倾向于在代码里硬编码形状相关的常量，两者似乎共享同一类缺陷：对程序通用性和健壮性的理解不够深入。

Triton转Triton类别的泛化失败案例虽然较少，但机制别具一格。有一个任务，代理使用了一个依赖"输入数必须是2的幂次方"的直方图操作，而这个约束在原始测试集里碰巧从未被违反，所以测试通过了。但未见配置里出现了37这个质数，直接触发了运行时错误。另一个案例里，代理的分块策略在特定序列长度下会积累数值误差，标准形状没问题，但非标准序列长度上误差超出了容忍范围。

**七、框架的可扩展性设计**

AgentKernelArena在设计上特别注重可扩展性，任何研究者或工程师都可以相对轻松地把新的内容加入进来。

接入一个新的AI代理只需要提供两个文件：一个Python脚本，负责用装饰器注册启动函数，接收配置信息和工作目录并调用具体的代理工具；另一个YAML配置文件，指定模型名称、超时时长等参数。加入之后，这个新代理会自动使用框架的集中化评测流水线，无需修改评分逻辑。

添加一个新任务则需要创建一个独立目录，里面包含源代码文件、YAML配置（指明哪些文件需要优化、目标函数是什么、编译/测试/性能评测命令各是什么）以及相应的评测脚本。框架通过文件系统自动发现所有任务。

支持新的GPU架构只需要在一个YAML文件里增加架构条目，写明架构标识（比如AMD的gfx942对应MI300X），并提供相应的架构说明文档和最佳实践文档。全局配置文件里切换目标GPU型号后，代理就会在提示词里收到对应的硬件参考资料。目前框架已经内置了MI300X和MI355X两款AMD GPU的配置。

每个任务的提示词由八个部分组成：任务类型的角色定义（告知代理它是一个Triton专家还是HIP专家）、需要优化的源文件路径和目标函数名、GPU架构预检指令（提醒代理检查并更新编译脚本中的硬件目标标识）、任务特定的优化指导、完成后的规范（禁止代理自行写入评分文件）、硬件和语言参考资料（完整的架构说明和最佳实践文档）、工作目录路径，以及迭代指令（软性要求代理完成至多三轮优化）。其中迭代指令是自然语言形式的"请你完成三个版本的优化"，而非强制限制工具调用次数——代理在每一轮内部可以执行任意多次编译和测试。

**八、研究的现实意义与内在局限**

这项研究最直接的价值在于：它为AI编程代理在GPU内核优化这一高度专业化领域提供了第一套系统性的、考虑泛化能力的评测基准，使得不同代理和模型之间的比较有了统一的标准。

实用层面，结果表明生产级AI代理已经能够在多数任务上实现可观的加速，尤其是从PyTorch代码生成高效HIP内核这类任务，加速效果非常突出。这对于希望降低AI推理成本的企业和研究团队而言，意味着AI辅助的内核开发工具已经具备了一定的实用价值，可以作为人类工程师的有益补充。

然而，泛化测试结果也发出了清晰的警示：在将AI代理生成的内核部署到生产环境之前，必须在多样化的输入规格下进行充分的正确性验证，而不能仅仅依赖开发测试集上的通过率。硬编码形状假设是一个系统性问题，在不同的代理和模型中普遍存在，程度不一。

研究的局限性也很明确。整个实验只在一块AMD MI300X上进行，不同的GPU架构（比如NVIDIA的显卡）上结果可能有所不同。实验中每个任务只跑了三次、每个代理只迭代三轮，主要受限于API调用成本。开源权重模型曾被纳入测试，但在单次迭代调用中因为需要处理多文件上下文而普遍编译失败；要让这类模型也能像商业代理一样在完整的迭代反馈环路中运行，需要额外的工程工作，这部分留待未来研究。专门针对内核优化设计的系统（如GEAK、AutoTriton等）由于架构与通用编程代理有本质差异，没有被纳入本次比较，但框架本身支持将其接入。任务集目前主要来自vLLM和GPU Mode社区，研究团队表示正在积极扩充来自AITER等代码库的任务。

说到底，AgentKernelArena这项研究的核心贡献在于：它把"AI代理能不能真正优化GPU内核"这个问题从模糊的印象变成了可测量的数据，并且首次系统地追问了"AI优化出来的代码，在新情况下还靠谱吗"——而这个追问的答案，在某些场景下相当令人警觉。

当AI代理在测试集上交出漂亮成绩单时，我们固然应该为技术进步感到欣喜；但当我们知道其中相当一部分"优化成果"只是把测试数据里的具体数字悄悄写死在了代码里，就必须思考：在真实的工程部署中，我们需要什么样的验证流程，才能让AI生成的代码真正值得信赖？

对于普通人而言，这项研究最直接的影响可能体现在未来AI应用的运行速度和成本上。随着更好的评测工具推动AI代理在GPU优化领域持续进步，每一次模型推理的电力消耗和等待时间都有望进一步降低，最终让AI工具变得更加普惠。如果你对这一领域有进一步兴趣，可以通过论文编号arXiv:2605.16819查阅完整原文，或者在GitHub上搜索AMD-AGI/AgentKernelArena获取开源代码和任务集。

**Q&A**

Q1：AgentKernelArena评测平台与KernelBench等已有评测工具的主要区别是什么？

A：AgentKernelArena与KernelBench等工具的核心区别有两点。第一，AgentKernelArena评测的是能够反复编译、测试、改进的完整代理工作流，而非单次代码生成的结果，更贴近真实工程场景。第二，AgentKernelArena引入了"未见配置泛化评估"，专门检验AI优化出的内核在从未见过的输入形状下是否仍然正确可用，而现有工具均不包含这一关键测试，导致会遗漏"硬编码形状假设"这类隐患。

Q2：PyTorch转HIP任务上AI代理的泛化失败是什么原因造成的？

A：主要原因是AI代理在从头生成HIP内核时，往往把测试集里出现的具体数值（比如最大批量大小、通道数）直接写成固定常量，而非编写能动态适应任意输入尺寸的通用逻辑。这样生成的代码在测试集内完美运行，但一旦遇到更大或形状不同的输入，就会因为超出硬编码的上限而崩溃或产出错误结果。不同模型受这一问题影响的程度差异明显，能力越强的模型（如Opus系列）相对更少出现这类问题。

Q3：AI代理在Triton转Triton任务上为什么加速效果远低于HIP相关任务？

A：这主要是由Triton语言本身的特性决定的，而非代理能力不足。Triton的编译器会自动处理大量底层优化，程序员（或AI代理）能够直接干预的优化空间本来就比手写HIP代码小得多。在HIP任务中，代理可以精细控制内存访问方式、线程协作模式、指令选择等底层细节；而在Triton任务中，代理主要能调整的是数据块大小、线程束数量、流水线阶段数等高层参数，可操作的范围有限，因此整体加速比普遍偏低，大多数配置的平均加速比在2倍以内。