Parameter count and precision give a first weight-memory estimate.
An 18 GB model file does not mean a 24 GB GPU will serve it under every workload. Beyond weights, quantization overhead, runtime, KV cache, context and concurrent sequences consume VRAM. This tool shows the budget components separately.
The default KV-cache cost is not universal. MHA/GQA structure, layer count, KV heads, head dimension, cache dtype and serving engine can change it substantially. Adjust the KV GB/1k-token input for the exact architecture.
Basic weight math is parameters(B) × bits / 8 ≈ GB, but that is only the starting point. The tool adds format overhead, runtime/headroom and adjustable KV-cache cost. Validate the estimate against model config and real `nvidia-smi` measurements.
Basic weight math is parameters(B) × bits / 8 ≈ GB, but that is only the starting point. The tool adds format overhead, runtime/headroom and adjustable KV-cache cost. Validate the estimate against model config and real `nvidia-smi` measurements.
Estimate LLM VRAM from parameter count, weight bits, context, KV cache and concurrency. See the transparent formula, add headroom and estimate a GPU memory class.
Parameter count and precision give a first weight-memory estimate.
Cache memory grows with context and concurrent sequences.
Editable starting reserve for runtime and fragmentation.
Validate production decisions with peak `nvidia-smi` and load tests.
Billions of parameters × bits per parameter ÷ 8 gives a rough decimal GB estimate. Actual file and VRAM usage differs with quant metadata, tensor packing and runtime.
| Example | Raw weights |
|---|---|
| 7B @ FP16 | ≈ 14 GB |
| 7B @ 8-bit | ≈ 7 GB |
| 7B @ 4-bit | ≈ 3.5 GB |
| 70B @ 4-bit | ≈ 35 GB |
Group scales, zero points, codebooks and tensor metadata can increase effective bits per parameter. The calculator adds a modest format overhead.
Decoder attention stores key/value state for previous tokens. Memory scales roughly with layers, KV heads, head dimension, dtype, token count and number of sequences.
Memory depends on how many sequences the serving engine keeps active, not how many users are merely connected or logged in.
| Concept | Meaning |
|---|---|
| Connected users | Users connected to system |
| Queued requests | Waiting for GPU |
| Active sequences | Active generations consuming GPU/KV |
Temporary tensors, CUDA graphs/kernels, allocator fragmentation and context spikes can trigger unexpected OOM. Leave margin above measured peaks.
Tensor parallelism can shard weights, but PCIe/NVLink communication affects throughput and latency. Two 24 GB GPUs are not equivalent to one 48 GB GPU.
nvidia-smi topo -mnvidia-smi --query-gpu=name,memory.total,memory.used,temperature.gpu,power.draw --format=csvLoad the exact model in the target serving engine at target context/concurrency and record idle weights, warmup peak and load-test peak separately.
| Stage | Record |
|---|---|
| Model load | Idle VRAM |
| Warmup | Kernel/graph peak |
| Max context | KV growth |
| Target concurrency | Peak + p95 latency |
Transparent estimate: weights + runtime reserve + KV cache. Adjust KV cost for the exact model architecture.
On Eka Sunucu GPU infrastructure, benchmark the 24/32/48/80+ GB class suggested by the calculator using your exact model, context and concurrency.
Primary documentation and technical references used by this guide.
Continue with related infrastructure and implementation guides.
LLM VRAM Calculator
Raw weights are roughly 35 GB; format overhead, runtime and KV cache raise the real serving requirement. Use the calculator with target context/concurrency.
Raw weights are around 16 GB; it may fit in many formats, but context, concurrency and runtime headroom determine viability. Test the exact model.
KV-cache cost varies significantly by architecture. A universal constant creates false precision, so the field is editable for model-specific estimates.
No. The model can only be sharded if the serving engine supports multi-GPU execution, and interconnect/tensor-parallel overhead affects performance.