Methodology

Does it fit?

A model loads if its weights plus headroom clear usable memory. Usable memory is less than nameplate memory: Apple silicon shares one pool with the OS and display and holds back roughly a quarter by default, while a discrete card gives up a smaller slice to the driver, framebuffer and allocator fragmentation.

usable  = memoryGB × 0.75 (Apple) or 0.92 (discrete)
needed  = weightsGB × 1.15
fits    = needed ≤ usable

The 1.15× factor covers KV cache, activations and allocator slack at a moderate context length. It is a "does this load at all" threshold, not a promise about 128k tokens — a long context can easily add tens of gigabytes beyond this.

Decode speed — the number you feel

Generating one token requires reading every active weight out of memory once. That makes single-stream decode bandwidth-bound, not compute-bound, which is why bandwidth tracks the felt speed of a machine far better than TFLOPS does.

decode = efficiency × bandwidthGBs ÷ activeGB

Efficiency is 0.65 for dense models and0.42 for mixture-of-experts. MoE scores worse because the active experts change from token to token, so reads are scattered rather than sequential and prefetching helps less.

Prefill speed — and the constant to argue with

Processing a prompt is compute-bound, at roughly two floating-point operations per active parameter per token. But nobody reaches nameplate TFLOPS, and how close you get depends on the vendor's software stack rather than its silicon.

prefill = softwareEfficiency × tflopsFP16 × 10¹² ÷ (2 × activeParamsB × 10⁹)

This is the most contestable table on the site. It encodes software maturity, not hardware: CUDA is years ahead, Metal is improving quickly, ROCm and oneAPI trail, and the startup stacks are early. These numbers will age, and prefill figures move proportionally when they do. If you have measurements that contradict them, I would rather publish yours than defend mine.

Batched throughput

Serving several sequences at once amortizes one weight read across all of them, so aggregate throughput rises — until compute runs out. Headroom is capped at8× and realized at 60%, which deliberately lands under measured vLLM throughput rather than over it.

headroom = clamp(prefill ÷ decode, 1, 8)
batched  = decode × (1 + (headroom − 1) × 0.6)

The calculator uses a sharper model

Everything above drives the comparison table, where context is folded into that flat1.15× factor. The calculator does better: it sizes the KV cache from each model's real attention geometry, read out of its publishedconfig.json and cited on every entry.

MHA / GQA:  2 × layers × kvHeads × headDim × ctx × kvBytes
MLA:        layers × (kvLoraRank + qkRopeHeadDim) × ctx × kvBytes

That cache is then charged against both memory and bandwidth, because attention re-reads all of it for every token generated:

decode = efficiency × bandwidthGBs ÷ (activeWeightsGB + kvCacheGB)

This is why a machine that feels quick at 4k can crawl at 128k, and why DeepSeek-V3 — a 671B model — has a smaller cache than a 70B dense one. At zero context the two models agree; above it the calculator is the more accurate of the two, and where they disagree, trust the calculator.

Prices and independence

Prices were captured Aug 31, 2026 and change constantly; the price at the retailer at the time of purchase is the one that applies. Some links earn a commission and are marked as paid links; vendor-direct links earn nothing.

Ranking is computed, not chosen. Every machine goes through the formula above, sort order comes from whichever column you click, and products that pay nothing sit in the same table as products that do. If a commission ever changed a number here, the formula would stop being reproducible — which is the whole value of publishing it.