Skip to content
mlmentorship

PagedAttention and the vLLM serving model

Resolve logical KV positions through block tables, calculate shared allocation and tail waste, and preserve ownership during release or branching.

Published · 7 min read ·Role-specific ·Advanced

Visual quick review

Trace two logical KV caches through their block tables to scattered physical blocks, and identify why a shared prefix occupies one physical copy with two references.

Learning objective

Two sequence block tables share prefix blocks in a non-contiguous physical pool

Two sequence block tables share prefix blocks in a non-contiguous physical pool Request A maps logical blocks zero, one, and two to physical blocks seven, one, and five. Request B maps the same logical prefix blocks zero and one to physical blocks seven and one, then maps its private logical block two to physical block three. Physical blocks seven and one each have reference count two. The remaining private blocks have reference count one, and unused physical blocks are free. 1 · EACH REQUEST KEEPS LOGICAL TOKEN ORDER request A logical 0 → physical 7 logical 1 → physical 1 logical 2 → physical 5 request B logical 0 → physical 7 logical 1 → physical 1 logical 2 → physical 3 same prefix mappings 2 · THE TABLE RESOLVES EACH LOOKUP IN HBM Match each physical ID to the pool below. physical KV blocks · scattered P0 free P1 prefix refs = 2 P2 free P3 B private refs = 1 P4 free P5 A private refs = 1 P6 free P7 prefix refs = 2
logical order stays fixed while physical addresses jump. Both tables reference P7 and P1; each shared block has two owners. P5 and P3 are private tails. The original schematic follows Kwon et al..
Check: Why can request A read logical blocks in order even though their physical locations are 7, 1 and 5?
Full explanation 7 min read
Reading depth

Summary

PagedAttention resolves logical KV positions through per-sequence tables pointing to fixed-size physical blocks. This permits scattered allocation and compatible-prefix sharing without changing the intended logical attention sequence. It reduces allocation waste relative to some contiguous reservation policies, but does not eliminate tail waste or guarantee higher throughput.

The mechanism

For token position and block capacity , lookup is:

Allocate blocks as sequences grow; the kernel gathers K/V in logical order with the same masks and position conventions. For the pictured tables, use hypothetical , ten valid positions per request, and shared positions zero through seven. A has table [7,1,5]; B has [7,1,3]. Position nine has logical block two and offset one: A reads P5[1], B reads P3[1].

Six logical blocks alias four physical blocks, reserving sixteen token slots rather than twenty-four without sharing. There are twelve distinct valid KV positions: eight shared and two private per request. Private tails still waste four slots total; sharing reserves sixteen slots, not twelve.

Learning objective

A block table preserves logical order across scattered physical storage

Logical order survives scattered physical placementLogical blocks 0,1,2 map to physical pages 7,2,9. The block table, not physical adjacency, reconstructs the token sequence.The block table restores logicalorder from scattered pages0page 71page 22page 90123456789Logical order is page 7, then page 2,then page 9.
Read it this way: Logical blocks 0,1,2 map to physical pages 7,2,9. The block table, not physical adjacency, reconstructs the token sequence. Does physical page two become the first sequence block because its address is smaller?
Reference drawing

Learning objective

A block table preserves logical order across scattered physical storage

Logical order survives scattered physical placementLogical blocks 0,1,2 map to physical pages 7,2,9. The block table, not physical adjacency, reconstructs the token sequence.The block table restores logicalorder from scattered pages0page 71page 22page 90123456789Logical order is page 7, then page 2,then page 9.
Derivation
Two sequence block tables share prefix blocks in a non-contiguous physical pool Request A maps logical blocks zero, one, and two to physical blocks seven, one, and five. Request B maps the same logical prefix blocks zero and one to physical blocks seven and one, then maps its private logical block two to physical block three. Physical blocks seven and one each have reference count two. The remaining private blocks have reference count one, and unused physical blocks are free. 1 · EACH REQUEST KEEPS LOGICAL TOKEN ORDER request A logical 0 → physical 7 logical 1 → physical 1 logical 2 → physical 5 request B logical 0 → physical 7 logical 1 → physical 1 logical 2 → physical 3 same prefix mappings 2 · THE TABLE RESOLVES EACH LOOKUP IN HBM Match each physical ID to the pool below. physical KV blocks · scattered P0 free P1 prefix refs = 2 P2 free P3 B private refs = 1 P4 free P5 A private refs = 1 P6 free P7 prefix refs = 2
logical order stays fixed while physical addresses jump. Both tables reference P7 and P1; each shared block has two owners. P5 and P3 are private tails. The original schematic follows Kwon et al..
Check: Why can request A read logical blocks in order even though their physical locations are 7, 1 and 5?
Read it this way: Logical blocks 0,1,2 map to physical pages 7,2,9. The block table, not physical adjacency, reconstructs the token sequence. Does physical page two become the first sequence block because its address is smaller?

Prefix sharing

After A’s outstanding uses finish, release P5 and decrement P7/P1 reference counts from two to one. B’s prefix must remain valid; a shared block is freed only after all live owners and in-flight uses are gone. Matching visible prompt text is insufficient: tokenization, model/adapters, positions, and relevant cache state must be compatible.

Append into a Shared Partial Tail

New task: Two requests share six positions in four-token blocks, then diverge.

Picture and change: Copy the two valid entries of shared logical block one before A appends at offset two. Redirect A’s table entry and decrement the old block’s reference count before its private write.

Check: B’s position six remains absent and B’s existing bytes are unchanged.

Use when: A shared writable tail branches; directly mutating the shared block would corrupt isolation.

Use Larger Blocks

New task: Change a unique ten-token request from four-token to eight-token blocks.

Picture and change: Rebuild table indexing and allocator units together without changing logical positions.

Check: Reserved slots rise from twelve to sixteen; tail waste rises from two to six. Generally, one unshared sequence wastes slots.

Use when: Measured lookup costs justify additional tail waste; fewer table entries alone do not establish faster execution.

Continuous batching pairs naturally with paging

Paging can support continuous batching through per-request cache addressing. Admission and scheduling remain separate policies constrained by available blocks, compute, and latency targets.

Tradeoffs

  • Kernel/layout cost: indirection, bandwidth, locality, and concurrency interact; measure actual workloads.
  • Block size: smaller blocks reduce bounded tail waste but increase metadata and potentially lookup work.
  • Policy state: allocation, eviction, caching, and copy-on-write must preserve ownership and identity.

Common pitfalls

  • Different mechanisms: paging addresses cache layout/ownership; FlashAttention addresses attention’s memory-access computation. Implementations can combine them when supported.
  • Incomplete measurement: report throughput, memory, and tail latency under stated load rather than a universal serving-speed claim.