KernelZero 用 7B 的 Proposer–Coder 协同进化，在 KernelBench 上把 CUDA pass@1 做到 75.8、Triton 做到 77.2

框架把 GPU kernel 生成拆成两个显式接口的模型：Proposer 从 API 集合生成 Torch 模块作为高层规格，Coder 把模块翻译成 CUDA 或 Triton kernel，两者交替用各自的 GRPO 奖励更新，形成自动课程。 相对以往把 kernel 生成当作单一模型任务的路线，这里把“出题”和“解题”分成两个可分别优化的角色，使训练数据随 Coder 能力动态变化，而不依赖固定语料。 论文给出两阶段映射的形式化定义、交替优化流程，以及 Proposer 与 Coder 各自的奖励设计；训练细节写明两者均由 Qwen2.5-Coder-7B 初始化，交替共 4 轮、每轮各 20 步。

frontier-driven 模块生成机制从 Coder 失败的模块中抽取 API 集合构造 Proposer 输入，并用 Frontier Reward 把生成模块的成功率推向约一半，使模块既非平凡也非不可解。 这直接回应论文指出的“与模型当前能力对齐的高质量数据稀缺”问题，用正确性反馈自动产生能力对齐的训练数据，无需人工标注。 论文描述了 API 共现分布采样、AST 检查、可运行检查与数值稳定性三步验证，并给出 Frontier Reward 在成功率接近一半时最大的形式；消融显示冻结 Proposer 后继续训练 Coder，CUDA 与 Triton 的 pass@1 与 fast1@1 均低于持续更新 Proposer 的版本。

CA-GRPO 通过组级门控把正确性与性能信号分开，只有当组正确率达到阈值后，正确 kernel 才获得归一化加速比奖励。 论文指出以往 RL 方法通常把正确性与性能当作单一未区分奖励，这里显式区分两者，以缓解“只优化正确性导致保守实现、只优化性能破坏功能等价”的取舍。 论文在 KernelBench Level 1 与 2 合并的 200 个任务上比较不同正确性阈值，报告中间阈值在正确性与加速比之间取得更好平衡，并给出六个代表性算子上四种训练变体的最快正确 kernel 对比。

在 KernelBench 上，KernelZero-7B 的 CUDA 结果为 Level 1 的 75.8 pass@1、98.87 pass@5、100 pass@10，Level 2 的 69.6 pass@1、93.70 pass@5、97 pass@10；Triton 为 Level 1 的 77.2 pass@1、97.41 pass@5、99 pass@10，Level 2 的 72.5 pass@1、94.96 pass@5、98 pass@10。 论文称其在 CUDA 上超过 Claude-4.5-Sonnet、在 Triton 上超过 DeepSeek-V4-Pro，且 CUDA Level 1 的 pass@1 与 Claude-4.5-Sonnet 相差 0.6 个百分点以内，而 pass@5 与 pass@10 在两个 Level 上更高。 结果来自 KernelBench 的 250 个任务（Level 1 为 100 个单 kernel 算子，Level 2 为 100 个融合模式），采用一次性提示生成，并报告 pass@k 与 fastp@k 两类指标及平均输出 token 数；评测使用基于 cudaLLM 的 Keck 验证服务，包含单样本 GPU 执行、参数一致性与正确性门控的性能测量。

这项工作面向以 PyTorch 参考实现为起点、需要生成 CUDA 或 Triton kernel 的 kernel 生成场景，适用于 KernelBench 这类以正确性与相对 PyTorch Eager 加速比为指标的评测设定。它使能力对齐的训练数据可以自动产生，让较小模型在无需重复完整流水线的情况下持续改进，对从事 kernel 生成训练与评测的研究者、以及需要为特定算子组合寻找高效实现的工程团队有直接用途。论文也说明生成的 CUDA kernel 不调用外部高性能库，因此 Level 2 中大量含卷积或 GEMM 的任务面对的是 cuDNN 或 cuBLAS 支撑的 PyTorch 参考，这一设定界定了结果适用的范围。

论文正文中若干具体数值在摘要与实验段落里以占位形式出现，例如摘要中 CUDA Level 1/2 的 pass@1 与 pass@10 未给出数字，消融中 Proposer 冻结对比与正确性阈值对比的若干百分比也留空，因此这些细节只能以表格与结论段落中已给出的数字为准。CA-GRPO 的正确性阈值选择、Frontier Reward 中成功率接近一半这一目标在不同后端与不同难度层级上的稳定性，以及 Keck 评测服务在更大规模任务上的表现，都是读者可以继续关注的方向。此外，Level 2 上 CUDA 与 Triton 的 fast1@1 差距被论文归因于后端抽象与是否调用厂商库，这一解释在更多算子类型上的适用程度仍属开放问题。