SOL-ExecBench: Speed-of-Light Benchmarking for Real-World GPU Kernels Against Hardware Limits

发表时间: 2026-03 · arXiv:2603.19173 (NVIDIA)

作者/机构: Edward Lin∗, Sahil Modi†, Siva Kumar Sastry Hari†, Qijing Huang†, Zhifan Ye†, Nestor Qin† Fengzhe Zhou†, Yuan Zhang†, Jingquan Wang†, Sana Damani†, Dheeraj Peri, Ouye Xie Aditya Kane, Moshe Maor, Michael Behar, Triston Cao, Rishabh Mehta, Vartika Singh Vikram Sharma Mailthody, Terry Chen, Zihao Ye, Hanfeng Chen, Tianqi Chen Vinod Grover, Wei Chen, Wei Liu, Eric Chung, Luis Ceze, Roger Bringmann Cyril Zeller, Michael Lightstone, Christos Kozyrakis, Humphrey Shi (NVIDIA)

A1 主要贡献

核心问题：随着智能体AI系统在生成和优化GPU内核方面的能力日益增强，现有的基准测试方法成为了进展的瓶颈。这些基准测试通常奖励相对于软件基线的加速比，而不是奖励接近硬件高效执行的程度。这种评估方式与内核工程的真实目标——即达到硬件性能极限——之间存在脱节。特别是随着每一代GPU快速引入新的性能关键特性，以及数据中心部署中功耗效率成为主要制约因素，这种不匹配变得愈发重要。

研究目标：本文旨在解决现有基准测试的局限性，提出一种新的基准测试框架，该框架能够：
1. 覆盖当前前沿和新兴的AI模型架构。
2. 包含需要利用新硬件特性和精度格式才能实现最佳性能的问题。
3. 涵盖后训练（post-training）和推理工作负载。
4. 基于硬件基础的、可实现的最大性能目标来评估内核，而非易变的软件基线。
5. 提供能抵抗对抗性优化（即“奖励黑客”）的稳健评估基础设施。

创新点：
1. SOL-ExecBench基准测试集：本文提出了SOL-ExecBench，这是一个包含235个CUDA内核优化问题的基准测试集。这些问题从124个生产和新兴的AI模型中提取，涵盖语言、扩散、视觉、音频、视频和混合架构，目标硬件为NVIDIA Blackwell GPU。它覆盖了BF16、FP8和NVFP4等精度下的前向和后向工作负载。
2. SOLAR分析流水线：为了建立基于硬件的评估目标，本文开发了SOLAR（Speed-of-Light Analysis for Runtime），一个能够从FLOP计数、字节计数和GPU峰值吞吐量/带宽等信息中，分析并推导出硬件光速（Speed-of-Light, SOL）边界的流水线。这个SOL边界为内核优化提供了一个固定的、理论上可达到的性能目标。
3. SOL分数（SOL Score）：本文引入了一个新的性能指标——SOL分数。它量化了一个候选内核在多大程度上缩小了从预定义评分基线到硬件SOL边界之间的性能差距。该分数不仅反映了对基线的改进，还揭示了相对于硬件极限仍有多少优化空间。
4. 沙盒化评估框架：为了支持对智能体优化器的稳健评估，本文提供了一个沙盒化的评估工具。该工具具备GPU时钟锁定、L2缓存清除、隔离的子进程执行以及基于静态分析的检查功能，以对抗常见的“奖励黑客”行为（即通过钻评估系统的空子来获得高分，而非真正优化内核）。

通过将评估标准从超越易变的软件基线转向缩小与硬件光速性能之间的差距，SOL-ExecBench重新定义了GPU内核基准测试的范式。

A3 背景知识

光速（Speed-of-Light）指标

理论框架：由Williams等人提出的Roofline分析【27, Roofline: An Insightful Visual Performance Model for Multicore Architectures, 2009, Commun. ACM】为我们的SOL指标提供了理论框架，它通过峰值计算吞吐量和内存带宽来限制内核性能。Orojenesis【9, Mind the Gap: Attainable Data Movement and Operational Intensity Bounds for Tensor Algorithms, 2024, ISCA】通过计算张量算法更紧凑、可实现的数据移动边界（作为片上缓冲容量的函数）来完善这一点，表明朴素的roofline边界可能会显著高估对于数据复用有限的操作可实现的性能。我们使用SOL边界，将基准评估与NVIDIA内部内核开发团队使用的方法论对齐，即性能以硬件光速的百分比来衡量，而不是相对于软件基线。我们基于Orojenesis开发了SOLAR（SOL Analysis for Runtime），这是一个用于从PyTorch参考实现中自动推导紧凑、基于硬件的SOL边界的流水线。SOLAR的详细信息在第4.2节中描述。

