KV Cache Optimization is the set of techniques for reducing memory footprint and bandwidth requirements of cached key-value pairs in autoregressive transformer inference — including quantization (INT8/INT4), eviction policies, compression, and architectural changes that collectively enable 2-10× memory reduction, allowing larger batch sizes, longer contexts, or deployment on smaller GPUs while maintaining generation quality.

KV Cache Fundamentals:

• Cache Purpose: in autoregressive generation, each token attends to all previous tokens; recomputing K and V for all previous tokens at each step costs O(L²) FLOPs; caching K and V reduces to O(L) per token; trades memory for compute
• Memory Scaling: for model with L layers, H heads, sequence length N, head dimension d, batch size B: cache size = B×L×2×N×H×d×sizeof(dtype); Llama 2 70B at N=4096, B=32, FP16: 70×2×4096×8×128×2 = 58GB just for KV cache
• Bandwidth Bottleneck: each generated token loads entire KV cache from HBM; at 4K context, loads 1.8GB per token; A100 HBM bandwidth 1.5TB/s limits to ~800 tokens/sec; memory bandwidth, not compute, determines throughput
• Growth During Generation: cache grows by B×L×2×H×d×sizeof(dtype) per token; for Llama 2 70B, adds 14MB per token; 1000-token generation requires 14GB additional memory; limits maximum batch size or context length

