PaperlayerView exact revision on arXiv

Source-linked AI summary

Engineering Efficient Self-Play Chess: Search, Replay, and Throughput Under Limited Compute

Bertil Braun

arXiv:2609.37447v1cs.LGcs.AI

TL;DR

The paper asks how strong an AlphaZero-style chess system can become under limited training compute when its full learning loop is engineered for efficiency. It trains from random initialization through searched self-play and evaluates the integrated system against fixed-node Stockfish 13. In 2.5 days on one eight-GPU node, the model reached 3,251 benchmark Elo at 100,000 searches per move.

  • Problem

    The study asks how strong an AlphaZero-style chess system can become when its full learning loop must operate within limited training compute.

    Source: §1 · p. 1, §3.1 · p. 2

  • Method

    The system trains from random initialization through searched self-play, combining a compact structured policy head, progressive model sizing, targeted restart states, prioritized replay, and throughput-oriented inference and training.

    Source: §10 · p. 19

  • Results

    3,251 benchmark Elo at 100,000 searches per move against a fixed-node Stockfish 13 ladder, after 2.5 days on one eight-GPU node.

    Source: §10 · p. 19

  • Takeaways & Limitations

    The reported strength demonstrates what the integrated recipe achieved within the available compute budget, while component studies show that local optimizations need not improve the complete learning loop.

    Source: §10 · p. 19

    The study’s principal limitations concern attribution of gains, calibration of playing strength, and transfer to larger models or different workloads.

    Source: §9 · p. 18

Abstract

from arXiv · show

How strong can an AlphaZero-style chess system become under limited training compute when its entire learning loop is engineered for efficiency? We train from random initialization through searched self-play on a single eight-GPU node for 2.5 days. The resulting 6.32-million-parameter model reaches 3,251 benchmark Elo [3,206, 3,297] at 100,000 searches per move (estimated at under five seconds of thinking time) against a fixed-node Stockfish 13 ladder. The run ingests 3.25 million completed games, involves an estimated 100 billion search simulations, and makes 836.6 million training presentations. We investigate search allocation, replay and restart-state selection, policy representation, progressive model sizing, quantized inference, and throughput engineering. Alongside the retained design, we document plausible alternatives that failed to improve the complete learning loop or did not justify their cost. The reported strength is a result of the integrated system, not an isolated Elo gain attributable to any single choice.

1 How far can efficient self-play go?

The study asks how far an AlphaZero-style chess system can go when its full self-play learning loop is engineered for efficiency. It reports a strong searched-play result from a short, single-node training run and examines system choices and alternatives across the loop.

1 How far can efficient self-play go?

  • In 2.5 days on one eight-GPU node, the 6.32-million-parameter model reached 3,251 benchmark Elo at 100,000 searches per move and 1,658 benchmark Elo without search.Both results are against the project’s fixed-node Stockfish 13 ladder; the searched budget is estimated at under five seconds of thinking time.Source: §1 · p. 1

1.1 Scope and contributions

  • The study covers chess, briefly considers cheaper 7×7 and 9×9 Go for tuning, and examines search, replay, restart states, policy, model sizing, resignation, auxiliary targets, and quantized inference.The authors kept chess as the focus because useful Go tuning appeared unlikely to transfer directly.Source: §1.1 · p. 1

1.2 Roadmap

  • The report moves from chess evaluation and system design through component experiments and throughput to failure studies, training progress, playing strength, and the final recipe.Appendix D specifies the final recipe.Source: §1.2 · p. 1

2 Evaluating the chess system

The paper evaluates chess strength with fixed search-visit budgets and compares the final model against Stockfish 13 at fixed search limits. It also frames component experiments around whether proposed changes improve the full learning loop, not just a local metric.

2 Evaluating the chess system

  • Search effort is reported in visits rather than seconds so hardware speed changes completion time, not the search budget; approximate thinking time is reported separately.Fixed visit budgets also prevent background load from changing the amount of search performed.Source: §2 · p. 1

2.1 Final playing strength

  • The model was tested without search and at four increasing search budgets, against two Stockfish limits, using 50 openings played once with each colour.Each match contains 100 games, and ratings use the opponent against which the model scored closest to 50%.Source: §2 · p. 1, §2.1 · pp. 1–2
  • 3,251 benchmark Elo against the harder opponent and 3,247 against the other were measured at the deepest budget, with the two ratings agreeing closely.The ratings use a published calibration of Stockfish’s fixed node limits.Source: Table 1 · p. 2, §2.1 · p. 2

