A Contract-Grade Verifier for LLM-Generated GPU Kernels, and a Native Blackwell Backward for the Gated-Linear-Recurrence Family
Abstract: Systems that generate GPU kernels with LLMs report high correctness rates. Those rates come from a single loose test: run the kernel on a few random inputs at one fixed shape and accept it if the output is close to a reference. A kernel can pass that test and still be silently wrong. It can return an ordinary number where the true answer is a NaN or an infinity, differ from run to run, break when the shape changes, or accumulate in fp16 where the reference keeps an fp32 total. We build the instrument that checks correctness properly: a contract-grade verifier of twelve adversarial gates, each a property a correct kernel must satisfy, several of them tolerance-free, so no choice of threshold can explain a failure away. Aimed outward, the verifier audits 2,638 machine-generated kernels that a public system's own harness had already accepted as correct. It finds 39.5% broken beyond any tolerance argument and 62.1% carrying at least one violation. The field's standard test accepts 1,487 kernels the verifier rejects, against only 14 the other way. We defend the finding four independent ways: a 7/7 positive control, a threshold-calibration sweep, 98.5% agreement with the reference benchmark's own correctness code, and a stratified hand-audit. Aimed inward, the verifier judges a kernel of our own: the first native Blackwell tcgen05 training backward for the gated-linear-recurrence (GDN) family, including the reverse-state stage the field still runs on a fallback. We establish its correctness independently, against a double-precision oracle, and train five family members through it. The correctness signal behind reported progress in kernel generation is far weaker than the numbers suggest, and a set of tolerance-free contracts would close most of the gap.
Paper Prompts
Sign up for free to create and run prompts on this paper.
Top Community Prompts
Explain it Like I'm 14
1. What is the paper about?
This paper studies whether computer programs written by LLMs for GPUs are really correct.
GPUs are powerful chips used for AI. An AI program can ask an LLM to write special GPU code called a kernel. Many benchmarks say that these generated kernels are correct because they produce results close to a trusted program on a few test inputs.
The paper argues that this test is often too weak. A kernel might pass the test but still:
- Fail when the input size changes
- Give different answers each time it runs
- Handle
NaNor infinity incorrectly - Use less accurate calculations than required
- Crash or exceed the GPU’s hardware limits
To address this, the authors create a much stricter testing system called a contract-grade verifier. They also use it to check a new GPU program for training certain AI sequence models on NVIDIA’s Blackwell GPUs.
2. What questions does the research ask?
The paper mainly asks two questions:
- How many LLM-generated GPU kernels that were reported as “correct” are actually broken under more careful testing?
- Can the same strict verifier correctly approve a new, hand-written GPU kernel created by the researchers themselves?
The second question is important because a verifier should not simply reject everyone else’s code. It should also approve code that has been carefully checked and is genuinely correct.
The researchers also ask whether they can build a faster and more suitable training backward pass for a family of AI models called gated linear recurrence models, including models related to Mamba and Gated DeltaNet.
3. How did the researchers do the study?
Testing GPU kernels with twelve “contracts”
The researchers designed twelve checks, or contracts. A contract is like a rule that a correct program promises to follow.
Instead of checking one ordinary example, the verifier tests many different situations. For example, it checks whether a kernel:
- Works with normal, very large, very small, and unusual numbers
- Works with different input shapes and sequence lengths
- Produces correct gradients, which are needed for training
- Gives the same answer every time
- Handles
NaNand infinity in the same way as the reference program - Works with several number formats, such as
fp32,fp16, andbf16 - Keeps enough precision when adding many numbers
- Keeps data on the correct device
- Fits within hardware limits, such as available GPU memory
Some checks are tolerance-free. This means there is no argument about whether an answer is “close enough.” For example, if the correct answer is NaN but the kernel returns an ordinary number, the kernel is simply wrong.
Other checks use carefully calculated error limits. These limits are based on how much rounding error computers normally create, rather than being chosen randomly.
Testing the verifier itself
Before using the verifier on other people’s kernels, the researchers tested it on:
- Honest reference programs
- Nineteen deliberately broken kernels
The broken kernels included programs that:
- Returned the input instead of calculating the answer
- Worked only for one input shape
- Used low-precision arithmetic
- Produced different answers on different runs
- Changed infinity into a normal number
- Moved results to the wrong device
The verifier rejected all nineteen broken kernels and accepted the honest program.
Auditing thousands of generated kernels
The researchers then tested 2,638 GPU kernels from a public collection. These kernels had already been marked as correct by the original system’s normal testing method.
They compared the results of the usual test with the results of their stricter verifier. They also:
- Ran the tests on another software setup
- Compared their checker with the original benchmark’s own checking code
- Manually examined some disagreements
- Tested several kernels written by the researchers themselves
Building a new Blackwell GPU backward kernel
The second part of the paper describes a new GPU kernel for training models in the gated-linear-recurrence family.
A forward pass calculates a model’s output. A backward pass works backward through the calculation to determine how the model’s parameters should change during learning. This is similar to checking which steps in a recipe contributed most to a bad result.
The new backward kernel is designed for NVIDIA’s Blackwell GPUs. It uses a special tensor-processing unit called tcgen05 and a small, fast memory area called Tensor Memory.
The researchers tested it against a slow, highly accurate fp64 reference program. They also trained five related models using the new kernel.
4. What did the researchers find?
Many supposedly correct kernels were not fully correct
Of the 2,638 kernels that had passed the usual benchmark:
- 62.1% broke at least one of the verifier’s rules.
- 39.5%, or 1,043 kernels, failed a tolerance-free check. These kernels were clearly wrong in ways that cannot be explained by ordinary rounding.
- The normal benchmark accepted 1,487 kernels that the stricter verifier rejected.
- Only 14 kernels were rejected by the normal test but accepted by the new verifier.
This one-sided difference suggests that the normal test is missing many broken kernels rather than the new verifier simply being unreasonably strict.
The most common serious problem was incorrect handling of special numbers. Some kernels returned a normal number when the correct answer was NaN or infinity. This is dangerous because it can hide an error during AI training instead of exposing it.
Other common problems included:
- Working only at the tested input size
- Using too little numerical precision
- Producing different results on repeated runs
- Making incorrect assumptions about the order in which numbers are added
The verifier passed additional checks of its fairness
The authors used several tests to show that the verifier was not designed merely to reject outside code:
- It rejected all nineteen deliberately broken test kernels.
- It accepted seven independently checked kernels written by the researchers.
- It agreed with the original benchmark’s checking code 98.5% of the time in a comparison of 1,030 cases.
- In a manual review of 31 disputed cases, the researchers admitted that seven should be excluded from the strict results.
These tests do not prove the verifier is perfect, but they provide evidence that its results are not caused simply by choosing unfair thresholds.
The new Blackwell backward kernel worked, but was not yet fast
The new native Blackwell kernel:
- Worked for five related sequence-model families
- Matched a high-precision reference closely
- Had a worst reported relative error of about 0.33% in its main tested configurations
- Produced identical results when run repeatedly
- Successfully trained models without numerical explosions in the tested settings
- Passed the verifier’s applicable checks
The researchers also solved a Blackwell hardware problem involving Tensor Memory. The GPU allows only a certain amount of this memory, and earlier designs requested too much or released it incorrectly. Their improved design reserves the memory once, manages it carefully, and releases it once at the end.
However, the new kernel was slower than the existing Triton implementation—about 8 to 78 times slower in the tested sequence lengths. The authors openly state that their main achievement is correctness and native Blackwell support, not speed.
The tests also covered only a narrow range of input sizes and mainly one type of Blackwell GPU. One larger configuration slightly exceeded the paper’s chosen error limit.
5. Why are these results important?
The main lesson is that saying a generated GPU kernel is “correct” depends heavily on how it is tested.
A simple test using a few random examples is like checking a bridge by putting one bicycle on it. The bridge might survive that test but still fail under heavy traffic, strong wind, or an unusual load.
The paper suggests that GPU-kernel benchmarks should include stronger rules, especially checks for:
- Correct behavior at many input shapes
- Proper handling of
NaNand infinity - Repeatable, deterministic results
- Correct numerical precision
- Hardware resource limits
These checks could prevent researchers from reporting impressive results based on kernels that only work in the narrow situation used by the benchmark.
The new Blackwell backward kernel may also help future developers build training systems for Mamba-like models without relying on slower fallback code. However, it needs more optimization and testing before it can be considered a practical replacement for faster existing implementations.
Simple conclusion
The paper makes two connected points:
- Many AI-generated GPU programs that pass ordinary tests still contain hidden bugs.
- More careful, rule-based testing can find those bugs while still approving programs that are genuinely correct.
The research therefore encourages AI and GPU researchers to use stronger testing standards. Better tests could make reported improvements more trustworthy and reduce the chance that faulty GPU code silently damages AI training or produces unreliable results.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
- Generalizability beyond the audited corpus remains unresolved: the headline rates are dominated by the Dr. Kernel/KernelGYM corpus, whose operator mix, generation process, acceptance criteria, and model distributions may not represent KernelBench, TritonBench, CUDA-L1, or future kernel-generation systems.
- The audit is restricted to kernels already accepted by one system’s harness: it does not establish how the verifier performs on rejected candidates, partially correct kernels, or kernels generated by other LLMs and search procedures.
- The corpus-level failure rate may be affected by selection and survivorship bias: kernels that failed to compile or were excluded as toolchain artifacts were removed, and the analysis does not quantify whether these exclusions systematically differ from the accepted kernels.
- Two verifier gates were not meaningfully exercised in the main audit: gradient correctness (
CMP-02) and hardware-resource compliance (RES-02) were unavailable or inactive for the forward-only corpus, leaving important failure modes unmeasured at scale. - The effective audit coverage is narrower than the nominal twelve-gate battery: only seven gates are treated as load-bearing, while
ORD-03,PRC-02, andRES-01contribute limited or indirect evidence; the extent to which this reduced set captures real-world defects is not established. - The verifier’s reference implementations are not independently validated across the full operator corpus: the results assume that the slow high-precision reference loops correctly implement every tested PyTorch operator, edge case, dtype rule, and non-finite-value convention.
- Reference disagreement is handled asymmetrically in favor of candidates, but its impact is not fully quantified: inputs that the reference cannot execute are marked not applicable, and the paper does not report how many potentially revealing cases are lost through this rule.
- The representativeness of the adversarial test inputs is uncertain: fixed seeds and hand-designed cases such as zeros, denormals, long sequences, and extreme magnitudes may miss defects triggered by other distributions, correlations, sparsity patterns, or application-specific inputs.
- Shape coverage remains finite and manually specified: the verifier tests selected batch, length, and width variations, but does not determine whether kernels generalize to arbitrary legal dimensions, irregular tilings, very large tensors, zero-sized dimensions, or dynamically changing shapes.
- The derived tolerance model is not theoretically complete for all operators: the reported accumulation bound and other scale-aware tolerances may not adequately model cancellation, non-associative matrix operations, TF32 behavior, fused operations, transcendental functions, or highly ill-conditioned computations.
- Threshold calibration is based on a small positive-control set: six Triton kernels and one native kernel may not span the numerical and architectural diversity needed to validate tolerances for all operator classes, dtypes, and GPU execution patterns.
- The thin safety margin for
ORD-03leaves residual classification risk: its reported separation from the real-error onset could lead to false positives or false negatives for kernels whose numerical behavior falls between the calibration examples. - The verifier’s behavior across hardware generations is not established: most conclusions are obtained on a single B200 configuration, so portability to H100, A100, consumer Blackwell GPUs, AMD accelerators, or future NVIDIA architectures remains unknown.
- Toolchain sensitivity is only partially tested: the second-stack audit uses one additional PyTorch/CUDA environment, but the effects of different CUDA, Triton, compiler, driver, optimization, and math-mode versions are not systematically characterized.
- The audit does not fully address adversarial kernels designed to evade the verifier: the nineteen broken kernels test known defects, but generated kernels could detect test patterns, specialize to fixed seeds or shapes, or exploit sandbox and reference-execution assumptions.
- Runtime and operational costs of contract-grade verification are not evaluated: the paper does not quantify verification time, GPU-hours, memory overhead, or scalability relative to standard benchmark harnesses, particularly for large training kernels and gradient checks.
- The relationship between contract violations and practical model-level harm remains unclear: the study identifies kernel defects but does not measure how often they alter loss curves, convergence, downstream accuracy, stability, or deployed-system outputs.
- The causal source of the observed defects is unresolved: the paper does not distinguish whether failures arise primarily from LLM code generation, prompt design, compiler behavior, benchmark incentives, insufficient testing, or human post-processing.
- The proposed minimal contract set is not empirically optimized: the claim that a small set of tolerance-free contracts would “close most of the gap” is plausible but not supported by an ablation quantifying the marginal detection value and cost of each gate.
- False-negative rates of the verifier are unknown: positive controls and deliberately broken examples demonstrate that the verifier catches certain defects, but there is no exhaustive or statistically grounded estimate of how many incorrect kernels can still pass.
- False-positive rates are also incompletely established: passing seven known-good kernels does not demonstrate correctness for mathematically valid but numerically unusual implementations, alternative reduction orders, approximate algorithms, or intentionally nondeterministic-but-acceptable kernels.
- The handling of nondeterminism may be overly strict for some GPU workloads: requiring byte-for-byte equality across five runs does not examine whether bounded nondeterminism could be numerically acceptable or expected under a given operator contract.
- The treatment of non-finite values depends on reference semantics that may not be universally appropriate: exact NaN positions and signs are enforced, although different mathematically equivalent implementations or hardware modes may legitimately produce different NaN payloads or propagation patterns.
- The native GDN backward is validated only on a narrow shape envelope: the tcgen05 kernels are tested at , chunk length 64, and , leaving other model widths, chunk sizes, sequence lengths, batch sizes, head configurations, and padding patterns unverified.
- Native-kernel correctness beyond the B200 is unestablished: no evidence is provided for correctness on other Blackwell products, future revisions, or different TMEM and scheduling configurations.
- The native backward is not fully native: normalization gradients, packing, masks, and other glue remain in PyTorch, so the reported implementation does not yet establish the performance or resource properties of an end-to-end native training path.
- The numerical accuracy envelope of the native backward is incomplete: one assembled pipeline arm exceeds the stated bound at , and the paper does not determine whether this reflects benign accumulation, an input-dependent instability, or a defect that could become significant in longer or larger training runs.
- Long-horizon numerical stability is not demonstrated: training experiments use limited sequence lengths and step counts, so stability under substantially longer sequences, larger states, recurrent distribution shifts, and prolonged optimization remains open.
- Training validation is too limited to establish model-level equivalence: the five family members are trained through the backward, but the paper does not report systematic comparisons of convergence, final quality, gradient statistics, or checkpoint equivalence against established implementations.
- The claimed family-wide generality requires broader independent validation: reductions to LA, GLA, SSD, KDA, and GDN are tested, but variants with different parameterizations, normalization conventions, gating ranges, or implementation choices are not evaluated.
- Performance conclusions are preliminary: the native backward is reported as substantially slower than the Triton baseline, but no comprehensive profiling or optimization study isolates the costs of sequential scans, TMEM management, torch glue, launch overhead, memory movement, and shape specialization.
- The impact of future compiler changes is unknown: the implementation relies on pinned tcgen05, TMA, TMEM, and Triton behavior; compatibility with post-PR #9093 toolchains and whether the native approach remains advantageous after compiler fixes are not measured.
- The comparison with alternative native implementations is incomplete: the paper does not provide a consistent benchmark against cuLA, FlashKDA, TileLang, vendor libraries, or fully fused custom implementations across identical shapes and precision settings.
- The novelty claim is limited by the scope of the literature search: “first native” claims depend on the completeness and recency of the survey, while proprietary, unpublished, or concurrently developed Blackwell implementations may not be covered.
- The proposed verifier standard lacks evidence of adoption feasibility: the paper does not evaluate how benchmark maintainers, kernel-generation researchers, or production users would integrate the contracts into existing evaluation pipelines or how stricter testing would affect reported throughput and research iteration speed.
- The interaction between correctness verification and performance optimization is unexplored: stricter contracts may reject optimizations involving approximate math, reduced precision, stochastic algorithms, or hardware-specific behavior; the acceptable trade-offs and contract definitions for such cases remain to be specified.
- The paper does not establish whether contract-aware generation improves kernel quality: it audits existing outputs but does not test whether providing the verifier’s feedback during prompting, reinforcement learning, search, or fine-tuning reduces defect rates or improves performance.
Practical Applications
Immediate Applications
The paper’s findings support several uses that can be deployed with existing GPU software, testing infrastructure, and Blackwell hardware, although some require adapting the verifier to a project’s operators and reference implementations.
- Production validation for generated CUDA and Triton kernels — software/AI infrastructure. Integrate the twelve-gate verifier into CI/CD pipelines for LLM-generated, compiler-generated, or manually optimized GPU kernels. A kernel would be promoted only after passing tests for adversarial inputs, shape variation, determinism, non-finite-value behavior, precision, device placement, and hardware-resource limits. This is particularly valuable for inference and training libraries where a numerically silent error can corrupt model outputs or checkpoints. Dependencies: a trustworthy high-precision reference implementation, reproducible execution environments, hardware access, and operator-specific handling for gates such as gradient validation.
- Replacement for single-shape
allclosebenchmark checks — benchmarking and academia. GPU-kernel benchmarks such as KernelBench-style evaluations can add tolerance-free gates for NaN/Infinity propagation, repeatability, shape polymorphism, and aliasing, alongside derived floating-point tolerances. This would make reported correctness and speedup results more reliable and reduce incentives to optimize only for a narrow test case. Dependencies: agreement on benchmark contracts, additional runtime per test, and clear treatment of operators whose valid behavior is intentionally shape- or dtype-specific. - Pre-deployment auditing of existing GPU-kernel repositories — software engineering. Organizations can re-audit kernels that already passed internal tests, especially reductions, scans, softmaxes, attention operators, normalization layers, and convolutions. The paper indicates that common defects include silently replacing NaNs or infinities with finite values, failing on untested shapes, using insufficient accumulation precision, and producing nondeterministic outputs. Potential workflow: run the verifier on every kernel version, classify failures by gate, require remediation or an explicit exception, and retain the verdict as part of the release artifact. Dependencies: source-level access or a callable kernel interface and a reference that defines expected exceptional-value behavior.
- Quality control for LLM-based code-generation systems — AI coding tools.
Kernel-generation systems can use verifier failures as training or reinforcement signals. For example, a failed
CMP-03gate can prompt shape-generalization improvements, whileEXC-01orPRC-02failures can be used to penalize incorrect exceptional-value handling or low-precision accumulation. This can prevent systems from reporting inflated “correctness” rates based on weak harnesses. Dependencies: reproducible compilation, sandboxing against timing or buffer-reuse exploits, sufficient evaluation diversity, and mechanisms to distinguish code defects from toolchain failures. - Debugging and regression detection for numerical GPU software — engineering and research laboratories. The verifier can function as a diagnostic suite rather than merely a pass/fail referee. Gate-specific failures identify whether a regression concerns precision, reduction order, determinism, shape handling, non-finite propagation, device placement, or resource usage. This is useful when upgrading PyTorch, Triton, CUDA, compiler versions, or GPU architectures. Dependencies: stable seeds, pinned software versions, and separate reporting of numerical failures, compilation failures, and hardware-resource failures.
- Safety checks for training pipelines in healthcare and other high-consequence domains — healthcare/finance/industrial AI.
In applications such as medical imaging, clinical prediction, fraud detection, or industrial monitoring, a kernel that converts a NaN into an ordinary value may hide an unstable model or corrupted input. Adding
EXC-01, determinism, precision, and shape checks to model-release procedures can make failures observable instead of silently propagating through training or inference. Dependencies: domain-specific validation, independent model-level testing, and the recognition that kernel verification does not establish clinical, financial, or operational correctness by itself. - Blackwell-specific resource validation for custom kernels — GPU systems and cloud operations.
The
RES-02concept can be used to detect register, shared-memory, and TMEM-budget violations before deployment. For Blackwell kernels usingtcgen05, developers can explicitly check allocation and release lifecycles, accumulator offsets, and the 512-column TMEM constraint. This can prevent illegal code generation, deadlocks, compilation failures, or unintended fallback to slower implementations. Dependencies: compiler support for exposing resource metadata, accurate architecture-specific limits, and testing on the target Blackwell SKU and software stack. - Native Blackwell training acceleration for gated-linear-recurrence models — machine learning systems. The released native backward provides a starting point for training LA, GLA, SSD/Mamba-2, KDA, and GDN-family models on B200/GB200-class systems. Teams can use the implementation where avoiding a Triton fallback or validating a native training path is more important than immediate speed. Dependencies: the reported implementation is validated only on a narrow envelope—principally , chunk length 64, and —and is slower than the referenced Triton implementation. Integration therefore requires independent performance and correctness testing.
- Reproducible research artifacts and teaching materials — academia. The verifier, deliberately broken kernels, calibration procedures, and oracle chain can be used in courses or laboratory exercises on floating-point arithmetic, GPU programming, compiler validation, numerical reproducibility, and research-methodology auditing. Students can observe why a kernel may pass a conventional test while violating a stronger contract. Dependencies: access to appropriate GPUs or emulation alternatives, and careful explanation that the audited percentages are corpus-specific rather than universal.
Long-Term Applications
The following applications require broader validation, standardization, performance optimization, or further research before they can become dependable general-purpose solutions.
- An industry-wide contract standard for GPU-kernel correctness — software ecosystem and benchmarking policy. The twelve gates could evolve into a common specification adopted by kernel benchmarks, GPU compiler projects, ML frameworks, and model-card or software-release reporting systems. Benchmark results could report separate scores for value correctness, exceptional-value behavior, determinism, precision, shape coverage, and hardware feasibility rather than a single correctness percentage. Dependencies: consensus on contract semantics, portable implementations across CUDA/Triton and other GPU programming systems, and solutions for operators whose behavior is nondeterministic by design.
- Certified or contract-aware LLM kernel generation — AI systems research. Future code-generation systems could generate both a kernel and a machine-readable contract describing supported shapes, dtypes, accumulation modes, exceptional-value behavior, and resource requirements. Generation could be coupled with automatic repair: the verifier identifies a failed gate, the model modifies the kernel, and the system reruns adversarial tests until it obtains a certificate. Dependencies: robust reference synthesis, resistance to verifier overfitting, sufficiently broad hidden tests, and formal or semi-formal guarantees that go beyond empirical test coverage.
- Automated kernel repair and optimization guided by failure classes — compiler technology. Gate-specific failures can become inputs to specialized repair passes. Examples include inserting fp32 accumulation, adding shape guards, preserving NaN/Infinity masks, enforcing deterministic reductions, or restructuring TMEM allocation. Over time, these diagnostics could support compiler transformations that optimize kernels while preserving explicit contracts. Dependencies: reliable mapping from observed failures to source-level causes, preservation of performance, and validation across architectures rather than only on B200 hardware.
- Formal or semi-formal verification of GPU numerical contracts — programming languages and formal methods. The tolerance-free gates could be combined with static analysis, symbolic execution, abstract interpretation, or hardware-aware proofs. Static methods might verify device placement, buffer aliasing, resource budgets, and some shape constraints, while dynamic tests handle floating-point error and exceptional-value behavior. Dependencies: tractable models of GPU memory ordering, asynchronous execution, compiler transformations, floating-point modes, and tensor-core semantics.
- A certified native Blackwell kernel library for recurrent sequence models — AI infrastructure. The GDN backward could be expanded into a production library covering broader dimensions, sequence lengths, batch sizes, mixed-precision modes, and multiple Blackwell configurations. Further fusion of the remaining Torch glue and optimization of the reverse-state scan could make the native path competitive with or superior to Triton fallbacks. Dependencies: wider shape validation, post-compiler-fix support, performance work on the sequential scan and fp32 glue, and resolution of the reported accuracy exception in one assembled pipeline arm.
- Architecture-portable resource contracts for GPUs — hardware/software co-design. The TMEM example suggests a broader interface in which kernels declare resource budgets and allocation lifecycles that compilers and deployment systems can validate for each GPU generation. Similar mechanisms could cover shared memory, registers, tensor-core fragments, asynchronous barriers, and accelerator-specific scratch spaces. Dependencies: vendor cooperation or stable compiler metadata, architecture-specific contract definitions, and tooling that can distinguish legal specialization from accidental resource overuse.
- Reliability certification for high-stakes GPU workloads — healthcare, autonomous systems, finance, and energy. A mature version of the verifier could become one layer in certification workflows for medical-model training, autonomous-robot perception, financial risk engines, power-grid optimization, and other systems where silent numerical corruption is unacceptable. Kernel-level certificates could be combined with dataset, model, and end-to-end safety evidence. Dependencies: regulatory acceptance, traceable software supply chains, coverage of the complete deployment stack, and recognition that kernel contracts are necessary but insufficient for system-level safety.
- Cloud and cluster admission control based on verified kernels — cloud computing and operations. GPU clusters could require kernels to pass contract checks before allowing them into shared production environments. Scheduling systems might use verified resource metadata to prevent TMEM, register, or memory oversubscription and to select kernels compatible with a particular GPU generation. Dependencies: low-overhead verification, trusted containers, reliable metadata extraction, and mechanisms for handling dynamically compiled kernels.
- Everyday-facing benefits through more reliable AI software — daily life. Users would not interact with the verifier directly, but stronger kernel validation could reduce silent failures in consumer applications such as speech assistants, translation, recommendation systems, image processing, navigation, and generative AI. More reliable propagation of invalid numerical states could also make application failures visible and diagnosable instead of producing plausible but incorrect outputs. Dependencies: adoption by framework and model providers, end-to-end monitoring, and safeguards against treating kernel-level test success as a guarantee of overall application accuracy.
Glossary
- Allclose: Approximate-equality test that checks whether two numerical arrays differ within specified absolute and relative tolerances. “accept the kernel if its output is close, in the allclose sense, to a reference”
- Autograd: Automatic differentiation system that constructs computation graphs and computes gradients. “autograd versus finite difference”
- Bfloat16 (bf16): 16-bit floating-point format with a larger exponent range than fp16, commonly used in machine learning. “correct in fp32, fp16, and bf16”
- Blackwell: NVIDIA GPU architecture generation that includes the B200 and specialized fifth-generation tensor cores. “NVIDIA's Blackwell generation (the B200, architecture sm_100)”
- Chunking: Splitting a long sequence or computation into smaller blocks to enable parallel processing and manageable state transfer. “The standard resolution is chunking: split the sequence into chunks of 64 steps”
- Contingency table: Table that cross-classifies observations according to the outcomes of two categorical tests. “the contingency table of Figure~\ref{fig:diff}”
- CUDA: NVIDIA’s parallel-computing platform and programming model for executing code on GPUs. “a second corpus of native CUDA kernels”
- CuTe: NVIDIA software-library framework for describing and optimizing tiled tensor computations. “cuLA has a KDA backward that is a hybrid (one native CuTe kernel for the WY stage”
- Delta rule: State-update mechanism that writes the difference between a target value and the state’s current prediction. “the delta rule (the model subtracts what already predicts for a key before writing”
- Denormal / subnormal: Floating-point value whose magnitude is smaller than the smallest normally represented value and which uses a reduced-precision representation. “zeros, , , denormals, long ”
- Differential testing: Testing method that compares the outputs or verdicts of two implementations on the same inputs. “The differential of Section~\ref{sec:diff} therefore rests on their code.”
- Double-precision oracle: High-precision reference implementation used as an authoritative source for checking numerical results. “we establish this kernel's correctness independently, against a double-precision oracle”
- Eager execution: Execution mode in which operations are performed immediately rather than represented only symbolically or deferred. “Fresh-input graph replay is bit-exact against eager execution.”
- Exponent overflow: Numerical condition in which an exponential operation exceeds the largest representable floating-point value. “a masked-exp2 fix corrected an exponent overflow that had produced a NaN”
- Finite difference: Numerical approximation of a derivative obtained by evaluating a function at nearby points. “autograd versus finite difference”
- Floating-point error model: Mathematical model used to estimate numerical error introduced by finite-precision arithmetic. “the rest use tolerances derived from a floating-point error model rather than chosen by hand”
- Flush-to-zero: Hardware or software behavior that replaces very small subnormal values with zero. “flush-to-zero handling of subnormals matches the reference”
- Fp16: 16-bit IEEE-style floating-point format with reduced precision and range relative to fp32. “accumulate in fp16 where the reference keeps an fp32 running total”
- Fp32: 32-bit single-precision floating-point format. “The reference for every operator is a plain high-precision loop that is defined to be ground truth”
- Fp64: 64-bit double-precision floating-point format used for high-accuracy numerical computation. “The full assembled backward against an independent fp64 oracle”
- Fused kernel: GPU kernel that combines multiple computational operations into one execution to reduce memory traffic and launch overhead. “a channel-wise fusion campaign cut the captured backward ”
- Gated DeltaNet (GDN): Gated linear-recurrence architecture that combines decay, erase, write, and delta-rule state updates. “the models we target use a matrix state of shape and the stronger gated DeltaNet (GDN) update”
- Gated linear attention (GLA): Linear-attention model that applies gates to control how recurrent state information is retained or modified. “gated linear attention (GLA)”
- Graph replay: Re-execution of a previously captured computation graph, often to reduce launch overhead and test execution consistency. “Fresh-input graph replay is bit-exact against eager execution.”
- GRPO: Group Relative Policy Optimization, a reinforcement-learning method for optimizing generative models using relative rewards within sampled groups. “a from-scratch GRPO system that autotunes them”
- Inter-chunk state scan: Sequential propagation of recurrent state gradients or values between independently processed sequence chunks. “the reverse inter-chunk state scan”
- Kernel: GPU-executable function that performs a parallel computational operation. “A kernel can pass that test and still be silently wrong.”
- KernelBench: Benchmark and evaluation framework for generated GPU kernels. “The verifier is the spine of the paper, and we aim it in two directions.”
- KernelGYM: Corpus or system containing machine-generated GPU-kernel programs and their training trajectories. “We ran the verifier over Dr.\ Kernel / KernelGYM”
- Lifecycle error: Incorrect allocation, use, or release sequence for a hardware-managed resource. “The root cause, established by reading NVIDIA's own mamba2_ssd.py in the same pinned toolchain, was a lifecycle error”
- Linear recurrence: Repeated state-update equation in which the current state depends on the previous state and the current input. “one gated linear recurrence”
- Masked exponential: Exponential computation selectively applied only to valid elements, often to prevent invalid or dangerous numerical operations. “a masked-exp2 fix corrected an exponent overflow”
- Mamba: Family of sequence models based on selective state-space recurrences. “Mamba~\cite{gu2023mamba}”
- Matrix multiply-accumulate (MMA): Hardware operation that multiplies matrices or tiles and accumulates the result. “NVIDIA's kernel instead runs four tcgen05 MMAs”
- Mixed precision: Computation that uses different numerical precisions for different operations or data structures. “the mixed-precision and shape conventions are fixed in advance”
- Non-finite value: Floating-point value that is NaN or positive or negative infinity. “the modal defect is a kernel silently replacing a NaN or infinity with an ordinary number”
- Nondeterminism: Variation in computational results across repeated executions with identical inputs and settings. “byte-for-byte identical across five repeats”
- Numerical oracle: Trusted implementation used to establish expected numerical results for another implementation. “a token-serial fp64 oracle”
- Numerical stability: Resistance of an algorithm’s results to excessive error caused by rounding, overflow, underflow, or perturbations. “the WY / triangular-inverse VJP. Inside each chunk the delta rule requires a small triangular solve”
- Rank-one update: Matrix modification formed from the outer product of two vectors, producing a rank-one matrix. “a rank-one write”
- Reduction: Operation that combines many values into one or more aggregate values, such as a sum. “reordered summation stays within a derived rounding bound”
- Relative error: Difference between an approximation and a reference value normalized by the magnitude of the reference. “worst relative error $\mathbf{3.29\times10^{-3}$”
- Recurrent state: Persistent vector or matrix representation carrying information from earlier sequence positions. “Sub-quadratic sequence models replace attention's quadratic cost with a fixed-size recurrent state.”
- Reverse-state scan: Backward-time computation that propagates gradients through recurrent states in reverse sequence order. “the native reverse-state scan and WY-VJP for the GDN family”
- Selective scan: State-space computation whose transition or update parameters depend on the current input. “A Mamba-style selective scan keeps a vector state ”
- Shape polymorphism: Ability of a kernel or program to operate correctly across varying tensor dimensions. “a small set of tolerance-free contracts (non-finite propagation, determinism, shape polymorphism)”
- Softmax: Function that converts a vector of scores into normalized exponential weights. “softmax correct at native shape but wrong by $0.30$ at four times the sequence length”
- State-space model (SSM): Sequence model that represents temporal information with a latent state updated over successive inputs. “all instantiate one gated linear recurrence”
- Tensor core: Specialized GPU hardware unit for accelerating matrix operations, especially mixed-precision operations. “adds a fifth-generation tensor core, tcgen05”
- Tensor Memory (TMEM): Specialized on-chip memory space on Blackwell GPUs for tensor-core operands and accumulators. “its matrix-multiply operands reside in a new scarce on-chip space, Tensor Memory (TMEM)”
- Tensor-memory budget: Hardware-imposed limit on the amount of Tensor Memory that a warpgroup may allocate. “governed by a hard 512-column budget per warpgroup”
- Triton: GPU programming language and compiler designed for writing high-performance tensor kernels. “the reverse-state stage open implementations still run on a fallback”
- Triangular solve: Solution of a linear system whose coefficient matrix is triangular, typically more efficiently than a general matrix inversion. “the delta rule requires a small triangular solve”
- Tolerance-free gate: Verification condition based on exact structural, bitwise, or mask equality rather than a numerical tolerance. “Some gates need no tolerance at all and compare by exact mask or byte equality”
- Tolerance calibration: Process of selecting or validating numerical acceptance thresholds by comparing honest numerical noise with known errors. “Threshold calibration. This is the graded version of the positive control.”
- Warpgroup: Group of GPU threads coordinated for specialized collective operations on modern NVIDIA architectures. “governed by a hard 512-column budget per warpgroup”
- WY representation: Compact representation used in blocked transformations and triangular computations, here reused for the backward pass. “The forward already computed , so the backward reuses it as two triangular matrix multiplies”
- Vector-Jacobian product (VJP): Product of a vector with a function’s Jacobian, commonly used to compute reverse-mode automatic-differentiation gradients. “its vector-Jacobian product is the numerically nastiest piece”


