Papers
Topics
Authors
Recent
Search
2000 character limit reached

A Contract-Grade Verifier for LLM-Generated GPU Kernels, and a Native Blackwell Backward for the Gated-Linear-Recurrence Family

Published 13 Aug 2026 in cs.LG, cs.AR, and cs.DC | (2608.12700v1)

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.

Authors (2)

Summary

  • The paper introduces a twelve-gate, contract-grade verifier that tests value accuracy, shapes, precision, exceptional values, determinism, aliasing, and device behavior against FP64 and adversarial references.
  • The audit finds that 62.1% of 2,638 previously accepted machine-generated kernels violate at least one contract, while 39.5% fail tolerance-free checks that ordinary allclose tests cannot detect.
  • The paper presents a native Blackwell tcgen05 backward for five gated-linear-recurrence families, achieving roughly 3.3×10⁻³ worst relative error and deterministic training behavior, but remaining slower than mature Triton implementations.

Contract-Grade Verification and Native Blackwell Backpropagation for Gated Linear Recurrences

"A Contract-Grade Verifier for LLM-Generated GPU Kernels, and a Native Blackwell Backward for the Gated-Linear-Recurrence Family" (2608.12700) addresses two closely related systems problems: the inadequacy of prevailing correctness tests for LLM-generated GPU kernels and the absence of a fully native Blackwell training backward for the gated-linear-recurrence family. The paper’s central methodological claim is that kernel-generation benchmarks substantially overstate correctness when they rely on a single approximate-equality test at one fixed shape. Its systems contribution is a hand-written tcgen05 backward for GDN and several related recurrence models, including the reverse-state stage that existing implementations leave on a Triton fallback.

The two contributions are linked through a common verification standard. The verifier is used first as an external auditing instrument against 2,638 kernels already accepted by a public generation system, and then as an internal acceptance test for a kernel whose correctness is independently established against an FP64 oracle. This dual use is intended to address the principal threat to validity in an audit of this kind: that a stricter checker merely rejects foreign implementations by construction.

The Correctness Problem in Generated GPU Kernels

Existing kernel-generation benchmarks typically evaluate a candidate by executing it on several random inputs at one fixed shape and applying an allclose criterion. In the KernelBench setting considered by the paper, the common configuration uses absolute and relative tolerances of 10210^{-2}. Such a test is inexpensive, but it probes only a narrow portion of a kernel’s behavioral contract.

The paper identifies several failure modes that can survive this procedure:

  • A kernel can return a finite value where the reference produces a NaN or infinity.
  • It can be nondeterministic across repeated executions.
  • It can work at the benchmarked shape while failing under a different sequence length, batch size, or feature dimension.
  • It can accumulate in FP16 even when the reference maintains an FP32 accumulator.
  • It can mishandle subnormals, device placement, reduction ordering, or aliasing.
  • It can produce numerically plausible outputs while implementing the wrong gradient.

These are not merely disagreements over an appropriate numerical tolerance. Several are categorical violations of the operator’s semantics. In particular, replacing a non-finite reference value with an ordinary finite number can convert an observable training failure into silent state corruption.

The paper therefore distinguishes a conservative, tolerance-free correctness floor from a broader rate that includes tolerance-dependent violations. This distinction is important: the former cannot be dismissed by arguing that the verifier’s numerical thresholds are overly strict.

The Twelve-Gate Verifier

The verifier operationalizes the Kernel Contracts taxonomy (Veit, 23 Apr 2026) as twelve adversarial gates. They cover value correctness, gradients, shape polymorphism, reduction behavior, precision regimes, exceptional values, device residency, determinism, aliasing, and hardware resource constraints.

Seven gates are treated as load-bearing for the forward-only audit:

  • CMP-01: value correctness over random and adversarial inputs;
  • CMP-03: correctness across shapes;
  • ORD-01: reduction-order error within a derived bound;
  • ORD-02: deterministic, non-aliased output;
  • EXC-01: exact NaN and infinity propagation;
  • EXC-02: subnormal and flush-to-zero behavior;
  • PRC-01: correctness across FP32, FP16, and BF16.

