The Correctness Illusion in LLM-Generated GPU Kernels

Abstract: Benchmarks for LLM-generated GPU kernels (KernelBench, TritonBench, GEAK) score correctness through fixed-shape, small-sample allclose-style checks. The number of inputs varies between benchmarks. The shape, dtype, and tolerance are fixed for each kernel. We test that oracle empirically. We construct a controlled corpus of 24 Triton and CPU stand-in kernels (15 correct controls and 9 LLM-style buggy variants seeded with documented transcription errors) and re-evaluate it under op-schema-aware seeded fuzzing with a high-precision (fp64) CPU reference and per-(op, dtype) absolute tolerances. The seeded oracle flags 9 of 9 buggy kernels and passes 15 of 15 correct controls, at zero precision cost on controls. We extend the corpus to 26 ops (adding a flash-attention pair) and re-run the same protocol on five GPU classes (RTX 3060, A10, L40S, A100 SXM4, H100 NVL). The verdicts are identical across all five GPUs: 10 of 10 illusions caught and 16 of 16 controls clean. The corpus result is about LLM-style transcription bugs that the allclose-on-one-shape oracle certifies as correct, not about the bug rate of any specific deployed LLM. Every flagged failure replays byte-for-byte from a stored seed.

• The paper demonstrates that conventional allclose-style benchmarks mistakenly certify buggy kernels by missing both transcription and shape-dependent errors.
• It introduces an op-schema-aware seeded fuzzing protocol that validates outputs using high-precision (fp64) CPU references and absolute per-op tolerances.
• The evaluation across multiple GPU architectures confirms consistent detection of bugs, underscoring the need for boundary-aware input generation in kernel validation.

Authoritative Summary of "The Correctness Illusion in LLM-Generated GPU Kernels"

Problem Statement and Context

This paper rigorously interrogates the prevailing evaluation methodologies used for assessing the correctness of GPU kernels generated by LLMs, focusing specifically on widely-adopted benchmarks such as KernelBench, TritonBench, and GEAK. These benchmarks rely primarily on fixed-shape, small-sample allclose-style tests that exercise single reference shapes and dtypes, with hand-selected tolerances. Such evaluation protocols risk certifying buggy kernels as correct, creating a systematic correctness illusion. The paper constructs a controlled corpus of Triton and numpy stand-ins, with seeded LLM-style transcription bugs, and introduces an op-schema-aware seeded fuzzing protocol. A high-precision (fp64) CPU reference and per-(op, dtype) absolute tolerances serve as the correctness oracle, in sharp contrast to the usual PyTorch-centric relative+absolute allclose checks.

Methodology

The evaluation pipeline is divided into four key contributions:

1. Op-schema-aware Shape Generation: The fuzzer samples input shapes based on operator schemas (e.g., matmul $A[M,K] \cdot B[K,N]$, attention $B,H,S,D$), systematically covering both regular and critical boundary values known to expose subtle shape-dependent bugs. Deterministic sampling from a master seed ensures reproducibility and thorough domain coverage.
2. High-Precision Oracle: Outputs are validated against an fp64 CPU reference, with absolute (not relative+absolute) per-(op, dtype) tolerances. The validator logs the full error distribution, including max/mean abs/rel error and ULP percentiles, supporting detection of low-magnitude but functionally erroneous kernels.
3. Corpus Construction and Evaluation: The corpus contains 24 kernels (15 controls, 9 buggy variants) and is extended to 26 kernels for cross-GPU evaluation. Each buggy variant encodes a canonical LLM transcription error, including dropped scale factors (e.g., GELU missing $0.5$), wrong mask semantics (softmax tail handling), incorrect accumulation, parameter confusion (wrong $\alpha$ in LeakyReLU), etc. Verdicts are tested across five GPU architectures.
4. Reproducibility Pipeline: All failed shards store input seeds for strict replay validation, ensuring bitwise consistency across reruns.

Figure 1: Verdict per kernel on the full 26-op corpus, plotted from the RTX~3060 cross-GPU run. Green indicates correctness (clean pass); red indicates illusions (bench oracle pass, seeded oracle fail).

Empirical Findings

Across the full evaluation, the seeded oracle flags 10 of 10 LLM-style buggy variants and passes 16 of 16 correct controls, with zero precision loss on controls. Notably, the traditional allclose-style benchmarks certify these buggy kernels as correct, failing to detect transcription and shape-sensitive errors. Cross-architecture evaluation shows verdict invariance: every illusion and control observed on RTX~3060 is consistently reproduced on A10, L40S, A100~SXM4, and H100~NVL.

Figure 2: Cross-GPU verdict consistency on the 26-op corpus. Rows represent GPU classes; columns represent kernel fail rates. Controls are consistently green (passing), illusions are consistently red (failing) on all tested GPUs.

Experimental results demonstrate categorical separation:

• Magnitude-uniform bugs (e.g., GELU missing $0.5$, silu with sigmoid(2x), rmsnorm/l2norm missing sqrt) are caught on every shape unless tolerances are deliberately set above the bias envelope.
• Shape-dependent bugs (softmax tail masking, matmul accumulator overwrite) are only surfaced with boundary-aware fuzzing, invisible to regular-shape sampling.

Minimal failing shapes (e.g., softmax$\_$triton$\_$buggy at $[1,1,3]$ fp16) consistently evade fixed-shape or regular shape-based sampling. Replay scripts confirm bit-for-bit verdict matching, establishing strict reproducibility.

Implications and Future Directions

The findings refute the adequacy of fixed-shape/small-sample allclose oracles for LLM-generated kernel validation. Such protocols systematically miss both magnitude-uniform and shape-dependent bugs that arise in LLM transcription. The paper's op-schema-aware seeded fuzzing, high-precision reference validation, and boundary-focused sampling achieve full recall over the tested bug classes, with cross-GPU consistency.

Practical implications include the necessity for benchmarks and agentic kernel synthesis systems (KernelBand, STARK) to adopt op-schema-aware input generation and principled tolerance calibration. The approach is immediately actionable in any framework dependent on allclose-style oracles, as absolute-per-(op, dtype) thresholds, boundary-aware shape sets, and input generation all reside in user-space infrastructure.

Theoretical implications call for a re-examination of the formal correctness definition in deep learning kernel evaluation, particularly regarding operator domain, dtype, tolerance specification, and reference semantics. Extending the corpus to fuzz real LLM outputs (e.g., from GEAK or KernelBench) and expanding dtype coverage (e.g., bfloat16) remain critical future steps. Cross-dtype comparisons (e.g., kernel-fp16 vs reference-fp64) warrant further investigation.

Conclusion

The paper systematically exposes illusions in LLM-generated GPU kernel validation, demonstrating that current fixed-shape, allclose-style oracles are insufficiently discriminative. Its op-schema-aware seeded protocol consistently surfaces transcription bugs, including both shape- and magnitude-dependent errors, across diverse GPU architectures. Adoption of boundary-aware input generation, absolute tolerance calibration, and high-precision reference oracles is recommended for all LLM kernel benchmarks and synthesis workflows.