Serving capacity

Plan context length and concurrency together

Choose the context and expected simultaneous requests first, then use the remaining VRAM to test a serving capacity boundary.

Context is a capacity decision

Longer prompts and responses reserve more KV Cache. Start with the useful context for the workload instead of selecting the largest number available.

Concurrency multiplies the cache

Each active request needs its own cache budget. Serving plans should state their target concurrency rather than borrowing a single-user result.

Tune the pressure point

When capacity is tight, compare reduced context, reduced concurrency, a smaller weight format, or a larger aggregate VRAM target as distinct paths.

Scale dense endpoints with independent replicas

Keep the command arguments tied to one dense-model replica. Add independent replicas behind the endpoint only after the per-replica memory boundary is clear; each replica carries its own model and KV Cache allocation.

Continue planning

Test this memory constraint with a live capacity plan.

Editorial record

Maintained by Make Your Own Tools to turn “Fit an LLM workload” into a defined weights, context or activations, runtime reserve, and the next hardware boundary. The references below provide the technical context for this planning path. Its calculation rules and planning assumptions are documented in the methodology, and affected calculations pass regression checks before the review date advances.

Last reviewed
Evidence set
4 primary references
Calculation coverage
2 affected rules checked
Planning scope
vLLM context and concurrent-request capacity planning.
Next check
Carry the capacity boundary into the exact vLLM version, model configuration, request distribution, and deployment topology.