The remaining gates are either unavailable or less informative for portions of the audited corpus. Gradient correctness cannot be tested when the candidate is forward-only, and resource metadata is unavailable for some generated kernels. The verifier nonetheless exercises these dimensions on the authors’ own kernels and on deliberately constructed controls.

Its numerical policy is designed to avoid arbitrary threshold selection. Tolerances are derived from floating-point error models and scale with the relevant operation. For example, reduction-order error is bounded approximately according to the expected N\sqrt{N} accumulation behavior rather than by an empirically convenient constant. Exact-mask comparisons are used for non-finite values, and repeated executions are compared byte-for-byte for determinism. Inputs are generated from fixed random seeds, ensuring that verdicts are reproducible and not dependent on stochastic sampling luck.

The repository also contains nineteen deliberately defective kernels implementing behaviors such as input return, cached outputs, FP16 accumulation, nondeterminism, shape specialization, non-finite suppression, and device migration. The verifier rejects all nineteen while accepting the honest reference operator. This two-sided test establishes that the battery is sensitive to targeted violations without rejecting a known-correct implementation.

The Audit of Accepted Machine-Generated Kernels

The external audit targets the Dr. Kernel/KernelGYM corpus (Liu et al., 5 Feb 2026), specifically an accepted subset of Triton kernels evaluated on a B200 using PyTorch 2.12 and Triton 3.7. Of 3,134 kernels in the selected operator classes, 2,638 had already passed the source system’s correctness predicate and had recorded positive speedups.

The verifier reports two headline rates:

  • 62.1% of the accepted kernels violate at least one contract.
  • 39.5%, or 1,043 of 2,638 kernels, fail a tolerance-free gate.

The second figure is the paper’s principal conservative result. These 1,043 kernels exhibit failures that cannot be explained by a choice of approximate-equality threshold.

The modal defect is EXC-01: non-finite non-propagation. It affects 868 kernels, or 34.2% of applicable cases. Other substantial failure rates include value errors on varied inputs, shape rigidity, missing FP32 accumulation, reduction-order errors, precision-regime failures, subnormal mishandling, and nondeterminism.

Figure 1

Figure 1: The audit of 2,638 previously accepted kernels, showing the contract-violation rate, tolerance-free failure floor, and per-gate failure distribution.

The findings remain stable under several re-slicings. Including shape rejection in the tolerance-free subset raises the floor to 41.1%. Removing the matrix-multiplication class, where TF32-related tolerance arguments might be most relevant, leaves a 61.9% violation rate. Removing all contested channels still yields 60.6%.

The result is reproduced on a second software stack: a 300-kernel re-audit under PyTorch 2.11 and CUDA 12.8 produces a 68.6% violation rate. The paper does not treat this as a new headline estimate because the smaller sample overweights the reduction class, but it demonstrates that the result is not tied to a single software environment. A separate native-CUDA corpus shows a weaker residual defect rate of 20.2%, driven primarily by shape rigidity, subnormal handling, and nondeterminism rather than widespread value corruption.

Validation Against the Benchmark Harness

The authors provide four defenses against the claim that the verifier is simply excessively strict.

First, seven independently known-correct kernels pass all applicable gates, including six Mamba-3 Triton kernels and the native GDN backward. The native backward was not used to calibrate the thresholds, making it a particularly important positive control. The verifier did identify a real input-validation defect in one of the authors’ own kernels: a fused block inferred its channel dimension from the input without checking compatibility with the convolution weights. The defect was fixed rather than reclassified.