2.2 Reading the component experiments

  • Component experiments follow proposed changes through the learning loop where measured, because faster inference or lower stored-position loss alone does not establish stronger play.Online comparisons matched starting weights, replay, evaluation, and hardware where possible; separate strength gains are attributed only when measured.Source: §2.2 · p. 2

3 Background and system design

The chapter explains how searched self-play converts network predictions into training targets, then describes an integrated system for producing, learning from, and evaluating chess games under limited compute.

3.1 Learning through search; 3.2 Related work

  • AlphaZero search turns policy and value predictions into stronger training targets, while KataGo and related search, replay, graph-search, and restart work motivate the efficiency investigations [1] [2] [3] [4] [5] [6].Root visit distributions supervise move probabilities, completed-game outcomes supervise value, and improved predictions guide later searches.Source: §3.1 · p. 2, §3.2 · p. 2

3.3 One learning cycle; 3.4 Why the search loop stays in C++

  • Actors search concurrently, replay converts completed trajectories into examples, and the trainer publishes updated weights while evaluation matches track progress separately.The search inner loop stays in C++ to avoid repeated Python dispatch; batched TensorRT inference lets other ready games advance while predictions are computed.Source: §3.3 · pp. 2–3, §3.4 · p. 3

3.5 Chess representation and outputs

  • The final network uses a shared 14-block, 160-channel backbone for 52 input planes, with policy and WDL value heads guiding search and auxiliary heads used only in training.The input includes game-state features; the policy encodes 1,880 actions, and search uses win probability minus loss probability as its scalar value estimate.Source: §3.5 · pp. 3–4, Figure 2 · p. 4

3.6 Search and self-play

  • PUCT balances estimated continuation value against exploration, and root visit distributions become policy targets as self-play varies openings and restart positions.The search budget rises from 300 to 800 visits as training progresses; a maximum game length limits compute spent on unusually long games.Source: §3.6 · pp. 4–5

3.7 Replay and materialization

  • Replay mixes positions across games, stores sparse search policies in a circular memory-mapped buffer, and grows from 600,000 toward 20 million positions.Sampling combines uniform draws with preference for positions where search substantially changed move probabilities; four training presentations are allowed per new position.Source: §3.7 · p. 5

3.8 Training

  • Training combines searched-policy and outcome prediction with auxiliary next-policy and remaining-length losses, while unfinished games omit unavailable remaining-length labels.Distributed data parallel training uses all eight GPUs with global batch size 2,048; half the actors continue self-play during training blocks.Source: §3.8 · p. 5

3.9 Progressive models and publication

  • Progressive sizing begins with a faster small model, tests larger candidates for catch-up, and retains the successful small-to-medium path; limited larger-model continuation showed no further strength gain.The inference copy removes auxiliary heads, is exported through ONNX to TensorRT, and uses quantization-aware training for eight-bit backbone convolutions.Source: §3.9 · p. 5

3.10 Evaluation

  • Evaluation uses colour-reversed matches against fixed-node Stockfish, with short policy-only and searched evaluations tracking different aspects of progress.Final matches test increasing search budgets, and local loss or throughput improvements must still contribute to stronger play within the available training time.Source: §3.10 · p. 6

4 Research investigations

This section investigates how search, training data, network design, and compression choices can support an efficient self-play system. It evaluates approaches for directing compute toward learning and retaining design elements supported by component tests, while noting unresolved comparisons.

4.1.1 The fixed-budget baseline

  • About 81 Elo per doubling: fixed-network score rose from 0.318 at 200 visits to 0.748 at 1,600, while 72.4% of 600-visit positions matched the 10,000-visit best move.These frozen-network results establish the value of search depth, not an optimal training schedule.Source: §4.1.1 · p. 6

4.1.7 The retained search design

  • The retained search design raises a fixed visit cap from 300 to 800 across training and applies each scheduled cap to every recorded move.It combines root noise, temperature, forced root playouts with forced visits pruned from targets, first-play urgency, a 0.99 per-ply discount, 60% subtree-visit retention, and native batching.Source: §4.1.1 · p. 6, §4.1.7 · p. 8