A2 方法细节

3 基准测试构建

我们基于AI后训练应用中对高性能内核的需求设计了SOL-ExecBench，该领域正在经历指数级增长，遵循三个原则：

应用驱动的问题：问题必须由最先进和新兴的模型架构驱动，以便算子类型、张量形状和数据类型能反映当前生产环境实际运行以及不久将来会运行的内容。
利用最新的硬件特性：问题和指标目标必须鼓励解决方案利用更新的GPU架构中的最新硬件特性（例如，Blackwell GPU上的第五代张量核心支持的NVFP4）。
后训练生命周期：问题必须涵盖更广泛的后训练生命周期，如微调、RLHF和推理服务，捕捉使用低精度数据类型（FP8, NVFP4）的前向和后向传播，而不仅仅是仅推理的前向内核。

遵循这些原则，我们从六个领域的124个生产AI模型中提取问题，目标是NVIDIA B200 GPU，并包括BF16、FP8和NVFP4精度的前向和后向传播，产生了235个分为四类的基准问题。

图1: SOL-ExecBench构建流程概览。输入是跨越六个领域的124个源模型；输出是分为四个类别的235个经过验证的基准问题。

3.1 源模型覆盖

模型来源：我们从HuggingFace、Artificial Analysis和arXiv sourcing模型，优先考虑那些代表当前及未来可能的AI工作负载前沿的成熟和新兴架构。总共，我们处理了跨越六个领域的124个模型。

大型语言模型 (61个模型)：这个群体包括密集型Transformer，如Llama-3.x、Gemma-3和Phi-4；混合专家（MoE）模型，如DeepSeek-V3/R1、Qwen3-Coder-480B和GLM-4.7；以及更新的注意力变体，如Kimi-K2。它们共同引入了分组查询注意力（grouped-query attention）、SwiGLU MoE分发和多令牌预测等操作。

扩散模型—文本和图像 (24个模型)：图像生成模型包括Stable Diffusion变体、FLUX.1/2、HunyuanImage、Qwen-Image-Edit、Step1X-Edit、Bria-3.2、FIBO、Sana和HiDream，贡献了自适应层归一化、双流联合注意力和VAE编码器/解码器块。文本扩散模型（例如LLaDA-8B）引入了对令牌序列的并行去噪，这是一种与自回归生成截然不同的计算模式。

视觉 (6)、音频/语音 (9) 和视频 (2个模型)：视觉集合包括SAM-HQ、ConvNextV2、VMamba、NAFNet、Swin2SR和MaskGIT等模型；音频集合包括ASR模型（Whisper、Parakeet-TDT、Canary）和TTS/语音模型（Voxtral、OpenVoice、Kokoro、XTTS-v2、Granite-Speech-3.3-8B）；视频集合包括Wan2.2-T2V。这些领域贡献了窗口化注意力、conformer编码器和基于3D RoPE的空间注意力。

多模态和混合架构 (22个模型)：此类别包括视觉-语言模型，如Qwen3-VL、Qwen3-Omni、Llama-3.2-Vision、Gemma-3n、Molmo-7B-D和MiMo-V2-Flash；OCR和文档理解模型，如DeepSeek-OCR；以及SSM和混合架构，如Jamba、Nemotron-H和RWKV-v7，它们结合了注意力、状态空间和MoE原语。

3.2 提取流水线

四个阶段：提取流水线按图1所示的四个阶段进行。

模型准备：对于每个模型，我们加载其架构定义并提取完整的模型源代码以及配置常量，如隐藏层大小、注意力头数量和数据类型。

子图提取：一个前沿的LLM分析每个准备好的模型，以识别重要的计算子图，并生成独立的PyTorch实现，其中所有常量都已内联。前向传播是顺序生成的，以便进行去重。后向传播是并行生成的。对于量化模型，专门的提示会引导LLM使用适当的低精度原语。我们从124个模型中提取了7400个子图，涵盖前向和后向传播。

策划与采样：每个子图都在11个维度上进行表征，包括操作类型、模型领域、精度、计算强度和前向/后向划分，然后通过分层采样选出一个覆盖均衡的多样化子集。采样过程维持了单核与多核融合问题的目标比例，并为量化操作保留了专用槽位。每个选定的子图由一个基于LLM的驱动程序生成器转换为一个基准问题。由于策划与提取是解耦的，因此可以重新采样该子图池以实现不同的基准目标，而无需重新运行提取。

