0

Prompt Caching in Production: Architecture Patterns for AI Systems

An engineering deep dive on the four caching layers for LLM inference — KV/prefix caching, prompt caching, semantic caching, and exact-response caching — with architecture patterns, provider pricing analysis, and production deployment strategies.

Prompt CachingLLM InferenceProduction ArchitectureAI InfrastructureKV Cache

Prompt caching is the single highest-leverage optimization most production AI systems leave on the table. A single prompt layout change — moving dynamic content out of the prefix — can shift cache hit rates from 7% to 74%, cutting inference costs by 59% without touching a line of model code [1].

This essay covers the four caching layers that production AI systems need, the architecture patterns for deploying them at scale, and the engineering decisions that separate a 7% hit rate from a 74% one [1].

The Four Caching Layers

Most teams use “prompt caching” to mean different things. Here’s the precise taxonomy [2]:

Layer What it reuses Cost saved Risk
KV/Prefix cache Internal attention state (K/V tensors) Prefill compute, GPU memory Memory pressure, tenant isolation
Prompt cache Input tokens at the provider level Input token cost (50–90% discount) Still generates output tokens
Semantic cache Answers based on meaning (embedding similarity) Full inference call False positives, staleness
Exact response cache Identical normalized requests Full inference call Low coverage

The key insight: these are a stack, not alternatives. Response caches (exact + semantic) skip the model entirely. Prompt/KV caches only make model calls cheaper. A production system should use all four, in that priority order.

Layer 1: KV/Prefix Caching

KV caching is baked into the transformer architecture. During autoregressive decoding, each token’s attention computation produces key-value tensors. These tensors are cached in GPU VRAM so that subsequent tokens don’t recompute attention over the entire context.

The scaling problem: KV cache is local per GPU. With N replicas behind a round-robin load balancer, a request with an identical prefix has only a 1/N chance of hitting the replica that has it cached. Cache hit rate degrades nearly linearly as the fleet grows [3].

Session Affinity

The first fix is session-aware routing. Pin each user session to a specific replica. This keeps cached prefixes warm across multi-turn conversations. Engines like vLLM, SGLang (via RadixAttention), and TensorRT-LLM all support automatic prefix caching out of the box — but only if the same replica sees sequential requests from the same session [3].

┌─────────────┐     ┌──────────────┐
│ Load        │────→│ Replica 1    │  ← Session A pinned here
│ Balancer    │     │ (warm cache) │
│ (consistent │     └──────────────┘
│  hash)      │     ┌──────────────┐
│             │────→│ Replica 2    │  ← Session B pinned here
└─────────────┘     │ (warm cache) │
                    └──────────────┘

Tiered Prefix Caching for Multi-Task

Session affinity alone fails when a single replica handles multiple task types (summarization, code generation, chat). Each task has a different prefix — they evict each other’s cached entries.

The solution is a two-tier cache architecture [3]:

  • Tier 1 (shared): Common instruction prefixes cached on dedicated replica groups. Consistent hashing on the prefix routes requests to the correct group.
  • Tier 2 (session-specific): Branches reused within each session, extending beyond the Tier 1 prefix.

This architecture is what the major inference providers are building internally. The decision rule: use shared caching if recompute time > 100–300ms. For prompts under 500 tokens, session affinity alone is sufficient [3].

Layer 2: Provider Prompt Caching

At the API level, prompt caching is a pricing and latency optimization offered by all major LLM providers. The mechanism is the same across providers: hash the prompt prefix, store internal state, discount subsequent reads. But the implementation details differ significantly [1].

Provider Model Cache Type Read Discount Write Cost TTL
OpenAI GPT-4o, GPT-5.2 Automatic (≥1024 tokens) 50% None Provider-managed
Anthropic Claude Sonnet 4.5+ Explicit breakpoints 90% 1.25–2× input price 5 min / 1 hour
Google Gemini 2.5 Pro Both explicit + automatic 75–90% Storage $4.50/1M tokens/hour Configurable (default 60 min)

The Token Layout Problem

Prompt caching works via exact prefix matching. If the byte sequence at the start of the prompt differs between requests — even by one character — it’s a cache miss. This is the single most common reason teams see <10% cache hit rates [1].

The fix is a strict static-first, volatile-last prompt layout:

✅ Cache-friendly order:
1. System prompt (role + persona)       → Always cached
2. Core instructions + constraints      → Always cached
3. Tool schema definitions              → Always cached
4. Reference documents / knowledge base → Explicit cache, long TTL
5. Conversation history                 → Partially cached (grows per turn)
6. Current user message / dynamic input → Never cached

❌ Natural but destructive order:
1. User profile + session context       → Breaks prefix matching immediately
2. Retrieved documents                  → Different per query
3. System instructions                  → Different after insertions
4. User question                        → Last, but cache already missed

One team saw their cache hit rate jump from 7% to 74% by moving timestamps and session IDs out of the system prompt prefix [1]. A KV-cache-aware prompting benchmark from August 2025 showed stable prefixes costing $0.0096/request vs. $0.0333 for perturbed prefixes — a 71.3% cost difference driven entirely by prefix stability [1].

Strategic Cache Boundary Control

A January 2026 evaluation of prompt caching on long-horizon agentic tasks (DeepResearchBench, 100 PhD-level research tasks) tested three caching strategies across GPT-4o, GPT-5.2, Claude Sonnet 4.5, and Gemini 2.5 Pro [4]:

