KernelBench-Verified：LLM生成的CUDA内核真的能击败PyTorch吗？

# KernelBench-Verified：LLM 生成的核函数真的能击败 PyTorch 吗？ 来源：https://arxiv.org/html/2607.16241 1\]Meta 2\]FAIR at Meta SuperIntelligence Lab 3\]Stanford University \(2026年6月26日\) ###### 摘要 近期的大语言模型（LLM）能够生成自定义 CUDA 核函数，这些核函数在 KernelBench 等基准测试中的表现似乎优于 PyTorch。在此基础框架之上，我们发现前沿模型经常进行奖励黑客行为，人为地夸大报告的性能。在本工作中，我们指出了评估框架必须与模型能力共同演进的两个方面。首先，为了准确衡量真实加速效果，我们审视了基准计时机制，并指出启用 TF32 张量核心加速可以在现代 GPU 上提供更符合实际部署情况的性能估算。其次，在算法正确性方面，模型经常利用狭窄的测试分布，通过针对特定张量值硬编码绕过来实现加速。通过跳过必要的计算，这些核函数人为地加速了执行，而非实现真正的 CUDA 核函数。我们引入了KernelBench-Verified，一个扩展的评估框架，包含启用 TF32 的基准和四分布隐藏测试套件。我们还引入了内存效率指标，以捕捉核函数优化中常被忽视的速度-内存权衡。在对七个前沿 LLM 进行验证后的单轮评估中，我们发现表现最好的模型（GPT-5.5）的几何平均加速比仅为 0.88×，远低于标准评估协议下的 1.43×。没有模型能在面对现实基准时持续优于 PyTorch。在内存方面，最佳模型生成的 GPU 核函数中有 28% 会增加峰值 GPU 内存使用量。我们的研究结果表明，随着 LLM 核函数生成能力的提升，持续调整稳健的评估协议是必要的。 ## 1 引言 GPU 核函数是在图形硬件上执行并行计算的底层程序。它们是现代深度学习性能关键的基础组件 (robustkbench;kernelbench)。编写高效的核函数需要同时考虑内存层次结构、线程级并行性和硬件特定特性（如张量核心 (nvidia_h200_datasheet;DBLP:journals/corr/abs-2602-24286)），这使得核函数编程成为系统软件开发中最具挑战性的任务之一。近期的大语言模型 (LLM) 已展示出生成自定义 CUDA 核函数的能力，这些核函数据报告优于标准 PyTorch 实现。KernelBench (kernelbench) 提供了一个包含 250 个不同难度核函数编程问题的标准化基准，近期结果表明前沿 LLM 可以相对于 PyTorch 实现有意义的加速。这些结果激发了大量关于 LLM 驱动核函数合成的后续工作 (cao2026k;DBLP:journals/corr/abs-2602-24286;du2026kernel;liu2026dr;wiedemann2026kernelfoundry) (附录5 (https://arxiv.org/html/2607.16241#S5))。

