Papers for

gpu software engineers

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

Agentic co-design speeds AI chip and software optimization jointly

Learning to Formulate: Agentic Hardware-Software Co-Design of AI Infrastructure through Progressive Optimization and Verification

Abstract: AI infrastructure, the chips and software that train and serve AI models, is designed in layers. Layers make the system manageable, but they also fix which choices an optimizer can consider. Gains that need the chip and its software to change together are excluded before optimization begins: the formulation leaves them out. Language-model agents make it possible to revisit these boundaries, but an agent's proposal cannot show by itself that a design is correct or optimal. We present Formulaic, a flow that divides the work. The agent writes the formulation, a mathematical solver optimizes within it, and verification and measurement check its assumptions and results. The agent refines the problem step by step, from the computation graph toward the chip. Each step is a template: a family of programs with the conditions under which they are correct. Wall relaxation searches the chip by pricing the hardware limits that bind the software. This paper takes a first step, through separate studies rather than one end-to-end run. On NVIDIA GB10, templates the agent wrote run complete Qwen3-8B layers $1.075\times$ faster than SGLang. In a simulated Ventus GPU study, joint design cuts the worst-scenario cycles of Qwen2.5-0.5B to 0.428 of the reference, against 0.934 for software alone. On a five-step GEMM refinement chain, reusing proofs makes checking $2.51\times$ faster.

Thu 29 OctHardware ArchitectureArtificial IntelligenceDistributed, Parallel, and Cluster Computing
The gist
Designing the hardware and software for AI systems usually happens in separate layers, which limits how much they can improve together. The authors create a process called Formulaic where an AI agent writes the design problem, a solver optimizes it, and then verification steps check correctness. This method lets the agent refine the problem step-by-step, improving both chip and software together. Their tests show faster performance on real and simulated GPUs compared to existing approaches.
Open → 2610.39380v1

PipeLink enables flexible linking of GPU kernel parts without performance loss

PipeLink: Contract-Guided Linking of GPU Kernel Components

Abstract: The fastest machine-learning kernels are compositions of components, such as loaders, matrix-multiply mainloops, epilogues and communication stages, that run concurrently on one GPU streaming multiprocessor and share its on-chip memory, barriers, warps and registers. Because these components hard-code where they sit in this shared space, they cannot be compiled, shipped or replaced on their own: combining components from different sources means forking them by hand or keeping them in separate kernels. We present PipeLink, a contract-guided linker for GPU kernel components. Each component is compiled separately into an LTO object that carries a contract stating what it requires and what it promises; PipeLink checks the contracts against each other, relocates every component by solving one joint placement of the SM's resources, and generates the transfers between them, and the vendor LTO backend folds the result into constants. Across 51 configurations on Hopper and Blackwell GPUs, linked kernels run within 0.2% of the same sources compiled as one unit. Linking makes new compositions practical: a CuTe attention operator inside a ThunderKittens decode megakernel speeds up decoding by 2.16$\times$, a four-owner MoE training megakernel matches the original monolith, one unchanged attention core yields sparse and context-parallel variants that outperform FlexAttention, vLLM and Transformer Engine, and a GEMM + SwiGLU composition whose consumer serves three GPU architectures runs 1.2$\times$ faster on Blackwell than cuBLAS with a compiled activation.

Tue 27 OctDistributed, Parallel, and Cluster Computing
The gist
When running complex GPU programs for machine learning, different parts like loaders and math operations usually have to be combined all at once, making it hard to swap or share parts. The authors created PipeLink, which lets these parts be compiled separately and then safely linked together by checking their requirements and fitting them onto the GPU. This makes it easier to build new combinations of GPU code without losing speed. Their tests show PipeLink performs almost as well as compiling everything as one piece, and can improve performance for certain tasks.
Open → 2610.37200v1

Multi agent teams improve gpu kernel optimization performance

Evolving Agent Teams

