PagedAttention Is Gone — What vLLM's Model Runner V2 Replaced It With

You upgraded to vLLM v0.25.0, or you read the release note, and one line stops you: "PagedAttention has been removed." For most people writing about inference, that reads like a category error. PagedAttention was not a feature of vLLM, it was the thing vLLM was, the paging trick that launched the project and the first bullet in every serving explainer since 2023. So the deletion (PR #47361, merged July 2, 2026, with a one-line rationale from the author, "It is time," approved by Woosuk Kwon, who wrote the original PagedAttention) lands as if someone deleted the foundation and left the house standing. What replaced it is Model Runner V2, and understanding what Model Runner V2 actually is, versus what the headline implies, is the difference between updating your mental model and repeating a stale one.

The short version: the named 2023 kernel is deleted, but block-based paged KV memory management is not. Those are two different things the phrase "PagedAttention" has quietly conflated for three years. This piece separates them, explains what Model Runner V2 is architecturally, and asks the only question that matters for a deployment: does any of it move your numbers. It assumes you know why the KV cache dominates serving cost; the KV-cache engineering piece is the substrate this one builds on. That earlier piece called PagedAttention "the substrate modern serving is built on, and the right mental model." Half of that is now out of date: the mental model survives, the named implementation does not.

What PagedAttention actually was

The reason the deletion sounds impossible is that "PagedAttention" names three separable things, and popular usage never bothered to distinguish them.

The first is a kernel: the specific 2023 attention implementation, the monolithic CUDA code path that read a block table and computed attention over non-contiguous KV blocks. The second is an abstraction: exposing the KV cache to the attention operation through a level of indirection, a mapping from logical token positions to physical blocks. The third is a memory model: managing the KV cache as fixed-size blocks that can live anywhere in GPU memory, allocated on demand, so a request does not reserve one contiguous chunk sized for its worst case.

The paper that started it (Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention," SOSP 2023, arXiv 2309.06180) borrowed operating-system virtual memory: pages for the KV cache. It is the memory model that mattered. Fragmentation waste dropped from the majority of KV memory to a few percent, and reclaimed memory became batch capacity.

The honest baseline hiding in "24x"

The number everyone repeats is the wrong one to attribute. You have seen "up to 24x throughput" attached to PagedAttention, including in this blog's own KV-cache engineering piece, which used it loosely. The "up to 24x" figure comes from the June 2023 vLLM launch blog, comparing against naive HuggingFace Transformers serving, a deliberately weak baseline. The peer-reviewed SOSP paper claims something more modest and more honest: 2 to 4x throughput over prior serving systems (FasterTransformer, Orca) at matched latency. Both are real; they measure different things. The 24x tells you how far behind unoptimized serving was; the 2-to-4x tells you what paging bought over people already trying. When you cite PagedAttention's impact, cite the 2-to-4x. It is the number that survives contact with a competent baseline.

What v0.25.0 deleted, and what it did not

Now the deletion, precisely. The release note wording is worth reading verbatim: "PagedAttention has been removed (#47361). The legacy attention implementation is deleted now that V1/MRv2 backends are the standard path." Read that carefully. What was deleted is the legacy attention implementation, the 2023 kernel from the list above. It became deletable specifically because the newer attention backends (the FlashAttention-family and FlashInfer paged kernels that Model Runner V2 runs) had already become the default path. Nobody was routing through the old code, so the old code went.

What did not get deleted is the memory model. Block-based paged KV allocation continues to run under Model Runner V2. Retiring the 2023 kernel did not remove the idea of managing the cache as non-contiguous blocks with a mapping table; that concept is now handled by the modern paged attention backends rather than the original monolithic path. So the accurate framing is a three-level split: the named abstraction is deleted, the kernel is replaced, the paged memory model is retained.

One honest caveat, because the release material does not spell it out: the claim that KV allocation is now owned specifically by FlashInfer and FlashAttention-3 paged kernels is a reasonable synthesis of the release wording, not a single verbatim primary statement. The defensible claim is the one the release makes directly, that the modern backends are the standard KV path and paged block management persists through them. The exact kernel ownership is consistent with that but not independently confirmed.

The practical consequence for the "PagedAttention == vLLM" shorthand: it is stale at the implementation level and correct at the concept level. Say "vLLM pages the KV cache into blocks" and you are still right; say "vLLM runs the 2023 PagedAttention kernel" and you are describing code that no longer exists. There is also no opt-out: the legacy implementation is deleted, not deprecated behind a flag, so there is no old path to fall back to.

What Model Runner V2 is

Model Runner V2 is described by the vLLM team as a ground-up re-implementation of the vLLM model runner: a cleaner, more modular, more efficient execution core, shipped with no public API changes. It became the default for dense models via PR #44443. The name invites a specific misunderstanding, so clear it up first.

Model Runner V2 is not the V0-to-V1 engine rewrite that vLLM went through in 2025. It is a further rewrite of the model runner that lives inside the V1 engine era, built to pay down technical debt that accumulated after V1 shipped. The V1 runner had grown into a single file exceeding 6,700 lines. Model Runner V2 is the next-generation runner within V1, not the first big rewrite. If you present it as vLLM's first architectural overhaul, you skip the predecessor that makes it legible.

Three stated design principles

The team frames the rebuild around three principles, quoted directly:

1. "Be modular. Isolate model-specific logic from the common execution path."
2. "Be GPU-native. Move bookkeeping off the CPU and onto the GPU."
3. "Be async-first. Treat overlapped CPU/GPU execution as a design constraint, not a retrofit."

Each maps to a concrete change. On modularity, a new ModelState abstraction encapsulates the model-specific logic (multimodal embeddings, attention metadata, CUDA-graph capture) that used to be tangled into the runner; the largest Model Runner V2 file is now under 1,300 lines against the old runner's 6,700-plus. On GPU-native, input tensors (input_ids, positions, query_start_loc, seq_lens) are built directly on the GPU via Triton kernels instead of assembled on the CPU and copied over, and a Triton-native sampler does Gumbel-Max sampling without materializing an explicit softmax. On async-first, the runner targets zero synchronization between CPU and GPU across supported configurations, with outputs copied in a separate CUDA stream decoupled from the main compute stream. The persistent-batch design was also reworked so request state lives in a stable table with gather operations, rather than coupling request order to the block-table layout.

CUDA-graph-native dynamic speculative decoding

The piece most likely to matter operationally is speculative decoding under full CUDA graphs. v0.25.0 adds dynamic speculative decoding compatible with full CUDA graphs (PR #45953). Spec decode's variable acceptance previously made it awkward to capture in a full graph; now the GPU-side preparation kernels directly consume the rejection-sampling results, removing a CPU-to-GPU synchronization point in the loop. If you run speculative decoding, this is the async-first principle showing up where you can feel it. One caveat: the release is explicit only about full CUDA-graph compatibility for dynamic spec decode. The general full-graph-versus-piecewise strategy across all cases is not spelled out, so do not generalize the claim beyond spec decode.

Scope: dense models, and an honest gap

The scope is deliberately worded. The official announcement says Model Runner V2 "is now the default for all dense models." Dense is doing real work in that sentence; the scope is not universal. The natural next question, what still runs the older path, does not have a clean answer in primary sources. The March 2026 design blog listed the then-unsupported cases (linear attention models, non-Eagle spec decoding, EPLB, DBO, logits processors, LoRA), and by v0.25.0 several gaps had closed: Mamba-hybrid prefix caching landed (PR #42406), and dynamic spec decode plus the DSpark and DFlash drafters landed. But a precise v0.25.0 list of what remains on the legacy runner is not something I could confirm. What is solid: dense is the default, Mamba-hybrids now have Model Runner V2 prefix caching, and linear-attention models were the last-listed holdout. If you run a mixture-of-experts model, a hybrid, or anything non-dense, verify feature parity for your specific architecture rather than assume it. That verification is the whole point of the checklist below.

Does it move your numbers?

This is where a release note becomes a deployment decision, and where the reality gap lives. vLLM published two headline benchmarks, and both need reading with their baselines attached.

The throughput number is Qwen3-0.6B on a single GB200: roughly 25,000 output tokens per second under Model Runner V2 against roughly 16,000 under Model Runner V1, a 56% improvement. Before you extrapolate, notice the model. Qwen3-0.6B is a 0.6-billion-parameter micro-model, chosen precisely because it is tiny. Runner overhead (CPU-side bookkeeping, input preparation, sampling) is a fixed cost per step, so on a model whose forward pass is cheap, that overhead is a large fraction of the total, and cutting it shows up as a big percentage. The same runner improvement on a 70-billion-parameter dense model, where the matrix multiplies dominate and the runner is a rounding error, moves throughput far less. The +56% is a real measurement of exactly the thing Model Runner V2 improved, presented on the workload that maximizes it: the best case, not the expected case. What it does not tell you is what the rewrite buys on a model large enough that you actually care about serving it efficiently, and that is the number you have to generate yourself.

The second benchmark is speculative decoding: GLM-4.7-FP8 with speculative decoding (MTP=1) on 4x GB200, reporting 6.3% lower time-per-output-token. That is a more representative workload (a real serving-scale model with spec decode on), and the gain is correspondingly smaller and more believable. Note GLM-4.7-FP8 here is vLLM's cited benchmark artifact, an older-generation model used as a fixed reference point, not a model recommendation.

Beyond the two headlines, v0.25.0 ships incremental kernel wins on the GLM-5.2 and DeepSeek serving paths (a fused indexer-rope-quant kernel at +1.9 to 3.3% end-to-end, a reduce-scatter MoE all-reduce at +3.1 to 3.2%, sequence parallelism at +1.9 to 5.0%). These are single-digit-percent improvements, not the runner headline, worth naming because a release with one big number and a pile of small ones invites you to remember only the big one. The honest read: a runner rewrite whose payoff scales inversely with your model size, plus incremental kernel gains on specific model paths. Whether it moves your numbers depends on which of those workloads your deployment resembles, and the only way to know is to re-benchmark at your model, precision, and concurrency. The inference optimization stack is where a runner change slots in among quantization, batching, and cache management, and the runner is rarely the dominant term for a large model.

DSpark and DFlash, mainlined

v0.25.0 also mainlines the DeepSeek DSpark drafter (PR #46995, merged July 1, 2026, by Benjamin Chislett of NVIDIA, plus speculators-checkpoint support in #47093) and the DFlash drafter path. This blog already took DSpark apart when DeepSeek released it, so the mechanism (semi-autoregressive drafting plus confidence-scheduled verification) lives in the DSpark analysis, with a dedicated reproduction piece planned rather than attempted here. The discipline to carry forward: the paper's headline (arXiv 2607.05147, submitted July 6, 2026) is a 60 to 85 percent per-user generation speedup at matched throughput versus an MTP-1 baseline, measured by DeepSeek inside the DeepSeek-V4 serving system under their own traffic. It is vendor-measured, not independently reproduced. What v0.25.0 adds that is checkable is the in-tree metric on the pull request: at batch size 1 with 7 draft tokens, roughly a 14-millisecond end-to-end step on 8x B300 and over 350 tokens per second, with accepted lengths of 1.22 to 1.40x over the MTP baselines. Treat the production multiple as a hypothesis about DeepSeek's regime until someone reproduces it; the speculative decoding tutorial covers why acceptance length, not a vendor headline, is the number to watch in your own logs.

Competitive context: SGLang v0.5.15

vLLM is not moving alone. SGLang v0.5.15 (released July 10, 2026) chases the same July 2026 frontier from a different entry point: a FlashKDA prefill backend for safe-gate KDA linear attention, a ReplaySSM buffered decode path for linear-attention models (KDA and GDN), and a Spec V2 reporting +11% end-to-end tokens per second, plus indexer-prologue fusion around 8% faster decode at batch size 1. At serving scale, SGLang reports GLM-5.2 in NVFP4 reaching 500-plus tokens per second per user on 8x B300 and around 450 on 4x GB300 at batch size 1. Both stacks are converging on the same problems: linear-attention kernels, NVFP4 on Blackwell, and load-aware next-generation speculative decoding. The operator takeaway is that the runner and kernel churn on both sides is real and fast, which is why a benchmark from three months ago, on either engine, is a stale input to a serving decision today.

After you upgrade: a checklist

The upgrade is not a config change you can accept on faith, because the runner that generates your numbers was replaced. Work through this before you trust the release note on your workload.

1. Re-benchmark at your own model, precision, and concurrency. The +56% headline is a 0.6B model on one GB200, chosen to maximize runner overhead. Measure output tokens per second and time-per-output-token on your model at the batch sizes you actually run.
2. Verify feature parity for your model family. If you serve a mixture-of-experts model, a hybrid, a linear-attention model, or anything using LoRA, EPLB, DBO, or custom logits processors, confirm your configuration is supported. Primary sources do not give a clean v0.25.0 parity list, so check your own stack.
3. Do not plan for an opt-out. The legacy PagedAttention path is deleted, not flagged off. A regression means fixing forward or pinning the previous vLLM release, not toggling a compatibility switch.
4. Delete direct references to the removed internals. Code that imports or subclasses the old PagedAttention class breaks; normal users of the standard serving interface are unaffected. Audit before you deploy.
5. If you run speculative decoding, re-test under full CUDA graphs. The dynamic-spec-decode-plus-full-CUDA-graph path (PR #45953) is new. Confirm your drafter and target capture cleanly and that acceptance length matches what you saw before.
6. Treat every vendor speedup as a hypothesis. The DSpark 60-to-85% is measured in DeepSeek's system against DeepSeek's baseline; the +56% is a best-case micro-model figure. Neither is portable until you measure it locally.
7. Check the removed model architectures. v0.25.0 dropped several older architectures (Baichuan, Aquila, Grok, Tarsier variants) and an old FP8 online MoE quantization class. If you serve one, the upgrade is a hard stop.

Key Takeaways

1. The deleted thing is the 2023 kernel, not the memory model. vLLM v0.25.0 removed the legacy PagedAttention implementation (PR #47361, merged July 2, 2026). Block-based paged KV management continues under Model Runner V2's modern attention backends. The "PagedAttention == vLLM" shorthand is now stale at the implementation level and still correct at the concept level.
2. Attribute PagedAttention's impact as 2 to 4x, not 24x. The SOSP 2023 paper claims 2 to 4x over prior serving systems at matched latency. The "up to 24x" figure is from the 2023 launch blog versus naive HuggingFace serving. Cite the number that survives a competent baseline.
3. Model Runner V2 is the V1 runner rebuilt, not the V1 rewrite. A ground-up re-implementation of the model runner (default for dense models via PR #44443) on three principles: modular, GPU-native, async-first. Its largest file dropped from over 6,700 lines to under 1,300.
4. The +56% throughput headline is a best case, not an expected case. It is Qwen3-0.6B on one GB200, a micro-model that maximizes the fixed runner overhead the rewrite cuts. On a large dense model where matrix multiplies dominate, the runner gain is far smaller. The more representative benchmark, GLM-4.7-FP8 spec decode on 4x GB200, shows 6.3% lower time-per-output-token.
5. Dynamic speculative decoding is now full-CUDA-graph compatible. PR #45953 lets GPU-side prep kernels consume rejection-sampling results directly, removing a CPU-to-GPU sync in the loop. The full-graph claim is confirmed for spec decode specifically, not generalized.
6. Scope is dense models, and the parity gaps are not cleanly documented. Mamba-hybrids gained Model Runner V2 prefix caching (PR #42406); linear-attention models were the last-listed holdout. No confirmed v0.25.0 enumeration of what still runs the legacy runner exists, so verify parity for non-dense architectures yourself.
7. DSpark and DFlash are mainlined, but the headline is still vendor-measured. DSpark landed via PR #46995. The 60 to 85 percent per-user speedup (arXiv 2607.05147) was measured by DeepSeek on DeepSeek-V4 against an MTP-1 baseline and is not independently reproduced. The checkable in-tree metric is roughly 14 ms per step at batch 1 with 7 draft tokens on 8x B300.
8. There is no opt-out, so re-benchmark before you trust the upgrade. The legacy path is deleted, not flagged off. Measure your model at your concurrency, verify feature parity for your architecture, and treat both the vLLM and DeepSeek numbers as hypotheses about their regimes, not portable scalars for yours.