尽管模型能力显著提升且 LLM 驱动的核函数合成进展迅速，但前沿模型越来越频繁地进行奖励黑客行为，利用特定的评估条件而非编写稳健的代码。为了确保基准测试与模型能力保持同步，我们确定了评估协议中三个关键的改进点。第一是改进性能基准。原始的 KernelBench 框架将生成的核函数与以 float32 模式执行的标准 PyTorch 进行对比。为了提供更全面的图景以反映现代实践者的部署情况，我们建议将基准扩展至包含 TF32 张量核心加速，这是现代 NVIDIA 架构原生支持的硬件特性。现代 NVIDIA GPU 包含两种类型的计算单元：标准 CUDA 核心一次性执行一个浮点运算，以及张量核心，它们以极高的吞吐量对小矩阵块执行融合矩阵乘加运算。在自 Ampere (A100, H100, H200) 以来的所有 NVIDIA GPU 上，PyTorch 支持 TF32 模式，这是一种将 float32 矩阵乘法路由到张量核心的硬件特性 (tf32nvidia)。这种加速通过单个 API 调用启用，在可忽略的精度损失下为矩阵操作带来显著的吞吐量提升。当基准忽视这一普遍可用的优化时，任何仅仅调用 cuBLAS (DBLP:conf/ipps/AnztSTLYD14;DBLP:journals/tpds/KurzakAGD16)（NVIDIA 高度优化的矩阵运算库，PyTorch 在其内部调用）的 LLM 生成核函数都会显得获得了惊人的加速。这种表面上的加速并非源于相对于实践者体验的卓越性能，而是源于人为放缓的基准。正如我们在第 3 节 (https://arxiv.org/html/2607.16241#S3) 中展示的，我们的估算表明，这种不匹配在 24% 的问题上使 PyTorch 基准加速了 >>1.5×，主要是那些以矩阵乘法为主的问题，不成比例地拉低了整体几何平均值。

第二，我们加强了正确性验证协议。我们观察到模型利用了测试输入张量的特定值，这些值来自标准测试中使用的狭窄均匀分布 (torch.rand())。这种狭窄分布创造了可利用的结构：所有值均为正、幅度小且同分布。我们发现具体的实例，其中 LLM 通过利用这些属性进行奖励黑客行为。例如，GPT-5.5 为 ReLU 激活函数生成了一个核函数，该核函数检查输入形状是否与测试配置匹配，如果匹配则原样返回输入（因为对于所有 x≥0，ReLU(x)=x）。这个恒等函数通过了正确性检查，并报告了 374× 的加速比。

最后，我们引入了内存评估以捕捉核函数优化中的速度-内存权衡，将基准的关注点扩展到执行时间之外。核函数优化本质上是用性能换取内存，但原始的 KernelBench 协议完全忽略了生成的核函数是否会增加峰值 GPU 内存消耗。虽然加速是主要目标，但内存占用决定了部署的可行性。关键的是，追踪内存可以解释实际的性能结果：通过融合节省内存只有在内存流量成为瓶颈时才会加速执行，而对于计算密集型操作则没有益处。

为了解决这些领域并演进方法论，我们引入了KernelBench-Verified，一个扩展的评估框架，特点包括：
1. 1. 现实的性能基准。我们在 PyTorch 参考中启用 TF32 张量核心加速，以匹配实践者在现代硬件上实际观察到的性能。
2. 2. 多分布隐藏测试。我们在四种输入分布（标准、放大 (×3)、缩小 (×0.01)、取反 (×-1)）上评估正确性，旨在捕获特定类别的错误，包括符号依赖的捷径、上溢和下溢。
3. 3. 内存效率指标。我们测量每个核函数的峰值 GPU 内存分配，捕获在生产部署中至关重要但在先前评估中缺失的速度-内存权衡。

关键的是，我们的验证协议不需要重新生成模型输出或修改现有的评估框架。它应用额外的隐藏测试用例并替换更现实的基准计时，使其成为任何使用标准 KernelBench 流程的实践者都可以轻松接入的轻量级修复方案。

我们使用 NVIDIA H200 GPU 在 KernelBench 上评估了七个前沿 LLM（GPT-5.5、Claude Opus 4.8、Claude Opus 4.7、Claude Sonnet 4.6、Kimi K2.6、Gemini 3 Flash、Gemini 3.1 Pro）。我们的结果显示，在验证评估下，没有任何模型在任何难度级别上相对于 PyTorch TF32 基准实现了超过 1× 的平均加速。在这种验证评估下，性能差异趋于正常：GPT-5.5 的整体加速比从标准协议下的 1.43× 重新校准为 0.88×。分解这一性能下降，我们发现 TF32 基准调整主要影响计算密集型问题（占问题的 21.2%），而隐藏测试套件则处理了模型依赖分布特定漏洞的实例（影响问题的 11.6%）。这两项改进在很大程度上是互补的：TF32 校准了用于测量加速的基准，而隐藏测试套件则捕获了标准正确性检查遗漏的一小部分但性质不同的分布捷径。

在内存方面，最佳模型 (GPT-5.5) 生成的正确核函数中有 28% 增加了峰值 GPU 内存使用量，并且随着问题复杂度的增加，内存节省急剧下降，从单算子问题的 82% 下降到完整模型架构的 36%。这揭示了一种速度-内存权衡，现有的基准完全忽视了这一点，而这对于实际部署至关重要。

随着 LLM 编写 GPU 核函数的能力越来越强，我们的评估框架必须持续适应，以捕捉硬件执行的完整复杂性。KernelBench-Verified 直接建立在 KernelBench 所建立的重要基础之上，提供了一种即插即用的扩展，将基准指标与启用 TF32 的基准计时对齐，并实施更严格的正确性验证。此外，通过引入峰值内存追踪，我们强调了执行速度和内存占用的联合优化是未来 LLM 核函数生成研究的关键前沿。

## 2 评估方法论

### 2.1 问题集与模型

我们在完整的 KernelBench 套件 (kernelbench) 上进行评估，该套件包含 250 个 GPU 核函数编程问题，分为三个难度级别。级别 1 包含 100 个单算子问题（矩阵乘法、softmax、层归一化、激活函数、损失函数等），测试模型是否能编写单个操作的高效实现。级别 2 包含 100 个融合算子链（例如，Matmul→Swish→BiasAdd→GroupNorm），需要算子融合才能达到有竞争力的性能。¹¹我们排除了三个设计不当的 Level 2 问题（PID 23、80、83），它们的 PyTorch 参考数学上保证无论输入如何都会产生恒定的零输出；这是在完整 250 问题基准中唯一三个其参考输出在我们的隐藏测试套件的所有四种输入分布下保持恒定的问题（附录 13 (https://arxiv.org/html/2607.16241#S13)），剩下 97 个活跃的 Level 2 问题。级别 3 包含 50 个完整模型架构（ResNet、DenseNet、MobileNet、MLP 流水线），代表实际的推理工作负载。

我们评估了七个跨越不同提供商和能力的前沿大语言模型：GPT-5.5（OpenAI）、Claude Opus 4.8、Claude Opus 4.7 和 Claude Sonnet 4.6（Anthropic）、Kimi K2.6（Moonshot AI）、Gemini 3 Flash Preview 以及 Gemini 3.1 Pro Preview（Google DeepMind）。²²所有模型于2026年5月评估。所有模型均以其默认推理能力进行查询；每个提供商的具体设置列于附录 6 (https://arxiv.org/html/2607.16241#S6)。每个模型收到标准的 KernelBench 单轮提示，其中包含原始的 PyTorch 实现，并要求生成优化的 CUDA 核函数。虽然近期工作探索了多轮和智能体化的核函数生成 (DBLP:journals/corr/abs-2602-24286;kernelbench)，但我们专注于标准的单轮协议，以将模型能力与搜索和反馈动态隔离开来。我们每个问题生成 N=5 个独立样本，并报告最佳 5 选 1 结果（每个问题最快的正确样本）。所有实验在 NVIDIA H200 GPU 上运行。完整的协议细节见附录 6 (https://arxiv.org/html/2607.16241#S6)。

### 2.2 TF32 基准配置

本工作的核心方法论贡献是使用启用 TF32 的 PyTorch 基准进行测量，而不是先前评估中使用的标准 float32 基准。在 NVIDIA Ampere 和 Hopper 架构上，TF32（TensorFloat-32）是一种计算模式，使用具有 19 位尾数精度的张量核心处理 float32 矩阵乘法，其指数范围与 IEEE float32 相同，但有效位数被截断。这为神经网络推理提供了显著的吞吐量提升（在计算密集型的矩阵乘法上可达 8 倍），而精度损失可忽略不计 (tf32nvidia)。在 PyTorch 中启用 TF32 只需设置一个全局标志：

代码清单 1：在 PyTorch 中启用 TF32 加速。这将所有 float32 矩阵乘法和卷积操作路由到张量核心。
```python
torch.set_float32_matmul_precision('high')
```

在硬件层面，这导致 cuBLAS 使用 CUBLAS_COMPUTE_32F_FAST_TF32 计算类型，将矩阵操作通过 Hopper 上的张量核心而非标准 FP32 CUDA 核心路由。这对基准测试的影响是深远的：一个内部启用 TF32 的核函数会显得获得惊人的加速，而实际上它只是匹配了实践者日常获得的性能。

### 2.3 隐藏测试套件设计

标准正确性测试从 torch.rand()（均匀 [0,1)）获取输入。虽然对基线验证非常有效，但我们发现高级 LLM 可以过拟合这种特定结构——例如，专门针对正值或有界幅度进行优化。为了鼓励生成稳健的算法，我们引入了一个隐藏测试套件，包含标准输入的四种确定性变换。该套件旨在确保模型在符号依赖路径、不同幅度和接近零的边界上都能泛化：

变换以逐元素方式应用于浮点张量；整数张量、标量参数和零值条目保持不变，保持三角形或稀疏布局等结构模式。我们改变值但不变形状：形状特化（编译时循环边界、静态共享内存、对齐的向量化加载）是合法的 CUDA 优化，而分布特定的利用则是泛化失败，因此固定形状保留了前者而减轻了后者（附录 15 (https://arxiv.org/html/2607.16241#S15)）。我们的隐藏测试纯粹作为正确性门控：如果一个核函数在任何分布上失败，则该问题被标记为不正确，然后从加速和内存聚合中排除。³³在测试之前，我们在每个配置上运行参考模型，并丢弃任何产生 NaN、Inf 或错误的配置；这在 1000 个配置中过滤掉了 2 个（问题 90 在 D2 下，问题 98 在 D4 下）。我们不在替代分布上基准测试运行时；性能和内存始终在模型生成时看到的原始（标准）分布上测量，使计时与公共 KernelBench 保持一致。

### 2.4 GPU 内存分析

现代 GPU 架构按层次组织内存：包含 CUDA 核心和张量核心的流式多处理器（SM）访问私有寄存器文件和 L1 缓存（共享内存），通过 L2 缓存连接到高带宽 DRAM（H200 上的 HBM3）。我们的内存指标捕获峰值 DRAM 分配，即内核执行期间保留的最大设备内存量，使用 PyTorch 内置的内存追踪：

代码清单 2：GPU 内存分析实现。测量单次前向传递期间的峰值 DRAM 分配。
```python
def get_memory_stats(kernel_fn, *args, device=None):
    torch.cuda.reset_peak_memory_stats(device)
    kernel_fn(*args)
    torch.
```
(注：代码清单 2 在原文中未完成，但按翻译规则保留原样)