AutoKernel: Automated Kernel Design & Tuning

• AutoKernel is a multi-domain framework that automates the selection and tuning of kernels by reducing high-dimensional design spaces using empirical feedback and prior structure.
• It leverages diverse methodologies—from data-dependent Gaussian process kernel learning and deep kernelized autoencoders to profiling-driven and evolutionary GPU kernel synthesis—to optimize performance.
• The approach integrates statistical, systems, and OS-level techniques, paving the way for hybrid solutions that combine symbolic reasoning, search strategies, and learned optimization.

AutoKernel denotes a family of methods that automate the choice, learning, extraction, synthesis, or tuning of kernels, but the object called a “kernel” varies sharply across subfields. In the supplied literature, AutoKernel refers to statistical kernels in Gaussian processes and representation learning, compute kernels for GPUs, NPUs, CPUs, and whole-model megakernels, Linux kernel configuration tuning, and the extraction of repeated execution kernels from dynamic traces (Wilson et al., 2015, Du et al., 29 Dec 2025, Lin et al., 12 Mar 2025, Uhrie et al., 2020). This suggests that AutoKernel is best understood as an automation agenda over kernel design spaces rather than as a single algorithm.

1. Conceptual scope

The literature uses the same term for at least three distinct but structurally related problems. In each case, the central task is to move from a large, high-dimensional kernel design space to a smaller set of high-value kernel choices by combining prior structure with empirical feedback.

Usage of AutoKernel	Kernel object	Representative line of work
Statistical kernel learning	Covariance or similarity kernel	Human inductive-bias inference, data-dependent kernel regression, kernelized autoencoders
Systems kernel synthesis	Hardware execution kernel	GPU/NPU/CPU operator kernels, profiling-guided tuning, megakernel generation
Kernel/OS automation	Linux kernel or dynamic code kernel	Kconfig tuning, vulnerable-environment generation, trace-based kernel extraction

A common misconception is that AutoKernel always means automatic CUDA or GPU kernel generation. The supplied corpus does support that meaning, but it also includes automatic kernel learning in Bayesian nonparametrics, explicit kernel approximation in deep representation learning, Linux kernel configuration tuning, and automatic kernel extraction from program traces (Simon, 2022, Ouyang et al., 14 Feb 2025, Ruan et al., 2024).

2. Statistical kernel automation

In statistical machine learning, AutoKernel concerns the automatic construction or adaptation of similarity and covariance structure. A direct formulation appears in the human function-learning work that treats a human learner as a black-box Gaussian process with an unknown kernel $k_{\text{human}}$, then infers a candidate kernel $k_\theta$ from multiple human extrapolations by maximizing a predictive conditional marginal likelihood of the form

$$\max_\theta \sum_{j=1}^{W} \log p(\mathbf{y}_*^{(j)} \mid \mathbf{y}, k_\theta),$$

using either spectral mixture parameterizations or empirical covariance estimation (Wilson et al., 2015). In that setting, learned human kernels capture heavy-tailed correlations, trend-plus-local-structure behavior, and highly nonstationary patterns such as sawtooth and step extrapolations that standard RBF or stationary kernels miss.

A more normative statement appears in kernel regression with data-dependent kernels. There, when the kernel may be chosen after observing the dataset $\mathcal{D}$, the Bayes-optimal choice is the posterior kernel

$$K_{\text{post}}(x,x') = \mathbb{E}_{f \sim \mu_f \mid \mathcal{D}}[f(x)f(x')],$$

and kernel regression with $K_{\text{post}}$ recovers the posterior mean, achieving minimum expected test risk among all predictors under squared loss (Simon, 2022). The same paper contrasts this with the fixed-kernel setting, where the optimal choice is the prior covariance kernel. In AutoKernel terms, this gives a theoretical target for data-dependent kernel adaptation: a good learned kernel should move toward posterior-like, label-aligned structure.

Deep representation learning introduces a second statistical interpretation. The deep kernelized autoencoder learns codes whose Gram matrix approximates a user-specified prior kernel matrix $\mathbf{P}$, via the objective

$$L = (1-\lambda)L_r(\mathbf{x}, \tilde{\mathbf{x}}) + \lambda L_c(\mathbf{C}, \mathbf{P}),$$

