How AlphaEvolve’s tiling rule sped up Gemini training

A matrix-multiplication kernel needs a way to choose block sizes for each input shape. In DeepMind’s Gemini case, AlphaEvolve searched for code that makes that choice. The authors report that the resulting rule reduced Gemini’s overall training time by 1%. Understanding that gain starts with the decision the code makes. Technical report, §3.3.2

A kernel is a program specialized for accelerator hardware. Its task here is the matrix product A × B = C, divided into smaller blocks called tiles. An M × N tile of A multiplies an N × P tile of B to contribute to an M × P tile of C. The contributions accumulate along the shared dimension. Choosing M, N and P determines how the multiplication is broken into pieces and affects the balance between computation and moving data.

Those dimensions must work with the hardware and the surrounding computation. Figure 7 names the matrix unit’s preferred shapes and memory capacity, memory required by nearby operations, operations fused into the kernel, and compiler details. AlphaEvolve changes the code that selects the tiling strategy while preserving the underlying mathematical operation. That constrained edit is why the authors describe correctness as maintained by construction: the search can change execution choices while keeping the matrix product fixed. Figure 7 and the tiling setup

Editorial explanation of Figure 7 and §3.3.2. The grids illustrate block relationships, not actual tile dimensions. The nested boxes locate the kernel within training; their areas do not represent elapsed-time shares.

The recurring problem is that the next input can have different dimensions. The paper describes search-based autotuning as requiring another tuning search after each shape change. A heuristic packages the choice into a rule that can be called again for the next shape, although crafting a good rule by hand is itself an engineering bottleneck. AlphaEvolve searched that rule-making code. The reusable output is therefore a way to choose configurations as inputs change, extending the value of the search beyond one tuned multiplication.

The performance objective was actual kernel runtime on real TPUs. This connects a candidate rule to the consequences of its choices under the hardware and compiler constraints. The arithmetic remains fixed; execution time determines which tiling choices are useful.

The evaluation also had to match the reusable output. The researchers collected realistic input shapes from kernel users and split them equally. Half supplied the optimization targets during evolutionary search; the remaining half tested the resulting heuristic’s general applicability. Here, the paper’s training and evaluation sets are sets of kernel input shapes used to search for and assess code. Reserving shapes asks whether the selected rule makes useful choices beyond the inputs that guided its selection. It tests applicability within that collected workload. Runtime objective and shape split

Over the existing expert-designed heuristic, the paper reports an average 23% kernel speedup, with a corresponding 1% reduction in overall Gemini training time. The authors also report deploying the discovered rule in production. The training-time result gives the kernel improvement a benefit beyond the local runtime measurements. These percentages describe different quantities: average kernel speedup and the duration of training as a whole. The supplied section gives no averaging weights or per-shape results, so the 23% average cannot be assigned to every input, and the two numbers alone do not reveal the kernel’s original share of training time. Results and production deployment

The feedback inside AlphaEvolve runs through programs and prompts. DeepMind describes Gemini models proposing code, automated evaluators verifying, running and scoring programs, and a program database selecting which programs enter later prompts. In this case, TPU runtime supplies the search objective. Evaluated code can thus influence the material available for another proposal. That mechanism describes feedback through program selection; it does not measure a change in the proposing model’s capability. DeepMind’s program-search description

Editorial explanation of the shape split, program feedback and reported deployment. The broken capability link marks a missing measurement, not evidence that improvement cannot occur.

Deployment carries the selected rule into the computation used to train Gemini. DeepMind’s announcement also explicitly includes training the language models behind AlphaEvolve among the processes it improved. Together, these reports describe a concrete infrastructure feedback path: Gemini helps produce code that improves Gemini training.

A stronger recursive-improvement claim would require a further connection: a subsequently trained model becomes better at discovering algorithms, then uses that capability to deliver additional training improvements. The supplied announcement and kernel section do not measure that sequence. The reported efficiency gain is a positive result at the level of training infrastructure; the return path through a more capable algorithm discoverer remains unmeasured. This case therefore does not establish general recursive self-improvement.

This 14 October 2026 analysis revisits DeepMind’s 14 May 2025 announcement and the supplied kernel-engineering extract. It presents author-reported performance and deployment results with editorial explanations, without independent replication results.