How much GPU memory does an LLM need?
Start with parameter count multiplied by bits per parameter. Then add capacity for runtime overhead, activations, and the KV cache. A weight-only estimate is a lower bound, not a production guarantee.
Instrument 09 / GPU fit
Turn parameter count, weight precision, architecture-aware KV cache, runtime headroom, and usable VRAM into a transparent minimum-GPU estimate.
Size one deployment
This is an early inference estimate, not a benchmark. Nothing is submitted or stored; every calculation runs in this browser.
Sizing boundaries
Weights are the floor.
A file fitting in VRAM does not prove the serving workload fits.
Context consumes memory.
KV cache grows with architecture, sequence length, batch size, and concurrency.
Profile the runtime.
Tensor parallelism, kernels, and quantization formats add deployment-specific overhead.
Transparent method
Weight memory uses the exact checkpoint size when you provide one. Otherwise, it multiplies total parameters by bits per parameter, divides by eight, and converts bytes to GiB. It deliberately uses total parameters for sparse models because inactive experts still have to be stored unless the deployment explicitly offloads them.
KV-cache memory is 2 × layers × KV heads × head dimension × context tokens × concurrent sequences × bytes per KV element. The factor of two stores keys and values. Sliding-window, chunked, quantized, offloaded, or shared-prefix caches need runtime-specific treatment.
Planning target adds the runtime headroom you choose after weights and any explicit KV cache. Hugging Face's model memory estimator describes weight loading as a floor and notes that inference can require additional memory. Use measured runtime data instead of the default once you have it.
Minimum GPUs divides the planning target by usable VRAM per GPU and rounds up. This capacity check does not promise throughput, latency, interconnect efficiency, or compatibility with a particular tensor-parallel configuration.
Quantized formats can include scales, metadata, and higher-precision modules. The calculator therefore treats bit width as a planning input, not a guarantee that every 4-bit or 8-bit artifact occupies exactly the same amount of memory.
GPU sizing guide
Memory fit is necessary, but it is only the first gate. Validate the exact model artifact, context window, batch profile, serving runtime, and hardware topology.
Compare 70B INT4, INT8, and FP16 scenarios → Compare Qwen3 dense and MoE memory targets → Calculate KV-cache memory and GQA savings → Read ResearchAudio's GPU architecture guide → Check the Hugging Face model memory estimator → Review current Transformers KV-cache strategies → Review current Transformers quantization support →Start with parameter count multiplied by bits per parameter. Then add capacity for runtime overhead, activations, and the KV cache. A weight-only estimate is a lower bound, not a production guarantee.
At 16-bit precision, 70 billion parameters require about 130 GiB for weights before inference overhead. The final GPU count depends on usable VRAM per device, quantization, context length, concurrency, and the serving runtime.
Lower-bit formats reduce weight memory, but real artifacts can also store scales, metadata, and some modules at higher precision. Treat the bit-width result as an estimate and check the actual model artifact.
Yes, when you provide layers, KV heads, head dimension, context length, concurrent sequences, and KV precision. Leave the architecture fields at zero for a weight-plus-headroom floor.
The deployment behind the benchmark
ResearchAudio turns model releases, hardware claims, and rate cards into practical decisions for engineers and builders.