LLM Inference Optimization
AI Engineer path · lesson 103 of 124Understand how production LLM serving achieves low latency and high throughput — explore KV cache mechanics, continuous batching, quantization tradeoffs, and speculative decoding side by side.
K_t = W_K · x_t (new key)
V_t = W_V · x_t (new value)
Cache: [K_1...K_t], [V_1...V_t]
Without cache: O(n²) per step
With cache: O(n) per step ← just new token
Key insight
The KV cache is the biggest memory consumer in LLM serving. A single 100K-token context on a 70B model using GQA needs ~32 GB of KV cache — without GQA it would be ~256 GB, more than most GPU servers have. Managing this memory is the primary engineering challenge in long-context serving.
Prefill or decode?
Sort each property by the inference phase it describes.
Tap a piece, then tap where it goes — or drag it. Tap the tray to take one back.
Prefill
Drop items hereDecode
Drop items hereTest your knowledge
What does the KV cache store during autoregressive LLM generation?
The short version
Serving an LLM without optimization is like a chef who re-reads the entire recipe from scratch before adding each ingredient. The KV cache is sticky-notes for each step already read; continuous batching is running multiple orders in parallel on the same stove; quantization is using a smaller measuring cup that's accurate enough for most dishes; speculative decoding is having a fast sous-chef who guesses the next few steps while the head chef reviews them in bulk.
In more depth
LLM Inference Optimization
LLM generation is autoregressive: each token is conditioned on all previous tokens. Naive inference is extremely slow — optimization is engineering the gap between "correct" and "fast."
KV Cache
Self-attention computes K = W_K · x and V = W_V · x for each position. In autoregressive generation, previous positions never change — their K/V can be cached.
Memory per request: 2 × L × H_kv × D × dtype per token (H_kv = number of KV heads, not query heads — with GQA these differ)
PagedAttention (vLLM) manages KV cache like virtual memory, eliminating fragmentation.
Continuous Batching
Static batching waits for a whole batch to finish before accepting new requests — long sequences block short ones. Continuous batching (iteration-level scheduling) inserts new requests at each token step, keeping GPU utilization near 100%.
Quantization
| Precision | Size | Speed | Quality loss |
|---|---|---|---|
| FP32 | 4× | 1× | none |
| FP16/BF16 | 2× | 1.5–2× | minimal |
| INT8 (W8A8) | 1× | 2–3× | <1% on most benchmarks |
| INT4 (GPTQ/AWQ) | 0.5× | 3–4× | ~2–5% on hard tasks |
Speculative Decoding
A small "draft" model generates k tokens cheaply. The large "target" model verifies all k in a single forward pass (parallel). Accepted tokens keep all; rejected tokens are resampled. Net effect: target-model quality at draft-model speed (when acceptance rate is high).
Interview Questions
References & Further Reading
Love this visualization?
Sign up to track your progress, earn achievements, use the AI assistant, and access your personal learning dashboard.
100% free • No credit card required