LLM VRAM calculator

Enter the total parameter count and choose an attention architecture, weight format and KV-cache format. See estimated memory and the context that fits your available VRAM.

Inputs
Presets supply attention dimensions only. Enter the total parameter count separately.
Illustrative 7 billion, not an exact model count. Include all MoE experts.
Optional for every format. Use total tensor bytes × 8 ÷ parameter count to override the estimate; recipe averages vary by architecture.
Prompt plus generated tokens; full cache allocation assumed.
Independent sequences, not prompt processing microbatch size.
User assumption, not a measured requirement. Covers buffers, activations and other allocations.
Use usable capacity after other applications. GPU labels often say GB; check reported bytes.

Results

Estimated total memory
15.309 GB / 14.257 GiB
Weights
13.039 GiB (16 bits/weight)
KV cache
0.219 GiB
Maximum context per sequence by memory
186,524 tokens
Illustrative GPU capacity tiers (GiB; often marketed as GB)
CapacityEstimated fit
8 GiBDoes not fit
12 GiBDoes not fit
16 GiBFits estimate
24 GiBFits estimate
32 GiBFits estimate
48 GiBFits estimate
80 GiBFits estimate
  • Attention: 28 layers, 3584 hidden, 28 attention heads, 4 KV heads, head dimension 128. Overhead reserved: 1 GiB.
  • Memory-only ceiling, not a supported context limit or a guarantee of successful loading. Runtime padding and scratch buffers vary.
  • Inference only; full GPU residency of all weights (including all MoE experts). No optimizer, CPU offload, sliding-window or latent-attention model.
  • Q2_K, Q3_K_M, Q4_K_M and Q5_K_M use approximate Llama-3.1-8B recipe averages; architecture and quantizer options change these. Q6_K uses pure block storage including scales. Measured bits override either estimate. FP8/INT8 assume packed one-byte weights; add scale overhead.

Results update as you type. The share link stores your inputs after the # in the address, which is not sent to our server, but anyone you send it to can read them.

How it works

Weights are total parameters × average bits per weight ÷ 8. Parameter counts are entered in billions. The architecture presets supply only attention dimensions from the official config files. The initial 7 billion parameters and 1 GiB overhead are illustrative user assumptions, not measured model requirements.

KV bytes = 2 × layers × KV heads × head dimension × context × concurrent sequences × bytes per cache element Total bytes = weight bytes + KV bytes + reserved overhead Max context = floor((available bytes − weights − overhead) ÷ KV bytes per context token)

The factor 2 represents keys and values, cached independently per layer as described in Transformers’ cache documentation. Context includes both prompt and generated tokens. GQA uses KV heads, not query heads. Enter the explicit head_dim from custom model configs; hidden size ÷ attention heads is only a fallback when the architecture defines it that way. Qwen3-4B, for example, uses head dimension 128 despite hidden size 2,560 and 32 attention heads. Maximum context is a memory-only ceiling and is not capped to a model’s supported positional range. If weights plus overhead exceed capacity, no context fits.

The ggml structures include block scales: Q2_K uses 2.625 bits per weight, Q3_K 3.4375, and Q6_K 6.5625. These pure block sizes are not whole-model recipe averages. The Q6_K selection uses pure block storage. The Q2_K, Q3_K_M, Q4_K_M and Q5_K_M selections instead use approximate Llama-3.1-8B benchmark averages of 3.1593, 3.9960, 4.8944 and 5.7036 bits per weight, respectively, from llama.cpp. They depend on architecture and quantizer options. Any format can use a measured override. q8_0 cache uses 34 bytes per 32 elements; q4_0 uses 18 per 32. Block padding may increase actual memory.

GB means 1,000,000,000 bytes; GiB means 1,073,741,824 bytes. GPU comparison rows are illustrative capacity tiers in GiB. Calculations retain intermediate precision. Displayed memory rounds to three decimals and context rounds down. The overhead reserve is fixed for this estimate; actual scratch memory can grow with context and workload.

Worked examples

Illustrative 7 billion weights with Qwen2.5-7B attention dimensions

FP16 weights occupy 14,000,000,000 bytes. With 28 layers, 4 KV heads, head dimension 128, context 4,096 and one sequence, FP16 cache uses 234,881,024 bytes (0.21875 GiB). Add a user-assumed 1 GiB reserve: total 15.309 GB, or 14.257 GiB.

Block quantization and a memory-only context ceiling

For the same illustrative 7 billion weights, Q6_K uses 5,742,187,500 bytes. q8_0 cache at 4,096 tokens uses 124,780,544 bytes. Including 1 GiB overhead, total is 6.941 GB, or 6.464 GiB. An 8 GiB capacity allows a memory-only maximum of 58,232 tokens per sequence; model context support must be checked separately.

Frequently asked questions

Why is Q4_K_M not exactly four bits per weight?
Scales take space and the M recipe uses different quantization types for selected tensors. The actual average depends on architecture and quantizer options. Q4_K_M and Q5_K_M work without measurements using approximate Llama-3.1-8B reference averages of 4.8944 and 5.7036 bits per weight. For a measured override, enter total tensor bytes × 8 ÷ total parameter count; raw GGUF file size also includes metadata, so it is only a proxy.
Does a model that fits this estimate definitely run?
No. Runtime kernels, cache padding, temporary buffers, graph allocation and other applications consume memory. Set overhead using measurements from your runtime and use available memory rather than advertised capacity.
How does batch size affect the cache?
Concurrent independent sequences multiply cache storage. Two equally long sequences use twice the cache of one in this model. Weights are shared. This input is not the runtime’s prompt-processing microbatch size.
Can I use this for MoE or training?
For full-residency MoE inference, enter all parameters across all experts, not only the active experts. The attention dimensions must match the model. Training, optimizer state, partial offload, sliding-window attention and compressed latent caches are outside this estimate.
Can every runtime use q4 or q8 KV caches?
No. Support depends on the runtime, kernels and model. Here q4 and q8 specifically mean ggml q4_0 and q8_0 block storage for both K and V. Their scale bytes are included.

Sources

Last reviewed 2026-11-14; next review due by 2027-02-12. The method is written out above so you can check our math.