Solving 7×7 Killall-Go Opening JA on a Single RTX 5090

A Reproduction and Cross-Generation Benchmark of the NeurIPS 2023 Online Fine-Tuning Solver — Technical Report v0.1

Date: 2026-07-17 / Status: v0.1 public technical report(英訳版は準備中)

Abstract (EN)

We reproduce the distributed Killall-Go solver of Wu et al. (NeurIPS 2023, Game Solving with Online Fine-Tuning) natively on WSL2 without Docker, on a single consumer machine (RTX 5090 / Blackwell sm_120, Core Ultra 9 285K), and solve the 7×7 Killall-Go opening JA, proving the same verdict (loss — White cannot secure life; Black captures all of White’s stones) as the authors’ recorded run on 12× GTX 1080Ti with 384 worker slots. Because the code, problem, model, and configuration family are held fixed, the two runs form a clean cross-generation systems benchmark: per-slot node throughput improved 2.00× (284 vs 141.3 nodes/s/slot), and the total search effort required fell to 0.59× (1.011B vs 1.728B job nodes), which we attribute primarily to a 19× higher online model-update frequency (4,007 vs 208 broadcasts) enabled by colocating the trainer on the same GPU. Combined per-slot effective productivity is ≈3.4×. We additionally solve all 37 EASY-small problems, document a GHI-conditional proof case (EASY-44) and its resolution via PCN-threshold decomposition, and analyze a cudart symbol-interposition crash specific to CUDA-13 libtorch builds on multi-toolkit hosts. All patches (36 lines total), scripts, and result artifacts are included or archived.

要旨(JP)

NeurIPS 2023のオンライン微調整ソルバをDocker非使用でWSL2上にネイティブ再現し、単一のRTX 5090で7×7 killall-go開局JAを完全求解した(判定 loss = 白が活き(無条件活き/セキ)を作れず黒が全消し、原著実測と一致)。コード・問題・初期モデル・設定系を固定したまま計算基盤だけが2017年世代(1080Ti×12/384スロット)から2026年世代(5090×1/24スロット)に替わったため、世代間システムベンチマークとして読める: スロット当たりノード処理は2.00倍、必要探索量は0.59倍(モデル配信頻度19倍の寄与と考える)。EASY-small全37問の証明、GHI条件付き証明の事例分析、CUDA 13世代libtorch特有のcudartシンボル横取りクラッシュの解析を含む。

1. 背景

killall-go(全消し碁)とは: 囲碁の非対称ルール。黒が攻撃側で、白石を全て取り切れば(全消し)勝ち — 攻める方が難しいため黒は最初に2手連続で着手するハンデを持つ。白が防御側で、無条件活き(Benson)またはセキ(双活)を達成すれば勝ち。地は数えず「黒は白を全部取れるか?」という二値の生死問題で、盤が小さく本物の囲碁ルール(取り・コウ・セキ・生死)を保つため厳密求解のベンチマークに向く。本レポートの判定 loss は白から見た負け=白が活きを作れず黒が全消し(黒の勝ち)、を指す。

2. 実験設定

項目 本走行 参照実測(上流docs記載)
GPU RTX 5090 32GB(sm_120)×1 GTX 1080Ti ×12(2〜3ホスト)
CPU Core Ultra 9 285K(24C) Xeon世代(詳細は原典参照)
ワーカスロット 24(1プロセス) 384(7g384w+1sp1op)
トレーナ 同一GPUに同居(zero_server+sp+op) 専用GPU
manager木上限(SIM) 2.5e6 1e7
PCN閾値 16.5(同一) 16.5
worker設定 sim=1e5, situational superko, RZone+block TT+GHI check(同一) 同一
初期モデル gpcn_n32_m16_empty_op:100000(リポジトリ同梱、同一) 同一
ソフトウェア libtorch 2.11.0+cu130 / CUDA 13.2 toolkit / gcc 13.3 / WSL2 当時のコンテナ環境
コード neurips2023 @ df2d80c + 3パッチ(計36行、patches/) 同一ベース

RAM 53GB(WSL上限)に対する配分実測: manager 26GB(木2.5e6設定時)+ worker(24並列)16.8GB + trainer系2GB。スワップ退避はコールドページに限られ探索速度への影響は観測されなかった(swap-in ≈ 0)。

3. 再現性の検証

  1. 参照問題2問(上流docs記載): status/rzone一致を3つのlibtorch世代(2.8.0+cu128 / 2.9.1+cu130 / 2.11.0+cu130)で確認。1 40c1cffff 1114±2 / -1 21c3fff 214 — 上流docsの.jobs例に現れる値(40c1cffff 1114)とも一致
  2. EASY-small 37問: 全問証明。36問はデフォルト設定でwin(計1,901秒)。EASY-44のみルートPCN値(16.245)が閾値以下で丸ごと1ジョブ投入され、GHI(コウ経路依存)注釈付き証明が返り、managerは誠実に「?」(virtual solved)を報告。PCN閾値を16に下げ木分解を強制すると局所解決されwin確定(644ノード/146ジョブ/24.8秒)— 求解器がコウ経路条件付き証明を無条件winと混同しない設計の実証
  3. JA本走行: 判定lossが原著実測と一致

4. JA本走行の結果