<svg viewBox="0 0 760 470" xmlns="http://www.w3.org/2000/svg" font-family="-apple-system,Segoe UI,Roboto,sans-serif">
  <rect x="0" y="0" width="760" height="470" fill="#0d1117"/>
  <text x="380" y="28" fill="#e6edf3" font-size="21" font-weight="700" text-anchor="middle">KV Cache — The Memory Bottleneck of LLM Inference</text>
  <text x="380" y="48" fill="#8b98a5" font-size="12" text-anchor="middle">store past key/value tensors to avoid recomputation — grows linearly with context length</text>

  <!-- Why KV cache exists -->
  <rect x="30" y="65" width="700" height="115" rx="6" fill="#080d14" stroke="#233043" stroke-width="1"/>
  <text x="380" y="84" fill="#e6edf3" font-size="11" font-weight="600" text-anchor="middle">Why KV Cache: Avoid Recomputing Attention</text>

  <!-- Without cache -->
  <text x="50" y="108" fill="#f87171" font-size="9" font-weight="600">Without cache (step t):</text>
  <text x="50" y="124" fill="#8b98a5" font-size="8">recompute K, V for ALL t tokens → O(t²) per step → O(t³) total</text>

  <!-- With cache -->
  <text x="50" y="148" fill="#34d399" font-size="9" font-weight="600">With KV cache (step t):</text>
  <text x="50" y="164" fill="#8b98a5" font-size="8">compute K_t, V_t for new token only → append to cache → O(t) per step → O(t²) total</text>

  <!-- Visual: growing cache -->
  <rect x="470" y="98" width="20" height="60" rx="2" fill="#1e3a5f" stroke="#60a5fa" stroke-width="0.4"/>
  <rect x="494" y="98" width="20" height="60" rx="2" fill="#1e3a5f" stroke="#60a5fa" stroke-width="0.4"/>
  <rect x="518" y="98" width="20" height="60" rx="2" fill="#1e3a5f" stroke="#60a5fa" stroke-width="0.4"/>
  <rect x="542" y="98" width="20" height="60" rx="2" fill="#1e3a5f" stroke="#60a5fa" stroke-width="0.4"/>
  <rect x="566" y="98" width="20" height="60" rx="2" fill="#1e3a5f" stroke="#60a5fa" stroke-width="0.4"/>
  <rect x="590" y="98" width="20" height="60" rx="2" fill="#14261f" stroke="#34d399" stroke-width="0.8"/>
  <text x="600" y="132" fill="#34d399" font-size="7" text-anchor="middle">new</text>
  <text x="530" y="170" fill="#6b7684" font-size="7" text-anchor="middle">cached K/V from previous tokens</text>

  <!-- Memory calculation -->
  <rect x="30" y="190" width="345" height="130" rx="6" fill="#080d14" stroke="#233043" stroke-width="1"/>
  <text x="202" y="210" fill="#e6edf3" font-size="10" font-weight="600" text-anchor="middle">KV Cache Size Formula</text>

  <text x="50" y="234" fill="#38bdf8" font-size="9.5" font-weight="600">size = 2 × L × n_kv × d_head × seq × bytes</text>
  <text x="50" y="254" fill="#8b98a5" font-size="8">L=80 layers, n_kv=8 (GQA), d_head=128, seq=128K, FP16</text>
  <text x="50" y="270" fill="#8b98a5" font-size="8">= 2×80×8×128×131072×2 = 32 GB per sequence!</text>
  <text x="50" y="290" fill="#f87171" font-size="8">batch of 16 → 512 GB KV cache alone</text>
  <text x="50" y="308" fill="#6b7684" font-size="7.5">this is why long context is expensive — KV cache dominates memory</text>

  <!-- Optimization techniques -->
  <rect x="390" y="190" width="340" height="130" rx="6" fill="#080d14" stroke="#233043" stroke-width="1"/>
  <text x="560" y="210" fill="#e6edf3" font-size="10" font-weight="600" text-anchor="middle">Optimization Techniques</text>

  <text x="410" y="234" fill="#34d399" font-size="8.5" font-weight="600">GQA (8 KV heads vs 32):</text><text x="580" y="234" fill="#8b98a5" font-size="8">4× smaller cache</text>
  <text x="410" y="252" fill="#60a5fa" font-size="8.5" font-weight="600">KV quantization (INT8):</text><text x="580" y="252" fill="#8b98a5" font-size="8">2× compression</text>
  <text x="410" y="270" fill="#a78bfa" font-size="8.5" font-weight="600">PagedAttention:</text><text x="545" y="270" fill="#8b98a5" font-size="8">no fragmentation waste</text>
  <text x="410" y="288" fill="#f59e0b" font-size="8.5" font-weight="600">Sliding window (W=4K):</text><text x="590" y="288" fill="#8b98a5" font-size="8">bounded cache</text>
  <text x="410" y="306" fill="#f87171" font-size="8.5" font-weight="600">Token eviction (H₂O):</text><text x="575" y="306" fill="#8b98a5" font-size="8">keep only important KVs</text>

  <!-- Bottom: prefix caching -->
  <rect x="30" y="332" width="700" height="98" rx="6" fill="#080d14" stroke="#233043" stroke-width="1"/>
  <text x="380" y="352" fill="#e6edf3" font-size="10" font-weight="600" text-anchor="middle">Advanced: Prefix Caching &amp; Multi-Query Serving</text>
  <text x="50" y="374" fill="#8b98a5" font-size="8.5">• System prompt KV cached once, shared across all requests (saves 80%+ recomputation)</text>
  <text x="50" y="392" fill="#8b98a5" font-size="8.5">• Radix tree indexing: reuse any common prefix (SGLang)</text>
  <text x="50" y="410" fill="#8b98a5" font-size="8.5">• Cross-request KV sharing: same document, different questions → compute KV once</text>
  <text x="50" y="424" fill="#6b7684" font-size="7.5">vLLM automatic prefix caching: hash-based dedup of KV blocks across requests</text>

  <text x="380" y="452" fill="#6b7684" font-size="11" text-anchor="middle">KV cache is the dominant memory cost in LLM serving — optimizing it directly translates to $/token savings.</text>
</svg>

Quantization Techniques:

