Roofline 模型（Roofline Model）

3 秒看懂

Roofline 模型是一張圖回答一個問題：你的程式跑得慢，到底是算力不夠，還是頻寬不夠？ 橫軸是”每搬運一位元組資料要做多少次計算”（算術強度），縱軸是”實際能達到的算力”。硬體的峰值算力畫成水平天花板、峰值頻寬畫成斜線天花板，程式的實際表現落在哪條線上，就說明瓶頸在哪。

3 分鐘產業解釋

為什麼這個模型重要？

在 AI 晶片和加速器產業中，計算與訪存的平衡是架構設計的核心矛盾。一顆 GPU 可能標稱 1000+ TFLOPS（FP16），但如果算術強度不夠高，資料搬不過來，實際利用率可能只有 10-20%。Roofline 模型正是量化這一矛盾的標準工具。

誰在用？

晶片架構師：設計新晶片時，用 Roofline 決定計算單元與記憶體頻寬的配比
編譯器/架構工程師：最佳化運算元時，判斷哪些 kernel 是 memory-bound、哪些是 compute-bound
AI 訓練/推論工程師：選擇 batch size、精度、並行策略時，用 Roofline 估算實際吞吐上界
投資者/分析師：理解為什麼某些晶片”紙面算力很高但實測利用率低”

產業影響

Roofline 直接揭示了一個事實：單純堆 FLOPS 沒有意義，必須與頻寬匹配。 這解釋了為什麼 HBM（高頻寬記憶體）成為 AI 晶片的關鍵瓶頸，也解釋了為什麼 NVIDIA 從 A100 到 H100 到 B200，每一代都在同步拉高算力和頻寬。

15 分鐘專家深入

起源與論文

Roofline 模型由 UC Berkeley 的 Samuel Williams、Andrew Waterman、David Patterson 於 2009 年提出，論文標題為 “Roofline: An Insightful Visual Performance Model for Multicore Architectures”，發表於 Communications of the ACM。原始目標是為多核處理器提供一種直觀的效能分析工具，後被廣泛擴充套件至 GPU、TPU 及各類加速器。

核心思想

Roofline 模型將程式效能上界表示為兩條”天花板”的交集：

計算天花板（Compute Roofline）：一條水平線，代表硬體峰值計算吞吐量（單位：FLOPS 或 TOPS）
頻寬天花板（Bandwidth Roofline）：一條從原點出發的斜線，斜率等於峰值記憶體頻寬（單位：Bytes/s）

程式的實際效能不可能超過這兩條天花板中的任何一條。兩條天花板的交點稱為 “脊點”（Ridge Point），其橫座標 = 峰值算力 / 峰值頻寬，代表了”要充分利用算力，每位元組資料至少需要做多少次計算”。

關鍵公式

算術強度 (Operational Intensity, OI)
  = 程式執行的總浮點運算元 / 從主存（或某級快取）搬運的總位元組數
  單位: FLOPs/Byte

可達到效能 (Attainable Performance)
  = min( 峰值算力, OI × 峰值頻寬 )
  單位: FLOPS

脊點 (Ridge Point)
  = 峰值算力 / 峰值頻寬
  單位: FLOPs/Byte

落在哪裡？

算術強度 vs 脊點	瓶頸型別	含義
OI < 脊點	Memory-bound（頻寬瓶頸）	資料搬運速度限制了效能，增加算力無用
OI > 脊點	Compute-bound（算力瓶頸）	計算單元已滿載，增加頻寬無用
OI ≈ 脊點	平衡點	算力與頻寬同時被充分利用

從單級到多級：Cache-Aware Roofline

原始模型只看主存頻寬。實際硬體有 L1/L2/LLC 多級快取。Cache-Aware Roofline（Iakymchuk 等人擴充套件）對每一級儲存分別畫一條頻寬斜線：

                 GFLOPS
                  │
    L1 頻寬線 /  │________________________  峰值算力
              /   │
    L2 頻寬線/    │
            /     │
  HBM 頻寬線/     │
          /       │
        /         │
      /___________│________________________ OI (FLOPs/Byte)
      0

同一段程式碼在不同快取層級下的有效 OI 可能不同——如果資料能駐留在 L2，實際可用頻寬遠高於 HBM，效能表現可能完全不同。這對 AI 推論尤其重要：權重駐留在片上 SRAM（如 Apple Neural Engine、Groq TSP）時，等效頻寬天花板極高，脊點左移，memory-bound 閾值大幅降低。

技術原理

1. 模型建置的完整流程

