· 4 min read · Gaia Lab

Measuring quantized LLMs: what is lost when an open model is compressed

Almost 300 GGUF files from dozens of families, served with llama.cpp and scored on function calling, code and long context, with speed and energy per card. The line that reserves the most GPU-hours trains nothing: it measures what each quantization level costs.

Eight horizontal bars of decreasing length labelled with quantization levels, from BF16 to IQ1_S
Illustration generated for the series: the quantization ladder.

Third instalment of Cluster X-ray. It is the best example of what the overview post said: the cluster today is above all a measurement laboratory. Not a single parameter is trained here.

The question #

Open models are distributed quantized: the same weights compressed to 8, 6, 5, 4, 3 or 2 bits so they fit on a small card or a laptop. The community publishes hundreds of variants, but rarely with a comparable measure of what is lost. The line asks how well each quantization level of each family really performs on tasks that matter for using the model as a tool, and at what speed and energy cost it does so on each card.

How it is approached #

Almost 300 different GGUF files from families such as Qwen (2.5 to 3.8), Gemma 3 and 4, GLM, DeepSeek, Mixtral, Llama 3, Mistral, gpt-oss, Nemotron, Granite, SmolLM or Phi-3, plus experimental ternary models, and the full ladder: BF16, Q8_0, Q6_K, Q5_K_M, Q4_K_M (the most common), Q3, Q2, Unsloth’s UD series with its IQ1 to IQ4, MXFP4 and NVFP4. For several families, curves of seven or eight levels of the same model are generated.

Three exams, chosen because they measure the model as a tool and not as a conversationalist:

  • BFCL, function calling: whether the model produces the right call with the right arguments.
  • BigCodeBench, 148 programming problems with real libraries.
  • RULER, retrieval in contexts from 4K to 128K tokens.

On top of that, tokens per second per card, the real memory each file occupies, perplexity on wikitext-2 in the quantization sweeps, and energy: each node’s idle consumption is measured and subtracted from the consumption during generation.

The method has two rules that make it comparable. Each data point carries a manifest with the file, the quantization, the KV cache, the context, the binary with its checksum and the card. And before measuring anything, the published score of an anchor model is reproduced: if the deviation exceeds five points, the fault lies with the harness, not the model.

What is learned #

Several findings were written down in the scripts themselves, with dates:

  • Quantizing the KV cache is not free and is not part of the protocol. With Gemma 4 it breaks: degenerate loops in 101 of 148 problems, against a clean result with the cache in f16.
  • Changing cards changes the output. Only 21 of 148 responses were identical between an L4 and an H200 with the same configuration. Comparisons are always made on the same card.
  • The model is measured, not the scaffolding. BFCL is attacked through the raw completion API: “via the native route we would be measuring the model plus the scaffolding”.
  • An anchor that cannot be downloaded is not an anchor: when Llama 3.1 8B ended up behind an acceptance wall, the long-context anchor moved to Phi-3 mini.

And a security rule that is part of the method: the cluster generates text, it never executes the code the model writes. BigCodeBench grading, which does run that code, happens in an isolated container on a separate machine. BFCL’s multi-turn phase, which executes calls during generation, runs inside a sandbox with no network and with the correct answers hidden. A comment that corrects itself records that misreading the harness code “would have put the isolation in the wrong place”.

On the cluster #

3,941jobs1,104 hGPU hours reserved7,328 hCPU hours reserved10 Jun – 21 Sepperiod (2026)
Figures for the line. Two people share the same harness; the second launched 1,184 jobs in six days of September and publishes their results at Yardstick .

Short jobs of one GPU, four cores and reduced priority, half of them on the modest 24 GB L4. The first 593 failed because of an SSH tunnel between the laptop and the node; since then client and server run on the same node. Five September jobs hung some 18 hours past their limit until Slurm closed them all at once; in the series’ figures they are counted only up to the requested limit.

Jobs by typeBFCL (function calling)BFCL (function calling): 1,105 · 28 %1,105 · 28 %BigCodeBench (generation)BigCodeBench (generation): 779 · 20 %779 · 20 %OtherOther: 777 · 20 %777 · 20 %Serving over SSH tunnel (failed)Serving over SSH tunnel (failed): 593 · 15 %593 · 15 %RULER (long context)RULER (long context): 426 · 11 %426 · 11 %Speed and energySpeed and energy: 192 · 5 %192 · 5 %Download, quantisation, buildDownload, quantisation, build: 69 · 2 %69 · 2 %
Jobs by type: the three exams, speed and energy, and file preparation.

In the fourth instalment we change subject completely: folding proteins.


Figures from Slurm accounting (reserved capacity, not measured usage) and the archived sbatch files. Anonymised post: no identifiable users, paths, emails or project names. Quotations are from the script comments.