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.

Evidence confidence97%
Hype riskHigh
Adoption stageRapid across vLLM, SGLang, LMCache, Mooncake, NVIDIA Dynamo and disaggregated serving stacks
The 60-second answer

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 now

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 it changes

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.
Engineering Lens

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.

01

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.

02

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.

03

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.

04

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.

05

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.

06

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.

07

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.

Architecture Constraints Benchmarks Security Deployment
The full system

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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

Back-of-the-envelope planning

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.
The conceptual shift

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.
Correctness boundary

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.
Reuse semantics

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.

Storage architecture

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.
Scheduling trade-off

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.
Phase separation

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.

Data movement

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.
Capacity controls

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.
Trust boundary

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.

Reliability

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.
Evidence model

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.
Practical rollout

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.

Test it properly

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.

MetricHow to measure itWhy 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.
Product choices

Four sensible deployment patterns

01

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.
02

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.
03

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.
04

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.
05

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.
06

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.
Lessons from the edge cases

Where projects usually go wrong

01

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.

02

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.

03

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.

04

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.

05

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.

06

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.

07

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.

08

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.

09

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.

10

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.

Before release

A checklist you can actually use

  1. Freeze the exact model, tokenizer, adapter, attention and cache-layout identity.
  2. Measure repeated-prefix and reusable-token distributions from representative traffic.
  3. Establish a no-cache and engine-local prefix-cache baseline.
  4. Define tenant namespaces, salts and authorized sharing groups.
  5. Set GPU headroom and per-tier capacity quotas.
  6. Choose explicit write, promotion, prefetch and eviction policies.
  7. Verify connector and layout compatibility across every worker topology.
  8. Benchmark remote reuse against recomputation by prefix-size bucket.
  9. Combine cache locality with queue, decode cost and worker health in routing.
  10. Measure useful hits, not only metadata hits.
  11. Qualify compression or blending on task-level output quality.
  12. Protect metadata, transfer descriptors and persistent cache contents.
  13. Implement atomic commit, expiry, invalidation and deletion propagation.
  14. Test stale events, node failure, network degradation and storage outage.
  15. Keep a controlled recompute or no-remote-cache fallback.
  16. Promote only when accepted-task latency, quality, isolation and complete cost improve.
Plain-language definitions

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.
About the author

H. Omer Aktas

H. Omer Aktas is the independent editor and publisher of WTFIsTrending.com. He applies more than 30 years of operational, surveillance, analytics and systems experience from regulated casino environments to questions of evidence, controls, implementation risk and deployment reality.

Source trail · 40 references

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.

  1. 01 vLLM automatic prefix caching designdocs.vllm.ai
  2. 02 vLLM KV cache configuration referencedocs.vllm.ai
  3. 03 vLLM disaggregated prefilling and connector matrixdocs.vllm.ai
  4. 04 vLLM KV connector v1 APIdocs.vllm.ai
  5. 05 vLLM bidirectional disaggregated serving exampledocs.vllm.ai
  6. 06 vLLM and PagedAttention paperarxiv.org
  7. 07 SGLang and RadixAttention paperarxiv.org
  8. 08 SGLang hierarchical-cache server argumentsgithub.com
  9. 09 SGLang prefill–decode disaggregation guidegithub.com
  10. 10 SGLang cache-aware model gatewaygithub.com
  11. 11 SGLang encoder–prefill–decode disaggregationgithub.com
  12. 12 LMCache distributed KV cache projectgithub.com
  13. 13 LMCache multi-tier architecturedocs.lmcache.ai
  14. 14 LMCache cache-engine implementationgithub.com
  15. 15 LMCache enterprise-scale inference layer paperarxiv.org
  16. 16 CacheGen — KV cache compression and streamingdoi.org
  17. 17 CacheBlend — cached knowledge fusion for RAGarxiv.org
  18. 18 Do Large Language Models Need a Content Delivery Network?arxiv.org
  19. 19 Mooncake KV-cache-centric serving platformgithub.com
  20. 20 Mooncake FAST 2025 paperusenix.org
  21. 21 Mooncake Store multi-layer storage designgithub.com
  22. 22 NVIDIA Dynamo KV Block Manager guidedocs.nvidia.com
  23. 23 NVIDIA Dynamo KV-cache-aware router guidedocs.nvidia.com
  24. 24 NVIDIA Dynamo disaggregated serving designdocs.nvidia.com
  25. 25 NVIDIA Dynamo SGLang KV transfer integrationdocs.nvidia.com
  26. 26 NVIDIA Dynamo LMCache integrationdocs.nvidia.com
  27. 27 NVIDIA Dynamo FlexKV integrationdocs.nvidia.com
  28. 28 NIXL inference transfer librarygithub.com
  29. 29 H2O — Heavy-Hitter Oracle KV evictionarxiv.org
  30. 30 SnapKV — prompt-aware KV compressionarxiv.org
  31. 31 StreamingLLM — attention sinks for long streamingarxiv.org
  32. 32 KIVI — tuning-free asymmetric KV quantizationarxiv.org
  33. 33 PyramidKV — dynamic KV-cache compressionarxiv.org
  34. 34 LeanKV — unified KV compressionarxiv.org
  35. 35 FibQuant — random-access KV-cache compressionarxiv.org
  36. 36 The risk of KV cache compressionarxiv.org
  37. 37 SGLANG-LSM — database storage for KV cachearxiv.org
  38. 38 DualMap — cache affinity and load balancingarxiv.org
  39. 39 BanaServe — unified KV cache and dynamic migrationarxiv.org
  40. 40 CompressKV — semantic-retrieval-guided cache compressionarxiv.org