Trendy LLMs depend on quantization, pruning, distillation, and sooner consideration kernels, however manufacturing efficiency usually relies upon most on KV cache administration. As context home windows develop, the cache consumes vital GPU reminiscence, limiting concurrency, throughput, and latency. Two breakthroughs remodeled this problem: PagedAttention improves reminiscence allocation, whereas RadixAttention permits environment friendly prefix reuse.<\/p>\n
Collectively, these methods make LLM serving sooner and extra memory-efficient. On this article, we look at how PagedAttention and RadixAttention work, why they matter, and the way they permit high-performance LLM serving.<\/p>\n
Why the KV Cache Is the Actual Bottleneck<\/h2>\n
Each transformer generates textual content one token at a time. For every new token, the mannequin should attend to all beforehand generated tokens through the use of their key (Ok) and worth (V) vectors. Recomputing these vectors at each step would make technology prohibitively costly, so serving engines retailer them in reminiscence because the KV cache. This cache eliminates redundant computation and makes autoregressive decoding sensible, nevertheless it introduces a brand new problem: reminiscence consumption grows linearly with sequence size. For long-context fashions, the KV cache usually turns into the most important dynamic client of GPU reminiscence, figuring out what number of requests can run concurrently.<\/p>\n
Why reminiscence turns into the limiting issue<\/h3>\n
The scale of the KV cache will depend on the mannequin structure and the variety of tokens saved. The per-token reminiscence requirement is:<\/p>\n
\n
<\/figure>\n<\/div>\n
The place:<\/p>\n
\n
\n\n
\n
Image<\/strong><\/th>\n
That means<\/strong><\/th>\n<\/tr>\n<\/thead>\n\n
\n
L<\/td>\n
Variety of transformer layers<\/td>\n<\/tr>\n
\n
Hkv<\/td>\n
Variety of KV heads<\/td>\n<\/tr>\n
\n
D<\/td>\n
Head dimension<\/td>\n<\/tr>\n
\n
B<\/td>\n
Bytes per worth (2 for FP16)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
For a Llama-3 8B class mannequin with 32 layers, 8 KV heads, 128-dimensional heads, and FP16 precision, every token occupies roughly 128 KiB of KV cache. A 100,000-token context due to this fact requires practically 12.8 GiB of reminiscence earlier than contemplating batching or extra requests.<\/p>\n
The 2 elementary issues<\/h3>\n
As GPU reminiscence fills with KV tensors, serving programs encounter two distinct bottlenecks:<\/p>\n
\n
Reminiscence fragmentation: <\/strong>This happens when the system allocates KV reminiscence inefficiently, leaving giant parts of GPU reminiscence unusable and decreasing the variety of concurrent requests.<\/li>\n
Redundant computation: <\/strong>Equivalent immediate prefixes are repeatedly prefetched and encoded, though their KV states have already been computed.<\/li>\n<\/ul>\n
These issues are unbiased, and every impressed a unique resolution. PagedAttention addresses environment friendly reminiscence allocation, whereas RadixAttention focuses on reusing beforehand computed KV cache throughout requests. Collectively, they outline the muse of recent LLM serving.<\/p>\n
PagedAttention: Fixing the Reminiscence Allocation Downside<\/h2>\n
By 2023, the trade recognized the most important inefficiency in LLM serving because the storage technique of the KV cache relatively than consideration itself. The system allotted one giant contiguous block of GPU reminiscence to carry the whole KV cache for each request. For the reason that serving engine couldn’t predict how lengthy a response could be, it sometimes reserved area near the mannequin\u2019s most context size. Most of that reminiscence remained unused all through the request, drastically decreasing the variety of sequences that may very well be served concurrently.<\/p>\n
The issue with contiguous allocation<\/h3>\n
Conventional allocation creates two types of fragmentation:<\/p>\n
\n
Inside fragmentation:<\/strong> A request reserves hundreds of token slots however generates solely a small response, leaving many of the allotted reminiscence idle.<\/li>\n
Exterior fragmentation: <\/strong>As requests of various lengths end, scattered gaps seem throughout GPU reminiscence. Though the overall free reminiscence could also be ample, it’s now not out there as one contiguous block for brand new requests.<\/li>\n<\/ul>\n
The result’s poor GPU utilization and decrease throughput, even when loads of reminiscence technically stays out there.<\/p>\n
How PagedAttention Works<\/h2>\n
The core concept behind PagedAttention is easy: allocate KV reminiscence solely when it’s wanted. As a substitute, the system divides the KV cache into fixed-size blocks (sometimes 16 or 32 tokens) relatively than reserving one giant contiguous buffer for a whole sequence. As technology progresses, new blocks are allotted solely after the earlier one turns into full, permitting reminiscence to develop incrementally relatively than being over-provisioned from the beginning.<\/p>\n
Step 1: Divide the KV cache into blocks<\/h3>\n
The system splits every sequence into equal-sized logical blocks, whereas the system can retailer the precise blocks wherever in GPU reminiscence.<\/p>\n
\n
<\/figure>\n<\/div>\n
Step 2: Use a block desk for handle translation<\/strong><\/h3>\n
Each request maintains a block desk that maps logical block IDs to their bodily areas in GPU reminiscence. Throughout consideration, the kernel consults this desk to collect the required keys and values, making the sequence seem steady though its knowledge is bodily scattered.<\/p>\n
Actually, this indirection attracts inspiration from web page tables in working programs: the mannequin operates on a logical sequence, whereas the serving engine manages bodily placement.<\/p>\n
Step 3: Develop reminiscence on demand<\/strong><\/h3>\n
As a substitute of allocating area for hundreds of future tokens, PagedAttention expands the KV cache one block at a time.<\/p>\n
A request producing 60 tokens occupies solely the blocks required for these 60 tokens. No reminiscence is reserved for tokens which will by no means be produced, which dramatically reduces inner fragmentation.<\/p>\n
Step 4: Share blocks with copy-on-write<\/strong><\/h3>\n
One of the crucial highly effective options of PagedAttention is block sharing. If a number of requests start with the identical immediate, they reference the identical bodily KV blocks as a substitute of storing duplicate tensors.<\/p>\n
When two requests finally diverge, the system copies the shared block solely on the level of modification, a mechanism often known as copy-on-write. This makes prefix sharing extremely memory-efficient for beam search, parallel sampling, and concurrent requests with an identical system prompts.<\/p>\n
Why this modified LLM serving<\/strong><\/h3>\n
PagedAttention doesn’t change the eye algorithm or the mannequin\u2019s outputs. Its innovation is solely architectural: it replaces inefficient contiguous allocation with a paged reminiscence format.<\/em> The result’s dramatically decrease reminiscence waste, increased GPU utilization, and the power to serve many extra concurrent requests on the identical {hardware}.<\/p>\n
RadixAttention: Fixing the Prefix Reuse Downside<\/h2>\n
PagedAttention made GPU reminiscence environment friendly, nevertheless it left one other main inefficiency untouched: the system nonetheless recomputed an identical prefixes for each new request. In actual manufacturing workloads, requests are hardly ever unbiased. 1000’s of customers share the identical system immediate, chat conversations repeatedly embrace their whole historical past, and agent workflows repeatedly append to an present context. Consequently, the system spends a lot of the costly prefill part producing KV tensors that exist already.<\/p>\n
The authors launched RadixAttention to eradicate this redundant computation by turning the KV cache right into a searchable, reusable index relatively than a brief reminiscence buffer.<\/p>\n
The important thing concept: Retailer prefixes in a radix tree<\/h3>\n
As a substitute of discarding KV tensors when a request finishes, RadixAttention retains them inside a radix tree a compressed trie the place every edge represents a sequence of tokens. The system shops each distinctive immediate prefix as soon as, whereas completely different requests department solely the place their tokens start to vary.<\/p>\n
\n
<\/figure>\n<\/div>\n
For instance, three requests could start with the identical system immediate:<\/p>\n
System:<\/strong> You're a useful assistant.Consumer:<\/strong> What's AI?System: <\/strong>You're a useful assistant.Consumer:<\/strong> What's Machine Studying?System: <\/strong>You're a useful assistant.Consumer:<\/strong> What's Deep Studying?<\/pre>\n
Relatively than storing three an identical copies of the shared prefix, the radix tree retains it as soon as and creates separate branches just for the ultimate consumer question.<\/p>\n
How prefix matching works<\/h3>\n
When a brand new request arrives, RadixAttention performs three operations:<\/p>\n
\n
Match:<\/strong> Discover the longest token prefix already current within the radix tree.<\/li>\n
Reuse:<\/strong> Load the present KV tensors for that matched prefix as a substitute of recomputing them.<\/li>\n
Insert:<\/strong> Compute solely the unequalled suffix and append it again into the tree for future requests.<\/li>\n<\/ol>\n
\n
<\/figure>\n<\/div>\n
The longer the shared prefix, the much less work the mannequin performs throughout prefill. This instantly reduces Time to First Token (TTFT), particularly for lengthy conversations and agentic purposes.<\/p>\n
Why it issues<\/h3>\n
In contrast to PagedAttention, which improves reminiscence utilization, RadixAttention improves computational effectivity. It transforms repeated prompts into cache hits, permitting serving engines to skip hundreds of an identical transformer computations. The profit is largest in workloads with secure system prompts, multi-turn chat, RAG pipelines, coding assistants, and agent loops the place contexts evolve incrementally as a substitute of being rewritten from scratch.<\/p>\n
How RadixAttention Works<\/h2>\n
In contrast to PagedAttention, which organizes reminiscence, RadixAttention organizes information. Its purpose solutions one query effectively: How a lot of this immediate has the system already computed? To do this, it maintains a world radix tree that indexes token sequences and their corresponding KV cache entries. Each new request both reuses an present prefix or provides solely the lacking suffix.<\/p>\n
Step 1: Discover the longest matching prefix<\/h3>\n
When a request arrives, the serving engine traverses the radix tree token by token to search out the longest prefix that already exists. As a substitute of evaluating whole prompts, it merely follows the matching path by the tree.<\/p>\n
\n
<\/figure>\n<\/div>\n
If 1,900 tokens of a 2,000-token immediate exist already, the mannequin instantly reuses these KV tensors and computes solely the remaining 100 tokens.<\/p>\n
Step 2: Compute solely the unequalled suffix<\/strong><\/h3>\n
Subsequent, as soon as the system identifies the shared prefix, prefill begins precisely the place the match ends. The system hundreds the reusable KV states from cache, whereas solely the brand new tokens move by the transformer.<\/p>\n
\n
<\/figure>\n<\/div>\n
Because of this RadixAttention primarily improves Time to First Token (TTFT) relatively than reminiscence effectivity it eliminates redundant transformer computation.<\/p>\n
Step 3: Insert the brand new path into the tree<\/strong><\/h3>\n
Lastly, after prefill (and later throughout technology), the system inserts the newly computed KV tensors again into the radix tree. Future requests can now reuse this longer prefix, permitting the cache to develop organically as actual site visitors arrives.<\/p>\n
\n
<\/figure>\n<\/div>\n
Relatively than treating accomplished requests as disposable, RadixAttention turns them into reusable cache entries for subsequent requests.<\/p>\n
As a result of GPU reminiscence is finite, the system can not retain each cached prefix eternally. RadixAttention makes use of leaf-based eviction, the place the system removes the least not too long ago used branches first whereas it protects shared inside prefixes.<\/p>\n
\n
<\/figure>\n<\/div>\n
This technique preserves the prefixes that profit the most important variety of requests and maximizes cache hit charge over time.<\/p>\n
Why this modified LLM serving<\/strong><\/h3>\n
RadixAttention transforms the KV cache from a brief reminiscence construction right into a persistent prefix cache. As a substitute of accelerating consideration itself, it reduces the quantity of consideration the mannequin must compute. For workloads resembling chatbots, coding assistants, RAG programs, and autonomous brokers the place immediate prefixes repeat continuously the result’s considerably decrease prefill latency and far increased total throughput.<\/p>\n
PagedAttention vs. RadixAttention: What\u2019s the Distinction?<\/h2>\n
In distinction, builders usually describe PagedAttention and RadixAttention as competing algorithms, however they remedy fully completely different issues. PagedAttention focuses on how the system shops the KV cache in GPU reminiscence, whereas RadixAttention focuses on how the system reuses beforehand computed KV states throughout requests. One is a reminiscence allocation technique; the opposite is a caching technique. In fashionable LLM serving, they’re complementary and are ceaselessly used collectively.<\/p>\n
Consider them as two completely different layers<\/strong>RadixAttention : Prefix cache & reuse<\/h3>\n
A helpful means to consider the serving stack is as two layers. PagedAttention sits on the reminiscence layer, deciding the place KV blocks dwell inside GPU reminiscence. RadixAttention sits above it, deciding whether or not these KV blocks exist already and could be reused. The radix tree merely factors to KV blocks which can be managed by the paged allocator.<\/p>\n
A sensible instance<\/strong><\/h3>\n
Think about three customers begin their conversations with the identical system immediate.<\/p>\n
\n
<\/figure>\n<\/div>\n
With out RadixAttention, the serving engine computes the shared prefix three separate instances. With out PagedAttention, every request additionally reserves an outsized contiguous reminiscence area, losing GPU reminiscence. When each methods are mixed, the shared prefix is computed as soon as, saved effectively in paged KV blocks, and reused by each matching request.<\/p>\n
The important thing takeaway<\/strong><\/h3>\n
PagedAttention improves reminiscence effectivity. RadixAttention improves computational effectivity. Collectively, they handle the 2 greatest bottlenecks in LLM inference: storing the KV cache effectively and avoiding pointless recomputation. Trendy serving frameworks resembling vLLM and SGLang more and more mix these concepts to maximise each throughput and latency.<\/p>\n
How vLLM Implements Prefix Caching<\/strong><\/h3>\n
A standard false impression is that RadixAttention is the one option to obtain prefix caching. In actuality, vLLM additionally helps automated prefix reuse, nevertheless it makes use of a unique knowledge construction. As a substitute of sustaining a radix tree, vLLM identifies KV blocks utilizing chain hashing, permitting an identical prefixes to be reused with out storing them in a tree.<\/p>\n
The core concept: Each KV block will get a novel hash<\/strong><\/h3>\n
As a immediate is processed, every accomplished KV block receives a hash generated from three items of knowledge:<\/p>\n
\n
the hash of its dad or mum block<\/li>\n
the block\u2019s personal token IDs<\/li>\n
optionally available metadata resembling a LoRA ID or multimodal enter hash<\/li>\n<\/ul>\n
As a result of every block will depend on its dad or mum, the hash uniquely represents the whole prefix resulting in that block. If one other request produces the identical sequence of tokens, it generates precisely the identical chain of hashes and instantly finds the cached KV blocks.<\/p>\n
\n
<\/figure>\n<\/div>\n
How cache lookup works<\/strong><\/h3>\n
When a brand new request arrives, vLLM computes block hashes so as and checks whether or not each already exists within the world cache.<\/p>\n
\n
Hash match: Reuse the present KV block.<\/li>\n
First miss: Allocate new blocks for the remaining suffix.<\/li>\n
Technology: Newly accomplished blocks are added again into the cache for future requests.<\/li>\n<\/ul>\n
This produces the identical sensible conduct as RadixAttention: repeated prefixes skip costly prefill computation and cut back Time to First Token.<\/p>\n
Radix tree vs. Chain hashing<\/strong><\/h3>\n
Though each programs obtain automated prefix caching, their underlying designs are completely different.<\/p>\n
For many purposes, the distinction is basically architectural relatively than practical. Each engines mechanically reuse an identical immediate prefixes, making repeated requests considerably extra environment friendly with out altering mannequin outputs.<\/p>\n
Safety Issues: Can Prefix Caching Leak Knowledge?<\/strong><\/h3>\n
Prefix caching is designed to enhance efficiency, nevertheless it additionally introduces an essential safety problem. In a multi-tenant LLM service, cached KV blocks could also be shared throughout requests from completely different customers. If an an identical prefix is served noticeably sooner as a result of it already exists within the cache, an attacker might probably infer whether or not that immediate was processed not too long ago. This is called a prefix cache aspect channel.<\/p>\n
How the aspect channel works<\/strong><\/h3>\n
Think about two customers interacting with the identical LLM service.<\/p>\n
If Consumer B repeatedly sends rigorously chosen prompts and observes unusually low Time to First Token (TTFT), they could infer that Consumer A beforehand submitted the identical prefix. The mannequin\u2019s output isn’t uncovered, however the cache itself turns into a supply of knowledge leakage.<\/p>\n
Trendy serving frameworks remedy this by introducing cache salting. As a substitute of hashing solely the immediate tokens, the serving engine additionally features a tenant-specific salt when producing cache identifiers.<\/p>\n
With cache salting:<\/p>\n
\n
Requests from the identical tenant reuse cached prefixes usually.<\/li>\n
Requests from completely different tenants generate completely different cache keys, even an identical prompts.<\/li>\n
Cross-tenant cache hits are eradicated, stopping timing-based info leakage.<\/li>\n<\/ul>\n
Why it issues<\/strong><\/h3>\n
For single-user or self-hosted deployments, prefix caching is primarily a efficiency optimization. In shared cloud infrastructure, nonetheless, it’s also a safety function that should be configured accurately. Separating cache entries by tenant preserves the latency advantages of prefix caching whereas guaranteeing that one buyer\u2019s requests can not reveal details about one other\u2019s.<\/p>\n
What Got here Subsequent: Past Paged and Radix Consideration<\/strong><\/h3>\n
PagedAttention and RadixAttention solved the 2 elementary issues of KV cache administration environment friendly storage and prefix reuse. Nonetheless, as context home windows expanded to lots of of hundreds of tokens and LLMs started powering long-running brokers, a brand new problem emerged: the KV cache grew to become too giant to suit fully in GPU reminiscence. Trendy serving programs due to this fact developed from managing a single cache into managing a hierarchy of caches throughout GPUs, CPUs, and distributed storage.<\/p>\n
1. Hierarchical KV Caching<\/strong><\/h3>\n
As a substitute of treating GPU reminiscence as the one cache, fashionable engines set up KV knowledge into a number of storage tiers. Often accessed prefixes stay in high-bandwidth GPU reminiscence, whereas older or much less energetic prefixes are moved to host RAM or distant storage and fetched again solely when wanted.<\/p>\n
\n
<\/figure>\n<\/div>\n
This hierarchy behaves very like a processor cache:<\/p>\n
\n
\n\n
\n
Tier<\/strong><\/th>\n
Storage<\/strong><\/th>\n
Function<\/strong><\/th>\n<\/tr>\n<\/thead>\n\n
\n
L1<\/td>\n
GPU HBM<\/td>\n
Lively KV blocks for ongoing requests<\/td>\n<\/tr>\n
The serving engine mechanically migrates KV pages between tiers, permitting a lot bigger efficient context home windows with out requiring monumental GPU reminiscence.<\/p>\n
2. Cache-Conscious Routing<\/strong><\/h3>\n
Prefix caching is effective provided that associated requests attain the identical serving duplicate. In a distributed deployment, a standard round-robin load balancer could ship consecutive turns of the identical dialog to completely different GPUs, leading to cache misses regardless of an identical prefixes.<\/p>\n
\n<\/figure>\n<\/div>\n
Cache-aware routing solves this by directing incoming requests towards the duplicate that already accommodates the required KV cache. Relatively than balancing solely by load, the router additionally considers cache locality, decreasing prefill latency and enhancing total throughput.<\/p>\n
3. Digital Reminiscence-Primarily based KV Administration<\/strong><\/h3>\n
One other course of analysis questioned PagedAttention itself. As a substitute of implementing paging contained in the serving framework, newer approaches use CUDA Digital Reminiscence Administration (VMM) to let the GPU present virtual-to-physical handle translation instantly.<\/p>\n
\n<\/figure>\n<\/div>\n
The concept is easy: preserve a contiguous digital KV cache whereas permitting bodily pages to stay scattered beneath<\/em>. This preserves compatibility with present consideration kernels and reduces the engineering overhead of sustaining specialised paged kernels.<\/p>\n
Conclusion<\/h2>\n
PagedAttention and RadixAttention remedy two completely different however equally essential challenges in fashionable LLM serving. PagedAttention maximizes GPU reminiscence effectivity by changing contiguous KV allocation with a paged reminiscence format, whereas RadixAttention reduces latency by reusing beforehand computed immediate prefixes as a substitute of recomputing them. <\/p>\n
Collectively, they enhance throughput, enhance concurrency, and decrease the price of long-context inference with out altering mannequin outputs. As LLM purposes proceed to scale, environment friendly KV cache administration has grow to be as essential as mannequin structure itself. For builders, well-structured prompts and secure prefixes are actually real efficiency optimizations.<\/p>\n
![\"Formula](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/08\/image-1-7eqxqe.webp\")
<\/figure>\n<\/div>\n![\"Logical](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/08\/image-2-7eqxqe.webp\")
<\/figure>\n<\/div>\n![\"Radix](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/08\/image-4-7eqxqe.webp\")
<\/figure>\n<\/div>\n![\"Comparison](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/08\/image-5-7eqxqe.webp\")
<\/figure>\n<\/div>\n![\"Process](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/08\/image-6-7eqxqe.webp\")
<\/figure>\n<\/div>\n![\"KV](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/08\/image-7-7eqxqe.webp\")
<\/figure>\n<\/div>\n![\"Radix](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/08\/image-8-7eqxqe.webp\")
<\/figure>\n<\/div>\n![\"Least](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/08\/image-9-7eqxqe.webp\")
<\/figure>\n<\/div>\n![\"Prefix](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/08\/image-10-7eqxqe.webp\")
<\/figure>\n<\/div>\n![\"KV](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/08\/image-11-7eqxqe.webp\")
<\/figure>\n<\/div>\n![\"Hierarchical](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/08\/image-12-7eqxqe.webp\")
<\/figure>\n<\/div>\n![\"Distributed](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/08\/image-13-7eqxqe.webp\")
<\/figure>\n<\/div>\n![\"Virtual](\"https:\/\/cdn.analyticsvidhya.com\/wp-content\/uploads\/2026\/08\/image-14-7eqxqe.webp\")
<\/figure>\n<\/div>\n![\"Janvi](\"https:\/\/av-eks-lekhak.s3.amazonaws.com\/media\/lekhak-profile-images\/converted_image_ToTu2tx.webp\")