EvoEngineer: Mastering Automated CUDA Kernel Code Evolution with Large Language Models

Conference: ICLR 2026 arXiv: 2510.03760 Code: Available (open-source platform) Area: LLM Efficiency Keywords: CUDA Kernel Optimization, LLM Code Evolution, Evolutionary Search, Code Generation, Prompt Engineering

TL;DR

This paper proposes EvoEngineer, the first systematic LLM-based code evolution framework that decomposes code evolution into two orthogonal components — traverse technique (with a two-layer design: solution guiding + prompt engineering) and population management. On 91 real-world CUDA kernels, EvoEngineer achieves a median speedup of up to 2.72× and a code validity rate of 69.8%, outperforming existing methods on both performance and correctness.

Background & Motivation

Background: CUDA kernel performance is a core bottleneck in AI training and inference efficiency. Manual optimization demands deep expertise in GPU architecture (memory hierarchy, thread scheduling, Tensor Cores, etc.), while LLMs have demonstrated potential for automated optimization. Recent approaches include kernel-specific methods such as AI CUDA Engineer and KernelBench, as well as general-purpose code evolution methods such as EoH and FunSearch.

Limitations of Prior Work: (a) Kernel-specific methods tightly couple the evaluation process with the optimization strategy, leading to unclear problem formulations that preclude fair comparison; (b) General-purpose code evolution methods have only been validated in settings with relaxed correctness requirements (e.g., mathematical problems), making them ill-suited for the strict correctness constraints of CUDA kernels; (c) Both categories of methods lack a systematic framework for understanding the effectiveness of different optimization strategies across different scenarios.

Key Challenge: There exists a fundamental trade-off between performance improvement and code correctness. Pursuing high speedup ratios often degrades code validity, while conservative strategies limit the performance ceiling. Existing methods either ignore this trade-off (strategy-agnostic) or consume excessive tokens through overly complex prompts (resource-inefficient).

Goal: How can optimization strategies be systematically selected and designed to simultaneously improve both performance and correctness in LLM-based kernel optimization?

Key Insight: Decompose code evolution into two orthogonal components (traverse + population management), and further decouple the strategy layer from the prompt engineering layer within traverse, enabling systematic analysis and design of optimization strategies.

Core Idea: Through a two-layer decomposition of traverse technique design — separating "what information guides the search" from "how to construct the prompt" — the framework enables systematic analysis and selection of LLM-based code evolution strategies.

Method

Overall Architecture

EvoEngineer decomposes LLM-based code evolution into two orthogonal components: Traverse Techniques (code space navigation strategies) and Population Management (candidate solution maintenance strategies). The overall workflow consists of three steps: (1) Task Configuration: specifying GPU type, CUDA version, evaluation metrics, etc.; (2) Solution Generation: implementing traverse technique and population management; (3) Solution Evaluation: compilation check + functional testing + performance measurement.

Key Designs

1. Two-Layer Traverse Technique

   • Function: Decomposes code space navigation into two layers — the Solution Guiding Layer (determining "what information to provide to the LLM") and the Prompt Engineering Layer (determining "how to organize the prompt").
   • Mechanism: The Solution Guiding Layer manages three categories of closed-world information: (I1) current task context (optimization objectives and constraints); (I2) historical high-quality solutions; (I3) optimization insights (design rationale and LLM reasoning traces). Open-world information (I4: domain knowledge) may also be optionally incorporated. The Prompt Engineering Layer translates upper-layer strategies into concrete prompts.
   • Design Motivation: Existing methods (EoH, FunSearch) conflate search strategy with prompt engineering by mimicking evolutionary operators (crossover/mutation), with no empirical evidence that LLMs can effectively execute such operations. The two-layer separation enables independent analysis of strategy design and prompt optimization.

2. Three EvoEngineer Configurations

   • EvoEngineer-Free: Uses only task context (I1) with simple prompts and a best-solution maintenance strategy. Prioritizes exploration; lower correctness but higher speedup.
   • EvoEngineer-Insight: Uses I1 + I3 (optimization insights), treating insights as an independent information source rather than binding them to specific solutions. Maintains a single best solution.
   • EvoEngineer-Full: Integrates I1 + I2 + I3 (task context + historical solutions + optimization insights) with an elite preservation strategy. Expected to achieve the highest correctness given maximum information utilization.
   • Design Motivation: The three configurations systematically explore the effect of different information combinations, revealing the relationship between information quantity and performance/correctness.

3. Population Management Strategies

   • Function: Defines how candidate solutions are maintained, selected, and evolved.
   • Three strategies: (1) Single-solution strategy: maintains only the current best solution; (2) Elite preservation strategy: retains a small set of high-performance solutions; (3) Diversity maintenance strategy: preserves solution diversity to explore the search space.
   • Design Motivation: Different maintenance strategies affect the exploration-exploitation balance — the single-solution strategy is faster but prone to local optima, while the elite strategy demonstrates stronger advantages in correctness.

4. Two-Stage Evaluation Pipeline

   • Function: Each generated kernel undergoes two-step validation: compilation check and functional testing.
   • Mechanism: The compilation check verifies syntactic validity; functional testing compares output against a PyTorch reference implementation using 5 test cases. Kernels that pass are evaluated by measuring average execution time over 100 runs.
   • Design Motivation: Strict correctness verification is a core constraint in CUDA kernel optimization, distinguishing it from general code generation tasks.

