ハクソク

世界を動かす技術を、日本語で。

カーパシのオートリサーチのスケーリング：エージェントがGPUクラスターを手に入れたときに起こること

46日前原文(blog.skypilot.co)

概要

  • Claude Codeをautoresearchに適用し、Kubernetesクラスタ上の16GPUで約8時間運用
  • 約910件の実験を並列実行し、val_bpbを1.003から0.974へ2.87%改善
  • モデル幅のスケーリングが最重要であることを発見
  • H100とH200の異種GPUを自律的に使い分け、効率的な検証戦略を自習
  • 並列化により探索戦略が大きく進化し、最良結果に到達するまでの時間を9倍短縮

Claude Codeとautoresearchによる並列化実験の概要

  • autoresearchはAndrej Karpathyが開発した、ニューラルネットワークのトレーニングスクリプトを自律的に改善するエージェント
  • エージェントはtrain.pyを編集し、5分間のトレーニング実験を実行し、val_bpb（validation bits per byte）で効果を判定
  • 1GPU構成では1度に1実験のみ、約12実験/時の制約
  • SkyPilotを利用し、クラウドやKubernetes上で16GPUを自動管理・割当
  • 16GPU構成で約90実験/時、8時間で約910実験を達成

並列化による探索戦略の進化

  • 1GPU時は貪欲法的なヒルクライミングに限定、1つずつ試行・評価
  • 16GPUでは因子分解グリッド探索が可能
    • 例：モデル幅やハイパーパラメータを同時に多値でテスト
    • パラメータ間の相互作用効果を一度のウェーブで検出
  • エージェントがGPU種別（H100/H200）を自律的に検出し、安価なH100でアイデア選別→H200で検証という戦略を自習

実験フェーズと主な発見

  • フェーズ1: ハイパーパラメータ探索（初期200実験）
    • バッチサイズ、Adamベータ、weight decay等を並列スイープ
    • バッチサイズ半減、Adamベータ(0.9, 0.95)、weight decay 0.08等で改善
    • val_bpb 1.003→0.981
  • フェーズ2: アーキテクチャ探索（200-420実験）
    • モデル幅（aspect ratio）を6値同時比較
    • AR=96（model_dim=768）が最良、幅の拡大が最大の改善要因
    • val_bpb 0.981→0.977
  • フェーズ3: 幅広モデルの微調整（420-560実験）
    • warmdown schedule、学習率、weight decay等を微調整
    • val_bpb 0.977→0.975
  • フェーズ4: オプティマイザ調整（560-700実験）
    • Muonオプティマイザのbeta2=0.98が大きな改善
    • val_bpb 0.975→0.974
  • フェーズ5: 組み合わせ最適化（700-910実験）
    • 学習率、warmdown、embedding LR等の最終調整
    • 改善幅は0.0001未満に減少（収穫逓減）

並列化によるスループットと効率向上

  • 16GPUでシーケンシャルの9倍速（~8時間 vs ~72時間）
  • 1GPU時のボトルネック（実験中のアイドルタイム）を解消
  • SkyPilotでクラスタやジョブの自動管理、エージェントがクラウドリソースを自律運用

最良構成例（抜粋）

  • アーキテクチャ
    • ASPECT_RATIO = 96（model_dim=768）
    • DEPTH = 8
    • WINDOW_PATTERN = "SL"
  • トレーニング
    • TOTAL_BATCH_SIZE = 2^18
    • MATRIX_LR = 0.05
    • EMBEDDING_LR = 0.6
    • SCALAR_LR = 0.5
  • オプティマイザ
    • ADAM_BETAS = (0.70, 0.95)
    • WEIGHT_DECAY = 0.08
    • WARMDOWN_RATIO = 0.6
    • FINAL_LR_FRAC = 0.05
    • muon_beta2 = 0.98

今後の課題と展望

  • 主要な改善（モデル幅、バッチサイズ、オプティマイザ）は出尽くし
  • さらなる性能向上には新規アーキテクチャや長時間トレーニング予算が必要
  • 並列探索の有効性を示し、今後の自律型AI研究エージェントの発展に期待

