The LLM KV cache is becoming a tiered distributed storage system
Long-context serving increasingly depends on whether reusable attention state can be identified, isolated, placed, transferred, prefetched and invalidated across GPU memory, host DRAM, NVMe and remote stores. The KV cache is therefore moving from an engine-local allocation detail toward a governed storage and routing plane with database-like identity, locality, consistency, security and lifecycle obligations.
What is happening?
During generation, a transformer stores key and value tensors for the tokens it has already processed. Reusing those tensors can avoid repeating expensive prompt work. At small scale, the cache can live only inside one GPU process. At production scale, teams increasingly move it between workers and storage tiers so another request, another turn or a separate decode server can use it. That makes the cache behave like distributed data: the system must know exactly what it represents, who may reuse it, where it is stored, whether it is still compatible, how expensive it is to fetch and when it must be deleted.
Why this trend is moving
- 01Long prompts, retrieval-heavy applications and multi-turn agents repeatedly process shared prefixes and reusable context blocks.
- 02KV state grows with layers, heads, sequence length, precision and concurrency, making GPU memory the limiting resource even when model weights fit.
- 03Serving frameworks now provide connectors that move cache state between prefill and decode workers and across GPU, CPU, disk and remote tiers.
- 04Cache-aware routers increasingly trade prefix locality against queue depth, tail latency, topology and worker health.
- 05Hierarchical cache systems expose write-through, write-back, selective persistence, prefetch and remote-storage policies that resemble storage-engine controls.
- 06Compression and selective-retention methods can reduce memory or transfer bytes but may alter quality, attention behavior and random-access cost.
- 07Cross-tenant cache reuse creates timing, privacy, deletion and provenance obligations that ordinary performance dashboards do not reveal.
What this means in practice
- A cache key must bind the exact tokenization, model revision, adapter, attention configuration, precision, layout and trust domain—not merely a prompt string.
- GPU hit rate is not enough; measure useful reuse after lookup, transfer, decode and output acceptance, including misses caused by incompatible layouts or stale metadata.
- Routing must balance locality with worker load because sending every repeated prefix to one node can create a cache hot spot and worse tail latency.
- Tiering policy should be explicit about promotion, demotion, write mode, prefetch, eviction, replication and persistence rather than relying on undocumented defaults.
- Cache compression, pruning or quantization requires task-level quality qualification and a safe full-cache fallback.
- Tenant isolation, cache salting, encryption, access control and deletion propagation are part of inference security, not optional storage polish.
- Complete economics must compare saved prefill compute with transfer bandwidth, storage, metadata, misses, invalidations and operations cost.
What the headline leaves out
This is the practical technical view: how the system is put together, where it can fail, and what a real deployment asks from the team running it.
How it is built
A production KV storage plane begins with a cache identity contract that binds model, tokenizer, adapter, attention layout, KV precision, block boundaries, multimodal inputs, system policy and tenant scope. The inference engine creates paged cache blocks and publishes immutable metadata and lifecycle events. A locality index records which compatible blocks exist on each worker and tier without exposing prompt content. The router estimates recomputation cost, overlap, queue pressure and transfer cost before choosing local execution, remote reuse or fresh prefill. A tier manager keeps the active working set in GPU memory, promotes and demotes blocks through host DRAM, NVMe or remote storage, and enforces quotas and retention. Transfer connectors negotiate layout and topology, validate digests and overlap movement with layer execution. Admission and eviction controls protect memory headroom and avoid thrashing. Observability connects each lookup to hit depth, bytes moved, time saved, quality outcome and tenant authorization. Failure handling invalidates uncertain state and falls back to recomputation. Promotion requires end-to-end evidence that the cache plane improves accepted-task latency and cost without crossing correctness or privacy boundaries.
How inference behaves
Each processed block produces keys and values for every attention layer. Prefix caching typically hashes token blocks together with prior-block identity and extra model inputs, then reuses only exact compatible prefixes. Hierarchical systems copy or encode blocks into slower tiers and later prefetch them before attention needs them. Disaggregated serving sends the prefill result to a decode worker, sometimes through direct GPU memory transfer over NVLink or RDMA. Global routers consume cache events or approximate placement and choose workers by predicted overlap and load. The critical path includes lookup, metadata validation, block allocation, transfer, optional decode or decompression, layer-wise insertion and synchronization. A nominal hit can still lose if the object is too far away, the network is congested, the layout differs, prefetch arrives late or the worker becomes overloaded. Correct invalidation must follow model, tokenizer, adapter, policy, tenant and retention changes.
What the tests can miss
Evaluate exact model and cache identities across repeated prefixes, multi-turn sessions, RAG documents, multimodal placeholders, adapters, quantized KV formats, mixed context lengths and realistic concurrency. Report lookup hit rate by tier, reusable-token ratio, useful-hit ratio after compatibility checks, bytes read and written, transfer and prefetch latency, TTFT, inter-token latency, throughput at fixed SLO, queue delay, eviction and promotion rates, duplicate storage, metadata lag, recomputation avoided, quality drift, isolation failures and cost per accepted task. Test cold start, warm steady state, bursty hot prefixes, low-reuse traffic, worker scaling, node loss, stale cache events, network degradation, storage failure, tenant deletion and model rollout. Compare no cache, engine-local prefix cache, cache-aware routing, hierarchical offload, remote store, disaggregated prefill and compressed-cache variants.
What deployment involves
Start with engine-local exact-prefix reuse and a deterministic cache identity. Measure the real reusable-prefix distribution before adding remote storage. Introduce a single host-memory tier with hard quotas, explicit write-through behavior and a recompute fallback. Add cache-aware routing only after worker cache events and load metrics are trustworthy. Canary remote or NVMe tiers for large stable prefixes where saved prefill exceeds transfer and decode cost. Use content-addressed objects, signed metadata and versioned connector compatibility. Keep tenant sharing disabled by default, with explicit salts or policy groups. Define invalidation for model, tokenizer, adapter, prompt-policy and data-retention changes. Promote disaggregated prefill only when topology and RDMA behavior are qualified, and retain an aggregated path for workloads where transfer is slower than recomputation.
Where the risks sit
KV caches can encode sensitive prompt content and can reveal cache presence through timing. Derive keys from canonical token and model state, but never expose raw keys or metadata as a content oracle. Partition or salt cache namespaces by tenant and policy; authenticate every lookup, store, transfer and eviction operation. Encrypt remote and persistent tiers where appropriate, protect RDMA registration and memory descriptors, and verify object digests before insertion into GPU memory. Apply retention and deletion to every replica and tier, including indexes and transfer buffers. Bound untrusted requests that deliberately create unique prefixes, force thrashing or probe shared cache timing. Treat connectors, codecs and storage plugins as native-code and supply-chain components. On uncertainty, invalidate and recompute rather than serving incompatible state.
What it really costs
Cache economics include GPU reservation, pinned host memory, NVMe or object storage, metadata services, network fabric, compression and decompression, replication, cache misses, duplicate blocks, prefetch waste, invalidation, observability and operations. A remote hit is valuable only when its complete lookup and movement path costs less than recomputing the prompt while still meeting the service objective. High hit rate can be misleading if a few enormous objects dominate bytes or if cache affinity overloads workers. Compare dollars per accepted request and GPU-seconds avoided at fixed quality and latency, separating local, host, disk and remote tiers.
What the evidence supports
The evidence shows a clear systems convergence. vLLM exposes paged blocks, hashed prefix identity, cache salting, offload backends and multiple KV connectors. SGLang combines RadixAttention, cache-aware routing, hierarchical host and remote storage and prefill–decode transfer. LMCache and Mooncake make reusable KV state available across processes and storage tiers, while NVIDIA Dynamo adds global routing, block management and topology-aware transfer. CacheGen, CacheBlend and related research treat cache state as a stream or reusable content object; eviction and quantization research explores memory reduction with different quality risks. The specific performance gains remain workload- and topology-dependent, but the architectural direction is strong: KV state is becoming a first-class distributed storage object whose identity, placement and lifecycle must be governed.
How it works in practice
KV-cache reuse is production-safe only when exact state identity, authorization, locality, storage tier, transfer compatibility, quality, invalidation and deletion are governed as one distributed data system. A high cache-hit percentage without those controls is not evidence of a reliable serving architecture.
How the parts work together
The headline technology is only one part of the product. Reliability, security and cost are usually decided by the handoffs around it.
- 1
Define the cache identity contract
Bind every reusable block to model, tokenizer, adapter, attention layout, precision, block boundaries, multimodal inputs, prompt-policy version and tenant scope.
- 2
Create paged engine-local state
Allocate deterministic KV pages, record block lineage and expose lifecycle events without assuming that local GPU residency is permanent.
- 3
Publish locality and compatibility metadata
Maintain a bounded index of compatible blocks, owners, tiers, digests, expiry and topology while keeping prompt content and sensitive identifiers out of the routing plane.
- 4
Route by reuse value and load
Estimate saved prefill work, queue delay, transfer cost, cache depth, topology and worker health before choosing local reuse, remote retrieval or recomputation.
- 5
Place state across storage tiers
Keep the active working set in GPU memory and govern promotion, demotion, write-through, write-back, persistence, quotas and eviction across host DRAM, NVMe and remote stores.
- 6
Transfer and materialize safely
Negotiate connector capabilities, verify layout and digests, move blocks through the best qualified path and overlap layer-wise loading with compute where correctness allows.
- 7
Observe useful reuse
Join lookup, transfer, insertion, attention execution and output acceptance so nominal hits can be separated from hits that actually improve user-visible service.
- 8
Invalidate, delete and recover
Propagate model, policy, tenant and retention changes to every replica and tier, and recompute when metadata, transfer or storage state is uncertain.
- 9
Promote from complete evidence
Accept a cache architecture only when latency, quality, isolation, reliability and complete cost improve across representative traffic and failure conditions.
Estimate the limits before the demo
These equations are planning tools rather than substitutes for testing. They help expose a design that is unlikely to fit its hardware, budget, reliability or risk limits.
Useful cache-hit ratio
H_u = N_reused,accepted / N_lookup A useful hit is compatible, authorized, transferred in time and followed by an accepted output. Raw metadata hits overstate value when blocks are stale, remote, late or incompatible.
- Report separately for GPU, host, local storage and remote tiers.
- Count fallback recomputation as a miss even when the metadata lookup succeeded.
- Stratify by prefix length because one enormous hit can hide many ineffective small hits.
Remote-reuse break-even condition
Reuse when T_lookup + T_queue + T_transfer + T_materialize < T_recompute - M_risk Remote state is beneficial only when the complete retrieval path is faster than recomputation after reserving a margin for variance, failure and quality risk.
- A network hit may lose for short prefixes even on fast RDMA.
- Prefetch can reduce materialization time but creates wasted reads when predictions are wrong.
- Use tail values, not only means, for the production decision.
Tier admission value
V_o = P_reuse * C_recompute - C_store - C_fetch - C_eviction - C_privacy An object belongs in a persistent or remote tier only when expected saved recomputation exceeds storage, retrieval, churn and policy cost over its valid lifetime.
- Stable system prompts and large shared documents can have high reuse value.
- Unique personal conversations usually have low shared value and high privacy cost.
- Recalculate after model, product or traffic changes.
Complete cost per accepted request
C_accept = (C_gpu + C_host + C_disk + C_remote + C_network + C_metadata + C_miss + C_ops) / N_accepted The numerator includes every cache tier, transfer, duplicate, failed lookup, invalidation and operational control. The denominator includes only outputs meeting quality and service objectives.
- Compare against a qualified no-cache baseline.
- Separate steady-state cost from cold start and model-rollout invalidation.
- Include storage reserved for isolation, replication and recovery.
KV state is no longer only a temporary GPU buffer
The key and value tensors produced by attention summarize how every processed token participates in future decoding. Reusing them avoids repeating the prompt phase, which can be the dominant cost for long contexts.
Once state is shared across requests, workers or time, it acquires storage-system properties: identity, location, ownership, lifetime, replication, transfer, eviction and failure semantics.
The correct abstraction is therefore not merely “memory saved.” It is a distributed state object whose use must preserve the exact computation that fresh prefill would have produced.
- GPU pages are the hottest tier, not the entire system.
- Cache metadata participates in routing and scheduling.
- Remote reuse creates consistency and authorization questions.
- Deletion must reach every copy, index and transfer buffer.
A cache hit is valid only for an exact execution identity
Matching visible prompt text is insufficient. Tokenizer revision, special tokens, chat template, model checkpoint, adapter, multimodal processor, attention implementation, positional encoding, KV precision and block layout can all change the produced tensors.
Robust systems hash canonical token blocks together with parent-block identity and additional model inputs. Distributed systems also need connector, tensor-parallel and pipeline-parallel compatibility metadata.
Identity should be immutable and content-addressed. When an input cannot be represented safely in the key, reuse should be disabled rather than approximated.
- Version model and tokenizer independently.
- Include adapter and prompt-policy identity.
- Bind multimodal placeholders to processed-content digests.
- Record cache dtype, layer grouping and physical layout.
Exact prefixes are the safest case; broader reuse needs recomputation controls
Prefix reuse preserves causal position: cached tokens appear in the same order at the beginning of a later request. That makes it straightforward to skip already-computed attention work.
RAG and modular prompts may reuse chunks that appear in different positions or combinations. Systems such as CacheBlend selectively recompute portions so cached knowledge can be fused with new context.
Broader reuse can create larger savings, but it adds positional, attention and quality assumptions. It needs task-level equivalence tests and must not be treated as an ordinary exact hit.
GPU, host, NVMe and remote stores need explicit tiering policy
GPU memory offers the lowest access latency but competes directly with weights, active sequences, workspaces and batch capacity. Host DRAM offers a larger nearby tier, while NVMe and remote stores trade capacity for transfer and metadata cost.
Write-through makes lower-tier durability and reuse predictable but increases write traffic. Write-back reduces immediate traffic but risks losing unflushed state. Selective policies persist only high-value blocks.
Promotion, demotion and eviction should use measured reuse value, object size, fetch cost, expiry, tenant quota and topology—not a single global least-recently-used list.
- Reserve GPU headroom to avoid preemption and thrashing.
- Use pinned or registered host memory deliberately because it is not free.
- Align large objects and I/O paths to storage and network characteristics.
- Limit remote replication to justified hot or recovery-critical objects.
Cache affinity and load balancing can conflict
Routing a request to the worker with the largest cached prefix can save prefill, but repeated popular prefixes may overload one worker while others sit idle.
A useful router estimates both saved computation and current cost: active KV blocks, queue depth, expected decode work, topology, transfer options and service-level risk.
Cache events can provide a more accurate global index, while approximate routing reduces control-plane traffic but can become stale after eviction, failure or scaling. The chosen consistency model must be visible in metrics.
- Measure cache-local and load-local decisions separately.
- Use SLO-aware override when the best cache location is overloaded.
- Rebuild or reconcile indexes after worker recovery.
- Test hot-prefix attacks and sudden skew.
Disaggregated prefill turns KV transfer into a critical path
Prefill is often compute-heavy, while decode is dominated by memory bandwidth and repeated cache reads. Splitting them allows independent scaling and can protect decode latency from long prompts.
The decode worker cannot continue until compatible state is available. Transfer therefore becomes part of time to first token and depends on allocation, descriptors, topology, transport, layout conversion and synchronization.
Disaggregation is not automatically a throughput improvement. For short prefixes, low concurrency or weak networks, local recomputation can be simpler and faster. A production router should support a qualified local path.
Connector compatibility is more than network reachability
A sender and receiver may use different tensor-parallel sizes, cache page layouts, attention types, precisions or layer groupings. Moving bytes successfully does not prove that the destination interprets them correctly.
Connectors need a handshake that covers model identity, ranks, layouts, block mapping, memory descriptors and supported transfer operations. Digests and completion signals should be checked before blocks become visible to attention.
Layer-wise transfer can overlap movement with execution, but partial visibility complicates cancellation and recovery. Failed requests must not leave reusable half-written state.
- Validate heterogeneous TP and pipeline layouts explicitly.
- Separate control-plane metadata from data-plane transfer.
- Measure fallback from RDMA to TCP or storage paths.
- Invalidate destination blocks after uncertain completion.
Compression changes the quality contract
Quantization, token eviction, head-specific budgets and encoded transfer streams can reduce memory and bandwidth. They also alter the state consumed by attention or add decode work on the critical path.
Methods that perform well on retrieval or long-context benchmarks may fail on code, exact copying, multilingual prompts, adversarial needles or a different model family. Worst-case analysis also shows that not every cache is safely compressible.
Every codec or retention policy should be versioned, evaluated by task and reversible. Full-precision or fresh-prefill fallback remains necessary for unsupported models and quality alarms.
- Measure attention and output quality, not only reconstruction error.
- Include codec latency and random-access behavior.
- Test mixed-length batches and layer-specific sensitivity.
- Do not silently change compression during an active session.
Shared cache state can expose content through access and timing
KV tensors are derived from prompt content. Even when they cannot be easily decoded into text, their presence, metadata, reuse timing and ownership can reveal that another request processed a particular prefix.
Tenant-specific namespaces or salts prevent unauthorized cross-tenant hits. Access control must apply to lookup, transfer, persistent storage and observability, not only to the original inference API.
Retention and deletion requests must remove every replica and index entry. Logs should record object identifiers and reason codes without retaining raw prompt material unnecessarily.
The safest cache failure mode is recomputation, not uncertain reuse
Cache stores, event planes, routers and transfer paths can fail independently. Metadata may say a block exists after it was evicted, or a partial object may remain after a node or link failure.
State should move through explicit pending, committed, expired and invalid states. Readers must not observe an object until its integrity and compatibility are confirmed.
When uncertainty exists, invalidate and recompute. This costs latency but preserves model meaning. Recovery tests should include stale events, index loss, split-brain metadata, partial writes and restart during transfer.
- Use idempotent writes and deletions.
- Reconcile indexes against actual storage.
- Bound retry storms and duplicate transfers.
- Keep a no-remote-cache serving mode.
Raw hit rate is not an operational KPI
A cache can report a high hit rate while increasing tail latency because objects reside on slow tiers or affinity routing overloads workers. It can also save many tokens but few milliseconds when prefixes are short.
Useful telemetry joins lookup result, matched tokens, tier, bytes, transfer path, materialization time, queue delay, recomputation avoided, output acceptance and tenant authorization.
Metrics should expose metadata lag, duplicate objects, prefetch waste, eviction churn and invalidation backlog. Without those signals, storage and routing failures appear as unexplained inference latency.
- Useful-hit ratio and reusable-token ratio.
- TTFT saved by tier and prefix bucket.
- Transfer bandwidth, queue and tail latency.
- Eviction, promotion, duplicate and invalidation rates.
- Fallback recomputation and quality alarms.
Build outward from exact local reuse
Start with deterministic engine-local prefix caching and measure the actual reuse distribution. This establishes the identity model and a reliable no-network baseline.
Add one host tier and explicit quotas before introducing remote storage. Then add cache-aware routing with observable cache events. Only after those controls are stable should the system attempt disaggregated prefill, persistent remote stores or approximate cache blending.
Each new tier or algorithm should have a narrow workload target, canary pool, rollback switch and break-even threshold. More cache infrastructure is not inherently better than recomputation.
What a benchmark worth believing should report
A performance number means little unless the workload, system configuration and quality bar are fixed. This is the minimum record a team should keep.
| Metric | How to measure it | Why it matters |
|---|---|---|
| Cache identity accuracy | Agreement between cache keys and exact model, tokenizer, adapter, layout, precision and input state | A fast hit on incompatible tensors can silently corrupt output. |
| Useful-hit ratio | Authorized compatible hits that arrive in time and produce accepted outputs divided by lookups | Metadata hits alone do not establish value. |
| Reusable-token ratio | Tokens skipped through reuse divided by total prefill tokens, by workload and tier | A count of requests hides how much compute was actually avoided. |
| Tier latency and bandwidth | Lookup, queue, read, transfer, decode and insertion time with bytes per operation | The slowest stage determines whether reuse beats recomputation. |
| End-to-end service performance | TTFT, inter-token latency, throughput and p95/p99 tails at fixed accepted quality | Microbenchmarks can improve while user-visible service regresses. |
| Cache-routing balance | Worker load, cache affinity, hot-prefix concentration and SLO overrides | Locality can create worker hot spots. |
| Eviction and churn | Promotions, demotions, evictions, duplicate writes, prefetch waste and recomputation after eviction | Thrashing consumes bandwidth and GPU cycles without durable benefit. |
| Quality equivalence | Task scores, exact-match, perplexity and output-difference review for compressed or blended state | Reduced storage is unacceptable when it changes the task result beyond policy. |
| Isolation and lifecycle | Unauthorized-hit attempts, salt or namespace separation, replica deletion and expiry completion | Cache reuse must respect tenant and retention boundaries. |
| Failure recovery | Behavior under stale metadata, node loss, partial transfer, storage outage and connector mismatch | The system must fall back safely instead of serving uncertain state. |
Four sensible deployment patterns
Engine-local exact prefix cache
- Where it fits
- Single instance or low-complexity deployments with repeated system prompts and documents
- What you take on
- Simple and low latency, but reuse disappears when traffic lands on another worker.
Cache-aware routed worker pool
- Where it fits
- Multiple workers with repeated prefixes and reliable cache events
- What you take on
- Improves locality but must avoid hot-worker overload and stale indexes.
GPU plus host-memory hierarchy
- Where it fits
- Contexts larger than the GPU working set with fast local interconnect
- What you take on
- Adds capacity and reuse, but pinned memory and transfer can become bottlenecks.
Local NVMe or filesystem tier
- Where it fits
- Large reusable documents with moderate latency tolerance
- What you take on
- Lower cost capacity, but metadata scale, I/O tail latency and prefetch accuracy matter.
Remote distributed KV store
- Where it fits
- Cross-instance reuse, elasticity and shared long-context workloads
- What you take on
- Largest reuse domain with the highest network, consistency, security and operations burden.
Disaggregated prefill and decode
- Where it fits
- Large long-prompt workloads needing independently scaled prefill and decode pools
- What you take on
- Improves phase control only when KV transfer and topology are faster than local recomputation.
Where projects usually go wrong
Cache-key under-specification
What you see: Unexpected output differences or corruption after reuse across model or adapter changes
What to do: Bind every execution-relevant input and version to immutable cache identity.
Stale locality metadata
What you see: Routers send requests toward blocks that no longer exist, increasing TTFT and retries
What to do: Use lifecycle events, expiry, reconciliation and miss-aware routing penalties.
Cache-affinity hot spot
What you see: One worker has strong hit rate but severe queue and tail latency
What to do: Combine overlap with load and SLO-aware override or replication.
Remote hit slower than recomputation
What you see: High hit rate with worse TTFT than the no-cache baseline
What to do: Apply per-tier break-even policy and retain local prefill fallback.
Tier thrashing
What you see: Rapid promotion, eviction and repeated writes with low useful reuse
What to do: Use admission thresholds, quotas, minimum residence and reuse-value estimates.
Layout or connector mismatch
What you see: Transfer succeeds but blocks cannot be consumed or produce incorrect results
What to do: Negotiate exact compatibility and verify before making state visible.
Partial or uncertain object
What you see: Requests read state left by interrupted transfer or failed storage write
What to do: Commit atomically, verify digests and invalidate on uncertain completion.
Compression quality regression
What you see: Memory improves while retrieval, code or long-context accuracy falls
What to do: Version codecs, qualify per workload and preserve full-cache fallback.
Cross-tenant timing leak
What you see: One tenant infers another tenant’s cached prefix from response latency
What to do: Use tenant namespaces or salts and prevent unauthorized shared reuse.
Incomplete deletion
What you see: Expired or deleted content remains in a lower tier, replica or index
What to do: Track object lineage and verify deletion across every tier and metadata service.
A checklist you can actually use
- Freeze the exact model, tokenizer, adapter, attention and cache-layout identity.
- Measure repeated-prefix and reusable-token distributions from representative traffic.
- Establish a no-cache and engine-local prefix-cache baseline.
- Define tenant namespaces, salts and authorized sharing groups.
- Set GPU headroom and per-tier capacity quotas.
- Choose explicit write, promotion, prefetch and eviction policies.
- Verify connector and layout compatibility across every worker topology.
- Benchmark remote reuse against recomputation by prefix-size bucket.
- Combine cache locality with queue, decode cost and worker health in routing.
- Measure useful hits, not only metadata hits.
- Qualify compression or blending on task-level output quality.
- Protect metadata, transfer descriptors and persistent cache contents.
- Implement atomic commit, expiry, invalidation and deletion propagation.
- Test stale events, node failure, network degradation and storage outage.
- Keep a controlled recompute or no-remote-cache fallback.
- Promote only when accepted-task latency, quality, isolation and complete cost improve.
Terms worth knowing
- KV cache
- Key and value tensors retained from processed tokens so later decoding does not recompute prior attention state.
- Prefix caching
- Exact reuse of KV state for a token prefix shared by a later request.
- Paged cache
- A block-based memory layout that allocates KV state in reusable pages rather than one contiguous region per sequence.
- Cache identity
- The complete model, token, layout, policy and tenant state that determines whether reuse is valid.
- Useful hit
- An authorized compatible hit that arrives in time and contributes to an accepted output.
- Cache affinity
- Routing preference for a worker or tier already holding reusable state.
- Hierarchical cache
- A storage design that places KV state across multiple latency and capacity tiers.
- Promotion
- Movement of a cache object toward a faster tier.
- Demotion
- Movement of an object toward a slower, larger or cheaper tier.
- Write-through
- A policy that writes state to a lower tier as part of the initial store path.
- Write-back
- A policy that acknowledges a fast-tier write before asynchronously persisting to a lower tier.
- Prefetch
- Loading state before the attention computation explicitly requests it.
- Disaggregated prefill
- A serving topology where prompt processing and token decoding run on separate worker pools.
- KV connector
- A framework interface that locates, saves, loads or transfers cache blocks between engines or tiers.
- Cache salting
- Adding a trust-domain value to cache identity so only authorized requests can share blocks.
- Cache blending
- Reusing non-prefix cached context with selective recomputation to restore attention consistency.
- Cache compression
- Reducing cache bytes through quantization, encoding, pruning or selective retention.
- Invalidation
- Marking previously reusable state unusable after identity, policy, integrity or lifecycle change.
Primary references and technical starting points
These sources support the architecture, runtime, benchmark and security claims. Vendor capabilities can change, so the article records the distinction between established evidence, measured product behavior and editorial interpretation.
- 01 vLLM automatic prefix caching designdocs.vllm.ai
- 02 vLLM KV cache configuration referencedocs.vllm.ai
- 03 vLLM disaggregated prefilling and connector matrixdocs.vllm.ai
- 04 vLLM KV connector v1 APIdocs.vllm.ai
- 05 vLLM bidirectional disaggregated serving exampledocs.vllm.ai
- 06 vLLM and PagedAttention paperarxiv.org
- 07 SGLang and RadixAttention paperarxiv.org
- 08 SGLang hierarchical-cache server argumentsgithub.com
- 09 SGLang prefill–decode disaggregation guidegithub.com
- 10 SGLang cache-aware model gatewaygithub.com
- 11 SGLang encoder–prefill–decode disaggregationgithub.com
- 12 LMCache distributed KV cache projectgithub.com
- 13 LMCache multi-tier architecturedocs.lmcache.ai
- 14 LMCache cache-engine implementationgithub.com
- 15 LMCache enterprise-scale inference layer paperarxiv.org
- 16 CacheGen — KV cache compression and streamingdoi.org
- 17 CacheBlend — cached knowledge fusion for RAGarxiv.org
- 18 Do Large Language Models Need a Content Delivery Network?arxiv.org
- 19 Mooncake KV-cache-centric serving platformgithub.com
- 20 Mooncake FAST 2025 paperusenix.org
- 21 Mooncake Store multi-layer storage designgithub.com
- 22 NVIDIA Dynamo KV Block Manager guidedocs.nvidia.com
- 23 NVIDIA Dynamo KV-cache-aware router guidedocs.nvidia.com
- 24 NVIDIA Dynamo disaggregated serving designdocs.nvidia.com
- 25 NVIDIA Dynamo SGLang KV transfer integrationdocs.nvidia.com
- 26 NVIDIA Dynamo LMCache integrationdocs.nvidia.com
- 27 NVIDIA Dynamo FlexKV integrationdocs.nvidia.com
- 28 NIXL inference transfer librarygithub.com
- 29 H2O — Heavy-Hitter Oracle KV evictionarxiv.org
- 30 SnapKV — prompt-aware KV compressionarxiv.org
- 31 StreamingLLM — attention sinks for long streamingarxiv.org
- 32 KIVI — tuning-free asymmetric KV quantizationarxiv.org
- 33 PyramidKV — dynamic KV-cache compressionarxiv.org
- 34 LeanKV — unified KV compressionarxiv.org
- 35 FibQuant — random-access KV-cache compressionarxiv.org
- 36 The risk of KV cache compressionarxiv.org
- 37 SGLANG-LSM — database storage for KV cachearxiv.org
- 38 DualMap — cache affinity and load balancingarxiv.org
- 39 BanaServe — unified KV cache and dynamic migrationarxiv.org
- 40 CompressKV — semantic-retrieval-guided cache compressionarxiv.org