CodexにGPUカーネル最適化を『自動でリサーチさせながら』回したら232倍速くなった話

GPU Modeが主催したCUDAカーネル最適化コンテストで、個人開発者sankalp氏がOpenAIのCodexを使い、183人中12位・ベースライン比232倍の高速化を達成したという体験記を公開した。ブログ本文で確認できる範囲では、この結果を生んだのは特別な魔法のプロンプトではなく、Codexの/goal機能でモデルに数時間〜1日以上走らせ続けさせ、/btwという別スレッド機能で進捗だけを差し込みで確認する、という反復可能な運用法だった。

3行まとめ

• GPU Modeの「Linear Algebra Kernels in the Age of Research」コンテストで、QR分解カーネルをCodexに最適化させ、183人中12位・ベースライン比232倍を達成
• 14日間で1,500回以上の提出。カギは/goalでモデルに数値目標を渡し数時間〜1日走らせ続け、/btw（/side）で裏スレッドから進捗だけを尋ねる運用
• 3,000µs→1,800µsの局所最適に詰まった際は、有望な候補を3〜5個並行維持する「beam of candidates」と、単一の強力な「advisorモデル」に助言を求める運用で突破したとブログは説明している

コンテストの中身——QR分解カーネルの高速化

GPU Modeは、Core Automationと共催でこのコンテストを主催した。課題は、バッチ化された正方行列に対する「compact Householder QR分解」——torch.geqrfが返すのと同じ形式のQR分解をCUDAカーネルとして実装することだった。ブログ本文はこう説明する。

GPU Mode, in collab with Core Automation, recently hosted an auto-research themed contest. The problem statement was to implement batched square compact-Householder QR factorization aka QR decomposition. I placed 12th out of 183 participants, ending up with a 232x speedup over the baseline solution.

（GPU ModeはCore Automationと共同で、最近「auto-research」をテーマにしたコンテストを主催した。課題はバッチ化された正方行列のcompact Householder QR分解——いわゆるQR分解の実装だった。私は183人中12位となり、ベースライン解に対して232倍の高速化を達成した）

提出はpopcornというCLIを通じて行い、形状ごとのタイミングと幾何平均をチェッカーがフィードバックする仕組みだった。ブログはこの設計自体が「エージェントが望む、締まったフィードバックループ」を生む土壌だったと指摘している。14日間のコンテスト期間中、sankalp氏は1,500回以上の提出を行ったという。

なぜCodexを選んだか

sankalp氏は当時ChatGPT Pro（月200ドル）とClaude Pro（月20ドル）の両方を契約していたが、コンテストではCodexを主力に据えた。理由をこう書いている。

I chose Codex mainly because: I had the bigger subscription. From prior experience, my intuition was that OpenAI models are better at Triton. /compaction works very well in Codex.

（Codexを選んだ主な理由は、より大きなサブスクリプションを持っていたこと、経験則としてOpenAIのモデルの方がTritonに強いという直感があったこと、Codexでは/compactionがよく機能すること、だった）

最初のステップは、Codex自身にproblem_statement.mdとAGENTS.md（提出方法・popcorn CLIの使い方を記載）、そして提出結果を記録するlog.mdを作らせるという、いわばハーネスのセットアップだった。ログは「どのアイデアが試されたか」を次のエージェントセッションが確認するための記録として機能したという。

/goalでモデルを走らせ、/btwで覗く——具体的な運用法

ブログ本文が最も具体的に説明しているのは、/goalという機能の使い方だ。

if you want to make the model loop until a certain objective is achieved, use /goal. You can give specific, achievable, quantitative goals. […] At one point, this goal ran for over a day.

（モデルにある目標が達成されるまでループさせたいなら/goalを使う。具体的で達成可能な、数値化されたゴールを与えることができる。〔中略〕あるゴールは1日以上動き続けたこともあった）

実際に与えたゴールの例として、次のプロンプトが引用されている。

"Use only Triton or CUDA and beat our active best's n = 512 timings. Try several ideas either by submitting directly to the leaderboard or using Modal profiling. Remove cuSolver altogether in the new set of experiments. We will only use it as a fallback."

