スループット改善
2026-08-25 の最適化記録です。現在の絶対速度は Manaka ベンチマーク / 共通ベンチマーク を参照してください。このページでは、何が効いたかだけを残します。
結果
RTX 4070 Ti、バッチ 1024 で、1学習ステップは約 44–45 ms → 13.3 ms、およそ 3.3 倍高速化しました。
効いたのはスケジューラや CUDA Graph ではなく、作ってすぐ縮約して捨てていた巨大な一時テンソルを作らないことでした。
効いた変更
GatherDot
以前の方策ヘッドは [batch, max_legal_moves, head_width] のパディング済みテンソルを作っていました。測定時には約 732 MB でした。
GatherDot で行参照と内積を融合し、中間テンソルを書かないようにした結果、45.1 → 18.5 ms/ステップ になりました。
PowerSums
対称多項式側も、次数ごとに [batch, 2, 40, dim] の埋め込みテンソルを作ってからトークン方向へ縮約していました。
PowerSums は 1 カーネル内でトークン走査とべき乗を行い、縮約後だけを出力します。結果は 18.5 → 13.3 ms/ステップ。
この 2 つの融合で VRAM 使用量も大きく減り、元のメモリ帯域飽和も解消しました。
効かなかった変更
損失値の CPU 読み出しを遅らせる
同期点に見えましたが、ログ出力時だけ読むようにしても速度差はありませんでした。主なボトルネックは別のメモリ転送でした。
カーネル起動 削減 / CUDA Graph
1ステップに数百カーネル起動がありましたが、約 4 分の 1 減らしても実時間は改善しませんでした。GPU 実行が支配的で、起動オーバーヘッドは隠れていました。
CUDA Graph は見送りました。CPU 側の起動処理が実測ボトルネックになった場合だけ再検討します。
生成スレッド 増加
20 コア環境では既定の4生成スレッドが 8 / 12 より速く、CPUワーカーは多ければよいわけではありませんでした。
自己対局側
Manaka 推論側には、学習時のような桁違いの一時テンソル浪費は見つかりませんでした。評価器演算と探索処理そのものが中心なので、推論側の改善余地は学習側ほど大きくありません。
現在の内訳は ベンチマーク を参照してください。
残る候補
- ペア表のオプティマイザ状態を低精度化すれば帯域を減らせる可能性はあるが、融合後は「メモリコントローラ飽和」が前提ではない。
- AdamW は毎 ステップ 数千万パラメータのペア表へ触れるため、固定コストとして残る。
- バッチを増やす場合はスループットだけでなく棋力も確認する。更新回数が減ると学習挙動が変わる。
得られた測定ルール
- 最適化対象を決める前に プロファイルする。
- GPU使用率だけでなく
utilization.memoryと電力も見る。 - 複数回の中央値を使い、競合 GPU プロセスがいた実行は捨てる。
- 他セッションがワークスペースを再ビルドする場合は測定用バイナリを分離する。
- 失敗して早く終了した実行を高速実行として数えない。
- カーネル融合後も数値一致テストを必ず行う。