まとめ

  • Claude CodeとSkyPilotの組み合わせにより、AIエージェントの自律的な並列探索とリソース管理が現実に
  • モデル設計・ハイパーパラメータ探索の高速化・効率化を大幅に推進
  • 人手を介さずに最適化ループを自動運用可能となり、AI研究の新たな地平を切り拓く

Hackerたちの意見

最近のオートリサーチのトレンドって、結局ハイパーパラメータ調整を再発明してる感じだよね。小さなクラスターでの最先端技術（SOTA）は、まだベイズ最適化なのかな？ 3年前にこの手の仕事をしてたけど、それ以来追いついてないや。あと、SkyPilotに感謝！ マルチクラウドでのトレーニングや推論の仕事にめっちゃ助かってる（GPUを手に入れるのは今でも大変だけど…）！
└
もっと直感的で、アーキテクチャの変更を自動で取り入れられるハイパーパラメータ調整。完全に新しいものを発明するわけではないけどね。
└
短絡的で間違った見解だね。LLMは途中で逐次的に学習して、道具を使ったりコードを自由に変更したりできるから。今は、もっと具体的な指示がないとハイパーパラメータ調整に似たものにデフォルトになってるみたい。最初はこのプロジェクトを「オートチューン」と呼ぼうかと思ったけど、「オートリサーチ」の方がずっと適切な名前になると思う。
└
これは「質的勾配降下」に近いのかな、すごく非線形で非凸な表面で。これを簡単に試してみることができるよ。例えば、スピードアップしたいコードがあるとする。エージェントをコードプロファイラー（あなたのオラクル、通常はPythonプロファイラー）に向けて、コードを速くするように指示してみて。試してみたけど、うまくいったよ。
一番驚いたのは、エージェントがH100とH200の両方にアクセスできたこと。何も言われずに、H200の方がスコアが良いことに気づいて、H100でアイデアを選別し始めたんだ。で、勝ち残ったやつをH200に昇格させて検証するっていう戦略が、自分で生まれたってわけ。
└
うん、そこが特に面白い部分だと思った。
└
なんでこれが「自発的に」出てきたと思うの？ この手法は訓練セットの研究論文で議論されてたはずだよね。
└
なんで？… experiment.yamlを見ると、h100/200を明示的に呼び出してるし、「数字が大きい方が良い」って人間が言うのはよくあることだよね… 嘘をついて値を逆にしてみたらどうなるか見てみて。設定ミスについて文句を言うハマり道にハマると思うよ。
これって、電動ドリルを持ったチンパンジーみたいだね。エージェントは正直、ただの brute-force サーチだけど、ガイド付きで。
└
人間主導の研究も brute-force だけど、もっと効率的なサーチ戦略を持ってるよね。研究のサーチスペースナビゲーションの効率を表すパラメータを考えることができる。RLで訓練されたエージェントは、そのパラメータを最適化することになるだろう。君の言う通り、その効率パラメータの価値は、今のところエージェントより人間の方が高いと思う。だけど、1. 研究効率を表すスカラー値関数がたくさんあって、その一部が堅牢な訓練につながること、2. AIラボが研究効率を全体的に向上させる大きなインセンティブを持っていて、何十億ドルもかけて本当に優秀な人間研究者がこの問題に取り組んでいることを考えると、彼らがその効率パラメータで人間の価値をすぐに超えないとは考えにくいよね。
└
「ガイド付きのブルートフォース検索」に当てはまらない研究分野ってあるのかな？科学全体が「入力を集めて、仮説を立てて、テストして、分析する」を繰り返してるだけだよね。特定のガイダンスアプローチには批判すべき点がたくさんあるけど、全体的な方法は同じだよ。
└
でも、電動ドリルはより良いチンパンジーを作るために使われてるわけじゃないよ。
└
君の言う「ガイド付きのブルートフォース検索」って、矛盾してるように感じるんだけど。「ガイド検索」とどう違うの？
> 並列性がエージェントの研究戦略をどう変えたか > 単一のGPUでは、エージェントは貪欲なヒルクライミングをするしかない：一つ試して、結果を確認して、方向を選んで、次のことを試す。16 GPUになると、戦略が変わる。...スキップ... 5分間で12回の実験を行うことができる。これにより、局所的最適解にハマるのが難しくなり、パラメータ間の相互作用効果を見つけるのが簡単になる。理論的には、エージェントはその12回の実験を一つずつ実行するプロトコルを考え出し、その後に次に探求する枝を決めることができるはずだけど、同じ結果になると思う？でもこの場合、最初の1回か2回の結果の後に貪欲な戦略を実行する機会がなかったから、たまたまこの特定の結果にたどり着いたんだ。悪い実験デザイン + 並列性 = 良い実験デザイン + 逐次実行？
└
うん、トレーニング中にアクティブなモニタリングがないと仮定すると、エージェントに「1 GPU」を「16 GPU」に変える抽象を簡単に与えられるよ。それは実行に16倍の時間がかかるだけなんだけどね。
└
> 理論的には、エージェントはその12回の実験を一つずつ実行するプロトコルを考え出し、その後に次に探求する枝を決めることができるはずだけど、同じ結果になると思う？少なくとも理論上は、適応性がサンプルを保存するはずで、この場合は計算もね。（言及されたように、並列を逐次に変えることはできるから、未来から情報を得る逐次アプローチは、サンプル効率においてどんな並列アプローチにも勝つか、少なくとも同等になるはず。）だから、バッチが適応的な探索にしか合致しないなら、LLMが適応的な設定でうまく推論できていなくて、追加情報をうまく活用できていないことを示唆してるかも。もっと明示的な反実仮想的推論や、可能な結果の木に対する計画が必要なのかな？
この「初期の速度のみ」アプローチは問題がありそうだね。5分間のトレーニングで全体の漸近線に影響を与えてないかどうか、どうやって確認するの？例えば、AIが最初の5分間でたまたま速い量子化器を選んだけど、大きなノイズフロアがあってそれ以上進めない場合はどうなるの？
└
そうだね、欲張りだからローカルオプティマに引っかかるかも。学習曲線をフィットさせて、その問題を避けるために外挿してみるのもいいかも。ちゃんと長く走らせて、行き止まりに近いことを確認するのが大事だし、過去の候補を定期的に復活させて長く走らせるのもアリだね。過去のハイパーパラメータアプローチ、例えばフリーズ・ソーの方法を見てみて。https://arxiv.org/abs/1406.3896
これ、めっちゃ興味深い！最近、似たようなものを作ったばかりなんだ（テスト用だけど）、AIを改善するためじゃなくて、物理シミュレーションのハイパーパラメータを調整するためにね。シミュレーションの実行をかなり最適化できたから、ブルートフォース検索も現実的な選択肢になったんだ。エージェントに、直感や物理的な理由に基づいてパラメータを調整する背景を教えて、テストを実行して結果の統計を取得する手段を与えると、意外とうまくいくんだよね。これは本質的に、システム内の暗黙の制約を見つけて活用する能力が高いハイパーパラメータ探索だと思ってる。
アメリカ政府は、この男をテスラの自動運転の責任者として犯罪で起訴する方法を「自動研究」すべきだね。
└
もう少し詳しく教えてくれる？
これはリンゴと洋梨の比較じゃない？単に、クレジットカードが大きいと物事が早く進むって言ってるだけだけど、実際にはGPUの利用効率や効率性の面では悪化してるよ。1) GPU時間だけをカウントすると、総時間は同じじゃない。16台のGPUがあれば、均等に比較するために4.5時間動かすのが理にかなってる、8時間じゃなくてね。2) もし4.5時間で止めて（大きな落ち込みを含めて寛大に見積もっても）、損失は約0.978で、これは逐次解法の約44時間と同じだから、逐次解法の方が約2倍効率的ってことになる。だから、ここでの本当の結論は、ハードウェアがもっとあれば効率を犠牲にしつつも時間を短縮して並行処理できるってことだね。ブログがちょっと過剰に売り込んでる気がする。
エージェントをどこでも動かす方法は解決した気がするけど、どこでも信頼する方法はまだだね。
これに「ワオ」って感じを見つけようとしてるんだけど。バリデーション基準を考慮して最適なパラメータの組み合わせを見つけるのは、機械でも人間でも退屈な繰り返し作業じゃないの？与えられたハードウェアをどう活用するかを決めることなのかな？