KernelZero: Co-Evolving Proposer and Coder for Continuously Improved GPU Kernel Generation
Changxin Ke, Rui Zhang, Zixiang Fang, Zhenghong Li, Yuanbo Wen, Jiashuo Shen, Shuo Wang, Jiaming Guo and 3 others
Institute of Computing Technology, CAS · University of Chinese Academy of Sciences · Institute of Software, CAS · Institute of AI for Industries, Chinese Academy of Sciences
Published September 27, 2026 · on the feed September 29, 2026 · ▲ 5 · arXiv 2609.33074
The abstract
High-performance GPU kernels are essential to modern machine learning systems, yet automatically generating kernels that are both correct and efficient remains challenging. Existing LLM-based approaches face two major limitations: the scarcity of high-quality training data aligned with the model's current capabilities, and the inherent trade-off between kernel correctness and performance. To address these challenges, we propose KernelZero, a co-evolution framework that continuously improves GPU kernel generation through two specialized models: a Proposer that generates Torch modules from API sets and a Coder that translates them into CUDA or Triton kernels. KernelZero uses a frontier-driven module generation mechanism to continuously produce capability-aligned training modules based on the Coder's current weaknesses. It further introduces Correctness-Aware Group Relative Policy Optimization (CA-GRPO), which optimizes performance only after correctness becomes sufficiently reliable. By alternating the optimization of the Proposer and Coder, KernelZero forms an automatic curriculum that enables targeted and training-efficient capability improvement. Empirically, KernelZero-7B surpasses Claude-4.5-Sonnet on CUDA and DeepSeek-V4-Pro on Triton. On KernelBench Level 1 and 2, it achieves CUDA pass@1 scores of 75.8% and 69.6%, respectively, with pass@10 reaching 100% and 97%. On Triton, it achieves pass@1 scores of 77.2% and 72.5%, respectively.
The Brief
2:32A short podcast summary of the paper. Written and voiced by AI.
Transcript
KernelZero. Co-Evolving Proposer and Coder for Continuously Improved GPU Kernel Generation. By Changxin Ke and ten others, from the Institute of Computing Technology, Chinese Academy of Sciences, the University of Chinese Academy of Sciences, and two other institutions. Published on the twenty-seventh of September. No code repository is linked to it.
Modern machine learning systems depend on high-performance GPU kernels, and generating kernels automatically that are both correct and fast is still hard. LLM-based approaches run into two limits. The first is data: there is little high-quality training material, and even less that matches what the model can currently do. Training data that sits far from the model's present level is not aligned with what it can use. The second is a built-in tension between getting a kernel right and making it perform well.
KernelZero answers with co-evolution between two specialised models. A Proposer generates Torch modules from API sets. A Coder translates those modules into CUDA or Triton kernels. Each side gives the other something to work on: the Proposer supplies problems, and the Coder's performance shapes which problems come next.
A frontier-driven module generation mechanism keeps producing training modules aligned to the Coder's current capability, based on where the Coder is currently weak. That addresses the data problem. For the correctness tension, the framework introduces Correctness-Aware Group Relative Policy Optimization, CA-GRPO, which optimizes performance only once correctness has become reliable enough. Speed is not chased before the kernel can be trusted. Optimization then alternates between the Proposer and the Coder, and that alternation forms an automatic curriculum, one that is targeted and efficient to train with.
Empirically, KernelZero-7B surpasses Claude-4.5-Sonnet on CUDA and DeepSeek-V4-Pro on Triton. On KernelBench, the CUDA pass at one scores are seventy-five point eight percent on Level 1 and sixty-nine point six percent on Level 2. Pass at ten reaches one hundred percent on the first level and ninety-seven percent on the second.
For Triton, pass at one is seventy-seven point two percent on Level 1 and seventy-two point five percent on Level 2. On both kernel languages, then, the first level is solved more often than the second.
Two problems, two separate answers, one loop. The Proposer keeps the Coder supplied with problems at the edge of its ability, and CA-GRPO keeps the Coder from trading correctness for speed. Alternate the two, and the curriculum writes itself from the Coder's own weaknesses rather than from a fixed dataset.
Paper Quest · 7 chapters · about 40 min
Play this paper
Learn it by doing: make the calls the authors made, guess the result before you see it, and defend it in a viva graded on your own words. Chapter 1 is right here.
Chapter 1 🧩 · The problem
Every quest starts with a wall. Here it is a kernel writer with nothing good left to practise on.
You train a language model to turn PyTorch modules into fast GPU kernels. Good training problems are scarce, and the ones you have are either far too easy or far too hard for the model as it is now.
The road ahead
- 1 · The problem ~6 min Training a model to write fast GPU kernels stalls when practice problems don't match its level and the reward pits correctness against speed.
- 2 · What came before ~3 min
- 3 · The key idea ~9 min A second model writes practice modules aimed at the Coder's weak spots, speed is paid only once kernels are reliably correct, and the two train in turn.
- 4 · Choose your own research ~3 min
- 5 · Build the method ~8 min The Proposer writes Torch modules from API sets, the Coder turns them into kernels, and the Coder's reward secures correctness before paying for speed.
- 6 · The experiment ~6 min You’ll guess: Could the small KernelZero-7B model outperform Claude-4.5-Sonnet at generating CUDA kernels?
- 7 · The viva ~5 min Three questions from the examiners, answered in your own words. Win it for the paper’s trophy.
Free, with Google or an email address. Your stars and progress are kept.