Decode capacity: token service and cache placement constrain scaling
Account for rounded KV blocks, per-instance feasibility, future growth, and token-rate demand before adding decode replicas.
On this page
The question for today
What you’ll understand
- Calculate block-rounded cache usage and internal waste.
- Separate mean token demand from memory and latency feasibility.
- Explain why adding a replica does not automatically migrate active decode state.
A decode pool’s capacity is not just its number of active requests. Each sequence carries growing state, each iteration reads context and model data, and a batch competes for bandwidth, memory, and scheduling time. Disaggregation permits independent decode scaling but does not make existing KV state instantly movable or eliminate per-instance fragmentation. We use a simple fixed-block cache inventory and mean token-rate condition. Real serving implementations require their actual layouts, sharing rules, parallel groups, and admission contracts.
Round allocations at the actual block granularity
For a fixed block size, a sequence generally occupies a rounded number of blocks, leaving unused positions in its final block. That internal waste differs from free blocks stranded across different devices or parallel groups. Shared prefixes and copy-on-write branches add reference accounting; do not charge one physical shared block once per logical sequence unless that is the intended conservative budget. Distinguish usable cache capacity from total device memory after weights, workspaces, staging, and runtime margins. A count of free bytes without these distinctions is not an admission proof.
Decode growth also requires a future policy. An estimated output length can guide packing but cannot guarantee that a request stays within the estimate. A hard generation cap, reserved extension blocks, explicit eviction/recomputation, or a defined failure response is needed for bounded resource claims. Variable arrivals and endings alter fragmentation over time. Test the allocation and release trace across EOS, cancellation, transfer, and branch termination rather than compute a single static occupancy percentage and assume it persists under continuous batching.
Mean token capacity is only one necessary condition
With request arrival rate and mean generated length, the mean output-token demand is their product under a consistently defined workload. A decode pool needs sufficient useful token service as well as enough resident state and acceptable iteration latency. Larger batches may improve aggregate throughput while worsening per-request gaps; small batches may underuse compute. Longer contexts can change per-token cost, so one fixed tokens-per-second number is not transferable across every length distribution. Preserve the prompt and output mix when comparing capacity measurements.
Adding a replica adds model residency and a potential place for new work; it does not automatically rebalance current sequences. Moving an active request needs a compatible KV and generation-state handoff, valid output ownership, transfer capacity, and a latency budget. A tensor-parallel decode instance also requires feasible state across its required shards, not merely aggregate free memory across the cluster. A request whose state fits in total can still fail because one required shard or chosen instance lacks its local obligation.
Measure fragmentation and scaling under real lifetimes
Report allocated blocks, logically used positions, unused final-block positions, shared references, uncommitted reservations, and per-instance free capacity. Include workload phases with long survivors and short arrivals, which can leave capacity distributed poorly even when the cluster average looks healthy. Check cleanup after aborted transfers and canceled streams. Scale-out tests should show when new instances become model-ready, how new requests are routed, and whether active-state movement is attempted. Count transfer and duplicated state during migration rather than treating it as a free rebalance.
The vector lab illustrates two normalized resource dimensions. Reset, explicitly set angle 45 degrees and magnitude two, predict both projections, then Play or Step. Compare a fresh Reset with angle zero and magnitude two explicitly set. The projections are approximately (1.414,1.414) versus (2,0) at the same magnitude. This geometric model contains no KV blocks, sequences, batch scheduling, or replicas. It only shows why one aggregate resource number cannot describe every memory-and-service demand profile.
Work it through
Rounding consumes eighty position slots for forty-nine used
Three independent unshared sequences retain seventeen, thirty-one, and one positions. Blocks hold sixteen positions each, and usable cache capacity is 128 position slots. Ignore all other allocations and future growth for this static inventory.
The sequences need two, two, and one blocks respectively. Their rounded allocation is 32+32+16=80 position slots, while logical use is 17+31+1=49.
Unused allocated positions total 80−49=31, or 31/80=38.75 percent of the rounded allocation. This is internal block waste, not the fraction of all device memory that is free.
The unallocated stated capacity is 128−80=48 slots, or three whole blocks. These blocks can satisfy only compatible local obligations under the actual allocator; the calculation does not reserve future sequence growth or describe stranded capacity on another instance.
The listed sequences use forty-nine positions but allocate eighty slots. Admission must account for both rounding and future growth rather than only logical tokens.
The living notebook
Explore the model
Interactive lab · vectors
Two normalized demands can share one misleading magnitude
Use independent Reset → explicitly set BOTH angle and magnitude → predict → Play/Step runs for (45°,2) and (0°,2), giving approximately (1.414,1.414) and (2,0). Coordinates are normalized dimensions, not measured cache or bandwidth. No decode allocator or scheduler is modeled.
- x component
- 1.393
- y component
- 0.975
- Magnitude
- 1.7
Playback traces a fixed vector and its projections. Angle and magnitude set the geometry; the moving marker does not change them. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forMemory feasibility and token service are separate constraints even when one aggregate utilization number is unchanged.
Pause & reason
Check your understanding
Your turn
Try it yourself
Two unshared sequences retain eighteen and two positions with sixteen-position blocks. Compute rounded allocation, logical use, and unused allocated positions. Separately, arrival three requests/s with mean forty output tokens needs what mean token demand?
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Round each sequence independently before summing, and do not confuse resident positions with generated tokens per second.
Compare with the solution
The allocations are 32 and sixteen slots, totaling 48; logical use is twenty, leaving 28 unused allocated positions. Mean output demand is 3×40=120 tokens/s under the stated workload. A service rate above 120 supplies only a necessary mean margin, not proof of burst, gap-latency, or memory feasibility. Future growth, prefixes, parallel-shard placement, staging, and release lifetimes need the actual allocator and scheduler contract.
Keep the idea
Take it with you
- Account for block rounding, sharing, and future growth separately.
- Check both token-service margin and local cache feasibility.
- Treat active-request rebalancing as a state transfer with ownership and latency costs.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.