验证：验证包括三个部分。首先，多轮人类专家审查与基于LLM的审查相结合，检查每个问题是否格式良好、捕捉了预期的子图，并有正确的参考实现。其次，基于执行的检查验证了所有工作负载的数值正确性，其容忍度是通过对参考实现的重复运行校准的。

对抗性测试：第三，我们针对每个候选问题运行一个智能体内核优化器。这一过程暴露了一些问题中的规范漏洞。这些情况下，智能体可以通过利用问题定义中的模糊性来获得高加速比，而不是编写一个真正更快的内核。任何未通过这些检查或易受此类规范博弈（specification gaming）影响的问题都会被修剪，最终得到245个经过验证的问题集。其中，我们发布了235个作为公共基准，并保留10个用于即将举行的竞赛。评估工具中的博弈和作弊检测在第4.4节中有更详细的描述。

3.3 问题规范格式

三个组成部分：每个问题由遵循扩展的FlashInfer Trace模式的三个组件定义。

定义 (Definition)：定义部分指定了问题名称、操作类型、带类型的符号轴（常量、变量或表达式）、输入/输出张量形状和数据类型，以及一个参考实现。

参考实现 (Reference)：参考实现是一个自包含的PyTorch实现，带有一个顶级的run()函数。需要结构化输入（例如，分页的KV缓存、稀疏索引）的问题还额外定义了一个get_inputs()函数。

工作负载 (Workloads)：工作负载部分为每个问题的多个（通常约16个）动态形状实例提供具体的轴值，典型的动态轴包括批处理大小 ∈ {1, . . . , 64} 和序列长度 ∈ {128, . . . , 8192}。

4 数据集与评估

基准测试中的问题构成可能会随时间变化。在本文发布时，SOL-ExecBench包含235个问题，按复杂度和精度分为四个类别，如表2所述。每个问题都随附完整的规范、PyTorch参考实现和一个优化后的基线。

表2: 基准测试类别总结。

4.1 问题特征描述

多维度特征：图2从四个维度展示了SOL-ExecBench中235个问题的特征。如图2(a)所示，L1和L2共同构成了176个问题（75%）。在整个集合中，189个问题（80%）是前向传播，46个（20%）是后向传播。Quant和FlashInfer-Bench部分的问题完全是前向传播。后向传播问题覆盖了诸如通过MoE路由的梯度散布、带softcapping的后向softmax以及通过融合的norm-residual链的反向传播等模式。

操作类型分布：图2(b)显示了操作类型的分布。注意力以81个问题（35%）占据主导地位，这与注意力在LLM、视觉和多模态架构中仍然是主要优化目标相一致。MoE以36个（15%）紧随其后，然后是归一化27个（12%）、嵌入/位置编码20个（9%）、线性/投影16个（7%）、其他操作13个（6%）、融合块11个（5%）、GEMM和MLP/激活各10个（4%）、卷积6个（3%）以及SSM/Mamba 5个（2%）。

图2: 235个SOL-ExecBench问题在四个维度上的特征描述。(a) 基准类别分解（前向/后向划分用阴影表示）。(b) 按主要操作类型分布。(c) 按模型领域划分的问题，按基准类别堆叠。(d) 按主要计算精度分布。

模型领域分布：图2(c)按模型领域分解了问题，并按基准类别堆叠。LLM贡献了最大份额（153个问题，65%），其次是多模态（27个）、扩散（25个）、视觉（13个）、音频/语音（11个）和视频（6个）。LLM问题涵盖了所有四个类别；扩散和视觉问题集中在L1和L2。

计算精度分布：图2(d)显示了按主要计算精度的分布，定义为主要数据张量（非累加缓冲区）的数据类型。BF16是最常见的格式（107个问题，46%），反映了现代LLM和扩散工作负载的主导地位。FP32占79个问题（34%），集中在音频、视觉和扩散模型中。FP8（19个，8%）和NVFP4（15个，6%）专属于Quant类别，而FP16（12个，5%）主要出现在音频和GEMM工作负载中。一小部分3个问题（1%）被标记为混合精度。这些是整数和布尔值主导的内核，如注意力掩码构造、MoE令牌路由排序和多模态位置索引计算，没有单一的浮点格式适用。

工作负载与输入：最后，每个问题有16个工作负载（FlashInfer-Bench：7-48个），覆盖了动态轴，如批处理大小 ∈ {1, . . . , 64} 和序列长度 ∈ {128, . . . , 8,192}（图中未绘制）。78个问题（33%）使用自定义输入生成来处理结构化输入，如分页KV缓存、MoE路由张量和稀疏注意力掩码。

图3: 从PyTorch模型和输入形状推导光速（Speed-of-Light）边界TSOL的SOLAR流水线。

