ここ数か月にわたり、私たちは複雑なソフトウェアを自律的に構築、保守、デプロイできるマルチエージェントシステムを開発してきました。その取り組みの一環として、ブラウザをゼロから構築させたり、First Proofベンチマークの研究レベルの数学問題を解かせたりするなど、さまざまな領域でこのシステムをテストしてきました。

最近では、CUDAカーネルの最適化にマルチエージェントハーネスを適用するという新たな課題に向けて、NVIDIAとの協業を開始しました。これは難易度の高い技術的課題であると同時に、実用上の影響も大きいテーマです。CUDAカーネルは、NVIDIA GPU上でAIモデルの学習と推論を支える中核的なソフトウェアです。カーネルが高速になるほど、GPUの利用効率が向上し、消費電力が減り、レイテンシが低下し、トークンあたりのコストも下がるため、プロバイダーはより大規模で高性能なモデルを、より多くのユーザーに同時に提供できるようになります。

私たちのマルチエージェントハーネスは、235件の問題に対して3週間にわたり自律的に稼働しました。このシステムは、Blackwell GPUカーネルをゼロから構築・最適化し、アセンブリレベルに至るまで対応することで、幾何平均で38%の高速化を達成しました。

この水準のパフォーマンス向上は通常、非常に経験豊富なカーネルエンジニアが何か月、あるいは何年もかけて初めて実現できるものです。マルチエージェントシステムはこれを数週間で成し遂げ、既存のアプローチでは現実的でなかったロングテールのカーネル問題にも対応しました。

#エージェントシステムの能力を測るカーネル最適化

長時間稼働するマルチエージェントシステムを評価する最良の方法の一つは、私たちでさえ正解がわからない、自由度の高い最適化問題を与えることです。カーネル最適化の問題は、この条件に当てはまります。既知の単純な差分を目標にするのではなく、システムが反復的に最適化できる測定可能な目標を与えられるからです。

現在、エンジニアはモデルを個々の数学演算に分解し、それぞれを個別に調整することでカーネルを最適化しています。これにより問題は扱いやすくなりますが、システム全体を横断して同時に最適化することで得られるはずの改善を、部分ごとの最適化では取りこぼしてしまうため、パフォーマンスを十分に引き出せていません。これまでGPUのパフォーマンスは、こうした手作業による単純化を超えて解空間全体を探索できないという制約に縛られてきました。

この実験では、私たちのマルチエージェントシステムがこうした制約の外で動作し、より広い解空間を探索して、より高速なカーネルを生み出せるかを確かめたいと考えました。

#問題生成とベンチマークのための SOL-ExecBench

NVIDIA は、Deepseek、Qwen、Gemma、Kimi、Stable Diffusion など、124 を超える実運用のオープンソースモデルから、SOL-ExecBench を使って 235 件の最適化問題を生成しました。合成データや単純化されたカーネルとは異なり、各問題は、LLM、拡散モデル、ビジョン、音声、動画、マルチモーダルのハイブリッドなど、さまざまなモデルアーキテクチャにおける学習または推論ワークロード上の現実的な制約を反映したものです。

また、27基のNVIDIA Blackwell 200 GPUで、マルチエージェントによるカーネル解法をベンチマークするためにSOL-ExecBenchを使用しました。SOL-ExecBenchは、カーネルのパフォーマンスを既存のソフトウェアベースラインや理論上のハードウェア性能限界と比較できる有効な評価手法です。エージェントがキャッシュのような不正な手法を使い、B200で実現可能な範囲を超えるパフォーマンスを示した場合、その結果はパイプラインによって無効と判定されます。

#実験の実施方法

マルチエージェントシステムは、パフォーマンス指標に基づいて自律ワーカー間の作業を分担・再配分するプランナーエージェントを導入することで、235 件の GPU カーネル最適化問題すべてを 1 回の実行で解きました。

調整プロトコル全体は、出力形式、ルール、テストを定義した 1 つの Markdown ファイルに収められていました。マルチエージェントシステムは、実行中にベンチマーク用パイプラインを呼び出すことを自律的に学習し、開発者の介入なしにカーネルのテスト、デバッグ、最適化を継続的に繰り返すループを生み出しました。

マルチエージェントシステムの能力をより正確に測るため、GPU 抽象化スペクトラムの両極にある 2 つの言語で、それぞれ別の実行で解答を書くよう求めました。

• インライン PTX を用いた CUDA C。これによりエージェントはレジスタや ISA レベルの命令に直接アクセスでき、システムが最も低いレベルでハードウェアを扱えるかを検証します。
• CuTe DSL。これは高水準で組み合わせ可能な抽象化を提供する一方、公開された学習データにはほとんど含まれておらず、システムが提供されたドキュメントだけをもとに新しい API を学べるかを検証します。

#38%高速化、最適化の19%で2倍超の改善を達成

マルチエージェントシステムのパフォーマンスは、次の2つの方法で示します。

• 幾何平均での高速化: ベースラインとして、単一のエージェントで最適化した PyTorch コードと比較します。
• Speed-of-Light (SOL) スコア: 対数曲線上で、理論上のハードウェア限界と比べてその解がどれほど優れているかを示します。スコア 0.5 は最適化済みの PyTorch ベースラインを表し、1.0 はパフォーマンスの限界です。

当社のマルチエージェントシステムは、235件中149件の問題 (63%) でベースラインを上回り、幾何平均比は1.38倍 (幾何平均での38%の高速化) を達成しました。