Abstract: The rapid progress of software engineering agents drives interest in applying them to open-ended problems such as GPU kernel optimization. However, we find that existing coding agents converge to local optima on real-world, expert-written kernels (e.g., FlashInfer). We introduce Evolving Agent Teams, a multi-agent framework that escapes such local optima. It features (1) a central supervisor that diagnoses each local optimum and restructures a team of agents; and (2) a persistent file system that comprises a learning document, an evolution history, and per-team artifacts, grounding restructuring with accumulated experience. Under a matched token budget, Evolving Agent Teams consistently outperforms strong coding-agent baselines. With an extended token budget, Evolving Agent Teams generates a CUDA kernel that reaches 1.2x mean speedup over the production FlashInfer MLA paged decode kernel from scratch and wins on 36 of 47 production workloads from FlashInfer-Bench (0.86-0.99x on the remaining 11). It also demonstrates superior performance on tasks such as KDA prefill on AMD MI350X (3.01x over vLLM) and NVIDIA B200 (3.44x over FlashKDA), MoE expert-offload serving on Apple silicon (30.3 tokens/s decode for Qwen3.8-Flash-Next in MLX 4-bit on a 48 GB M4 Pro), and RoboDojo robot manipulation (62.1 on held-out seeds vs. 55.3 for the best leaderboard entry). Code is available at https://github.com/caoshiyi/EAT.

Tue 27 OctArtificial Intelligence
The gist
Optimizing GPU code is hard because many smart programs get stuck improving only a little and miss better solutions. The authors developed a system called Evolving Agent Teams, where multiple software agents work together and a supervisor reshapes their efforts based on past experience. This approach helps avoid getting stuck in small improvements and finds faster GPU code. Their system outperformed other coding programs and even made new, faster GPU kernels from scratch on real-world tasks.
Open → 2610.36848v1

Verifying safety and correctness of GPU code generated by AI models

Proving LLM-Generated GPU Kernels Correct and Safe: Floating-Point Verification in Lean and VerCors

Abstract: Modern statistical model development begins with a high-level specification in an automatic differentiation framework such as PyTorch, JAX, or TensorFlow, which is then lowered to a target backend by a compiler or implemented manually by a research engineer. In this paper, we study whether frontier language models can correctly perform the latter task by generating GPU kernels from high-level benchmark specifications. We introduce a framework in which a language-model agent uses Velvet, a program verifier for imperative programs embedded in Lean, to prove semantic equivalence between a high-level specification and a generated CUDA kernel under an explicit set of assumptions. It also asks the LLM to prove thread safety and data race freedom of the generated kernel in VerCors, a deductive verifier for parallel code. Our main contribution to the formal verification of LLM- generated GPU kernels is showing that a combination of Lean automation and language-model-guided proof construction can verify a broad set of basic neural- network building blocks over floating-point values, allowing LLMs to implement semantically correct and safe kernels. In our framework, floating-point verifications never rely on compiled code and are always checked via the Lean kernel.

Sat 17 OctProgramming Languages
The gist
Turning high-level math descriptions into fast GPU programs can cause errors and unsafe code, especially with tricky floating-point math and parallel threads. The authors study if advanced AI language models can generate these GPU programs correctly. They created a system where AI-generated GPU code is checked in detail using mathematical proof tools to ensure it matches the original description and runs safely without data conflicts. This method helps confirm that AI can write GPU code that is both correct and safe.
Open → 2610.24548v1

Small language model learns to optimize GPU code better than large models

How to Train Your Little Dragon: Teaching a Small Language Model to Construct and Refine GPU Optimization Scripts