┌─────────────────────────────────────────────────────────┐
│  Step 1: 確定硬體引數                                     │
│    ├── 峰值算力 P_peak (FLOPS)                           │
│    │     = 計算單元數 × 每週期運算元 × 頻率               │
│    │     例: 108 SM × 128 FP32 FLOPS/cycle/SM × 1.41 GHz      │
│    │       ≈ 19.5 TFLOPS (FP32)  [某GPU示例估算]         │
│    └── 峰值頻寬 B_peak (Bytes/s)                         │
│          = 記憶體介面寬度 × 有效資料速率                     │
│          例: HBM2e 4096-bit × 3.2 Gbps ≈ 1.6 TB/s       │
│                                                         │
│  Step 2: 計算脊點                                         │
│    Ridge Point = P_peak / B_peak                         │
│    例: 19.5 TFLOPS / 1.6 TB/s ≈ 12.2 FLOPs/Byte        │
│                                                         │
│  Step 3: 分析目標 Kernel                                  │
│    ├── 統計總浮點運算元 F_total                           │
│    │     (如: GEMM M×N×K → 2MNK FLOPs)                   │
│    ├── 統計主存搬運量 B_total                             │
│    │     (讀入+寫出, 需區分是否複用快取中的資料)           │
│    └── 計算 OI = F_total / B_total                       │
│                                                         │
│  Step 4: 在圖上定位                                       │
│    ├── x = OI, y = min(P_peak, OI × B_peak)              │
│    └── 落在斜線段 → memory-bound; 落在水平段 → compute-bound│
└─────────────────────────────────────────────────────────┘

2. AI 工作負載的典型算術強度

算術強度 (FLOPs/Byte)   低 ◄──────────────────────► 高
                     0.1    1      10     100    1000

  逐元素啟用函式       ■
  LayerNorm/BatchNorm  ■■
  Softmax              ■■
  Attention (推論)     ■■■
  卷積 3×3            ■■■■
  矩陣乘法(大GEMM)    ■■■■■■■■■■
  矩陣乘法(推論小batch)■■■

關鍵洞察：

大矩陣乘法（如訓練中的 GEMM）算術強度可達 O(M)（M 為矩陣維度），通常落在 compute-bound 區域
逐元素操作、歸一化、Softmax 算術強度極低（通常 < 1 FLOPs/Byte），幾乎總是 memory-bound
Flash Attention 的核心最佳化思路正是通過 tiling 減少 HBM 訪問量，將 OI 提高，從頻寬斜線推向算力天花板

3. Roofline 與 Roofline 的”陷阱”

OI 計算取決於你觀察哪級儲存

同一段程式碼，相對於不同儲存層級的 OI 可能完全不同：

Kernel A: 1024 FLOPs, 訪問 HBM 256 Bytes → OI_HBM = 4 FLOPs/Byte
  但如果資料在 L2 中命中, 實際訪存只有 64 Bytes → OI_L2 = 16 FLOPs/Byte

因此嚴格來說，Roofline 圖上應該標註”相對於哪級儲存”。

指令/控制流開銷未建模

Roofline 只關注資料搬運和計算之間的關係，不考慮：

指令發射/解碼瓶頸
分支預測失敗
同步/通訊開銷（如 AllReduce）
尾部效應（wave quantization）

這意味著 Roofline 給出的是上界，而非精確預測。

技術演進史

年份	里程碑	關鍵進展
2009	原始 Roofline 論文 (Williams et al.)	針對多核 CPU 的單級主存模型
2011	Cache-Aware Roofline (Iakymchuk et al.)	考慮多級快取層次，每級畫獨立頻寬線
2013-15	GPU Roofline 適配	社群將模型擴充套件至 NVIDIA GPU（考慮 shared memory / L1/L2 層次）
2015	Intel Advisor 整合	Intel 將 Roofline 嵌入其效能分析工具，支援自動化採集
2018	DRAM-Aware Roofline (Oliveira et al.)	區分 Row Buffer Hit/Miss 的不同 DRAM 頻寬
2019-20	Roofline for DNN accelerators	學術界將模型適配至 TPU、Eyeriss 等脈動陣列架構
2020+	Communication-Aware Roofline	擴充套件至分散式訓練場景，將網路通訊（AllReduce）納入”頻寬天花板”
2022+	Roofline for Transformer 工作負載	針對 Attention、MoE 等混合負載的分段分析

技術路線對比

Roofline 與其它效能分析模型