Strategy Cost Savings TTFT Improvement
No cache (baseline) — —
Full context caching 41–80% +13% to -8.8%
System prompt only 46–80% +6% to +31%
Exclude tool results 47–79% +13% to +23%

The critical finding: naive full-context caching can increase latency. GPT-4o showed an 8.8% TTFT regression under full-context caching because cache writes for dynamic tool results introduced overhead without reuse benefits. Strategic boundary control — caching only the stable system prompt — provided the most consistent improvements across all models [4].

Cost savings scale linearly with prompt size: 10–45% at 500 tokens to 54–89% at 50,000 tokens. At 50K tokens, GPT-5.2 achieves 89% savings ($0.253 → $0.029 per request) [4].

Layer 3: Semantic Caching

Semantic caching maps varied queries to a single answer via embedding similarity. This is where the big cost savings live — but also where the risk is highest [2].

The architecture:

User query
    │
    ▼
Embedding model ─→ Vector DB lookup ─→ Similarity ≥ threshold?
                                        │                  │
                                      Yes                 No
                                        │                  │
                                    Return cache        LLM call
                                    (skip model)    Store response
                                                       in cache

The False Positive Problem

A false miss costs tokens. A false hit costs credibility [2]. For a financial services AI assistant, a semantic cache returning a hit with 0.87 similarity on queries that “sound similar” but have different regulatory contexts caused $34,200 in undetected incorrect answers in one documented case [5].

Safe semantic cache hits require multi-dimensional gating beyond cosine similarity:

  • Same tenant or public scope
  • Same locale
  • Same product/version
  • Same permission boundary
  • Same source document version
  • Same answer type
  • Freshness still valid
  • No policy override [2]

When to Use Semantic Caching

Workload Semantic Cache? Why
FAQ / documentation answers Yes Stable facts, repeated intent
Customer support (known issues) Yes, with tenant scoping High repetition
Coding agents Rarely (final answer only) Context repeats, output task-specific
Legal / regulated answers Carefully Strict freshness, high precision
Incident status Usually no Truth changes quickly

Layer 4: Exact Response Caching

The simplest layer and the one with the least coverage. Hash the normalized request (prompt + parameters + temperature), check Redis (or equivalent), return the cached response on hit.

This is trivially low-risk — same input, same deterministic output — but coverage is near-zero for creative generation. It matters most for:

  • Classification tasks at temperature 0
  • FAQ-style answers with identical wording
  • Multi-turn agents repeating exact system prompts (though prompt caching already handles this)

Monitoring: What to Track

Aggregate cache hit rates are deceptive. Track per workload [1]:

Metric What it tells you
Cache hit rate per workload Isolates which prompt templates are broken
Cache read tokens as % of input tokens Direct cost-reduction signal
TTFT distribution (P50, P95) Cache hits shift latency percentiles lower
Cost per agent session Business-level ROI metric
Per-replica cache utilization Whether session affinity is working

For OpenAI: prompt_tokens_details.cached_tokens. For Anthropic: cache_read_input_tokens / (input_tokens + cache_creation_input_tokens + cache_read_input_tokens). Target: 70%+ for stable-prompt workloads. Red flag: <40% means dynamic content is in the prefix [1].

Putting It Together: A Production Architecture

A complete caching stack for a production AI system:

Request
   │
   ▼
┌──────────────────────────────────┐
│ Layer 4: Exact Response Cache    │ ← Redis, hashed request
│ (skip model if exact match)      │
└───────────┬──────────────────────┘
            │ (miss)
            ▼
┌──────────────────────────────────┐
│ Layer 3: Semantic Cache          │ ← Vector DB, multi-dim gate
│ (skip model if safe semantic hit)│
└───────────┬──────────────────────┘
            │ (miss)
            ▼
┌──────────────────────────────────┐
│ Load Balancer (consistent hash)  │ ← Pins session to replica
└───────────┬──────────────────────┘
            │
            ▼
┌──────────────────────────────────┐
│ Replica with warm KV cache       │ ← Tier 1 + Tier 2 prefixes
│ → LLM call at cached input price │
└──────────────────────────────────┘

At 100,000 sessions/day with 10,000-token system prompts on Claude Opus 4.6-class models, a 75% cache hit rate on the system prompt portion delivers ~67.5% cost reduction on system prompt tokens. If the system prompt is 40–60% of total tokens, that’s a 30–45% total inference cost reduction — purely from token layout and routing changes [1].

References

[1] AgentMarketCap, “Prompt Cache Hit Rate Engineering: How Production Teams Are Cutting AI Costs 60–85%,” April 2026. agentmarketcap.ai/blog/2026/04/11/prompt-cache-hit-rate-engineering-2026

[2] Ace The Cloud, “The Cache Has Layers: Prompt Caching, Semantic Caching, and When Each One Betrays You,” April 2026. acethecloud.com/blog/prompt-caching-semantic-caching-tradeoffs/

[3] DigitalOcean, “Advanced Prompt Caching at Scale,” April 2026. digitalocean.com/blog/advanced-prompt-caching

[4] Lumer et al., “Don’t Break the Cache: An Evaluation of Prompt Caching for Long-Horizon Agentic Tasks,” arXiv:2601.06007, January 2026. arxiv.org/pdf/2601.06007

[5] Amul Kumar, “Prompt Caching vs Semantic Caching: Real-World Tradeoffs in Production LLM Systems,” May 2026. (Case study: $34,200 in undetected incorrect answers from semantic cache false positives.)

📖 Related Reads

  • ToolBrain — tool reviews, LLM comparisons, and AI workflow guides

Cross-links automatically generated from CodeIntel Log.