Abstract: Compiler transformations interact, making GPU kernel optimization a search for combinations that preserve the computation while improving performance. We introduce HOW TO TRAIN YOUR LITTLE DRAGON, a training method that teaches a small language model both to construct complete optimization scripts and to improve existing ones. Instead of ranking candidates or generating kernel code, our model generates optimization scripts. We devise a compact, lossless representation whose deterministic decoding reconstructs the exact compiler trace, preserving its transformation parameters and dependencies. We use a compiler framework TVM MetaSchedule to build training data on 54,116 distinct workloads, and construct 108,594 examples in two training sets: 60,236 teach the model to generate an optimized script from an unoptimized kernel, while 48,358 teach it to produce a better script given the kernel and a somewhat optimized script. Supervised fine-tuning teaches the model to construct and improve optimization scripts from these search-derived examples. We then add reinforcement learning with a shaped reward that combines correctness with measured performance, awarding a latency-based bonus only to numerically correct kernels. We apply this training method to a model with 8 billion parameters. After supervised fine-tuning and reinforcement learning, the model achieves per-attempt correctness of 91.27% for construction and 92.01% for refinement, while reinforcement learning produces faster kernels than supervised training on 88 of 102 construction tasks and 145 of 170 refinement prompts. With only 8B parameters, our LITTLE DRAGON achieves higher per-attempt correctness and better kernel performance than six frontier LLMs: GPT-6 Astra, Opus 5, Kimi-K3, and GLM-5.3 among them, each with hundreds of billions to trillions of parameters, for which task-specific training is unavailable or expensive.

Wed 14 OctMachine LearningArtificial Intelligence
The gist
Optimizing GPU programs is tricky because many changes can interact and affect performance. The authors developed a method to teach a small language model to create and improve GPU optimization scripts that tell the compiler how to speed up code. They trained the model using many examples from a special compiler framework, then refined it with rewards based on speed and correctness. Surprisingly, this smaller model outperformed much larger language models on this task, producing faster and more correct GPU code optimizations.
Open → 2610.20980v1

TileCas lets AI coding agents write faster GPU kernels across levels

TileCas: Cascading Kernel Development Across Programming Abstractions

Abstract: Programming abstractions have traditionally been designed for humans, but code generation is increasingly performed by models and autonomous agents. We investigate abstractions for machine-driven programming through GPU and AI-accelerator kernel generation. High-level domain-specific languages (DSLs) simplify search by delegating implementation details to compilers, while lower-level representations provide finer-grained control at the cost of a larger and more complex search space. In this paper, we present TileCas, a unified, pluggable interface that enables coding agents to develop kernels across multiple editable abstraction levels. Rather than committing to a single representation, TileCas allows an agent to transfer and refine candidates across levels through Cross-Level Diagnosis, which maps correctness and performance feedback to actionable controls at different abstraction levels; Abstraction Scheduling, which selects both the candidate and representation from which subsequent refinement should proceed; and a Heterogeneous Search Tree, which preserves and revisits alternative search trajectories spanning multiple representations. We integrate TileCas with two code agents AKO and KDA, and evaluate both integrations on 50 end-to-end KernelBench Level 3 workloads across two accelerator platforms and two language models. Giving equal weight to the four accelerator-model configurations, AKO with TileCas achieves an arithmetic-mean speedup of $4.84\times$, compared with $3.75\times$ for the strongest evaluated baseline without TileCas, an improvement of 29.0%. Integrating the same interface with KDA improves its mean speedup by 69.2%, with gains in every configuration. These results show that allowing coding agents to navigate across programming abstractions can improve machine-driven software development and can be reused across different base workflows.

Sat 10 OctSoftware Engineering
The gist
Writing computer programs for graphics and AI processors is tricky because programmers use different levels of detail, from simple to complex. The authors designed TileCas, a system that helps AI coding agents move smoothly between these different levels to improve programs. TileCas tracks how well a program is doing and suggests fixes at whichever level is best. When tested, AI agents using TileCas made programs that ran noticeably faster than before. This shows smarter AI tools can write better computer code when they work across multiple programming styles.
Open → 2610.14740v1

LLM decoding sped up by pruning tuned to generated tokens

SparseDecoding: Decoding-Aware Pruning for Accurate and Efficient LLM Inference

