正确率会把内核写手抬高：阿里 Atrex-Bench 用生产时长给 GPU 内核打屋顶线分

正确率会把内核写手抬高：阿里 Atrex-Bench 用生产时长给 GPU 内核打屋顶线分

只看编译过了、数值对了，会把「调用了现成算子」算成「自己写出了内核」。2026 年 7 月 16 日，阿里巴巴集团 ATREX 团队在 arXiv 放出 Atrex-Bench（用生产推理轨迹抽样、再用屋顶线打分的 GPU 内核生成基准）。题目不从合成算子里挑，而从线上服务的真实形状里来。分数按这些算子在生产里占了多少 GPU 时间来加权，所以做对一个冷门算子，几乎抬不动总分。

作者是 Lingyun Yang、Yuxiao Wang、Shenghao Liang、Linfeng Yang、Daocheng Ying、Chunbo You、Rui Zhang、Luping Wang、Yinghao Yu、Guodong Yang、Liping Zhang，单位写的是 ATREX Team, Alibaba Group。代码仓库在论文注释里写为 alibaba/atrex-bench 和 alibaba/atrex-kernel-agent。下面按论文顺序整理题怎么来、分怎么算、六套编码智能体的数字，以及作者标明的范围。

合成题回答不了能不能上生产

论文把问题收成三句：现有内核基准的题从哪来，和线上负载差多远；正确通过之后，有多少时间其实花在 PyTorch 回退或预编译厂商算子上；怎样才算够好，是靠近硬件屋顶，还是超过已经部署的生产内核。

相关工作里，KernelBench 把任务定义成「交一个又对又快的后端」。后续基准把题库改到约 285 道，并把评测搬到 NVIDIA L20、华为昇腾 NPU 等平台。Atrex 不跟这些榜比名次。表 1 只用来标能力：题是否来自生产轨迹、有没有按算子的生产时间加权、有没有逐题屋顶线、有没有把目标 DSL 的占比单独记下来。

实验主平台写作 XPU-A。目标语言故意选 FlyDSL。论文说它基本不在这些模型的预训练语料里，用来看模型能不能照着给的参考学会一套陌生编程模型，而不是回忆见过的 CUDA 或 Triton。提示框架也支持 Triton、Gluon、CuteDSL，这一版没有跑。

题从超过一万张卡的轨迹里来

这一版的轨迹采自选定的 XPU-A 和 H20 推理集群，部署加速器超过 1 万张。追踪器挂在正在跑的负载上，不重启服务，也不在应用里插桩。它把 Python 帧（算子阶段、batch 和 token 形状、框架状态）和厂商运行时轨迹（内核启动、计时、流、内存操作、图锚点）对在一起。有关联 ID 就用关联 ID，否则用时间戳或图锚点。这样能看出哪个框架操作打出了哪个设备内核、当时的服务形状是什么。

原始内核记录先收成计算级的算子族，而不是框架自己的内核名。vLLM、SGLang、AITER、RTP-LLM 里语义相同的算子可以共用一道题。每个保留下来的（算子，形状）在 metadata.json 里留上游出处。

每个算子用一份与硬件无关的 PyTorch 参考实现 reference.py，并拿生产内核校验。形状优先用轨迹里的张量维度；没有的话，固定的模型维度从部署配置恢复，token 数和 batch 这类动态维度用部署里常见的值。轨迹里近重复很多，所以架构固定的维度保持原样，动态 token 维度从单 token 解码分桶到长上下文预填充。这一版是 30 个算子、440 个形状。

每个（算子，形状）还记下生产框架内核在线上观察到的运行时间，当作部署基线，也用来核对屋顶线有没有离谱。算子带阶段标签：prefill、decode，或两者都有。

1,303 份生产 profile，覆盖上述四个服务框架。权重很斜：前五个算子大约占 64%。unified_attention 36.1%，fused_moe 10.4%，block_scaled_mm 8.5%，fp8_blockscale_fused_moe 4.7%，paged_attention_decode 4.0%。前十大约占 80%，剩下 20 个算子合计 20.4%。权重会在用新轨迹刷新基准时重算。

形状数不等于重要程度。rms_norm 有 56 个形状，权重只有 2.5%；paged_attention_decode 只有 8 个形状，权重 4.0%。所以总分按权重加，不按形状条数平均。做对 50 个 RMSNorm 变体、做砸注意力，不应该排在相反的结果前面。

