You don't need to know anything about Go to read this. The game is just the fixed yardstick. The story is a hardware benchmark: the same program, the same problem, the same settings — only the machine changed, from a 2017 GPU cluster to a single 2026 graphics card. That makes it a rare clean measurement of one decade of progress.
What "solving" means here
There are two very different things a computer can do with a board game. It can play it well — that's what AlphaGo did. Or it can solve it: mathematically prove the outcome under perfect play from both sides, leaving no doubt. Solving is the hard one. You explore an enormous tree of "if I play here, they play there…" move sequences until you have an airtight proof. Each node in that tree is one position examined.
The target here is a single 7x7 opening called JA. In 2023, a NeurIPS paper (Game Solving with Online Fine-Tuning, Wu et al.) proved its verdict — that White cannot survive (Black captures everything) — using a cluster of twelve GTX 1080Ti GPUs running 384 parallel workers. The solver is guided by a neural network that estimates how hard each branch is, and crucially that network is fine-tuned online — it keeps learning during the solve.
I rebuilt that exact solver (same code, same problem, same initial model, same search settings) and ran it on one RTX 5090. It reached the identical proof. Everything but the hardware was held fixed, so the two runs line up as a generation-vs-generation benchmark — and it doubled as a full shakedown of the new Blackwell workstation.
What is killall-go?
Killall-go is the Go variant used here, and it has a deliberately lopsided goal — which is what makes it clean to solve. The two sides want opposite things. Black is the attacker: it wins only by capturing every White stone — hence "kill-all." White is the defender: it wins by keeping its stones alive, either as an unconditionally living group or as seki (a mutual-life standoff). Because wiping the board is harder than merely surviving, Black gets the handicap — it plays the first two moves in a row. Nobody counts territory; the whole game reduces to one yes/no question: can Black capture all of White, or does White survive?
That binary verdict, on a small 7x7 board that still obeys the full rules of Go (captures, ko, seki, life-and-death), is why solvers like it: the answer is a provable fact, not a score. In the table below, loss is written from White's (the defender's) side: White cannot secure life or seki, so Black captures all of White and wins.
The numbers
1x RTX 5090 (2026) 12x GTX 1080Ti (2017) ratio
Worker slots 24 384 1/16 the parallelism
Per-slot throughput 284 nodes/s 141 nodes/s 2.01x faster
Search work to proof 1.01B nodes 1.73B nodes 0.59x (41% less work)
Avg work per sub-job 4,189 nodes 6,136 nodes shallower proofs
Live model updates 4,007 208 19.3x more
Wall-clock time 41.4 h 8.9 h 4.64x slower
Verdict loss (proven) loss identical
The single card finished slower in wall-clock time (41 h vs 9 h) — but it was doing it on 1/16 the parallel hardware and, notably, it needed 41% less total search work to get there.
What the numbers say
The wall-clock gap decomposes almost exactly:
wall-clock ratio = (slot ratio) / (per-slot effective productivity)
4.64x = 16x / (2.01x speed x 1.71x less work)
4.64x = 16x / 3.44x ✓
Two independent things improved, and they multiply:
- 2.01x raw throughput per slot. This is the hardware-and-toolchain generation talking (Blackwell + CUDA 13 vs Pascal-era). Caveat: this figure mixes CPU tree-search with GPU inference, and my rig also gave each slot about twice the CPU budget — so read it as rig-generation, not pure GPU-generation.
- 1.71x less search needed (1.73B → 1.01B nodes). This is the more interesting one, because it isn't about speed — it's about the search getting smarter. Putting the trainer on the same GPU as the solver let a freshly fine-tuned model broadcast roughly every 37 seconds (4,007 times) instead of every ~2.5 minutes (208 times) on the cluster. Fresher guidance meant each sub-proof went shallower (4,189 vs 6,136 nodes per job). The takeaway: online fine-tuning's payoff scales with how often you can update the model — and colocation is what unlocks the frequency.
The honest caveat on that second point: fewer workers (24 vs 384) also means fewer redundant speculative jobs, so update-frequency and worker-count are confounded here. Separating them cleanly needs a controlled run at fixed worker count — which is exactly the kind of follow-up this baseline sets up. That's the real value of the exercise: one machine now does, on a desktop, what took a rack of GPUs in 2017 — slower on the clock, but on a sixteenth of the parallel hardware and with less total compute — and the run flushed out real integration bugs (including a CUDA-13 symbol-interposition crash) that only a full end-to-end proof would surface.
Full details
Method, per-run statistics, the performance decomposition, threats to validity, and the CUDA-13 crash write-up are in the full technical report (body in Japanese, English abstract at the top). It reproduces the solver from Wu et al., Game Solving with Online Fine-Tuning (NeurIPS 2023) and the rlglab/online-fine-tuning-solver codebase — full credit to the original authors; this work only swaps the hardware underneath and measures the difference.
