FRONTIER · 工程实践

十个单元测试换一款新芯片的软件栈——agent 在训练数据里几乎没有的 Blackwell 上，写出了比专家手写 Triton 更快的算子

Hawkeye: Hardware-Aware GPU Kernel Optimization with Minimal Supervision

Arya Tschand、Kesavan Ramakrishnan 等 9 人 哈佛、斯坦福、Together AI、Caltech 的联合团队。通讯作者 Vijay Janapa Reddi 是哈佛教授、MLPerf 基准的发起人之一；合作者 Azalia Mirhoseini 主持过 Google 用强化学习做芯片布局的 AlphaChip 工作，Simran Arora 和 Simon Guo 是 KernelBench（衡量 LLM 能不能写出高性能 GPU 算子的基准）的作者——这批人同时站在「造基准」和「造硬件」两头

2026 年 8 月

为什么选它「让 AI 写 GPU kernel」的论文这两年一大把，多数在 A100、H100 上刷分。这篇换了个更难的问题：一款新芯片刚出、专属指令在训练数据里几乎为零时，agent 还写不写得出来。答案是能，人类的代价是十个单元测试。它顺带证伪了一个很多人正在做的事——把厂商文档整本塞进上下文，效果不如不塞。

这是 8 月 20 日挂到 alphaXiv 的一篇系统论文，九位作者来自哈佛、斯坦福、Together AI 和 Caltech。它问的问题很窄，答案却出人意料：要让 coding agent 在一款刚出的芯片上写出接近专家水平的 GPU kernel，人类需要提供的知识量，大约是十个单元测试。不是十万行厂商文档，不是几百个示例算子，是十个——每个只演示一种优化手法，配一段最小的参考实现和一个可以量出来的性能指标。

值得读的地方在于它同时证伪了一个很多人正在做的事。把文档整本塞进 agent 的上下文，效果不是打了折，而是不如不塞。论文把几种给 agent 喂硬件知识的方式摆在一起比——原始文档、Triton 这类 DSL 写的样例、CUTLASS 那种生产级 kernel 的 few-shot 示例——结果只有 Hawkeye 这套结构能让性能随着 agent 的迭代轮数持续上涨，其余几种都会在某处撞到天花板。这和本栏第 53 篇是同一个调子：模型没换，换的是它周围那副脚手架，而脚手架决定了上限。

「硬件感知」缺的不是聪明，是没见过

作者给「硬件感知」下了个很具体的定义：知道这块芯片上存在哪些专属优化，并且知道怎么把它正确写进 kernel 里。前沿模型在这件事上普遍不行，而且越新的硬件越不行。作者自己列的原因很朴素——训练数据少得多、语法更难更啰嗦、架构更复杂。Blackwell 的新指令、AMD MI350 的写法，在模型见过的公开代码里几乎不存在，于是它退回自己熟悉的老套路，把矩阵核心和共享内存大片晾在那儿不用。

这不是个学术问题。每出一款新加速器，软件栈的适配都要专家花几个月手写，而工作量是按「算子 × 精度」的组合数长的。芯片一年一代，低精度格式（FP8、NVFP4、MXFP4）又在快速分化，硬件能力和软件实现之间那道缝正在变宽——芯片流片了，却没人能在第一天把它喂饱。

一张二维表，把知识切到最小单位

Hawkeye 的核心是一张表：行是优化手法（向量化访存、异步数据流水、生产者/消费者切分、warp 级归约这类反复出现的套路），列是架构（Ampere、Hopper、Blackwell、AMD MI350）。每个格子里放四样东西：一个刻意不用该硬件特性的朴素 kernel、一个专家手写的最小优化版、一份指明该看哪个 profiling 指标的配置、一段简短的说明。

关键在「最小」两个字。专家的工作量因此从 O(算子 × 精度) 降到了 O(优化手法数)——支持一款新芯片，不是重写一遍所有算子，而是写十个单元测试。论文对「这个单元测试算不算数」还定了硬标准：它必须既让对应的硬件利用率指标上升，又带来端到端的加速，光看着像用上了不算。

agent 拿到的不是这张表本身，而是一个能编译、能跑、能 profile 的沙箱。它的循环是：改代码 → 编译 → 在真卡上跑一遍、和 PyTorch 的结果对数值 → 用 Nsight Compute 或 rocprof 量硬件利用率 → 跟表里的理想值比，找出还没吃到的那个特性 → 翻到对应格子读那个单元测试，把它拼进去。整个过程里 agent 不需要「懂」硬件，它只需要能看出自己还差哪一格。

数字：18.9 倍、1.22 倍，和一句「还有很大空间」

在 torch.compile 能直接派发到 cuBLAS、cuDNN、FlashAttention 的标准算子上，Hawkeye 打平或略胜，包括几种 PyTorch 根本跑不了的低精度格式。真正拉开差距的是没有现成库可用的新型注意力变体（线性注意力、DeltaNet、Forgetting Attention 这类）：torch.compile 融不了它们那些非标准的 scan 和 gate，Hawkeye 在这里拿到约 18.9 倍的几何平均加速。更值得看的是另一条线——和专家手写的 Triton FLA 库比，Hawkeye 在每个架构上都接近或超过它，Blackwell 上 1.22 倍、MI350 上打平。

