世界を動かす技術を、日本語で。

コーデックスを用いた自動研究:232倍速いカーネルを達成した方法

概要

  • GPU Mode 主催の自動リサーチ型コンテストで バッチ化されたHouseholder QR分解 を実装
  • torch.geqrf 互換のコンパクトな(H, tau)形式を出力し、 232倍の高速化 を達成
  • 反復的な自動最適化ループフィードバック で性能向上
  • Householder反射とブロック化アルゴリズム の活用が鍵
  • 学びと課題、実装ヒント も含む体験記

GPU Mode QR分解コンテスト体験記

  • GPU ModeCore Automation による自動リサーチコンテスト開催
  • 問題は「バッチ化された正方行列のコンパクトHouseholder QR分解」のCUDA実装
  • torch.geqrf 互換の(H, tau)形式で出力
    • Hの上三角がR、下三角がHouseholderベクトル
    • tauは各反射子の係数
  • チェッカーはtorch.linalg.householder_product(H, tau)でQを再構成し、A ≈ QRやQの直交性を検証
  • リーダーボードは実行速度(幾何平均) で順位付け
  • 重要なサイズ は512×512、1024、2048、4096などのバッチ正方行列
  • 内部的に低ビット(FP16, FP8, NVFP4)利用可だが、出力はFP32精度を満たす必要

コンテストの自動リサーチ性

  • popcorn CLI による自動テスト・ベンチマーク・提出が可能
  • 形状ごとのフィードバックと全体のタイミングを即時取得
  • 無制限の提出 が可能(ただし間隔を空ける必要あり)
  • 14日間で 1500回以上提出 し、ループで高速化を追求

QR分解とHouseholder反射の基礎

  • QR分解 は行列Aを直交行列Qと上三角行列Rに分解
  • Householder反射 で逐次的に下三角成分をゼロ化
  • 各反射子は 一つの列をターゲット軸に写す ことで下をゼロに
  • コンパクト形式では、RはHの上三角、反射ベクトルは下三角、tauは別ベクトルに格納

Householder反射の数式と直感

  • 鏡の反射のように「 垂直成分を2倍引く」ことで反射ベクトルを構成
  • 反射子は vベクトル とスカラーtauで表現
  • 数式:ℋx = x − τv(vᵗx), τ = 2 / (vᵗv)
  • 逐次的に反射を適用し、最終的にAをRに変形

ブロック化Householderアルゴリズムの利点

  • 通常のHouseholder QRは 逐次依存性 が強く並列化しにくい
  • ブロック化では パネル単位(b列)で逐次処理 し、残りは WY表現 で一括GEMM
  • シリアルな作業量をパネル内に限定 し、後続は高速な行列積で並列化

自動最適化・ループエンジニアリングの学び

  • TritonやCUDA の基礎知識があると LLMへのプロンプトも精度向上
  • ドメイン知識なしでも 自動ループとフィードバックで大幅な高速化が可能
  • ClaudeやGPT-5.5 との対話で設計方針を決定
  • 現代のLLMトレーニング最適化手法 (Shampoo, Muonなど)にもQR分解は応用

反省点と実装ヒント

  • 早期からブロック化アルゴリズム に注力すべきだった
  • 逐次部分の最小化とGEMM活用 が性能の鍵
  • 提出ループの効率化ログの活用 でボトルネック特定
  • 低ビット演算の活用メモリアクセスパターン最適化 も有効

まとめ

  • 自動リサーチ環境反復的な提出ループ が高速化を牽引
  • Householder反射の理解とブロック化アルゴリズム が高性能の要
  • GPUカーネル最適化 の学びと現代機械学習への応用可能性

参考文献・謝辞

  • GPU Mode Linear Algebra Kernels in the Age of Researchシリーズ
  • torch.geqrf, torch.linalg.householder_product 公式ドキュメント
  • GatedDeltaNet, Shampoo, Muon などの関連論文
  • コンテスト運営、コミュニティ、フィードバック提供者

Hackerたちの意見

最近、DeepSeek v4の新しいリリースを試してみたくてね。半放置状態の動画圧縮コーデックのリポジトリを使って、いつものベンチマーク -> プロファイル -> 検証 -> 研究 -> 改善のループをやらせたんだ。このコーデックを選んだのは、作者がビットストリームの検証ツールを入れてるから、自分の実装を試しても壊れないようになってるんだよね。エージェントにはコンパイラのプロファイラーと、素晴らしい出力を持つIntelのVTuneにもアクセスさせた。数時間で、LLMがSSEとAVXの圧縮・解凍アルゴリズムの実装を生成して、シングルコアでほぼパフォーマンスが倍増したんだ。それから、NVIDIAのNSIGHTプロファイラーを使ってCUDA実装を作るように頼んだら、そっちもいい感じで進んでる。個人的には、LLMはPrologや線形プログラミングの進化版みたいに扱うべきだと思ってる。制約を与えて、正しさを検証する方法を持たせて、明確な目標を与える。LLMが自分で検証して修正できるなら、ほぼ自動操縦で放置できるよ。

