Figure: a matrix of six systems against the five control-plane stages SELECT, PLACE, MOVE, ATTEND and OBSERVE. vLLM is the substrate: it allocates at PLACE and executes at ATTEND, and is what the other systems run on. PNM-KV optimises SELECT: it selects which KV or token pages are needed before paying the movement cost, using a processing-near-memory accelerator, and reports up to 21.9 times throughput improvement in its own benchmarks, arXiv 2511.00321, their reported result and not independently verified here. CacheWise optimises SELECT and PLACE: it predicts future KV reuse from agent and tool-call behaviour, combining prefix-aware scheduling with reuse-aware eviction, and reports 2 to 2.6 times fewer KV-cache evictions and up to 3.5 times faster agent session completion in a vLLM implementation over its own collected coding-agent traces. LMCache optimises PLACE and MOVE: KV persistence, reuse and movement across tiers and engines, including pinning, lookup, cleanup, movement, compression, batched movement, compute and I/O pipelining, cross-engine cache transfer, and prefill/decode disaggregation. TraCT optimises MOVE: rack-scale KV sharing and transfer over CXL, implemented on NVIDIA Dynamo with direct GPU to CXL operations behind a rack-wide prefix-aware cache. Tutti optimises MOVE: efficient GPU to NVMe KV object movement, removing the CPU from the critical path and using GPU io_uring with slack-aware I/O scheduling, and against GDS-enabled SSD-backed LMCache reports 78.3 per cent TTFT reduction under strict SLO constraints, 2 times higher achievable request rate, 27 per cent lower serving cost, and near-DRAM performance at much greater capacity, arXiv 2605.03375. This package contributes one cell, at PLACE: residency persistence, plus 34.15 points to LFU at 32 gibibytes, simulated and provisional. No system in the survey optimises OBSERVE. Every figure quoted is external literature, that system's own reported result, cited and not reproduced here. This is a map of how the pieces could compose, not a claim that any system is inferior or that a gap exists.
Figure 10.1 · External literature
The 2026 landscape, placed by the decision each system optimises
Not a ranking, and not a gap analysis. Five specialised 2026 systems mapped onto the five stages of the control plane, to show how the pieces could compose.
Placed by the decision each one optimises
What each system optimises, and what it reports
- PNM-KV · SELECTExternal literature
Select which KV/token pages are needed before paying the movement cost, using a processing-near-memory accelerator sitting in or near CXL memory.
Reported: Reports up to 21.9× throughput improvement in its own benchmarks.
arXiv:2511.00321 — their reported result, not independently verified here.
- CacheWise · SELECT + PLACEExternal literature
Predict future KV reuse from agent and tool-call behaviour: prefix-aware scheduling plus reuse-aware eviction guided by lightweight predictions from tool-call metadata, rather than a generic recency or frequency policy.
Reported: Reports 2–2.6× fewer KV-cache evictions and up to 3.5× faster agent session completion.
A vLLM implementation over its own collected coding-agent traces — their reported result.
- LMCache · PLACE + MOVEExternal literature
KV persistence, reuse and movement across tiers and engines: pinning, lookup, cleanup, movement, compression, batched movement, compute/I·O pipelining, cross-engine cache transfer, and prefill/decode disaggregation.
Reported: No headline figure is quoted for LMCache in this package’s survey.
Describing it as a simple offload cache understates it.
- TraCT · MOVEExternal literature
Rack-scale KV sharing and transfer over CXL. Implemented on NVIDIA Dynamo, performing direct GPU↔CXL operations behind a rack-wide, prefix-aware cache.
Reported: No headline figure is quoted for TraCT in this package’s survey.
It is already a CXL-native KV-cache system, not a gap waiting to be filled.
- Tutti · MOVEExternal literature
Efficient GPU↔NVMe KV object movement. Removes the CPU from the KV data/I·O critical path — the CPU only loads I·O kernels to the GPU once per layer — and uses GPU io_uring plus slack-aware I·O scheduling for asynchronous, GPU-direct object transfer.
Reported: Against GDS-enabled SSD-backed LMCache, reports 78.3% TTFT reduction under strict SLO constraints, 2× higher achievable request rate, 27% lower serving cost, and near-DRAM performance at much greater capacity.
arXiv:2605.03375 — their reported result.
- vLLM · substrateExternal literature
GPU KV allocation and paging — the baseline serving-framework capability every offload layer sits on top of.
Reported: — no figure; it is the substrate the rows above run on, not a competitor to them.
The pieces are specialised, not unified.CacheWise’s tool-call-driven reuse prediction lives inside vLLM’s eviction path and does not decide where a block should physically reside. PNM-KV’s near-memory selection avoids wasted recalls, but selection and cross-tier movement policy remain separate concerns. LMCache spans tiers and engines but does not predict future reuse from agent signals. TraCT solves rack-wide CXL transport but is not a relevance-prediction system. Tutti’s contribution is squarely at the GPU↔NVMe movement layer.
Nobody has built the joint control plane — including this package.Whether a higher-level control plane should sit above these pieces, jointly deciding what is relevant, what will be reused, where it should live and when it should move, is a design question. This package’s only contribution to the map is one cell: residency persistence inside PLACE, +34.15 pts to LFU at 32 GiB, simulated and provisional — a single defect in Revision 1 of that simulator inverted four of five findings.
External literature — chapters/ch10-market.html §10.2. Each figure is that system’s own reported result, cited and not reproduced.