（「TritonかCUDAのみを使い、現行ベストのn=512タイミングを上回れ。リーダーボードへの直接提出かModalでのプロファイリングで複数のアイデアを試せ。今回の実験セットではcuSolverを完全に排除しろ。フォールバックとしてのみ使う」）

数時間おきに指示を差し込み、夜間は監督なしで走らせ続けた日もあったという。ここでの教訓を、ブログはこう書いている。

A lesson I learned here: I often had the itch to check on my agents frequently, but you gotta trust it and let it do its work. Get out of the agent's way you must; steer it back only when it gets stuck.

（ここで学んだ教訓：エージェントを頻繁にチェックしたくなる衝動はよくあったが、信頼して仕事をさせなければならない。エージェントの邪魔をしないこと。詰まったときだけ軌道修正すればいい）

ループを止めずに進捗だけ確認する手段として使ったのが/btw（または/side）だ。

When using /goal, you can ask the model questions without pausing the loop by using /btw or /side. This creates a temporary thread with context from your main conversation.

（/goalを使っているとき、/btwや/sideを使うとループを止めずにモデルへ質問できる。これはメインの会話の文脈を引き継いだ一時的なスレッドを作る）

具体的な問いかけの例として「勝ってる？」「今のアクティブな提出にあるアルゴリズムや変更点は？」「直近のブレイクスルーは？」「次の最善のアイデアは？」といった質問が挙げられている。

108,803µsから1,805µsへ——構造変化10段階の記録

ブログには、幾何平均タイミングがtorch.geqrfを全形状で使う初期状態の108.8k µsから、最終的な1,805µs（-98.34%）まで落ちていく過程を10段階の構造変化として整理した表がある。ブロック化WY QRの導入（108.8k→10.2k µs）、TritonパネルとグループWY更新（10.2k→4.3k µs）、CUDAグラフ再生によるカーネル起動オーバーヘッドの削減（4.0k→3.4k µs）、V/Tレイアウトの融合アセンブリ（3.4k→2.75k µs）など、各段階でボトルネックの種類が変わっていったことが読み取れる。ブログはこの過程についてこう総括している。

There was a lot of back and forth on profiling the entire shape and then identifying the bottlenecks. For this problem, launch overhead and panel overhead dominated. We were rarely memory or compute bound.

（形状全体をプロファイリングしてボトルネックを特定する、という往復が何度もあった。この問題では起動オーバーヘッドとパネルオーバーヘッドが支配的で、メモリ律速や計算律速になることはほとんどなかった）

局所最適からの脱出——候補の並行維持とadvisorモデル

3,000µsから1,800µsへ進める区間で、モデルが同じアイデアの微調整を繰り返す「局所最適」に詰まる問題が起きたという。ブログが「idea diversity」の節で挙げている対策の中心は2つあり、いずれも複数モデルを競わせる話ではない。

1つ目は「beam of candidates」。それまでは常に単一のベスト候補とだけ新しい候補を比較していたが、有望な案を3〜5個並行して維持する運用に切り替えたという。

Beam of candidates: For a long time, I did a dumb thing. I kept a single best candidate against which new candidates were tested. […] With this observation, I introduced some instructions to maintain a beam of 3-5 candidates.

（候補の並行維持：長らく、私は愚かなことをしていた。常に単一のベスト候補とだけ新しい候補を比較していたのだ。〔中略〕この気づきをもとに、3〜5個の候補を並行維持する指示を導入した）

2つ目は「stronger advisor model」。AGENTS.mdに、ヘッドレス呼び出しclaude -pでアイデアやプロファイリングデータを取得するよう指示する、単一の強力な助言役モデルを使う運用だ。

Use a stronger advisor model that produces more varied ideas. In my harness, this would look like an instruction in AGENTS.md to encourage the model to use headless calls claude -p to get ideas, provide profiling data, etc.

（より多様なアイデアを出す、より強力なadvisorモデルを使う。私のハーネスでは、これはAGENTS.mdに「ヘッドレス呼び出しclaude -pを使ってアイデアを取得し、プロファイリングデータを提供する」よう促す指示として実装した）