DeepSeek-V4-Flashを使ってカーネルの自動研究も試してみた。FlashAttentionの最適化作業に1〜2時間かかって、費用はたったの0.2ドルだった。これで、AIエージェントに多くの明確に定義された制約最適化問題をオフロードする準備が整ったと思う。

まさに俺もそうやって使ってる。放置されたリポジトリじゃなくて、ベンチマーク -> プロファイル -> 検証 -> 研究 -> 改善のループでね。

最近、GoogleのC# protobufライブラリで似たようなことをやったんだ。dotnet gRPCでuint32バッファのストリーミングをしているときに、CPUがボトルネックになっていることに気づいたんだ。それで、ClaudeにC#/.NETの実装とC++のバージョンを比較してもらったら、C++版にあるいくつかの安価な最適化がC#ライブラリには欠けていることがすぐにわかった。もしPRをマージできる手助けができれば、今までやった中で一番のインパクトになると思う。Rust版とも比較したけど、特定の最適化があったんだ。人気のあるTokio/Prostライブラリにはそれがなかった。適切なガードレールがあれば、LLMは根本原因や特定のパフォーマンスボトルネックを見つけるのがめちゃくちゃ早いんだよね。

俺はこの方法で古いゲームのROMをデコンパイルするのに成功したことがたくさんあるんだ。言う通り、正しさを検証する方法を与えて、ループに入れたら、かなり驚くべき結果が出るよ。 https://github.com/qarl/arcade-js

これが正しい方法だよ。alphaevolveの論文に載ってる技術をチェックして、自分の設定に合うか試してみて。

MacOS用のネイティブWineを、Win32 FEXサポート付きで数日中にリリースできることを期待してるよ。claudeとcodexがwinquakeやエイジ・オブ・エンパイアをプレイしてるのを見たり、Firefox 52のデバッグサポートを見たりするのはすごく面白かった。

Opus 5とFable 5を使って、Raspberry Pi 4で4K 10ビットHEVCのリアルタイムトランスコーディング(1080pやそれ以下のSDR AVCに)をやっと実現できたよ。最適化されたNEONカーネルを書くのがすごく得意だった。Argon HEVCハードウェアデコーダーはSAND30というタイル形式を出力するんだけど、これが扱いにくくて他のものであまりサポートされてないんだ。大きなパフォーマンスの問題は、変換とスケーリングにあったけど、実際にはメモリの移動が多くて、複数のステップを一つのカーネルにまとめることで十分速くなったよ。異なる組み合わせのNEONカーネルを書くのは手作業だと永遠にかかりそうだった。自動研究が似たような結果に達したかどうか気になるけど、リアルタイムで動くところまで持っていくのにはかなりの指導が必要だった。興味がある人は、ffmpegがここにあるよ:https://github.com/poizan42/jellyfin-rpi-ffmpeg、そして標準のjellyfinと一緒に使うためのshimがここにあるよ:https://github.com/poizan42/jellyfin-rpi-ffmpeg-shim

AIの時代にMojoプログラミング言語は役に立つのかな?

自分のRustでのJSONLogic式評価エンジンの実装でも似たような経験があったよ。テストスイートがあって、何千ものケースとベンチマークスクリプトがあったから、いくつかの基本的なヒントを与えて、いろんな最適化技術を試すことができたんだ。結果はすごく良かったよ。フルベンチマークテストで1.6秒から200ミリ秒にまで短縮できた。最初の3バージョンは手書きで3年間メンテナンスしてたけど、4番目のバージョンは1ヶ月も経たずに出てきて、パフォーマンスもすごく良い。

すごい!もし一人のエンジニアがこれをできるなら、OAIやAnthropic周りの人たちがかなり弱く見えてくるね。

これはトップの投稿には全然及ばないけど、もし一人のエンジニアがトップのカーネルを作れるとしても、何千人ものエンジニアがいて、無限のトークンと、一般には公開されていない強力なモデルがあったら、ラボにかなりのアドバンテージがあると思わない?

Hacker Newsで議論の続きを見る