単一GPU向けのCUDAカーネルなら、最先端のコーディングモデルがかなり書けるようになってきました。ところが複数GPUにまたがる並列カーネルになると、正解率は3割を切り、ベースラインを上回る実装はさらに少なくなります。Together AIが2026年6月23日に公開したベンチマーク「ParallelKernelBench」が、そのギャップを数値で示しました。

この記事では、なぜマルチGPUが単一GPUと別問題なのか、87問のベンチマークがどう設計されているか、各モデルの結果が何を意味するかを整理します。

  • ParallelKernelBenchが測定する課題の内容
  • Megatron-LMやDeepSpeedなど実コード由来の87問題の構成
  • GPT-5.5やClaude Opus 4.7など主要モデルの正解率・高速化率
  • 失敗の主因と、一部で公開実装を上回ったカーネルの例

https://www.together.ai/blog/parallelkernelbench

単一GPUの成功がマルチGPUでは通用しない理由

LLMによるGPUカーネル自動生成は、KernelBenchなどの単一GPUベンチマークで着実に進んでいます。一方、本番の大規模学習・推論では複数GPUをまたぐ処理が前提です。Together AIの調査では、通信オーバーヘッドだけで推論レイテンシの20%超を占めるケースもあります（参考）。

マルチGPUカーネル生成が難しい理由は、主に3つに整理できます。

  • 設計空間の爆発 — テンソル並列、データ並列、エキスパート並列、コンテキスト並列、シーケンス並列、FSDP/ZeROなど、組み合わせごとに通信パターンが変わる
  • 性能モデルの変化 — 単一GPUのルーフラインモデル（計算とメモリ帯域が上限）は、マルチGPUではインターコネクト帯域がボトルネックになる
  • 転送方式の選択 — コピーエンジン、TMA（Tensor Memory Accelerator）、SMのload/store、NVLS（NVLink SHARP）など、経路ごとに性能特性が異なる

論文では、FP16テンソルコアのスループットはAmpereからRubin世代で10倍以上伸びた一方、NVLink帯域は約6倍にとどまったと指摘しています（参考）。計算が先に伸び、通信が追いつかない構造が、マルチGPU最適化の難しさをさらに高めています。

ParallelKernelBenchが課すタスク

ParallelKernelBench（略称PKB）は、マルチGPUカーネル生成を評価するオープンベンチマークです。各問題は、最適化されていないPyTorchとNCCL（NVIDIA Collective Communications Library。GPU間の集合通信を担う標準ライブラリ）の参照実装から始まります。モデルは、ハードウェアトポロジの説明を受け取ったうえで、PyTorchのSymmetric Memory（複数GPU間で対称に割り当てたメモリ領域。カーネル内からピアGPUのメモリへ直接アクセスできる）を使ったCUDAカーネルに書き換えます。

評価は3段階で行われます。

  1. 正しさ — ランダム入力で参照実装と出力が一致するか
  2. 速度 — PyTorch＋NCCLの非オーバーラップ実装より速いか
  3. ハードウェア利用率 — 通信を含むルーフラインモデルに対してどれだけ近いか

参照実装が標準的なPyTorch＋NCCLで書かれているため、新しいGPU世代が登場してもベースラインを維持しやすい設計です。問題データと生成カーネルはHugging Faceでも公開されています。

87問はどこから来たか

PKBの87問は、実運用コードベースから抽出されています。並列化の分類（タクソノミー）を先に作り、テンソル・コンテキスト・データ・エキスパート・シーケンス・FSDP/ZeROなどの並列戦略と、それぞれが生む通信パターンを網羅する形で問題を選びました。

出典コードベースには、次のような名前が挙げられています。

  • LLM学習・推論 — Megatron-LM、DeepSpeed、DeepEP、TensorRT-LLM
  • 強化学習・事後学習 — NeMo-RL
  • その他 — GNNルーティング、分散FFT、Gaussian Splattingなど

カテゴリ別の内訳は、テンソル並列17問、コンテキスト並列12問、エキスパート並列11問、データ並列9問、FSDP/ZeRO 9問など、実務で遭遇する並列パターンを幅広くカバーしています。デフォルト評価環境は8台のH100、1024×1024、bfloat16、5試行です。

