#Inference
Articles about Inference — exploring patterns, best practices, and real-world implementations in production systems.
8 posts tagged with inference. ← All posts
Everything in this series converges on one discipline: you cannot optimize what you haven't measured. GPU performance is unintuitive — the bottleneck is rarely where you'd guess — so the engineers who make inference fast are the ones who profile first, identify the actual limit, apply the one lever that moves it, and measure again. This closing post ties the series into a workflow you can actually run, and looks at where inference engineering is heading.
You can't optimize what you haven't measured. The optimization loop — baseline, profile, find the dominant limit, apply the matching lever, repeat — plus knowing when to stop, leaning on the ecosystem, and the durable mental model behind it all.
The single largest consumer of GPU memory during inference often isn't the model — it's the KV cache, the growing store of attention state that lets a model generate text without recomputing the past. Managing it well is the difference between serving a handful of users and serving thousands on the same hardware. This post explains what the KV cache is, why it's such a brutal memory problem, and how PagedAttention borrowed a 1960s operating-systems idea to solve it.
The KV cache often exceeds the model weights in HBM, and naive contiguous allocation wrecks concurrency with fragmentation. PagedAttention applies operating-system paging to fix it — a core inference bottleneck solved by borrowing a classic systems idea.
Attention is the operation that makes transformers powerful, and for years it was also their worst performance bottleneck — not because it does too much math, but because it moved too much data. FlashAttention is the single most important GPU optimization of the LLM era, and it's a perfect case study in everything this series has built: it's memory-bound, the roofline says so, and the fix is to raise arithmetic intensity by never writing the big intermediate to HBM. Understanding it is understanding how real kernel optimization works.
Naive attention materializes an N×N matrix in HBM — memory-bound and quadratic. FlashAttention fixes it with pure roofline reasoning: tile into shared memory, use an online softmax, fuse the kernel, never touch HBM. The archetype of all inference optimization.
The fastest way to speed up LLM inference is often not a better algorithm but fewer bits per number. Precision — how many bits represent each weight and activation — is a direct lever on both of the limits this series has built up: it halves or quarters the data you move (bandwidth, post 2) and unlocks the GPU's fastest arithmetic units (compute, post 3). Understanding floating-point formats is understanding why fp16, bf16, and int8 are everywhere in modern inference.
FP32, FP16, BF16, and INT8/INT4 — how a float splits bits between range and precision, why bf16 won, and why fewer bits is a double win: less data to stream from HBM and faster tensor-core math. Quantization and why LLMs tolerate it.
To make a GPU fast you have to express your problem the way the hardware wants to run it: as thousands of near-identical threads marching in lockstep. CUDA is the programming model that exposes this, and its abstractions — threads, warps, blocks, grids — map directly onto the SMs and cores from post 1. You don't need to write kernels to be an inference engineer, but you do need this model to understand why some operations fly and others crawl.
Threads, warps, blocks, and grids; SIMT and branch divergence; and the cleverest trick — hiding slow memory by oversubscribing warps (occupancy). Why a GPU can be underutilized without being either compute- or memory-bound.
Posts 1 and 2 kept drawing a line between two worlds: workloads limited by how fast the GPU can compute, and workloads limited by how fast it can move data. The roofline model is the single tool that tells you which world you're in for any given operation — and therefore which optimizations will help and which are a waste of time. It is the most useful mental model in performance engineering, and it fits on one chart.
The roofline model answers the one question that governs every optimization — compute-bound or memory-bound? — from arithmetic intensity (FLOPs per byte). Why LLM prefill is compute-bound and decode is memory-bound, and why batching is the master throughput lever.
Post 1 ended on a reversal: GPUs are fast at arithmetic, but arithmetic is rarely the bottleneck — moving data is. This post makes that concrete by walking the GPU's memory hierarchy, from the tiny ultra-fast registers next to the compute units down to the big slow memory that holds the model's weights. Once you see the orders-of-magnitude gaps between these levels, every performance decision in LLM inference starts to make sense.
The GPU memory hierarchy from registers to HBM, the difference between capacity and bandwidth limits, and the defining fact of LLM generation: it's memory-bandwidth-bound because every token reads the whole model from HBM — which is why batching and quantization work.
Every large language model runs on a GPU, but most engineers treat the GPU as a black box that "does the math fast." Understanding why it's fast — and, more usefully, why it's often not as fast as its spec sheet promises — is the foundation of inference engineering. This series works below the serving layer: not how to run an inference server, but how the silicon actually executes a model and where the real bottlenecks live.
Every LLM runs on a GPU, but the spec-sheet FLOPS number is a near-fiction in practice. Why neural nets map onto GPUs (matrix multiply, SMs, tensor cores), and the governing intuition of the series: compute is cheap, data movement is expensive.
All posts on this site are written by Pratik Dhanave, an Agentic AI Architect with 7+ years building production distributed systems, multi-agent AI platforms, and cloud-native infrastructure. About the author → Each article includes working code, architecture diagrams, and references to the specific frameworks and standards discussed. Browse all posts or explore related topics using the tag cloud above.