Codexでカーネルを232倍高速化：自動リサーチでQR分解コンテストに挑む
Auto-research with codex: How I achieved a 232x Faster Kernel
GPU ModeとCore Automationが主催した自動リサーチコンテストで、著者はCodexを活用してバッチ正方行列のQR分解（Householder法）を実装し、ベースライン比232倍の高速化を達成して183人中12位に入賞。本記事では、ブロック化HouseholderアルゴリズムとWY更新を採用したアプローチ、反復的なプロンプトとフィードバックループによる最適化の過程、局所最適解を脱するためのアイデア多様性の導入など、自動リサーチの実践的な知見を詳述する。
エージェントはタイトなフィードバックループを渇望している。それによって、思う存分ヒルクライムできるのだ。
HNでの議論
92- Almondsetat
ここ数日、新しい決定版となるDeepSeek v4リリースを試してみたいと思っていました。半ば放棄されたビデオ圧縮コーデックのリポジトリを与え、通常のベンチマーク→プロファイル→検証→リサーチ→改善というループを実行するように指示しました。このコーデックを選んだのは、作者がビットストリーム用の検証器を含めており、独自実装を試す場合に何かを壊さないようにできるからです。エージェントにはコンパイラのプロファイラと、素晴らしい出力を持つIntelのVTuneへのアクセスを与えました。数時間で、LLMは圧縮・解凍アルゴリズムのSSEおよびAVX実装を生成し、シングルコアでほぼ2倍のパフォーマンスを達成しました。次に、NVIDIAのNSIGHTプロファイラをガイドとしてCUDA実装を作成するよう依頼したところ、それも良い仕事を始めました。個人的には、LLMはPrologや線形計画法の高度なバージョンとして扱うべきだと思います。制約を与え、正しさを検証する方法を持ち、明確な目標を与えるのです。LLMが自己検証して軌道修正できるなら、基本的にオートパイロットに任せておくことができます。
- augment_me
このコンペで注目すべき点の1つは、上位10のソリューションのうち8つが、すべてこの方法で最適化されたもので、コンペの入力以外では完全に壊れてしまったことです。OODシェイプでテストしたときに壊れなかった唯一のソリューションは、GPUプログラミングに詳しい専門家によって作られたもので、2万5千行のCUDAを作成せず、妥当な範囲でソリューションを追跡・調整しました。このことから得られる教訓は、これらのアプローチは常に特異性を解決するものですが、モデルを一般的なソリューションに導くことははるかに難しいタスクであるということです。つまり、特定のモデルシェイプ向けの推論プロバイダーであれば、素晴らしい、ぜひやるべきです。オープンソースライブラリのメンテナーであれば、これは役に立ちません。
- lmeyerov
GFQLのためにカスタムバリアントを作るのは本当に魅力的でした。GFQLは、CPU+GPU向けの最初のOSS組み込み可能なCypherプロパティグラフクエリエンジンです。
- polarsのような新しいバックエンドの立ち上げを加速し、新しいレイジーモードとプランナーを含む、根本的に新しいパスを実現しました。
- 当初はGPUベンチマークのトップスコアを目指していましたが、現在はCPUスコアでもトップを維持しています！
長期的には、これによってクエリエンジンとは何かという考え方が再考されることが、私にとってより興味深いです。現在、私たちは特に自社のユースケース、主要な業界ベンチマーク、ユーザーからのワークロードにおいて、全体的に最速にしています。同時に、JITやマルチステージコンピューティングと同様に、ユーザーが実行できる新しい事前最適化技術を検討しています。これは、カスタムインデックスをプラグインするよりも興味深いものです。基本的に、私たちのエージェントが高速な特化を実行できるなら、ユーザーのエージェントにも公開できる安全なフックがあるはずです。
- tosh
トレーニング資料は、GPUカーネルとSIMDに関して特に豊富であるように思えます。モデルに取り組む研究者にとって有用だからという追加の努力があるのか、それとも、言語モデルが非常に適しており人間が苦手とするサブドメインに過ぎないのか、疑問に思います。
- sqquima
メタなコメントですが、AI生成ではないと思われる長文を読むのは新鮮でした。ありがとう。