where $L_c$ is a normalized Frobenius-distance kernel-alignment term (Kampffmeyer et al., 2017). This yields an explicit encoder approximating a kernel feature map and a decoder approximating the pre-image map. On the denoising experiment reported there, dkAE+PCA obtained MSE $0.0358$ versus $k_\theta$0 for kPCA with a separate pre-image procedure. A related generative-model line learns a data-dependent spectral distribution $k_\theta$1, proves positive definiteness for the resulting kernel, and shows that the induced MMD can endow the continuity property in weak topology by simple regularization (Zhou et al., 2019).

Across these works, the statistical meaning of AutoKernel is not mere hyperparameter tuning. It is kernel discovery conditioned on richer evidence: behavioral data, posterior information, or user-specified similarity structure.

3. Automatic synthesis and tuning of compute kernels

In systems research, AutoKernel usually means automatic synthesis, migration, optimization, or retargeting of hardware execution kernels. One representative architecture is the multi-agent framework that automates kernel generation, migration, and performance tuning across multiple DSLs and hardware backends. Its core agents are Designer, Coder, Verifier, and Conductor, and its portable intermediate representation is a Unified Sketch

$k_\theta$2

with declarations, operations, control flow, and optimization hints. Evaluated on KernelBench using Triton DSL across GPU and NPU backends, it achieves an average speedup of $k_\theta$3 over PyTorch Eager baselines implementations (Du et al., 29 Dec 2025).

A second line adds explicit profiling semantics to the optimization loop. The profiling-reasoned multi-agent framework integrates execution feedback with Nsight Compute on GPU and Linux perf on CPU, and the Conductor agent reasons over occupancy, thread register usage, shared memory utilization, tensor core active cycles, memory throughput, IPC, front-end bound, and back-end bound. It reports $k_\theta$4 and $k_\theta$5 averaged speedups against Torch on CPU and GPU platforms, respectively (Lei et al., 9 Nov 2025). Taken together, the systems literature suggests a recurring loop of generation, compilation, correctness checking, profiling, and targeted refinement.

Evolutionary approaches occupy another major branch. One diagnosis-driven framework for Triton/GPU kernels combines retrieval-augmented initialization, multi-island evolutionary search, structured diagnostic feedback, an experience library, and explicit anti-cheating mechanisms; on KernelBench it achieves up to $k_\theta$6 correctness on Level 2 (Huang et al., 8 May 2026). In a reference-scarce RISC-V setting, Evolution of Kernels mines optimization ideas from OpenBLAS development history, formalizes them as ideas and actionable thoughts, augments generation with RISC-V-specific RAG, and reports a median $k_\theta$7 speedup while surpassing human experts on all $k_\theta$8 evaluated kernel design tasks (Chen et al., 14 Sep 2025).

Whole-model synthesis extends the notion further. AutoMegaKernel compiles a HuggingFace Llama-family model into a single persistent cooperative CUDA kernel that runs the whole forward pass in one launch. Its frozen schedule-IR validator statically certifies deadlock-freedom and race-freedom via static graph checks; across $k_\theta$9 adversarial schedules, including $$\max_\theta \sum_{j=1}^{W} \log p(\mathbf{y}_*^{(j)} \mid \mathbf{y}, k_\theta),$$0 unsafe ones, it had zero false-accepts and accepted all $$\max_\theta \sum_{j=1}^{W} \log p(\mathbf{y}_*^{(j)} \mid \mathbf{y}, k_\theta),$$1 real lowerings (Jaber et al., 8 Jun 2026). The same source retargets $$\max_\theta \sum_{j=1}^{W} \log p(\mathbf{y}_*^{(j)} \mid \mathbf{y}, k_\theta),$$2 from one codebase, auto-generates correct megakernels for $$\max_\theta \sum_{j=1}^{W} \log p(\mathbf{y}_*^{(j)} \mid \mathbf{y}, k_\theta),$$3 of $$\max_\theta \sum_{j=1}^{W} \log p(\mathbf{y}_*^{(j)} \mid \mathbf{y}, k_\theta),$$4 supported models, and an unattended autoresearch loop self-improves the megakernel over its own baseline by $$\max_\theta \sum_{j=1}^{W} \log p(\mathbf{y}_*^{(j)} \mid \mathbf{y}, k_\theta),$$5–$$\max_\theta \sum_{j=1}^{W} \log p(\mathbf{y}_*^{(j)} \mid \mathbf{y}, k_\theta),$$6 (Jaber et al., 8 Jun 2026).