Blackwell 和 MI350 这两列尤其说明问题——这两款芯片的专属指令基本不在模型的训练数据里，agent 是靠那十个单元测试现学的（扩展实验用的是 Gemini 3.1 Pro 和 GPT-5.4 这个级别的模型）。作者自己补了一句：还有很大空间。这话应该当真——这套东西是把专家水平变便宜，不是把专家取消掉。

论文还记了一个容易被忽略的观察：kernel 优化的收益是不连续的。性能会长时间纹丝不动，直到某条架构专属指令被正确写出来，然后突然跳一级。这也解释了为什么光让 agent 多迭代没用——平台期上它拿不到任何反馈，只有 profiling 指标能告诉它「你以为用上了，其实没有」。

为什么塞文档反而更差

这是全文最有迁移价值的一段，哪怕你这辈子不会碰 CUDA。原始文档信息量最大，但相关的那几页淹在无关内容里，agent 找不着北；CUTLASS 那种生产级示例质量最高，但算法逻辑和硬件细节死死缠在一起，拆不出可迁移的部分；Triton 这类 DSL 最省事，但对新硬件特性的支持总要滞后一截。三者都会随迭代轮数增加停在天花板上，只有拆成独立最小单元的那种能一直往上爬。换句话说，喂给 agent 的知识，可组合性比完备性重要。

最后一句实话：这套框架没把人从环里拿掉。给一款全新芯片写出那张表的第一列，仍然需要真懂硬件的人，而且要懂到能把一种优化手法剥离成最小的、可验证的样例。变的是这活儿只用干一次，之后所有算子、所有精度的适配都由 agent 接手。论文称框架会开源，作者说代码即将放出。

先说它跟本栏第 1 篇的紧张关系。「苦涩的教训」说的是：往系统里注入人类知识，短期有效，长期都会被算力碾平。Hawkeye 看起来正好相反——它靠十个人写的单元测试拿到了性能。但仔细看它注入的是什么：不是「这个算子该怎么写」，而是「这块芯片上存在哪些可以被 profiling 指标验证的优化」。这是一份可验证的搜索空间说明书，不是一份答案。人负责把空间划出来，算力负责在里面搜。这恰恰是苦涩教训认可的那一类知识注入——它没有替 agent 做决定，它让 agent 的迭代第一次有了方向。真正的新东西，是「专家监督」的计价方式变了。过去支持一款新芯片，成本按「算子 × 精度」的组合数走，几十个算子乘上四五种精度，就是好几个专家人月；现在按「优化手法数」走，十个单元测试封顶。这是一次从乘法到加法的降级，它改变的不是性能上限，而是谁付得起这个上限。受益最大的不是英伟达——它养得起 CUTLASS 团队——而是所有做非主流加速器的人，以及所有想试试非标准算子的研究者。软件生态一直是新芯片最硬的护城河，这篇在护城河上凿了个口子，能凿多大还不知道。该打的折要说清楚。论文比的是 torch.compile 和 FLA，都是很强的基线，但不是绝对上限——真正压榨到底的手写 CUTLASS/CuTe kernel 没进对比表，作者自己也说还有很大空间。另外这套流程有个隐性前提：你得有那张真卡，而且能在上面反复跑 profiler。这里的 test-time compute 不是几十次文本采样，是几十上百轮「编译—运行—profile」的真实 GPU 占用；再加上前沿模型的调用费，这笔账不是每个团队都算得过来。还有一层它没写，但躲不开。让 AI 写更快的 kernel，等于让 AI 加速 AI 训练本身——这是 AI R&D 自动化里最短的一条反馈回路。本栏第 53 篇讲自动化后训练，第 51 篇讲 AI 参与算法发现，这篇是同一张地图上更靠底层的一格：模型正在学着优化跑自己的那台机器。Hawkeye 目前还老实待在「人给表、机器搜」的边界里，可这条回路一旦被拉长成「机器自己补表」，性质就变了。

GPU kernelcoding agent硬件适配test-time computeAI for systems

去读原文 本文是原创导读，不是原文翻译——真正的细节、证据和微妙之处都在原文里。原文论文 · Hawkeye: Hardware-Aware GPU Kernel Optimization with Minimal Supervision（alphaXiv，2026 年 8 月 20 日）→

上一篇1200 个本该互相隔离的 agent 自己建了个论坛，发了七万条消息——然后为了骗过一个根本不存在的打分器，去打了 Hugging Face 下一篇在开源模型上用梯度练出的一串乱码，贴到闭源模型后面照样管用——而最好的那道防线，只把成功率从九成压到四成

本文为 AKL AI Club 原创撰写的导读，不是原文翻译；著作权归原文作者所有。篇目由编辑独立选取，来源均经人工核实。