ブログはこのほか「Human in the loop（自分が長時間停滞したときの秘訣として介入する）」「モデルにリスクを取るよう促す」「サブエージェントに調査やWeb検索をさせる」「NCUとModal両方のプロファイリング結果が一致するボトルネックに絞る」を挙げている。一方で、複数モデルにアイデアを競わせる設計そのものは、試していないと明記している。

A multi-agent swarm approach is something I thought of but didn't try.

（複数エージェントによるswarmアプローチは考えたが、試していない）

"Gemini"という語はブログ本文に一度も登場しない。将来のadvisorモデル候補としてブログが名指ししているのは「GPT-5.6 SolやFable」だ。

GPU Mode公式リポジトリで裏取りする——qr_v2は実在の問題だった

ブログの記述をGPU Mode自身の公開リポジトリ(gpu-mode/reference-kernels)と突き合わせた。problems/linalg.yamlには、このコンテストが対象とした4つの問題が並んでいる。

sankalp氏が取り組んだqr_v2の締切は2026年6月30日で、ブログのグラフに記載されていた「Jun 15 – Jun 30, 2026」というコンテスト期間と一致する。つまり「コンテスト自体は6月に行われた」という部分は、GPU Mode公式リポジトリのコミット履歴とは独立に、問題定義ファイルの締切日からも裏付けが取れた。

さらにqr_v2/task.ymlには問題の仕様がそのまま書かれており、ブログが説明していた「torch.geqrfが返すのと同じ形式のQR分解」という要約と、次の公式記述が一致することも確認した。

Implement batched square compact-Householder QR factorization. Input is A, a batch x n x n CUDA tensor in torch.float32. Return (H, tau) in the same compact Householder convention as torch.geqrf(A).

（バッチ化された正方compact-Householder QR分解を実装せよ。入力はbatch x n x nのCUDAテンソルA(torch.float32)。torch.geqrf(A)と同じcompact Householder形式で(H, tau)を返す）

また、GPU Mode Organization配下のGitHub公式リポジトリには、ブログが言及していた提出用CLI「popcorn」に対応するpopcorn-cli、採点バックエンドのkernelbot(READMEには「GPU Mode kernel competition platformのバックエンドサービス」と明記)、公式Webアプリkernelboardが実在しており、ブログで説明されていたコンテスト基盤(popcorn CLIでの提出→チェッカーによる採点)が実際のGPU Modeの仕組みと整合することも確認できた。

日付のズレ——コンテストは6月、公開は7月、HNは8月

このブログ記事のヘッダーには「08 Jul, 2026」という公開日が表示されている一方、本文中のグラフには「Jun 15 – Jun 30, 2026」というコンテスト期間の記載があり、batch候補の情報ではHacker Newsでの初出は2026年8月15日とされている。つまりコンテスト自体は6月に行われ、ブログは7月8日に公開され、Hacker Newsで話題になったのはそこからさらに1カ月以上後、という時系列になる。コンテスト期間の6月という部分はGPU Mode公式リポジトリの締切日(qr_v2:2026-06-30)と一致することを確認できたが、ブログ公開が7月8日である理由、Hacker Newsで8月まで話題にならなかった理由については、この記事では追えていない。

CUDAカーネルのチューニングは自分で手を動かしていない

GPUカーネル最適化そのものは専門性が高い領域で、この記事を書いている自分自身はCUDAカーネルのチューニングを実務で行った経験がなく、記事中の数値・手順の妥当性を自分の手を動かして検証したわけではない。GPU Mode公式リポジトリで裏取りできたのは、qr_v2という問題が実在すること・締切日・問題仕様のテキストまでで、183人中12位という順位やベースライン比232倍という数値そのものを、GPU Mode側の公開リーダーボードで直接確認したわけではない(kernelboardはJavaScriptで描画されるWebアプリで、この記事の確認方法では順位表の中身までは読めなかった)。あくまでsankalp氏のブログ本文に書かれている内容と、GPU Mode公式リポジトリで裏取りできる範囲の紹介にとどまる。

関連記事: AIコーディングアシスタント比較 / AIに毎回同じ説明をするのが面倒──「朝会」方式で引き継ぎをなくす運用

感想・指摘はコメント欄へ。