No server, no AI, no guessing: one arithmetic function on this page answers “what will llama.cpp ask this hardware for, given this model and these flags?” It prices demand (bytes the engine reserves) against supply (the GPU / RAM / NVMe you type in). Memory is reserved by llama.cpp's allocator code before any GPU is touched — the same build asks the same bytes on a 3060 as on an H100, so your hardware never changes the equation, only the budget line.
Host RAM bill = offloaded experts (MoE) or -ncffn FFN layers (dense) + staged activations + anything -lm mlock / no-mmap commits. NVMe bill = the whole GGUF pack + tables — it is always on disk.
Weights and KV are exact counting — the KV pool sizes were verified to the MiB against llama.cpp's own llama_kv_cache: size logs. The compute-scratch prices are measured from llama.cpp's sched_reserve logs across a ladder of real model shapes; their error band is about −2% to +5%, which is exactly what the slack dial absorbs. Model shapes (layers, heads, windows, experts) come from the real GGUF metadata when you load a repo id.
All prices are calibrated on llama.cpp v0.6.0-dev · build 11429 — the linked version in the title, commit d812350. One GPU in the lab served as the measuring instrument; the card is not part of the result, the build is.
The GPUs field means "N cards, this much VRAM on every one". It deliberately does not model mixed-size rigs (say a 24 GB + a 12 GB card): with tensor parallelism every device holds its share of the same shapes, and those per-device reserves were only ever measured on equal cards — extrapolating to unequal VRAM would be guessing, and this tool would rather decline than lie. Two honest ways to bracket a mixed rig: set N to your card count with VRAM = the smallest card (the conservative wall, as if the small card carries an equal share), or N=1 with just the big card (as if the small one is decoration and the rest spills to RAM). llama.cpp can split by weight (--tensor-split) or hand-place tensors (-ot), but the per-device reserve cost of those splits is beyond what has been validated here — and whichever way you slice it, the slowest card sets the throughput.
llama.cpp's memory model moves between minor releases — pools, reserves and offload behavior get re-tuned. This page is re-verified and updated with every minor llama.cpp release, and the title always names the exact build the current prices were validated against. If you run a newer build than the one named here, treat the numbers as close, not gospel.
Scope: llama.cpp & GGUF only. It prices memory, never tokens/sec. Independent community tool — not affiliated with ggml.org or Hugging Face.