LLMはGPUの専門家を置き換えるのか――CUDAの知識をApple Siliconへ移すK-Searchが示すもの

こちらも参考に: https://chinoba.org/research/ai-infrastructure-hardware/

LLMが、GPU専門家の手を借りずに、高度に最適化されたGPUカーネルを書けるのか。

さらに、CUDAで長年蓄積されてきたNVIDIA GPU向けの最適化知識を、Apple Siliconのように設計思想もプログラミング環境も異なるハードウェアへ移せるのか。

この問いに対して「LLMに一度コードを書かせるだけ」という条件を付ければ、答えは今でもほぼノーに近い。カーネル最適化では、アルゴリズムの理解だけでなく、メモリ階層、並列度、同期、命令、コンパイラ、入力サイズ、実機の挙動が絡み合うからだ。

しかし、UC Berkeley Sky Labと協力して進められたK-SearchをApple Siliconへ拡張した取り組みは、問いの立て方を変える。重要なのは、LLMが単独で完成品を当てるかではない。LLMを「仮説を立てる探索者」とし、実機計測を「選別と学習の基準」とすることで、異なるアーキテクチャにも最適化の知識を移せるか、である。

BAIRの報告によれば、進化的探索で得たAttentionカーネルはAppleのネイティブMLX Attentionカーネルの約97%の性能に到達した。Mamba SSMカーネルでは、コミュニティのMLX-LM実装に対し、prefillで最大約20倍の高速化を示したという。いずれもGPU性能エンジニアが個別に手作業でチューニングした成果ではなく、LLMと計測駆動の探索を組み合わせて得た結果である。
BAIR: From CUDA to MLX: How K-Search Brings Decades of Kernel Expertise to Apple Silicon

GPUカーネルとは何か

GPUは、大量の小さな演算を同時に走らせることに特化したプロセッサである。LLMの推論では、行列積、Attention、正規化、活性化関数など、非常に多くの同型計算を繰り返す。GPUカーネルとは、そのうちの一つの処理をGPU上で並列実行するための小さなプログラムである。

たとえばAttentionでは、入力ベクトルから関連度を計算し、正規化し、値ベクトルを重み付きで集約する。この処理を素直に複数の演算へ分けると、その都度メモリへの読み書きが発生する。高性能カーネルは、複数の処理を融合し、必要なデータを近いメモリに置き、読み込みと計算を重ね、同期を減らすことで、同じ数式を桁違いに速く実行する。

ここで難しいのは、速いコードに普遍的な形がないことだ。

• 演算量が多ければ、計算器をどれだけ埋められるかが支配的になる。
• データ移動が多ければ、メモリ帯域とアクセスの規則性が支配的になる。
• 小さな入力では、並列化や同期のための余分な処理がかえって遅くなる。
• 大きな入力では、分割、パイプライン、タイルサイズが結果を左右する。

CUDAはNVIDIA GPUを対象にしたプログラミング基盤であり、CUDAカーネルには、スレッドの割当て、共有メモリ、レジスタ、Tensor Core、非同期コピーなどを使い分けてきた膨大な経験が埋め込まれている。一方、Apple Siliconでは統合メモリを持つApple GPU上で、MLXというAppleの機械学習フレームワークとそのカーネル環境が用いられる。CUDAのコードをそのまま移植しても速くならないのは当然である。

「コード移植」ではなく「最適化意図の移植」

K-Searchの核は、ソースコードを少しずつ書き換えるだけの探索ではない。最適化の意図と、その意図を実装するプログラムを分ける。

たとえば、次のような意図を探索木の中に残す。

• メモリ帯域が律速なら、不要な中間出力をなくして処理を融合する
• データ再利用があるなら、タイル化して近いメモリやレジスタに保持する
• メモリ待ちがあるなら、次のデータ読込みと現在の計算を重ねる
• 入力が小さいなら、分割や同期を減らして起動コストを抑える
• 入力が大きいなら、より多くの並列単位へ分解して演算器を埋める

LLMはこの段階で、カーネルの形、ボトルネック、次に試すべき構造変更について仮説を立てる。次に、各アーキテクチャに合ったコードを生成し、対象ハードウェアでコンパイルする。正しさのテストを通過した候補だけを計測し、レイテンシやスループットの結果を探索木へ返す。

K-Searchの論文では、この仕組みをLLMとともに更新される「world model」として表現している。途中の変更が一時的に遅くなったり、実装が失敗したりしても、最適化の方針まで直ちに捨てない。メモリ配置を先に変更してからベクトル化する、といった複数段階の変換を追えることが要点である。CUDAからMLXへの拡張では、CUDAカーネルを完成コードとして再利用するのではなく、そこに含まれる設計知識を探索の初期知識として用いる。
K-Search論文

