本文作者包括明尼苏达大学的张子健（共同第一作者），王嵘（共同第一作者），李世阳，罗越波，洪明毅，丁才文。

CUDA 代码的性能对于当今的模型训练与推理至关重要，然而手动编写优化 CUDA Kernel 需要很高的知识门槛和时间成本。与此同时，近年来 LLM 在 Code 领域获得了诸多成功。这推动人们去探索如何利用 LLM 来编写优化 CUDA kernel。然而，现有的方法面临诸多问题，例如高昂的训练与推理成本，不良的 kernel 性能，以及缺乏硬件反馈导致的盲目探索。

那么对于使用 LLM 进行 CUDA 代码生成，我们能不能设计一个简单而有效的方法，使其能够低成本地生成可靠高效的 CUDA kernel？

明尼苏达大学的团队提出了一种新的方法——CudaForge。这是一种简单、高效且低成本的多智能体 CUDA Kernel 生成与优化工作流。该工作流受人类专家的实际开发流程启发，包含初始 Kernel 的编写、正确性测试、硬件反馈分析以及迭代改进等关键阶段。

论文标题：CudaForge: An Agent framework with Hardware Feedback for CUDA Kernel Optimization论文链接：https://arxiv.org/pdf/2511.01884代码地址： https://github.com/OptimAI-Lab/CudaForge

实验结果表明，CudaForge 在 KernelBench Levels 1-3 上取得了 SOTA 的结果，超越了现有的所有方法。值得注意的是，通过 CudaForge 生成一个经过优化的 Kernel 在单张 RTX6000上仅需约26.5 分钟，同时仅产生约0.3 美元的 API 调用成本！

CudaForge Workflow 介绍

正如人类专家所采用的开发方法，包括初始 Kernel 的编写、正确性测试、硬件反馈分析以及迭代改进，我们将 CudaForge 设计为如上所示的迭代式优化框架。

该框架包含两个相互独立的智能体：CoderJudge

Coder 根据任务描述以及来自 Judge 的反馈生成候选 CUDA kernel；而 Judge 则利用 kernel 本身、硬件反馈以及运行时信息对每个候选进行评估。

具体而言，给定一个 CUDA kernel 生成任务，Coder 首先接收任务要求以及对应的 PyTorch 参考实现，然后生成一个初始的候选 kernel。该 kernel 将被编译并在测试用例上执行以验证其正确性。

如果测试失败，Judge 会检查运行时信息（例如编译错误、与 PyTorch 参考结果不一致的输出），并分析该错误 kernel 的问题所在。随后，Judge 会返回相应的纠错反馈（如缺少头文件等），以指导下一轮生成。当某个候选 kernel 通过了正确性测试后，Judge 会使用NCU工具对其进行性能剖析，获取NCU 性能指标（如内存带宽、占用率、warp 效率等）。

结合 GPU 硬件规格，这些指标构成了用于识别主要性能瓶颈（如算力受限或带宽受限）的硬件反馈，Judge 会进一步基于此返回一个明确的优化建议（如使用 shared memory）给 Coder。

在下一轮中，Coder 会同时接收上一轮的 kernel、Judge 的反馈以及原始任务需求，并生成新的、经过修正或优化的 kernel。该过程最多重复N轮，最终我们会从所有正确的候选结果中选择效率最高的 kernel作为最终输出。

在此，我们给出一个使用 CudaForge 进行 Kernel 优化的案例，并将其与Kevin-32B方法进行对比：

这一对比进一步凸显出使用硬件反馈对于 Cuda 代码优化的重要意义。

具体来说，CudaForge通过以下三项关键设计显著提升了 CUDA kernel 的生成与优化能力：

双智能体分工协作：CudaForge 采用Coder–Judge双智能体架构，其中 Coder 专注于代码生成，Judge 负责评估代码并提供反馈，从而实现“认知负载”的有效分离。

迭代式优化流程：CudaForge 通过多轮迭代逐步纠错与提速，使得 Kernel 能在每一轮中持续被改进，特别是在复杂任务中能够获得更加稳定的优化效果。

