agents/prod
06
Knowledge · Chapter 6

Caching at every layer

Caching is the highest-leverage cost-and-latency win in the whole stack — but "caching" means four different things at four different layers, and teams constantly confuse them. This chapter walks each one, deepest-in-the-GPU to highest-in-your-app, and lets you watch the bill drop.

1 · KV cache — inside a single generation

When a model decodes text, attention would normally recompute the Key and Value vectors for every prior token at each step. The KV cache stores them after first computation, so each new step only computes the new token. It's what makes generation fast at all — without it, producing token 1,000 would redo the work for tokens 1–999.

cached (reused, not recomputed) new← only this token is computed this step
Decode reuses the cached Keys/Values of all prior tokens and computes only the newest — the difference between "fast" and "unusable."

2 · Prefix cache — reuse across requests

Prefix caching extends the KV cache across requests: the KV state of shared leading tokens — a system prompt, a big reference doc, few-shot examples — is stored and reused by the next request that starts the same way. The one hard rule: the cached prefix must be byte-for-byte identical — one changed character invalidates it. (vLLM does this automatically; SGLang's RadixAttention shares overlapping prefixes across many requests via a radix tree.)

shared prefix (system prompt + docs) — cached once req A req B req C unique tail →
Every request plugs into the same pre-computed prefix and only pays for its small fresh tail (amber).

3 · Prompt / context caching — the API feature you pay for

This is prefix caching exposed as a billing feature. You mark a stable prefix as cacheable, and repeat calls skip reprocessing it. The economics are dramatic — Anthropic charges cache reads at 0.1× the base input price (~90% off); OpenAI gives ~50% off. The design implication (from Chapter 4): put static content first so the cacheable prefix is as long as possible. Watch the bill for a big fixed knowledge base:

Interactive · prompt-cache cost calculator
Prompt size:  ·  Provider:
Uncached
Cached hit

4 · Semantic cache — skip the model entirely

The highest layer, in your app. Embed the incoming query, search a small vector store of past queries, and if a previous one is close enough (cosine threshold), return its cached answer without calling the model at all. It adds an embedding + lookup to every request but can cut spend ~70% on repetitive workloads — the caveat being it returns an approximate match, so it's ideal for FAQ traffic and dangerous where small wording changes the correct answer.

query similar seen?vector lookup big model (skipped) cached answer hit → bypass
On a near-duplicate query, you return the stored answer and never pay for the model at all.

The four layers at a glance

LayerWhereWhat it saves
KV cacheGPU, within one callrecompute of past tokens during decode
Prefix cacheserver, across callsreprocessing a shared prompt prefix
Prompt cacheAPI billing50–90% off the cached prefix tokens
Semantic cacheyour appthe entire model call on near-duplicate queries
Carry into Chapter 7

The KV cache we started with lives in scarce GPU memory. Next we open up inference serving — prefill vs decode, batching, and why a faster GPU won't fix your latency.