4.1.2 Why fast and full searches did not transfer

  • Fast/full search and concentration-threshold stopping were not retained because they discarded useful policy targets or tended to stop where more search helped.The fast/full recipe spent 42.9% of nominal search work on cheap moves excluded as primary targets. The threshold audit suggested potential savings but lacked intermediate traces to identify a safe stopping point; diffuse and already-decided positions benefited little, while moderately concentrated but contested positions gained most.Source: §4.1.2 · p. 6, §4.1.3 · pp. 6–7

4.1.3 Three attempts to allocate search adaptively

  • The learned allocator improved policy agreement but weakened learning, while an in-search stopper cut nominal search by about 14% yet improved generation cadence by only about 3%.Repeated allocator attempts trailed comparable non-adaptive training by roughly 60–100 ladder Elo. The stopper's paired strength differences were unresolved, and the cadence gain was worth only about one Elo over three hours because much removed search was off the critical path.Source: §4.1.3 · p. 7

4.1.4 Parallel leaves: buying latency with search quality

  • Four- and sixteen-way parallel leaves cut match time by roughly fivefold and elevenfold, but sixteen-way search at 100 visits lowered the central strength estimate by about 235 Elo.A sweep estimated a 6.4 ± 4.7 Elo loss per doubling of parallel leaves. Many independent self-play games can fill batches without much per-tree parallelism; interactive play has only one root, and the budget must be large enough to tolerate less-informed selections.Source: §4.1.4 · pp. 7–8

4.1.5 When a tree became a graph

  • Exact graph reuse avoided only 0.0249% of evaluations at 1,000 searches and 0.1769% at 10,000, while running 8.63% and 8.28% slower; caching likewise lacked demonstrated speedups.Exact chess-state equality sharply limited graph sharing. The implemented cache had a 0.970% hit rate, and disabling it made game updates about 0.88% faster; an audit found repeats of about 4% or less, with same-batch duplicates essentially absent.Source: §4.1.5 · p. 8, §4.1.6 · p. 8

4.2.1 Restart-state selection

  • Restart states target unresolved alternatives, while replay admits searched positions throughout games and grows capacity from 600,000 to 20 million rows.Half of games start after zero to eight random legal plies and half from archived states when available; archived positions favor meaningful untried branches. The sampler uses 70% policy-surprise draws capped at 2.0 and 30% uniform draws; the retained reuse ratio is four presentations per admitted row.Source: §4.2.1 · p. 8, §4.2.2 · p. 9, §4.2.3 · p. 9

4.2.6 Outcome targets at the ply cap

  • At the later ply-cap checkpoint, a dedicated cut-position search scored 0.193 Brier and 0.374 cross-entropy versus 0.388 and 0.707 for material divided by 39.The retained worker uses a full search at the cut position to bootstrap a soft WDL target. Resignation is calibrated from continuation games with a 2.5% upper-bound gate; the benefits of the separate 0.99 search and 0.998 training discounts were not established.Source: §4.2.5 · p. 9, §4.2.6 · p. 10, §4.2.7 · p. 10

4.2.11 The retained data strategy

  • The retained data strategy combines broad opening coverage, targeted restarts, expanding replay, and policy-surprise sampling, while fresh-game supply limits reuse.Calibrated resignation and searched cutoff values reduce trajectory-completion cost. Future-derived auxiliary labels are masked when unavailable; broader auxiliary bundles were set aside during simultaneous-problem diagnosis, not shown harmful. Reanalysis was integrated into an earlier replay design but not retained, and its return versus fresh self-play was unmeasured; publishing every 100 optimizer steps cost too much overhead, so the retained interval is 500 steps. Half the actors remain active per training block, with overlap effects deferred to Chapter 5.Source: §4.2.11 · p. 11, §4.2.8 · p. 11, §4.2.9 · p. 11

4.3.1 Three policy representations

  • 0.0298 nats: the from-to head improved held-out policy fit and cut head parameters to 50,048 from 483,680, with a smaller throughput penalty at large batches.On the controlled convolutional trunk, throughput fell about 1.9% at batch 512 and 9% at batch 64. A move-plane head did not show an advantage over the dense control.Source: §4.3.1 · p. 11

4.3.9 Decision

  • The selected network uses 52 side-to-move-canonical board planes and a compact WDL head; training-only next-policy and remaining-length auxiliaries are removed at deployment, adding no inference cost.A matched 32-channel probe added 97,020 parameters, reduced measured training throughput by 1.31%, and improved total loss by only 0.00309 in one short seed while slightly worsening WDL loss.Source: §4.3.2 · p. 11, §4.3.4 · p. 12