• INT8 KV Cache: quantize cached K and V from FP16 to INT8; 2× memory reduction; per-tensor or per-channel quantization; dequantize before attention computation; quality loss <0.1 perplexity for most models; supported in TensorRT-LLM, vLLM, HuggingFace TGI
• INT4 KV Cache: aggressive 4× reduction; requires careful calibration; group-wise quantization (groups of 32-128 elements) maintains quality; perplexity increase 0.1-0.3; enables 4× larger batches or contexts; used in GPTQ-for-LLMs, AWQ
• Mixed Precision: quantize V cache more aggressively than K; V contributes to output values (less sensitive), K affects attention scores (more sensitive); K in INT8, V in INT4 provides 3× reduction with minimal quality loss
• Dynamic Quantization: quantize during generation, not ahead of time; adapts to actual value distributions; slightly higher latency (quantization overhead) but better quality; used in production systems with strict quality requirements

Eviction and Compression:

• H2O (Heavy Hitter Oracle): evicts KV pairs with lowest attention scores; keeps "heavy hitter" tokens that receive most attention; maintains 20-30% of cache with <1% quality loss; requires tracking attention scores (overhead); effective for long contexts where most tokens rarely attended
• StreamingLLM: keeps first few tokens (system prompt) and recent window; evicts middle tokens; exploits observation that attention focuses on recent context and initial tokens; enables infinite context with fixed memory; quality depends on task (good for chat, poor for long-document QA)
• Scissorhands: learns to predict which KV pairs can be evicted; trains small predictor network on attention patterns; achieves 50-70% cache reduction with <0.5% quality loss; requires model-specific training
• Sparse Attention Patterns: for models with structured sparsity (sliding window, block-sparse), only cache tokens within attention pattern; Mistral 7B with 4K sliding window caches only 4K tokens regardless of total length; enables unbounded generation

Architectural Optimizations:

• Multi-Query Attention (MQA): shares K and V across all query heads; reduces cache by number of heads (typically 32-64×); used in PaLM, Falcon; 1-2% quality trade-off for massive memory savings
• Grouped Query Attention (GQA): shares K and V across groups of heads; 4-8× cache reduction with <0.5% quality loss; used in Llama 2, Mistral; sweet spot between MHA and MQA
• Cross-Layer KV Sharing: shares KV cache across multiple layers; reduces cache by factor of layers sharing; experimental technique; 2-4 layers can share with acceptable quality loss; total reduction 2-4×
• Low-Rank KV Projection: projects K and V to lower dimension before caching; cache stores low-rank version; reconstruct full dimension during attention; 2-4× reduction; requires architecture modification and retraining

PagedAttention and Memory Management:

• PagedAttention (vLLM): treats KV cache like virtual memory with paging; divides cache into fixed-size blocks (pages); non-contiguous storage eliminates fragmentation; enables near-optimal memory utilization (90-95% vs 20-40% for naive allocation)
• Block Size: typical block size 16-64 tokens; smaller blocks reduce internal fragmentation but increase metadata overhead; 32 tokens balances trade-offs for most workloads
• Copy-on-Write: multiple sequences can share cache blocks (e.g., common prompt); only copy when sequences diverge; critical for beam search and parallel sampling where sequences share prefix
• Memory Pool: pre-allocates memory pool for cache blocks; eliminates allocation overhead during generation; enables predictable latency; pool size determines maximum concurrent requests

Production Deployment Impact:

• Throughput: INT8 quantization + PagedAttention enables 2-3× higher throughput vs naive FP16 caching; serves 100-200 requests/sec vs 30-50 for Llama 2 70B on 8×A100
• Latency: reduced memory bandwidth improves time-to-first-token by 20-40%; subsequent tokens 10-20% faster; critical for interactive applications where latency matters
• Cost: 2-4× memory reduction enables deployment on smaller/fewer GPUs; Llama 2 70B with optimizations fits on 4×A100 vs 8×A100; halves infrastructure cost
• Context Length: memory savings enable 2-4× longer contexts at same batch size; or maintain context while increasing batch size 2-4×; flexibility to optimize for throughput or capability

KV Cache Optimization is the critical enabler of practical LLM deployment — by addressing the memory bottleneck that dominates inference costs, these techniques transform LLMs from research artifacts requiring massive GPU clusters into production systems that serve millions of users on reasonable hardware budgets.