Quantisierungen von LLMs in llama.cpp fair vergleichen: gleiche Bytes, gleiche Fenster, gleiche GPU
Zwei GGUF-Dateien von Qwen3-4B, beide als 2-Bit beworben, liefern sehr unterschiedliche WikiText-2-Perplexity-Werte. Ein fairer Vergleich braucht darum gleiche Dateigroessen, identische Textfenster und dieselbe Hardware.
Hier sind zwei GGUF-Dateien von Qwen3-4B, beide als "2-bit" verkauft. Die eine erreicht eine WikiText-2-Perplexity von 28,61, die andere 16,64. Ist die zweite also besser? Vielleicht. Bevor man einer solchen Differenz glaubt, braucht man drei Fakten: wie viele Bytes jede Datei tatsächlich belegt, welche Textfenster bewertet wurden und wie, und ob die Geschwindigkeitswerte von einer GPU in einer einzigen Session stammen.
Dies ist eine Anleitung zum Vergleichen quantisierter Modelle in llama.cpp, damit die Zahlen aussagekräftig sind. Alle folgenden Befehle sind unveränderte llama.cpp-Befehle und funktionieren mit jeder GGUF-Datei. Unser praktisches Beispiel ist Pingala-8, ein 2-Bit-Format, das wir entwickelt haben (die beiden Zahlen oben sind llama.cpps IQ2_XXS und unseres). Die Dateien benötigen unseren gepatchten llama.cpp-Build: das unveränderte llama.cpp, Ollama und LM Studio können sie nicht laden. Wie das Format funktioniert, steht in unserem ersten Artikel; in diesem geht es um die Messung.
Ein Quant-Name beschreibt ein Blockformat, keine Datei. llama-quantize listet IQ2_XXS mit "2,06 bpw", aber eine IQ2_XXS-Datei speichert die Ausgabeschicht als Q5_K, die Token-Embeddings als Q2_K und, bei Modellen wie Qwen3 und Llama 3, die Attention-Value-Tensoren als Q4_K. Das Label verrät also wenig über die Datei.
Die Rechnung für Qwen3-4B: Die 16-Bit-Datei ist 8,05 GB groß bei 2 Bytes pro Gewicht, enthält also etwa 4,0 Milliarden Gewichte. Unsere IQ2_XXS-Datei umfasst 1.246.621.312 Bytes, rund 2,5 Bits pro Gewicht über das gesamte Modell, nicht 2,06. Pingala-8 ist 1.243.153.792 Bytes groß, ebenfalls etwa 2,5.
Warum Bytes? Bytes sind das, was man herunterlädt und was in den VRAM passen muss, und sie sind das Qualitätsbudget: Eine 10% größere Datei kann allein dadurch gewinnen, dass sie größer ist. GSQs Q2_K von Qwen3-4B hat eine bessere Perplexity als unseres (14,37 gegenüber 16,64), aber mit 1,67 GB ist es 34% größer, sodass dieses Paar wenig über die beiden Methoden aussagt.
Auf der Festplatte messen und alle Teile einer aufgeteilten Datei zusammenrechnen:
stat -c '%s %n' model.gguf # eine Datei, exakte Bytes du -cb qwen3-4b-pingala8/ *.gguf | tail -1 # aufgeteiltes GGUF: Summe aller Teile Enter fullscreen mode Exit fullscreen mode Zwei Fallen. Führt man ein llama.cpp-Werkzeug mit -lv 4 aus (neuere Builds verbergen Loader-Meldungen standardmäßig), gibt der Loader "file size =... GiB (... BPW)" aus. Diese Zeile zählt nur Tensor-Bytes (ohne Metadaten) und verwendet GiB: 1.243.153.792 Bytes sind 1,24 GB auf Hugging Face, aber 1,16 GiB im Log. Nutzt man stat für den Größenabgleich und den BPW-Wert des Loaders, der Embeddings und Ausgabe-Tensoren einschließt, für Bits pro Gewicht.
Unsere Regel: Die Kandidatendatei darf nicht größer sein als die Datei, mit der sie verglichen wird. Pingala-8 ist 3.467.520 Bytes unter IQ2_XXS und 2.760.960 Bytes unter der IQ2_KT-Datei unten.
Die Perplexity hängt vom Text, vom Tokenizer, von der Fensterlänge und davon ab, welche Token in jedem Fenster bewertet werden. Alle vier Größen festlegen.
# Standard: jedes Fenster beginnt mit einem BOS-Token; bewertet wird die zweite Hälfte jedes Fensters./llama-perplexity -m model.gguf -f wiki.test.raw -c 4096 -ngl 99 # Strided: jedes Token wird bewertet; Fenster nach dem ersten beginnen mitten im Text./llama-perplexity -m model.gguf -f wiki.test.raw -c 2049 --ppl-stride 4095 -ngl 99 Enter fullscreen mode Exit fullscreen mode Das -c 2049 ist kein Tippfehler. Im Strided-Modus addiert das Werkzeug die halbe Stride zu -c, und das Log sagt es auch: "adjusting context size from 2049 to 4096".
Ein Paar Llama-3.1-8B-Dateien in beiden Modi (die IQ2_KT-Datei wurde aus Q8_0 quantisiert):
Dieselbe Rangfolge, andere Zahlen, weil sich zwei Dinge gleichzeitig ändern. Der Standardmodus bewertet nur die zweite Hälfte jedes Fensters, wo jedes Token mindestens 2.048 Token Kontext hat; der Strided-Modus bewertet auch die schlecht vorhergesagten frühen Token. Und im Strided-Modus beginnen Fenster nach dem ersten mit einem gewöhnlichen Token: llama.cpp schreibt das BOS erst nach der Dekodierung des Fensters in die Token-Liste. Modelle, die das BOS als Attention Sink nutzen, verhalten sich ohne es anders.
Dieses Detail hat uns einen Build gekostet. Eine frühere Llama-3.1-8B-Datei von uns schnitt mit einem BOS gut ab und fiel im Strided-Modus auseinander, weil jede Kalibrierungssequenz, die sie gesehen hatte, mit einem BOS begann. Die Lösung war, jede zweite Kalibrierungssequenz mitten im Text beginnen zu lassen. Vergleicht man also mit der Zahl eines anderen, nur wenn der Modus übereinstimmt, und wenn die eigene Methode auf Daten kalibriert, beide Modi testen.
Eine weitere Prüfung, wenn Formate unterschiedliche Runtimes benötigen. IQ2_KT liegt im Fork ik_llama.cpp, daher haben wir eine gemeinsame Datei durch beide Binaries laufen lassen: Unsere IQ2_XXS-Datei erreicht 28,6083 in llama.cpp und 28,6037 in ik_llama.cpp. Die Runtimes sind also nicht der Unterschied.
Beide Dateien bewerten dieselben Fenster, also subtrahiert man Fenster für Fenster: Die gemeinsame Schwierigkeit hebt sich auf, und das Fehlerintervall schrumpft. llama-perplexity gibt nach jedem Fenster einen laufenden Wert aus (...,... ), womit sich der Loss jedes Fensters rekonstruieren lässt:
# paired.py A.log B.log: per-window NLL differences between two llama-perplexity runs import re, math, statistics as st, sys def windows ( path ): ppl = [ float ( v ) for v in re. findall ( r ' \[\d+\]([0-9.]+) ', open ( path, errors = ' ignore ' ). read ())] ln = [ math. log ( p ) for p in ppl ] # running perplexity after k windows -> NLL of window k (every window has the same token count) return [ ln [ 0 ]] + [( k + 1 ) * ln [ k ] - k * ln [ k - 1 ] for k in range ( 1, len ( ln ))] a, b = windows ( sys. argv [ 1 ]), windows ( sys. argv [ 2 ]) d = [ x - y for x, y in zip ( a, b )] print ( f " A - B: { st. mean ( d ): +. 4 f } +/- { 1.96 * st. stdev ( d ) / math. sqrt ( len ( d )):. 4 f } nats/token, " f " A better on { sum ( x < 0 for x in d ) } of { len ( d ) } windows " ) Enter fullscreen mode Exit fullscreen mode Auf unseren Qwen3-4B-Logs ergibt das -0,542 +/- 0,020 nats pro Token gegenüber IQ2_XXS, besser auf 73 von 73 Fenstern.
Benachbarte Fenster sind korreliert, daher sollte man das Intervall als optimistisch betrachten, wenn der Abstand klein ist.
Die Perplexity sagt aus, wie gut eine Datei echten Text vorhersagt. Sie ist günstig und empfindlich, aber sie ist ein Durchschnitt über Token.
Die KL-Divergenz sagt aus, wie weit die Next-Token-Verteilung des quantisierten Modells token für token von der des Originals entfernt ist (0 bedeutet identisch). Sie benötigt einen Referenzlauf, der Logits speichert:
# 1. reference: save the logits of the fp16 (or Q8_0) model./llama-perplexity -m qwen3-4b-q8_0.gguf -f wiki.test.raw -c 512 --chunks 72 -ngl 99 --kl-divergence-base q8.kld # 2. each quant: the tokens and context are read back from q8.kld./llama-perplexity -m quant.gguf -c 512 -ngl 99 --kl-divergence-base q8.kld --kl-divergence Enter fullscreen mode Exit fullscreen mode Die Logits-Datei ist riesig (die llama.cpp-Dokumentation nennt 37 GiB für Llama 3 auf dem vollständigen WikiText-2-Testsatz), also --chunks begrenzen. Wenn fp16 nicht auf die GPU passt, ist Q8_0 eine faire Referenz: Bei Qwen3-4B erreicht es 12,50 gegenüber 12,46 für fp16.
Die beiden Kennzahlen können auseinanderlaufen. Von den IQ2_KT-Dateien dieser Größe, die wir für Qwen3-4B gebaut haben, hatte die mit der niedrigsten Perplexity (18,15) die höchste KL-Divergenz: im Durchschnitt genau richtig, aber am weitesten vom Originalmodell entfernt. Beides berichten.
Task-Scores prüfen, ob die Antworten erhalten bleiben. llama-perplexity hat Zero-Shot-Modi eingebaut:
./llama-perplexity -m model.gguf -c 2048 -ngl 99 --hellaswag --hellaswag-tasks 1000 -f hellaswag_val_full.txt./llama-perplexity -m model.gguf -c 2048 -ngl 99 --winogrande -f winogrande-debiased-eval.csv./llama-perplexity -m model.gguf -c 2048 -ngl 99 -np 5 --multiple-choice -f arc-easy-validation.bin Enter fullscreen mode Exit fullscreen mode ARC-Fragen können fünf Optionen haben, und unser erster ARC-Lauf brach ohne -np 5 mittendrin ab. Unser Fünf-Task-Durchschnitt bei Qwen3-4B (ARC-Easy, ARC-Challenge, HellaSwag, WinoGrande, MMLU) liegt bei 50,8 für Pingala-8 gegenüber 41,9 für IQ2_XXS: 90% der 56,3 von 8-Bit-Q8_0, nicht 100%. Eine kleinere Datei beantwortet mehr Fragen falsch.
llama-bench misst zwei verschiedene Aufgaben. pp (prompt processing, -p 512 -n 0 ) liest viele Token auf einmal und ist durch die Rechenleistung begrenzt. tg (token generation, -p 0 -n 128 ) erzeugt ein Token nach dem anderen und ist davon begrenzt, wie schnell die Gewichte aus dem Speicher streamen. Eine kleinere Datei hilft meist bei tg; zusätzliche Dekodierarbeit in einem komplexen Format zeigt sich in pp.
Alles gleich lassen außer der Datei: eine GPU, eine Session, Flash Attention und KV-Cache-Typ explizit gesetzt, und eine rotierte Reihenfolge, damit Warm-up und Taktverhalten nicht stets eine Datei begünstigen:
models =( iq2_xxs.gguf candidate.gguf q4_k_m.gguf ) for r in 0 1 2; do for k in 0 1 2; do m = ${ models [ $(( ( k + r ) % 3 )) ] } for t in "pp:-p 512 -n 0" "tg:-p 0 -n 128"; do./llama-bench -m " $m " -ngl 99 -fa 1 -ctk f16 -ctv f16 ${ t #*: } -r 5 -o json > " ${ t %%: * } _r ${ r } _ ${ m %.gguf }.json" done done done Enter fullscreen mode Exit fullscreen mode Jede JSON-Datei enthält avg_ts, Token pro Sekunde. Man teilt es durch den Wert der Baseline aus derselben Runde und mittelt dann die Quotienten über die Runden.
Unser Qwen3-4B-Ergebnis auf einer RTX 5070 Ti Laptop GPU: etwa 200 Token pro Sekunde bei der Generierung, 39% schneller als Q4_K_M (eine Datei von etwa doppelter Größe), aber beim Prompt Processing 0,74x von IQ2_XXS. Beides gehört in denselben Satz. Auch die Batch-Größe spielt eine Rolle: Mit 2 bis 8 parallelen Sequenzen ist unsere Datei deutlich langsamer als IQ2_XXS, also benchmarkt man den Batch, den man tatsächlich ausliefern wird.
Wenn man auf den Testtext tune't, ist die finale Zahl optimistisch. Unsere Qwen3-4B-Datei ist der letzte von vielen Builds, die wir auf WikiText-2 geprüft haben, deshalb kennzeichnen wir sie als tuned und behandeln C4 als den einzigen zurückgehaltenen Text. Für Llama-3.1-8B und Qwen3-14B haben wir vor dem Lauf eine Vorhersage und eine Entscheidungsregel in eine Datei mit Zeitstempel geschrieben. Eine Vorlage:
prereg.txt vor dem Lauf geschrieben, nach compare nie mehr bearbeitet: candidate vs IQ2_KT, nicht mehr Bytes als IQ2_KT Metrik: WikiText-2, llama-perplexity strided, alle Fenster Regel: Gewinn nur, wenn die gepaarte dNLL unter 0 liegt und ihr 95-Prozent-Intervall die 0 ausschliesst Vorhersage: PPL <value> [<low>, <high>] Hash berechnen ( sha256sum prereg.txt ) und den Hash zusammen mit dem Ergebnis veröffentlichen. Beide unserer Vorhersagen gingen fehl, in entgegengesetzte Richtungen: Bei Llama-3.1-8B übertraf das Ergebnis unser Intervall, und bei Qwen3-14B hatten wir einen Gewinn vorhergesagt und erlitten eine Niederlage.
Qwen3-4B bei gleicher Größe (WikiText-2, strided, 73 Fenster):
Geschrieben von Harshit Goyal, Gründer von Genrius AI (ehemaliger Softwareentwickler bei Google, Alumnus der IIIT Delhi).
Dieser Artikel wurde mit Unterstützung von KI verfasst; alle Zahlen stammen aus unseren gemessenen Logs und dem Paper.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Here are two GGUF files of Qwen3-4B, both sold as "2-bit". One scores a WikiText-2 perplexity of 28.61, the other 16.64. Is the second one better? Maybe. Before you believe a gap like that, you need three facts: how many bytes each file really takes, which text windows were scored and how, and whether the speed numbers came from one GPU in one session.
This is a how-to for comparing quantized models in llama.cpp so that the numbers mean something. Every command below is stock llama.cpp and works on any GGUF file. Our worked example is Pingala-8, a 2-bit format we built (the two numbers above are llama.cpp's IQ2_XXS and ours). Its files need our patched llama.cpp build: stock llama.cpp, Ollama and LM Studio cannot load them. How the format works is in our first article; this one is about measuring.
A quant name describes a block format, not a file. llama-quantize lists IQ2_XXS as "2.06 bpw", but an IQ2_XXS file stores the output layer as Q5_K, the token embeddings as Q2_K and, on models such as Qwen3 and Llama 3, the attention value tensors as Q4_K. The label tells you little about the file.
The arithmetic for Qwen3-4B: the 16-bit file is 8.05 GB at 2 bytes per weight, so it holds about 4.0 billion weights. Our IQ2_XXS file is 1,246,621,312 bytes, about 2.5 bits per weight over the whole model, not 2.06. Pingala-8 is 1,243,153,792 bytes, also about 2.5.
Why bytes? Bytes are what you download and what has to fit in VRAM, and they are the quality budget: a file 10% bigger can win simply by being bigger. GSQ's Q2_K of Qwen3-4B has a better perplexity than ours (14.37 against 16.64), but at 1.67 GB it is 34% larger, so that pair tells you little about either method.
Measure on disk, and add up every part of a split file:
stat -c '%s %n' model.gguf # one file, exact bytes du -cb qwen3-4b-pingala8/ *.gguf | tail -1 # split GGUF: total of all parts Enter fullscreen mode Exit fullscreen mode Two traps. Run any llama.cpp tool with -lv 4 (recent builds hide loader messages by default) and the loader prints file size =... GiB (... BPW). That line counts tensor bytes only (no metadata) and uses GiB: 1,243,153,792 bytes is 1.24 GB on Hugging Face but 1.16 GiB in the log. Use stat for matching sizes, and the loader's BPW, which includes the embeddings and output tensors, for bits per weight.
Our rule: the candidate may not be larger than the file it is compared with. Pingala-8 is 3,467,520 bytes under IQ2_XXS and 2,760,960 bytes under the IQ2_KT file below.
Perplexity depends on the text, the tokenizer, the window length and which tokens in each window are scored. Fix all four.
# default: every window starts with a BOS token; the second half of each window is scored./llama-perplexity -m model.gguf -f wiki.test.raw -c 4096 -ngl 99 # strided: every token is scored; windows after the first start mid-text./llama-perplexity -m model.gguf -f wiki.test.raw -c 2049 --ppl-stride 4095 -ngl 99 Enter fullscreen mode Exit fullscreen mode The -c 2049 is not a typo. In strided mode the tool adds half the stride to -c, and the log says so: "adjusting context size from 2049 to 4096".
One pair of Llama-3.1-8B files under both modes (the IQ2_KT file was quantized from Q8_0):
Same ranking, different numbers, because two things change at once. The default mode scores only the second half of each window, where every token has at least 2,048 tokens of context; strided mode also scores the poorly predicted early tokens. And in strided mode, windows after the first begin with an ordinary token: llama.cpp writes the BOS into the token list only after the window has been decoded. Models that use the BOS as an attention sink behave differently without it.
That detail cost us a build. An earlier Llama-3.1-8B file of ours did well with a BOS and fell apart in strided mode, because every calibration sequence it had seen started with a BOS. The fix was to start every second calibration sequence mid-text. So compare with someone else's number only if the mode matches, and if your method calibrates on data, test both modes.
One more check when formats need different runtimes. IQ2_KT lives in the ik_llama.cpp fork, so we ran a shared file through both binaries: our IQ2_XXS file scores 28.6083 in llama.cpp and 28.6037 in ik_llama.cpp. The runtimes are not the difference.
Both files score the same windows, so subtract window by window: shared difficulty cancels and the error bar shrinks. llama-perplexity prints a running value after each window (...,... ), which is enough to recover each window's loss:
# paired.py A.log B.log: per-window NLL differences between two llama-perplexity runs import re, math, statistics as st, sys def windows ( path ): ppl = [ float ( v ) for v in re. findall ( r ' \[\d+\]([0-9.]+) ', open ( path, errors = ' ignore ' ). read ())] ln = [ math. log ( p ) for p in ppl ] # running perplexity after k windows -> NLL of window k (every window has the same token count) return [ ln [ 0 ]] + [( k + 1 ) * ln [ k ] - k * ln [ k - 1 ] for k in range ( 1, len ( ln ))] a, b = windows ( sys. argv [ 1 ]), windows ( sys. argv [ 2 ]) d = [ x - y for x, y in zip ( a, b )] print ( f " A - B: { st. mean ( d ): +. 4 f } +/- { 1.96 * st. stdev ( d ) / math. sqrt ( len ( d )):. 4 f } nats/token, " f " A better on { sum ( x < 0 for x in d ) } of { len ( d ) } windows " ) Enter fullscreen mode Exit fullscreen mode On our Qwen3-4B logs it gives -0.542 +/- 0.020 nats per token against IQ2_XXS, better on 73 of 73 windows.
Adjacent windows are correlated, so treat the interval as optimistic when a margin is small.
Perplexity says how well a file predicts real text. It is cheap and sensitive, but it is an average over tokens.
KL divergence says how far the quantized model's next-token distribution is from the original's, token by token (0 means identical). It needs a reference run that saves logits:
# 1. reference: save the logits of the fp16 (or Q8_0) model./llama-perplexity -m qwen3-4b-q8_0.gguf -f wiki.test.raw -c 512 --chunks 72 -ngl 99 --kl-divergence-base q8.kld # 2. each quant: the tokens and context are read back from q8.kld./llama-perplexity -m quant.gguf -c 512 -ngl 99 --kl-divergence-base q8.kld --kl-divergence Enter fullscreen mode Exit fullscreen mode The logits file is huge (the llama.cpp docs quote 37 GiB for Llama 3 on the full WikiText-2 test set), so cap --chunks. If fp16 does not fit on your GPU, Q8_0 is a fair reference: on Qwen3-4B it scores 12.50 against 12.46 for fp16.
The two can disagree. Of the IQ2_KT files of this size we built for Qwen3-4B, the one with the lowest perplexity (18.15) had the highest KL divergence: right on average, yet furthest from the original model. Report both.
Task scores check whether answers survive. llama-perplexity has zero-shot modes built in:
./llama-perplexity -m model.gguf -c 2048 -ngl 99 --hellaswag --hellaswag-tasks 1000 -f hellaswag_val_full.txt./llama-perplexity -m model.gguf -c 2048 -ngl 99 --winogrande -f winogrande-debiased-eval.csv./llama-perplexity -m model.gguf -c 2048 -ngl 99 -np 5 --multiple-choice -f arc-easy-validation.bin Enter fullscreen mode Exit fullscreen mode ARC questions can have five options, and our first ARC run aborted partway without -np 5. Our five-task average on Qwen3-4B (ARC-Easy, ARC-Challenge, HellaSwag, WinoGrande, MMLU) is 50.8 for Pingala-8 against 41.9 for IQ2_XXS: 90% of the 8-bit Q8_0's 56.3, not 100%. A smaller file gets more answers wrong.
llama-bench measures two different jobs. pp (prompt processing, -p 512 -n 0 ) reads many tokens at once and is limited by compute. tg (token generation, -p 0 -n 128 ) makes one token at a time and is limited by how fast the weights stream from memory. A smaller file usually helps tg; extra decode work in a complex format shows up in pp.
Change nothing but the file: one GPU, one session, flash attention and KV cache type set explicitly, and a rotated order so that warm-up and clock drift do not always favour one file:
models =( iq2_xxs.gguf candidate.gguf q4_k_m.gguf ) for r in 0 1 2; do for k in 0 1 2; do m = ${ models [ $(( ( k + r ) % 3 )) ] } for t in "pp:-p 512 -n 0" "tg:-p 0 -n 128"; do./llama-bench -m " $m " -ngl 99 -fa 1 -ctk f16 -ctv f16 ${ t #*: } -r 5 -o json > " ${ t %%: * } _r ${ r } _ ${ m %.gguf }.json" done done done Enter fullscreen mode Exit fullscreen mode Each JSON file holds avg_ts, tokens per second. Divide it by the baseline's from the same round, then average the ratios over rounds.
Our Qwen3-4B result on one RTX 5070 Ti Laptop GPU: about 200 tokens per second in generation, 39% faster than Q4_K_M (a file about twice the size), but prompt processing at 0.74x IQ2_XXS. Both belong in the same sentence. Batch size matters too: with 2 to 8 parallel sequences our file is much slower than IQ2_XXS, so benchmark the batch you will actually serve.
If you tune on the test text, the final number is optimistic. Our Qwen3-4B file is the last of many builds we checked on WikiText-2, so we label it tuned and treat C4 as the only held-out text. For Llama-3.1-8B and Qwen3-14B we wrote a prediction and a decision rule into a timestamped file before the run. A template:
prereg.txt written before the run, never edited after compare: candidate vs IQ2_KT, no more bytes than IQ2_KT metric: WikiText-2, llama-perplexity strided, all windows rule: win only if the paired dNLL is below 0 and its 95% interval excludes 0 prediction: PPL <value> [<low>, <high>] Enter fullscreen mode Exit fullscreen mode Hash it ( sha256sum prereg.txt ) and publish the hash with the result. Both of our predictions missed, in opposite directions: on Llama-3.1-8B the result beat our interval, and on Qwen3-14B we predicted a win and got a loss.
Qwen3-4B at equal size (WikiText-2, strided, 73 windows):
Written by Harshit Goyal, founder of Genrius AI (ex-Google software engineer, IIIT Delhi alumnus).
This article was written with the help of AI; every number comes from our measured logs and the paper.