精度也不单一。30 个算子里 bf16 有 19 个，fp8_e4m3 有 5 个，fp16、fp32、int32 各 2 个。fused_moe 是 bf16，fp8_blockscale_fused_moe 是 fp8_e4m3。硬件峰值必须按 dtype 分开标定。静默升精度躲不过正确性门，因为比对发生在参考实现声明的 dtype 上。

440 个形状来自大约 20 个生产模型部署，包括 Qwen3 MoE、DeepSeek-R1、Qwen3-VL、QwQ-32B、Qwen3-32B、Qwen3-8B。公开元数据涂掉了精确模型身份。按主要上游框架分，形状是 vLLM 292、SGLang 90、RTP-LLM 38、AITER 20。XPU-A 上记录的生产基线后端是 AITER 266、SGLang 151、RTP-LLM 23。这个倾斜是被追踪集群的部署结构，不是人为配平。

算术强度差到不能用一个制度概括。440 个形状里，大 batch 的 GEMM 和注意力可以 AI > 100，偏计算；rms_norm、silu_and_mul 的 AI < 1，怎么加 token 都是带宽瓶颈；reshape_and_cache、topk_filter 不算算术。一个大 batch 的 fp8_blockscale_fused_moe 形状大约 4000 亿 FLOPs、约 7 GB；一个单 token 的 fused_qkv_rope 大约 1.5 万 FLOPs、约 29 KB。同一套题同时覆盖两种制度。

生成时看得见的，和打分时才拿出来的

每个算子一个目录，五份固定文件。

可比的默认运行只开放本地工作区查看、搜索、编辑，以及用 shell 做构建和测试。网页检索、笔记本编辑、委派和辅助智能体工具排除在外。故意打开这些工具的优化实验单独成组，不和默认同榜。

评测时把生成文件放进一套新环境，里面才有完整基准状态。模型读不到的东西，不能拿来判分。这样既不能按名字把上游内核源码捞回来，也不能对着屋顶线分母去拟合。算子权重是发布级文件，换一批轨迹重加权时不必改每道题。

屋顶线是硬件下界，不是模型自己的曲线

先把加速器的计算吞吐和内存带宽峰值标定一次，记成发布常量。再由参考实现给出这道题的语义工作量 F 和访存量 M。对目标加速器、该 dtype 的计算峰值 P 和带宽 β，光速时延是两者的较大值：F/P 与 M/β。这个时间写进 roofline.json，当每题的分母。它来自参考语义，不来自候选自己的 profile，并且所有候选共用。

单题成就 S = 光速时间 / 候选实测时间，范围在 0 到 1。大于 1 视为单位不一致、测量错误或界限无效，当评测错误，不截断成 1。编译失败或对不上参考时，这题的 S 不定义。

算子级先取做对的那些形状的中位数。一个算子一个正确内核都没有，记 0，不能从总分里悄悄拿掉。当前发布里，每个算子的形状数从 3 到 56。

总分是重要性加权：Sagg = Σ wi × Si。它高，只说明又快又对的内核落在占生产时间的算子上。做对冷门算子几乎不动它；做砸重算子，整段权重都是 0。论文用加权算术平均，不用几何平均，因为几何平均会在一个 Si = 0 时变成 0，把其余信号抹掉。

权重本身按应用和阶段拆开。设应用 a 占集群卡时的比例是 pa，合计为 1。算子 i 在应用 a、阶段 φ（prefill 或 decode）上的设备时间，是它名下各内核每次调用时长之和。这个时间除以该应用该阶段的总设备时间，就是时间份额。只跑一个阶段的算子用这一份；两个阶段都跑的，把两份简单平均，再按 pa 加权，最后在纳入这一版的算子上归一化，使权重合计为 1。调用次数已经体现在时长求和里，不再另乘一遍。

三道门，以及六套模型

每份提交过三道门：编译；正确性，在随机输入和角落输入上跟 reference.py 做数值等价；性能，在受控沙箱里测，有显式的锁频检查、每轮迭代清 L2、每个形状单独子进程。只有走到性能门的内核才贡献 S。评测器返回逐形状的端到端时延。

正确性对 eager 参考跑 K = 5 个随机种子，atol = 10⁻²，rtol = 5×10⁻²。五个种子都过，这个形状才算对。性能取预热之后端到端前向时间的中位数。

通过率先在算子内部汇总形状，再对 30 个算子平均，所以形状多的算子不能靠条数压过形状少的。时间比用算子中位数，避免一个离群算子主导。

