LLM fundamentals
Prefill, decode and the KV cache
One parallel pass over the prompt, then one token at a time. Reusing keys and values is why a stable prefix saves money.
One forward pass over the whole prompt is prefill. After that, producing each new token is decode. Output tokens are typically priced higher than input tokens partly because decode is expensive per token and harder to batch, and partly because markets allow it. Either way, verbose answers cost more and feel slower even when a short sentence would do.
Concept
Before you start: generation is a next-token loop. Prefill is the first pass that builds a cache. Decode is every pass after that.
Two phases
| Phase | What happens | Feels like | Economics |
|---|---|---|---|
| Prefill | Prompt tokens processed in parallel | Time to first token (TTFT) | Input tokens billed; compute-heavy |
| Decode | One token at a time, repeatedly | Tokens/second streaming | Output tokens billed; memory-bandwidth heavy |
Deep dive: prefill vs decode.
When TTFT spikes, check input length and cache hit rate before blaming the model name. When the stream is slow, you are on decode. When finance asks why output is several times input spend, draw this cartoon.
The KV cache and prefix reuse
During prefill, each layer stores keys and values for every prompt token. On decode, those tensors are reused so the model does not re-encode the entire prompt for every new token. That store is the KV cache.
KV bytes ≈ 2 × layers × kv_heads × head_dim × bytes_per_elem × seq_lenLong contexts blow up memory. Grouped-query attention and quantization exist largely to shrink this footprint. For product engineers the important corollary is prefix reuse.
If request N and request N+1 share a long identical prefix, a serving stack can reuse the computed KV for that prefix (prompt caching / prefix caching). Stable system prompts, large tool schemas and frozen policy docs belong at the front of the prompt and should change rarely. Putting a per-request UUID or timestamp at the start destroys the cache hit.
Example
Support bot system prompt + tool schemas = 2,000 tokens. User question = 100 tokens. 1M requests/day.
If the 2,000-token prefix is cacheable at ~10% of input price, you pay full freight on 100 tokens and cheap rates on 2,000 — every call. Shuffle the user question before the system prompt and you may pay full freight on 2,100 tokens with no reusable prefix. Same model, same answer quality, very different bill.
Details in LLM caching and inference KV cache.
Repetition loops are the other KV-shaped bug. Decode that keeps reinforcing recent tokens feeds those tokens back into the cache and amplifies them. Fix with penalties, stop sequences, or a lower max-token cap and a clearer instruction.
Common mistakes
- Putting dynamic content at the start of the prompt. Cache miss storms follow.
- Blaming the model name for a TTFT spike without checking input length and cache hit rate.
- Asking for a long answer when a short one would do. Decode is the expensive phase.
Check yourself
- Why does a request ID at the start of the system prompt raise the bill? The prefix is no longer identical across calls, so the KV / prompt cache misses and you pay full prefill.
- TTFT jumped after you added a 6,000-token policy to every request. Which phase? Prefill. The first pass now covers a much longer prompt.
Key takeaways
- Prefill sets time to first token. Decode sets stream speed.
- Output tokens are the expensive phase. Ask for brevity and stream.
- The KV cache reuses keys and values so decode does not redo the prompt.
- Identical prefixes are cheap. Dynamic bytes at the front are not.
Further learning
Prefill vs decode, KV cache, prefix caching. Next, where the model's knowledge lives.
Related
How transformers work (practitioner view)
Just enough transformer internals to predict model behavior — attention, context, and why the KV cache shapes pricing.
Prefill vs decode
The two phases of LLM inference. Prefill is compute-bound and sets TTFT. Decode is memory-bound and sets TPOT. They interfere when they share a GPU.
Caching for LLM apps
Prompt caching, exact-match and semantic caches: where each fits, and how to avoid serving the wrong answer.