Abstract: The memory-bound nature of the decoding stage of large language model (LLM) inference incurs significant latency. Layer-wise training-free network pruning approaches guided by the Hessian have been a prominent solution to this problem, as pruning reduces the number of nonzero parameters read from memory during decoding. Nevertheless, typical methods in this line compute the Hessian using pre-collected natural sequences, whereas the model is fed self-generated tokens during decoding, creating a distribution shift between the two sequences. The Hessian calculated on the natural sequence is different from that calculated on the generated sequence. We observe that this discrepancy causes the activation distribution during generation to deviate from that used for pruning, further hurting the pruned model performance. Moreover, most existing LLM pruning methods that bring actual speedup primarily target the sparse matrix-matrix (SpMM) multiplication, providing limited support for the sparse matrix-vector (SpMV) operations, which dominate decoding. To solve these problems, we introduce SparseDecoding, a principled decoding-aware pruning framework tailored for accurate and efficient LLM decoding. Specifically, at the algorithmic axis, SparseDecoding constructs calibration matrices from layer-wise activations collected during the dense-model autoregressive generation, excluding prefill, thereby aligning the pruning objective with the decoding activations. At the system axis, we develop an optimized N:M sparse matrix-vector kernel with bitmask indexing and fixed-step traversal. Substantial empirical results on representative LLMs (Llama-3.1-8B, Llama-3.3-70B, Qwen3-14B / 32B) demonstrate that our method consistently outperforms standard fixed-text calibration on the long-form generation benchmarks while achieving up to 1.48x end-to-end wall-clock decoding speedup on A100 GPUs.

Thu 8 OctMachine LearningComputation and Language
The gist
Decoding large language models takes time because the computer has to read many numbers from memory. Pruning, which means cutting out less important parts of the model, can speed this up, but usually it’s done using sample text different from what the model actually produces when guessing the next word. The authors found that this difference makes pruning less effective. They created a new method called SparseDecoding that prunes the model based on the data it generates itself, resulting in more accurate and faster language generation. They also built a new computer program to better handle the model’s math during decoding on GPUs.
Open → 2610.12327v1

Gpu kernel validation improves with testing and formal proof

RESOLVE: Language-Agnostic Validation of GPU Kernels Through Testing, Reduction, and Proof

Abstract: AI systems can now write and optimize production GPU kernels, but validating them remains an important challenge. Evaluating the kernel on a few random inputs and checking that its outputs match a trusted reference kernel within numeric tolerances is not sufficient: races can cause nondeterministic behavior that fails to manifest in tests, and numeric tolerances can hide bugs and cause false positives even after extensive calibration. To address this challenge, we present RESOLVE, which combines testing and formal verification to build a comprehensive kernel validation pipeline. It operates in three steps: First, it tests for nondeterminism using binary instrumentation that perturbs execution timing to expose races. Second, an agent rewrites the candidate and reference kernels to obtain "reduced-concurrency" versions that are simpler to analyze but still produce bitwise-identical outputs in all tests. Third, the reduced kernels are formally analyzed in the F*/Pulse framework and prove that they perform the same computation on real numbers. This sidesteps the need for numeric tolerances. We show that RESOLVE can validate a broad selection of kernels using KernelBench, and prove equivalence across fused GEMMs in three state-of-the-art frameworks and languages: CUTLASS, Triton, and Gluon. It also analyzes mega-kernels, notoriously difficult to validate, and finds four previously unreported issues, including two clear bugs. We show that agents can use RESOLVE to repair the issues, with minimal performance impact, highlighting that agents can optimize aggressively when they can rigorously check their results.

Mon 5 OctProgramming LanguagesDistributed, Parallel, and Cluster ComputingMachine Learning
The gist
Checking the computer code that runs on graphics cards (GPU kernels) is hard because errors can show up randomly and tests might miss them. The authors created RESOLVE, a process that first checks for timing bugs by changing execution patterns, then simplifies the code to something easier to analyze, and finally uses mathematical proofs to confirm the computations are the same without relying on numerical guesswork. They tested RESOLVE on a variety of GPU programs and found real bugs, even fixing some with little slowdown. This helps ensure GPU code is both correct and efficient.
Open → 2610.05683v1

