Where every number comes from

What we measure and why

A language model does two very different things with a document, and each one is limited by a different part of the computer.

The reference measurement

This is the only figure that is not an estimate: it was timed on a real card on 21 September 2026.

With those numbers, sorting a real electricity bill and pulling its data out (1,052 tokens in, 160 out) comes to about 0.9 seconds reading and about 4.1 seconds writing.

The formulas, as they are

Nothing is hidden. This is literally what the estimator calculates, in this order.

1 · Writing speed

Every token written means running through the model's active weights in memory (t_mem) and doing the associated compute (t_c):

t_mem       = active_weights_GB ÷ (bandwidth_GB/s × η)
t_c         = 1 ÷ prefill_tps
decode_tps(1) = 1 ÷ (t_mem + t_c)

With several requests at once the memory pass is shared between all of them, but the compute is not. That is why serving ten people gets far more done than serving one:

aggregate tokens/s (N requests) = 0.85 × N ÷ (t_mem + N × t_c)

The 0.85 is what real parallel processing gets against the ideal: with it, the model gives 240 t/s for an RTX 5090 on four requests, and the public vLLM measurement is 223 t/s. «Factory mode» uses the point beyond which adding requests barely helps —when compute weighs as much as memory— capped at 16 and at whatever fits in memory:

N (factory mode) = min( t_mem ÷ t_c , 16 , requests that fit in memory )

Careful: parallel only makes writing cheaper. Reading the document costs the same, so jobs with a lot of reading and little writing (sorting) gain less than jobs with a lot of writing (extracting, translating).

2 · Reading speed

Reading is compute-bound. Each input token costs roughly two operations per active parameter:

prefill_tps = κ × TFLOPS × 10¹² ÷ (2 × active_parameters)

3 · From speed to work

seconds/doc = input_tokens ÷ prefill_tps + output_tokens ÷ decode_tps
docs/day    = 86,400 ÷ seconds/doc

input_tokens and output_tokens come from the chosen job: an invoice to sort does not take the same room as a contract to audit.

How each card is calibrated

The two Greek letters in the formulas are what keep this from being wishful thinking.

• η (memory efficiency) — no card reaches its nominal bandwidth. This is the fraction actually used when running through the weights.
• κ (compute efficiency) — the same with TFLOPS: the fraction of theoretical power that ends up being used while reading.

Both are calibrated per card against public llama.cpp benchmarks (Llama 2 7B in Q4_0, the pp512 and tg128 runs), then corrected against the 3090 Ti anchor: if the model predicts the 3090 Ti with a given error, that same error is applied to the rest. A card with a public benchmark shows as MEASURED.

When a card has no public figure (new releases, unusual models), the typical values for its family and architecture are used, and the number is always marked ESTIMATED. A calculation is never presented as if it were a measurement.

Does the model fit?

Before talking about speed you have to know whether the model goes into the card. The weights alone are not enough: every context token of every simultaneous request takes memory in the KV cache.

memory needed = weights + KV cache(context × requests) + ~1.5 GB headroom

The headroom covers the compute buffer, what the system itself reserves and the desktop. If the total goes over the memory available, the ranking says so plainly: «does not fit, needs X GB», and it checks whether it would go in split across two or four identical cards.

Quantisation: which version of the model are we talking about

Saying «Qwen3.8 27B» on its own means nothing: the same model exists in several versions that take up room and perform differently. That is why on this site every model is named with its exact quantisation. Quantising is compressing: storing each of the model's numbers in fewer bits.

The reference measurement was taken with the 4-bit version (Qwen3.8-⁠27B-UD-Q4_K_XL.gguf, 17.55 GB): the one that fits in the 24 GB of an RTX 3090 Ti. At 8 bits it no longer goes in, and unquantised it needs more than 56 GB. When a model does not exist in the chosen quantisation, the site uses whichever it has and says so. The KV cache (the conversation's memory) is always calculated at 16 bits, which is the prudent figure; the measurement used it at 8 bits, which is why 64K of context fits.

How the rankings are sorted

Every sort comes from the same calculation; only the figure in charge changes. Cards that cannot hold the model always go last.

• Work a day: units of the job in 24 hours straight.
• Work per euro: units a day ÷ purchase price (with 2 cards, the price of both).
• Payback: price ÷ monthly saving against paying that same job to the same model's API, with the card at full tilt. If the API comes out cheaper than the electricity: «never pays off».
• Efficiency: units per kWh used. Electricity per 1,000: euros of electricity per thousand units.
• Writing / Reading: tokens per second generating and reading. Wait: seconds per unit on a single request.
• People: people on an eight-hour day who would do that same work. Price, memory, power: catalogue figures.

From tokens to people and to euros

People equivalent

Each job has a note of how many minutes a person takes to do it by hand (human_minutes). With an eight-hour day:

people_equivalent = (docs/day × human_minutes) ÷ (8 × 60)

It is an equivalence of volume, not a comparison of quality: it says how many people it would take to move that pile of paper, not that the result is as good.

Electricity cost

cost = W × seconds ÷ 3,600,000 × €/kWh

The real measured draw is used where there is one (361 W on the 3090 Ti) and the card's TDP where there is not. The default kWh price is indicative and can be changed. The rest of the machine is not counted: motherboard, processor, drives and fans add up separately.

Limits and small print

• OCR is not included. We assume the document is already text. Digitising a scanned PDF is a separate step with its own cost.
• Queues and start-up are not included. Loading the model, waiting your turn or retrying a failure are not counted. They are seconds or minutes that exist in real life.
• Quality is not measured. There is only speed here. A card writing 40 tokens a second says nothing about whether the model gets the invoice total right.
• Prices are indicative. They change every week, they depend on the second-hand market and they include neither tax nor the rest of the machine.
• Several cards = replicas. When 2 or 4 cards are counted, they are treated as independent copies processing different documents in parallel, not as one bigger, faster card.
• A physical model is not a test bench. The estimates get the order of magnitude and the relative comparisons right; the exact number for one specific card only comes from measuring it.
• Third-party data comes with its link. They are all below, one by one, so anyone can check them.

Sources

136 links, generated from the data catalogues themselves. If a figure is on this site, its origin is in this list.

See a figure that does not match your experience? You are probably right: measure your own card and compare. That is the whole point.