Roofline Model

The roofline model is a one-picture performance framework: it plots attainable compute throughput against arithmetic intensity, so you can see at a glance whether a kernel is limited by the chip's math units or by its memory bandwidth.

Two ceilings, one plot. The y-axis is performance (FLOP/s); the x-axis is arithmetic intensity (FLOPs done per byte moved from memory). A sloped line — the memory roof — rises at the machine's peak bandwidth, and a flat line — the compute roof — caps out at peak FLOP/s. Every kernel sits under whichever roof is lower at its intensity.

The ridge point splits the world. Where the two roofs meet is the ridge, at arithmetic intensity = peak FLOPs / peak bandwidth. Left of it a kernel is memory-bound: it starves the math units, and only faster memory (HBM) helps. Right of it a kernel is compute-bound: the pipes are full, and only more or faster FLOPs help. On an H100-class GPU the FP16 ridge sits near a few hundred FLOP per byte — which is exactly why so much LLM inference lands on the memory-bound side.

RegimeWhereLimited byLever that helpsExample
Memory-boundleft of ridgeHBM bandwidthfaster memory, more reuseattention, GEMV, decode
Balancedat the ridgebothmatched tilingtuned GEMM
Compute-boundright of ridgepeak FLOP/smore/faster tensor coreslarge GEMM, big-batch training
Roofline Model — Am I Compute-Bound or Memory-Bound? plot attainable FLOPS vs arithmetic intensity — one chart answers where your bottleneck is Arithmetic Intensity (FLOPs / Byte loaded) Attainable GFLOPS (log) 10 100 1K 10K 100K 1 10 100 1000 BW ceiling (3.35 TB/s) peak compute = 990 TFLOPS (BF16) ridge point AI = 295 ops/byte memory-bound region compute-bound region LLM decode (AI≈1) attention small GEMM large batch GEMM training matmul How to Read It below sloped line → memory-starved (increase AI or BW) below flat line → compute-limited (need more FLOPS) H100 Roofline Numbers peak BF16: 990 TFLOPS · HBM BW: 3.35 TB/s ridge point: 990T / 3.35T = 295 ops/byte The roofline tells you in one glance: is your kernel starved for data or starved for compute?

You move a kernel by changing its intensity. Tiling, kernel fusion, keeping data resident in registers or SRAM, and larger batch sizes all raise arithmetic intensity, sliding a kernel rightward toward the compute roof. This is why FlashAttention is such a large win: by fusing the attention kernel so it never re-reads the big score matrix from HBM, it raises intensity and lifts the kernel off the memory roof.

Read the roofline through a quant lens rather than a tuning-tips lens: it is the single diagram that ties together every other number on this site. HBM bandwidth sets the slope, the tensor core sets the ceiling, and arithmetic intensity — fixed by the algorithm and the memory hierarchy — decides which one you actually hit. Optimizing hardware or software without knowing which side of the ridge you are on is guessing.

Take roofline model further

Ask the copilot about this term, or have our engineers assess it against your process.