Manaka ベンチマーク
現在の絶対速度は 共通ベンチマーク を正本とします。このページには Manaka 固有の測定解釈とコマンドだけを残します。
現在の測定
360398d 時点。
学習
既定 d128_o3_h512_pair16:
| GPU | 最良バッチ | pos/s |
|---|---|---|
| RTX 4070 Ti | 4096 | 104,579 |
| A100-SXM4-80GB | 2048 | 117,059 |
| RTX 5060 | 2048 | 58,080 |
この処理では A100 の優位は小さめです。バッチ幅は GPU を使い切るまで効き、その後は頭打ちになります。DLManaka の最適バッチから推測しないでください。
CPU探索
search_speed、5,000シミュレーション、1 コア:
| CPU | sims/s | nps | evals/s |
|---|---|---|---|
| Core Ultra 7 265KF P-core | 22,329 | 22,334 | 29,608 |
| Core i5-14400 | 16,411 | 16,414 | 23,736 |
| EPYC 7742 | 4,411 | 4,412 | 11,006 |
EPYC ホストは測定中に高負荷だったため、CPU 同士の厳密な比較には使えません。
評価と探索の内訳
265KF の eval_split では、1シミュレーションの約 4 分の 3 が評価器演算で、残りの大半が探索木の処理です。合法手生成は小さい割合です。
既定評価器は 1 局面あたり約 494k MAC。小幅なテーブル変更より、全結合幅を縮める方が推論速度へ大きく効きます。
差分更新
eval_throughput で異なる局面を 1 回ずつ評価した結果:
| モード | 265KF スループット |
|---|---|
| アキュムレータ差分更新 | 28,550 pos/s |
| アキュムレータ再構築 | 19,389 pos/s |
1.47倍の差が、この CPU でアキュムレータを局面間に保持する実測効果です。
並列自己対局
265KF では、1 つのパラメータ表を共有する 1 プロセスが 20スレッドで 371,498 sims/s。20 個の独立プロセスは 176 MB のペア表をそれぞれ持つため、246,556 sims/s でした。manaka-selfplay は共有表・スレッド方式を使っています。
特徴量空間の実験
2026-08-26 の search_speed では、細い KP 構成が太い Manaka 型ヘッドより大幅に高速でした。ただし主因は KP そのものではなくネットワーク幅です。
同じ実行の HalfKP 行は正式な対局時速度ではありません。玉が動くと全 HalfKP 特徴 ID が変わりますが、現在の 4 トークン差分では正しく更新できないためです。玉移動時の再構築を実装するまでは HalfKP 速度を未測定扱いにします。
検証とのトレードオフは NNUE特徴量比較 を参照してください。
コマンド
学習ベンチマーク:
cargo build --release -p manaka-train --features cuda探索・評価器:
cargo run --release -p manaka-core --example search_speed
cargo run --release -p manaka-core --example eval_throughput測定ルール
- マシン間の現在値は共通ベンチマークを使う。
- 他セッションが同じワークスペースを再ビルドする可能性がある場合、測定用バイナリを別場所へコピーする。
- ログ出力が計測へ混ざる場合は
WANDB_API_KEYを空にする。 - GPU 学習は実行前後に競合プロセスを確認する。
- 重みが変わると探索木の形も変わるため、
sims/sを評価器単体速度とみなさない。必要なら探索木なし測定を使う。