Skip to main content
An agent can resend the same instructions and tool definitions on every turn. Enable vLLM prefix caching to reuse attention state for the identical beginning of those prompts, then check cache-hit counters and time to first token. This saves repeated prefill computation when the prefix remains cached; generating each new answer still requires decode work.
Reviewed September 6, 2026 against vLLM 0.28.0. The example is a local verification workflow, not a Tensorfuse GPU benchmark or a guaranteed latency improvement.

Which part of the request gets reused?

The model processes input tokens during prefill, then generates output during decode. The key-value cache stores attention state. Cross-request prefix caching reuses compatible cached blocks when another request begins with the same token sequence. Similar wording is insufficient: reuse depends on matching tokens and the engine’s cache identity, including relevant model and adapter settings. See vLLM’s prefix-cache design for block hashing and isolation details.

1. Put stable content before changing content

For an agent that uses a fixed set of tools, a useful prompt layout is:
A timestamp or random identifier at the beginning prevents later tokens from sharing the same prefix. Move changing metadata later when application semantics allow it. Keep the chat template and tool serialization consistent, preserve instruction priority, and evaluate answer quality after rearranging prompts. For RAG, repeated questions about the same document can benefit from a shared document prefix. Retrieval that selects different passages on every request may have little reuse. These use cases and the prefill/decode distinction are covered in vLLM’s feature guide.

2. Enable prefix caching on one server

Use a Linux NVIDIA GPU host with Docker, NVIDIA Container Toolkit, Python 3, and a CUDA 12.9-compatible driver. This example uses the small Qwen2.5-1.5B-Instruct model on an Ampere or newer supported NVIDIA GPU. Start on an otherwise idle GPU and keep port 8000 free.
Wait for application startup to complete, then press Ctrl-C to stop following logs. Confirm enable_prefix_caching=True in the engine configuration. The v0.28.0 server reference documents the flag and its disabling counterpart, --no-enable-prefix-caching. The server reads VLLM_API_KEY from its environment. Keep the published port on loopback. API-key authentication covers selected inference paths, not every vLLM route; put remote access behind a gateway that authenticates all exposed routes.

3. Send a cold prefix, then reuse it

Save this snippet as prefix_check.py, then run python3 prefix_check.py in the shell where you set INFERENCE_API_KEY. It uses only the standard library and prints client-observed time to the first nonempty streamed content chunk. It consumes the full response before the next request.
The first request must populate this salt’s cache. The following requests share the document and change only the question. Complete blocks of that shared prefix can be reused, so a hit rate below 100% is expected. The first request may also include runtime warm-up effects; three requests demonstrate the mechanism and are insufficient for a performance conclusion.

4. Check cache counters and compare latency

Capture metrics before and after the requests, allowing the server’s periodic metric update to complete:
vLLM’s production metrics define prefix hits and queries as token counters. Their Prometheus samples use the standard _total counter suffix. Calculate the interval hit ratio from the increase in hits divided by the increase in queries for the same model and engine. A zero query increase means there was no sample to interpret. For a Prometheus dashboard with this single model:
Repeat with the flag --no-enable-prefix-caching after stopping and relaunching the container. At realistic load, compare repeated and unique prefixes, then repeat during replica startup. Keep prompt/output lengths and arrival rate comparable. Record p50/p95 time to first token, queue time, completed requests, and quality using the benchmarking guide. The streaming snippet measures client delivery; the server’s vllm:time_to_first_token_seconds histogram measures its own timing boundary.

Why are there no hits, or no latency improvement?

Check whether requests reach the same replica, use the same salt, and retain identical token prefixes. Changing templates, tools, adapters, or early metadata can break reuse. Very short shared prefixes may not fill cache blocks, and competing requests can evict cached blocks. A new replica begins without another replica’s in-memory cache. Persistent model files on a Tensorfuse volume do not automatically create a shared KV cache. Distributed cache transfer and routing need their own implementation. Set tenant-specific cache salts through trusted application logic when isolating reuse between tenants. If hit counters rise but total latency barely changes, inspect queue time and output length: decode can dominate. Continue with speculative decoding or the inference cost reduction workflow based on the measured bottleneck. Stop the example with docker stop qwen-prefix.