LLM Serving Capacity: KV Cache, Concurrent Users and Queue
Estimate KV cache capacity, concurrent requests, queue delay and streaming latency. Compare parallel agent completion and cost against local server and API limits.
Use this LLM serving capacity calculator to estimate how many concurrent requests fit in a server, how a steady request stream may queue, and when extra agent workers stop helping. It is intended for engineers sizing a self-hosted inference endpoint, students studying serving systems, and teams planning parallel agent workflows.
Start with Server capacity and queue. Enter the total VRAM assigned to one model replica, its resident weights, the engine's usable-memory fraction, and a reserve for activations and runtime allocations. For several GPUs, the pooled calculation assumes balanced sharding; independent replicas need separate calculations. Match the model's attention layers, KV heads and head dimension. GQA uses the KV-head count rather than the query-head count. Compressed MLA has separate latent and RoPE-key dimensions and requires measured performance.
Set the prompt and representative maximum output length. The KV cache size calculator reserves the entire prompt-plus-output context for every active sequence and rounds retained tokens to allocation blocks. Sliding-window savings apply only if the backend actually releases old blocks. The resulting memory ceiling is a capacity bound, not a guarantee of acceptable latency.
For throughput, choose a roofline estimate or enter measurements at the effective server concurrency. The defaults describe an illustrative 8B-class decoder on a 24 GiB replica; they are not a GPU benchmark. The roofline compares weight and KV reads with operation demand. Compute is entered in TFLOP/s; 60 means 60 trillion operations per second. Its prefill screen shows why chunking can reduce individual decode stalls while introducing more scheduling interleaves. A measured vLLM or SGLang run should match the same hardware, token lengths, cache format and slot count.
Enter arrivals in requests per minute. The queue calculation uses a fixed calibrated service rate with Erlang C. It reports no finite wait when arrivals reach capacity. Little's law converts mean response time into the average requests present. This estimates concurrent requests, not logged-in users; a user population also needs a request frequency or think-time model.
Switch to Agent parallelism to compare a dedicated local replica with an external API. Describe a uniform fork-and-join graph using dependent stages and independent calls per stage. Local work runs in bounded waves. API work is smoothly paced by requests per minute, quota-charged tokens per minute and a concurrency ceiling. The critical path, completion curve and editable cost assumptions show how far to parallelise agents before a resource limit dominates.
Results are first-order planning estimates. They exclude heterogeneous graphs, speculative decoding, prefix sharing, cache offload, retries and provider burst allowances. Queue delays assume random arrivals and exponential service despite the batching approximation. Use matched workload benchmarks for deployment decisions and a calibrated simulator such as Vidur when detailed latency distributions matter.
How it is calculated
Memory: . Raw conventional cache bytes/token are ; compressed MLA uses (DeepSeek-V2, attached s3, Sections 2.1.2–2.1.4). Apply replication and metadata factors, cap sliding layers at the window, and round each retained length to complete blocks. The rolling-window storage cap follows Mistral 7B (s10 p.2). Divide the available pool by the reserved per-sequence footprint and round down. PagedAttention (s1 p.4) provides the independent OPT-13B memory example; GQA (s2 p.2) explains shared KV heads.
Roofline: one generated token uses approximately operations. Each decode iteration takes the larger of compute time and weight-plus-KV bandwidth time, plus launch overhead. For each prefill chunk with new tokens after prompt tokens, operation demand is . Bandwidth demand includes weights plus one read of the retained preceding KV cache, including replication and cache overhead. The retained prefix is capped separately for sliding layers (Mistral 7B, s10 p.3). The chunk time is the larger compute/bandwidth demand plus launch overhead; prefill sums those chunk times. Arithmetic-series sums split at the sliding-window and roofline crossovers, so even one-token chunks need no long simulation loop. The compute input is in TFLOP/s: one operation/ps equals one trillion operations/s, converted explicitly to operations/s. These are our dense-decoder work estimates, following the arithmetic approach of kipply, not fitted performance curves. The service proxy adds the first-token timeline and the remaining decode iterations; completed throughput is . It treats prefill and decode resource demands as serialized. Orca (s5) motivates iteration-level admission; the calculator does not reproduce its scheduler.
The batch TTFT screen charges . When and , it also charges decode interleaves before the first token. Completion uses exactly that first-token timeline followed by decode iterations. For one-token responses, no decode interleaves or output decode steps are charged: TTFT and completion coincide. This is a deliberately simple batch-interference proxy, not a scheduler simulation. Decode-only ITL is ; an interleaved chunk adds the longest chunk duration, illustrating Sarathi-Serve's chunking tradeoff (s4 pp.3–4). For measured mode, ; TTFT and ITL use user measurements for multi-token outputs. For a one-token output, first-token time is the same inferred occupancy, and redundant TTFT/ITL inputs are hidden. Below calibrated concurrency, the graph conservatively holds measured slot occupancy constant.
Queue: . An Erlang B recurrence gives numerically stable Erlang C, followed by , only for . Response time is and Little's law gives . This is a fixed operating-point M/M/c surrogate for shared batching.
Agents: every stage is a fork of identical calls followed by a join. Local waves respect both requested parallelism and effective server slots. The dependency-only bound is one call per stage plus interstage delays. API launch spacing is the reciprocal of the available minimum of RPM and TPM divided by charged tokens/call. A deterministic schedule enforces that spacing globally, worker completion times and every stage barrier. Rental cost uses graph execution time; API token cost uses input and output tokens, independent of parallelism.
Assumptions
All requests have the same representative prompt and output length. Peak memory reserves output in advance; no prefix sharing, offload, beam branching or speculative draft cache is credited. The overhead factor includes cache quantization scales; weight quantization is already reflected in resident weights.
One balanced replica group is modeled. Cache replication is an explicit multiplier; memory and bandwidth cannot be pooled freely across unrelated replicas or imbalanced pipeline stages. The roofline assumes a dense decoder with equal key/value dimensions. Select measured mode for MoE and MLA. Its full-context attention FLOPs are conservative for sliding-window models.
The server queue is an open Poisson arrival stream with independent exponential service at a fixed target-batch calibration. Actual continuous batching violates the independent-server assumption. Slot count is capped by memory; the displayed server slot value is only meaningful after memory conditions pass.
Agent comparison uses a dedicated local replica and excludes the server queue's background traffic. The API has constant queue-excluded service time, a common combined token bucket, smooth pacing, no burst credit and no retries. For separate input/output buckets, convert each to calls/minute and enter the tightest equivalent combined budget. Tool delay occurs only between stages. Every agent call uses the workload token counts.
All price and quota defaults are illustrative editable assumptions dated 2026-10-27, not provider offers. Local rental excludes idle time before/after execution, billing minimums, energy and operations; API cost excludes caching discounts, tools and failed calls.
Sliding-window storage assumes an ideal rolling buffer rounded to blocks; allow extra overhead if the backend keeps additional boundary or look-ahead blocks.
Prefill bandwidth counts one preceding-KV read per chunk and assumes new-chunk KV reuse within the kernel. It does not model extra memory rereads across query tiles; use measured calibration when kernel tiling, cache writes or communication dominate. The ITL stall screen uses the longest chunk, including a shorter final chunk if present.
Where it applies
Use for screening capacity and identifying which parameter to benchmark next. A memory ceiling is not a safe production concurrency setting or a latency SLO. Saturated throughput is held fixed while arrival rate is swept; light-load batch changes and scheduler feedback are not modeled.
There is no finite steady-state queue result at or above capacity: time cards read “Unbounded”. Near saturation, small calibration errors produce large wait errors. The TTFT/interleave screen uses a serialized batch-interference timeline and is not a percentile guarantee. In measured mode, roofline-only table columns remain labeled as such and are not used for queue or graph throughput.
Graphs are homogeneous layered fork-and-join workloads with deterministic calls. They do not represent arbitrary DAGs, asynchronous agent reasoning, stragglers, token-length distributions, cancellations or shared provider traffic beyond the quota fraction. A concurrency ceiling is not a token-bucket burst allowance.
Validate on the exact server configuration and traffic mix. Vidur (s6) is a reference for calibrated simulator-level studies; this calculator makes no simulator-grade accuracy claim. Quotas and prices must be checked against the user's account and date of use.
References
- PagedAttention / vLLM: Kwon et al. (2023), Efficient Memory Management for Large Language Model Serving. https://arxiv.org/abs/2309.06180 — attached s1, p.4 OPT-13B example.
- GQA: Ainslie et al. (2023), Training Generalized Multi-Query Transformer Models. https://arxiv.org/abs/2305.13245 — attached s2, p.2.
- DeepSeek-AI (2024), DeepSeek-V2, Sections 2.1.2–2.1.4. https://arxiv.org/abs/2405.04434 — attached s3.
- kipply (2022), Transformer Inference Arithmetic. https://kipp.ly/p/transformer-inference-arithmetic — arithmetic method, not a measured GPU benchmark.
- Yu et al. (2022), Orca: A Distributed Serving System for Transformer-Based Generative Models, OSDI. https://www.usenix.org/conference/osdi22/presentation/yu — attached s5.
- Agrawal et al. (2024), Sarathi-Serve. https://arxiv.org/abs/2403.02310 — attached s4, pp.3–4.
- vLLM Optimization and Tuning, chunked prefill, accessed 2026-10-27. https://docs.vllm.ai/en/latest/configuration/optimization/
- J. E. Beasley, OR-Notes: Queueing theory, worked M/M/1 and M/M/2 comparison. https://people.brunel.ac.uk/~mastjjb/jeb/or/queue.html
- Agrawal et al. (2024), Vidur: A Large-Scale Simulation Framework for LLM Inference. https://arxiv.org/abs/2405.05465 — attached s6; reference only.
- Jiang et al. (2023), Mistral 7B, rolling buffer cache and the published 8x memory saving at 32k context. https://arxiv.org/abs/2310.06825 — attached s10, p.2.
Inputs
| Input | Symbol | Unit | Default |
|---|---|---|---|
| Study Agent comparison uses a dedicated local replica; background arrivals apply only to the server queue. | study | Server capacity and queue | |
| Total VRAM in one replica group Sum across balanced shards of one model replica. Do not sum independent replicas. | vram | GiB | 24 |
| Fraction of VRAM usable by engine For example, gpu_memory_utilization = 0.90. Weights and reserve are subtracted within this budget. | mem_fraction | 0.9 | |
| Resident model weights Actual resident weights across that group, including quantization metadata. Default is an illustrative 8B deployment. | weights | GiB | 15 |
| Activation and runtime reserve CUDA graphs, activations, workspaces and other non-KV allocations inside the engine budget. | reserve | GiB | 2 |
| KV storage overhead multiplier Extra scales, alignment and metadata. Block rounding is applied separately. | kv_overhead | 1.05 | |
| KV replication factor across group 1 for perfectly sharded cache; increase for replicated KV heads or replicated MLA latent cache. | kv_copies | 1 | |
| Cached attention representation MLA requires a backend that stores the compressed latent and RoPE key. Select measured performance for MLA. | attention | MHA / GQA / MQA | |
| Attention layers Default is an illustrative 32-layer decoder. | layers | 32 | |
| KV heads per layer MHA: query head count. GQA: KV head count. MQA: 1. | kv_heads | 8 | |
| Key and value head dimension Assumes equal key and value widths. | head_dim | 128 | |
| MLA compressed KV dimension DeepSeek-style latent vector dimension, before the separate RoPE key. | latent_dim | 512 | |
| MLA cached RoPE key dimension One decoupled RoPE key per token and layer, not one per query head. | rope_dim | 64 | |
| Storage per cached element FP16/BF16: 2 B; FP8: 1 B. Quantization scales belong in the overhead multiplier. | kv_bytes | B | 2 |
| Cache retention Choose sliding only when the serving backend actually releases old window blocks. | windowing | All layers retain full context | |
| Layers retaining full context The remaining attention layers use the sliding window. | full_layers | 0 | |
| Sliding window tokens Cache size is capped at this many tokens in sliding layers. | window_tokens | 4096 | |
| KV allocation block tokens Round each layer's retained tokens up to whole blocks. | block_tokens | 16 | |
| Prompt tokens per request Count system prompt, history, retrieved text and tool definitions. | prompt_tokens | 4096 | |
| Maximum / representative output tokens Memory reserves the full value. Queueing treats every request as this representative size. | output_tokens | 512 | |
| Configured context limit Model and engine limit for prompt plus output, regardless of sliding-window retention. | context_limit | 131072 | |
| Target in-flight server sequences Effective slots are the smaller of this setting and the KV memory ceiling. | target_c | 4 | |
| Server arrivals (requests per minute) Open arrival process used for the server queue. Agents use a separate finite-burst model. | arrival_rpm | 1/min | 6 |
| Performance calibration Measured values must use the same prompt, output, context, hardware and effective slot count. | performance | Roofline estimate | |
| Active parameters (billions) Dense decoder approximation. For MoE or MLA, use measured mode. | active_billion | 8 | |
| Query heads per layer Used for attention FLOPs, never for GQA KV storage. | query_heads | 32 | |
| Effective aggregate memory bandwidth Sustained bandwidth across balanced shards after communication losses, not advertised peak. | bandwidth | GB/s | 600 |
| Effective compute (TFLOP/s) 60 TFLOP/s means 60 trillion operations/s, or 60 operations/ps. Use sustained effective compute rather than advertised peak. | compute_rate | 1/ps | 60 |
| Launch and scheduler time per iteration Time beyond the compute / bandwidth roofline. | iteration_overhead | s | 0.001 |
| Prefill interference screen A simplified serialized prefill/decode interleave, not a reproduction of vLLM's scheduler. | prefill_policy | Chunked prefill | |
| Prefill chunk tokens At most this many prompt tokens per chunk. Smaller chunks shorten individual decode stalls. | chunk_tokens | 512 | |
| Measured completed requests per minute Saturated completed throughput at effective slots, same prompt/output mix; exclude client throttling. | measured_rpm | 1/min | 12 |
| Measured TTFT excluding admission queue Service-side time to first token at the same effective slot count. | measured_ttft | s | 2 |
| Measured inter-token interval Streaming interval from the same workload and concurrency. | measured_itl | s | 0.035 |
| Dependent graph stages Uniform fork-and-join stages; each stage waits for all calls in the preceding stage. | stages | 4 | |
| Independent calls per stage Each call uses the common prompt and output lengths; one call per active worker. | stage_width | 8 | |
| Requested parallel agent calls Local execution is capped by server slots; API execution by API concurrency and pacing. | workers | 8 | |
| Tool / orchestration delay between stages Serial delay after each stage except the last. | tool_delay | s | 1 |
| API request quota (requests per minute) User's current quota, not a provider default. Other workloads are excluded. | api_rpm | 1/min | 60 |
| API total token quota (tokens per minute) Combined charged token budget. For separate input/output buckets, enter the tightest equivalent rate. | api_tpm | 1/min | 120000 |
| Quota-charged tokens per API call Use provider accounting, including reserved output if applicable. Can differ from billable tokens. | quota_tokens | 4608 | |
| Quota fraction available to this graph Headroom after other traffic. Smooth pacing assumes no burst credit and no retries. | api_fraction | 0.8 | |
| API simultaneous request ceiling Use your gateway/provider cap or a deliberate client ceiling. | api_slots | 32 | |
| API response time excluding rate-limit wait Measured or assumed wall time per call for the same workload. Constant in this model. | api_service | s | 20 |
| Local replica rental (USD per hour) Illustrative editable rate dated 2026-10-27; whole replica group. Excludes idle time outside this graph. | server_hourly | 1 | |
| API input price (USD per million tokens) Illustrative user assumption dated 2026-10-27; excludes caching discounts, tools and retries. | price_input | 1 | |
| API output price (USD per million tokens) Illustrative user assumption dated 2026-10-27, not a live provider quote. | price_output | 3 |
Results
With the default inputs above, the calc gives:
| Result | Value |
|---|---|
| KV-resident sequence ceiling | 7 |
| Usable KV memory | 4.6 GiB |
| Effective server slots | 4 |
| Server capacity (requests/min) | 11.33 1/min |
| Server offered load / capacity | 0.53 |
| Mean admission queue delay | 2.301 s |
| First token including queue | 7.218 s |
| Decode interval without prefill | 31.84 ms |
| Request / local graph completion | 23.49 s |
| Mean occupancy / API graph time | 2.349 requests in system |
| Illustrative cost | USD 0.001471 per request at saturation |
| Operating limit | Stable at the selected batch calibration |
Checked against sources
Each case below was calculated by this calc and agrees with the value from its source (within the tolerance where one is shown).
OPT-13B FP16 KV footprint (PagedAttention)
Source: Kwon et al., PagedAttention (2023), attached s1 p.4: OPT-13B has 800 KB/token and about 1.6 GB per 2048-token request. The stated dimensions imply 819,200 bytes = 800 KiB and 1.5625 GiB. The paper uses KB/GB informally; the calculator keeps binary GiB explicit.
Inputs: Performance calibration = Measured at effective server slots; Attention layers = 40; KV heads per layer = 40; KV storage overhead multiplier = 1; Prompt tokens per request = 2,047; Maximum / representative output tokens = 1; Target in-flight server sequences = 1; Measured completed requests per minute = 8 1/min; Server arrivals (requests per minute) = 0.5 1/min; the others as above.
| Result | Source | This calc |
|---|---|---|
| Raw full-context KV bytes per token | 819,200 B | 819,200 B |
| Reserved peak cache per sequence | 1.563 GiB | 1.563 GiB |
Published M/M/1 example: one server twice as fast
Source: J. E. Beasley, OR-Notes, 'Faster servers or more servers?', https://people.brunel.ac.uk/~mastjjb/jeb/or/queue.html. Arrivals 0.5/min, one server 8/min. Published comparison gives 6.25% wait probability, 0.0083 min queue time and 0.1333 min total time; expectations convert the published rounded minutes to seconds.
Inputs: Performance calibration = Measured at effective server slots; Target in-flight server sequences = 1; Measured completed requests per minute = 8 1/min; Server arrivals (requests per minute) = 0.5 1/min; Prompt tokens per request = 1; Maximum / representative output tokens = 1; the others as above.
| Result | Source | This calc |
|---|---|---|
| Probability an arrival must queue | 0.0625 | 0.0625 |
| Mean admission queue delay | 0.498 ± 0.005 s | 0.5 s |
| Mean end-to-end request time | 7.998 s | 8 s |
Published M/M/2 example: two original-rate servers
Source: J. E. Beasley, OR-Notes, same worked comparison, https://people.brunel.ac.uk/~mastjjb/jeb/or/queue.html. Two servers at 4/min each; arrivals 0.5/min. Published results: 0.7353% chance of wait, 0.0010 min queue time, 0.2510 min total time. Tolerances cover rounding to four decimal minutes.
Inputs: Performance calibration = Measured at effective server slots; Target in-flight server sequences = 2; Measured completed requests per minute = 8 1/min; Server arrivals (requests per minute) = 0.5 1/min; Prompt tokens per request = 1; Maximum / representative output tokens = 1; the others as above.
| Result | Source | This calc |
|---|---|---|
| Probability an arrival must queue | 0.007353 | 0.007353 |
| Mean admission queue delay | 0.06 ± 0.003 s | 0.05882 s |
| Mean end-to-end request time | 15.06 s | 15.059 s |
Mistral published 32k/4k rolling-cache saving
Source: Jiang et al., Mistral 7B, attached s10 p.2, Rolling Buffer Cache. The paper reports an 8x reduction at 32k tokens with a 4096-token window; here 32k means 32768, consistent with the reported factor. This checks storage reduction, not language-model quality or throughput.
Inputs: Performance calibration = Measured at effective server slots; KV storage overhead multiplier = 1; Cache retention = Mixed full and sliding-window layers; Prompt tokens per request = 32,767; Maximum / representative output tokens = 1; Configured context limit = 32,768; Target in-flight server sequences = 1; Server arrivals (requests per minute) = 0.5 1/min; Measured completed requests per minute = 8 1/min; the others as above.
| Result | Source | This calc |
|---|---|---|
| Full-context cache / actual retained cache | 8 | 8 |
Independent reviewer: 65,536 single-token prefill chunks
Source: Independent reviewer numerical example supplied by the user: raw preceding-KV reads give about 2293.87 s for the stated long-prompt case. kv_overhead=1 makes this a raw-KV comparison; the default 1.05 multiplier instead gives about 2317.33 s. This is an arithmetic regression, not a published hardware benchmark. Mistral 7B s10 p.3 supplies the cache-attention mechanism, not the numerical result.
Inputs: Total VRAM in one replica group = 48 GiB; Prompt tokens per request = 65,536; Maximum / representative output tokens = 1; Prefill chunk tokens = 1; Target in-flight server sequences = 1; Server arrivals (requests per minute) = 0 1/min; KV storage overhead multiplier = 1; the others as above.
| Result | Source | This calc |
|---|---|---|
| Sum of per-chunk prefill roofline times | 2,294 s | 2,294 s |
| TTFT including admission queue | 2,294 s | 2,294 s |
| Mean end-to-end request time | 2,294 s | 2,294 s |







Responses