As introduced earlier, the sheer scale of modern LLMs, governed by scaling laws, directly translates into immense computational and memory requirements. While training these models is a massive undertaking, deploying them for inference presents its own set of significant efficiency hurdles. During inference, particularly in autoregressive generation where tokens are produced sequentially, two primary constraints often dictate performance: memory bandwidth and compute capacity. Understanding which bottleneck dominates is fundamental for effective optimization.

The Memory Wall: Bandwidth as the Bottleneck

For many LLM inference workloads, especially latency-sensitive ones generating text token-by-token, the primary limitation is often memory bandwidth. This refers to the rate at which data, primarily the model's parameters (weights), can be transferred from main memory (typically DRAM) to the processing units (GPU SRAM, caches, registers) where computations actually happen.

Consider a large model with billions of parameters. Even using low-precision formats like FP16 or BF16, the total size can range from tens to hundreds of gigabytes.

Parameter Size vs. On-Chip Memory: Modern GPUs have relatively small amounts of very fast on-chip memory (SRAM, caches) compared to their large pools of slower DRAM. For instance, a high-end GPU might have hundreds of megabytes of L2 cache but tens of gigabytes of HBM (High Bandwidth Memory). The vast majority of the LLM's parameters ( $W$ ) reside in this slower HBM/DRAM.
Inference Workflow: During inference, especially for autoregressive decoding, each generated token requires processing through the entire network. This involves loading the weights for each layer sequentially from DRAM into the compute units. Even if the computation itself is fast, the time spent waiting for these weights to arrive becomes the dominant factor.
Transformer Components: The self-attention mechanism is particularly notorious for its memory access patterns. Computing attention scores involves operations on the query ( $Q$ ), key ( $K$ ), and value ( $V$ ) matrices. In autoregressive decoding, the $K$ and $V$ tensors grow with each generated token (the KV cache). Accessing and updating this cache, along with loading attention layer weights, requires significant data movement, often limited by DRAM bandwidth. Matrix-vector multiplications, common in attention and feed-forward layers during single-token decoding, also tend to be memory-bound because the computation per byte loaded is relatively low.

We can conceptualize this using the Arithmetic Intensity ( $AI$ ) of an operation, defined as the ratio of floating-point operations (FLOPs) to the bytes of data moved from main memory:

AI = \frac{\text{Total FLOPs}}{\text{Total Bytes Accessed (DRAM)}}

Operations with low arithmetic intensity are typically limited by memory bandwidth. Many operations in single-token LLM inference fall into this category. The processor spends more time waiting for data than performing calculations. This scenario is often referred to as being memory-bound.

Simplified view of data flow during inference, highlighting the potential bottleneck between slower main memory (DRAM) where weights reside and faster on-chip caches feeding the compute units.

The Compute Ceiling: When Calculations Dominate

Conversely, an operation is compute-bound when the processor's calculation speed (measured in FLOPS - Floating Point Operations Per Second) is the limiting factor. This typically occurs when:

High Arithmetic Intensity: The operation performs many computations for each byte of data loaded from memory. Large matrix-matrix multiplications, especially when the matrices fit into faster caches, are prime examples.
Sufficient Data Locality: The required data is already present in fast on-chip memory (SRAM/cache), minimizing the need to fetch from slower DRAM.
Large Batch Sizes: Processing multiple input sequences concurrently (increasing the batch size) often shifts the balance towards being compute-bound. This amortizes the cost of loading weights over more computations, making matrix-matrix operations more dominant than matrix-vector operations. However, large batches increase latency, making them less suitable for real-time interactive applications.

In the context of LLMs:

Feed-Forward Networks (FFNs): The FFN layers in Transformers involve large matrix multiplications. If the input batch size is large enough, or if techniques like operator fusion keep intermediate results in fast memory, these operations can become compute-bound.
Prefill Phase: When processing the initial prompt (before autoregressive generation starts), computations can often be parallelized across the prompt tokens. This involves larger matrix-matrix operations than the subsequent token-by-token generation, potentially making the prefill phase more compute-bound than the decoding phase.

Hardware capabilities play a direct role here. The peak theoretical FLOPS of a processor (e.g., boosted by specialized units like NVIDIA's Tensor Cores) sets the ceiling for compute-bound performance.

The Interplay: Decoding vs. Prefill and Batching

It's important to recognize that the bottleneck isn't static; it depends heavily on the specific operation, the inference strategy, and the hardware.

Prefill vs. Decode: As mentioned, processing the initial prompt (prefill) often involves parallel computation across tokens, leading to large matrix multiplications that can be compute-bound. The subsequent autoregressive decoding phase generates one token at a time, relying heavily on memory-bandwidth-sensitive operations like attention lookups and matrix-vector multiplications.
Batch Size: Increasing the batch size generally increases arithmetic intensity, pushing operations towards being compute-bound. However, this comes at the cost of increased latency. Optimizing for maximum throughput (e.g., offline processing) might favor large batches and target compute limitations, while optimizing for minimum latency (e.g., chatbots) necessitates small batches (often batch size 1) and focuses efforts on overcoming memory bandwidth limits.

Roofline plot illustrating performance limits. Operations with low arithmetic intensity (left side) are capped by memory bandwidth (orange line), while operations with high arithmetic intensity (right side) are capped by the peak compute performance (green line). Typical LLM inference operations often fall into different regions depending on the context (e.g., single-token decoding attention vs. batched FFN).

Recognizing whether an LLM workload is primarily memory-bound or compute-bound is the first step in choosing appropriate optimization strategies. Techniques like quantization and optimized memory access patterns directly target the memory wall, while methods like pruning (reducing FLOPs) or using faster compute kernels address the compute ceiling. The following chapters will provide the tools and techniques to tackle both of these fundamental bottlenecks.