Why is the download a bit larger than parameters times bytes-per-weight?

The weight tensors dominate, but a repo also ships a tokenizer, a config file, a generation config, and for safetensors a small index that maps tensors to shards. It adds a few megabytes to tens of megabytes — negligible next to a multi-gigabyte model, but it is why the number is not perfectly round.

safetensors if you run on GPU with transformers, vLLM or TGI — it is the Hugging Face standard and loads memory-mapped. GGUF if you use llama.cpp, Ollama, LM Studio or run partly on CPU. GGUF is usually one file; safetensors repos are split into roughly 5 GB shards.

How much free disk should I actually keep?

More than the model. You often have the download and an extracted or converted copy at the same time, plus the KV cache and logs at runtime are on disk for some setups. Two to three times the model size is a safe working margin.

The download time looks optimistic.

It assumes your full line speed with no contention. Hugging Face and mirrors can be slower than your link, and many small requests for shard files add overhead. Treat it as a floor.

// storage

LLM Download Size & Disk Calculator

How much disk a model takes at a given quantization, how many files it splits into, and how long the download takes.

Model

QuantizationFile formatDownload speedMbit/s

On disk

4.5GB

Shard / file count

1files

Download time

0.1h

8.0B params × 0.604 B/param = 4.5 GB + metadata → 0h 6m at 100 Mbit/s

Presets verified 2026-09. Disk size ≈ the weight footprint plus a few MB of tokenizer/config. safetensors repos are split into ~5 GB shards; GGUF is usually one file (occasionally split for very large models). Leave headroom — you often keep the download and an unpacked copy at once.

notes

The maths

on disk        ≈ params × (bpw ÷ 8) + a few MB of tokenizer/config
shard count    ≈ ceil(weights ÷ 5 GB)   for safetensors
               ≈ 1                        for most GGUF
download time  ≈ on-disk bits ÷ link speed

Bits-per-weight is the effective figure including the small per-block scale: fp16 is 16, Q8_0 about 8.5, Q4_K_M about 4.83, Q2_K about 2.63.

Worked example

Llama 3.1 8B:

fp16 safetensors: 8.03e9 × 2 ≈ 15 GB, ~3 shards, ~20 min at 100 Mbit/s.
Q4_K_M GGUF: 8.03e9 × 0.60 ≈ 4.8 GB, 1 file, ~6 min at 100 Mbit/s.

Llama 3.3 70B at Q4_K_M ≈ 40 GB — one big GGUF file, about an hour at 100 Mbit/s, and you want ~100 GB of free space to work with it comfortably.

Notes

Presets carry a verified date. The size maths is exact; the download time assumes uncontended full-speed transfer and is a best case.

faq

Why is the download a bit larger than parameters times bytes-per-weight?: The weight tensors dominate, but a repo also ships a tokenizer, a config file, a generation config, and for safetensors a small index that maps tensors to shards. It adds a few megabytes to tens of megabytes — negligible next to a multi-gigabyte model, but it is why the number is not perfectly round.
safetensors or GGUF?: safetensors if you run on GPU with transformers, vLLM or TGI — it is the Hugging Face standard and loads memory-mapped. GGUF if you use llama.cpp, Ollama, LM Studio or run partly on CPU. GGUF is usually one file; safetensors repos are split into roughly 5 GB shards.
How much free disk should I actually keep?: More than the model. You often have the download and an extracted or converted copy at the same time, plus the KV cache and logs at runtime are on disk for some setups. Two to three times the model size is a safe working margin.
The download time looks optimistic.: It assumes your full line speed with no contention. Hugging Face and mirrors can be slower than your link, and many small requests for shard files add overhead. Treat it as a floor.