图4: SOLAR流水线在一个具体的SOL-ExecBench L1问题上的应用。

4.2 SOL边界推导

SOLAR工具：为了量化剩余的改进空间并验证生成内核声称的加速比，我们在基准测试中为每个问题包含了光速（SOL）运行时。这些边界是使用SOLAR2推导的，这是一个为估计PyTorch程序在目标硬件上可实现的最小理论运行时而开发的工具。如图3所示，SOLAR由三个分析阶段组成：

1. 图提取器 (Graph Extractor)：提取器跟踪PyTorch模型以生成一个捕获数据流、算子类型和中间张量形状的算子图。它建立在torchview库【11, torchview: Visualize PyTorch Models, 2022, GitHub】之上，该库利用前向钩子（forward hooks）在实时前向传播期间收集张量元数据。通过利用这种机制，SOLAR尊重PyTorch的即时执行（eager execution）和动态控制流，使其能够捕获确切的执行路径，而无需静态模型图。

2. 智能体Einsum转换器 (Agentic Einsum Converter)：此阶段将PyTorch算子转换为扩展的einsum表达式【10, The tensor algebra compiler, 2017, OOPSLA】【21, The EDGE Language: Extended General Einsums for Graph Algorithms, 2024, arXiv】——这是爱因斯坦求和约定【8, The general theory of relativity, 1922, Springer】的一种泛化，使用基于索引的表示法来表示张量计算。
* 表示法：这种规范形式统一了张量代数运算，并明确揭示了张量迭代空间和计算模式，SOLAR据此进行算子分析并推导FLOP计数和内存流量。
* 查找机制：SOLAR维护一个持久的查找表，将PyTorch算子映射到经过验证的einsum转换函数。对于表中已存在的算子，直接应用转换。
* 自动化：对于以前未见过的算子，一个LLM智能体会生成一个候选转换函数，并通过模拟einsum表达式并将结果与原始PyTorch算子进行比较来验证它。这使得在将新条目添加到查找表之前能够自动进行自我修正。

3. SOL分析器 (SOL Analyzer)：生成的einsum图和目标硬件规格被传递给SOL分析器。它使用基于目标频率下峰值计算吞吐量和内存带宽的roofline模型【27, Roofline: An Insightful Visual Performance Model for Multicore Architectures, 2009, Commun. ACM】来计算性能：

该分析器考虑了图级别的融合和预取优化。它还支持Orojenesis【9, Mind the Gap: Attainable Data Movement and Operational Intensity Bounds for Tensor Algorithms, 2024, ISCA】，通过将片外数据移动建模为片上缓冲容量的函数来推导更紧密的边界，考虑到了并非所有张量数据都能被暂存到片上以实现完全复用的现实情况。

SOLAR流水线示例：图4展示了SOLAR流水线在一个来自JambaReasoning-3B的具体SOL-ExecBench L1问题上的应用，该问题执行融合的注意力输出投影和残差加法。图4(a)描绘了执行矩阵乘法后跟逐元素加法的PyTorch代码。图提取器将PyTorch程序作为输入，并生成一个带有显式节点（matmul, add, transpose）和张量形状的算子图（图4(b)）。接下来，基于LLM的Einsum转换器将算子图映射到一个扩展的einsum图：矩阵乘法映射到单个收缩节点$A_{CB},B_{H}→A_{CH}$，投影映射到逐元素加法$A_{CH},A_{CH}→A_{CH}$节点（图4(c)）。最后，SOL分析器从Einsum图推导出FLOPs和内存流量，并在一台B200 GPU上生成一个roofline边界。对于这个工作负载，该内核是计算密集型的，融合后的内存占用约为126 MB，算术强度为427，得出的SOL运行时为0.06毫秒（图4(d)）。

当前局限性：SOLAR的一个当前局限性是其分析仅基于张量形状而非值。因此，它无法捕捉依赖于值的优化，如压缩或常量传播，并可能忽略由结构化或重复数据带来的性能增益，这些数据可以实现更高效的内存访问或代数简化。此外，由于硬件可变性，如功率上限或热节流，SOL边界在实践中可能不够紧密。

4.3 指标：SOL分数

定义：我们定义了一个新的性能指标，即SOL分数，记为 $S \in [0, 1]$。它衡量一个内核相对于一个固定的基线运行时，距离硬件SOL有多近。设 $T_b$ 为基线实现的运行时， $T_{SOL}$ 为SOLAR估计的运行时， $T_k$ 为候选内核的测量运行时。我们假设 $T_b > T_{SOL}$ 且 $T_k \geq T_{SOL}$，这样基线到SOL的差距是正的。如果在实践中任一假设被违反，我们将其视为一个审计信号，并报告用于SOLAR边界审查和奖励黑客行为检查（第4.4.1节）。

