Skip to main content
KV cache sharing reduces duplicate KV storage across GPUs in a prefill worker. It keeps one persistent copy of each cache page within the shard group, allowing the same GPU memory budget to retain more unique tokens. Prefill context parallelism (CP) distributes prompt computation, but can still leave the cached history replicated across ranks. KV cache sharing distributes those stored pages as well. This is useful for long-context and multi-turn workloads that reuse large prefixes.

How it works

Shared logical tree, distributed pages

Every rank keeps the same logical radix tree and request-to-token mapping. A prefix match therefore identifies the same cached tokens on all ranks, while each GPU stores only the pages it owns. For example, a CP4 group can distribute eight logical pages as follows: A request that reuses A–D matches the same logical prefix on every rank. New pages continue the cached path’s ownership sequence, and prefixes remain reusable at the original page size.

Gather one layer at a time

Before attention reads a cached prefix, each rank contributes its owned pages to an all-gather. Attention reads the assembled prefix from a temporary layer buffer, using a page-table mapping to preserve the logical token order. Two buffers alternate across layers so the next gather can overlap with current-layer computation. Their memory is included in the cache budget. A prefix hit saves recomputation, but still incurs the cost of gathering the distributed KV.

HiCache and MTP integration

HiCache preserves page ownership during GPU-to-host backup and host-to-GPU reload. Each rank backs up and restores its own pages. For each layer, execution follows this order:
Read order
With GLM MTP, the target and draft KV/indexer state follow the same ownership plan and are restored together. During P/D transfer, each prefill rank sends the pages it owns; decode receives complete, unsharded cache entries.

Usage example

Enable KV cache sharing with --enable-kv-cache-sharding on the prefill worker only. The following example uses Linux with NVIDIA CUDA on two GB300 nodes, with four GPUs per worker. Prefill uses TP4/CP4 and CPU HiCache; decode uses TP4/EP4 with attention DP4. Both workers use the same GLM-5.3 NVFP4 checkpoint and model revision.

Environment variables

Create kv-shard.env on both nodes. Replace the example IP addresses and RDMA NIC names with values for your environment. This example uses Mooncake RDMA for P/D transfer.
Environment variables

Prefill worker: TP4/CP4

Run this command on the prefill node. It enables interleave CP, page-based KV sharding, CPU HiCache, and EAGLE MTP.
Prefill worker

Decode worker: TP4/EP4

Run this command on the decode node. The target uses attention DP4 and FlashInfer A2A with EP4; the EAGLE draft uses the TP-only path. Decode does not enable KV cache sharding.
Decode worker

Router

After both workers are healthy, start the router on a host that can reach them. The worker HTTP endpoints, prefill bootstrap port, and RDMA transport must be reachable between nodes.
Router

Send a request

From the router host, send a request using the shared served model name:
Request