維度	Roofline 模型	簡單 FLOPS 利用率	詳細 Cycle-Accurate 模擬	硬體效能計數器實測
抽象層級	中——演算法+硬體引數	低——僅算力維度	高——逐週期	最高——真實硬體
輸入成本	低——只需 OI + 硬體規格	極低	極高——需 RTL/微架構模型	中——需硬體訪問
可解釋性	★★★★★ 直觀圖表	★★ 單一數字	★★★ 資料量大	★★★★ 需專業解讀
準確性	給出上界，不含尾部效應	忽略頻寬約束	高但模擬慢	真實值
適用階段	設計早期 + 最佳化決策	快速篩選	晶片設計階段	已有硬體的調優
典型工具	手算/Intel Advisor/Nsight Compute	紙面估算	gem5/Simulator	Nsight Compute/VTune/rocprof
侷限	不含通訊/同步/控制流	嚴重簡化	建模成本高	需要目標硬體

不同 Roofline 變體

變體	擴充套件點	典型應用
經典 Roofline	單級主存	通用處理器
Cache-Aware Roofline	多級快取層次	CPU 最佳化
DRAM-Aware Roofline	區分 DRAM Row Buffer 命中/未命中	DRAM 密集型應用
Communication-Aware	網路/PCIe 頻寬作為額外約束	分散式訓練、多 GPU
Power-Aware Roofline	加入功耗牆約束	移動/邊緣推論
Latency-Aware Roofline	考慮訪存延遲而非純頻寬	小 batch 推論

上下游

上游依賴（Roofline 需要什麼輸入）

上游輸入
├── 硬體規格
│   ├── 峰值算力 (各精度: FP64/FP32/TF32/FP16/BF16/INT8...)
│   ├── 峰值頻寬 (HBM/L2/L1 各級)
│   ├── 快取大小與關聯度
│   └── 互聯頻寬 (NVLink/PCIe/網路)
│
├── 演算法/Kernel 特徵
│   ├── 總浮點運算元 (可從運算元定義推導)
│   ├── 資料複用模式 (tiling 策略)
│   └── 快取駐留行為 (資料是否能放入某級快取)
│
└── 執行上下文
    ├── batch size
    ├── 並行度 (資料並行/模型並行)
    └── 精度選擇

下游應用（Roofline 指導什麼決策）

下游決策
├── 晶片架構設計
│   ├── 計算單元 vs 記憶體頻寬的配比
│   ├── 片上 SRAM 容量 (影響快取命中率 → OI)
│   └── 互聯拓撲 (影響分散式 Roofline 上界)
│
├── 運算元/Kernel 最佳化
│   ├── Tiling 策略 (提高 OI → 推離頻寬瓶頸)
│   ├── 資料版面配置 (NHWC vs NCHW → 快取友好性)
│   ├── Kernel Fusion (減少中間結果寫回 → 降 Bytes)
│   └── 精度降級 (降低 FLOPs 或 Bytes)
│
├── 系統級排程
│   ├── 運算元排布 (compute-bound op 與 memory-bound op 重疊)
│   ├── 流水線並行 (隱藏延遲)
│   └── batch size 選擇 (影響 GEMM 的 OI)
│
└── 採購/選型
    ├── 選晶片時對比 "有效算力" 而非峰值算力
    └── 評估頻寬擴充套件方案 (HBM 堆疊數、NVLink 代際)

關鍵指標

指標	含義	典型量級（AI 訓練場景，估算）
峰值算力 (P_peak)	硬體在特定精度下的理論最大 FLOPS	FP16 Tensor Core: 數百至數千 TFLOPS [因晶片而異]
峰值頻寬 (B_peak)	主存（通常 HBM）理論最大吞吐	HBM2e: ~1.5-2.0 TB/s; HBM3: ~3-8 TB/s [因堆疊/頻率而異]
脊點 (Ridge Point)	P_peak / B_peak，平衡點的 OI	現代 AI GPU 典型脊點: 數十 FLOPs/Byte [因精度而異]
算術強度 (OI)	Kernel 的 FLOPs / Bytes	大 GEMM: 100+; Softmax: <1 [因實現而異]
算力利用率 (FLOPS Util.)	實際 FLOPS / 峰值 FLOPS	訓練大 GEMM: 60-80%+; 推論小 batch: 可低至 10-30% [因場景而異]
頻寬利用率	實際吞吐 / 峰值頻寬	Memory-bound kernel: 70-90% [因實現而異]

