Quantization precision × batch size, bitsandbytes engine. Generated from the published data, not hand-maintained.
Every EcoCompute number so far was taken at batch 1. That is not a rounding detail: batch size changes how busy the GPU is between decode steps, and utilisation is the thing that decides whether a quantized kernel pays for itself. So the whole right-hand side of this grid is unknown — including to us.
Counts are measurements, not sessions: a cell measured three times on the same card reads 3, and a configuration repeated five times contributes 5. FP16 is dense because every quantized run also measures its own FP16 baseline on the same card, and each baseline counts in its own right: 72 quantized measurements plus 72 baselines. The “42 rows” quoted elsewhere on this site counts distinct configurations, not repeats — same data, different unit. A quantized number with no same-session baseline cannot produce a ΔE% and is not counted at all. Contributors so far: @gkgoing, @hongping-zh.
Any of the four batch-4 cells. They need a card you already have and one parameter change, and they are the boundary between "we measured batch 1" and "we know what batch size does" — which is also the gap between this dataset and the large-batch datacentre leaderboards it cannot currently be compared with.
A submission counts once it carries an FP16 baseline from the same session on the same card, and a
schema-valid energy.json. Disagreements with the published curve are published on the same page as
confirmations.