NNUE feature spaces in Manaka — four one-epoch runs
Measurement record, 2026-08-26. This experiment temporarily replaces Manaka's raw token space with YaneuraOu-compatible KP or HalfKP features to measure how much hand-designed cross-features buy.
Setup
Four runs crossed two feature spaces with two head widths:
| run | feature | network above accumulator |
|---|---|---|
pair0_d128_o3_h512_kp | KP | 768 → 512 + policy |
pair0_d128_o3_h512_halfkp | HalfKP | same |
pair0_d256_o1_h32_h232_kp | KP | 256×2 → 32 → 32 |
pair0_d256_o1_h32_h232_halfkp | HalfKP | same |
Each run used one A100, 268,800 steps × batch 1024 = 275,251,200 samples, one pass over the deduplicated corpus minus the holdout.
Validation results
| shape | val CE | top1 | top3 | top5 | value_sign |
|---|---|---|---|---|---|
KP d128_o3_h512 | 2.4744 | .3557 | .6293 | .7352 | .7135 |
HalfKP d128_o3_h512 | 2.5105 | .3493 | .6151 | .7229 | .6813 |
HalfKP d256_o1_h32_h232 | 2.9905 | .2617 | .4791 | .5832 | .6719 |
KP d256_o1_h32_h232 | 3.0677 | .2418 | .4572 | .5623 | .6958 |
For reference, the best raw-token result in the twelve-shape validation record was CE 2.6336 / top1 .3369. That comparison is indicative rather than controlled because those runs used 293,000 steps, about 9% more.
Conclusions
- Feature choice matters: at the wide head, KP improves both CE and top1 over the best token-space record.
- Head width matters much more: narrowing from 768→512 to 256×2→32→32 costs roughly 11 top1 points with KP, far larger than the KP/HalfKP difference.
- KP and HalfKP do not establish a stable ordering across both widths.
Search speed points the opposite way: the narrow KP shape reached 169,366 sims/s versus 32,785 for wide KP in the corresponding benchmark. That is the intended trade-off to test in games: weaker policy but roughly 5× more search.
Caveat: HalfKP search is not valid yet
A HalfKP id depends on the own-king square. When the king moves, all piece ids change, but Manaka's current MoveDelta updates only the moved tokens. Release search_speed therefore measures an incorrect incremental state for HalfKP. Treat HalfKP playing speed as unmeasured until king-move refresh is implemented.
Next measurement
Run the same weights in a Simulations = 0 round robin, then repeat with search enabled. Validation metrics alone cannot decide whether the extra search throughput compensates for the weaker policy.