What Is KV Cache? Why It Matters for LLM Inference Speed
When a large language model generates a response, it typically produces text one token at a time. Each new token requires another Transformer computation. Without an efficient caching mechanism, the model would repeatedly recompute information for tokens it has already processed, creating substantial redundant work as the context grows.
KV Cache, short for Key-Value Cache, is designed to reduce this repeated computation. It stores the Keys and Values previously calculated by the Attention mechanism so they can be reused when the model generates subsequent tokens.
This makes KV Cache a fundamental part of modern LLM inference. It can significantly improve autoregressive generation efficiency, but the cache itself consumes memory or GPU VRAM. Longer contexts and more concurrent requests generally require larger KV Caches, making KV Cache management an important factor in LLM latency, throughput, and inference infrastructure.
What Is KV Cache?
KV Cache is an inference mechanism that stores previously computed Attention Keys and Values for tokens that have already been processed. Instead of recalculating these representations every time the model generates another token, the model can retrieve them directly from the cache.
In the Transformer Attention mechanism, each token representation is projected into three components:
- Query (Q): represents what the current token is looking for.
- Key (K): represents information used to determine how relevant another token is.
- Value (V): contains the information that contributes to the Attention output.
When an LLM generates a new token, its Query needs to interact with the Keys of previous tokens and use the corresponding Values to construct the Attention output.
The important point is that the Keys and Values for previously processed tokens have already been calculated. They generally do not need to be recomputed simply because another token has been added to the sequence.
KV Cache therefore stores these K and V representations. For each newly generated token, the model calculates the new token’s relevant Q, K, and V representations, adds the new K and V to the cache, and reuses the cached history for subsequent Attention computation.
Why Would LLMs Perform Repeated Computation Without KV Cache?
The value of KV Cache becomes clearer when looking at a simplified autoregressive generation process.
Suppose the Prompt is:
AI models can
The model processes these tokens and predicts:
generate
The context is now:
AI models can generate
To predict the next token, a model without KV Cache would need to process the growing sequence again, including recomputing Key and Value representations for historical tokens that were already processed.
If the next generated token is "text," the sequence becomes:
AI models can generate text
Without caching, the model would again perform unnecessary calculations for earlier tokens. As the output becomes longer, the amount of redundant computation continues to grow.
KV Cache changes this process. When the model initially processes "AI models can," it stores the relevant Keys and Values. After "generate" is produced, only the new K and V need to be calculated and added to the cache. The same process repeats for "text" and every subsequent token.
The key idea is therefore:
KV Cache allows the model to keep using the full available history without repeatedly recomputing the historical Keys and Values.
How Does KV Cache Work?
KV Cache is closely connected to Self-Attention in autoregressive Transformer models.
Suppose a model has already processed four tokens:
T1 → T2 → T3 → T4
The Attention layers have produced Key and Value representations associated with these tokens. KV Cache stores them:
K1, V1K2, V2K3, V3K4, V4
When T5 is processed, the model does not need to regenerate the K/V representations for T1 through T4. It calculates the relevant representations for the new token:
Q5, K5, V5
The new Query can then attend to the cached Keys, together with the new Key, and retrieve information from the corresponding Values.
Afterward:
K5, V5
are added to the KV Cache and become available when the model processes the next token.
The process can be summarized as:
Previous Tokens → Cached K/V
New Token → New Q/K/V → Attention with Cached K/V → Generate Next Token → Add New K/V to Cache
This caching happens across the relevant Attention layers of the Transformer, which is why KV Cache memory usage can become substantial in large models with many layers.
What Is the Difference Between Prefill and Decode?
LLM inference is commonly divided into two important phases: Prefill and Decode. Understanding this distinction makes the role of KV Cache much clearer.
Suppose a user submits a Prompt containing 2,000 tokens.
During the Prefill phase, the model processes those input tokens and builds the KV Cache needed for subsequent generation. Because the Prompt tokens already exist, GPUs can process much of this work in parallel.
Once Prefill is complete, the model begins generating output and enters the Decode phase.
Decode is typically autoregressive. The model generates one token and then uses the expanded context to generate the next. KV Cache becomes particularly important here because the historical K/V representations are already available. The model can reuse them instead of recalculating the entire sequence for every Decode step.
This distinction also helps explain two common LLM performance metrics:
| Metric | Meaning | Common Influences |
|---|---|---|
| TTFT | Time to First Token | Prompt length, Prefill computation, hardware |
| TPOT | Time per Output Token | Decode performance, KV Cache access, hardware |
A long Prompt may increase the time before the first output token appears, while efficient KV Cache management becomes especially important once the model is generating subsequent tokens.
Why Does KV Cache Make LLM Inference Faster?
The main performance benefit of KV Cache comes from avoiding repeated K/V projection computation for historical tokens.
During autoregressive generation, the context grows every time a new token is produced. Without caching, repeatedly processing representations for the entire history would create substantial redundant work.
KV Cache stores previously computed Keys and Values so that each Decode step can focus primarily on the newly added token while reusing historical Attention states.
The benefit becomes increasingly important during long generations. If a model only generates a few tokens, the difference may be relatively small. If it generates hundreds or thousands of tokens, avoiding repeated historical computation can save substantial work.
However, KV Cache does not make Attention independent of context length. The Query for a new token still needs to attend over an increasingly long sequence of cached Keys and access the corresponding Values.
KV Cache therefore reduces redundant computation, but it does not eliminate the computational and memory costs associated with long contexts.
Why Does KV Cache Consume So Much GPU Memory?
The main trade-off of KV Cache is memory usage.
The model needs to store Keys and Values for previously processed tokens, and these states may need to be maintained across many Transformer layers. KV Cache size is therefore influenced by factors such as the number of layers, the number of KV Heads, Head Dimension, numerical precision, sequence length, and the number of concurrent requests.
The most intuitive relationship is:
Longer Context → More Cached Tokens → Larger KV Cache
A request with only a few hundred tokens may require a relatively modest cache. When the context grows to tens of thousands of tokens or more, KV Cache memory requirements can become much more significant.
Concurrency amplifies the issue. An inference server may process many users at the same time, and each active generation request can require its own KV Cache. A large number of simultaneous long-context requests can therefore consume GPU memory rapidly.
For this reason, GPU memory in an LLM inference system is not used only for model weights. Space must also be available for KV Cache, intermediate computation, batching, and other runtime requirements.
A model fitting into GPU memory does not necessarily mean the same hardware can efficiently serve a large number of concurrent users.
Why Does Context Length Affect KV Cache?
Context Window length is directly related to KV Cache because the model needs to maintain K/V states for tokens that remain relevant to the current sequence.
If a model has processed 1,000 tokens, the cache contains states associated with that history. If the context grows to 10,000 tokens, significantly more information must be stored.
This has two major consequences.
First, memory pressure increases. A longer Context Window can require more cache space for each request, potentially reducing the number of requests that can fit on the same GPU.
Second, Attention and memory-access costs increase. When generating a new token, the model needs to work with a longer sequence of cached K/V representations. Even though historical K/V projections do not need to be recomputed, accessing and attending over a longer history still has a cost.
A model supporting a 128K or larger Context Window therefore does not mean that using the maximum context length is computationally free. Maximum context capacity and practical inference efficiency are separate considerations.
How Do MHA, MQA, and GQA Affect KV Cache Size?
Modern Transformer architectures use different Attention designs to reduce the memory cost of KV Cache. Three important approaches are Multi-Head Attention (MHA), Multi-Query Attention (MQA), and Grouped-Query Attention (GQA).
Traditional MHA generally maintains separate Key and Value heads corresponding to multiple Attention heads, which can result in a relatively large KV Cache.
MQA allows multiple Query Heads to share a much smaller set of Key and Value Heads, substantially reducing the amount of K/V information that needs to be cached. GQA takes an intermediate approach, grouping multiple Query Heads so that each group shares K/V Heads.
| Attention Type | K/V Structure | KV Cache Characteristics |
|---|---|---|
| MHA | More separate K/V Heads | Larger cache |
| GQA | Groups of Query Heads share K/V Heads | Reduced cache |
| MQA | Many Query Heads share fewer K/V Heads | Further reduced cache |
This is another reason model parameter count alone cannot fully describe inference efficiency. Two models with similar parameter counts can have substantially different KV Cache requirements if they use different Attention architectures.
How Does KV Cache Affect Batch Size and Throughput?
For AI infrastructure providers, KV Cache is not only about how quickly one user receives an answer. It also affects how many requests an inference server can process efficiently at the same time.
GPU memory is limited. Once model weights occupy part of the available VRAM, the remaining memory must accommodate KV Cache and other runtime data. If each request requires a larger KV Cache, fewer concurrent sequences may fit on the same hardware.
This affects Batch Size. Larger batches can improve GPU utilization and overall throughput, but only if sufficient memory is available to hold the KV Cache associated with those requests.
LLM serving systems therefore need to balance several factors:
Context Length, Concurrent Requests, Batch Size, Latency, Throughput, and GPU Memory
Modern inference systems use specialized KV Cache management techniques to improve this balance. These can include reducing memory fragmentation, dynamically allocating cache blocks, reusing shared prefixes, or storing K/V representations at lower precision.
KV Cache optimization is therefore not only a model-level issue. It is also a central part of large-scale LLM serving infrastructure.
Is KV Cache the Same as Prompt Caching?
No. Both involve caching, but they generally refer to different layers of the inference process.
KV Cache stores Key and Value representations from Attention so they can be reused as an autoregressive model continues generating a sequence.
Prompt Caching generally refers to reusing computation associated with repeated Prompts or shared prefixes across requests. For example, if many requests begin with the same long System Prompt, an inference platform may be able to reuse previously computed prefix states rather than repeating the entire Prefill computation.
| Comparison | KV Cache | Prompt Caching |
|---|---|---|
| What is cached | Attention Keys and Values | Computation associated with repeated Prompts or prefixes |
| Main purpose | Accelerate Decode | Reduce repeated Prefill work |
| Typical use | Autoregressive generation | Requests sharing common prefixes |
| Main impact | Generation efficiency and memory | TTFT, compute usage, and serving cost |
Prompt Caching implementations may reuse underlying KV states, but the concepts describe different optimization goals from an application and infrastructure perspective.
How Is KV Cache Related to LLM Inference Optimization?
KV Cache is one of the foundational techniques used in LLM inference, but modern serving systems combine it with many other optimizations.
These can include Continuous Batching, Paged Attention, KV Cache Quantization, Prefix Caching, and Speculative Decoding.
Each technique addresses a different bottleneck. Paged Attention focuses on improving how KV Cache memory is allocated and managed. KV Cache Quantization reduces the numerical precision used for cached states to lower memory requirements. Prefix Caching can reuse computation for common input prefixes, while Speculative Decoding attempts to reduce some of the sequential cost of token generation.
Modern LLM inference optimization is therefore not only about making matrix multiplication faster. It is also about managing memory efficiently, scheduling requests effectively, and serving more tokens and users with limited accelerator resources.
KV Cache sits at the intersection of these problems, making it one of the most important concepts for understanding modern AI inference infrastructure.
Summary
KV Cache, or Key-Value Cache, is an important optimization used during Transformer-based LLM inference. It stores the Keys and Values already calculated for previous tokens, allowing the Decoder to reuse historical Attention states instead of repeatedly recomputing their K/V projections as each new token is generated.
This makes KV Cache particularly important for efficient autoregressive generation. However, caching is not free. Longer contexts, more Transformer layers, more KV Heads, and higher concurrency can all increase memory requirements.
KV Cache therefore connects two major LLM inference challenges: speed and memory. It reduces redundant computation and improves Decode efficiency, but it can also become one of the major consumers of GPU memory in long-context and high-concurrency serving environments.
Understanding KV Cache also makes related technologies such as GQA, MQA, Paged Attention, Prefix Caching, and KV Cache Quantization easier to understand. These techniques address different parts of the same broader problem: enabling large language models to generate tokens efficiently within limited compute and memory resources.
FAQ
Does KV Cache change the answers generated by an LLM?
Normally, no. KV Cache is primarily an inference optimization that reuses previously computed Attention Keys and Values without changing the model’s trained parameters.
Can an LLM generate text without KV Cache?
Yes, but autoregressive generation would generally require substantially more repeated computation, particularly as the context and generated output become longer.
Does KV Cache keep growing during generation?
Generally, yes. As additional tokens enter the active context, their K/V states are added to the cache until the request ends, the context limit is reached, or the inference system applies another cache-management strategy.
Why is KV Cache particularly important for long-context LLMs?
Longer contexts require the model to maintain K/V states for more tokens and access a larger cache during generation, increasing both memory usage and memory-access pressure.
Is KV Cache also required during LLM training?
Its main benefit is during autoregressive inference. Training typically processes sequences with substantially more parallelism, so it does not rely on inference-style KV caching in the same way.


