LLM capacity planner
Turn a model idea into a VRAM plan you can operate.
Separate loaded weights, KV Cache, runtime reserve, context length, and concurrent requests before you choose a local GPU or a serving target.
Start with the real constraint
Choose the work that will pressure the memory budget.
Local chat
One model, one user
Start from a smaller GPU target and see how context changes the capacity boundary.
vLLM serving
Context plus concurrency
Turn the same model into explicit model-length, per-engine, and endpoint-capacity limits.
LoRA training
Base weights plus activations
Plan the training pressure from sequence length, micro-batch size, adapters, checkpointing, and strategy.
Learn the moving parts
Read only what changes the capacity plan.
Memory model
Separate model weights, KV Cache, and runtime reserve
A parameter count alone cannot tell you whether a model will fit at the context length and concurrency you need.
Read guide →Serving capacity
Plan context length and concurrency together
A model that fits for one chat can run out of capacity once long requests or parallel users share the same GPU.
Read guide →vLLM model length
Set vLLM max model length from the KV Cache budget
Choose a useful maximum request length that leaves enough cache for the number of active requests you want to serve.
Read guide →vLLM concurrency
Plan vLLM concurrency before raising max_num_seqs
Translate a request target into cache pressure before exposing it as an endpoint concurrency limit.
Read guide →LoRA mode
Choose LoRA or QLoRA from the base-weight budget
Choose the adapter path only after you know how much of the GPU is already occupied by the frozen base model.
Read guide →Training memory
Set sequence length and micro-batch before increasing VRAM
Control activation memory with the two workload inputs that move it most: sequence length and micro-batch size.
Read guide →