Second, the threshold-calibration sweep places the selected thresholds between the noise floor of correct kernels and the error magnitudes induced by deliberate perturbations. The margins are broad for most gates. The exception is the deliberately relaxed ORD-03 gate, whose upper margin is only 1.2×1.2\times; its coverage is therefore supported by the stronger CMP-01 and ORD-01 gates.

Figure 2

Figure 2: Calibration of thresholded gates, showing the separation between correct-kernel noise and deliberately injected errors.

Third, the authors compare their reimplementation with KernelBench’s own correctness code (Ouyang et al., 14 Feb 2025). The two implementations agree on 98.5% of 1,030 pairs. Of the fifteen disagreements, seven involve the verifier being stricter and eight are seed-sensitive borderline cases. This comparison supports the claim that the large discrepancy arises from the narrow behavioral scope of the benchmark test rather than from a faulty replica.

Fourth, a stratified hand audit of 31 disputed cases rejects the possibility that every disagreement represents a genuine correctness failure. Sixteen cases are genuinely broken under the tolerance-free core, eight are real but tolerance-dependent, and seven are excluded as out of scope. The willingness to remove seven disputed cases strengthens the methodological credibility of the audit.

The direct differential is strongly asymmetric. KernelBench’s paper-era check accepts 2,472 of 2,638 kernels, or 93.7%. Of the accepted set, 1,487 are rejected by the contract verifier, including 958 tolerance-free failures. In the reverse direction, only fourteen kernels are rejected by KernelBench but accepted by the verifier.

Figure 3

Figure 3: The directional disagreement between the standard benchmark test and the contract-grade verifier, dominated by kernels accepted externally but rejected under adversarial contracts.

This $1,487$-to-$14$ asymmetry is theoretically more informative than a simple difference in acceptance rates. If the verifier were merely a uniformly stricter allclose, disagreements would be expected in both directions. Instead, the result indicates a systematic blind spot in the standard test: it omits behavioral dimensions on which many kernels fail.

The Native Blackwell GDN Backward

The paper’s second contribution is a native Blackwell training backward for the gated-linear-recurrence family. The target recurrence maintains a matrix state StS_t and combines channel-wise decay, delta-rule correction, rank-one writes, and query-based reads. The general GDN formulation subsumes five model families:

The authors argue that approximately 80% of the parameterization is shared across these models. Consequently, a single differentiated implementation of the general recurrence can serve all five, provided each reduction is independently checked against its own reference rather than inferred solely from gate settings.

The backward is organized around two difficult stages. The first is a reverse inter-chunk state scan. Chunking makes the forward recurrence partially parallel, but the backward must propagate a state-gradient accumulator backward through the chunks, including the rank-one delta correction. This is the stage that existing open implementations leave in the Flash Linear Attention Triton fallback.

The second is the WY/triangular-inverse vector-Jacobian product. Within each chunk, the delta rule requires a triangular solve. The backward reuses the forward triangular factor and expresses the VJP through triangular matrix multiplications rather than recomputing an inverse.

The implementation uses Blackwell’s fifth-generation tensor cores through tcgen05, Tensor Memory, TMA movement, asynchronous pipelines, and a (128,64,128)(128,64,128) tile. The main hardware difficulty is the 512-column TMEM budget per warpgroup. The paper connects this constraint to issue #904 in the Mamba repository, where a compiler-generated kernel requests 544 columns and falls back to a path reported as 38.7 times slower on B200/GB200 hardware.

The authors reproduce the failure and attribute their own initial illegal-code and deadlock failures to incorrect TMEM lifecycle management. The successful implementation reserves TMEM once, uses fixed accumulator offsets, and releases the allocation once after all matrix multiplications. This allocation-once/relinquish-once discipline permits multiple tcgen05 MMAs within the kernel.

Numerical Verification and Training Behavior

The native backward is verified through a layered oracle chain:

  1. a token-serial FP64 specification;
  2. a chunkwise reference;
  3. an FP64 assembly of the two difficult backward stages;
  4. the native tcgen05 implementation on B200 hardware.

