複数の独立した GPU カーネルを単一のカーネルに統合する最適化技術。ループフュージョンの GPU 版に相当するが、カーネルの起動境界でグローバルメモリが暗黙的に同期される点がループフュージョンと本質的に異なる。 ## 定義 GPU プログラムは通常、複数のカーネルを順次起動する。各カーネル起動の境界ではグローバルメモリが暗黙的に同期され、中間結果が一旦デバイスメモリに書き出される。カーネルフュージョンはこの中間書き出しを排除し、データをレジスタまたはシェアードメモリ上で次の処理ステージに直接渡す。 **フュージョンの三方式**(Wang ほか [378] による分類): 1. **inner thread 方式**: 各スレッドが両カーネルの処理を担当。スレッドブロックとグリッドサイズが一致する必要がある 2. **inner thread block 方式**: 各スレッドブロックが両カーネルを順次処理。スレッドブロック間の独立性が必要 3. **inter thread block 方式**: ブロック番号に基づいて処理を振り分け ## 主な効果 - **グローバルメモリ帯域幅削減**: 同一データを扱う複数カーネルの中間書き出しを排除(最も普及した理由) - **キャッシュ効果向上**: データがキャッシュ/レジスタ上に留まる - **カーネル起動オーバーヘッド削減**: 起動回数を減らす - **データ再利用の向上**: 中間結果をレジスタ経由で渡す場合、同一スレッドがデータを保持し続ける ## トレードオフ・制約 - **レジスタ圧力増大**: フューズされたカーネルはより多くのレジスタを消費し、オキュパンシーが低下する可能性がある - **スレッドマッピング制約**: 2 カーネルが同一スレッド数でない場合、一方をシリアライズしてフュージョンするトレードオフが生じる - **グローバル同期不要の場合のみ適用可能**: フューズする 2 カーネルが異なるスレッドブロック間の同期を必要とする場合、通常のフュージョンは不可(ブロック間同期技術が必要) - **「fusibility」の判定**: 中間結果をレジスタで渡すには同一スレッドマッピングが必要。シェアードメモリ経由ならブロックマッピングが一致すれば可 ## 横断的知見 - **LLM 推論の中核技術**: [[FlashAttention]]（Dao ほか 2022）はソフトマックス計算とアテンション行列積を単一カーネルに統合したカーネルフュージョンの代表例であり、HBM 往復を削減することで大幅な高速化を実現する。GPU 最適化の古典的技術が深層学習推論で再発見されている形態といえる。4 世代にわたる進化（FA1→FA4）はカーネルフュージョンの設計が GPU アーキテクチャの世代交代に密結合していることを示す——A100 ではタイリング＋オンライン softmax の融合設計が中心だったが、Hopper ではワープ特化で非同期テンソルコアを活かす融合パイプラインへ、Blackwell ではテンソルメモリ（TMEM）と 2-CTA MMA モードを用いた融合設計へと、融合の「何をオンチップに留めるか」の対象が世代ごとに変わっている。(Source: [[@2022__arXiv__FlashAttention - Fast and Memory-Efficient Exact Attention with IO-Awareness]], [[@2026__arXiv__FlashAttention-4 - Algorithm and Kernel Pipelining Co-Design for Asymmetric Hardware Scaling]]) - **10〜17% の性能向上がグラフアルゴリズムで報告**: Liu ほか(2019)はグラフアルゴリズムで Kepler 2012 で 10〜74% の改善を報告するが、13% の低下も記録。全メモリ集約的アプリケーションでフュージョンが効果的だが、文脈依存性が高い([[@2023__CSUR__Optimization Techniques for GPU Programming]] §A.1.8) - **カーネル分割(Kernel Fission)と双対**: 大型カーネルをより単純な小カーネルに分割するカーネル分割は、フュージョンとは逆方向の最適化であり、規則性向上・auto-tuning 適用性向上の目的で使われる。どちらを選ぶかはカーネルの複雑性・データ共有パターン・レジスタ圧力によって異なる - **Triton・CuTe-DSL は手書きカーネルフュージョンの実装コストを Python レベルに下げる**: LLM高速化の勉強会資料は、素朴な Python + Torch 実装がループ 1 回あたり 10〜100 μs を消費し GPU 上での実装が必須になることを述べ、CUDA を書く工数・専門エンジニア雇用コストを避けるための DSL として Triton と CuTe-DSL を挙げる。近年の FlashAttention や vLLM の実装が基本的にこれらで書かれているという観察は、[[カーネルフュージョン]]の実装がカーネルフュージョン概念そのものの理論的発展から、そのフュージョンを Python から低コストで書けるツールチェーンの発展へ重心を移していることを示す。(Source: [[@2026__SpeakerDeck__LLM高速化(勉強会)]]) - **カーネル境界の暗黙同期という同じ問題に、Rubin は「フュージョンしない」第 3 の解を持ち込む**: カーネルフュージョンはカーネル起動境界のグローバルメモリ暗黙同期を、複数カーネルを 1 つに統合することで排除する。これに対し [[NVIDIA Rubin GPU]] のタイルレベル・カーネル間トリガリングは、producer/consumer を別カーネルのまま維持しつつ、producer の広範な完了を待たずデータドリブンなポーリングで consumer の対応タイルを早期開始する。フュージョンが「境界を消す」解であるのに対し、Rubin の機構は「境界は残すが待ち時間を細粒度化する」解であり、フュージョンできない(スレッドマッピング不一致・レジスタ圧力過大などで fusibility 条件を満たさない)producer-consumer 対にも適用できる点が異なる。Blackwell の programmatic dependent launch(粗粒度の早期開始)から Rubin のタイルレベルトリガリングへの進化は、フュージョン不可能なケースへの対処がハードウェアスケジューリング側でも独立に進んでいることを示す。(Source: [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]]) ## 未解決の問い - FlashAttention のようなカーネルフュージョンは手動で設計されているが、FA4 の CuTe-DSL（Python ベース）実装はコンパイル時間を 20-30 倍短縮した。この方向は自動フュージョンとどう交差するか - 3 個以上のカーネルを同時にフュージョンする場合の最適な分割点はどう決定するか - Hopper の Non-Coherent MicroBenchmarks や Tensor Memory Accelerator (TMA) はカーネルフュージョンのトレードオフをどう変えるか - Rubin のタイルレベル・カーネル間トリガリングが十分に細粒度化した場合、カーネルフュージョンそのものの必要性は薄れるか。「境界を消す」設計と「境界の待ち時間を減らす」設計はどちらが今後の主流になるか、それとも用途(fusibility の有無)で使い分けが続くか