注意：以上量級均為行業典型估算範圍，具體數字因晶片型號、精度、實現質量差異極大。各廠商公佈的峰值數字口徑不同（是否含 Tensor Core / Sparsity），需注意對齊。

供需與市場資料

為什麼 Roofline 越來越重要？

背景趨勢：過去 5 年，AI 晶片的算力增速遠超頻寬增速。

年份        算力增長趨勢          頻寬增長趨勢          脊點移動
──────────────────────────────────────────────────────────
~2016       基線                  基線                  基線
~2020       ↑↑↑ (~4-8×)         ↑↑ (~2-3×)           右移 →
~2024       ↑↑↑↑ (~16-32×)      ↑↑↑ (~4-8×)          繼續右移 →

脊點右移意味著：同樣的 Kernel，以前是 compute-bound，現在可能變成 memory-bound，除非同步最佳化資料複用。

市場影響

HBM 市場暴漲：正是因為 Roofline 分析表明，不提升頻寬，堆再多算力也無法利用。HBM 市場從邊緣走向 AI 晶片的 BOM 成本核心。
片上儲存增大：Cerebras、Groq、Tesla Dojo 等架構選擇巨大的片上 SRAM，本質上是將 Roofline 脊點極度左移（片上頻寬遠高於 HBM）。
Kernel Fusion 成為核心最佳化手段：vLLM、TensorRT、XLA 等推論架構大量使用 Fusion，本質是降低 Bytes 訪問量以提高 OI。

代表公司與資本對映

工具層面

公司/專案	Roofline 相關工具/能力	備註
Intel	Intel Advisor（內建 Roofline 視覺化）	最成熟的商業化 Roofline 工具
NVIDIA	Nsight Compute（支援 Roofline 圖表）	GPU 效能分析的事實標準
AMD	rocprof / Omniperf	ROCm 生態的 Roofline 分析
UC Berkeley	原始論文 + 開源工具	學術源頭

晶片/架構層面（Roofline 思維的受益方/驗證方）

公司	Roofline 視角下的核心優勢
NVIDIA	每代同步提升算力+HBM 頻寬+NVLink（A100→H100→B200），Roofline 脊點控制優秀
AMD (MI300X)	HBM3 容量/頻寬突出，memory-bound 場景競爭力強
Broadcom/Marvell (定製 ASIC)	為 Google TPU、Amazon Trainium 等定製，可針對特定 OI 配比最佳化
Cerebras	WSE 巨量片上 SRAM，將”頻寬天花板”替換為片上頻寬（極高），脊點極左
Groq	TSP 架構確定性執行，片上 SRAM 為主儲存，Roofline 上界易達

投資邏輯

1. Roofline 揭示的結構性投資主線

“算力過剩、頻寬稀缺”的格局在加劇。 Roofline 脊點持續右移意味著：

HBM 及先進封裝（SK 海力士、三星、美光、台積電 CoWoS）是確定性受益方向
晶片間互聯（NVLink、UALink、CXL）成為新瓶頸 → 關注高速 SerDes / 光互聯
片上儲存架構創新（如 SRAM-centric 設計）可能改變遊戲規則

2. Roofline 作為選晶片的分析架構

評估 AI 晶片時，不宜只看峰值 TFLOPS，可同時觀察：

"有效算力" = min( 峰值算力, 典型工作負載OI × 頻寬 )

一顆 2000 TFLOPS 但只有 1 TB/s 頻寬的晶片，對於 OI=1 的 kernel 實際只能提供 1 TFLOPS；而一顆 500 TFLOPS + 4 TB/s 頻寬的晶片在同樣 kernel 下能達到 4 TFLOPS。紙面算力差距 4×，實際效能可能反轉。

3. Kernel Fusion / 編譯最佳化賽道

降低 Bytes 訪問 = 提高 OI = 推離 Roofline 瓶頸。這為編譯器/AI 架構公司（如 Modular/Mojo、MLIR 生態、Triton）提供了理論支撐。

常見誤讀糾偏

❌ 誤讀 1：“Roofline 告訴你程式的實際效能”

糾偏：Roofline 給出的是效能上界（ceiling），不是預測值。實際效能還受以下因素影響：

指令排程效率、warp 佔用率（GPU）
快取衝突/容量未命中
同步開銷（AllReduce、流水線 bubble）
尾部效應（wave quantization：最後一個 wave 不滿載）
排程/啟動延遲

一個落在算力天花板下方很遠的點，Roofline 只能說”你還有提升空間”，不能直接告訴你瓶頸在哪——需要更細粒度的 profiling 工具配合。

