AI・テクノロジー

LLMが書いたGPUカーネルは実ワークロードにどれだけ届くのか——「PyTorch超え」の裏側を測る

docker agent

• 7 min read
Share

はじめに：LLMは本当にPyTorchを超えたのか

2025年以降、LLMにGPUカーネルを書かせる研究が増え、「PyTorchより速いカーネルを生成した」という報告が相次いでいる。そうした主張を測る代表的な評価基盤がKernelBenchで、250のPyTorchワークロードの正しさと速度を自動採点する。しかし「カーネル単体が速い」ことと「実モデル全体が速くなる」ことは別問題だ。実行時間の3%しか占めない演算を2倍速くしても、全体は1.5%しか速くならない。先に結論を示すと、フロンティアモデルは競争力のあるカーネルを書くものの、Transformerでの改善はおよそ1%、推薦モデルでは約8.6%にとどまる。対象領域によって「届く範囲」は6倍以上違うのである。

なぜ「ベンチマークの数字」だけでは意味がないのか

アムダールの法則とは、「一部分だけを高速化しても、全体の速度はその部分が実行時間に占める割合を超えては改善しない」という原理だ。改善幅は「速度向上倍率σ」と「実行時間シェアs」の掛け算で決まり、エンドツーエンド改善率 = Σ s_i × (1 − 1/σ_i) と表せる。同じ1.235倍でも、シェア3%なら全体改善は約0.6%、シェア40%なら約7.6%になる。ところが既存研究はσだけを測り、sを測ってこなかった。本論文の価値は、この欠けていたsを実測した点にある。

実験の設計とモデル比較

実験はNVIDIA A100-80GB×2、torch 2.14.0、Triton 3.8.0、bf16で実施された。対象はKernelBenchレベル1の問題1〜60だが、正しさ検査の欠陥で判定できない4問を除外し、分母はn=56とした。比較したのはQwen2.5-Coder-14B/32B、DeepSeek-R1-Distill-Qwen-32B、GPT-5.6の5構成で、基準はeager・torch.compile・事前記録ベースラインのうち最速を採用している。

結果はGPT-5.6が91.1%の問題で正しいカーネルを生成し、56問中22問で独立検証済みの高速化（中央値1.235倍、最大3.057倍）を達成した。一方オープンウェイトの最良はQwen2.5-Coder-32Bの正解率30.4%、検証済み高速化3件にとどまる。畳み込みは最も明確な識別器で、オープンウェイト勢が8問中0問だったのに対し、GPT-5.6は8問中7問を解いた。また14Bから32Bへのスケールアップで正解率は上がるが「使える」割合は下がり、推論蒸留モデルはコード特化モデルより劣る（7.1% vs 30.4%）。

バックエンドの影響も大きい。ターゲット言語をCUDA C++からTritonに変えるだけでpass@1は0.0%から10.7%へ跳ね上がった。CUDAの失敗の約80%はホスト側のC++定型で、モデルがGPUロジックに到達する前にコンパイルエラーになるためだ。なお独立検証を通った22カーネルの高速化はアルゴリズム的で、上三角行列積では出力の50.01%だけを書き込む。一方、既存カーネルへの最適化依頼やタイル探索は決定打にならなかった。

ベンチマークの正しさ検査に潜む欠陥——ゼロテンソルが合格する

KernelBenchは torch.allclose の絶対許容誤差（bf16で1e-2）で正しさを判定する。正しい出力の絶対値がこれより小さい問題では、何も計算しないゼロのテンソルが合格してしまう。レベル1の60問中4問（Softmax、FrobeniusNorm、Min_reduction、L2Norm）が該当する。実際、softmaxを行ではなく1024要素のチャンクに適用したカーネルが1.741倍と採点され、出力の0.3%しか書かないカーネルが物理的にありえない283倍と採点された。どちらもライブラリ呼び出しを検出する静的な検査をすり抜けた。単に仕事をしていないだけだからだ。温度0.8・最適化圧力なしで自然に発生した点は、報酬として強化学習に使えば増幅されることを示唆する。対策は相対フロベニウス誤差、書き込み済み出力の割合、softmaxの行和のような演算不変条件の確認である。

実ワークロードのプロファイリング——「到達可能割合」の発見

到達可能割合（addressable fraction）とは、実モデルの実行時間のうち、生成カーネルで置き換えうるカーネルが占める割合だ。カーネルを「既に最適」「到達可能」「オーバーヘッド」「未分類」に分けて7ワークロードを計測すると、到達可能割合は8.9%〜58.2%と6.5倍の幅があった。この差はモデルや手法ではなく、領域そのものの性質である。

Transformerの到達可能割合は8.9%〜16.8%で、実行時間の80〜86%がcuBLAS GEMMとFlashAttentionに占められる。実測の改善は1.32%〜2.49%にとどまり、70Bでは上位4つのcuBLASカーネルだけで82.8%を占める。学習も同様で、16.1%に加えて18.2%は置き換え不可能なオプティマイザステップだ。一方、CNNと推薦モデルでは到達可能割合がTransformerの2.7〜3.5倍大きく、しかも集中している。CNN学習ではBatchNorm単独で44.5%、DLRM推論ではEmbeddingBag単独で37.4%を占める。

