Kernel Fusion（運算元融合）
3 秒看懂
一句話定義： Kernel Fusion（運算元融合）是把 GPU/AI 加速器上原本需要多次獨立執行的計算”小任務”（kernel）合併為一次執行的編譯最佳化技術，核心目的是減少對 HBM（高頻寬視訊記憶體）的反覆讀寫和消除逐次核心啟動（kernel launch）的開銷。
類比： 如果把每次 kernel launch 比作去廚房燒一道菜，那 kernel fusion 就是把需要相同食材的五道菜一次做好端出來——省去了反覆進出廚房的跑腿時間，也避免了反覆開關冰箱門（HBM 訪問）的浪費。
為什麼此刻重要： 當 LLM 推論/訓練的瓶頸從”算力不夠”轉向”視訊記憶體頻寬不夠”（memory-bandwidth bound），Kernel Fusion 成為讓每一塊 GPU 發揮出更接近理論算力的關鍵編譯層技術，也是 FlashAttention、TorchInductor、Triton 等當前熱門工具的核心最佳化原理之一。
3 分鐘產業解釋
問題的本質：GPU “空轉”與”搬運浪費”
現代 AI 加速器（GPU、TPU 等）的計算能力（FLOPS）增長速度遠快於視訊記憶體頻寬（HBM GB/s）的增長速度。以 NVIDIA 產品線為例，HBM 頻寬與峰值算力的比值（bytes/FLOP，即每做一次浮點運算能搬運多少位元組資料）在過去幾代中持續惡化，這意味著晶片越來越容易”算完了等資料”。
在典型的深度學習推論中，一個 Transformer 層包含數十個子操作（element-wise add、LayerNorm、MatMul、softmax、殘差連線等）。如果每個操作都獨立作為一個 kernel：
- 每次 kernel launch 存在啟動開銷（GPU 命令佇列提交、引數設定、block/grid 配置等），在輕量推論或小 batch 場景下，這個開銷可能佔總延遲的顯著比例；
- 每次 kernel 結束時，中間結果必須寫回 HBM，下一次 kernel 再從 HBM 讀回來——而這些資料可能只需要用一次就丟棄了；
- 大量 HBM 頻寬被”搬運中間結果”消耗，晶片實際執行的有用計算量遠低於峰值。
Kernel Fusion 就是解決這個問題的最直接手段：把多個 kernel 合併為一個，讓中間資料留在片上（暫存器、shared memory / scratchpad、L1/L2 cache），只讀寫一次輸入、只寫出一次最終結果。
對產業的影響鏈
| 環節 | 影響 |
|---|---|
| 推論效率 | 頻寬利用率（MBU）可提升數倍；延遲降低 |
| 視訊記憶體容量 | 不必為中間結果預留視訊記憶體，等效擴大可用容量 |
| 硬體採購 | 同樣硬體上跑更大 batch / 更大型模型 → 降低單位推論成本 |
| 軟體棧競爭 | 編譯器/推論架構的融合能力成為差異化壁壘（TensorRT vs ONNX Runtime vs vLLM） |
| 算力利用率 | 雲端廠商 GPU 利用率提升 → 資本效率改善 |
15 分鐘專家深入
從 Roofline 模型理解 Fusion 的價值
Roofline 模型是分析 kernel 效能的基本架構：
Achievable Performance = min(Peak FLOPS, Peak BW × Arithmetic Intensity)- Arithmetic Intensity（算術強度）= FLOPs / Bytes（每搬運一個位元組能做多少次運算）
- 如果 kernel 的算術強度低於”屋頂拐點”（ridge point），它就是memory-bound——視訊記憶體頻寬是瓶頸，再多算力也用不滿。
大量深度學習子操作（逐元素加法、啟用函式、歸一化等）算術強度極低（遠低於 1 FLOP/Byte），屬於典型的 memory-bound kernel。Fusion 通過減少讀寫次數提升了融合後 kernel 的有效算術強度，使其更靠近 compute-bound 區域。
Fusion 的三種基本模式
┌─────────────────────────────────────────────────────┐
│ 型別 1：Vertical Fusion（縱向融合 / 生產者-消費者融合） │
│ │
│ Kernel A → 寫 HBM → Kernel B → 寫 HBM → Kernel C │
│ ↓ 合併為 ↓ │
│ Kernel ABC（中間結果留在片上暫存器/shared memory） │
│ │
│ 典型場景：Add + LayerNorm + Dropout 融合 │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ 型別 2：Horizontal Fusion（橫向融合 / 並行融合） │
│ │
│ Kernel A（處理資料塊X） Kernel B（處理資料塊Y） │
│ ↓ 合併為 ↓ │
│ Kernel AB（一次 launch 同時處理 X 和 Y） │
│ │
│ 典型場景：同一層的多個 head 或多個 channel 平行計算 │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ 型別 3：Input Fusion / Reduction Fusion │
│ │
│ 多個 kernel 讀同一份輸入，合併為一個 kernel 一次讀入 │
│ 或多個 kernel 各自 reduce → 合併為一次 reduce │
│ │
│ 典型場景：多路 loss 計算共享底層 feature │
└─────────────────────────────────────────────────────┘FlashAttention：Kernel Fusion 的標誌性案例
FlashAttention（Tri Dao, 2022）本質上是對 Transformer Attention 的極致縱向融合：
標準 Attention 實現：
S = Q × K^T ← 寫入 HBM（N×N 矩陣，N 為序列長度）
P = softmax(S) ← 從 HBM 讀 S，寫入 HBM
O = P × V ← 從 HBM 讀 P 和 V三步操作，中間矩陣 S 和 P 都必須落地到 HBM，O(N²) 的視訊記憶體佔用。
FlashAttention 的融合策略：
┌─────────────────────────────────────────────┐
│ 將 Q、K、V 按塊（tile）切分 │
│ 在一個 kernel 內完成： │
│ 1. 逐塊計算 S_block = Q_block × K_block^T │
│ 2. 在片上對 S_block 做 softmax（用 online │
│ softmax 演算法維護 running max/sum） │
│ 3. 立即乘以 V_block 累加到輸出 O │
│ 4. S_block 和 P_block 不寫回 HBM │
│ → 整個 attention 一個 kernel 完成 │
│ → 視訊記憶體 O(N²) → O(N) │
└─────────────────────────────────────────────┘FlashAttention 的核心創新不僅僅是 fusion 本身，還有**線上 softmax（online softmax / safe softmax with running statistics）**演算法，使得 softmax 可以分塊計算而不需要先看到完整的 N×N 矩陣。
這是為什麼 FlashAttention 被視為”改變遊戲規則”——它同時解決了頻寬問題和視訊記憶體問題。
編譯器視角：Fusion 是如何自動完成的？
在工業級 ML 編譯器中，Fusion 通常分為以下階段：
前端模型 (PyTorch / TF / ONNX)
│
▼
Graph IR 層（計算圖）
→ 運算元級 Fusion 模式匹配
→ 常見模式庫：Conv+BN+ReLU、Linear+Bias+GELU 等
│
▼
Tensor IR / Lower IR 層
→ 更細粒度的迴圈級 Fusion
→ Tiling（分塊）+ 記憶體層次分析
→ 確定資料留在哪個層級（暫存器 / shared / L2 / HBM）
│
▼
Hardware codegen（PTX / ROCm / 自定義 ISA）關鍵編譯器/工具棧：
| 工具 | 組織 | Fusion 能力概述 |
|---|---|---|
| XLA | TF/JAX 預設後端；模式匹配 + HLO 級 fusion；對 TPU/GPU 均適用 | |
| TorchInductor / torch.compile | PyTorch (Meta) | 通過 FX graph → Triton 程式碼 → 自動融合 |
| Triton | OpenAI | Python-like DSL，開發者可手動寫 fused kernel，門檻遠低於 CUDA |
| TVM / Relax | Apache | 基於 MLIR 的自動融合與程式碼生成 |
| TensorRT | NVIDIA | 推論最佳化器；內建豐富的 fusion pattern 庫 |
| cuDNN | NVIDIA | 手寫高效能 fused kernel（如 fused multi-head attention） |
| MLIR | Google/LLVM | 基礎設施層，提供多層級 IR，各廠商在此基礎上建置融合 pass |
Fusion 的工程挑戰
並非越融合越好：
- 暫存器壓力（register pressure）：融合過多計算會導致單個 kernel 使用過多暫存器，反而減少可並行執行的 warp 數量（occupancy 下降），可能降低 GPU 利用率。
- Shared memory 容量限制：片上 scratchpad 有限（NVIDIA A100 的 shared memory 為每 SM 最多 164 KB [配置依具體架構而定]），如果融合後的 kernel 需要的中間資料超過此容量，就必須部分溢位到 L2 或 HBM。
- 編譯搜尋空間爆炸：自動 fusion 的最優方案是 NP-hard 級別的搜尋問題，工業編譯器通常用啟發式規則 + auto-tuning 解決。
- 除錯困難：融合後的 kernel 難以分步排查錯誤。
- 跨運算元邊界最佳化：融合改變了執行順序，在有數值敏感操作（如 fused multiply-add 精度差異）時可能影響最終結果。
技術原理
一個具體的 Fusion 示例：LayerNorm 融合
標準 PyTorch 實現中，Transformer 層的一個典型操作序列：
# 未融合的 4 個 kernel
residual = x + shortcut # Kernel 1: Elementwise Add
normed = LayerNorm(residual) # Kernel 2: Reduce (mean) → Subtract →
# Reduce (variance) → Normalize → Scale + Shift
out = Linear(normed) # Kernel 3: MatMul
out = out + bias # Kernel 4: Elementwise Add融合後的邏輯（虛擬碼）：
fused_residual_layernorm_linear_bias_kernel(x, shortcut, W, b, gamma, beta):
// 所有操作在一個 kernel 內
// 使用 shared memory 儲存 reduction 中間結果
for each token in parallel: // 執行緒並行
r = x[token] + shortcut[token] // 殘差加法（片上暫存器）
// 線上計算 mean（Welford 演算法或兩次 pass）
mean = reduce_mean(r)
var = reduce_variance(r, mean)
normed = (r - mean) * rsqrt(var + eps) * gamma + beta // LayerNorm
out = matmul(normed, W) + b // 線性層
write_out(token, out) // 只寫最終結果到 HBM讀寫對比：
| 未融合 | 融合後 | |
|---|---|---|
| HBM 讀次數 | 4~5 次（各 kernel 分別讀輸入） | 1 次（讀 x + shortcut + W + b） |
| HBM 寫次數 | 3~4 次（各 kernel 寫中間結果 + 最終結果） | 1 次（只寫最終 out） |
| 中間資料暫存 | 全部經過 HBM | 全部在暫存器/shared memory |
融合決策的關鍵引數
┌─────────────────────────────────────────────┐
│ Fusion Decision Factors │
├─────────────────────────────────────────────┤
│ │
│ 1. 資料重用程度（reusability） │
│ → 中間結果被消費幾次？ │
│ → 1 次 → 強 fusion 候選 │
│ → 多次 → 可能需要快取策略 │
│ │
│ 2. 中間資料量 vs 片上容量 │
│ → 乘積累加的中間張量是否超過 │
│ shared memory / register 容量？ │
│ → 超過則需 tiling 或放棄 fusion │
│ │
│ 3. Kernel launch 開銷佔比 │
│ → 單個 kernel 計算量越小， │
│ launch 開銷佔比越高 → 越值得融合 │
│ → 大 MatMul 本身計算量足夠， │
│ launch 開銷可忽略 → 融合收益小 │
│ │
│ 4. 並行度影響（occupancy） │
│ → 融合後暫存器使用是否導致 │
│ 活躍 warp 數下降？ │
│ → 需要 profile 驗證 │
│ │
│ 5. 數值精度約束 │
│ → 融合改變了 reduce 和 elementwise │
│ 的執行順序，可能影響浮點結果 │
│ │
└─────────────────────────────────────────────┘Kernel Launch 開銷量化
NVIDIA GPU 上單次 CUDA kernel launch 的延遲通常在 5~15 微秒量級（具體取決於驅動版本、GPU 架構、是否使用 CUDA Graph 等）。在 LLM 生成式推論中，每個 token 的生成可能涉及數十甚至上百個 kernel。如果每個 token 的計算僅需數十微秒（小 batch、小模型），則 launch 開銷本身可能佔到總延遲的 **10%~30%**以上。
這就是為什麼 CUDA Graph（預先錄製 kernel launch 序列，一次性回放）和 kernel fusion 在推論場景中尤為重要——它們從不同維度減少 launch 開銷。
技術演進史
| 時間 | 里程碑 | 意義 |
|---|---|---|
| ~2010s 前期 | 手寫 CUDA fused kernel | 高效能團隊逐案手寫融合；門檻極高 |
| 2015~2017 | cuDNN 早期 fusion（Conv+BN+ReLU） | NVIDIA 在庫層面提供有限融合 |
| 2017~2019 | XLA、TVM 早期自動 fusion | 編譯器自動識別可融合 pattern |
| 2018 | TensorRT 加速推論 | 推論側 fusion pattern 庫商業化 |
| 2019~2020 | MLIR 提出 | 多層級 IR 奠定下一代編譯基礎設施 |
| 2022 | FlashAttention v1 釋出 | 手寫 fused attention kernel 引爆關注；證明極致融合的巨大收益 |
| 2022~2023 | Triton 語言生態成熟 | 降低 fused kernel 開發門檻；大量 Flash-Attention 變體用 Triton 實現 |
| 2023 | torch.compile / TorchInductor 正式釋出 | PyTorch 生態自動 fusion 成為預設能力 |
| 2023~2024 | FlashAttention-2/3, Flash-Decoding | 融合技術持續深化；支援更多硬體 |
| 2024+ | 自動 kernel 生成 + AI-assisted fusion | 編譯器開始用 ML 搜尋最優融合策略 |
技術路線對比
| 維度 | 手寫 Fused Kernel（CUDA/Triton） | 編譯器自動 Fusion（XLA/Inductor/TVM） | 推論引擎內建 Fusion（TensorRT/ONNX RT） |
|---|---|---|---|
| 效能上限 | 最高（專家精細調優） | 中高（受限於 pattern 庫和搜尋策略） | 高（針對常見模型高度最佳化） |
| 開發成本 | 極高（需 GPU 專家 + 數週/月） | 低（編譯器自動完成） | 極低（使用者無感） |
| 靈活性 | 最高（任意操作可融合） | 中等（受限於已知 pattern） | 低（僅支援架構內建 pattern） |
| 適用場景 | 核心熱點運算元（attention、MoE dispatch） | 通用模型、快速迭代 | 生產部署 |
| 代表 | FlashAttention、Triton kernels | torch.compile、XLA、TVM | TensorRT、vLLM 內建最佳化 |
| 可移植性 | 低（繫結特定硬體） | 中高（IR 層抽象） | 中（繫結推論架構） |
| 典型加速比 | 2x~10x（針對特定運算元） | 1.2x~3x（端到端） | 1.5x~5x（端到端推論） |
加速比為行業經驗性量級，具體數值取決於模型架構、batch size、硬體等因素。
上下游
上游：Kernel Fusion 需要什麼
| 上游要素 | 說明 |
|---|---|
| GPU 硬體架構 | 片上記憶體層次（暫存器檔案大小、shared memory、L1/L2 cache 容量）直接決定融合的上限 |
| 程式設計模型/ISA | CUDA、ROCm、Triton IR、各 TPU 的 XLA HLO 等 |
| 運算元庫 | cuDNN、cuBLAS 等提供手寫 fused kernel；是編譯器 fallback 的基礎 |
| ML 編譯器 | 圖級分析、pattern 匹配、tiling 策略、auto-tuning 基礎設施 |
| Profiling 工具 | Nsight Compute、Triton profiler 等用於驗證融合效果 |
下游：Kernel Fusion 影響什麼
| 下游受益方 | 機制 |
|---|---|
| LLM 推論服務（vLLM、TensorRT-LLM 等） | 融合 attention、layernorm 等熱點運算元，降低每 token 延遲和成本 |
| 訓練架構（DeepSpeed、Megatron 等） | 訓練中每層的大量小運算元融合減少通訊間隙的 HBM 讀寫 |
| 雲端廠商 GPU 叢集 | 同等硬體上可承載更大吞吐 → 降低單位推論成本 → 資本效率 |
| 端側/邊緣 AI | 算力和頻寬更受限的場景，fusion 收益更顯著 |
| AI 晶片創業公司 | 編譯器棧中 fusion 能力是差異化競爭核心之一 |
關鍵指標
| 指標 | 含義 | 量級參考 |
|---|---|---|
| Memory Bandwidth Utilization (MBU) | 實際 HBM 頻寬利用率佔峰值比 | 未 fusion 時 30%~60% → 高效 fusion 後 70%~90%+ [估算] |
| Kernel Launch Latency | 單次 kernel 啟動開銷 | 數微秒量級（NVIDIA GPU）[業界經驗] |
| HBM Traffic Reduction | 融合後 HBM 讀寫總量減少比例 | 視場景，50%~90% 減少常見 [估算] |
| Arithmetic Intensity | FLOP / Byte，衡量計算 vs 頻寬比 | 融合後顯著提升（更靠近 compute-bound） |
| Register Usage / Occupancy | 融合後每執行緒暫存器數 / SM 活躍 warp 佔比 | 過高融合可能導致 occupancy 下降 |
| End-to-End Latency / Throughput | 端到端推論延遲和吞吐 | 受 fusion 影響顯著，尤其小 batch |
供需與市場資料
需求側驅動
- LLM 推論爆發：生成式推論的逐 token 解碼是 memory-bound 場景，每層數十個小 kernel 導致頻寬利用效率低 → 對 fusion 的需求空前強烈。
- 小模型 + 端側部署：引數量小但推論頻率極高，launch 開銷佔比大 → fusion 收益大。
- 長上下文推論：序列長度增長使 attention 的 memory 壓力倍增 → FlashAttention 類融合成為剛需。
供給側格局
- NVIDIA：擁有最成熟的融合生態（cuDNN fused kernels、TensorRT fusion pass、Triton 生態支援）。
- AMD：ROCm 生態追趕中；Triton 已支援 AMD GPU 後端，但 cuDNN 級別的手寫 fused kernel 庫仍落後。
- Google：XLA/MLIR 基礎設施，TPU 上自動 fusion 能力成熟。
- AI 編譯器創業公司：包括 Modular（Mojo/MAX）、Centml、各種基於 MLIR 的最佳化層——fusion 是其核心技術賣點。
- 推論架構：vLLM、TensorRT-LLM、SGLang 等在推論引擎層面對關鍵路徑做手動/半自動融合最佳化。
市場角度
Kernel Fusion 本身不是一個可直接量化的市場規模，但它是影響每 FLOP 有效利用率的關鍵技術。當全球 GPU 支出每年數百億美元時，即使 fusion 只帶來 20%~30% 的端到端效率提升，等效節省的算力採購成本在行業層面可達數十億美元量級[推算]。
代表公司與資本對映
| 公司/組織 | 與 Kernel Fusion 的關係 | 上市/投資標的 |
|---|---|---|
| NVIDIA (NVDA) | Fusion 生態最完整；Triton、cuDNN、TensorRT 均為核心 | 上市 |
| AMD (AMD) | ROCm + Triton 支援；追趕中 | 上市 |
| Alphabet/Google (GOOGL) | XLA、MLIR；TPU 自動 fusion 成熟 | 上市 |
| Modular (Mojo) | AI 編譯器創業公司；Mojo 語言目標之一是高效 kernel fusion | 私有 |
| CentML | AI 編譯最佳化平台；fusion 是核心功能之一 | 私有 |
| Magic / Poolside 等 | AI-native 開發工具，可能在程式碼生成層面利用/最佳化 fusion | 私有 |
| Meta (META) | PyTorch TorchInductor；開源 fusion 編譯器貢獻者 | 上市 |
標註 “私有” 表示截至知識截止日該公司尚未上市或未有公開可交易標的。投資對映僅作資訊參考，不構成建議。
投資邏輯
看多邏輯
- Memory-bound 趨勢不可逆：GPU 算力增長快於 HBM 頻寬 → 每一代新硬體都需要更激進的 fusion → 軟體棧價值持續提升。
- LLM 推論成本敏感：推論佔 AI 計算的比重持續上升 → fusion 直接降低推論成本 → 誰的 fusion 好誰的推論便宜。
- 編譯器成為新戰場：硬體差異化縮小時，軟體/編譯器成為競爭壁壘 → 擁有強 fusion 能力的編譯器棧有護城河效應。
- NVIDIA 生態優勢放大：Triton + cuDNN + TensorRT 構成了三層 fusion 防線 → 競爭對手追趕困難。
風險/需關注點
- Fusion 可能被”固化”進硬體：如果硬體架構演進使得更多操作在硬體層面自動融合（如 NVIDIA 的 FP8 Tensor Core 融合乘加），則純軟體 fusion 的邊際價值可能下降。
- 開源標準化：Triton 等開源工具降低了 fusion 的”技術壁壘” → 競爭差異化縮小。
- 架構變換：如果 MoE、SSM/Mamba 等非 Transformer 架構興起，現有的 Transformer 專用 fusion pattern 可能需要重寫。
常見誤讀糾偏
❌ 誤讀 1：“Kernel Fusion 就是把所有運算元合併成一個大 kernel”
糾偏： 融合是有選擇的。過多融合會導致暫存器溢位（register spilling）、occupancy 下降、編譯時間增長。工業級編譯器使用 cost model 來決定哪些運算元值得融合、哪些保持獨立。融合不是”越多越好”，而是”恰到好處”。實際部署中，一個典型 Transformer 模型的推論圖上仍會有數十個獨立 kernel，並非所有都被融合。
❌ 誤讀 2：“Kernel Fusion 主要節省的是計算時間”
糾偏： Fusion 最主要的收益來自減少 HBM 訪問次數和 kernel launch 開銷，而非減少計算量。融合不改變總 FLOPs（計算量基本不變），但大幅減少了資料搬運量。在 memory-bound 的小運算元場景中，計算時間可能只佔總執行時間的很小比例，真正的瓶頸是資料搬運。因此 fusion 節省的主要是等資料的時間和啟動排程的時間。
❌ 誤讀 3：“FlashAttention 是一個模型架構創新”
糾偏： FlashAttention 不是一個新的注意力演算法，而是一個注意力計算的 kernel fusion 實現。它不改變注意力的數學結果（在數值精度範圍內），而是改變了計算的執行順序和記憶體訪問模式，使得注意力可以在