MODULE 07

Compute vs Memory Bound

Understanding the Roofline Model -- why some operations are limited by compute (FLOPS) and others by memory bandwidth (bytes/sec). The key to optimizing GPU inference.

989
H100 TFLOPS (FP16)
3.35
TB/s HBM Bandwidth
295
Ridge Point (FLOP/byte)
80
GB HBM3 Memory
ROOFLINE MODEL

The Roofline Chart

The roofline model shows achievable performance as a function of arithmetic intensity (FLOPs per byte of memory accessed).

Batch Size 1
1248163264128256
Sequence Length 128
1282565121K2K4K8K16K
Compute Roof
Memory Bandwidth Roof
MatMul / Linear
Attention
Softmax / LayerNorm

Adjust batch size and sequence length to see how operations move on the roofline chart.

KEY CONCEPT

Arithmetic Intensity

Arithmetic intensity = FLOPs / Bytes accessed. This ratio determines whether an operation is compute-bound or memory-bound.

Operation Intensity Spectrum Ridge Point: 295 FLOP/byte
Ridge Point
0.1 FLOP/byte Memory Bound 295 FLOP/byte Compute Bound 10K FLOP/byte
Softmax
MEMORY BOUND
Intensity: ~2 FLOP/byte
Reads entire row, writes same size
LayerNorm
MEMORY BOUND
Intensity: ~5 FLOP/byte
Element-wise with reduction
GELU / ReLU
MEMORY BOUND
Intensity: ~1 FLOP/byte
1 op per element loaded
Attention (BS=1)
MEMORY BOUND
Intensity: ~10 FLOP/byte
KV cache reads dominate
MatMul (Large)
COMPUTE BOUND
Intensity: ~512 FLOP/byte
O(n^3) compute, O(n^2) memory
Conv2D (3x3)
COMPUTE BOUND
Intensity: ~800 FLOP/byte
High reuse of filter weights
Linear (BS=64)
COMPUTE BOUND
Intensity: ~350 FLOP/byte
Batch amortizes weight loading
Linear (BS=1)
MEMORY BOUND
Intensity: ~8 FLOP/byte
Weight loading dominates

The Formula

Arithmetic Intensity = FLOPs / Bytes Transferred

If intensity < ridge point → memory-bound (waiting for data). If intensity > ridge point → compute-bound (GPU fully utilized).

DEEP DIVE

How Batch Size Changes Everything

Increasing batch size amortizes weight loading across more input tokens, shifting operations from memory-bound to compute-bound.

Batch Size for Linear Layer (d=4096) 1
FLOPs
33.6M
Bytes Accessed
33.6MB
Arithmetic Intensity
1.0
Ridge (295)
Memory Bound Compute Bound
MEMORY BOUND
Time Breakdown (Linear Layer, d_model=4096)
Compute Time
0.03ms
Memory Time
10ms
Total Time
10ms
GPU SPECS

GPU Roofline Comparison

Different GPUs have different ridge points. Higher-end GPUs shift the ridge point higher, requiring more arithmetic intensity to become compute-bound.

989
TFLOPS (FP16)
3.35
TB/s Bandwidth
295
Ridge Point
80
GB HBM

What This Means for LLM Inference

LLM decode (single token generation) is almost always memory-bound. The bottleneck is loading model weights from HBM, not computing with them. This is why memory bandwidth matters more than TFLOPS for serving.

Prefill vs Decode

Prefill processes many tokens at once (high arithmetic intensity, compute-bound). Decode generates one token at a time (low intensity, memory-bound). This duality drives many optimization strategies.

SUMMARY

Optimization Strategies

Different bottlenecks require different optimization approaches.

Memory-Bound Optimizations

  • Quantization -- FP16/FP8/INT4 reduces bytes loaded
  • Kernel Fusion -- reduce memory round-trips
  • FlashAttention -- fuse attention into single kernel
  • Batching -- increase arithmetic intensity
  • Speculative Decoding -- use smaller model to draft

Compute-Bound Optimizations

  • Tensor Cores -- use mixed-precision (FP16, FP8)
  • Tensor Parallelism -- split across GPUs
  • Model Pruning -- reduce FLOPs directly
  • Distillation -- smaller model, fewer ops
  • Compiler Optimization -- TensorRT, Triton

Key Takeaways

  • Profile first -- determine your bottleneck before optimizing
  • LLM decode is memory-bound -- bandwidth > TFLOPS
  • LLM prefill is compute-bound -- TFLOPS matter
  • Batching changes the game -- amortize weight loading
  • The ridge point is GPU-specific -- know your hardware