DLManaka architecture

DLManaka is the GPU-first engine: a residual convolutional network produces policy and value, and Gumbel AlphaZero MCTS searches with those outputs. The long-term inference target is Apple silicon, while training and most measurements currently use CUDA.

Network

The input is a 9×9 stack of binary feature planes. The current family uses:

• a 3×3 stem convolution;
• a residual tower with squeeze-and-excitation (SE) blocks;
• a spatial policy head over the common 2,187 move labels;
• a scalar value head.

The commonly measured production shape is 15 blocks × 256 channels (b15_c256, about 18.9M parameters). Network size is a config choice, not a file-format constant.

Unlike Manaka, DLManaka does not support incremental evaluation. Convolutions spread a local change across neighboring squares, nonlinearities break additivity, and SE mixes information from the whole board. The engine therefore evaluates complete positions and recovers throughput through GPU batching.

Input and outputs

Position encoding and move labels are defined on the Rust side; Python keeps the corresponding sizes for training. The current policy space is 27 move channels × 81 destination squares = 2,187 labels.

The network emits:

• policy logits for all labels;
• value in [-1,1].

During training, policy uses cross-entropy against a sparse search/teacher distribution and value uses a blended target from game outcome z and search value q.

Search

Gumbel AlphaZero MCTS is implemented in dl-manaka-core. It was chosen because policy improvement remains meaningful at small simulation budgets, where conventional PUCT is less reliable.

Search can batch leaf evaluations. Batch width must be tuned together with simulation count: an oversized batch can cause many descents to collide on already queued leaves, reducing the number and depth of distinct nodes. The algorithm and invariants are documented in search design.

Exact mate-in-one handling is performed at the root. Other endgame/search limitations belong in the search document rather than the network definition.

Runtime paths

Training is PyTorch. Inference loads exported ONNX through Rust/ONNX Runtime on CUDA today; Apple-silicon backend selection remains a runtime/benchmark question rather than an architectural assumption.

Current CUDA speed and optimal batch widths are maintained in the benchmark. Historical hardware-bandwidth tables were removed from this page because they did not determine the actual batched-inference bottleneck.

Repository layout

configs/                    trainer configs
crates/dl-manaka-core/      encoding, inference, search
crates/dl-manaka-teacher/   teacher/self-play shard production
crates/dl-manaka-selfplay/  self-play driver
crates/dl-manaka-usi/       USI engine
tideborn/trainer/           PyTorch trainer
tideborn/tools/             data preparation, runs, benchmarks

Important trainer modules:

module	role
network.py	residual tower and heads
losses.py	policy/value losses
shards.py, data.py	data loading
train.py	AMP/DDP/accumulation/checkpoint loop
checkpoint.py	atomic save/resume
export_onnx.py	checkpoint → ONNX

Design rules

• Rules, positions, legal moves and USI plumbing come from chisaki rather than being reimplemented.
• Training stays in PyTorch; game generation/search/inference integration stays in Rust.
• Encoding has one source of truth on the Rust side.
• Performance claims live in benchmark pages, not architecture pages.
• Architecture changes are accepted only when validation and game-based measurements support them; parameter count alone is not a goal.

Open questions

• Best Apple-silicon inference backend and batch behavior.
• Whether the current network size remains optimal once teacher/search quality changes.
• Whether an auxiliary value target deserves its own head; the data format reserves aux_value, but no production head currently depends on it.