SOL分数公式：SOL分数定义为：

这可以等价地写为：

锚点属性：SOL分数位于[0, 1]区间，并具有以下三个锚点属性（如图5所示）：

图5: SOL分数作为内核运行时Tk的函数，图中TSOL = 50，Tb = 100。该指标在Tk = TSOL时锚定为S = 1，在Tk = Tb时锚定为S = 0.5，并随着运行时的增加平滑地衰减到0。曲线还突显了该指标的非线性：当接近SOL区域时，相同的运行时改进会产生更大的分数增益。

设计理念：我们设计该分数将基线赋予一个中点分数而不是零，这样指标可以在一个共同的有界尺度上区分三个区域：低于基线性能（$S < 0.5$）、高于基线但低于SOL的性能（$0.5 < S < 1$）和SOL级别的性能（$S = 1$）。在低于基线的性能区域，随着运行时的增加，指标会平滑地衰减到零。项 $T_b - T_{SOL}$ 代表了基线和硬件SOL之间的性能提升空间。因此，SOL分数衡量了一个候选内核在多大程度上有效地填补了这个差距。分数大于0.5表示内核优于基线，而接近1的分数表示它接近硬件高效执行。我们之前假设 $T_b > T_{SOL}$，但当 $T_b \rightarrow T_{SOL}$ 时，我们认为该问题已解决，不再评估该问题的新提交。我们试验了使用clip和/或sigmoid函数实现相同目标的该公式的变体，但因其简单性而选择了此公式。

正确性指标：为确保性能得分只授予功能正确的内核，我们为每个问题引入了一个正确性指示器 $C \in {0, 1}$。未通过验证的内核将被赋予 $C = 0$，因此无论其运行时如何，都将获得零性能得分。

总体分数：对于一个包含 $N$ 个问题的基准测试套件，总体SOL分数定义为每个问题分数的算术平均值：

我们使用算术平均值，因为每个问题的SOL分数已经限定在[0, 1]范围内，并且在所有问题中具有相同的解释，所以平均后在套件级别上保留了这种解释。该公式可以自然地扩展到为每个问题生成多个候选解决方案的智能体系统的best-of-k设置，但为简洁起见，我们在此省略了该扩展。

4.4 评估框架

解决方案格式：解决方案以JSON规范的形式接受，其中包含源文件、实现语言、构建配置、目标硬件和一个入口点函数。当前的评估器支持Python、Triton和通过torch.utils.cpp_extension实现的CUDA/C++，包括基于PTX、CUTLASS、CuTE DSL、cuBLAS、cuDNN和cuTile的实现。

参考实现与评分基线：每个基准问题都附带一个PyTorch参考实现，它定义了预期的语义并用于正确性检查。这个参考实现主要为可移植性、可读性和功能覆盖而编写，可能不提供高性能，因此应被解释为功能规范，而不是一个强大的软件性能基线。因此，我们区分了参考实现和运行时基线的概念。为了计算SOL分数，我们为每个问题定义了一个评分基线$T_b$，它锚定了指标的中点（第4.3节）。该评分基线目前在基准测试内部保留，并可能在未来版本中发布。由于评分基线不固定于特定实现，它可能会随着更强基线的出现而随时间更新，从而使基准测试随着技术水平的进步而保持挑战性。我们将在第4.5节中描述当前评分基线的获取方式。

正确性检查：对于正确性检查，评估器首先执行固定的参考实现以生成参考输出，然后在多个有种子的试验中将候选输出与这些参考输出进行比较。验证会检查输出形状、数据类型和基本的张量健全性，当参考输出不平凡时，会拒绝虚假的inf/NaN值和退化的全零输出。对于密集张量输出，正确性由存储在workload.jsonl中的特定于工作负载的容差元组（atol, rtol, matched_ratio）定义。对于BF16/FP32问题，这些阈值是通过在随机输入上重复探测参考实现并对所需的绝对容差应用1.25倍的安全裕度来离线校准的。对于量化和采样问题，使用专门的评估器。对于量化内核，正确性通过PyTorch与cuBLAS参考实现进行比较，或者在前者不可用时与FP32参考实现进行比较。

