Manaka architecture

Manaka is a CPU-first shogi evaluator built around one constraint: the state before the head must be expressible as sums of per-token contributions, so a move can update the evaluator by adding and subtracting only what changed.

The engine and trainer share the MNW1 weight format. The current format is version 5; the authoritative shape definition is crates/manaka-core/src/params.rs and its name grammar is shape.rs.

Core idea

A position is converted to tokens and maintained in two perspectives. For the native token space, a token identifies piece kind, owner and square; hand pieces use unary states.

position
  → tokens
  → incrementally maintained aggregates
      power sums / symmetric polynomials
      optional pair table
      optional second moments
      optional square fields
  → W1 → ReLU [→ optional W2 → ReLU]
  → value
  → policy + moving-piece term + optional destination-field term

The accumulator is cheap to update because every enabled block is still a sum over tokens. Everything after the sum runs in full at every evaluated node.

Default/baseline shape

The historical baseline is pair16_d128_o3_h512:

• embedding width d=128;
• symmetric-polynomial order o=3;
• hidden width h=512;
• full-rank pair table width pair=16;
• no second hidden layer, moments or square field.

It has about 45.8M parameters, most of them in the pair table. Current absolute speed belongs in the benchmark, not in this design page.

Aggregation blocks

Power sums

For token embedding e(z), the accumulator keeps

p_k = Σ e(z)^k

and reconstructs elementary symmetric polynomials with Newton's identities. This gives higher-order permutation-invariant interactions while preserving incremental updates.

split changes only the aggregation boundary: each perspective computes separate power sums for its own pieces and the opponent's pieces, while still sharing the embedding parameters. It is currently defined only for the native token space.

Pair table

pairN adds a learned vector for every unordered token pair and sums the active rows. This is the dominant capacity block in the baseline. pair0 disables it.

lseN reallocates the last N pair channels to log-sum-exp readout. The table width and update traffic do not grow; the exponential is baked into the exported table and the engine takes the logarithm at readout.

ks additionally exposes the magnitude discarded by RMS normalization.

Optional blocks

shape token	block	purpose
h2N	second hidden layer	extra head depth
mN	second moments Σ vvᵀ	cross-channel interactions
fN	square field Σ K[token,s]	preserve square-addressed context

These knobs are independently switchable and cost extra per-node arithmetic. Their measured architecture effects are summarized in network history.

Feature spaces

features is separate from the arithmetic above.

suffix	input space
none	Manaka native tokens
kp	YaneuraOu-compatible KP
halfkp	YaneuraOu-compatible HalfKP

KP/HalfKP are experimental controls for measuring the value of NNUE-style features. Their current validation results are in the 2026-08-26 record.

HalfKP needs special handling on king moves because the own-king square is part of every feature id. The accumulator must be rebuilt when that king moves; a four-token delta is insufficient.

nnue arithmetic

The nnue suffix switches from Manaka's normal arithmetic to an export-compatible NNUE form: no RMS norms, clipped hidden activations, and linear value output. It is intentionally restrictive and accepts only shapes that can be represented by the NNUE export path.

Feature space and arithmetic are independent: kp selects numbering, while nnue selects the forward-pass form.

Policy and value

The value head reads the final hidden vector and produces one scalar.

The policy uses the common 2,187-label move space and combines:

1. a label-specific row dotted with the hidden vector;
2. policy_from, which lets the score depend on the moving piece and origin;
3. when field_dim > 0, a destination-square field term.

This corrects the earliest prototype's main policy limitation, where a label could not distinguish which piece was moving.

What is deliberately not here

• Historical speed tables: benchmark.
• Why particular knobs were proposed and whether they helped: network history.
• The older structural diagnosis: architecture critique.
• Training commands: training.

Keeping those concerns separate avoids making the architecture page stale whenever a benchmark or experiment changes.