How we calculate memory requirements

Every number on this site is computed from real, published data — never estimated from a rule of thumb, and never invented by a language model. This page explains exactly how, so you can check our work.

1. Model weights come from the actual files

For any model, we read the real file listing of its repository from the model hub's API and sum the byte sizes of the published GGUF shards, grouped by quantization (Q4_K_M, Q5_K_M, IQ2_XXS and so on). A quantization that ships as several split files is added back together. We deliberately exclude files that are not a runnable model — the importance-matrix (imatrix) file used during quantization, and the multimodal projector (mmproj) — because counting them would understate the smallest usable size.

The number of parameters is read from the repository's safetensors metadata when available, not guessed from the model name.

2. The KV cache is computed from the real architecture

Running a model needs memory for more than its weights: the KV cache holds the attention keys and values for every token in your context. We compute it from each model's own config.json — layer count, attention heads, key/value heads and head dimension — rather than a generic formula. That matters because modern architectures differ enormously:

• Grouped-query attention (GQA): fewer key/value heads than query heads, so the cache is already smaller than classic multi-head attention.
• Hybrid attention: only some layers keep a full KV cache; the rest use linear attention with a constant-size state. We count only the full-attention layers, so we don't overstate long-context memory.
• Multi-head Latent Attention (MLA): a single compressed latent is cached per layer instead of keys and values per head. We size the cache from the latent rank, not the head count.

When a quantized repository doesn't ship a config.json, we follow its declared base_model to read the original architecture. If the architecture genuinely can't be determined, we say so on the page rather than printing a confident-looking guess.

3. Total memory and the verdict

The total we show is weights + KV cache at your chosen context + a system margin for the runtime, framework and OS overhead. We then compare that total against your VRAM (and RAM) to produce one of three honest verdicts:

• Fits in VRAM — the model runs entirely on the GPU.
• Runs with offload — part of the model spills to system RAM; it works, but more slowly.
• Insufficient — it doesn't fit in VRAM and RAM combined.

4. What is an estimate — and what isn't

File sizes, parameter counts and KV-cache math are exact, derived from published data. The one number we label as an estimate is inference speed: real throughput depends on your specific GPU, driver, quantization kernel and settings, so we only give a rough figure bounded by memory bandwidth. We mark it as an estimate wherever it appears.

Why we do it this way

Plenty of "will it run" advice online is copied, out of date, or made up. Our rule is simple: if we can't ground a claim in the actual files and configuration a model publishes, we don't print it. That's the whole point of the site — an answer you can trust because you can check it.

Spotted a number that looks wrong? We want to know. Tell us and we'll investigate.