What an LLM checkpoint actually weighs on disk

By Michael Lip. Figures verified 2026-08-22.

Qwen2.5-7B-Instruct stores 7615616512 parameters across its safetensors shards, and the community Q4_K_M build of the same model measures 4683074240 bytes as one file. Both figures are read out of the repositories rather than estimated from a bits-times-parameters shortcut. Pick a repository below and the page divides one by the other, so you can see what a weight really costs in the file you are about to download.

Stored parameters against the label on the model card

The census column below is what the Hub counted by reading each safetensors header. The card column is what the model card says about itself. Read across a row and you can see where the round marketing label and the file disagree.

Card labels and the census disagree, and phi-2 shows it plainly

The phi-2 card calls the model 2.7 billion parameters. The Hub census for the same repository counts 2779683840, which does not round to the card's figure. Neither number is wrong on its own terms, and the page gives you both rather than quietly picking one. Qwen goes the other direction and publishes Number of Parameters: 8.2B on the Qwen3-8B card instead of the round label sitting in the repository name, against a census of 8190735360. When you are provisioning disk, the census is the figure that matches what lands on it.

Measured GGUF builds, byte for byte

Each row is a real file in a public repository, not a projection. The last column divides the file size by the stored parameter count of the original checkpoint, so it covers everything the GGUF carries.

Why a four-bit build is not four bits per weight

The overhead starts in the block format itself. ggml documents its Q4_K super-block as Effectively 4.5 bits per weight, with Q5_K described as Effectively 5.5 bits per weight and Q6_K as Effectively 6.5625 bits per weight. A Q4_K block covers QK_K weights and stores QK_K/2 bytes of packed quants next to a K_SCALE_SIZE scale array and a pair of half-precision super-block scales. Q8_0 is the plainest case of the same tax, since a block covers QK8_0 weights in sizeof(ggml_half) + QK8_0 bytes, which sits above eight bits per weight rather than at eight.

Then the quantizer refuses to treat every tensor the same. llama.cpp promotes selected attn_v.weight tensors to Q6_K when the requested file type is Q4_K_M or Q5_K_M, and it handles token_embd.weight and the output weight as separate cases with their own type selection. For Falcon models, and for any tensor whose row length is not a multiple of the super-block size, the quantizer falls back to Q8_0 for that tensor. The tool even exposes flags to leave output.weight un(re)quantized or to override its ggml_type. And the codebase names these file types MOSTLY_Q4_K_M, which is the honest part of the name. Building one takes two passes: convert the original model to GGUF, then quantize that file starting from a high-precision F32 or BF16 input.

Where a mixture-of-experts checkpoint spends its bytes

Qwen3-30B-A3B lists Number of Parameters: 30.5B in total and 3.3B activated and, on the same card, Number of Activated Experts: 8. The census counts 30532122624 stored parameters, so the number your disk sees tracks the total rather than the activated slice. OLMoE-1B-7B-0924 tells the same story at a smaller scale, described on its card as a Mixture-of-Experts LLM with 1B active and 7B total parameters against a census of 6919161856. Budget storage from the total, and budget compute from the activated figure.

What the census is actually counting

A safetensors file opens with a little-endian header length followed by a JSON header recording each tensor's dtype, shape and data_offsets, which is what makes an exact per-repository tensor census possible without downloading a single weight. On the GGUF side, the Hub's authoritative size for an LFS-backed file is the X-Linked-Size response header the official huggingface_hub client reads. GGUF itself is the binary format for storing models for inference with GGML, and the quantization scheme rides in the filename as the Weight Encoding Scheme component, for example Q4_K_M.

How we measured this

Primary source for every parameter count is the Hugging Face Hub API with the safetensors expansion, which reports the tensor census the Hub computed from each shard header. The independent cross-check is the shard index file in the same repository: for Qwen2.5-7B-Instruct and for phi-2 alike, metadata.total_size comes out at twice the census, which is what a two-byte-per-parameter checkpoint should look like. For GGUF builds the primary source is the repository file listing and the cross-check is a HEAD request against the CDN download URL, where the returned X-Linked-Size matches the listing. All figures were verified on 2026-08-22. Nothing here is typed by hand. Sizes are injected from validated fields at build time and every ratio is recomputed in your browser from those same values, which is the same rule the shape calculators on this site follow.

I build heytensor.com and the Zovo Tools network of free, privacy-first developer utilities. The shape calculators there compute output shapes entirely client-side and validate every formula against the official torch.nn documentation, and parameter counts are cross-checked against an independent source before anything is published. A figure two sources do not agree on is held back, not shown, which is exactly why the phi-2 row above prints both numbers instead of one.

Weights only, and what that leaves out

Every byte on this page is weights sitting on disk. A model in service also needs a KV cache that grows with context length and batch size, activation memory for the forward pass, and whatever the framework, CUDA build and driver reserve before your tensors ever land. Do not read these figures as an accelerator fit check, because a reader who treats a weights-only number as headroom runs out of memory. For the rest of the budget, use the training memory tool.