六个候选是 Claude Opus 4.7、GPT-5.5、Qwen3.7-Max、Kimi-K2.6、GLM-5.1、DeepSeek-V4-Pro，都跑满 30 个算子、440 个单元。除 GPT-5.5 用它自己的 Codex 运行时，其余运行时固定为 Claude Code，提示和工具集相同。论文说这样比的是基座模型，不是 harness。两个参照不是候选：把参考实现交给 torch.compile，以及每个算子已经部署的生产内核（AITER、vLLM、SGLang 或 RTP-LLM）。

指标口径要分开看：

• 编译率：各算子（编译成功的形状 / 形状数）的平均。完成提前编译的 MLIR 产物才算编译成功，光能 import 不算。
• 正确率：各算子（正确形状 / 形状数）的平均。没编译过的算不正确。
• FlyDSL 采用率：前向设备时间里，花在 @flydsl.kernel 中的比例，再按算子平均。用来把「目标 DSL 占主导」和「主要丢给 PyTorch 或预编译厂商算子」分开。
• Sagg：上面的生产权重加权屋顶线。编译率、正确率对全部 30 个算子平均，整算子失败记 0。FlyDSL、算子中位 S 和时间比只在有定义的算子上算，没有跑起来或没有做对的算子是排除，不是记 0。因此表里的算子中位 S 是模型自己做对的那些算子上的内部摘要；会惩罚失败、又按生产时间加权的，才是 Sagg。

表 4 是 XPU-A 上的主结果。通过率是百分比。Sagg 无单位。对照列是相对 torch.compile（t.c.）和生产内核的倍数，大于 1 表示候选更快。

编译率从 60.9% 到 100%。正确率从 Opus 4.7 的 92.0% 到 GLM-5.1 的 46.2%，大约差 45 个百分点。FlyDSL 把场子再切开：Opus 4.7 和 GPT-5.5 的设备时间有 78.5% 和 71.6% 在 FlyDSL 里，另外四个都低于 44%。Qwen3.7-Max 正确率 84.8%，FlyDSL 只有 43.8%。

不加权的算子中位屋顶线，GPT-5.5 是 0.129，Opus 4.7 是 0.104。换成 Sagg 之后是 0.107 对 0.059，大约 1.8 倍。差距拉大是因为 Opus 在常见的、多半带宽受限的算子上能靠近屋顶，在 Sagg 加重的那些重计算算子上中位数只有 0.009，GPT-5.5 是 0.074。绝对水平仍然低：最好的 Sagg 也只有 0.107，大约是参考语义推出的硬件屋顶的 10.7%。论文摘要里的「最好的原样模型大约只到屋顶的 10%」指的就是这个数。

只有 Opus 4.7 和 GPT-5.5 在算子中位数上快过 torch.compile，分别 2.29 倍和 3.06 倍。Qwen3.7-Max 是 1.10 倍，刚过线。没有一个候选在这列上超过已部署的生产内核。Opus 4.7 最接近，0.99 倍；GPT-5.5 是 0.85 倍；最远到 DeepSeek-V4-Pro 的 0.12 倍。正确通过生产算子，不等于有生产性能。

正确率里有多少不是自己写的

编译门放得过 PyTorch 回退和预编译厂商内核，所以模型可以正确率很高、FlyDSL 很少。图 2 数两件事：完全正确的算子个数，以及设备时间里 FlyDSL 超过 50% 的算子个数。

中间几家大约一半「正确」算子走的不是目标 DSL：注意力用 scaled_dot_product_attention，GEMM 用预编译的 AITER 入口。Opus 4.7 是负差额，FlyDSL 占主导的算子比完全做对的还多，论文把它当成目标 DSL 占主导、而不是回退的特征。

难度更像算子的属性，而不是某一个模型的短板。把六个模型在每个算子上的形状通过率再平均，最难的是 fp8_blockscale_fused_moe，22.2%；其后 fused_rmsnorm_quant 34.8%，per_token_group_quant_fp8 44.7%，attention_forward 45.2%，block_scaled_mm 56.9%。最容易的 9 个算子，六个模型都通过。没有一个算子是六个模型全军覆没。难的那一团大多是低精度量化和第二个操作焊在一起，论文认为这是共同的能力边界，不是某一家的个例。

按参考语义的算术强度、以 10 FLOP/byte 为界，并取算子内形状的中位数，得到 16 个内存受限算子和 10 个计算受限算子。四个纯索引、没有算术的算子排除在这组对比之外。每家在带宽受限时都更靠近屋顶。Opus 4.7 的内存受限中位数是 0.207，计算受限中位数是 0.009，差二十倍以上。GPT-5.5 是唯一在计算受限侧有实质分数的，中位数 0.074；论文举例它在融合 MoE GEMM 上到 0.22。带宽侧的例子是 moe_sum_reduce，Opus 4.7 大约到内存屋顶的五分之三（S ≈ 0.59）。读法是：这些智能体更会把带宽吃满，还不大会做矩阵引擎要的分块和软件流水。