The core tiles agree with their closed-form specifications to approximately 7×10167\times10^{-16}. The assembled backward reaches worst relative errors of 3.29×1033.29\times10^{-3} for the scalar path and 3.31×1033.31\times10^{-3} for the channel-wise path, both below the stated N\sqrt{N}0 acceptance bound. The implementation is bit-for-bit deterministic across repeated executions.

The paper discloses an important exception rather than suppressing it: the widest N\sqrt{N}1 save-forward arm reaches N\sqrt{N}2, exceeding the acceptance bound by approximately 4%. The individual kernel itself measures N\sqrt{N}3 against the same FP64 oracle, so the overrun is attributed to the assembled pipeline rather than to the native kernel. The formal correctness claim is correspondingly scoped.

The backward trains all five supported recurrence variants without enabling the reference fallback. Real 300-step training loops exhibit no numerical blow-ups after fixing an exponent-overflow bug through a masked exp2 implementation. The native path also supports graph replay with bit-exact agreement against eager execution.

The positive-control result is significant: the native backward passes the complete twelve-gate verifier and is clean on every tolerance-free channel. This does not prove universal correctness outside the tested domain, but it demonstrates that the audit battery can accept a complex, independently established Blackwell kernel.

Performance and Engineering Trade-offs

The native backward is not competitive with the mature FLA Triton implementation in latency. It is approximately eight times slower at sequence length N\sqrt{N}4 and approximately 78 times slower at N\sqrt{N}5. The authors attribute this disparity to the inherently sequential reverse-state scan and to substantial unfused FP32 glue surrounding the native tensor-core stages. The FLA implementation also benefits from reusing intermediates computed during the forward pass.

This performance result qualifies the systems contribution. The native implementation closes an availability and coverage gap, rather than delivering a speed record. Its primary advantages are that it is genuinely native to Blackwell, handles the reverse-state stage, generalizes across the five recurrence families, and correctly manages the TMEM lifecycle. The paper reports internal optimizations, including a 2.75-times reduction in captured backward time through channel-wise fusion and a 2.98-times reduction for a N\sqrt{N}6 save-forward variant through TMEM tiling, but these are improvements over the authors’ own earlier pipeline, not over FLA.

The supporting Mamba-3 kernels provide a related availability result. Six Triton kernels avoid tl.dot and therefore compile under configurations where the official implementation encounters the 544-column TMEM request. This is a categorical compatibility advantage, although the paper explicitly avoids turning it into an unconditional latency claim.

Broader Experimental Implications

The paper’s applied demonstrations reinforce, but do not independently establish, the central audit result. The authors train a 1.1-billion-parameter Mamba-3 SISO model on PTB-XL using the verified kernels and report a peak macro-AUC of 0.880. The experiment demonstrates end-to-end trainability and zero NaNs after fixing an unstable N\sqrt{N}7 parameterization and a device-placement issue; it is not presented as a state-of-the-art physiological-signal result.

The authors also construct a GRPO-based autotuning system whose reward grants speed bonuses only after the full contract battery passes. Configuration-only RL improves performance by 1.167 times over the shipped default, although a deterministic shape-gated selector achieves a larger 2.174-times geometric-mean improvement over the earlier serial default. Source-edit RL performs poorly: 208 of 320 edits fail to apply, 37 applied edits fail correctness, and no successful edit exceeds the baseline. This negative result illustrates a practical benefit of contract-grade verification: incorrect optimizations are rejected before they can receive performance credit.

More generally, the work suggests that kernel-generation benchmarks should treat correctness as a multi-dimensional contract rather than a scalar approximate-equality score. At minimum, benchmark protocols should test non-finite propagation, determinism, shape variation, mixed-precision accumulation, and device/resource constraints. These tests are relatively inexpensive compared with the cost of training models or deploying kernels whose silent errors may be difficult to diagnose.

Limitations and Theoretical Significance

