The 9-Layer Inference Optimization Stack: Where Your 5-8x Cost Savings Actually Lives
The Cost Gap Is Real and Closable
A comprehensive taxonomy of 72 LLM inference optimizations across 9 layers quantifies what many teams intuit: the gap between naive FP16 serving and an optimized stack (vLLM/TensorRT-LLM with quantization, PagedAttention, continuous batching, and prompt caching) is 5-8x in cost-efficiency. LLM inference prices have already collapsed ~50x in 3.5 years ($20/M tokens → ~$0.40 for GPT-4-level performance), but most of that was serving optimization — and your stack likely hasn't captured it all.
The critical insight: the layers compound multiplicatively, and the highest-ROI moves require zero model changes.
The Priority Stack: ROI-Ordered
Application-layer caching is the single highest-leverage move — Anthropic reports 90% cost reduction and 85% latency reduction for long cached prompts. Most teams skip this. Batch API endpoints cut per-token cost ~50% for async workloads. If you're not measuring prompt cache hit rates on your highest-volume endpoints, start today.
Cache-aware routing is the infrastructure fix most teams are missing. Standard Kubernetes round-robin load balancing destroys your KV cache, dropping hit rates from 50-90% to 1/N across N replicas. Prefix cache-aware routing using radix trees and real-time KV cache events recovers 108% throughput improvement over standard K8s load balancing. If you're running vLLM or TensorRT-LLM behind round-robin, you have a one-week engineering sprint that pays for itself immediately.
Tool definition compression is the agentic efficiency win. Cloudflare's Code Mode collapses dozens of MCP tool definitions into two search-and-execute functions, reducing token costs 94-99.9%. The pattern is generalizable: instead of injecting all N tool schemas into every prompt (O(N) tokens), use lightweight retrieval to find relevant tools, then inject only matched schemas. An agent with 50 tools at 200 tokens each burns 10K tokens/turn on definitions alone — droppable to ~400.
Output tokens cost 3-10x more than input tokens — optimizing output shape (structured decoding, max_tokens caps, function calling) is higher leverage than optimizing input. Claude Sonnet 4: $3 input vs $15 output per M tokens.
The Prefill-Decode Asymmetry
On an H100 running Llama 70B, a single inference request hits 92% GPU compute utilization during prefill, then drops to 28% during decode. Co-locating both phases on the same GPU wastes 64% of decode compute capacity. This is why Perplexity, Meta, and Mistral all run prefill-decode disaggregation in production — and it's separately validated by Meta's Muse Spark results, which achieved 2-3x token efficiency at near-parity quality via thought compression (RL penalty on verbose reasoning tokens).
The KV Cache Is Your Real Memory Hog
A 70B model with 4K context per request consumes more KV cache than model weights for long-context workloads. Three techniques achieve >90% compression: MLA (93.3%) requires architecture changes at training time, SnapKV (92%) is inference-time applicable with 3.6x decode speedup, and PagedAttention eliminates fragmentation (already standard in vLLM).
Quantization: The New Default
FP8 on Hopper/Blackwell is the sweet spot — native hardware support means 2x compression AND speedup with minimal quality risk. For aggressive compression, AWQ provides fast INT4 deployment; GPTQ offers best accuracy at low bit-width but is slow to quantize. Meanwhile, Ternary Bonsai's 1.58-bit models (8B/4B/1.7B, Apache 2.0) claim 75.5 average benchmark at 3-4x energy efficiency over 1-bit counterparts — worth benchmarking against your 4-bit baselines for edge deployment.
What to do
Instrument prompt caching hit rates on your top-5 volume LLM endpoints this week
Audit your LLM serving load balancer for round-robin; implement prefix-hash routing within one sprint
Refactor agent tool injection to search-then-execute pattern for any agent with >5 tools
Benchmark FP8 quantization on Hopper/Blackwell GPUs against your current FP16 or INT8 baseline
Profile prefill vs decode GPU utilization under production load to size the disaggregation opportunity