❌ 誤讀 2：“OI 是演算法的固有屬性，與實現無關”

糾悲：OI 是演算法+實現+硬體的函式，而非僅由演算法決定。

同一演算法的不同實現可能有完全不同的 OI：

樸素矩陣乘法 OI ≈ O(N)（取決於具體 tiling）
做了 tiling 最佳化後，資料在快取中複用，有效 OI 可能提高數倍至數十倍
Kernel Fusion（如 Conv + BN + ReLU 融合）減少了中間結果的記憶體讀寫，直接降低 Bytes 分母

這就是為什麼 Flash Attention（通過 tiling 使 OI 從 O(N) 提升到 O(N) 與塊大小的比值關係）能在不改變演算法語義的前提下顯著提升效能——它把 Attention 從頻寬斜線上推向了算力天花板。

❌ 誤讀 3：“只看 FLOPS 利用率就夠了，不需要 Roofline”

糾偏：純 FLOPS 利用率只告訴你”距離算力天花板還有多遠”，但不告訴你為什麼沒到。

90% FLOPS 利用率 → 很可能是 compute-bound，最佳化空間在演算法/精度
15% FLOPS 利用率 → Roofline 能告訴你是否因為 OI 太低導致的頻寬瓶頸，從而指明最佳化方向（tiling/fusion/降精度）

FLOPS 利用率是結果，Roofline 是診斷工具。

❌ 誤讀 4：“Roofline 只適用於 CPU”

糾偏：Roofline 是硬體無關的分析架構。只要你能定義”峰值算力”和”峰值頻寬”，就可以建置 Roofline。它已被廣泛應用於 GPU、TPU、FPGA、定製 ASIC（如 Eyeriss）、甚至片上網路（NoC）的分析。不同硬體只需替換 P_peak 和 B_peak 的數值。

學習路徑

入門（1-2 小時）

讀原始論文：Williams et al., “Roofline: An Insightful Visual Performance Model for Multicore Architectures” (CACM, 2009) — 篇幅不長，圖文並茂
手算一個例子：選一個簡單的 GEMM kernel，手動計算 FLOPs、Bytes、OI，在紙上畫 Roofline

進階（1-2 天）

用 Intel Advisor 或 Nsight Compute 跑一次真實 Roofline：對一個實際 AI 推論模型（如 ResNet-50 的某個 conv 層）生成 Roofline 圖
理解 Cache-Aware Roofline：閱讀 Iakymchuk et al. 的擴充套件論文，理解多級快取如何改變圖片
分析 Flash Attention 論文中的 tiling 策略 — 它是 Roofline 最佳化的經典案例

深入（持續）

Communication-Aware Roofline：研究分散式訓練場景下，AllReduce 通訊如何成為額外的”頻寬天花板”
閱讀 NVIDIA/AMD 技術部落格中關於 Roofline 分析的案例
閱讀 Hennessy & Patterson《計算機體系結構：量化研究方法》 相關章節 — Roofline 在更廣的效能分析架構中的位置

一句話總結

Roofline 模型用一張圖、兩條線（算力天花板 + 頻寬斜線）、一個交點（脊點），將”程式為什麼跑不快”這個複雜問題歸結為一個清晰的二分診斷——算力瓶頸還是頻寬瓶頸——是 AI 時代從晶片設計到運算元最佳化的第一性分析工具。

延伸閱讀與來源

資源	說明
Williams et al., “Roofline: An Insightful Visual Performance Model for Multicore Architectures”, CACM 2009	必讀原文，奠基性論文
Iakymchuk et al., “An Overview of the Roofline Model for Multicore Architectures”	Cache-Aware 擴充套件
Intel Advisor Roofline 官方文件	實操指南，含自動生成工具
NVIDIA Nsight Compute 文件	GPU Roofline 實操
Dao et al., “FlashAttention” (2022)	Roofline 最佳化的經典案例：通過 tiling 提高 OI
Patterson & Hennessy, Computer Architecture: A Quantitative Approach (6th ed.)	體系結構教科書中的 Roofline 章節
”Are We Hitting the Roofline Yet?” (various NVIDIA GTC talks)	NVIDIA GTC 上多次出現的 Roofline 實戰分享

宣告：本文中所有具體硬體規格、效能數字均為基於公開文獻的典型估算範圍，非精確引用單一來源。讀者在做決策時應以廠商官方資料表（datasheet）為準，並注意各廠商計算口徑差異（如是否含 Tensor Core 加速、是否含 2:4 Sparsity 等）。