IIntroduction to AI Systems Performance EngineeringTechnical textbook
Chapter 20: Production Inference Systems
20.3

Capacity and unit economics

Compute cost from real occupancy and headroom

Before you begin

Follow a linked prerequisite when you cannot explain it from memory. Background skills without links are stated as abilities rather than hidden terminology.

  • Goodput
  • Operating curves
  • Basic amortization

The 7-billion-parameter service receives 70 requests per second on ordinary afternoons, 100 during a predictable peak, and brief bursts above 130. A load test shows that one GPU replica sustains 85 useful requests per second under the latency and quality objectives, while an offline batch test reports a much larger number that ignores arrival timing. Capacity planning must use the measured online curve and provide room for burst absorption and replica failure.

Build one hour of demand from request arrivals, input tokens, output tokens, active-sequence time, retained key-value tokens, and request class. Multiply the useful work by measured replicas needed at each operating point, then add host, network, power, idle reserve, startup, and failure costs. The calculation defines capacity as work the service can complete within constraints, not as nominal GPU arithmetic throughput.

Capacity planning connects a load distribution to provisioned replicas. The planning process asks how many useful requests a replica can sustain at the SLO, how much reserve is needed for burst and failure, how traffic is balanced, and how much each completion costs. Peak benchmark throughput is only one input.

AI serving has several coupled capacity units: weight-resident replicas, KV memory, prefill compute, decode bandwidth, network, and sometimes draft or retrieval systems. A replica can have spare arithmetic and no KV blocks, or spare memory and a saturated interconnect. Capacity must be calculated for every resource needed by the admitted request mix.

Disaggregating prefill and decode can place the two phases on different resource pools, but it introduces KV transfer, routing, queueing, and failure boundaries. Replication can remove some communication but consume more weight memory. The capacity model should compare complete topologies at the same service objective.

Convert demand into active work and state

For each request class, begin with its arrival process, prompt-length distribution, generated-length distribution, latency objective, cache-hit behavior, and cancellation. Convert arrivals into input tokens per second, output tokens per second, active decode-sequence time, peak concurrent KV tokens, and network traffic.

In a stable window, Little's law provides a useful check: mean requests in the system equal arrival rate multiplied by mean residence time. Apply the relation separately to relevant classes or phases when their service times differ. Little's law predicts mean concurrency, not the KV-cache tail; memory admission still needs the joint distribution of concurrent sequence lengths and a reserve for growth.

Use measured operating curves for the selected model, hardware, parallel plan, quantization, and scheduler. A replica's sustainable goodput is the highest rate that meets the class SLO under the representative mix and remains stable. Offline maximum throughput is not the service rate for an interactive pool.

Traffic distribution creates fragmentation. Models, adapters, regions, tenants, and latency classes may need separate replicas or routing rules. Ten half-used specialized pools do not combine into five fully used replicas automatically. Record stranded memory and compute as part of fleet utilization.

Add reserve, burst, startup, and failure

Choose a utilization target that leaves room for normal length variation and arrival bursts. Then add the failure policy: loss of one replica, a percentage of a rack, or a complete zone. Divide required service rate by the capacity that remains in the stated failure case, and account for load-balancing unevenness.

Autoscaling cannot remove the need for immediate reserve. New replicas may need image download, model loading, quantization artifact loading, graph compilation, memory profiling, graph capture, health checks, and cache warming. If this takes minutes, existing reserve or bounded queues must absorb demand during that interval.

Stateful warmth affects restored capacity. A newly started replica has no prefix cache and may compile new shapes under load. A failover can therefore increase prefill demand at the same moment that fewer replicas remain. Test the failure transition, not only the final healthy replica count.

Calculate fully loaded cost per useful output

Include provisioned accelerator, host, memory, storage, network, energy, software, idle reserve, failures, and retries over a defined period. Divide by requests or tokens that meet quality and SLO requirements. Report marginal cost separately when a decision concerns one additional request on already provisioned capacity.

For purchased hardware, specify depreciation period, expected lifetime utilization, power, cooling, and maintenance. For cloud capacity, specify reservation terms, on-demand premiums, data transfer, and minimum billing intervals. Do not compare one option's marginal cost with another option's fully loaded cost.

Engineering complexity is difficult to reduce to one currency value but should remain explicit. A specialized topology can reduce accelerator expense while increasing rollout risk, on-call load, or vendor dependence. Present those risks beside the quantitative cost rather than hiding them in an arbitrary score.

Calculate cost over the complete demand curve. A configuration with the lowest cost per token at full load may be expensive during nights or regional troughs because its replicas cannot consolidate, scale down, or share capacity. Weight each operating region by time and traffic, then include the reserve that remains provisioned but idle.

