Inference systems

Prompt Caching Visualised

Change a prompt and trace exactly which cached blocks survive. Explore shared prefixes, block size, expiry and cache isolation in an interactive 2D and 3D prefix tree.

There is a narrated film on this topic.Watch Prompt caching: reuse the stable prefix

View
Tokens per block
Cache age 2 min
16 / 24
Tokens reused
8
Uncached prompt tokens
4 / 2
Block hits / misses
0
Expired cached requests

The prefix tree

9 blocks
RootB1B2B3B4B5B6B6B5B6Select a block to inspect its tokens
ReusedComputeStored branchExpired / root

Read the incoming prompt

The shared policy stays first. A different question creates a branch later in the prefix.

67% of prompt tokens reuse cached state. This is a cache-coverage count, not a latency estimate or a guarantee that the runtime skips every forward pass.

Block 5

compute

Question: · Who · approves · the

Cache namespace: northbank

Position 17 to 20. Matching this block alone is insufficient: all earlier tokens must match too.

17 opening tokens match a live cached request. Only 16 fit into complete blocks of 4. Changing a prompt creates a new branch; it does not delete the old cached request.

Illustrative runtime: one displayed word is one educational token. Cache retention is fixed at 10 minutes from the original write, with no refresh on access. Real tokenisers, minimum lengths, eviction rules, model keys and provider cache policies differ. The model computes exact prefix availability; it does not generate or cache answers. A runtime can still recompute the final prompt token or block to obtain logits, even when all displayed KV blocks match. Changing block size rebuilds this synthetic cache layout.

Keep the stable context at the beginning and put the changing question afterwards. In this small experiment, the first sixteen words describe Northbank’s assistant and its policy rules. Changing the question preserves that opening. Changing the very first word breaks reuse from the start.

The model compares exact token sequences and caches complete blocks. Each block is identified by its preceding prefix as well as its own content. Repeated words further down a different branch therefore cannot produce a hit. This illustrates the block-prefix mechanism documented by vLLM.

Try four experiments: change the opening, increase block size, advance the clock beyond ten minutes, and switch the team namespace. The orange blocks expose a different reason for recomputation in each case. Selecting a block reveals its exact words and positions. A block size of five exposes a final partial block that cannot enter the complete-block cache.

This lab uses visible word tokens and an illustrative fixed expiry. It is not a provider pricing or performance calculator. Real serving systems have different tokenisers, memory pressure, retention rules and additional cache-key inputs. A full KV prefix match does not mean zero model work: a runtime may recompute the final prompt token or block to obtain logits. Reusing prompt state also does not mean reusing a previously generated answer.

The maths

Reuse only complete prefix blocks
R=BLB,C=NRR = B \left\lfloor \frac{L}{B} \right\rfloor, \qquad C = N - R

L is the longest exact opening sequence in a live cache entry from the same namespace. B is the block size, N is the incoming token count, R counts tokens in reusable KV blocks and C counts tokens outside those blocks. These counts exclude runtime-specific recomputation to obtain logits.

Sources and model assumptions

Follow the original mechanism behind this explainer. The interactive examples identify their toy data and simplifying assumptions above.

Put it to work

Related terms

More visualisations

Building with language models?

These explainers come out of the work. If you want the same thinking applied to your own system, that is what I do.

See how I can help