Where GPU Software Fails Beneath Large Language Models

Looking beneath the model

GPU kernels are programs that perform operations on graphics processors. Libraries package optimized implementations of attention, matrix multiplication and quantization for use in model training and inference. Their behavior depends on more than the mathematical operation: input dimensions, memory organization, numerical formats and GPU capabilities all help determine which implementation runs.

In the preprint An Empirical Study of Issues in GPU Kernel Libraries for LLM Systems, Yanjie Gao, Jiayi Bi, Haoxiang Lin and Ling Feng investigate failures across this layer. Rather than introducing a faster kernel, they examine reported problems, their diagnoses and available repairs.

How the evidence was selected

The researchers collected 9,099 GitHub issues from FlashInfer, FlashAttention, Triton, CUTLASS, DeepGEMM, xFormers and bitsandbytes, covering reports dated from December 2015 through July 2026. These projects span attention, matrix operations, compilation and quantization.

Screening retained 3,181 closed reports concerning concrete failures of existing functionality. The authors excluded duplicates, support questions, feature requests and reports without explicit failure evidence. They then constructed a 300-report sample, with each repository represented proportionally to its candidate reports.

Reports without an identifiable cause were replaced by reports from the same repository created as close in time as possible. Two authors independently classified symptoms and root causes, achieving a Cohen’s kappa agreement score of 0.87 before resolving disagreements through discussion. The resulting taxonomy contains six symptom categories and 15 root-cause categories.

Many problems occur before calculation

Deployment failures accounted for 27.33% of the sample, and build failures for 24.33%. Together, these categories represented more than half the reports: problems frequently prevented software from becoming ready for device execution.

The distinction matters. Deployment failures included installation, dependency, linking and loading problems. Build failures prevented source or generated code from becoming an executable artifact. A library can therefore be unusable even when the arithmetic in its kernel is not the immediate problem.

Root causes provide a different view from symptoms. Compiler and build-system problems accounted for 27.00% of reports, while runtime-environment problems accounted for 33.33%—a combined 60.33%. Software incompatibility was the largest individual root-cause category. These figures describe the selected reports, not the likelihood that any particular deployment will fail.

Successful execution can conceal wrong results

Incorrect functionality appeared in 53 reports, or 17.67% of the sample. One FlashAttention case illustrates why checking only an operation’s output can miss a training defect. A block-sparse attention implementation produced a correct forward result but inaccurate gradients during the backward calculation used in training.

Information identifying the permitted attention blocks had not been preserved for the backward pass. Consequently, that pass calculated gradients as though dense attention had been used. Saving and passing the missing sparse information restored agreement with a higher-precision reference.

Another case involved a FlashInfer sampler that intermittently returned invalid token identifiers. An underlying parallel operation required separate input and output storage, but the implementation reused the same variable for both. Introducing separate storage corrected the reported behavior. Both examples expose hidden requirements that a supported operation must still satisfy.

Testing needs trustworthy comparisons

Numerical disagreement does not automatically establish that the optimized kernel is wrong. In one report, FlashAttention gradients disagreed with a reference using FP16 arithmetic but matched an FP32 calculation. The problem was rounding error in the lower-precision reference.

The study therefore emphasizes comparisons with compatible numerical assumptions and appropriate tolerances. It also discusses boundary tests, memory and synchronization diagnostics, and performance measurements that separate compilation time from device execution. A Triton case traced a slowdown to repeated compilation rather than slow GPU arithmetic.

Recommendations, with limits

The authors propose compatibility checks across hardware and software versions, explicit checks of kernel input requirements, improved numerical and compiler diagnostics, and facilities to record and replay failures. These are research and engineering directions, not tools whose effectiveness this study experimentally establishes.

The evidence also has selection limits. Closed, well-documented reports with identifiable causes may differ from unresolved or poorly documented failures. Manual classification requires judgment, and practices absent from issue discussions may still have been used. Seven open-source libraries cannot establish failure rates for proprietary kernels or complete training and serving systems.

The preprint’s practical message is nevertheless concrete: reliability checks need to cover installation, compilation, implementation selection and numerical results—not merely whether a kernel launches.