RTX 5090 / Blackwell の環境で autoresearch を正しく動作させるのに時間を費やし、実際に起きたことを共有することで、他の人の時間を少しでも節約できるかもしれないと思いました。
要点
初期の経路はひどく壊れていました。最初は極めて低い性能しか出ず — およそ数千トークン/秒のオーダーで、MFU は実質的に役に立たない状態 — それにもかかわらずコードは技術的には“動作している”と言える状態でした。
最終的に機能した経路は:
• この設定で壊れた全モデルのコンパイル経路を回避する
• 実際に役立つ箇所で、良い fused optimizer のコンパイル改善を維持する
• 安定した SDPA / CuDNN アテンション経路を使用する
• 推測せず経験的に総バッチサイズと時間予算を調整する
• ベンチマークの自動化 / 抽出 / 戦略立案 / 再実行ループを自動化する
What failed
いくつかの故障モードは特に誤解を招くものでした：
• 技術的には正しいが壊滅的に遅い経路
• 5090 の文脈に合わせて分母を修正するまで MFU の解釈が誤解を生む
• 助けになるように見えたが実際には事態を悪化させた、デバイスあたりのバッチ設定が高すぎた
• 鍵のクリーンアップ / 完了フック / ディスパッチ順序に関する自動化のバグ
つまり：愚かなことをしながらも動作しているように見える実行を得る方法はいくつかありました。
What helped
実際の改善は次の点から生まれました：
• fused optimizer のコンパイル経路を再有効化する
• 元のより大きな設定から総バッチを削減する
• 2**17 をより適した total batch 領域として検証する
• 安定したバッチ運用が見つかったら時間予算を増やす
• 自動化をベンチマークシステムの一部として扱い、付随的なものとしない
進行状況
有用な実行の簡略化された推移：
• 基準となる健全な実行：
• val_bpb: 1.165452
• mfu: 40.49%
• fused optimizer のコンパイル改善：
• val_bpb: 1.155400
• mfu: 42.88%
• TOTAL_BATCH_SIZE = 2**18:
• val_bpb: 1.108381
• mfu: 43.18%
• TOTAL_BATCH_SIZE = 2**17 検証:
• val_bpb: 1.089424
• mfu: 43.03%
• 現在の最良の自動ループ結果：
• TOTAL_BATCH_SIZE = 2**17
• TIME_BUDGET = 1200
• 学習率倍率 = 1.0
• val_bpb: 0.999445
• mfu: 42.56%
• total_tokens_M: 387.8
• num_steps: 2959
現在の最良の既知設定
これまでのところ最良の結果は：
• TOTAL_BATCH_SIZE = 2**17
• TIME_BUDGET = 1200
• 学習率倍率 = 1.0
この組み合わせは以下を上回った:
• より大きなバッチ設定
• より小さな 2**16 の設定
• より低い LR のテスト
• 短いトレーニング予算
主な教訓
この 5090 パスでは、勝つための設定は決して華やかな「すべてを最大化する」ものではないというのが最大の教訓でした。
より良い道は：
• 安定したバッチ運用
• より長いトレーニングの展望
• 自動化とバックエンドのミスを慎重に排除すること
なぜこれを投稿するのか
Blackwell / 5090 のトレーニングに取り組んでいて、奇妙な挙動が見られる場合、それはあなたの想像力だけではないかもしれません。いくつかの経路は、最初に見えるよりもはるかに悪いことがあります。
この作業の有用な部分は、単により良いベンチマーク番号を見つけることではなく、次のような道筋を見つけることでした：
• 安定している
• 自動化可能
• 再現性がある
• 実際のフォローオン実験を構築するのに十分な
もし役に立つなら、ベンチマークの推移表と、実験を自動で再実行し続けるために使用した自動化ループ構造も共有できます。
[リンク] [コメント]