最先端モデルでも正解は3割弱

Together AIはGPT-5.5、Claude Opus 4.7、Gemini 3 Pro、GLM-5.1、GLM-5.2、DeepSeek V4 Proを評価しました。ゼロショット（1回生成）では、最も成績の良いGPT-5.5でも87問中28問が正解、うち22問だけがPyTorch＋NCCLベースラインより高速でした。3回サンプリングして最良案を選んでも、正解は36問、ベースライン超えは27問。高速化も含めた指標fast1@3のピークは31%です。

指標 GPT-5.5 Claude Opus 4.7 Gemini 3 Pro
pass@1→3（正解数） 28→36 20→31 24→30
fast1@1→3（正解かつ高速化） 22→27 12→20 12→19

正解が集中するのは、集合通信プリミティブ、テンソル並列GEMM、Ulysses型コンテキスト並列など、オープンソースに実装例が多い領域です。パイプライン並列は全モデルが0問正解で、エキスパート並列やデータ並列も苦戦しています。

オープンソース系モデル（GLM-5.1、DeepSeek V4 Pro）は、単一GPUベンチマークでは高いスコアを出す一方、PKBではfast1@3がそれぞれ3%、1%にとどまりました。単一GPUの得意分野が、そのままマルチGPUに転用できないことを示しています。

失敗のパターンとエージェントによる改善

失敗の内訳は、モデルの能力によって質が変わります。弱いモデルはコンパイルエラーやテンソル形状の誤りが多く、推論能力の高いモデルはコンパイルは通るものの、出力不一致やデッドロックが主因になります。つまり、CUDAの文法よりも、ランク間のデータ分割・集合通信の順序・並列実行の推論がボトルネックです。

生成カーネルが使う通信方式も偏っています。コピーエンジンとSM load/storeが大半を占め、TMAやNVLS（NVSwitch上のインネットワーク削減）の利用はほぼ見られません。動くカーネルと、ハードウェア上限に近いカーネルの間に大きな隔たりがあります。

Gemini 3 Proにコンパイル・正誤判定・速度計測ができるエージェント環境を与えた実験では、正解数が24問から35問に増え、ベースライン超えは26問に達しました。ただし約20ステップで頭打ちになり、構文修正や単純なランタイムバグの修正が中心で、並列推論の壁は残りました。

公開実装を上回った「新規カーネル」も存在

全体としては厳しい結果ですが、一部の問題ではLLMが公開最適化実装のないカーネルを生成し、参照実装を上回りました。Together AIが挙げた例は次のとおりです。

  • NeMo-RLの語彙並列log-prob（Gemini 3 Pro）— GRPO学習ループの中核処理。NCCLのall-gatherを避け、対称メモリ上でlog-softmaxとトークン抽出を融合。最大2.06倍
  • Hyenaのコンテキスト並列フォワード（GPT-5.5）— all_to_allの繰り返しをNVLink直接読み込みに置き換え。最大1.72倍
  • SAM 3のマスクIoU重複除去（GPT-5.5）— 可変長all_gatherと密なmatmulを、対称メモリ上のビットパック＋popcountに集約。最大1.40倍

GEMM＋All-Gatherの問題では、生成カーネルが87.9μs、参照実装が320.6μsと、計算と通信のオーバーラップで大幅な短縮を達成した例も報告されています。

開発者にとっての示唆

PKBが示すのは、「LLMはGPUカーネルを書ける」という話と、「分散インフラを自律的に最適化できる」という話の間に、まだ大きな溝があるという事実です。単一GPU向けのベンチマークスコアだけでは、本番のマルチGPU最適化力は測れません。

現時点で実務に活かせるのは、集合通信やテンソル並列GEMMなど、モデルが比較的得意なパターンのたたき台生成です。エージェントにコンパイル・実行フィードバックを回すと、構文や形状の修正は進みますが、ランク協調の設計は人間のレビューが欠かせません。PKBはオープンソースとして公開されており、自社ワークロードのマルチGPU最適化を試す際の共通評価基盤として使えます。今後はノード間通信（RoCE、InfiniBand）やTPUなど、より広いトポロジへの拡張も研究課題として挙げられています。