4.3.3 Convolution, attention, and global context

  • The best Smolgen attention cell beat the convolutional comparison by 0.0090 nats, but convolution remained preferred for faster, lower-memory serving.Replacing attention’s dense head with from-to and reallocating capacity to the trunk improved held-out gap by 0.1573 nats; this was not an isolated head replacement. Periodic global pooling gave local convolutions whole-board context, with no clear final-strength difference in the qualitative comparison.Source: §4.3.3 · p. 12

4.3.6 Quantization as an architectural constraint

  • 135,000 INT8 positions per second: the scaled post-activation trunk outpaced TorchScript BF16 at 60,000 and TensorRT FP16 at 99,000 in model-core throughput.These are not end-to-end self-play rates or evidence of a playing-strength advantage. Ordinary post-training INT8 preserved only 13.3–25.9% policy top-one agreement, motivating quantization-aware architectural changes.Source: §4.3.6 · p. 13

4.3.7 Progressive model sizing

  • Small-to-medium progressive sizing worked repeatedly, but function-preserving growth of a larger model reached parity without a clear strength gain, leaving the reported model medium-sized.The larger candidate trained on the same replay before promotion, which required two passing paired matches against the active model; a matched-compute comparison of catch-up versus growth remains needed.Source: §4.3.7 · p. 13

4.3.8 Distillation and compact models

  • 291.3 Elo: the 474,069-parameter replay-distilled student trailed its teacher at 64 searches each, and parity required 850 searches under an equal-MAC allowance.Its measured serving advantage raised searches only to 186 against the teacher’s 64, and the allowance omitted tree work and inference overhead. Distillation reduced inference cost, but realized search gains were smaller than arithmetic ratios; deeper search widened the teacher’s measured advantage. Distillation was separate from primary self-play training.Source: §4.3.8 · p. 13

4.3.9 Decision

  • The assembled design retains the convolutional trunk, periodic global context, from-to policy, compact WDL head, auxiliary training objectives, and quantization-aware residual blocks.Small models serve early self-play before a medium candidate trains on the same replay; the larger stage remains unresolved, and final playing strength belongs to the assembled system rather than isolated components.Source: §4.3.9 · pp. 13–14, Figure 8 · p. 14

5 From inference speed to learning speed

Under a fixed compute budget, inference speed matters only insofar as the complete system turns it into more useful self-play and training. The section develops that throughput chain from native search and inference through replay delivery and actor scheduling.

5.1 Native ownership of the search loop

  • Native search avoids per-position Python dispatch, while actors interleave games and retain search subtrees to overlap tree traversal with neural evaluation.The retained setup uses four actors per GPU, batches up to 320 positions, and two outstanding batches per actor.Source: §5.1 · p. 14

5.2 Batching and host-side submission

  • In a controlled 32-process workload, the optimized path raised search throughput 20.5% and cut aggregate actor CPU use from 52.6 to 19.8 cores.With a 24-core CPU limit, throughput more than doubled as reduced submission overhead kept GPUs busy.Source: §5.2 · p. 14
  • Reducing TensorRT actors from four to two per GPU cut search throughput 39%, despite full batches; process-level concurrency with one inference thread per actor was supported.Additional inference threads duplicated CUDA contexts and fragmented batches.Source: §5.2 · p. 14

5.3 Inference runtimes and precision

  • TensorRT FP16 delivered 1.86x TorchScript BF16 inference throughput, while quantization-aware INT8 added 1.31x over FP16 on the tested network.Production-topology INT8 gains were 14.4% for the smaller network and 39.1% for the medium network; most trunk convolutions ran in INT8.Source: §5.3 · p. 14
  • The alternative torch.compile path improved eager batch-64 inference roughly 27–33%, but reduced throughput about 18% in the eight-GPU training workload and was not retained.Fused TorchScript remained faster than compiled inference in the tested comparison.Source: §5.3 · p. 14

5.4 Replay materialization and training supply

  • Compacting 5,000 producer shards into 25 containers made a 2.5-million-row loader benchmark 8.26x faster and put delivery capacity 44% above measured trainer demand.In a live interval, materialization appended positions more than six times as fast as self-play supplied them.Source: §5.4 · p. 15