235件中45件の問題 (19%) では、マルチエージェントシステムはベースラインと比較して2倍を超える高速化を実現しました。システムが開発した最終的な解は、この公開リポジトリで確認できます。

#問題ごとに異なる最適化戦略

さまざまな種類の問題に対してこのシステムが適応できることを示すため、異なる最適化戦略に自然にたどり着いた3つの問題を取り上げます。

#ページドプリフィルを用いた BF16 Grouped Query Attention

ページドプリフィルを伴う Grouped Query Attention は、最新の LLM 推論スタックにおける一般的なプロンプト段階の処理です。十分に最適化された実装であれば、同じ GPU VRAM 上で、より長いコンテキスト、より高い並列性、より高いスループットを実現できます。

エージェントは CUDA C++ を使って、Llama 3.1 8B 向けの SGLang 推論から切り出したこのアテンション処理を最適化しました。エージェントはカーネルの改良を重ねる中で、メモリロードと演算向けの特定のハードウェア命令を活用し、永続カーネルによるスケジューリング改善を加え、入力サイズに合わせて徹底的に最適化しました。

私たちは、このマルチエージェントシステムのカスタムカーネルを、FlashInfer ライブラリにある人間が最適化したベースラインと比較しました。その結果、このシステムは SOL スコア 0.9722 でハードウェア限界に迫る解を生み出し、ベースラインに対して幾何平均で 84% の高速化を達成したことが分かりました。

私たちはさらに、SGLang の既存カーネルを置き換え、Llama 3.1 8B で Time to First Token (TTFT) が 3% 高速化することを確認しました。このアテンション処理は、サービング設定に応じてプリフィル処理の 2〜5% を占めるため、これは無視できないエンドツーエンドの高速化だと考えています。

#ゲーティング付き NVFP4 MoE Linear

この問題は、Qwen3 のような Mixture-of-Experts モデルで見られる一般的な 2 カーネル構成を表しています。ただし、入力テンソルと乗算の中間出力が NVFP4 (4 ビット浮動小数点) に量子化されている点が特徴です。

エージェントは、量子化処理が主なボトルネックであることを正しく見抜き、それに合わせてスケール計算と丸めを統合しました。量子化の際にスケーリングしてから丸める代わりに、事前計算したしきい値バケットを使って FP32 の値を直接 FP4 コードにマッピングしました。これは、NVFP4 で取り得る値が 16 個しかないため可能です。続いて、これらの最適化をより大規模なテストケースにも適用しました。

最終的に、エージェントは最適化済みの PyTorch ベースラインを上回り、幾何平均で 39% の高速化と 0.58 の SOL スコアを達成しました。

#BF16 行列積

行列積は、さまざまなハードウェアユニットとそのスケジューリングを深く理解する必要があるため、最適化が非常に難しいことで知られています。高い性能を発揮する行列積カーネル (GEMM) には、インライン PTX (アセンブリ言語に近いもの) 、パイプライン化、そしてカーネル内でのステージングが必要です。そのため、高速な GEMM の実装は、長らく非常に経験豊富なカーネル開発のエキスパートに限られてきました。

Cursor のマルチエージェントシステムは、特化した CUDA C++ の GEMM カーネルをゼロから生成し、NVIDIA の cuBLAS ライブラリにある、人間が綿密にチューニングしたベースラインに驚くほど迫る性能 (86%) を達成しました。このシステムは、Blackwell 固有の命令の使い方を自律的に学習し、ハードウェアに合わせてメモリの読み書きを最適化し、さらに対象の行列サイズに合わせて極限まで最適化することで、この結果に到達しました。

さらに、LLM の推論時のデコードで特に重要な small-M のテストケースでは、このマルチエージェントシステムのカーネルはライブラリを最大 9% 上回る性能を示しました。この結果は、最も難しいカーネル問題でさえ、マルチエージェントシステムがまもなくその分野のエキスパートを上回る可能性を示しています。

#ソフトウェア構築のためのマルチエージェントシステム

マルチエージェントハーネスはベースラインと比べて幾何平均で38%の高速化を実現しましたが、SOLスコアの中央値は依然として0.56にとどまり、さらなる最適化の余地が大きく残っていました。私たちは、より多くの計算資源があれば、マルチエージェントの解決策は大幅に改善できると考えています。というのも、数百件の問題とエージェントを、わずか27基のGPUで動かしていたからです。これでは、マルチエージェントシステムの性能を十分に引き出せません。GPUがさらに増えれば、このシステムはより深く、さらに斬新な解決策まで探れるようになります。

ソフトウェアにおける最も意欲的なタスクは、明確な解のないオープンエンドなものです。単一エージェントのシステムがここで苦戦するのは、モデルが学習中にすでに見たことのある、範囲の狭いタスクを最も得意としているからです。私たちは、このカーネル最適化の実験を、マルチエージェントアーキテクチャがソフトウェア構築の標準的なアプローチとして急速に定着していくことをさらに裏づける検証だと捉えています。なぜなら、こうしたアーキテクチャは学習データの分布から大きく外れた新しい問題にも取り組めるからです。

ここで私たちが研究している技術は、まもなくCursorの中核製品に反映されます。マルチエージェントの協調における難しい問題に取り組むことに関心があるなら、Cursorチームは hiring@cursor.com までぜひご連絡ください。