Guided large language models improve efficiency of gpu code

D2K-Bench: Can LLM Agents Turn Expert Designs into Efficient GPU Kernels?

Abstract: GPU kernels generated by large language model (LLM) agents can remain less efficient than expert implementations, but runtime alone does not reveal how the gap relates to design discovery and implementation. We introduce D2K-Bench, a diagnostic benchmark of 26 tasks and 85 workloads that measures how effectively agents translate expert design guidance into efficient GPU kernels. The guidance covers L1: high-level algorithmic insights, L2: dataflow design, and L3: low-level optimization tricks, including dependencies among these levels. Pairwise runs with and without guidance share task descriptions, workloads, tools, hardware, and a 350-turn budget. Complementary assessments examine independently proposed designs and the design properties implemented in generated code. Across five models on NVIDIA B200 GPUs, guidance raises correctness over 130 model-task pairs from 93.1% to 98.5% and increases the Performance Score over all 26 tasks from 1.46 to 1.95. For the three frontier models with correct submissions on all 26 tasks in both runs (GPT-6-Astra, Claude-Opus-4.8, and GPT-5.6-Sol), geometric mean speedup increases from $1.69\times$ to $2.49\times$. Across all five models, the mean combined implementation score increases from 57 to 70 out of 100. These results show the value of expert design guidance while identifying design properties that remain unimplemented.

Fri 2 OctMachine LearningArtificial IntelligenceDistributed, Parallel, and Cluster Computing
The gist
Generating fast GPU programs is tricky, and large language models (LLMs) often produce slower code than experts. The authors created a benchmark called D2K-Bench to test how well LLMs turn expert design tips into efficient GPU code. They found that giving LLMs detailed guidance on algorithm design, data flow, and low-level tricks helped them write more correct and faster code across many tasks. However, some complex design aspects were still missed by the models, showing room for improvement.
Open → 2610.03226v1

New method speeds up low-precision matrix math on GPUs by up to 83 times

FP64 Is All You Want, INT8 Is All You Need, FP4/6/8 Is All You Have

Abstract: Ozaki scheme II emulates FP64 matrix products with INT8 ones through residues modulo pairwise coprime moduli, and variants for FP8 and FP4 have followed. We treat these schemes as one family and pose the choice of a scheme as a combinatorial program that minimizes the number of low-precision GEMMs. Given, for each modulus, a finite set of ways to compute products modulo it from low-precision GEMMs, we find the choice of moduli and ways with the fewest GEMMs, for any format, accumulator and inner dimension, and derive lower bounds on the GEMM count over the whole family. Applied to the formats of current GPUs, the method gives the first FP6 schemes, an FP8 scheme with fewer GEMMs than any previous one, and an FP4 scheme that the bounds show needs the fewest GEMMs of any scheme in the family whose moduli lie in a stated range. Implemented on three Blackwell GPUs, the INT8, FP8 and FP4 schemes run faster than native FP64, up to 83x on B300.

Tue 29 SeptDistributed, Parallel, and Cluster Computing
The gist
Calculations using very precise numbers, like FP64, can be slow on graphics processors. The authors studied ways to do these calculations using simpler, smaller number types like INT8 or FP4, which GPUs handle faster. They developed a strategy to pick the best mix of these small number methods that use the fewest slower steps. Their approach found faster ways to do this math on current GPUs, running as much as 83 times faster than the usual precise method. This could help speed up programs that rely on big matrix calculations.
Open → 2609.37693v1

AI translates GPU code directly improving performance over traditional compilers

AI as a Compiler: Compiling Triton kernels without the Triton compiler