Worked example: Sizing an interactive pool

Peak demand is 9,000 requests/s. Under the real workload mix, one replica sustains 110 requests per second that complete successfully and meet every declared latency and quality SLO. This rate is the replica's request goodput.

  1. The simple healthy requirement is about 82 replicas. The 82-replica result has no burst or failure margin.
  2. To tolerate loss of 10% capacity while staying within the operating point, divide by 0.9, producing about 91 replicas, then consider load-balancing unevenness.
  3. Add burst behavior and autoscaling delay. If loading a model takes minutes, additional warm reserve or a bounded admission queue may be needed.
  4. Calculate cost per useful request from provisioned replicas over the demand curve, not only at peak. Compare pooling and traffic-shaping alternatives.

Conclusion: The 82-replica calculation covers only healthy peak demand. Approximately 91 replicas preserve that service rate after a 10 percent loss before load-balancing and burst margins. Startup time, cold-cache behavior, and the full demand curve determine the final reserve and cost.

Common errors

  • Dividing peak demand by peak throughput. Sustainable per-replica goodput at the SLO is the relevant service rate.
  • Treating all GPU-hours as equally utilized. Demand curves and reserve determine actual cost per useful completion.
  • Assuming instant scale-out. Model loading, compilation, routing, and cache warm-up create stateful startup.

Reference summary

cost/useful token = total period cost / tokens meeting quality and SLOs
Include accelerator, host, network, power, idle capacity, failures, and material operating costs.

Convert arrival and length distributions into input tokens, output tokens, active sequence time, KV occupancy, and network traffic. Apply the measured goodput curve for each configuration. Then add traffic fragmentation, burst margin, failover reserve, startup time, and cold-cache behavior.

Calculate cost over the full demand curve. Include provisioned but idle reserve, host and network, energy, failures, retries, and operational requirements. A configuration that is cheapest only at full load can have poor fleet economics when it cannot consolidate during lower demand.

  • Use separate marginal cost and fully loaded cost for different decisions.
  • Model accelerator-hours lost to fragmentation and stranded memory.
  • Compare scale-up versus scale-out with topology and failure-domain costs.
  • Include engineering complexity and vendor lock-in as explicit qualitative risks.
  • Track joules per useful token when power or thermal capacity constrains growth.

Knowledge check

Why can the configuration with the lowest measured cost per token at full load have worse fleet economics?

Show the answer guide
  • The lowest cost per token at full load assumes a continuously saturated, efficiently batched replica. Real demand varies, so the fleet needs enough replicas and reserve to absorb bursts, failures, maintenance, and uneven request lengths without violating latency objectives.
  • A configuration whose efficiency appears only near saturation can have a narrow admissible range. The narrow range may require more idle headroom, produce long queues during bursts, or need extra replicas because each large iteration has poor tail latency.
  • Memory limits, startup time, failure domains, and recovery behavior can reduce usable capacity below the full-load benchmark. Timed-out or canceled work further increases cost without adding useful tokens.
  • Fleet economics must use goodput per provisioned dollar across the demand trace, including idle capacity, redundancy, energy, and SLO penalties. The full-load token minimum is one point on that curve, not the objective by itself.
Practice

Convert a full-load benchmark into a fleet plan

Compare two declared server configurations. Configuration A costs $3 per GPU-hour, reaches 1,000 tokens/s at saturation, and meets SLO only below 65% load. Configuration B costs $4 per GPU-hour, reaches 900 tokens/s, and meets SLO below 85% load. Apply both to a 24-hour demand trace with a 300,000-token/s baseline, two 600,000-token/s peaks, one-replica failure reserve, and integer replica counts. Replace the illustrative rates with measured values if available.

Evidence to keep: Submit the capacity model or spreadsheet, the demand trace, replica count by interval, utilization and reserve, served goodput, rejected or late work, energy or hourly cost, and total cost per SLO-compliant token for both configurations. State why the full-load winner does or does not win the fleet calculation.

Capacity absorbs expected variability. Admission, degradation, and recovery policies protect the system when demand or failure exceeds that plan.

References

Sources and further reading

The lesson explanations synthesize primary papers and official references. Follow the originals for proofs, exact APIs, architecture details, and version-sensitive behavior.

  1. MLPerf Inference Rules
  2. PagedAttention / vLLM
  3. SGLang
  4. NCCL RAS
  5. NVIDIA Nsight Systems User Guide

    Official reference for capturing and reading CPU, CUDA API, GPU workload, and communication timelines.