Loss & Training

This work does not involve conventional loss-based training; instead, it employs search-based optimization. The core optimization objective is: \(p^* = \arg\min_{p \in \mathcal{S}} f(p)\), subject to the constraint \(g(p) = 0\) (compilation success + functional correctness). Each kernel is allocated a maximum of 45 optimization trials.

Key Experimental Results

Main Results

Method	LLM	Median Speedup	Functional Correctness (Pass@1)	Compilation Success Rate
AI CUDA Engineer	GPT-4.1	1.19	59.4%	84.0%
FunSearch	GPT-4.1	1.34	53.2%	73.8%
EoH (EvoEngineer-Solution)	GPT-4.1	1.57	53.7%	74.7%
EvoEngineer-Free	Claude-Sonnet-4	2.72	52.2%	74.1%
EvoEngineer-Insight	GPT-4.1	1.60	60.0%	82.2%
EvoEngineer-Full	GPT-4.1	1.20	69.8%	87.5%

Maximum speedup: 36.75× over PyTorch kernels. Among 50 operations achieving 2× speedup, EvoEngineer achieves the highest speedup on 28 (56%) of them.

Ablation Study

Information Combination	Speedup Direction	Correctness Direction	Notes
I1 only (Free)	Highest (2.72×)	Lowest (52.2%)	Free exploration, high risk / high reward
I1 + I3 (Insight)	Moderate (1.60×)	Moderate (60.0%)	Insights improve correctness but constrain exploration
I1 + I2 (EoH/Solution)	Moderate (1.57×)	Lower (53.7%)	Historical solutions add constraints
I1 + I2 + I3 (Full)	Lower (1.20×)	Highest (69.8%)	More information yields higher correctness but more conservative speedup

Key Findings

• Information quantity and performance/correctness are inversely related: More information (I2+I3) significantly improves correctness (+17.6%) at the cost of speedup (−56%).
• LLM selection has a substantial impact: The Claude-Sonnet-4 + EvoEngineer-Free combination achieves the highest speedup (2.72×), indicating that stronger LLMs perform best under free exploration strategies.
• EvoEngineer-Full significantly leads on correctness: 69.8% vs. AI CUDA Engineer's 59.4%, with a compilation success rate of 87.5% vs. 84.0%.
• AI CUDA Engineer employs complex prompts with >5 historical solutions yet achieves the lowest speedup, validating the "strategy-agnostic" problem.

Highlights & Insights

• First systematic decomposition of code evolution into orthogonal components: The two-layer traverse design cleanly separates "strategy" from "implementation," enabling fair comparison of different methods within a unified framework. This is transferable to any LLM-based code optimization scenario.
• Reveals a core trade-off in LLM code evolution: More information → higher correctness but more conservative speedup. This is an important framework-level insight with strong implications for future work.
• Problem formalization as a key contribution: Formalizing CUDA kernel optimization as a constrained optimization problem and defining a unified evaluation protocol addresses the fragmentation issue in the field.

Limitations & Future Work

• Evaluated on a single GPU architecture (RTX 4090); cross-architecture generalizability remains unknown.
• The 45-trial budget may be insufficient to fully demonstrate the potential of certain methods.
• Open-world information (I4: domain knowledge) remains unexplored and may be key to raising the performance ceiling.
• The search process remains a brute-force random search combined with LLM generation, lacking learned search strategies (e.g., bandit algorithms, Bayesian optimization).
• Cross-operation optimizations such as kernel fusion are not considered.

Related Work & Insights

• vs. AI CUDA Engineer: AI CUDA Engineer employs complex prompts with >5 historical solutions but lacks a systematic framework, incurring high token costs while underperforming EvoEngineer-Free (speedup of only 1.19 vs. 2.72).
• vs. FunSearch/EoH: These general-purpose methods are unified within the EvoEngineer framework. EoH is mapped to the EvoEngineer-Solution configuration. FunSearch uses only 2 historical solutions and does not leverage optimization insights.
• vs. Traditional Genetic Programming: Traditional methods operate in AST/syntax tree space, whereas LLM-based methods search directly in text space, offering greater flexibility.

Rating

• Novelty: ⭐⭐⭐⭐ The framework design and decomposition approach are innovative, though individual components are not novel in isolation.
• Experimental Thoroughness: ⭐⭐⭐⭐⭐ 91 kernels × 3 LLMs × 6 methods, with comprehensive analysis.
• Writing Quality: ⭐⭐⭐⭐ Clear structure and systematic analysis, though notation is somewhat redundant.
• Value: ⭐⭐⭐⭐ Offers a framework-level contribution to LLM-based code optimization.

Related Papers

• [ICLR 2026] DND: Boosting Large Language Models with Dynamic Nested Depth
• [ICLR 2026] Expert Divergence Learning for MoE-based Language Models
• [AAAI 2026] The Curious Case of Analogies: Investigating Analogical Reasoning in Large Language Models
• [NeurIPS 2025] L-MTP: Leap Multi-Token Prediction Beyond Adjacent Context for Large Language Models
• [AAAI 2026] Scaling and Transferability of Annealing Strategies in Large Language Model Training