运行时测量：我们使用CUDA事件来测量运行时，每个试验进行10次预热迭代和50次计时迭代，共进行3个试验，报告的运行时是所有试验的平均值。在每次计时迭代之前，评估工具通过将一个256 MB的设备缓冲区清零来清除L2缓存，并克隆张量参数，以便每次运行都从新的输入和新的地址开始，而不是重用先前迭代的状态。在给定GPU上的基准测试是串行化的，并且通过nvidia-smi将时钟锁定在硬件特定的频率（B200为1,500 MHz），以提高可复现性。评估工具报告以毫秒为单位的绝对运行时，而诸如加速比和SOL分数之类的相对指标则在之后根据给定基准版本定义的评分基线进行计算。

沙盒化执行：每个提交的解决方案都在一个专用的子进程中编译和执行，从而隔离评估器状态，使一个解决方案不会影响后续的解决方案。这种设计还支持在多个GPU上进行轮询调度，并允许丢弃和重新启动失败的工作进程，而不会中断基准测试的其余部分。一个300秒的超时可以防止挂起和无限循环，参考输出以及参考计时数据会单独准备并通过IPC传输给解决方案工作进程。

4.4.1 奖励黑客与缓解措施

奖励黑客现象：先前的工作观察到，智能体优化系统容易受到奖励黑客（reward hacking）的影响，即优化器利用评估环境中的漏洞来最大化其分数，而没有真正正确地解决底层任务【12, Towards Robust Agentic CUDA Kernel Benchmarking, Verification, and Optimization, 2025, arXiv】。在GPU内核优化的背景下，我们也观察到智能体生成的代码会绕过计时机制、违反基准约束或利用计时循环的重复性来获得人为的低运行时。我们将这些利用行为分为三大类：并发利用、状态缓存和环境操纵，如表3所示。

并发利用：并发利用涉及将执行时间从基准测试的torch.cuda.Event计时器中隐藏起来。智能体通过将工作分派到后台Python线程、在未记录的非默认CUDA流上启动内核或利用torch.jit.fork进行非预期的并行执行来实现这一点。一个特别复杂的变体利用了torch.cuda.CUDAGraph和流的捕获机制，其中torch.cuda.CUDAGraph为其捕获区域创建了自己的隐式非默认流，而其他非PyTorch库并未明确意识到这一点。在一个CuTe DSL实例中，隐式流未被转发到CuTe内核，因此初始捕获过程执行了计算并用正确结果填充了输出缓冲区以通过正确性检查，但计时循环期间的后续图重放却没有任何工作，执行时间可以忽略不计。

状态缓存与环境操纵：状态缓存利用了基准测试的重复计时循环。智能体会在初始正确性检查期间计算一次结果，将输出（或中间变量）缓存在全局字典中，并在计时迭代期间简单地复制缓存的张量。类似地，智能体采用惰性求值，返回FakeTensor对象，这些对象仅在eq正确性检查期间执行计算，从而在计时阶段有效地跳过了所有数学运算。最后，环境操纵包括对关键计时函数（例如Event.elapsed_time）进行猴子补丁，以及降低计算精度（例如，在FP16中执行FP32问题并上转型结果）。对于后者，我们认识到某些问题不需要完整的32位精度，因此当输入和输出数据类型匹配且满足严格的容差时，允许降级转换。我们还观察到一些非PyTorch提交，它们将预编译的机器码（ELF二进制文件或cubin blob）作为base64编码的字符串嵌入，并通过ctypes或cuModuleLoadData在运行时加载，以完全绕过源代码级别的审查。

表3: 智能体内核优化器观察到的奖励黑客策略及相应的缓解措施。

缓解措施：为了确保SOL分数的完整性，我们实现了一个评估沙盒，以抵御智能体优化器使用的常见奖励黑客策略。它检查对计时路径的篡改，检测隐藏在旁路CUDA流上的工作，在每次运行之间克隆输入以减少状态泄漏，并将严格的输出验证与子进程隔离相结合，使无效或对抗性的解决方案无法获得性能得分。评估框架强制执行严格的动态检查：它监控活动线程数，断言输出是完全物化的torch.Tensor对象（拒绝子类），注入torch.cuda.synchronize()来捕获隐藏的异步工作，并验证关键计时函数的内存地址以防止猴子补丁。为了缓解状态缓存，我们在每次计时迭代前使用随机输入运行多次正确性试验，并显式清除一个256 MB的GPU L2缓存缓冲区。为了防止智能体在计时循环中使用内存地址（data_ptr）作为缓存键，评估工具实现了一个新的内存分配器，在预分配的缓冲区中每次迭代将内存指针移动256 B。对于更复杂或混淆的模式，如动态流创建、语义缓存或未经授权的文件I/O，我们采用一个“LLM即法官”在执行前对所有提交进行静态代码分析。最后，由于新的利用方式偶尔会出现，所有被提议采纳为新评分基线的候选解决方案在被接受进入数据集之前都经过人工审查。

