Methodology

1. The fit formula

A model fits when everything it needs in memory fits inside your usable memory pool:

required = weights + KV cache + activations + runtime overhead
pool     = VRAM − runtime base allocation          (discrete GPUs)
         = memory × GPU-addressable fraction − base (unified memory)

• Weights — the measured size of the actual quantized file (e.g. the GGUF on Hugging Face), not a params-times-bits formula. Measured beats derived whenever we have it.
• KV cache — computed from the model's real attention config: 2 × layers × context × KV heads × head dim × 2 bytes (fp16). Models with MLA, sliding-window, or hybrid attention use their own branch of the formula and carry a beta label until validated.
• Activations + overhead — a small scratch-buffer term plus a fixed runtime overhead constant, calibrated conservatively.
• The pool — for discrete GPUs, VRAM minus what the runtime itself allocates at startup. For Macs and unified-memory mini-PCs, total memory times the GPU-addressable fraction (macOS and the mini-PC firmware don't let the GPU take everything), minus the same base allocation.

Worked example: RTX 4090 × Qwen2.5-32B-Instruct (Q4_K_M, 8K context)

Note what the honest answer looks like: 95.8% of the pool is Tight, not “fits”. It loads and runs well — but a longer context or anything else using VRAM pushes it over. Most calculators would round this to a clean yes. Run this exact check yourself.

2. Why speed is a tier, not a number

Internally we compute a bandwidth-roofline estimate — decode speed on a single request is dominated by how fast the hardware can stream the model's active weights through memory. But publishing that estimate as “42 tok/s” would be fake precision: the real number moves with runtime version, drivers, quant kernel, batch size, and thermals. A tier survives a stopwatch; a number does not.

The unified-memory mini-PC class is the sharpest argument for tiers. An NVIDIA DGX Spark (128 GB unified, ~273 GB/s bandwidth) fits a 120B-class MoE model — huge capacity — but that bandwidth caps single-request decode to a middling tier, while its prompt-processing (compute-bound, not bandwidth-bound) can land a tier higher. One headline number would mislead in both directions at once. The tier plus the stated assumptions — decode, batch 1, the exact quant — is the answer that stays true.

Same logic for multi-GPU: a second card raises the VRAM pool (run a bigger model) but with the default layer-split serving, a request still runs the layers sequentially — so the pool adds and the speed doesn't. We compute the two effects separately and never conflate them.

3. The grade thresholds — disclosed

The grade is the required-to-pool ratio against fixed, published thresholds. These are locked by tests in the codebase — they only change together with a test update, never silently.

Before any of this math runs, a hard compatibility gate checks that the quant format actually has a supported kernel on your hardware's backend — an AMD card on a CUDA-only path is a “no” regardless of VRAM, and gated results carry no misleading numbers at all.

4. What “beta” means

A beta badge means the fit verdict is solid (it's physics) but the speed tier for that regime hasn't been calibrated against enough real-world measurements yet, so it carries wider error bars. We show the label instead of pretending. The beta regimes:

• AMD Radeon and Intel Arc discrete GPUs (ROCm / Vulkan paths) — performance is volatile across driver and runtime versions
• The unified-memory mini-PC class (DGX Spark, Strix Halo boxes) — new hardware, few verified measurements exist anywhere
• MoE models — expert routing makes decode speed estimates carry wide error bars
• CPU offload — speed varies heavily with how many layers spill to RAM
• MLA, sliding-window, and hybrid attention — the KV-cache formula branches are implemented but not yet validated against measurements

A single fast result on a nightly driver build never promotes a tier — calibration requires reviewed, verified submissions across versions.

5. Data sources and stamping

• Model architecture — layer counts, KV heads, head dims, context limits read from each model's config.json on Hugging Face.
• Quantized file sizes — measured from the actual published artifacts (GGUF repos on Hugging Face), not estimated.
• Hardware specs — VRAM, memory bandwidth, TDP from TechPowerUp and vendor spec sheets; every row links its source.
• Prices — MSRP from vendors; used prices from market listings. Dated, because a dated real number beats a fresh made-up one.

Every row in the dataset carries a source_url and an as_of date. The current data snapshot is 2026-07-11. AI tooling may polish our prose; it never generates the facts — every number traces to a source or a formula on this page.

6. What we do not model — yet

Published so you can decide whether a verdict applies to your setup:

• Batching — every tier assumes batch 1 (one request at a time), the single-user case
• Speculative decoding — draft-model speedups are not modeled
• Tensor-parallel speedups — a second GPU adds VRAM in our math (layer-split), never speed
• KV-cache quantization — we assume fp16 KV; Q8/Q4 KV options would shrink the cache and aren't modeled yet
• Prompt-processing speed — tiers describe decode (generation) speed only
• Thermals, power limits, and background load on your machine

7. The error-bar commitment

Estimates should be falsifiable. As verified real-world submissions accumulate, we will calibrate the tier model against them and publish our median error on this page — including where we were wrong. Submissions are reviewed before they influence anything (our anti-poisoning policy), and until a regime has enough verified data it keeps its beta label.

Ran a model we got wrong? Use the submission form under any result — hardware, model, quant, and runtime come pre-filled; you add the measured tokens-per-second.