LLM が高速なマルチ GPU カーネルを記述できるか？

LLM はマルチ GPU カーネルを自動化できるか？「計算」から「通信」へ、ボトルネックが移る今、AI が見落としているもの

現代の AI ハードウェアにおいて、ボトルネックは単一 GPU 内の「計算能力」から、複数 GPU 間を結ぶ「通信速度」へと移行しています。Together AI のシムラン・アローラ氏は、この複雑化するマルチ GPU カーネル開発において、LLM がコード生成は得意でも、性能最適化のための深い推論にはまだ限界があることを実証しました。

ボトルネックの転換点：計算から通信へ

数年前まで、GPU の性能を最大化する課題は、単一デバイス内でのメモリアクセス効率やカーネルの実行速度にありました。しかし、Flash Attention や Mamba といった効率的なアーキテクチャ、スパースアテンション、そして高速な DSL（ドメイン固有言語）の進化により、状況は一変しました。

現在では、AI ワークロードが巨大化し、分散トレーニングや推論において「通信」がランタイムの大部分を占めるようになっています。特に大規模モデルでは、計算リソースよりもネットワーク通信に時間を費やすことが多く、結果としてモデルの FLOP（浮動小数点演算）利用率が低下しています。

「現代の AI ワークロードは非常に巨大化しており、複数の GPU にまたがるカーネルが必要になっています。多くの生産環境において、通信がランタイムの大部分を占め、スケーリング時のモデル計算効率を低下させています。」

この変化は、ハードウェアベンダーごとのネットワークスタックの多様性も加速させています。NVIDIA の NVLink や NV Switch、AMD の XGMI、Google の TPU 間接続など、各社が独自のトポロジーとリンク技術を採用しています。特に NVIDIA は、NV Switch を介して通信自体に計算機能（オフロード）を持たせるなど、ネットワークスタックの進化を続けています。

GPU の階層構造と通信の難しさ

マルチ GPU カーネル開発が難しい背景には、ハードウェアの物理的な階層構造があります。GPU 内部では、演算ユニットのすぐ隣にあるレジスタメモリが最速ですが容量は小さく、L2 キャッシュや HBM（High Bandwidth Memory）へと進むにつれて速度は落ちますが容量が増えます。

複数の GPU をまたぐ場合、この階層に加えて PCIe、InfiniBand、NVLink などのインターコネクトが複雑に絡み合います。NVIDIA の NV Switch は、非ブロッキングファブリックを提供し、マルチキャストやリダクションといった通信プリミティブをネットワーク内でオフロードする能力も備えています。

しかし、計算ユニットの進化速度は通信インフラのそれよりも圧倒的に速いのが現状です。2020 年の A100 から 2024 年の B200 へ移行した際、BF16 テンソルコアの速度は 7.2 倍向上しましたが、ノード内通信は 3 倍、ノード間通信はわずか 2 倍の改善に留まりました。この「計算と通信のスピード差」が、最適化を困難にしています。

既存ツールと手動チューニングの限界

現在の開発現場では、主に以下の 3 つのアプローチが取られていますが、いずれにも課題があります。

1. 既存ライブラリの利用: NVIDIA の NCCL や AMD の RCCL は、大規模な連続データの転送には優れていますが、細かい粒度での通信や複雑な集約操作（collectives）の融合においては設計が破綻しやすく、ピーク性能を達成できません。単純なベースラインでは、通信可能な理論上限（roof line bound）の 50% も満たないケースが多発します。
2. コンパイラと DSL の活用: Triton Distributed や TileLink などのツールは存在しますが、ネットワーク技術が急速に進化する中で、これらのフレームワークが新しいハードウェアやプロトコルに柔軟に対応するのは困難です。例えば、Triton Distributed は H800 GPU で最適化されていても、H100 では効率的に適応できないという事例も報告されています。
3. 手動チューニング: DPP や Comet Ring Attention などの手法はピーク性能を達成できますが、特定の精度やアーキテクチャ向けに数ヶ月かけて手作業で調整する必要があります。一度の調整で他の環境へスケーリングするのは現実的ではなく、このアプローチのスケーラビリティは低いと言えます。

「Parallel Kernels」：基本原則の抽出

これらの課題に対し、著者らは「LLM に任せる前に人間がまず理解する」という方針を取りました。その結果、マルチ GPU カーネル設計を支配する少数のトレードオフとパターンを抽出し、「Parallel Kernels」として定式化しました。

これは、複雑なカーネル開発を最小限のプリミティブとパターンセットに還元したものであり、教育やベンチマークの基盤として機能します。このアプローチにより、通信メカニズムの選択やスケジューリングといった、性能最適化に不可欠な要素が明確になりました。

LLM の推論限界：コードは書けるが「最適化」はできない

Parallel Kernels ベンチマークを用いて、GPT-5.5 や DeepSeek などの最先端 LLM にマルチ GPU カーネル生成を依頼した結果、興味深い事実が浮かび上がりました。

LLM は CUDA の構文を理解し、エラーを修正してコードを生成する能力には長けています。しかし、メモリ階層の特性や通信オーバーヘッドといった「性能最適化のためのトレードオフ」を理解して推論する点では大きな限界が見られました。具体的には、通信メカニズムの適切な選択や、スケジューリングの最適化において失敗するケースが多発しました。

「LLM はカーネルを生成することはできますが、通信メカニズムの選択やスケジューリングといった、性能最適化のための深い推論には失敗します。」

これは、生成 AI がハードウェアの低レイヤーであるカーネル開発を完全に自動化できるという楽観論に、現実的な冷水を浴びせる結果となりました。AI エージェント形式でローカル環境での試行錯誤を可能にした場合、問題解決数は増加しますが、時間を延長しても性能向上は頭打ちになることが示されています。

結論：LLM を「推論補助」として再定義する時

本研究は、現代の AI ハードウェアが直面している通信ボトルネックと、それを解決するための複雑な開発課題を浮き彫りにしました。LLM はコード生成ツールとして有用ですが、複雑なシステム設計における推論補助として位置づけ直す必要があります。

業界は、LLM を単なるコード生成機として過信するのではなく、ハードウェアの物理的制約や通信のトレードオフを理解した上で、人間が設計した基本原則（Parallel Kernels）を補完するツールとして活用していくべきです。計算から通信へシフトした今こそ、AI と人間の役割分担を見直す時が来ています。