Codex search delivers a 232× GPU kernel speedup

A GPU kernel optimization contest turned an agent feedback loop into a 232× speedup over the baseline for batched QR decomposition. The author placed 12th out of 183 participants after making more than 1,500 submissions in 14 days, according to Sankalp Bearblog, published on July 8, 2026.

The contest was hosted by GPU Mode in collaboration with Core Automation as part of GPU Mode’s “Linear Algebra Kernels in the Age of Research” series. Participants had to implement batched square compact-Householder QR factorization for FP32 CUDA matrices and return the same compact (H, tau) representation produced by torch.geqrf.

The checker reconstructed Q from the submitted factors, extracted the upper-triangular R, and verified that the result satisfied:

• A ≈ QR
• QᵀQ ≈ I
• QᵀA ≈ R

Leaderboard rankings used the geometric mean of runtimes across matrix sizes and conditioning cases. The workload included square matrices from 32×32 to 4096×4096, with particularly important cases around 512×512. Low-precision formats such as FP16, FP8, and NVFP4 were allowed internally, but the returned factors still had to pass FP32-style correctness checks.

×

Turning QR decomposition into an agent search problem

GPU Mode supplied the popcorn CLI, allowing agents to test, benchmark, and submit kernels directly to the leaderboard. Shape-specific feedback and repeated submissions created a tight optimization loop: change the kernel, run the checker, inspect performance, and try again.

The author made more than 1,500 submissions during the two-week contest. Submission queues became long when too many participants submitted at once, and the shared workspace temporarily exhausted its Modal credits.

The approach was not entirely automated. The author had about a year of experience with GPU kernel optimization, mainly in Triton and some CUDA, and spent time learning QR decomposition and Householder reflections. They used conversations with Claude to build intuition and concluded that a blocked Householder algorithm with a trailing WY update was the right basic architecture. The post also says GPT-5.5 suggested a strong idea for the problem.

The underlying task is sequential. A standard Householder QR implementation processes one column at a time, using each newly updated column to construct the next reflector. That dependency makes the operation difficult to express as large matrix multiplications, leaving tensor cores underused.

Why blocked Householder QR was faster

The blocked algorithm confines the serial portion to a narrow panel of columns, such as 32 or 64. It then combines the panel’s reflectors into a single WY transformation:

H₁H₂⋯Hᵦ = I − VTVᵀ

Here, V contains the Householder vectors and T is a small upper-triangular matrix. Applying that combined transformation to the trailing portion of the input becomes three matrix-multiplication-shaped operations:

1. 1W = VᵀAtrail
2. 2Z = TᵀW
3. 3Atrail ← Atrail − VZ

That changes most of the expensive work from serial matrix-vector updates into GEMM-style operations suited to GPU tensor cores. The panel advances across the matrix, while the trailing block shrinks after each update.

Compact storage also matters. In the output matrix H, the upper triangle stores R, while the entries below the diagonal hold the tails of the Householder vectors. The leading 1 in each vector is implicit, and the separate tau vector stores one coefficient per reflector.

The contest introduced two additional engineering problems: using low precision without losing accuracy on ill-conditioned inputs, and tuning across a wide range of shapes and batch sizes. Large matrices sometimes supplied too few batches to fully occupy the tensor cores, while tiny 32×32 matrices required packing many instances into a single kernel launch.

The result was a substantial speedup, but not a winning submission: the author finished 12th, with the leaderboard measuring runtime across all required shapes rather than rewarding a single optimized case.