LLM model size calculator

What eleven repos actually store

The census counts 7,248,023,552 stored parameters in mistralai/Mistral-7B-Instruct-v0.3 and 7,217,189,760 in tiiuae/falcon-7b. Neither is seven billion.

Every row below is the Hub tensor census, with the dtype it reports for that repo. The last two columns come from the exact count, so you can see how far the friendly label sits from the file.

Where the card and the census disagree

Microsoft's card for phi-2 calls it a Transformer with 2.7 billion parameters (model card). The census counts 2,779,683,840 stored weights, all in F16.

Round that the way the card rounds and you land a tenth of a billion higher. The two do not agree. Both stay on this page, because picking one and quietly dropping the other is how a reader ends up short on disk.

Qwen3-8B goes the other way. Its card gives 8.2B (model card) and the census count of 8,190,735,360 rounds to the same figure. That card also reports a non-embedding count below the census total, so the token embedding and the output head carry the rest.

Mixture-of-experts repos need a second look. The card for Qwen3-30B-A3B gives 30.5B total and 3.3B activated per token (model card), while the census counts 30,532,122,624 stored parameters.

What you download tracks the stored count, not the activated slice. And allenai/OLMoE-1B-7B-0924 stores 6,919,161,856 parameters, closer to the second number in its name than the first.

Measured GGUF builds beat nominal bit widths

A GGUF file encodes the tensors plus a standardized set of metadata (Hub docs). Safetensors stores tensors with zero-copy loading (safetensors docs). So a GGUF download carries more than the weights.

Hugging Face documents Q4_K as 4-bit quantization whose super-blocks also store a block scale and a block minimum, "resulting in 4.5 bits-per-weight" rather than 4 (Hub docs).

The k-quants pull request adds that the Q4_K_M mixture keeps half of the attention.wv and feed_forward.w2 tensors at Q6_K (pull request).

Divide a measured file by its census parameter count and the effective width lands above the nominal one every time. The last column prints that division.

Q8_0 is 8-bit round-to-nearest with a per-block scale, listed as a legacy method (Hub docs). Its measured rows still sit above eight bits per weight.

Weights only, and what sits on top

Every figure here sizes the weights. A model in service also holds a KV cache that grows with context length and batch size, the activations for whatever is in flight, and whatever the framework, CUDA build and driver reserve.

So a checkpoint whose weights fit your card can still run out of memory on the first long prompt. That is why the calculator above has no accelerator-memory box and no headroom column.

Weights alone cannot answer that, and a number that pretends otherwise is worse than none. For the rest of the budget, use the GPU memory calculator.

Doing it yourself in Python

The census is one request away and the arithmetic is a multiplication.

import requests

url = "https://huggingface.co/api/models/Qwen/Qwen2.5-7B-Instruct?expand[]=safetensors"
sf = requests.get(url, timeout=30).json()["safetensors"]

stored = sf["total"]        # parameters the repo actually stores
bytes_per_param = 2         # BF16, per the repo's own config.json
print(stored, stored * bytes_per_param)

How we measured this

Primary source for every parameter count is the Hugging Face Hub tensor census, the safetensors expansion of the model API, which reports the stored tensor count per dtype.

Quantized sizes come from the recursive file listing of the bartowski GGUF repo for each model. A row is the size of a file you can download, not a prediction of one. Figures were verified on 6 August 2026.

The cross-check runs through the repo's own files. The shard index for Qwen2.5-7B-Instruct declares a metadata.total_size, and its config.json declares torch_dtype bfloat16, two bytes per stored parameter.

Multiply the census count by two and the index total is what you get.

Model cards give the second check for phi-2, Qwen3-8B and Qwen3-30B-A3B. Where a card and the census differ, both figures stay on the page.

Derived figures come from those inputs. Gibibytes from the byte count. Effective bits per weight from measured bytes divided by the census parameter count. No value on this page was typed from memory.

I maintain the shape calculators on heytensor.com, which compute output shapes in the browser and never send an architecture, an error string or a parameter to a server. Same rule here.

The model list, the census counts and the GGUF sizes ship with the page, and the arithmetic happens on your machine.