5.5 Overlapping self-play and training

  • Keeping all 32 actors active nearly doubled trainer work time for only a small reduction in the complete cycle; the retained policy kept half active during training.Table 3 covers optimizer throughput and concurrent search.Source: §5.5 · p. 15, Table 3 · p. 15

5.6 Throughput allocation within the learning loop

  • Native search and batched inference increase game supply, replay materialization prevents delivery from limiting training, and actor overlap replenishes replay during updates.The integrated system allocates throughput across data generation and optimization rather than maximizing either in isolation.Source: §5.6 · p. 15

6 Three failures that changed the method

Three failures revealed dependencies that local metrics missed: late-game targets affected learning, TensorRT refitting could change deployed predictions, and loss-based promotion could select a weaker player. The corrections and their limits are documented as parts of the learning process.

6.1 Late-game target poisoning

  • Excluding late-game tails and reducing their search budget removed endgame-conversion examples; weak conversion then produced more capped games with unreliable targets.At the most affected interval, approximately one ply in seven was ineligible for training, 27–32% of games reached the cap, and 36–38% of admitted rows inherited a cutoff target.Source: §6.1 · pp. 15–16
  • A dedicated full search at the actual cutoff supplied a root-value and searched-policy target, restoring searched endgame positions; conversion recovered after concurrent changes whose individual effects were not isolated.The earlier target study favored searched values over material, but compared target estimators rather than the complete conversion repair.Source: §6.1 · p. 16, Figure 10 · p. 16

6.2 Prediction drift under TensorRT refitting

  • A TensorRT refit could report success yet change predictions when equal template scales were later refit with unequal scales under optimization level four or higher.On 516 positions, legal-policy KL divergence was approximately 1.05; separating scales or lowering optimization reduced it to approximately 0.0012 and restored deterministic refitting.Source: §6.2 · p. 16

6.3 Promotion from incomparable training losses

  • Training-loss promotion selected a candidate approximately 270 Elo weaker, because extra catch-up training gave it more optimizer quanta on the same replay distribution.Promotion now requires at least 0.48 in two consecutive paired matches against the active deployment artifact.Source: §6.3 · p. 16

7 Training progress under limited compute

The final run trained a 6.32-million-parameter model for 2.5 days, and the final recipe reached higher playing strength within the reported training window. The chapter tracks training volume and model transition alongside that progression.

7.1 Progress across training campaigns

  • The final recipe reached higher playing strength within the reported training window across the five 64-search campaign ladders.Those curves use 64 searches per move; the final model’s benchmark result was 3,251 Elo at 100,000 searches per move.Source: §7.1 · pp. 16–17, Figure 11 · p. 17
  • The larger progression across campaigns reflects successive changes to architecture, data generation, and training efficiency.Additional MCTS search improves move selection using the trained network without further training.Source: §7.1 · p. 17

7.2 Training volume and model transition

  • The run estimates approximately 100 billion search simulations from 209 million materialized positions and an assumed average of 500 fresh simulations per position.The multiplier is an accounting assumption, not an independently measured average; Table 4 summarizes the final run.Source: §7.2 · p. 17, Table 4 · p. 17
  • Across the 12×128-to-14×160 transition, median trainer throughput fell from about 17.0 thousand to 11.2 thousand samples/s as search rose from 300 to 600 visits per move.The configured 800-visit stage lies beyond the selected checkpoint; replay expanded and the learner received approximately four presentations per admitted position.Source: §7.2 · pp. 17–18, Figure 12 · p. 17
  • The reported checkpoint was selected near the strongest region of the training ladder; a function-preserving 19×176 continuation recovered parity but established no higher plateau.The final reported player remained on the successful small-to-medium path.Source: §7.2 · p. 18

8 Playing strength and model compression

The model’s playing strength rose substantially with deeper search, while a distilled student retained considerable strength at a much smaller size. The reported search curve reflects deployed settings that also change leaf parallelism.

8.1 Strength across search budgets

  • 1,658 Elo policy-only strength rose to 3,251 Elo at 100,000 searches per move, a gain of 1,593 points.The final tenfold increase in search added 137 Elo, less than the increases at shallower budgets.Source: §8.1 · p. 18
  • The two opponent-based estimates at 100,000 searches differ by only four Elo, while estimates at shallower budgets are farther apart.The evaluation curve uses one leaf at 100 and 1,000 searches, four at 10,000, and sixteen at 100,000.Source: §8.1 · p. 18