4. Benchmarks, evaluation criteria, and selection mechanisms

The most explicit benchmark formulation for LLM-based AutoKernel systems is the 250-task GPU benchmark of PyTorch workloads that introduces the metric

$$\max_\theta \sum_{j=1}^{W} \log p(\mathbf{y}_*^{(j)} \mid \mathbf{y}, k_\theta),$$7

where correctness and speedup over a baseline must hold simultaneously (Ouyang et al., 14 Feb 2025). That study reports that frontier reasoning models perform the best out of the box but still fall short overall, matching the PyTorch baseline in less than $$\max_\theta \sum_{j=1}^{W} \log p(\mathbf{y}_*^{(j)} \mid \mathbf{y}, k_\theta),$$8 of the cases. It also shows that execution and profiling feedback in iterative refinement can materially improve results, especially on fused workloads.

A broader benchmarking move is the 285-task, 14-category, multi-platform benchmark spanning Nvidia GPUs, Huawei NPUs, and Google TPUs, with a modular backend abstraction layer that decouples platform-specific logic from the core infrastructure (Wen et al., 20 Jul 2025). Its results reveal significant variation in task difficulty, poor generalization to platforms with less training exposure, and the effectiveness of category-aware one-shot prompting. The category split is itself informative: activation and reduction are much easier than convolution, fusion, and full architecture generation, and hardware exposure strongly shapes success rates.

An earlier, non-LLM precursor framed AutoKernel as offline pruning plus runtime selection. In a SYCL case study for GEMM kernels, the authors exhaustively evaluated $$\max_\theta \sum_{j=1}^{W} \log p(\mathbf{y}_*^{(j)} \mid \mathbf{y}, k_\theta),$$9 configurations, used machine learning and clustering to prune them to a small library, and then used a lightweight classifier at runtime to select among the retained kernels. The reported result is around $\mathcal{D}$0–$\mathcal{D}$1 of the performance of the globally best configuration while only compiling a handful of $\mathcal{D}$2–$\mathcal{D}$3 kernels (Lawson, 2020). That work established an important pattern later reused in LLM-based systems: expensive exploration offline, inexpensive selection online.

5. Linux-kernel and program-analysis uses

A separate AutoKernel tradition concerns the Linux kernel itself. The requirement-driven OS kernel configuration tuning framework formulates tuning as

$\mathcal{D}$4

where $\mathcal{D}$5 is a natural-language requirement and $\mathcal{D}$6 is a performance evaluation function over kernel configurations (Lin et al., 12 Mar 2025). Its OS-oriented Dual-layer Knowledge Graph $\mathcal{D}$7 combines an instance layer of Kconfig options and dependencies, a concept layer of OS concepts, and cross-layer links connecting options to concepts. In experiments, it reports $\mathcal{D}$8–$\mathcal{D}$9 performance improvements over default configurations across standard OS benchmarks and real-world applications (Lin et al., 12 Mar 2025). Notably, its stability test shows fewer compile and boot failures than the AutoOS baseline.

Security research uses yet another kernel meaning: automated vulnerable environment generation for Linux kernel vulnerabilities. KernJC applies a patch-based approach to identify real vulnerable versions and a graph-based approach to identify the necessary non-default configs that activate a vulnerability. On a dataset of $$K_{\text{post}}(x,x') = \mathbb{E}_{f \sim \mu_f \mid \mathcal{D}}[f(x)f(x')],$$0 representative real-world vulnerabilities with PoCs, it builds vulnerable environments for all $$K_{\text{post}}(x,x') = \mathbb{E}_{f \sim \mu_f \mid \mathcal{D}}[f(x)f(x')],$$1; $$K_{\text{post}}(x,x') = \mathbb{E}_{f \sim \mu_f \mid \mathcal{D}}[f(x)f(x')],$$2 require non-default configs, and $$K_{\text{post}}(x,x') = \mathbb{E}_{f \sim \mu_f \mid \mathcal{D}}[f(x)f(x')],$$3 have incorrect version claims in the National Vulnerability Database (Ruan et al., 2024). At larger scale, it identifies $$K_{\text{post}}(x,x') = \mathbb{E}_{f \sim \mu_f \mid \mathcal{D}}[f(x)f(x')],$$4 vulnerabilities with spurious version claims in NVD (Ruan et al., 2024).

