← All AgentX optimizations

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.

Diagram of several vLLM instances above a shared LMCache layer with CPU DRAM, local NVMe through GDS, and a remote store tier, where a later request on another instance reads what an earlier one wrote.
LMCache sits under every instance as a hash-addressed KV layer across CPU DRAM, local NVMe, and a remote store, so a later request on a different instance can read what an earlier one wrote.View full-resolution image

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.

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.

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