8.2 Distilling a smaller player

  • The distilled student, with approximately 470 thousand parameters (13.4 times fewer than its teacher), rose from 2,697 to 2,873 Elo when search increased from 10,000 to 100,000.It trained for 110,000 optimizer steps on a frozen 20-million-position replay snapshot.Source: §8.2 · p. 18
  • The distilled student retained substantial playing strength, but remained behind the teacher even with deeper search.The smaller model’s search-budget results are presented in the distilled-student strength table.Source: §8.2 · p. 18, Table 5 · p. 18

9 Limitations and open questions

The study’s limitations center on component attribution, scaling, rating calibration, evaluation scope, and workload-dependent costs. Most component tests were economical screening experiments, and the final benchmark does not isolate every design choice or generalize automatically to other settings.

9.1 Attribution and scaling

  • Most component experiments used a single seed, short continuation, or frozen replay, limiting attribution of independent final-strength gains.Policy-head and global-context comparisons also include qualitative observations rather than complete matched evaluations.Source: §9.1 · p. 18
  • Progressive sizing and replay growth couple capacity, training history, self-play cost, data exposure, and fresh-game demand; matched-compute experiments are needed to separate effects.The attribution problem is strongest for these coupled choices.Source: §9.1 · pp. 18–19

9.2 Persistent plateaus and the remaining engine gap

  • Continuation experiments showed similar strength plateaus at 64 and 400 searches per move; further training may yield tens, not hundreds, of Elo.Closing the roughly 400-Elo gap to the upper end of the historical Stockfish 13 calibration would likely require changes to the training recipe.Source: §9.2 · p. 19

9.3 Rating calibration and evaluation scope

  • The benchmark uses a published fixed-node Stockfish 13 calibration, and each final match contains 100 games; broader opponents and more games could clarify calibration and matchup effects.The reported intervals capture match sampling uncertainty with calibration anchors held fixed, and agreement between opponent rungs is weaker at shallow budgets.Source: §9.3 · p. 19
  • The search-budget curve combines deeper search with increased parallelism, so it measures deployed operating points rather than isolated search-depth effects.Backend differences also enter policy-only, searched, and student evaluations.Source: §9.3 · p. 19

9.4 Workload dependence and development cost

  • Rejected optimizations depended on workload: exact cache reuse did not offset overhead in diverse self-play, while adaptive stopping barely shortened a GPU-bound cycle.Repeated analysis may offer more cache reuse; actor-trainer overlap limited adaptive stopping’s cadence gain.Source: §9.4 · p. 19
  • The $43.20 rental cost covers only the final training run, excluding development experiments and evaluation; reproduction may vary with contention, drivers, and TensorRT versions.The configuration, published model, and evaluation protocol define the comparison, while exact weights and timing may vary across executions.Source: §9.4 · p. 19

10 Conclusion

An integrated AlphaZero-style system trained from random initialization on one eight-GPU node for 2.5 days and reached 3,251 benchmark Elo at 100,000 searches per move. Its reported strength reflects the combined recipe, while scaling beyond the observed plateaus remains open.

10 Conclusion

  • 3,251 benchmark Elo at 100,000 searches per move, versus 1,658 benchmark Elo without search, came from a 6.3-million-parameter model trained for 2.5 days on one eight-GPU node.The evaluation was against a fixed-node Stockfish 13 ladder.Source: §10 · p. 19
  • The recipe combines a compact structured policy head, progressive small-to-medium sizing, targeted restart states, prioritized replay, INT8-capable architecture, native search, batched TensorRT inference, and distributed training.The authors frame the result as strength achievable by this integrated recipe within the available compute budget.Source: §10 · p. 19
  • Local optimizations did not always improve the learning loop: cache reuse added overhead, while endgame removal corrupted value targets, TensorRT refits altered predictions, and loss-based promotion chose a weaker player.The findings connect efficiency with the quality of data and models consumed by self-play.Source: §10 · p. 19
  • The larger model recovered its parent’s strength without surpassing it during the available continuation, and the much smaller distilled model did not match its teacher.The observed plateaus point toward recipe changes for substantial improvement; larger models, deeper self-play search, lower reuse, and broader replay remain hypotheses to test against strength per compute.Source: §10 · p. 19

A Training diagnostics

