The Correctness Illusion in LLM-Generated GPU Kernels

Technical Summary: The Correctness Illusion in LLM-Generated GPU Kernels

Problem Statement
Current benchmarks for evaluating Large Language Model (LLM)-generated GPU kernels (e.g., KernelBench, TritonBench, GEAK) rely on a "fixed-shape, small-sample allclose-style" oracle to determine correctness. These benchmarks typically test a single input shape and data type (dtype) with hand-picked tolerances. The authors argue that this oracle is systematically optimistic, creating a "correctness illusion" where buggy kernels pass validation while containing significant errors. Specifically, the authors identify three failure modes in current evaluation methods:

1. Shape Rigidity: Testing only one shape per operation fails to detect bugs related to tail masking, off-by-one accumulation, or block-size assumptions that only manifest at specific dimensions.
2. Dtype Rigidity: Testing only the primary dtype (e.g., fp32) misses mixed-precision errors, such as overflow, underflow, or accumulation drift in fp16 or bf16.
3. Loose Tolerances: Hand-picked absolute (atol) and relative (rtol) tolerances are often orders of magnitude looser than the kernel's actual error envelope, allowing real numerical errors to be absorbed.

Methodology
To empirically test this hypothesis, the authors constructed a controlled corpus and a new evaluation pipeline:

• The Corpus: A set of 24 kernels (extended to 26 for cross-GPU testing) comprising 15 correct control kernels and 9 (later 10) "LLM-style buggy variants." The buggy variants were not pulled from live LLM outputs but were author-seeded with documented transcription errors common in LLM-generated code (e.g., missing 0.5 in GELU, incorrect tail masking in softmax, missing sqrt in RMSNorm, accumulator overwrites in matmul, and incorrect scaling in attention mechanisms).
• Op-Schema-Aware Fuzzing: Instead of random shape generation, the fuzzer uses the operator's schema (e.g., matmul A[M, K] · B[K, N]) to generate inputs. It samples values for symbolic dimensions (M, K, N) from a candidate set that explicitly includes boundary values (e.g., 1, 3, 7, 256, 1025) alongside regular values. This ensures coverage of edge cases like tail blocks.
• High-Precision Oracle: The validation oracle compares kernel outputs against a high-precision (fp64) CPU reference, rounded to the target dtype. Crucially, it uses per-(op, dtype) absolute tolerances rather than the combined absolute/relative allclose metric used by PyTorch. It also records full error distributions (ULP percentiles, NaN/Inf detection).
• Reproducibility: The system is fully reproducible; every flagged failure stores a binary input snapshot and a seed, allowing byte-for-byte replay of the failure.

Key Results
The study was conducted on a single GPU (RTX 3060) and extended across five GPU classes (RTX 3060, A10, L40S, A100 SXM4, H100 NVL).

• Detection Rate: The seeded oracle successfully flagged 9 of 9 (and later 10 of 10) buggy kernels.
• False Positives: The oracle passed 15 of 15 (and later 16 of 16) correct control kernels with zero false positives.
• Cross-Architecture Consistency: The verdicts were identical across all five GPU classes, confirming that the "illusions" (bugs that pass standard benchmarks but fail the rigorous oracle) are consistent regardless of the underlying hardware architecture.
• Bug Categories: The authors partition the detected bugs into two classes:
  1. Magnitude-uniform bugs: Errors like missing constants or wrong scaling factors that are caught on almost every shape but missed by standard benchmarks due to loose tolerances.
  2. Shape-dependent bugs: Errors like tail-mask leaks or accumulation overwrites that are invisible without boundary-aware shape generation.

Significance and Claims
The paper claims to demonstrate that the standard "allclose-on-one-shape" oracle is insufficient for certifying the correctness of LLM-generated GPU kernels. The "correctness illusion" arises because current benchmarks certify kernels as correct based on a narrow slice of the input domain and loose error margins.

The authors emphasize that their results are specifically about which bug patterns the current oracle certifies as correct, rather than the bug rate of any specific deployed LLM. By using author-seeded bugs, they establish a ground truth for specific transcription errors known to occur in LLM code generation. The paper concludes that the countermeasures required to fix this—boundary-aware shape sets, per-op/dtype tolerance calibration, and principled input generation—are feasible for any project currently using allclose-style oracles.

Limitations Noted
The authors explicitly state that the buggy variants are author-seeded based on documented patterns, not sampled from real LLM outputs, meaning the study measures the oracle's sensitivity to specific known error types rather than the general failure rate of LLMs. Additionally, the current implementation relies on same-dtype comparison (kernel-fp16 vs. reference-fp16) and does not yet support cross-dtype validation or native bf16 client decoding (proxied via fp16).