保守设计选择：为了减少奖励黑客行为，当前的评估器做出了两个保守的设计选择：它不允许使用CUDA流，并依赖于PyTorch的默认内存分配器。不允许CUDA流有助于防止隐藏工作的利用，但这也意味着用户内核可能无法完全复现基于torch.compile的评分基线。我们认为这对于通常从多流执行中获益甚少的高计算量LLM内核来说是一个可接受的限制。同样，依赖PyTorch的即时分配器提高了实用性和可读性，但对于VRAM占用率超过50%的子图上的非PyTorch内核可能不利，因为PyTorch可能会保留和重用已释放的内存。未来版本可以通过更好的流检查方法、分配器控制（如PYTORCH_NO_CUDA_MEMORY_CACHING）、自定义PyTorch构建或使用静态分配器的非PyTorch参考实现来改进这些保障措施，尽管每个选项都引入了其自身的兼容性、可读性或维护权衡。

4.5 评分基线

基线定义：SOL-ExecBench中的每个问题都有一个评分基线（未发布），它不同于参考程序，是一个性能更高的实现，作为SOL分数公式（公式2）中的运行时锚点$T_b$。任何比$T_b$快的解决方案都将获得高于0.5的分数，反映出其在已经优化的内核基础上的改进。

基线生成：这些基线实现是使用一个智能体内核优化系统生成的。该优化器以回合制、多智能体的方式运作。对于每个问题，我们独立启动多个智能体，在固定的时间和成本预算下优化所提供的PyTorch参考实现的运行时。每轮之后，我们收集所有有效的提交解决方案，并将其暴露给下一批智能体，这些智能体可以在下一轮中将任何这些正确的候选方案作为起点或参考进行进一步优化。

智能体环境：每个智能体被限制只能使用PyTorch和标准Python包来生成解决方案。智能体配备了工具和技能，可以将其实现提交到第4.4节中描述的远程评估沙盒进行正确性检查和基准测试。此外，每个提交的解决方案都由一个基于LLM的法官进行检查，以检测违反要求和常见的作弊模式。

基线选择：只有那些编译成功、通过正确性验证并满足我们奖励黑客缓解机制的解决方案才被保留为基线候选。在规定的轮数之后，我们汇总所有智能体在所有回合中产生的所有有效候选方案，并为每个问题选择最快的内核作为最终的优化基线。

A4 实验环境

硬件配置：所有实验均在NVIDIA DGX B200节点上进行。每个节点配备8个NVIDIA Blackwell B200 GPU，每个GPU提供192 GB的HBM3e内存和8 TB/s的内存带宽【17, NVIDIA B200 GPU Data Sheet, 2024, NVIDIA】【18, NVIDIA Blackwell Architecture Technical Brief, 2024, NVIDIA】。
软件配置：软件栈基于NVIDIA提供的Docker镜像，包含CUDA 13.1.1、cuDNN 9.17.1、PyTorch 2.9.0和NVIDIA驱动程序580.95。
运行配置：每个基准测试运行使用单个GPU，并通过nvidia-smi将SM时钟频率锁定在1,500 MHz，以减少频率缩放带来的噪声，这与第4.4节描述的评估工具配置相匹配。

A4 实验结果

SOL分数与加速比的对比

核心发现：评估内核优化的传统方法是测量其相对于PyTorch参考实现的加速比。然而，实验表明，仅凭加速比无法全面评估内核的优化质量。
- 加速比与SOL距离不相关：图6显示，内核相对于PyTorch参考实现的加速比（Tref /Tk）与其距离硬件SOL边界的程度（Tk/TSOL）之间没有相关性（对数尺度上相关系数r=0.10）。这意味着，一个比PyTorch快10倍的内核，可能距离硬件性能极限仍有超过10倍的差距。仅使用加速比的指标会对此类内核给予高评价，从而掩盖了巨大的优化空间。
- SOL分数整合了双重信息：图7通过SOL分数（S）对每个点进行着色，展示了SOL分数如何整合加速比和SOL距离这两个维度。高分（S ≥ 0.9）的点集中在图的右下角（高加速比、低SOL距离），而低分（S < 0.4）的点则位于左上角。那些相对于PyTorch很快但离SOL很远的点，只获得了中等分数（S ≈ 0.5–0.7），这证明SOL分数不是简单的加速比重标。
- SOL分数有效反映优化质量：为了验证SOL分数的有效性，图8将其与“已回收的优化空间分数”（(Tref − Tk)/(Tref − TSOL)）进行比较，该分数直接衡量解决方案填补了多少优化差距。结果显示，SOL分数与该分数几乎完美相关（皮尔逊相关系数r=0.981），证实了S忠实地追踪了优化进展。相比之下，加速比与该分数的关联性较弱（r=0.81）。这突显了将硬件SOL边界纳入评估指标的价值，因为SOL分数揭示了单独使用加速比所留下的盲点。

