AgentX industry impact · KV-cache layer
LMCache
LMCache is an open-source KV-cache layer that sits under inference engines such as vLLM, storing reusable KV chunks keyed by prefix hash across CPU DRAM, local NVMe, and remote backends including Mooncake, Redis, and S3. It can be used as an alternative to vLLM’s native offloading connectors.
- requests completed before the old path deadlocked
- 120 vs 28
- less storage per token for hybrid groups
- ~20×
- KV-transfer kernel tests passing on MI350X
- 56/56
Chunked external-cache loading
LMCache’s multiprocess path was changed for the volume and shape of agentic cache movement, beginning with a failure that is not a slowdown but a stop. When each of many requests with contexts above 100,000 tokens reserves the blocks for its whole load before starting, the pool is exhausted by requests that are all waiting and none progressing.
Chunked external-cache loading reserves per chunk instead, so loads interleave and drain. At concurrency 32 the validation completed 120 requests where the old path deadlocked after 28, and concurrency 48 kept running with the KV pool 98.5% full.

Upstream pull requests
Moving less, and getting out of the way
The other changes reduce how much is moved and how often the runtime gets in the way. Storing only the useful portions of DeepSeek-V4’s hybrid groups cut storage per token by almost twenty times, and sliding-window prefetch now loads only the live window rather than window state that will never be read — the same reachability argument vLLM applied to offload, approached from the storage side.
One native transfer call per object group then removes repeated Python lock handoffs across staging copies and kernel launches, which is overhead proportional to the number of pieces rather than to the bytes in them.
Upstream pull requests
Open: hybrid lock accounting
Two current LMCache changes are especially specific to AgentX but remain open. The hybrid lock-accounting fix stops one request from releasing another request’s read locks on shared sliding-window or recurrent-state chunks. Reproducing it requires three things at once: several requests must share the same chunks, the accounting must be per-chunk rather than per-holder, and eviction must actually start.
Sustained Kimi-K3 runs with DRAM offload supplied all three and produced tens of thousands of warnings, corrupt generations, and eventually GPU crashes once eviction began. Anything short of a long, shared, memory-pressured run leaves the bug dormant.
Upstream pull requests
AMD Instinct enablement
A parallel line of work made all of the above reachable on AMD Instinct hardware. CacheBlend’s non-prefix reuse depended on FlashInfer, which is CUDA-only, so a Triton block-sparse attention backend reimplements the three kernels it needs: block-sparse attention with CSR indices and log-sum-exp output, causal prefill, and log-sum-exp output blending. It then routes to them automatically when ROCm is detected or FlashInfer is missing. ROCm Dockerfiles mirror the CUDA build and lightweight images. An AMD hipFile backend extends the GDS L1 slab-file tier, which reached storage only through NVIDIA cuFile, by binding ROCm’s hipFile through ctypes and dispatching on torch.version.hip; the cuFile path is unchanged.
Distribution was the remaining gap. CUDA users installed a prebuilt wheel while AMD users built from source. We worked with AMD to publish a prebuilt gfx942 and gfx950 wheel that closes it: it installs into the upstream image and passes all 56 KV-transfer kernel tests on MI350X, and it publishes to a GitHub release rather than PyPI so a plain pip install lmcache stays the CUDA build. A one-line follow-up marks the bind-mounted repository as a git safe directory, which only fails in CI because the container runs as root over a runner-owned checkout and the version introspection in setup.py refuses to read it.
Upstream pull requests
DCP-aware CPU offload
DCP-aware CPU offload resolves a straightforward incompatibility between two features that long contexts make mandatory together. With decode context parallelism enabled, each rank holds only a stride of the KV, so what any one rank could save is not a usable prefix. The fix gathers the strided shards before saving and redistributes them after loading. Without it, enabling context parallelism silently disables CPU cache hits for exactly the long prefixes that motivated both features. Its validation recorded more than 30,000 CPU hit events, with single-request loads reaching hundreds of thousands of tokens.
Upstream pull requests
Other projects
Inference engine
vLLM
Hybrid-attention prefix retention, CPU KV offload for hybrid models, and a narrowed store and load path.
Read the optimizations →Inference engine
SGLang
Sliding-window allocation, HiCache hybrid offload, runtime-scalar context length, and cache-aware DP routing.
Read the optimizations →Inference engine
TensorRT-LLM
Boundary-aware incremental tokenization, disaggregated KV descriptor coalescing, and scheduler-lifetime fixes.
Read the optimizations →Inference engine
AMD ATOM
Sparse checkpoint retention, recurrent-state checkpoints, CPU offload ownership, and long-prefill parallelism.
Read the optimizations →Kernels
ROCm AITER
Context-parallel process groups, 64-bit addressing for large cache pools, and persistent MLA decode kernels.
Read the optimizations →Router and orchestration
NVIDIA Dynamo
Batched KV matching, request-lease ownership, cheaper router state, and a leaner request plane.
Read the optimizations →Transfer engine
Mooncake
GPU-direct RDMA on ROCm through HIP dmabuf, plus a published ROCm wheel and release path.
Read the optimizations →