The diagnostics track the training sequence for checkpoint 1026, its losses and gradients, and rating trends across training. They also report game counts, position volume, and trainer throughput for the run.

A Training diagnostics

  • Checkpoint 1026 represents 408,500 optimizer steps and 836,608,000 presentations; it was selected near the strongest 64-search ladder region with full training and deployment artifacts retained.The plotted sequence excludes reverted INT8 conversion, invalid capacity promotion, and subsequent larger-model continuation.Source: A Training diagnostics · p. 20
  • The diagnostic plots show total loss reaching approximately 2.95, WDL loss near 0.80, and learning rate declining from approximately 0.10 to 0.0266; mean gradient norm rose above the 1.0 limit during medium-model training.Individual optimizer steps were clipped before application; the loss plots mark the small-to-medium transition at 240,000 optimizer steps.Source: Figure A.1 · p. 20, Figure A.3 · p. 20
  • The run completed 3,249,647 games and materialized approximately 209.15 million net positions, with median throughput of 16,977 samples/s for small-model quanta and 11,194 for medium-model quanta.The run’s node rental totaled $43.20.Source: A Training diagnostics · p. 20
  • Policy-only and 64-search ladder ratings both improved over the final 2.5-day window, while separate final matches are reported in Table 1.Next-policy and remaining-game-length losses are plotted on separate scales.Source: Figure A.2 · p. 20, Figure A.4 · p. 21

B Evaluation detail

The evaluation combines fixed-node Stockfish matches with targeted controls of architecture, replay, and search reuse. It reports student strength at two search budgets and tests whether local efficiency gains improve the broader training loop.

B.1 Fixed-node match protocol

  • The fixed-node protocol used 100 games per match from 50 colour-swapped openings, and benchmark Elo was calculated against the tested opponent anchor nearest a 0.5 score.Intervals bootstrap the 50 opening pairs; they quantify match-sampling uncertainty, not uncertainty in the historical calibration.Source: §B.1 · p. 21
  • At 100,000 searches, the harder and easier opponents implied ratings only 4 Elo apart, though the matches cannot identify the source of earlier discrepancies.The difference between opponent-implied ratings narrowed from 128 Elo at 100 searches to 4 Elo at 100,000; draw behaviour, calibration error, matchup effects, and sampling variation could contribute.Source: §B.1 · p. 21

B.2 Student matches

  • At 100,000 searches, the student scored 2,873 [2,819, 2,935] Elo against Stockfish 13 at 20,000 nodes, anchored at 2,700 benchmark Elo.The 100-game match produced a 59/28/13 W/D/L record; the 10,000-search match scored 2,697 [2,640, 2,753] Elo.Source: §B.2 · p. 21

B.3 Thinking-time estimate

  • The under-five-second estimate for 100,000 searches extrapolates from TorchScript timing and TensorRT speedup; it is not a measured latency.The estimate assumes inference acceleration transfers sufficiently to overall search.Source: §B.3 · p. 21

C.1 Architecture shape and inference throughput

  • The 112- and 120-channel CNNs served fewer positions per second than width 128 despite doing less arithmetic, showing width alone poorly predicts inference cost.The width sweep compared measured throughput with the inverse-width-squared arithmetic estimate.Source: §C.1 · p. 22, Table C.1 · p. 22
  • The 20×128 model was faster than 14×152 at batch 512 but slower at batch 64, while the best Smolgen cell traded lower held-out loss for slower inference and higher memory use.Smolgen reduced held-out loss by 0.0090 nats versus the parameter-matched from-to CNN, but reached 36.1% and 45.8% of the dense CNN's batch-512 and batch-64 forward rates, with 5.17× its peak training memory.Source: §C.1 · p. 22

C.2 Replay-reuse controls

  • Reuse ratios 4, 6.25, and 8 showed comparable strength at shared evaluation boundaries; the retained ratio of four favoured fresh self-play data.Long-run effects were coupled to replay capacity, optimization, and inference changes, while schedule events advanced at quantum boundaries.Source: §C.2 · p. 23

C.3 Negative search and reuse controls

  • The learned pre-search allocator captured about 23% of available deep-policy-divergence improvement but trailed online training by roughly 60–100 ladder Elo; measured graph and inference reuse did not offset their costs.Exact graph search was 8.63% and 8.28% slower at 1,000 and 10,000 searches, while its neural-evaluation savings were 0.0249% and 0.1769%; the bounded cache hit rate was 0.970%.Source: §C.3 · p. 23