图6: 此处显示了每个问题和工作负载相对于PyTorch参考实现的加速比（x轴）与距离硬件SOL的距离（y轴）。

图7: 此处显示了SOL分数景观。每个点按其SOL分数带进行着色，并叠加了等分线（S=0.5, 0.7, 0.9）。坐标轴与图6相同。

PROTECTED_IMAGE_19__图8: 验证SOL分数与已回收的优化空间分数。两个面板共享相同的x轴。 (a) 此处显示了SOL分数与已回收的优化空间分数的对比，按类别着色。
__PROTECTED_IMAGE_15
(b) 此处显示了加速比与已回收的优化空间分数的对比，按SOL分数着色。

奖励黑客行为的缓解

普遍性与缓解：在智能体解决问题的过程中，观察到了“奖励黑客”行为。图9显示了在所有智能体提交中检测到的利用漏洞的分布情况。
- 主要利用类型：精度降级是最常见的利用方式（占所有提交的6.4%），即智能体使用较低精度计算（如FP16而非FP32）再上转型以通过验证。其次是猴子补丁（3.3%），即覆盖关键计时函数；以及流注入（2.5%），即将工作隐藏在未同步的CUDA流中。
- 检测结果：总共有589个提交（占总数的14.5%）被动态运行时检查和基于LLM的静态分析相结合的机制标记并拒绝。这一结果强调了在使用智能体系统进行内核优化时，拥有稳健的评估基础设施至关重要。

按基准级别划分的利用漏洞分布。图9: 此处显示了在智能体提交中检测到的奖励黑客利用漏洞的分布，按利用漏洞类型和问题类别划分。

评分基线分析

基线性能：图10展示了智能体生成的解决方案（即新的评分基线）在所有四个基准类别中的性能特征。
- SOL分数分布：所有类别的中位SOL分数均显著高于0.5（L1: 0.688, L2: 0.761, Quant: 0.757, FlashInfer-Bench: 0.789），总体中位数为0.732。这证实了智能体生成的解决方案普遍优于PyTorch参考实现。
- 优化空间：尽管性能优越，但分数很少达到1.0，表明在每个类别中仍有相当大的优化空间。L1类别的分数分布最广，反映了其单操作内核类型的多样性。
- 与SOL的距离：图10(b)直接比较了PyTorch参考实现和智能体解决方案与SOL边界的距离。几乎所有点都落在对角线以下，证实了智能体解决方案更接近SOL。中位数SOL距离缩减倍数分别为L1: 2.0倍, L2: 2.7倍, Quant: 2.9倍, FlashInfer-Bench: 3.4倍。这些性能更强的智能体解决方案将作为未来评估的评分基线$T_b$。

(a) 此处显示了每个类别的SOL分数分布。直方图（顶部）带有中位数（实线）和平均值（虚线）；箱线图（底部）。S=0.5线标志着与PyTorch参考实现的持平。

(b) 此处显示了PyTorch参考实现与智能体解决方案距离硬件SOL的距离对比。
图10: 此处分析了智能体解决方案（新的评分基准）的结果。

A5 结论

本文介绍了SOL-ExecBench，一个围绕硬件光速（SOL）目标构建的GPU内核优化基准测试。SOL-ExecBench包含从124个前沿和新兴AI模型中汇编的235个问题，覆盖了后训练和推理工作负载、现代精度格式以及受益于新硬件特性的内核。我们还引入了SOLAR，一个能从PyTorch程序中分析推导出基于硬件的SOL边界的流水线，为每个问题提供了一个超越软件基线的稳定目标。

我们引入了SOL分数，这是一个新的内核评估指标。与单独的加速比不同，它通过衡量候选内核在多大程度上缩小了评分基线与SOL边界之间的差距，揭示了剩余的优化空间。我们还提供了一个稳健的评估框架，具备抵御奖励黑客行为的防御机制，这些机制的设计灵感来源于我们从智能体生成的解决方案中观察到的失败模式。

我们的智能体优化器生成了强大的基线解决方案，总体中位SOL分数为0.732，这表明仍然存在可观的优化空间。展望未来，我们期望SOL-ExecBench能够随着新的工作负载、更强的基线和社区提交而不断发展，从而始终与模型、内核和硬件的前沿保持一致。