vLLM PagedAttention is the memory management algorithm that partitions the KV cache into fixed-size blocks stored in non-contiguous GPU memory, reducing memory waste to under 4% compared to the 60-80% squandered by conventional serving systems on fragmentation and over-reservation. The result is up to 24x higher throughput than HuggingFace Transformers on the same GPU, with no changes to model architecture.
Why KV Cache Dominates GPU Memory
During autoregressive decoding, every input token generates attention key and value tensors that persist in GPU memory to produce subsequent tokens. This KV cache is the single largest consumer of VRAM at inference time. For LLaMA-13B, a single sequence’s KV cache can consume 1.7 GB, and that footprint grows linearly with context length. The problem compounds because sequence lengths are unpredictable: one request may need 128 tokens, another 8,000, and static allocation strategies must size for the worst case or risk out-of-memory errors mid-generation.
Existing serving frameworks like HuggingFace Transformers typically pre-allocate contiguous memory blocks sized to the maximum sequence length for every request. This leaves large gaps when actual sequences fall short, and the contiguous requirement prevents the system from backfilling those gaps with other requests. The vLLM team’s measurements found that these inefficiencies waste between 60% and 80% of KV cache memory in traditional systems, memory that could otherwise hold more concurrent sequences and increase batch sizes.
How PagedAttention Works
PagedAttention borrows directly from operating system virtual memory and paging. Instead of requiring a contiguous block for each sequence’s KV cache, it partitions the cache into fixed-size blocks, each holding key and value tensors for a set number of tokens. A block table maps logical positions within each sequence to physical GPU memory locations, exactly as an OS page table translates virtual to physical addresses.
Blocks are allocated on demand as new tokens are generated and freed when a sequence completes. Because blocks need not be adjacent, fragmentation disappears except for partial utilization of each sequence’s final block. The block-table design also enables zero-copy memory sharing across sequences: when parallel sampling or beam search produces multiple outputs from a shared prompt, those sequences reference the same physical blocks, and a copy-on-write mechanism handles divergences.
| Memory Strategy | Allocation Model | Waste | Sharing |
|---|---|---|---|
| HuggingFace Transformers | Contiguous, max-length pre-reserved | 60-80% | No |
| vLLM with PagedAttention | Non-contiguous, demand-allocated blocks | Under 4% | Copy-on-write |
Throughput Gains in Practice
The memory savings translate directly into throughput. Benchmarking LLaMA-7B on an NVIDIA A10G and LLaMA-13B on an NVIDIA A100 (40 GB), sampling input and output lengths from the ShareGPT dataset, vLLM delivered up to 24x higher throughput than HuggingFace Transformers and 2.2x to 3.5x higher than HuggingFace TGI.
The peer-reviewed SOSP 2023 paper that formalizes PagedAttention reports a 2-4x throughput improvement over prior state-of-the-art systems including FasterTransformer and Orca, measured at equivalent latency levels. The improvement scales with longer sequences, larger models, and more complex decoding algorithms.
Real-world deployment data corroborates the benchmarks. LMSYS used vLLM as the backend for Chatbot Arena, serving Vicuna, Koala, and LLaMA models to millions of users. The switch to vLLM halved the organization’s GPU count while handling an average of 30,000 daily requests and peaks of 60,000. Gains are most pronounced with longer sequences, larger models, and complex decoding algorithms like parallel sampling and beam search, where PagedAttention’s memory sharing cuts cache usage by up to 55%.
Deploying vLLM in Production
vLLM ships with an OpenAI-compatible API server, making it a drop-in replacement for teams already calling the OpenAI API. The standard deployment path involves packaging the model in a Docker container, exposing the server behind a load balancer, and scaling horizontally with Kubernetes. For teams running inference across multiple regions, pairing vLLM with the patterns described in our multi-region disaster recovery guide ensures that GPU capacity fails over cleanly without losing in-flight requests.
The following checklist covers the key production configuration decisions:
- Choose
--gpu-memory-utilization(default 0.90) to control how much VRAM vLLM reserves for the KV cache pool; raise it on dedicated inference nodes and lower it when co-locating with training workloads. - Enable automatic prefix caching (
--enable-prefix-caching) to reuse KV blocks across requests that share system prompts or few-shot examples, reducing redundant prefill computation. - Set
--max-model-lenbased on actual workload distribution rather than the model’s theoretical maximum; lower values free blocks for more concurrent sequences. - Select tensor parallel size (
--tensor-parallel-size) to match GPU topology; multi-GPU parallelism is essential for models exceeding single-GPU VRAM. - Integrate deployment via GitOps using the tools surveyed in our open-source GitOps tools roundup to automate container rollouts and detect configuration drift.
Sources
- vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention — vLLM Project Blog, June 2023
- Efficient Memory Management for Large Language Model Serving with PagedAttention — Kwon et al., SOSP 2023
- vllm-project/vllm — GitHub Repository