Abstract: Compiler backends are expensive to build and maintain as programming models, workloads, and accelerators evolve. We investigate whether large language models can replace the conventional optimizing and lowering pipeline, a process that we call AI lowering. We study AI lowering from Triton to NVIDIA PTX: an LLM agent translates Triton kernels directly into PTX. We build an environment that evaluates candidate PTX, and an agentic harness in which an LLM translates Triton kernels into PTX. Across twelve common kernels on Ada, Hopper, and Blackwell GPUs and ten kernels from recent ML papers, AI lowering achieves 0.83x-3.34x the performance of autotuned Triton. The largest gains come from transformations that Triton's lowering pipeline does not perform, such as decoding packed binary weights directly into Tensor Core operands (3.34x on BitDelta), assigning each thread a complete softmax row in tensor memory (1.37x on FlashAttention), and reusing overlapping convolution windows (up to 2.23x). These results rely on a robust evaluation harness with comprehensive verification support. We build on Volta, an existing PTX verifier, and substantially extend it to support modern GPU architectures by introducing support for Blackwell's tcgen05 Tensor Core interface. This requires modeling three architectural features: managed tensor memory, descriptor-based operand layouts, and asynchronous execution coordinated through commits, waits, memory barriers, and proxy fences. We discuss the challenges involved in formalizing them, as well as the current limitations. Our results suggest an emerging future in which AI compilers replace custom-written intermediate representations and checkers, reducing the time and engineering effort required to bring up software for new general-purpose and custom chips.

Tue 29 SeptArtificial Intelligence
The gist
Writing software to run efficiently on new computer chips is very difficult. This paper shows that large AI models can act like translators, turning high-level GPU code into the low-level instructions that GPUs understand, without needing traditional compilers. The authors demonstrate that this AI-driven process can sometimes produce faster code than the usual method. Their approach also handles complex modern GPU features and checks the code's correctness. This suggests AI might one day reduce the effort needed to make software for new hardware.
Open → 2609.36800v1

Amd gpu support added to awkward array for faster physics data analysis

Bridging the Vendor Gap: Enabling AMD GPU Support for Awkward Array via ROCm/HIP for the HL-LHC Era

Abstract: The High-Luminosity LHC (HL-LHC) will demand order-of-magnitude gains in analysis throughput, and increasingly those gains must come from GPUs that are not made by a single vendor. Leadership-class systems such as El Capitan, Frontier and LUMI are built on AMD accelerators, yet the Scikit-HEP analysis stack---and Awkward Array in particular---has grown up CUDA-first. We report on $rawkward$, a Rust-backed kernel engine that adds a ROCm/HIP backend for Awkward Array's nested, jagged, variable-length data structures. Our central finding is that a naive source-level port of CUDA kernels to HIP loses $5$--$10\times$ in performance on irregular kernels, because AMD's $64$-lane wavefronts, higher register pressure and more expensive divergence behave fundamentally differently from NVIDIA's $32$-thread warps. We show that a small, reusable set of optimization patterns---loop flattening, $128$-bit vectorized loads, splitting fused kernels, and profile-guided launch configuration---recovers CUDA-class performance without changing the public API. A Rust macro-and-match dispatch layer keeps a single, backend-agnostic call site while emitting vendor-specific kernel strategies, and the type system enforces buffer-size and lifetime correctness at compile time. On a two-socket AMD Instinct MI210 node we measure GPU speedups from $1.03\times$ (bandwidth-bound $sum$) up to $12.5\times$ ($count$) over $128$ EPYC~7763 CPU cores, and the Rust CPU kernels match or beat on aggregate the incumbent C++ kernels (geometric-mean runtime ratio $0.37\times$ across twelve kernels). We argue that these patterns constitute a practical recipe for performance-portable, vendor-agnostic HEP analysis kernels.

Mon 21 SeptDistributed, Parallel, and Cluster ComputingProgramming Languages
The gist
Data analysis for physics experiments at the HL-LHC needs to be much faster and use different types of graphics cards, not just Nvidia’s. The authors created a bridge that lets a popular data tool called Awkward Array work well on AMD GPUs, which are used in some supercomputers. They found simple copying of Nvidia-focused code ran much slower on AMD and fixed this by optimizing the code specifically for AMD’s hardware quirks. Their approach speeds up certain computations by up to 12 times compared to many CPU cores, without changing how users program with Awkward Array.
Open → 2609.24628v1

Adaptive encoding reduces matrix multiplication steps on Nvidia tensor cores

AWE: Adaptive Weight Encoding for Exact Integer Matrix Products with Fewer GEMMs on FP4 Tensor Cores

Abstract: Emulation of high-accuracy floating-point matrix multiplication, as in the Ozaki scheme, splits the inputs into low-precision components and multiplies them pairwise. These products must be error-free, and each is an integer matrix product times a scale factor. FP4 Tensor Cores are the fastest on the NVIDIA B200 and B300 but cannot hold INT8 operands. The FP4 values scaled by 2 form the set $S = \{0, \pm1, \pm2, \pm3, \pm4, \pm6, \pm8, \pm12\}$, which contains every residue modulo 13, so with carries any integer splits into base-13 digits that FP4 can store. Prior work splits each INT8 operand into 3 such digits (limbs) with weights $(1, 13, 169)$ and multiplies them pairwise, 9 FP4 matrix multiplications (GEMMs) for INT8$\times$INT8. The classical ways to reduce products, such as the Karatsuba and Toom--Cook methods, do not apply as they stand: sums of limbs reach $\pm 24$ and leave $S$. This paper asks how many FP4 GEMMs are needed for one integer matrix product. We propose Adaptive Weight Encoding (AWE): the limbs take freely chosen integer weights, the stored planes are linear combinations of limbs, and the exact product is the sum of the FP4 GEMMs scaled by reconstruction coefficients. For each input range, we searched these choices for encodings with fewer products and found INT8$\times$INT8 in 6 products and INT4$\times$INT8 in 4. The formulation also holds modulo $m$, which covers the residue number systems of Ozaki scheme II: for the FP64 significand, the 75 products of prior work are reduced to 59. The boundary in product count between encodings with and without residues lies near input width 15. We release the encodings found.

Mon 21 SeptMathematical SoftwareHardware Architecture
The gist
Multiplying big integer matrices exactly can be slow when using very low precision floating-point units like FP4, which are fast but limited in number size. The authors found a way to represent the numbers with flexible weights, reducing the number of smaller fast multiplications needed from 9 to 6 for 8-bit integers. This new method also applies to other settings and can speed up accurate matrix calculations on hardware like Nvidia B200 and B300 GPUs. They provide the detailed encodings to help others use these improvements.
Open → 2609.24519v1

Tensor superoptimizer boosts gpu program speed by up to three times

Unleashing the Power of Equality Saturation for Tensor Program Superoptimization

Abstract: Efficient GPU implementations of tensor programs often require joint optimization of high-level algebraic formulations and low-level execution strategies. However, the resulting search space grows rapidly as transformations combine across operators, making joint optimization difficult to scale. We present EqiForge, a tensor program superoptimizer based on equality saturation. Its unified IR represents high-level tensor expressions and tiled computations in a single expression language. By composing equality rules, EqiForge derives fused implementations such as FlashAttention-style kernels directly from tensor expressions. Early compaction prunes redundant partial programs before completion, while subgraph composition extends the search to larger graphs. Across tensor-program benchmarks, EqiForge achieves a geometric mean speedup of 1.32x and a maximum of 2.74x over the fastest available baseline per configuration. Its attention kernels outperform FlashAttention by up to 1.87x in decode and approach its performance in prefill. EqiForge also discovers new implementations that outperform torch.compile on various Transformer layers, including QK-normalized MLA (3.16x) and mHC (5.84x).

