When the KV Cache Is Slower Than the GPU: Scaling Remote KV Tiers for Context-Parallel Prefill
Remote KV-cache hits slowed GLM-5.3 prefill until sharding and async loads cut p99 from 83s to 0.67s.
A study of remote KV-cache reuse for GLM-5.3, an FP8 mixture-of-experts model with multi-head latent attention, on 8xB300 nodes found LMCache plus Valkey left median time-to-first-token unchanged but raised 16k-token p99 from 3.96s to 17.3s. Remote hits took 0.88s versus 0.31s to recompute, and synchronous loads pushed a hit-heavy stream to p99 83.32s with GPUs 7% busy. Sharding, per-rank servers, asynchronous loading, and three client bug fixes reduced that p99 to 0.67s while serving 98.5% of prompt tokens remotely, lifting prefill throughput 14% and 34% with an upstream kernel fix. Changes were submitted to LMCache.
- Remote LMCache on GLM-5.3 raised 16k-token p99 from 3.96s to 17.3s.
- Hits pay off only above 2.53 GB/s and prompts longer than about 17k tokens.
- Sharding, async loads, and bug fixes cut hit-heavy p99 from 83.32s to 0.67s.
- Sharded store plus a kernel fix raised prefill throughput by 34%.
Full article308 words · extracted from huggingface.co · click to collapse
Reusing the attention KV cache across requests is a standard way to cut prefill cost in long-context LLM serving, and production systems increasingly back the per-engine cache with a remote tier shared by every engine. We study such a tier in a disaggregated deployment of GLM-5.3, an FP8 mixture-of-experts model with multi-head latent attention (MLA), on 8xB300 nodes running prefill context parallelism (PCP8). Enabling the remote tier (LMCache with a Valkey store) left median time-to-first-token unchanged but raised the 16k-token p99 from 3.96 s to 17.3 s. Replaying a production request stream on an isolated engine, we find that a remote hit took 0.88 s against 0.31 s to recompute the prompt, and that synchronous loading turned a hit-heavy stream into an unstable queue: p99 83.32 s with the GPUs 7% busy. A two-term cost model explains both: a hit pays off only if the tier delivers more than B* = sR (2.53 GB/s for this model and GPU), and a fixed per-hit engine cost (T0 ~ 0.33 s) means that hits on prompts shorter than about 17k tokens cannot beat recompute at any bandwidth. Guided by the model, we (i) shard the MLA KV store across PCP ranks, with a proof that the existing minimum-over-ranks lookup returns the longest cached prefix and a load protocol that can never desynchronize collectives; (ii) partition the remote tier by rank, one server instance per rank with no coordination, which raises GET bandwidth 6.3x to 10.76 GB/s; (iii) add asynchronous loading to the sharded store; and (iv) fix three client bugs that caused unbounded stalls. On the hit-heavy stream, with 98.5% of prompt tokens served from the remote tier, p99 falls from 83.32 s to 0.67 s. The sharded store raises prefill throughput by 14%, and by 34% together with an upstream kernel fix. All changes are submitted upstream to LMCache.
Text extracted automatically; images, tables and formatting may be missing. Original: https://huggingface.co/papers/2610.21500