C.4 Throughput benchmarks

The appendix reports throughput benchmarks, late-training strength comparisons, and the recipe and interfaces used for the experiment. It distinguishes the released configuration from the frozen record of the reported run.

C.4 Throughput benchmarks

  • Compacting 5,000 replay shards into 25 containers increased loader throughput from 3,943 to 32,579 samples/s, while the eight-GPU trainer processed 6,252 samples/s under concurrent self-play.Separate measurements reported 512,679 to 617,782 aggregate searches/s in the 32-process benchmark and 75,889 versus 40,716 positions/s for TensorRT FP16 versus TorchScript BF16.Source: §C.4 · p. 23

C.5 Late-training strength

  • The 64-search estimate rose 16.0 Elo between the first and last checkpoints, but 400-search matches showed no sustained gain; a late continuation changed by 3.0 Elo over 9.2 hours.The continuation means were 2,373.7 Elo for the first 14 observations and 2,376.7 for the last 14, supporting diminishing returns rather than proving further improvement impossible.Source: §C.5 · pp. 23–24, Table C.4 · p. 24

D.1 Network input and output contract

  • The network input is a 52×8×8 tensor, and the policy head maps legal moves into 1,880 action logits while the value head predicts win, draw, and loss probabilities.Training-only heads predict the next searched policy and remaining game length; inference returns the primary policy logits and WDL probabilities.Source: §D.1 · pp. 24–25

D.2 Configuration and reported result

  • The maintained expanded configuration supports new training runs, while replication of the reported experiment requires its frozen source revision, resolved configuration, manifest, checkpoints, engines, and datasets.The published checkpoint fixes the model used for the reported results.Source: §D.2 · p. 25

D.3 Expanded chess recipe settings

  • The recipe used a progressive 12×128, 14×160, and 19×176 residual-CNN ladder, with the reported checkpoint from the 14×160 stage.It used a from-to policy head, WDL head, discounted outcome targets, and deployment-copy folding, recalibration, and TensorRT refitting.Source: §D.3 · p. 25

D.3 Expanded chess recipe settings; D.4 Self-play schedules and promotion

  • Self-play used 32 actors and restart states filtered by remaining game length, root value, and leading-action visit mass; replay sampling mixed uniform selection with policy-surprise prioritization.Restart selection was 30% uniform and otherwise weighted by the square root of value correction; each admitted position funded four training presentations.Source: §D.3 · p. 25, §D.4 · p. 25

D.4 Self-play schedules and promotion

  • Successor promotion required a score of at least 0.48 in two consecutive paired evaluations, with candidate training triggered by stage-specific thresholds for smoothed 64-search ladder gains.Monitoring used 50 paired openings, an adaptive three-rung Stockfish 13 bracket, and both 64-search and policy-only play.Source: §D.3 · p. 25, §D.4 · p. 25

D.5 Result identity and provenance

The appendix records provenance and reproduction requirements for the experiment. It distinguishes public software and artifacts from the complete materials needed to reproduce the reported results exactly.

D.5 Result identity and provenance

  • The public recipe and model support inspection and a new run, but exact-match reproduction is not yet self-contained because key source, archive, and evaluation inputs remain local.The release identifies a published INT8 ONNX artifact and immutable model-repository revision, while the frozen training revision, resolved configuration, large run archives, and some evaluation inputs remain in the local result archive.Source: §D.5 · p. 26

D.6 Reproducing the software

  • The source release and final model artifacts are MIT-licensed, while external dependencies, reference sources, and third-party data retain their own terms.The source release includes setup and validation instructions for installing locked dependencies, building the extension, and verifying pinned engines.Source: §D.6 · p. 26

D.7 Reproducing evaluation

  • Matched evaluation requires the published checkpoint and inference artifact, paired opening suite, opponent settings, search budget, runtime configuration, and adjudication rules.Re-exporting with a different toolchain can change predictions and constitutes a new deployment comparison; throughput regimes also require separate benchmarks.Source: §D.7 · p. 26

D.8 Reproducing plots and tables

  • Plots and tables are generated from archived data with extraction methods retained, allowing independent recomputation of rates, Elo estimates, and uncertainty intervals.The underlying columns support recomputation independently of live dashboards.Source: §D.8 · p. 26
Loading 2609.37447v1…