24 時間・1,000 ツールコール：カーネル最適化ケーススタディが証明したもの

実験のセットアップ

Meta は Muse Spark 1.2 に対し、1,000 回を超えるツールコール、最長 24 時間に及ぶ実行で GPU カーネルを反復的に最適化させるテストを行いました。Muse Code のエージェント環境の中で、モデルはカーネルを書き、コンパイルし、提供されたベースラインに対してプロファイリングし、その計測データをもとに次の一手を試します。「書く → コンパイル → プロファイル → 改善」のタイトなループを、丸一日回し続けるわけです。ベンチマーク対象は NVIDIA Hopper GPU 上の KDA および MLA アテンションカーネルでした。

このテストを誠実なものにしているルールがひとつあります。FLA のようなサードパーティのカーネルライブラリの import は禁止。既存の高速実装をラップして手柄にすることはできず、エージェントは本物のカーネル最適化の知識を使って、アルゴリズムを Triton で自力実装する必要がありました。

エージェントが実際に作ったもの

生まれた解は、汎用的な小手先のものではありませんでした。KDA（比較対象は FLA の Triton 実装）に対して Muse Spark 1.2 は、チャンク並列の前処理カーネルと逐次的なチャンク間スキャンを組み合わせ、標準的なフュージョンやタイリングに加えて、ゲート付き累積減衰をチャンク中点で再センタリングするといった KDA 固有の工夫を織り込みました。MLA（バッチサイズ 1、64 ヘッド、シーケンス長 8192、潜在次元 512 の PyTorch リファレンスと比較）では、共有 KV 潜在表現を K と V の両方として再利用する 2 カーネル構成の Triton パイプラインを設計しています。

これらは、アルゴリズムの構造を理解した専門家が書く類の最適化であって、表面的なループいじりではありません。しかもエージェントは、実行が進むにつれてベースラインに対する大きな改善を見つけ続けました。最初のひと伸びで頭打ちになるのではなく、数百イテレーションにわたって進捗が積み上がったのです。

本当の見出しは「24 時間」のほう

カーネルを 20 分間改善できるモデルなら珍しくありません。しかし、一日中方向性を保ったまま前進し続けるには、大半のエージェントが持っていないインフラが要ります。負荷を支えているのは 3 つの要素です。まずゴールコンディショニング。700 回目のイテレーションが 1 回目と同じ目標を向き続けるための仕組みで、モデルはまさにこのために訓練されています。次にコンテキストコンパクション。どの戦略が失敗したか、プロファイラが何を示したかという「重要な知識」だけを保持し、丸一日分の履歴に溺れないようにします。そしてイベントログがランタイムを再起動安全にします。24 時間もあれば何かは必ずつまずきます。23 時間目の成果を消し飛ばすクラッシュが起きたら、実験全体が無意味になってしまうからです。

普段の仕事にとって何を意味するか

Hopper のカーネルを最適化するチームは多くありません。しかしこのタスクの形、つまり「測定可能な目標に向かって反復し、各試行から学び、筋道を見失わない」というパターンは、地味なエンジニアリングの多くと重なります。フレーキーなテストスイートの追い込み、バンドルサイズの削り込み、100 箇所の呼び出し元を抱えた API 移行。このケーススタディは、「投げておいて明日確認する」が現実のワークフローになったという Meta の証拠です。評価手法の詳細は Meta のリサーチサイトで公開されています。プロダクト側での長時間タスクの始め方はドキュメントからどうぞ。