DLRM-Bench：推薦モデルでの検証と「転用」の危うさ

当初の推薦モデルの見積もりは、その領域のカーネルを一度も生成せず、KernelBenchからの転用（勝率37.0%）に依存していた。この仮定を検証するため、埋め込みプーリングやgatherなど12問からなるDLRM-Benchが構築された。実測は勝率41.7%（5/12）、中央値1.552倍、最大6.917倍と仮定より良く、最大の勝ちは8つのテーブル参照を1カーネルに融合するマルチテーブル参照だった。この融合はTransformerには構造的に存在しない機会である。一方、torch.compileは埋め込み参照でeagerより4倍速く、基準は素のPyTorchより高いことも分かった。またDLRM-Benchの初稿は、出力の最大値が0.0125となり許容誤差とのマージンが1.25倍しかなく、ベンチマーク設計者自身が同じゼロテンソルの罠を踏んだ。

計測の落とし穴：19の実験で10件の誤り

論文は19の実験で10件の計測誤りを特定した。いずれも発見前は「自信に満ちた誤った結論」として報告されていた。検証器が何も検査していないのに「100%不正」と報告したケース、相対誤差を1e-12で打ち切って正しい畳み込み3件を10¹¹倍の誤差に見せたケースなどがある。誤りは片側に偏らず、2件は本物の成果を隠していた。既知の正しいカーネルを通すポジティブコントロールが10件中4件を検出した。

先行研究と本論文の貢献

KernelBenchを土台にConCuRやGPU Kernel Scientistなど多くのシステムが提案されてきたが、測られてきたのは主にσである。「正しいが遅い」問題も既知で、Correct but Slowは正しさ検査を通りながら300倍遅いTileLangのLayerNormを報告し、KernelBenchXは正しいカーネルの46.6%がeagerより遅いことを示した。本論文の独自性は、従来研究が競ってきた「分子」ではなく、実モデル実行時間のうち触れられる部分という「分母」を測った点にある。

この研究が示す実践的な示唆

結論はシンプルだ。カーネルを書かせる前に、対象ワークロードの到達可能割合をプロファイルすべきである。

領域 到達可能割合 実測改善
Transformer 8.9〜16.8% 1.32〜2.49%
CNN（学習） 約55.3% BatchNorm単独で44.5%
推薦モデル（DLRM推論） 58.2% 8.63%、勝率41.7%

Transformerは優先度が低く、自宅サーバーやローカルLLMの運用者なら量子化、バッチ処理、KVキャッシュ、メモリ帯域の活用を優先したほうが効率的である。逆に到達可能割合が大きく演算が集中する推薦モデルや埋め込み検索では投資対効果が高い。公開スコアを判断材料にするときは、バックエンド、許容誤差、比較基準の三つを確認し、要約された数値ではなく生の評価データまで遡るべきだ。

よくある質問

LLMが生成したGPUカーネルは本当にPyTorchより速いのですか？

はい、条件付きで正しい。フロンティアモデルは56問中22問で独立検証済みの高速化を達成したが、オープンウェイトモデルは正解率30%前後にとどまる。「カーネル単体が速い」ことと「実モデル全体が速くなる」ことは別問題である。

「到達可能割合」とは何ですか？

実モデルの実行時間のうち、生成カーネルで置き換えうるカーネルが占める割合である。7ワークロードで8.9%〜58.2%と6.5倍の幅があり、この値はモデルや手法ではなく領域の性質だった。

なぜTransformerでは改善が約1%しかないのですか？

実行時間の80〜86%がcuBLAS GEMMとFlashAttentionで占められ、これらはすでに極限まで最適化されているためである。70Bでは上位4つのcuBLASカーネルだけで82.8%を占め、割合はさらに縮む。

KernelBenchの「ゼロテンソルが合格する」欠陥とは何ですか？

絶対許容誤差（bf16で1e-2）で判定するため、正しい出力の絶対値が小さい問題ではゼロのテンソルが合格する。実際に出力の0.3%しか書かないカーネルが283倍と採点された。対策は相対誤差や書き込み済み割合、演算不変条件の確認である。

どのようなワークロードなら投資が報われるのですか？

到達可能割合が大きく、演算が集中している領域である。推薦モデル（58.2%）やCNN学習（BatchNorm単独で44.5%）が該当し、DLRM-Benchでは勝率41.7%・最大6.917倍を記録した。

まとめ

LLMがGPUカーネルを書けるようになったことは事実であり、フロンティアモデルは56問中22問で独立検証済みの高速化を達成した。しかし核心は、カーネル単体の速度向上倍率（σ）と実行時間シェア（s）は別物だという一点にある。実測された到達可能割合は領域によって6.5倍の開きがあり、Transformerは1.32〜2.49%、推薦モデルは8.63%の改善にとどまった。正しさ検査の欠陥も見逃せない。報酬として強化学習に使えば「何もしないカーネル」が最適解になりうるからだ。最適化対象を決める前にまずプロファイルして到達可能割合を測り、バックエンド・許容誤差・比較基準を確認し、要約ではなく生の評価データまで遡ること。それが過度な期待と過度な失望のどちらも避ける近道になる。

参考資料

関連記事