Fri 11 SeptDistributed, Parallel, and Cluster Computing
The gist
Making programs that run on graphics cards faster is tricky because there are many ways to change the program, and trying them all takes too long. The authors created EqiForge, a tool that uses a special method called equality saturation to explore many program changes efficiently. EqiForge finds better ways to run tensor math, which is common in AI tasks, making programs up to three times faster than current methods. It can also discover new fast versions of parts used in popular AI models.
Open → 2609.12330v1

Code generation simplified by clear computational models for gpu kernels

The Art of Closed-Formula Defaults: Search-Free Code Generation for Tensor Operators

Abstract: Agentic search and automated optimization of GPU kernels are powerful tools for large language model inference. Their effectiveness, however, depends not on the sophistication of the search itself, but on the clarity of the optimization problem being solved. We provide an application-first approach that drives a hierarchical code generation tool from operator specifi cation down to GPU instructions, and show that a clearly defined computational model makes the optimization problem tractable.

Thu 10 SeptMathematical Software
The gist
Generating efficient code for GPUs, which are computer chips used in tasks like AI, is tricky because the optimization problems can be complicated. The authors found that clearly defining the rules and structure of the computations makes it easier to generate optimized GPU code without needing expensive searching methods. They built a step-by-step tool that starts with describing math operations and ends with GPU instructions, making the whole process more straightforward and faster.
Open → 2609.10937v1

Fp64 emulation gains speed on Nvidia Rubin GPUs with fp8 tensor cores

Ozaki 2.5: Engineering the Deconstruction Path of fp64-Emulated Dense Matrix Multiplication on FP8 Tensor Cores

Abstract: FP8 Ozaki II emulates FP64 matrix multiplication by tensor-core products over a CRT residue system; converting the operands into residue planes (the deconstruction term in the Tensor-Memory Equilibrium model of the companion paper "FP8 is All You Need, Part 1") costs integer-pipe and memory resources before tensor instructions issue. This paper engineers that path; every result is a model projection pending measurement. First, a deconstruction-aware model: on the NVIDIA Rubin GPU the emulated rate reaches the arithmetic roof $P_{\rm FP8}/(3r+1)$ ($\approx 473$ TFLOPS at $r=12$) only within one thread-block cluster; larger outputs are re-split on the fly and held at a floor of $\approx 235$ TFLOPS (half the roof, a ratio of three design integers, not a fit), while real solvers' tall/skinny shapes stay near the crossover, $1.6$-$1.9\times$ over simple deconstruction today. Second, the method: convert-once residue workspaces, an exact two-limb constant-reduction GEMM on integer tensor pipes (or pure-SIMT dp4a), and conversion pipelined behind the MMAs, moving the crossover from $\approx 1211$ to $\approx 480$-$730$. Third, modulus co-design: all-byte and hybrid sets, two supply bounds and a carry-corrected E4M3 split of tail moduli. Fourth and central, the closed-form floor names its hardware escape, and the prize is Rubin's: a stream-side residue-conversion mode on the asynchronous copy path (Option C), a narrow fixed-function block sized as a bill of materials, takes plane formation off the arithmetic pipes and lifts the floor from 235 TFLOPS to the full 473-TFLOPS roof at unchanged cluster reach, about doubling HPL-class FP64 per Rubin GPU, and unbinds conversion-bound sparse kernels. The NVIDIA GB300 GPU, whose 135-TFLOPS roof sits at its own floor, gains little; floor and remedy are Rubin-scale. Application traces ground the analysis; constants are script-checked.

Tue 8 SeptMathematical SoftwareHardware ArchitectureDistributed, Parallel, and Cluster Computing
The gist
Performing precise FP64 (double-precision) matrix multiplication on GPUs is slow and costly. The authors show a way to speed this up by breaking down FP64 operations into many simpler FP8 operations using the CRT (Chinese Remainder Theorem) system and careful engineering on NVIDIA Rubin GPUs. They modeled and improved the conversion steps to greatly increase computation speed, almost doubling performance for some large matrix problems. This method exploits special hardware and memory pathways to avoid bottlenecks seen on other GPUs like the NVIDIA GB300.
Open → 2609.09095v1