アーキテクチャ
DLManaka は GPU を主対象にした将棋エンジンです。残差 CNN が方策と価値を出し、Gumbel AlphaZero MCTS がそれを使って探索します。長期的な推論対象は Apple silicon ですが、現在の学習と主要測定は CUDA が中心です。
ネットワーク
入力は 9×9 の二値特徴プレーンです。現在の構成は次の通りです。
- 3×3 の入力畳み込み
- squeeze-and-excitation(SE)付き残差ブロック
- 共通 2,187 着手ラベルへの方策ヘッド
- 1 値を出す価値ヘッド
よく測定している本番構成は 15ブロック × 256チャネル(b15_c256、約1,890万パラメータ)です。ネットワーク規模は設定値であり、ファイル形式に固定されてはいません。
Manaka と違い、DLManaka は差分評価を行いません。畳み込みは局所変化を周辺へ広げ、非線形層は加法性を壊し、SE は盤面全体を混ぜるためです。局面全体を毎回評価し、GPU バッチで速度を稼ぎます。
入出力
局面エンコードと着手ラベルの定義は Rust 側を正本とし、Python 側は学習に必要なサイズだけを共有します。方策空間は 27着手チャネル × 81マス = 2,187ラベル です。
ネットワークの出力:
- 方策ロジット — 全ラベルのスコア
- 価値 —
[-1,1]
学習では、方策は探索・教師分布との交差エントロピー、価値は最終結果 z と探索価値 q を混ぜた教師信号を使います。
探索
Gumbel AlphaZero MCTS は dl-manaka-core に実装されています。少ないシミュレーション数でも方策改善の教師信号を作りやすいため採用しています。
葉評価はバッチ化できます。ただしバッチ幅は シミュレーション数と一緒に調整する必要があります。大きすぎるバッチでは複数の探索経路が同じ待機中の葉へ衝突し、実際に増えるノード数や探索深さが減ることがあります。詳細は 探索設計 を参照してください。
ルートでは 1 手詰めを厳密に確認します。その他の探索上の制約はネットワーク定義ではなく探索ページに置きます。
実行経路
学習は PyTorch。現在の推論は ONNX を Rust / ONNX Runtime から CUDA で実行します。Apple silicon のバックエンド選択はアーキテクチャ前提ではなく、実測で決めます。
現在の CUDA 速度と推奨バッチ幅は ベンチマーク を正本とします。
リポジトリ構成
configs/ 学習設定
crates/dl-manaka-core/ エンコード、推論、探索
crates/dl-manaka-teacher/ 教師・自己対局シャード生成
crates/dl-manaka-selfplay/ 自己対局
crates/dl-manaka-usi/ USI エンジン
tideborn/trainer/ PyTorch 学習器
tideborn/tools/ データ整備、実行管理、測定主な学習モジュール:
| モジュール | 役割 |
|---|---|
network.py | 残差本体と各ヘッド |
losses.py | 方策・価値の損失 |
shards.py, data.py | データ読み込み |
train.py | AMP / DDP / 勾配蓄積 / チェックポイント |
checkpoint.py | 安全な保存・再開 |
export_onnx.py | チェックポイント → ONNX |
設計ルール
- ルール・局面・合法手・USI は chisaki を使い、再実装しない。
- 学習は PyTorch、対局生成・探索・推論統合は Rust に置く。
- エンコード定義は Rust 側を唯一の正本にする。
- 性能値はアーキテクチャページではなくベンチマークに置く。
- パラメータ数そのものを目的にせず、検証と対局測定で改善を判断する。
未解決事項
- Apple silicon で最適な推論バックエンドとバッチ特性。
- 教師・探索品質が変わった後も現在のネットワーク規模が最適か。
aux_valueを独立ヘッドとして使う価値があるか。