Methodology

●From the file

A fact, not a calculation. File sizes are the bytes of the actual published files added up; cache sizes come from the model's own architecture. If this is wrong, the source is wrong.

◍Benchmarked

Somebody ran it and wrote down the result. Not us — these come from public benchmark threads, reproduced with a link to the original. We aggregate them and have not rerun them.

○Spec sheet

What the manufacturer publishes. Memory bandwidth, capacity, throughput. Theoretical peak, which no real workload reaches.

◐Predicted

Our prediction, never an observation. Always carries a ± figure, and that figure is how wrong we have actually been against real benchmarks — not a guess at our own accuracy.

⚠Rough guess

A fallback we could not avoid. Rare, and flagged rather than quietly mixed in with everything else.

We read the file listing for each quantization repository and sum the byte sizes of its files, including every shard. We never multiply a parameter count by a bits-per-weight constant. The nominal rate for a quantization is not what the file weighs: a Q4_K_M is a mixture, with attention and output tensors held at higher precision, so its effective rate is consistently above the nominal one. We publish the effective rate we measured, not the label.

The common formula multiplies context by layers by KV heads by head dimension. It is wrong for three families of architecture, and the errors are large:

• Sliding-window attention. Most layers cache a fixed window rather than the whole context. We resolve the window period the way llama.cpp does — the value in the model file wins, and a per-architecture default applies only when the file omits it. A period of zero means every layer is windowed, not none.
• Multi-head latent attention. These models allocate no V cache at all, and the K cache stores a latent projection. Reading num_key_value_heads from the config and multiplying overstates the result by well over an order of magnitude.
• Declared-but-unused windows. Some models ship a sliding window alongside a flag that disables it. Honouring the field without the flag understates the cache for an entire model family.

Token generation is bound by memory bandwidth: each token requires reading the weights that participate in it. We divide bytes-read-per-token by achievable bandwidth and add a fixed per-token overhead, with both constants fitted separately per backend from public benchmark sets. Mixture-of-experts models read only their routed experts, so their bytes-per-token is far below their resident size — and because few have been publicly measured, they carry a visibly wider band.

We do not assume a constant fraction of peak bandwidth. That assumption is what most estimates use, and it degrades badly at the high end, because a fixed per-token cost dominates as the memory term shrinks.

The point of an error band is that it can be checked. We score our predicted generation speed against measured runs harvested from public benchmark threads — the same numbers, on the same hardware, produced by people with no connection to us — and publish the result whether or not it flatters us.

Read the median as the typical case and the 90th percentile as the warning. Half our predictions land within about 7% on consumer hardware and 4% on Apple Silicon. The tail is longer on AMD and on datacenter cards, where we have fewer runs and more variety of configuration. The bands shown throughout the site are these measured figures, not the residual of the fit that produced the underlying constants — that earlier number described how well the curve matched the small dataset it was built from, which is not the same question.

The tail is real, not noise. Harvested runs carry conditions we cannot see: power limits, thermal throttling, background load, different flash-attention settings, and firmware differences between cards sold under one name. Some of that is genuine model error and some is measurement variance, and we cannot yet separate them — which is itself an argument for measuring under controlled conditions ourselves rather than only borrowing.

• Exact total VRAM.Weights are exact and the KV cache is computed from the architecture, but the runtime's working buffers are neither. There is no closed form for them. Ours is a structural model — it scales with feed-forward width, with micro-batch, and with context where flash attention is off — but its constants are chosen rather than fitted against measured allocations, and it is the widest error band on the site. It is why a total carries a band when its parts do not. The proper fix is to have llama.cpp simulate the allocation from file metadata and report the real figures, which we have not built yet.
• Usable memory on hardware without a published ceiling. Where a device documents an allocation limit we use it directly. Everywhere else we apply a fixed fraction of nameplate capacity for driver overhead. That fraction is ours and unsourced.
• Measured speed of our own. Where a figure is marked Measured it was measured by someone else and is reproduced here with attribution — we have not verified those runs, and we aggregate them into a median with a spread rather than quoting any single one. Everything we compute ourselves is modeled, and shows a band rather than a confident number.
• Multipliers against named competitors. We publish what a flat formula computes next to what the architecture actually requires. We do not attribute that flat figure to a specific site unless we have queried it.
• Speed for non-text modalities. Image, video and speech memory is derived from real component sizes, but throughput on consumer hardware is not something any public source has measured, and we will not invent it.

Model metadata and file sizes come from the Hugging Face Hub. Accelerator specifications come from Wikipedia (CC BY-SA 4.0) with a hand-curated override layer for parts it covers poorly. Architecture behaviour is mirrored from llama.cpp (MIT) and checked against upstream automatically. We deliberately use no GPU specification database whose terms forbid reuse, and no dataset derived from one. Our own derived data is published under CC BY 4.0.