The audit is corpus-dependent. Although the result survives a second stack and a second native-CUDA corpus, the headline rate is still derived primarily from one Triton corpus. Gate coverage is also incomplete: gradient correctness and resource metadata are unavailable for the forward-only audit set. The verifier’s reference implementations are another potential dependency, although the FP64 design, adversarial red team, positive controls, and independent hand audit mitigate this concern.

The native backward is evaluated on a narrow envelope: B200 hardware, N\sqrt{N}8, chunk length 64, and N\sqrt{N}9. It remains partially native because normalization gradients, packing, masks, and other glue execute through PyTorch. Consequently, neither the numerical verification nor the performance characterization should be generalized to arbitrary dimensions, future Blackwell variants, or fully fused training pipelines.

The paper’s stronger theoretical implication concerns the semantics of evaluation. A conventional tolerance test treats correctness as proximity on sampled finite-valued outputs. The contract formulation instead treats correctness as preservation of a structured execution contract across input domains, shapes, precision modes, exceptional values, executions, devices, and resource constraints. This reframing is especially appropriate for GPU kernels, where undefined behavior, silent precision changes, aliasing, and hardware-specific compilation failures can invalidate an implementation without producing a large error on ordinary random inputs.

Conclusion

The paper presents a unified argument for stronger evaluation of generated GPU kernels and for disciplined implementation of specialized GPU backward passes. Its audit of 2,638 previously accepted kernels finds a 39.5% tolerance-free failure floor and a 62.1% overall contract-violation rate, with the standard benchmark check accepting 1,487 kernels that the verifier rejects and only fourteen disagreements in the opposite direction. The result is supported by positive controls, calibration experiments, agreement with the benchmark’s own code, and a stratified manual audit.

Its native Blackwell contribution supplies a tcgen05/TMEM backward for the GDN family, including the reverse-state scan absent from existing native implementations. The backward is independently checked against FP64 references, achieves approximately 1.2×1.2\times0 worst relative error in the principal configurations, is deterministic, and trains five recurrence variants. It is nevertheless substantially slower than FLA, and its verified operating envelope remains narrow.

The principal consequence is methodological: reported progress in LLM-based GPU-kernel generation should not be interpreted without examining the contract used to certify correctness. A small set of tolerance-free behavioral checks would eliminate a large fraction of the current acceptance gap, while the Blackwell implementation demonstrates how the same verification discipline can guide the development of complex, hardware-specific kernels.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

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 NaN or 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:

  1. How many LLM-generated GPU kernels that were reported as “correct” are actually broken under more careful testing?
  2. 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 NaN and infinity in the same way as the reference program
  • Works with several number formats, such as fp32, fp16, and bf16
  • 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 NaN and 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:

  1. Many AI-generated GPU programs that pass ordinary tests still contain hidden bugs.
  2. 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, and RES-01 contribute 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 N\sqrt{N} 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-03 leaves residual classification risk: its reported 1.2×1.2\times 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 dk=128d_k=128, chunk length 64, and dv{64,128}d_v\in\{64,128\}, 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 5.21×1035.21\times10^{-3}, 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 allclose benchmark 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-03 gate can prompt shape-generalization improvements, while EXC-01 or PRC-02 failures 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-02 concept can be used to detect register, shared-memory, and TMEM-budget violations before deployment. For Blackwell kernels using tcgen05, 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 dk=128d_k=128, chunk length 64, and dv{64,128}d_v\in\{64,128\}—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 dv=128d_v=128 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 2×22\times2 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 SS 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, 10610^{6}, 10610^{-6}, denormals, long LL
  • 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 2.75×2.75\times
  • 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 SS of shape dk×dvd_k\times d_v 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  ⁣N\propto\!\sqrt{N} 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 hh
  • 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 TT, 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”

Tweets

Sign up for free to view the 9 tweets with 1 like about this paper.

HackerNews