生成长度也不预测质量。输出 token 是到达最终候选所发出的量。

发得最多的 DeepSeek-V4-Pro 只做对 18 个算子。发得最少的 GPT-5.5 做对 26 个，Sagg 也最高。图 4 把输出量和 Sagg 放在一起，论文认为看不出关系。

683 次失败里，编译和算错各占一头

六个候选合计 683 个失败单元。

只看能不能 import 的门，会把那 365 个没产出编译结果的单元放进正确性。GLM-5.1 单独占了其中 232 个。编译过了以后，最常见的是静默算错：张量形状和 dtype 都对，值不对。这要五种子数值检查才抓得住。另外 24 个是对但慢，超过性能预算。

防作弊靠文件边界，不靠事后抓。生成工作区看不到 metadata.json，也看不到 roofline.json，所以既不能按上游符号把参考实现找回来，也不能对着没给的打分公式拟合。边界留得住的漏洞是规格抄近路：用语义等价、但不是目标 DSL 的实现去满足 PyTorch 参考。FlyDSL 采用率把这种通过从隐形变成一个数。三种反复出现的模式是 PyTorch 回退、调用预编译厂商内核、以及该写 FlyDSL 时改交 Triton。

优化循环是三道算子上的个案，不是全榜重跑

论文后半放出 Atrex-Kernel-Agent（AKA）。它不是一句更长的提示，而是把准备、写内核、按 profile 搜索、部分重启和打包分成可审计的状态。两条设计原则：硬件规格只从 GPU Wiki 来，并留下引用，不编造峰值；每次改内核都要有官方 profiler 的证据，不靠直觉。知识库规模是 298 个参考内核文件、244 份优化知识文档，另加用于查 API 和指令集的外部上游项目。

这组实验明确写成受控个案，不是全基准排名。只拿 Qwen3.7-Max 和 Claude Opus 4.7，各在三个计算受限算子、每个算子一个生产形状上，比较一次 vanilla 提示和套上 AKA。性能是每个（算子，形状）一次计时。三个算子的瓶颈还不一样：attention_forward 吃吞吐，可以靠近矩阵引擎屋顶；chunk_gated_delta_rule_state 和 mla_decode_attention 是小形状、调度受限，屋顶线分数会贴着地板，更该看相对生产内核的倍数。

下表是 vanilla 到优化后。FlyDSL 是设备时间占比，S 是屋顶线，最后一列是相对生产内核。

Qwen3.7-Max 的变化主要是从回退变成目标 DSL：三道 vanilla 都落后生产内核（0.03 倍到 0.17 倍），优化后三道都超过。attention_forward 的屋顶线从 0.06 到 0.40，相对那次回退大约 6.7 倍，并略超手工调过的 AITER 内核（1.11 倍）。Opus 4.7 在两个注意力算子上本来就在写 FlyDSL，工作流主要是把已写成的内核往屋顶推，而不是先解决「根本没写 DSL」。论文写明 AKA 不把成品内核交给智能体，给的是制度目标、参考脚手架、要避开的坑、指令集杠杆和测量循环。这组数字不能外推成 440 个形状上的 Sagg。

作者写下的范围

轨迹只覆盖选定的、计算受限而显存相对充裕的 XPU-A 和 H20 生产集群，部署超过 1 万张卡。它代表的是这一片被追踪的部署，不是每一种硬件。这一稿的实验数字只在 XPU-A 上。作者不声称同一批轨迹代表未来的硬件类别。屋顶线归一化能不能跨加速器家族仍然有信息量，留作后续，并且要按加速器重标定峰值、重验参考和评测路径。

这一版只有推理内核。训练里的反向内核和优化器步进内核不在范围内。

生产服务会随模型、引擎和内核库变。作者计划按新轨迹定期刷新算子集合、形状和权重，同时把每个已发布版本冻住，以便复现。

阿里，Lingyun Yang、Yuxiao Wang、Shenghao Liang、Linfeng Yang、Daocheng Ying、Chunbo You、Rui Zhang、Luping Wang、Yinghao Yu、Guodong Yang、Liping Zhang，Are LLM-Generated GPU Kernels Production-Ready? A Trace-Driven Benchmark and Optimization Agent，2026-07-16，https://arxiv.org/abs/2607.14541