指標 本走行 参照実測 比
判定 loss(白が活き作れず=黒の全消し) loss 一致
壁時計 148,879 s(41.4 h) 32,105 s 4.64倍遅
managerツリー 1,194,363 1,413,138 0.85×
総ジョブ 241,415 281,648 0.86×
ジョブ総ノード 1,011,351,341 1,728,286,526 0.585×
ジョブ総時間 3,560,612 s 12,227,753 s 0.29×
平均ジョブ時間 14.75 s 43.42 s 0.34×
nodes/s/slot 284.0 141.3 2.01×
モデル配信(load_model) 4,007 208 19.3×
微調整世代(200step毎) 4,013(最終step 902,400) — —
unsolvedジョブ率 0.2%前後 — —

5. 性能分解

壁時計比 4.64× は次のように分解できる:

(参照スロット数/本スロット数) ÷ (スロット当たり実効生産性比)
= (384/24) ÷ (2.01 × 1.71)
= 16 ÷ 3.44 ≈ 4.65   ✓(実測4.64×と整合)

6. 考察

6.1 更新頻度とノード削減。 本走行はトレーナを求解と同一GPUに同居させた結果、モデル配信が参照実測の19倍の頻度(約37秒に1回)となり、必要ノードが41%減った。これは「オンライン微調整の効果は更新頻度でスケールする」ことの観察証拠と考える。ただしワーカ数(24 vs 384)の違いによる投機ジョブ減と交絡しており、寄与の分離には制御実験(§8)が要る。総ジョブ数の減少(0.86×)よりノード減(0.585×)が大きいことは、ジョブ数だけでなく個々のジョブが浅く済んだ(平均4,189 vs 6,136ノード)ことを示し、更新頻度説と整合する。

6.2 managerツリーとRAM。 走行中のmanager RSS+swapからのツリー占有推定は最終実測(1.19M)を大きく過大評価した(TT・断片化の混入)。容量計画には.statの実測木サイズを使うべきである。参照実測の木(1.41M)も本走行の木(1.19M)もSIM=2.5e6以下であり、この開局はSIM=2.5e6で足りる(原著設定1e7は保守的)ことが分かった。

6.3 cudartシンボル横取り(工学的知見)。 CUDA 13系libtorch(cu130)のバイナリは、システムに別マイナー版のCUDAツールキットが存在すると、実行ファイル側がリンクするシステムlibcudart.so.13がlibtorch同梱cudartのシンボルを乗っ取り、WSLドライバのPTX JIT内でSIGSEGVする。cu128世代で顕在化しなかったのは要求soname(.so.12)がシステム側と偶然同版だったため。対策は同梱cudartのLD_PRELOAD(+libディレクトリへの正名symlink)。詳細はBuild Notes。

7. 妥当性への脅威(Threats to Validity)

  1. 単一走行: JAは1回のみ。探索は並列非決定であり、時間・ジョブ数には走行間分散があるはず(参照問題レベルではノード数±2程度の揺らぎを確認)
  2. CPU交絡: nodes/s/slotはCPU探索+GPU推論の混合値。さらにスロット当たりCPU配分が本走行は参照の約2倍(16スレッド/24games vs 16スレッド/48games)。「GPU世代比2.01×」ではなく「リグ世代比」と読むべき
  3. 参照値の出典: 比較主行は上流docsに記録された実測であり、論文本文Table(JA ONLINE-CP: 22,384s/1.29Bノード)とは条件(ワーカ数・top-k)が異なる。論文Tableとの直接比較はしていない
  4. 設定差: SIM(2.5e6 vs 1e7)とトレーナ同居/専用の差がある。判定の同一性には影響しない(証明は証明)が、性能数値の解釈には注意
  5. 測定系: ジョブ数・ノード数はソルバ自身の.stat/.jobsに依拠(独立検証はしていない)

8. 今後の実験計画

  1. セキ(双活)DB導入 → 同一JA再求解: 「5090+セキDB vs 1080Ti+セキなし」の二軸比較で、ハード寄与とアルゴリズム寄与を一つの開局上で分離する(本レポートのベースラインがその片翼)
  2. 更新頻度の制御実験: 同一ワーカ数で配信間隔だけ変えた走行により§6.1の交絡を解く
  3. RZコーパス: 本走行で得た241,415ジョブのRZone注釈はRZ縮小研究(arXiv 2510.00689)の検証素材となる
  4. CGTハイブリッド: workerプロトコル(+ id sgf / id status rzone nodes ghi)は疎結合であり、Alberta系CGTソルバを異種ワーカとしてbroker混在登録できる

9. 成果物

場所 内容
本リポジトリ パッチ、スクリプト、結果表、JA .stat、本レポート、BUILD_NOTES(全記録)
ローカルアーカイブ(E:\go\JA_results) 証明木SGF(756MB)/7esgf(843MB)、全ジョブログ(78MB)、managerログ、微調整モデル全4,013世代(393GB)、自己対戦棋譜コーパス(13GB/4,013ファイル)、学習曲線(op.log)

成果物の入手(Availability)

10. 再現手順(要約)

git clone --recursive --branch neurips2023 https://github.com/rlglab/online-fine-tuning-solver
cd online-fine-tuning-solver && git apply ../patches/*.patch
# libtorch 2.11.0+cu130 を配置し、シンボル横取り対策(BUILD_NOTES参照)を適用
cmake -B build/killallgo -DCMAKE_BUILD_TYPE=Release -DGAME_TYPE=KILLALLGO \
      -DCMAKE_PREFIX_PATH=<libtorch> -DCUDAToolkit_ROOT=/usr/local/cuda-13.2
make -C build/killallgo -j
# 分散構成の起動・JA投入コマンドはBUILD_NOTES.mdの運用メモ参照

引用