自動化された AI 研究への第一歩（12 分間の読了）

本日、Recursive の自動化 AI 研究システムからの初期結果を発表します。3 つのベンチマークにおいて、このシステムは最先端の結果を達成しました：固定予算での言語モデルトレーニング、小規模モデルのトレーニング速度、および GPU カーネル最適化です。 このシステムは、特定の目標に対する研究ループを自動化します。アイデアを提案し、実装し、実験を実行し、結果を検証し、得られた知見を用いて次の実験を選択します。長期にわたる多数の研究スレッドを実行し、過去の实验からの有用な文脈を保持し、有望な分岐を組み合わせ、改善されたパフォーマンスが真の進歩であるとみなす前に、報酬ハックや分散に対する検証を経て結果を処理します。このシステムは拡張可能に設計されており、オープンエンドアルゴリズムの原則を活用し、チームおよび他者の先行研究からのアイデアを基盤として、再帰的に自己改善する AI を構築しています。 私たちは、実用的な重要性と緊密なフィードバックループの両方を考慮して選択されたベンチマークでこのシステムを検証しました。これらは AI 進歩の3 つのコアレバー、すなわちより優れたトレーニングアルゴリズム、高速化されたトレーニング、およびハードウェアのより効率的な利用に負荷をかけます。また、明確な指標、比較的低い分散、報酬ハックに対して堅牢化可能な評価者を持つため、自動化研究にも適しています。 私たちは、他者がシステムの出力を検証し構築できるようにするために、これらの実行から得られたアーティファクトをオープンソース化します [https://github.com/recursive-org/first-steps-toward-automated-ai-research](https://github.com/recursive-org/first-steps-toward-automated-ai-research)。 ベンチマーク タスクタイプ 指標 以前の最先端技術 再帰的改善 NanoChat 自動研究 小規模言語モデルを、限られた計算リソース予算内で最高性能まで訓練する 検証 BPB (Bits Per Byte) 0.9372 0.9109 検証 BPB が 0.0263 低下、または同等の損失に到達するのに 1.3 倍の高速化 NanoGPT スピードラン 小規模言語モデルを特定の性能まで可能な限り速く訓練する 検証損失 3.28 に到達するために必要な訓練時間 79.7 秒 77.5 秒 訓練が 2.2 秒高速化 SOL-ExecBench ハードウェアの限界に向けて GPU カーネルを最適化する 235 のカーネルにわたる平均 SOL スコア 0.699 0.754 最適性能推定値 1.0 に対するギャップが 18% 減少 ケーススタディ 1: NanoChat 自動研究 Andrej Karpathy の NanoChat [autoresearch リポジトリ](https://github.com/karpathy/autoresearch) は、自動化された研究システムの人気のある出発点です。このタスクは、単一の GPU で固定された 5 分という予算内で、ビット毎バイト (BPB: bits per byte) で測定される検証損失を最小化する小規模言語モデルを訓練することです。実験が高速であり、ばらつきが小さく、報酬のハッキングが比較的容易に検出できるため、これは私たちのシステムの自然なテストとなります。 おそらくこれらの理由から、この設定を巡って公的な共同作業の取り組みがすでに形成されています。[autoresearch@home](https://www.ensue-network.ai/lab/autoresearch) は、元の設定を拡張し、数十人の人間と数百人のエージェントが集団的にパフォーマンスを向上させる共同環境へと発展させました。これにより、Karpathy 氏の単一の一夜限りの実行よりも強力な比較対象が得られます。私たちは、私たちのシステムが、人間とエージェントからなるコミュニティ全体が生み出した解決策を上回る能力があるかどうかを検証したかったのです。 私たちのシステムは、Autoresearch コードが開始するのと同じ初期シード解から出発します。当初は NVIDIA H100 GPU で探索を行い、その後、発見された解を NVIDIA B200 GPU 上で実行できるように転送し、公開結果との公平な比較を実現しました。以前の最良の autoresearch@home 解からわずかな報酬ハック（reward hacks）を取り除き、10 のランダムシードで評価したところ、その平均パフォーマンスは 0.9372 BPB でした。私たちのシステムが見つけた解は 0.9109 BPB に到達し、0.0263 BPB の改善となりました。別の測定方法では、私たちの解は Karpathy 氏の元の一夜限りの autoresearch が達成した BPB の品質に、最良の autoresearch@home 解よりも約 1.3 倍少ないトレーニング時間で到達します。 ![image](https://cdn.prod.website-files.com/69c2d7e2ad6312d0a414043e/6a2a5c2a900a3c312cdd1277_progress_best.svg)FIGURE 1 自動研究は、すでに最適化されたモデル、すなわちいくつかの非自明な設計決定が組み込まれた状態から始まります。そこで、本システムがはるかに弱い出発点である素朴な初期実装（AdamW を用いたバニラ Transformer）からも改善を行えるかどうかをテストしました。その結果、本システムはモデルを 1.059 BPB から 0.9344 BPB に向上させました（NVIDIA B200 GPU で評価）。これは再び、自動研究@home コミュニティが生成した最良のソリューションを上回るものでした。これは必ずしも独立した再発見を証明するものではありません。なぜなら、基盤となるモデルは、自動研究@home コミュニティによって使用されたり作成されたりしたものを含む多くの公開技術を既に知っている可能性があるからです。しかし、この結果は、検索プロセスがはるかに弱い出発点から競争力のあるトレーニングスタックを組み立てることができることを示しています。得られたソリューションは、公開されている最良のソリューションとはいくつかの点で異なっていました。 ![image](https://cdn.prod.website-files.com/69c2d7e2ad6312d0a414043e/6a2a619f6d291d39440cfd9c_val_bpb_karpathy_best.svg)FIGURE 2 ![image](https://cdn.prod.website-files.com/69c2d7e2ad6312d0a414043e/6a2a5c2a424c74435b0c9828_speedup_all.svg)Figure 3 本システムがどのような改良を提案したのでしょうか。最良のソリューションは、単一のトリックによって導かれたものではありませんでした。それらは、アーキテクチャ、短文脈メモリ、補助損失関数、アテンション機構、オプティマイザの動作、重み減衰スケジューリング、コンパイラ設定などへの複数の変更を組み合わせたものでした。 最大の成果の一つは、より豊かな短文脈メモリ機構から得られました。ベースラインではすでに値埋め込みを使用していますが、当システムはこの考え方を拡張し、ハッシュ化された bigram および trigram の埋め込みテーブルを、学習されたゲートを通じてアテンション値パスに混合しました。これにより、モデルはより遅い畳み込みやアテンション重視の代替手法にかかる時間コストを支払うことなく、局所的な n-gram 情報を安価に利用できるようになりました。 これは、ハッシュテーブルをスパース性の軸として探求する最近の研究である [DeepSeek Engram](https://arxiv.org/abs/2601.07372) と関連しています。当システムの設定では、ハッシュテーブルは約 5,000 万パラメータのモデルに 10 億〜20 億のパラメータを追加する可能性があります：エントリの多くは任意のバッチにおいて非アクティブであり、参照コストも低いです。同様のハッシュテーブルおよび n-gram のアイデアは、トップクラスの NanoGPT Speedrun 提出物にも見られます。当システムは、このアイデアのファミリーを固定予算設定に適応させるため、複数の層にわたってアテンション値ベクトルへハッシュ化された bigram および trigram 埋め込みを注入し、各層で異なるハッシュを使用することで重複衝突を減らしました。この正確なバリアントを用いた先行研究があるとは認識していません。 以下の展開可能なボックスには、システムのソリューションから選ばれた技術的な詳細が含まれています。これらの出力を手動で検査し、AI を活用した分析を用いて技術を理解するとともに、報酬ハックのスクリーニングを行いました。カーネル最適化におけるエラーを見逃している可能性もまだありますが、それもまた重要な点です：ここで提示されたアイデアは、私たちの専門知識からではなく、システム自体から生まれたものです。 [## ハッシュテーブル](#)初期ソリューションにおける標準的なユニグラム値埋め込みの上に、最良のソリューションではモデルが各ビッグラムとトライグラムを固定サイズのテーブルにハッシュし、学習された入力依存型のヘッドごとのゲートを通じて検索したベクトルをアテンション値パスに混合します。これにより、古典的な n-gram モデルがトランスフォーマーの値ストリームに組み込まれます。 for j, layer_i in enumerate(ve_layers): self.bigram_ves[str(layer_i)] = nn.ModuleList([ nn.Embedding(self.bigram_table_size, half_kv_dim), nn.Embedding(self.bigram_table_size, half_kv_dim), ]) self.bigram_hash_primes_per_layer[layer_i] = _decorr_bigram_primes[j] for j, layer_i in enumerate(sorted(self.trigram_ve_layers)): self.trigram_ves[str(layer_i)] = nn.ModuleList([ nn.Embedding(self.trigram_table_size, half_kv_dim), nn.Embedding(self.trigram_table_size, half_kv_dim), ]) self.trigram_hash_primes_per_layer[layer_i] = _decorr_trigram_primes[j] v = v + gate.unsqueeze(-1) * ve ## standard value embedding v = v + bg_gate.unsqueeze(-1) * bigram_ve ## additional bigram embedding from lookup table v = v + tg_gate.unsqueeze(-1) * trigram_ve ## additional trigram embedding from lookup table 解法は、異なるトランスフォーマー層にそれぞれ異なるハッシュ関数（互いに素なハッシュ素数のペア）を与えることも可能にする。 self.bigram_hash_primes_per_layer[layer_i] = _decorr_bigram_primes[j] self.trigram_hash_primes_per_layer[layer_i] = _decorr_trigram_primes[j]つまり、衝突は依然として発生するが、異なる層で同じような方法で衝突が発生する可能性は低くなる。 バニラトランスフォーマーの最適化には、最良の解法と同じ技術の一部（ハッシュテーブルと二乗 ReLU の MLP など）が使用された。しかし、最終的なスタックは異なるもの（ただし同等に競争力のあるもの）に収束しており、トークンのシフト、評価前の重み平均、バイトレベルの特徴埋め込みが含まれていた。これは、システムが他のランで発見したのと同じ発見を単に繰り返していたわけではないことを示唆している。展開可能なボックスには、バニラトランスフォーマーのラン固有の変更点がいくつか示されている。 ## バニラ型トランスフォーマーの最適化 バニラ型トランスフォーマーソリューションにおける多くの変更点は、私たちの最良ソリューション（Autoresearch の初期シードコードからシステムを開始して得られたもの）にも見られます。具体的には、AdamW から Muon への置き換えやハッシュテーブルの追加などが該当します。しかし、最良ソリューションを生み出した主要な実行プロセスでは現れなかったが、私たちが特に注目したいくつかの改善点も存在します。その一つは因果トークンシフト（causal token shifting）です。これは、直前のトークンのアテンション投影 Q と K を現在のトークンにブレンドするものであり、次元ごとに学習された係数を用います。 B, T, C = x.size() x_prev = F.pad(x[:, :-1, :], (0, 0, 1, 0)) q = self.c_q(x + self.q_shift_beta * x_prev).view(B, T, self.n_head, self.head_dim) k = self.c_k(x + self.k_shift_beta * x_prev).view(B, T, self.n_head, self.head_dim) v = self.c_v(x).view(B, T, self.n_head, self.head_dim) 二つ目の改善点は、トークン埋め込みの直後に注入されるバイトレベルの特徴量（byte-level features）のセットです。この特徴量は、トークンを構成するバイト（例えば個々の文字など）に関する情報を表しています。類似したバイトで構成されたトークンは、同様のバイトレベル埋め込みを得ることになります。このバイト特徴量の埋め込み行列は以下のように構築されます： combined = torch.zeros(vocab_size, 769) for token_id in range(vocab_size): raw_bytes = tokenizer_enc.decode_single_token_bytes(token_id) # variable length if len(raw_bytes) > 0: for b in raw_bytes[:max_bytes]: # max_bytes=16 combined[token_id, b] += 1.0 / len(raw_bytes) # [0:256] byte-frequency histogram combined[token_id, 256 + raw_bytes[0]] = 1.0 # first byte one-hot combined[token_id, 512 + raw_bytes[-1]] = 1.0 # last byte one-hot combined[token_id, 768] = len(raw_bytes) / max_bytes # length feature torch.manual_seed(1337) proj = torch.randn(769, embed_dim) * 0.01 init_emb = combined @ proj # [vocab, embed_dim] self.embed = nn.Embedding(vocab_size, embed_dim) self.embed.weight.data.copy_(init_emb) # used only as the INITThese embeddings are then updated by gradient descent during training, and added after the token embedding alongside the bigram and trigram embeddings: x_base = self.wte(idx) # トークン埋め込み gates = self.embed_mixer(x_base) # 4 つのソースに対するトークンごとのゲート [B,T,4] x = x_base x = x + gates[:,:,0:1] * bi_raw # bigram ハッシュ x = x + gates[:,:,1:2] * tri_raw # trigram ハッシュ x = x + gates[:,:,2:3] * self.byte_embed.get_raw(idx) # バイトコンテンツ x = x + gates[:,:,3:4] * self.byte_boundary.get_raw(idx) # バイト境界 x = x + self.ssm_light(x) x = self.embed_ctx_norm(x) これらは、今回の実行でシステムが行った変更のほんの一部に過ぎません。 NanoChat は、固定予算トレーニングを改善するようシステムに指示することが、多くの複合的で予算意識的な改善の発見につながったことを示しています。次のテストは、このプロセスがベンチマークに対する長年の公的な人間の最適化の後でも依然として改善点を見つけられるかどうかでした。これを NanoGPT Speedrun で検証しました。同プロジェクトの最良の公開ソリューションは、コミュニティによって 2 年間にわたり高度に最適化されています。 ## ケーススタディ 2: NanoGPT Speedrun [NanoGPT Speedrun](https://github.com/KellerJordan/modded-nanogpt) は類似したタスクですが、大規模なコミュニティが 2 年以上にわたってこのタスクのソリューションを最適化しているため、最先端を打ち破ることははるかに困難です。固定時間予算内で達成できる検証損失がどれだけ低いかを問うのではなく、このベンチマークでは、単一の HGX H100 8-GPU ノードを使用して、FineWeb テキストデータセット上で小さな GPT スタイルのモデルを固定された検証損失 3.28 に到達させるまでの速度を問います。 これは成熟したコミュニティによる取り組みであり、これまでにリーダーボードに対して83件の人間による記録更新貢献があり、提案されたプルリクエストは数百件に及びます。2024年中盤以降、主に手作業で設計された提出物の連続的な積み重ねにより、トレーニング時間は約45分から79.7秒へと短縮されました。現在のソリューションがこれほどまでに最適化されているため、明白な改善の余地はほとんど残されていません。 現在の最上位ソリューションを出発点として、当システムは追加の最適化セットを見つけ出し、リーダーボードの検証損失の有意性要件（p < 0.01で平均検証損失 ≤ 3.28）を満たしつつ、トレーニング時間を79.7秒から77.5秒に短縮しました。[1](#footnote-1)* *これは直近の人間の貢献と同様か、それ以上の改善規模です。 ## 77.5秒ソリューション：FP8アテンション、探索ノイズ、慎重な埋め込み [^] 以下の変更は、トレーニングスクリプトとカーネルファイル全体で約200行にわたる変更を通じて、77.5秒という達成に至るためにシステムが創出し、組み合わせた革新の例です。 **FP8 アテンション投影。**人間の記録では、アテンション QKV（クエリ、キー、バリュー）および出力投影層を bf16（bfloat16、16 ビット浮動小数点形式）で実行し、LM ヘッド（次のトークンを予測する最終層）でのみ FP8（8 ビット浮動小数点）を使用しています。本システムは、アテンションパス（アテンション層内の計算）に FP8 を導入しました。これは、フォワード行列乗算を float8_e4m3（指数部 4 ビット、仮数部 3 ビットの FP8 形式）で実行してテナーコアのスループットを 2 倍にしつつ、バックワードパスは安定性を保つために bf16 で維持し、トレーニング時のみ適用するカスタム演算です（検証用フォワードパスでは bf16 に復元されます）: class FP8LinearFunction(torch.autograd.Function): @staticmethod def forward(ctx, x, w): x_f8, w_f8 = x.to(torch.float8_e4m3fn), w.to(torch.float8_e4m3fn) y = torch._scaled_mm(x_f8, w_f8.T, out_dtype=torch.bfloat16, scale_a=ones, scale_b=ones, use_fast_accum=True) ctx.save_for_backward(x, w) return y @staticmethod def backward(ctx, grad_output): # 精度のためバックワードは bf16 で維持 x, w = ctx.saved_tensors return grad_output @ w, grad_output.T @ x # アテンション投影に適用、学習時のみ： if self.training: qkv = fp8_linear_fn(x.view(-1, self.dim), qkv_w) else: q, k, v = F.linear(x, ...) # 評価時はbf16**オプティマイザにおける減衰探索ノイズ** [(ランジェバン/SGLD)](https://www.semanticscholar.org/paper/aeed631d6a84100b5e9a021ec1914095c66de415)。本システムは、[NorMuon](https://arxiv.org/abs/2510.05491) の更新式を改変し、直交化され分散が低減された更新に対して平均ゼロのガウスノイズを注入します。このノイズの標準偏差は、行ごとに更新自体のルート・アベレージ・スクエア（RMS）にスケーリングされており、パラメータ間でスケール不変性を保ちます。ノイズは最初の 50 ステップでウォームアップされ、その後学習の約 4 分の 1 の地点まで線形的にゼロへ減衰します。これにより、最終解は（ hopefully より平坦な）バシン内にきれいに収束する傾向があります： def _add_exploration_noise(v_chunk, noise_t, red_dim): sigma = noise_t.to(v_chunk.dtype) # annealed scale (0-D CPU tensor) row_rms = v_chunk.float().square().mean(red_dim, keepdim=True).sqrt_() return v_chunk.add_(torch.randn_like(v_chunk) * (sigma * row_rms)) **Adam における慎重な（符号一致）更新。** 人間の記録による解決策ではすでに慎重な重み減衰が使用されています。本システムはこの「慎重さ」の概念を、特に bigram および値埋め込みテーブルに対する Adam の更新ステップ自体に拡張しました。これは、適応的なステップが生の勾配と逆向きに向いている場合のパラメータ更新をマスクし、残りの更新を再正規化し、その慎重な更新を標準的な Adam 更新と強度 0.5 で混合するものです： agree = (update * g_slice) > 0 keep = agree.to(update.dtype) masked_update = update * (keep / keep.float().mean().clamp_min_(1e-3)) update.lerp_(masked_update, strength) # adam_coptim=0.5, only on bigram_embed + value_embeds **より軽量な融合 MLP カーネル。** システムはまた、線形-ReLU²-線形の融合 Triton カーネルを書き換え、順伝播では二乗された ReLU 活性化値のみを保存し、逆伝播ではカーネル内で未平方の活性化値をその場で再構築することで、高帯域幅 GPU メモリへの完全な活性化テンソルの往復転送を不要にしました。 これらの改善と並行して、当システムは複数の小規模なシステムレベルおよびスケジュールレベルの選択を行いました：最終ステップにおける言語モデルヘッドの勾配更新にはスパース（疎）アプローチを採用し、バッチ内で実際に出現する語彙行のみをインデックス加算（index_add_）によって書き戻すことで、密な転置加算を回避しました。また、人間の解決策が 2/3 の時点で埋め込み層と言語モデルヘッドを分離するのに対し、当システムは実行全体を通じて両者を結合したまま維持しました。さらに、ステージスケジュールとステップ数を scheduled steps 1,387 ステップに拡張ステップ 11 ステップを追加して再調整し、ペアヘッドアテンション（paired-head attention）レイヤーの使用数を減らしました。 ![image](https://cdn.prod.website-files.com/69c2d7e2ad6312d0a414043e/6a2a5c2a943a4c54caff1b0b_timeline.svg)FIGURE 4 当システムが、はるかに弱い初期状態からでも進歩を遂げられるかどうかについてもテストを行いました。より早期の約 15 分間の解決策（チャンピオンの系譜における最初の動作する Python ソリューションであるエントリー#5 を選択しました。それ以前のバージョンは C で記述されていたため）から開始し、当システムは数日以内に約 185 秒という結果を達成しました。これは、人間のリーダーボードの 2025 年 5 月時点における約 180 秒のレベルにほぼ匹敵するものです。ただし、これは独立した発見や独自の発見として解釈すべきではありません。基盤となるモデルがリポジトリを参照している可能性があるためです。しかし、当システムは異なる最終解決策を見出し、重複する貢献を異なる順序で追加しました。 ## 185 秒のゼロから構築したソリューションの分析：3 分への異なるアプローチ このソリューションは、2025 年 5 月頃の約 3 分（180 秒）という記録（#22, 179.4 秒）に迫るものでした。両者とも標準的な現代的なアイデアを共有しています。私たちのソリューションでは、人間の記録で採用された QKV の統合やロングショートアテンションは使用していません。さらに異なる点として以下が挙げられます： **ステッチストリームアテンション。** 学習データは多くの短いシーケンスとして提供されます。システムはそれらを 8 つまとめて単一の約 16k トークンのストリームにパックし、モデルのローカルアテンションウィンドウがこれら間の境界を越えて文脈を保持できるようにします。ただし、マスクによって任意のトークンがドキュメント境界を跨いでアテンションしたり、未来のトークンを参照したりすることは防止されます： STITCH_GROUP = 8 # 8 行を折りたたむ -> 1 つ (B//8, 8*T) = (·, 16384) シーケンス mask = causal & same_doc & (q_idx - kv_idx < window) # ドキュメント間/未来への漏洩なし **レイヤーごとのウィンドウピラミッド。** ほとんどのレイヤーは近くの 384 トークンのみにアテンションを向けますが、3 つのレイヤーでは 2,048 トークンまで視野を広げます。これにより、単一の均一なウィンドウではなく、ローカルとより長距離の視点の安価な混合が実現されます。 **狭められたアテンション。** 4 つのアテンションヘッド（総幅 512）を使用します。これはモデルの全幅である 768 よりも狭く、人間の広範で融合射影された設定に代わり、ステップあたりの計算量を削減します。 **クロスレイヤー差分 (cldiff)。** 後のレイヤーは、前のレイヤーのアテンション出力から学習可能な少量を混合します。これはモデルが既に計算した情報を再利用する安価な方法です： # 後方層は、ヘッドごとの学習可能なλを用いて、分離された前方層の注意出力をブレンドする: y = y - lam * rms_norm(cldiff_src) # cldiff_src = 前方層の注意出力（分離済み）**ハッシュ化されたbigram埋め込み。**隣接するトークンペアをキーとする小さなルックアップテーブルであり、ゼロから始まるゲートを通じて入力に混合される。これは、有益な場合のみ寄与するように設計されている。人間のリーダーボードも同様の「Bigram Hash Embedding」を採用したが、技術スタックの開発プロセスにおいて異なる順序で追加した。 **FP8 とカスタム融合Tritonカーネル。**システムは、トレーニング中にフィードフォワード層と出力層を8ビット浮動小数点で実行する（評価時には完全精度が復元される）、また、メモリアクセスを削減するために複数のGPU操作を単一のカスタムカーネルに統合している。比較のために言うと、2025年5月時点では人間の記録は最終層のみで8ビットを使用し、このような融合カーネルの採用はその数ヶ月後となった（記録#27は2025年7月、#59–60は2026年1月）。 **オプティマイザーおよびシステムトリック。**オプティマイザーが更新を蓄積する方法や、大規模ルックアップテーブルの勾配を8つのGPU間で共有する方法（圧縮され、頻度の低い通信を使用）など、少数の小さな変更があり、それぞれがわずかな時間の節約をもたらした。 77.5秒という解決策は単一の最適化ではなかった。それは注意精度、オプティマイザーの動作、埋め込み更新、スケジューリングの選択、および融合GPUカーネルに対する変更を組み合わせたものである。各変更は、トレーニングを不安定にすることなく時間を節約するものでなければならなかった。 人間コミュニティ全体（時には AI の支援を受けながら）がこの問題に取り組むために数年を費やしているにもかかわらず、Recursive の自動化された AI 研究システムはさらに改善点を見つけ出しました。次のケーススタディでは、小規模モデルのトレーニングレシピから GPU カーネルへとレベルを下げていきます。最初の 2 つのベンチマークとは異なり、カーネル最適化は本番環境システムの作業に近く、実際のトレーニングや推論ワークロードのコストを決定することがよくあります。 ## ケーススタディ 3: SOL-ExecBench 最初の 2 つのベンチマークは小規模言語モデルのトレーニング実行の最適化に焦点を当てています。[SOL-ExecBench](https://research.nvidia.com/benchmarks/sol-execbench) は代わりに、高速かつ正確な GPU カーネル（行列乗算、リダクション、正規化層、アテンションコンポーネント、量子化ルーチン、融合ブロックなどの演算背後にある小型アクセラレータプログラム）の記述に焦点を当てています。 このベンチマークには、実際のワークロードから派生した 235 のカーネル記述タスクが含まれています。各タスクは、シグネチャ、テンソル形状、データ型、および数値契約（カーネルが生成すべき出力とその参照実装との許容差）を定義する単純なリファレンス PyTorch 実装を提供します。目標は、NVIDIA Blackwell B200 GPU 上で可能な限り高速に実行しつつ、許容範囲内で同じ結果を生み出すことです。 ベンチマークは、光速（SOL）SOL-ExecBench スコアを報告しています。スコア 0.5 はベンチマークの最適化された PyTorch ベースラインに対応し、スコア 1.0 はベンチマークによる解析的な最適性能推定値に対応します。 当システムは 235 のカーネルすべてを統合的に実行しました。これにより、関連するタスク間で発見した知見を再利用し、より効率的な手法（例えば、メモリアクセスのパターン、タイリング、リダクション、ベクトル化、融合など）を実現できるようにしています。標準的なプロファイリングツールは提供しましたが、カーネルエンジニアリングのためにシステムを特化してチューニングしたわけではありません。プロファイリングツールの追加を除き、他の 2 つのベンチマークと同様に、同じシステムを使用してカーネルの最適化を行っています。 当システムの平均 NVIDIA SOL-ExecBench スコアは 0.754 となり、前回のリーダーボード最高値である 0.699 からハードウェア限界との差が 18% 縮小されました。 ![image](https://cdn.prod.website-files.com/69c2d7e2ad6312d0a414043e/6a2a5c2a19f9f42de5e9ea69_recursive_vs_sota_pretty_zoom.svg)FIGURE 5 ![image](https://cdn.prod.website-files.com/69c2d7e2ad6312d0a414043e/6a2a5c29690b5e223da54949_recursive_vs_sota_pretty_means_by_category_zoom.svg)FIGURE 6 いくつかの高パフォーマンスなカーネルを確認したところ、その解決策には優れたカーネルエンジニアリングの慣行と創造的なアプローチが含まれていることがわかりました。展開可能なボックスでは、詳細に興味のある方のためにいくつかの例を示しています。 [## Example L1 kernel 045_fused_linear_gelu_grn_linear (L1)](#) ## What the kernel does このオペレーションは Linear → GELU → GRN → Linear の順で構成されています。GRN（ConvNeXt-V2 の Global Response Normalisation）は、GELU 後の活性化値を受け取り、その活性化値のチャネルごとの L2 ノルムに基づいてスケーリングされるチャネル単位のアフィン変換を適用します： out[i] = x[i] * (1 + gamma[i] * n[i] / mean(n)) + beta[i] ここで i はチャネルインデックス、n[i] はチャネル i の L2 ノルム（空間トークン軸に沿って縮約されたもの）、gamma と beta は学習されるチャネル単位のパラメータです。チャネル間の縮約である mean(n) が存在するため、GRN を単一の GEMM エピローグで両側の Linear 演算と融合させるのは困難になります。 ## The solution 2 つの Linear 演算の間に GRN を実行するのではなく、このカーネルは順伝播（フォワードパス）ごとに第 2 の重み行列を書き換えてアフィン変数を吸収します。s_inv = 1 / (mean(n) + eps) とし、j を W2 の出力行インデックス、i をチャネル/入力インデックスとすると： W2_prime[j, i] = (1 + gamma[i] * n[i] * s_inv) * W2[j, i] b_eff[j] = sum_i ( beta[i] * W2[j, i] ) + b2[j] out[j] = sum_i ( x[i] * W2_prime[j, i] ) + b_eff[j] 最初の式は小さな Triton カーネルで計算され、最後の式は、バッチごとに事前スケーリングされた W2_prime に対するストライド付きバッチ化 fp16 GEMM で、b_eff は CUBLASLT_EPILOGUE_BIAS を介して GEMM のバイアス加算エピローグによって消費されます。 チャネルごとのスケールと吸収されたバイアスの累積は、1 つのループ内で実行されます（gw は gamma、gb は beta、wf は W2 の fp32 行、oh は W2_prime の fp16 セル、bc2 は吸収されたバイアス項を累積）： for (int i = 0; i < VEC; ++i) { float sc = gw[i] * (n[i] * s_inv) + 1.0f; oh[i] = __float2half(sc * wf[i]); if (wb) bc2 += gb[i] * wf[i]; } W2_prime は {B, DIM, HIDDEN} の fp16 テンソルとしてマテリアライズされ、各バッチ要素ごとに独自のプリスケーリングされた W2_prime が割り当てられます。 [## 例 L2 カーネル 049_group_limited_topk_routing (L2)](#) ## このカーネルの役割 DeepSeek-V3 スタイルのグループ制限付きエキスパートトップ K。256 のエキスパートは 8 グループ（各 32）に分割されます。各グループは、その上位 2 つのエキスパートスコアの合計によって評価され、上位 4 つのグループが保持されます。その後、保持されたグループ全体に対してトークンごとのトップ K = 8 が選択され、K 個の勝者重みが合計が 1 となるように再正規化されます。 ## 解決策 (bit-packed (score, expert_index) キー)。各候補は順序付け可能な uint32 にパッキングされるため、各トップ K 反復では単一の __reduce_max_sync が使用され、その勝者はスコアとエキスパートインデックスの両方を別個のインデックスブロードキャストなしでデコードします。上位 24 ビットにはスコアの IEEE-754 ビットパターンが格納され、下位バイトには同点時の低インデックス優先のために 255 - expert_idx が格納されます: constexpr uint32_t TOP8_VALUE_MASK = 0xffffff00u; CUTLASS_DEVICE uint32_t make_top8_key(uint32_t shifted_route_bits, int expert_idx) { return (shifted_route_bits & TOP8_VALUE_MASK) | (uint32_t)(255 - expert_idx); } ルート値は sigmoid(logit) + bias + 16.0 であるため、ビットパターンは非負となり、符号なし整数として直接順序付け可能です。 **CUTLASS デバイス関数内の融合ルーティングテール。** シグモイド、バイアスの加算、グループごとのトップ 2 和計算、トップ 4 グループのプルーニング、レーンごとのトップ K 選択、8 つの勝者に対するビトニックソート、再正規化という一連の処理全体が、行ごとのワープとして動作する単一の関数として実行されます。 **先行する GEMM との PDL。** この関数は `cudaLaunchAttributeProgrammaticStreamSerialization` を指定して起動され、そのグリッド設定により、先行する bf16 ロジット GEMM のテール処理とオーバーラップします。 [## 例：量子化カーネル 032_nvfp4_moe_expert_linear_with_gating (Quant)](#) ## このカーネルの機能 融合された NVFP4 SwiGLU MoE エキスパート: gate = W_g @ x up = W_u @ x out = W_d @ ( silu(gate) * up ) # * は要素ごとの演算 3 つの重み（W_g, W_u, W_d）はすべて NVFP4 で保存されています。これは NVIDIA の 4 ビットマイクロスケーリング形式です。値は E2M1 形式であり、各 16 要素ブロックには FP8 (E4M3) スケールが含まれ、テンソル全体にはさらに 1 つの FP32 スケールが付加されています。デ量子化では、ブロックスケールとテンソルスケーラーを組み合わせて計算を行います。 ## 解決策 **ネイティブ PTX を用いた FP4 パッキング。** この変換は、ソフトエミュレーションによる量子化ではなく、`cvt.rn.satfinite.e2m1x2.f32` 命令を使用して、1 バイトあたり 2 つの FP4 値を直接パッキングします。 packed_byte = tl.inline_asm_elementwise( "{ .reg .b8 b; cvt.rn.satfinite.e2m1x2.f32 b, $2, $1; cvt.u32.u8 $0, b; }", "=r,f,f", [v0, v1], dtype=tl.uint32, is_pure=True, pack=1, ) **キャプチャされた CUDA グラフの外側でのウェイトのステージングとスケールのリブロッキング。** 単一の Triton カーネルは、CTA（Cooperative Thread Array）領域によってグリッドを分割します：最初の n_scale_tiles の CTA がスケールのリブロッキングを行い、残りの CTA がゲート/アップ/ダウン重みをコピーします。このステージングカーネルは、キャプチャされた CUDA グラフが再生される*前*に実行されます — グラフ自体には、量子化 → GEMM（行列積）→ SwiGLU → 再量子化 → GEMM の計算パスのみが含まれています。 **FP4 レイヤー間の FP32 SwiGLU。** ゲート/アップ FP4 GEMM 出力とダウン投影 FP4 再量子化の間、SwiGLU 活性化は FP32 で実行され、活性化を介した連鎖的な FP4 丸め誤差を防ぎます。 [## Example FlashInfer-Bench kernel 012_gqa_paged_decode_h32_kv4_d128_ps1 (FlashInfer-Bench)](#) ## What the kernel does Single-query GQA paged-attention decode: 32 query heads sharing 4 KV heads, head_dim = 128, page_size = 1. One query token per request, paged KV cache with one slot per page. The reference is FlashInfer. ## The solution 計算カーネルにおける最後のブロックの融合リダクション。各分割プログラムは、スクラッチ領域に部分結果 (m, l, acc) を書き込みます。アトミックな完了カウンターが最後に到着した分割プログラムを選出し、そのプログラムがすべての部分結果をマージして、次の呼び出しのためにカウンターをリセットします（略記）： prev = tl.atomic_add(done_ptr + b * stride_db + kvh * stride_dh, 1, sem="acq_rel", scope="gpu") if prev == (NUM_SPLITS - 1): m_part = tl.load(m_ptr + ...) l_part = tl.load(l_ptr + ...) acc_part = tl.load(acc_ptr + ...).to(tl.float32) valid = l_part > 0.0 m_part = tl.where(valid, m_part, -float("inf")) m_final = tl.max(m_part, axis=1) alpha = tl.exp2(m_part - m_final[:, None]) # rescale, finalise, then store 0 to done_ptr acq_rel/gpu スコープのセマンティクスを持つアトミック演算は、選定されたブロックが部分的な結果を安全に読み取るために必要な順序付けを保証します。この集約処理は、別個の実行として起動されるのではなく、計算カーネル内に融合されています。 **対数基底 2 のオンラインソフトマックス。** クエリはエントリー時点で sm_scale * log2(e) によって事前スケーリングされており、内部ループでは tl.exp2 が使用され、最終的な LSE（Log-Sum-Exp）は m + log2(l) で計算されます。これはハードウェアの ex2.approx.f32 命令に直接マッピングされます。 **2段階の形状認識ディスパッチ。** Python のカスケード処理により、バッチと平均シーケンス長から (NUM_SPLITS, split_block_n) が選択され、その後第 2 のカスケードでカーネル変種とそのタイルサイズ（BLOCK_N, num_warps, num_stages）が選択されます。 報酬ハッキングは 3 つのベンチマークすべてで対処すべき課題でしたが、SOL-ExecBench では特に困難でした。いくつかの候補者は、より高速なカーネルを実装するのではなく、評価セットアップを悪用しました：出力のキャッシュ化、永続状態への依存、またはタイミングハーネスの詳細を利用することです。 そのため、私たちはすべてのベンチマークにおいて、正しさの監査を研究システムの一部として扱いました。有望な改善点は、本質的なカーネルの向上とベンチマーク固有の抜け道を区別するために設計された、段階的に厳格化する自動チェックを通じて通されました。これにより報酬ハックが大幅に減少し、ループそのものの重要な一部となりました：検索が強力になるにつれて、評価者もまた強くなければなりませんでした。 SOL-ExecBench は、私たちのシステムが AI スタックの全く異なる部分を改善する能力を示しています。これは、低レベルの実装選択について推論し、候補となるカーネルを生成し、正しさとパフォーマンスのチェックを実行し、関連するタスク間で有用なパターンを転送することを必要としました。 ## 次のステップ これらの結果は、私たちのシステムが AI 学習およびインフラストラクチャの課題において最前線を押し広げられるという初期の兆候です。特に目標が明確に定義され、測定可能であり、多数回の評価を迅速に行える場合に有効です。このシステムは、多くの発見を積み重ねることで進展しました：新しい最適化手法の発明、より厳しい制約下での既存概念の再構築、重要な実装詳細の調整、そしてモデル化、最適化、システム層にわたる改善の組み合わせです。 本稿全体を通じて、特に検索能力が高まるにつれて、重要な課題の一つは報酬ハッキング（すなわち、システムが意図したタスクを解決するのではなく、タスクの文字通りの要件を満たして高得点を獲得しつつも、その意図を裏切る抜け穴を利用することを防ぐこと）です。このような報酬ハッキングを回避・検出するために、AI支援および/または人間のフィードバックを用いて報酬ハッキング検出器を反復的に改善するなどの多くの手法を実装しました。より困難な実世界アプリケーションに取り組み、より強力な自動 AI 研究アルゴリズムを作成していくにつれて、この対策は引き続き必要になると予想されます。タスクの文字通りの要件ではなく、その精神（spirit）を解決するようにこれらのシステムを整列させることは、安全かつ有益な形で知識発見を自動化し、再帰的に自己改善を行うシステムの創出における大きな課題となります。私たちは、この本質的な問題に取り組むことを楽しみにしています。 ここで得られる多くの成果は効率性の向上をもたらします。これは重要です。なぜなら、AI の進展は単に大規模モデルやより多くの計算資源によるものだけでなく、既存のシステムをより高速に学習させ、より安価に実行し、ハードウェアをより効果的に活用することによってももたらされるからです。私たちは、このようなシステムが知能のコストを削減すると予想しています：まず今日時点のシステムにおけるより良いエンジニアリング上のトレードオフを見つけることで、そして長期的にはフロンティア研究プロセスそのもののより大きな部分を自動化することで。 私たちは、これらの実行から得られた成果物をオープンソース化し、他の人々がシステムの出力を検証し、それを基に構築できるようにしています。自動化された研究をより有能で人類にとって有益なものにするシステムを構築することに興味がある場合は、[参加を申請してください](mailto:talent@recursive.com)。 脚注 - 私たちの結果は、Modal HGX H100 8-GPU ノードで得られ、Andromeda HGX H100 8-GPU ノードでもノイズの範囲内で独立して数値を再確認しました。公式ハードウェアである PrimeIntellect HGX H100 8-GPU ノードへのアクセス権限を得てから、リーダーボードへの提出を待っています。

自動化された AI 研究への第一歩（12 分間の読了）

背景や根拠まで確認しますか？

調べる

選ぶ

サイト