显式引入硬件反馈：CudaForge 将GPU 规格NCU 性能指标（如带宽、占用率、Warp 效率）纳入反馈，使 Judge 能精确定位瓶颈并提供可执行的优化指导

实验评估

我们在 KernelBench Levels 1-3 上评估了我们的模型，并与 Kevin-32B，OpenAI-o3 等模型进行了比较。

在 RTX 6000 上的 KernelBench Levels 1–3 主要结果：

在我们的主要实验中，我们默认将OpenAI-o3同时用作 Coder 与 Judge，并将最大迭代轮数设为N = 10，以在性能提升与推理成本之间取得平衡。

在 KernelBench 上，CudaForge 达到了 97.6% 的正确率，平均加速比为 1.677×，Fast1 比例为 70.8%，并且实现了1.107× 的中位数加速比1.592× 的 75 分位加速比。这些结果显著优于基础模型 OpenAI-o3 与一系列消融变体（包括o3-self-refine、o3-correction、o3-optimization）。

与 Kevin-32B 在 H200 上的对比：

考虑到 Kevin-32B 是基于 H200 训练的 RL 模型，我们在 H200 上对比了 Kevin-32B 和 CudaForge。下图展示了 CudaForge 与 Kevin-32B 在 KernelBench 上的正确性与性能表现对比。虚线表示 CudaForge 在 Level 1 和 Level 2 上的平均水平。

尽管CudaForge 不需要训练（training-free），它在KernelBench Level 1–2上的表现依然优于Kevin-32B，并且在Level 3上也取得了极为出色的性能。

CudaForge 的 API 与计算时间成本分析

我们进一步分析了 CudaForge 的性能与其 API 调用成本和计算时间之间的关系，如图所示。随着 API 成本与计算时间的增加，CudaForge 的性能呈单调提升趋势。值得注意的是，即使在每个任务耗费不超过 0.15 美元和 10 分钟的情况下，CudaForge 也已经能够超越 Agentic 基线方法，这充分展示了其出色的性能-成本平衡能力。

基于 KernelBench，我们测评了 CudaForge 所需的时间和 API 成本，结果表明在 KernelBench Levels 1-3 所有任务上，CudaForge 每个任务仅需平均 0.3 美元的 API 成本，以及在单卡 RTX6000 上 26.5 分钟的运行时间！

消融实验

在不同 LLM 上实例化 CudaForge：

为了验证 CudaForge 是否依赖某个特定基础模型，我们在实验中固定一方（Coder 或 Judge）为 OpenAI-o3（记作 O3），并将另一方替换为多种先进的大模型，包括 QwQ-32B、GPT-5、Claude-Sonnet-4、GPT-OSS-120B 等。

如表所示，所有组合都能够取得较高的正确率和良好的性能表现，并且在某些情况下甚至超过原始的 O3/O3 配置。

这一结果表明，CudaForge 并不依赖于某个特定的基础模型：其有效性主要来源于 Coder–Judge 的工作流机制，并且随着更强模型的出现，它可以直接受益并进一步提升性能。

在不同 GPU 架构上使用 CudaForge：

我们进一步在多种 GPU 架构上评估 CudaForge，包括 RTX 6000、RTX 4090、RTX 3090 和 A100，以考察其在不同硬件条件下的适用性。

实验结果（如表所示）显示，CudaForge 在所有测试 GPU 上均保持了高正确率和强性能表现，证明其具有良好的硬件通用性和稳定性。

总结

我们提出了 CudaForge，一个无需训练的多智能体 CUDA kernel 生成与优化框架。该框架模拟人类专家的迭代式工作流程，并显式地引入硬件反馈，以实现有针对性的 Kernel 优化，而非盲目搜索。 在 KernelBench 基准上，CudaForge 相较于现有方法取得了最高的正确率和显著的性能提升，同时在不同 GPU 架构和多种基础大模型上均表现出强鲁棒性与泛化性。

此外，CudaForge 的性能随着迭代轮数的增加能够进一步提升。 最后，得益于其低 API 开销与低时间成本，CudaForge 为自动化 CUDA Kernel 开发提供了一种高效、实用且可投入实际使用的解决方案。