research29 min studyLesson 747 in Engineering

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

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.

MKV=kB∑i⌈siB⌉M_{\rm KV}=kB\sum_i\left\lceil\frac{s_i}{B}\right\rceil
For independent unshared sequences, si is retained positions, B positive integer positions per block, and k bytes per stored position under the actual cache representation. This bytes inventory includes final-block rounding but excludes metadata, shared-prefix accounting, staging, and future unreserved growth.↔ Scroll wide equations horizontally.

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.

λE[Lout]<Rdecode\lambda\mathbb E[L_{\rm out}]<R_{\rm decode}
This necessary mean-load margin uses requests/s, generated tokens/request, and useful generated tokens/s under a matching workload. It assumes the same output convention and does not prove latency, burst tolerance, memory feasibility, fairness, or linear replica scaling.↔ Scroll wide equations horizontally.

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.

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.

  1. 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.

  2. 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.

  3. 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 result

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.

Explore the model

Interactive lab

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.

Two normalized demands can share one misleading magnitudePlayback traces a fixed vector and its projections. Angle and magnitude set the geometry; the moving marker does not change them. Current readings: x component: 1.393; y component: 0.975; Magnitude: 1.7. All parameters are adjustable with the labeled controls below.−7.46−3.7303.737.46−3.5−1.7501.753.5xyvvₓ = 1.39
Vectorx / y projectionsTrace marker
x component
1.393
y component
0.975
Magnitude
1.7
t = 0 s

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.

Check your understanding

A cluster has enough total free KV bytes, but the selected tensor-parallel decode group lacks required space on one shard. Which conclusion follows?

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.

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.