Program-analysis work introduces a third systems meaning: automatic discovery of repeated execution kernels from dynamic traces. The trace-based extraction system defines kernels as semantic collections of basic blocks that are temporally clustered in execution and recur many times during program execution. With optimization, trace collection incurs a time-dilation of a factor of nine and file-size of one megabyte per second; the method was validated across $$K_{\text{post}}(x,x') = \mathbb{E}_{f \sim \mu_f \mid \mathcal{D}}[f(x)f(x')],$$5 libraries, comprising $$K_{\text{post}}(x,x') = \mathbb{E}_{f \sim \mu_f \mid \mathcal{D}}[f(x)f(x')],$$6 kernel instances (Uhrie et al., 2020). This use is not about tuning a predefined kernel at all; it is about discovering kernel structure from runtime behavior so that later optimization or hardware mapping becomes possible.

6. Limitations, misconceptions, and research directions

The most persistent misconception is terminological. “Kernel” can mean a covariance function, a GPU/NPU/CPU operator implementation, a Linux kernel configuration, or a repeated code region in a dynamic trace. The literature does not collapse these meanings into one formalism; instead, it reuses the term for related automation problems over structured design spaces.

Another misconception is that LLM-based AutoKernel has already become a one-shot solved problem. The benchmark evidence does not support that view. On the 250-task GPU benchmark, out-of-the-box frontier reasoning models still match the PyTorch baseline in less than $$K_{\text{post}}(x,x') = \mathbb{E}_{f \sim \mu_f \mid \mathcal{D}}[f(x)f(x')],$$7 of the cases, and the multi-platform benchmark reports poor generalization to platforms with less training exposure (Ouyang et al., 14 Feb 2025, Wen et al., 20 Jul 2025). The strongest current results usually come from multi-agent control, structured IRs, profiling feedback, evolutionary search, retrieval, or category-aware exemplars rather than from unconstrained generation alone.

Performance claims also require careful interpretation. AutoMegaKernel reports wins for a search-found int8 megakernel over CUDA-graphed cuBLAS bf16 at batch-1 decode on several inference-class GPUs, but the paper explicitly states that this is a precision-asymmetric $$K_{\text{post}}(x,x') = \mathbb{E}_{f \sim \mu_f \mid \mathcal{D}}[f(x)f(x')],$$8 versus bf16 comparison at decode position $$K_{\text{post}}(x,x') = \mathbb{E}_{f \sim \mu_f \mid \mathcal{D}}[f(x)f(x')],$$9, and it also reports that AMK trails cuBLAS on A100 and H100, where the harness localizes the cross-SM-sync bottleneck (Jaber et al., 8 Jun 2026). Similarly, statistical AutoKernel ideals can be conceptually strong but computationally limited: the posterior kernel in data-dependent kernel regression is a normative optimum, not a generally tractable algorithm outside special cases, and deep kernelized autoencoders still require a pre-specified kernel matrix $K_{\text{post}}$0 and therefore do not discover kernels from scratch (Simon, 2022, Kampffmeyer et al., 2017).

The current frontier therefore points in several directions at once. The systems papers point toward portable IRs, diagnosis-driven search, explicit anti-cheating constraints, and profiler-informed reasoning. The statistical papers point toward data-dependent kernels, human-inspired priors, and explicit feature/pre-image maps. The Linux-kernel work points toward structured knowledge bases and continuous maintenance as kernels and toolchains evolve. A plausible implication is that future AutoKernel systems will be hybrid systems: part symbolic knowledge base, part search or evolutionary optimizer, part learned generator, and part verifier.