なぜ97%と20倍が同時に起こり得るのか

二つの数値は比べる基準が異なるため、切り分けて読む必要がある。

Attentionの約97%は、Appleが高度に最適化したネイティブMLX Attentionカーネルを基準にした到達度である。これは「自動探索でも、専門家が磨いた実装にかなり近づける」ことを意味する。ただし97%は、全ての入力形状・全てのApple製品・全てのモデルで同じという意味ではない。ベンチマークで定められた条件の結果である。

一方、Mamba SSMの約20倍は、コミュニティのMLX-LM実装を比較対象にした速度向上である。これは最適化の余地が大きい実装との比較であり、Appleの最適化済み基準を20倍上回ったという意味ではない。報告では、状態空間モデルの再帰計算を並列prefix scanとして実装することが大きな要素になっている。

この二つを併記する意義は明確だ。自動探索は、すでに極限まで最適化された基準に近づくこともあれば、まだ十分に最適化されていない実装を大きく改善することもある。ただし、常に前者を超える万能なコード生成器ではない。

似た事例とベンチマークは何を示しているか

K-Searchだけを見ると、LLMがGPU最適化をほぼ解決したようにも見える。しかし、評価の全体像はもっと慎重である。

K-Searchは、FlashInferのGQA、MLA、MoEなど複雑なカーネルで、OpenEvolveに対して平均2.10倍、MoEでは14.3倍の改善を報告している。しかし論文自身も、生成されたカーネルが専門家最適化済みのFlashInferを恒常的に上回るわけではないと示している。ここに現実的な境界がある。
K-Searchの評価結果

KernelBenchは、LLMがPyTorchの処理を正しく高速なCUDAまたはDSLカーネルに置き換えられるかを測る250タスクのベンチマークである。ここで重要なのは、コードの見た目やコンパイル成功ではなく、正確性と性能を実測する評価環境を提供したことにある。
KernelBench

さらにParallelKernelBenchは、複数GPUにまたがる実運用寄りの87問題を扱う。ここでは演算だけでなくNVLinkを通じたデータ通信、トポロジー、デッドロック回避、計算と通信の融合まで考えなければならない。2026年6月の報告では、最良のフロンティアモデルでも3回の試行で「正しく、かつナイーブな基準より速い」解に到達した割合は31%にとどまった。これは、LLM単体で高度なGPUコードを書けるという期待への、きわめて重要な反証である。
ParallelKernelBench

またKernelFoundryは、候補の多様性を保つMAP-Elites探索、プロンプト自体の進化、テンプレートのパラメータ最適化を組み合わせ、SYCLとCUDAの両方を対象にしている。ここでも主役は、LLMの一回の回答ではなく、候補生成・検証・計測・選択という閉ループである。
KernelFoundry

専門家は不要になるのか

答えは「すぐにはならない」である。ただし、専門家の仕事の重心は変わる。

従来は、専門家がカーネルの構造を設計し、タイルサイズ、メモリレイアウト、同期、パイプラインを何度も手で試し、性能の理由を分析してきた。探索型の仕組みが成熟すれば、専門家は全候補を手で書く人から、問題設定と評価を設計する人へ移る。

具体的には、次の責任はむしろ重要になる。

• 対象ワークロードと実運用の入力分布を定義する
• 正しさ、数値誤差、再現性、電力、メモリ使用量を含む評価基準を決める
• 探索を許す範囲と、安全に使えない最適化を制約する
• ベンチマークだけを速く見せる不正な近道を検知する
• 採用候補を本番環境の複数条件で再検証し、保守可能な形にする

これは、AI Agent時代における意思決定の問題にも似ている。LLMに最終判断を丸投げするのではなく、仮説の生成、実行、評価、採用を分け、それぞれに証跡を残す。GPUカーネル探索では、コンパイルログ、正しさテスト、計測値、入力条件、採用理由がDecision Traceに相当する。

結論：LLMが書くのはコードだけではない

K-Searchが示しているのは、LLMが突然GPU専門家を完全に代替した、という話ではない。

むしろ、CUDAで育った最適化知識を、対象ハードウェアで検証しながら再解釈し、Apple Siliconのような異なる環境へ適応する仕組みが現れた、という話である。価値の源泉は、LLMの生成能力そのものよりも、仮説、実装、正しさ検証、性能計測、次の探索を結ぶループにある。

単発のLLM生成は、今なお複雑なGPUプログラミングで高い失敗率を示す。だが、実機評価を組み込んだ進化的探索は、専門知識を再利用可能な探索資産へ変え始めている。

GPU最適化は、人が一度だけ正解を書く問題から、人とAIが実測を通じて正解に近づく問題へ移りつつあるのかもしれない。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance