GGUF-Quantisierung: Welches Level solltest du nutzen?

Standard ist Q4_K_M; geh auf Q6_K oder Q8_0, wenn du VRAM übrig hast und die letzten paar Prozent Qualität brauchst. GGUF-Quantisierung staucht die Gewichte eines Modells von 16 Bit auf weniger — Q4_K_M speichert rund 4.85 Bit pro Gewicht, ein 7B-Modell fällt also von ~14 GB auf ~4.1 GB, mit einer Perplexität, die typischerweise weniger als 1 % schlechter ist als die des Originals. Die Frage „welche GGUF-Quantisierung soll ich nehmen” hat eine langweilig stabile Antwort, die der größte Teil des Online-Dramas vernebelt. Unten: was Quantisierung wirklich mit den Gewichten macht, was jedes Level an Qualität kostet, wie du die Größen-Mathe selbst rechnest — und ein Befehl, um den Schaden auf deiner eigenen Hardware zu messen, statt den Benchmark eines Fremden zu glauben.

Was macht GGUF-Quantisierung eigentlich?

Ein Modell wird in 16-Bit-Fließkomma trainiert (FP16 oder BF16): jedes seiner Milliarden Gewichte ist eine 2-Byte-Zahl. Quantisierung presst jedes Gewicht in weniger Bits. Der naive Weg — jedes Gewicht auf eine 4-Bit-Ganzzahl runden — vernichtet kleine, aber wichtige Werte, also nutzt GGUF zwei Tricks:

1. Blockskalierung. Gewichte werden zu Blöcken gruppiert (meist 32), und jeder Block bekommt seinen eigenen Skalierungsfaktor. Die 4-Bit-Werte sind Offsets innerhalb des Blocks, sodass ein weiter Magnitudenbereich überlebt.
2. Importanz-bewusste k-quants. Das „K” in Q4_K_M steht für Superblöcke aus Skalen, plus die getrennte Behandlung von Attention- und Feed-Forward-Schichten, weil sie Kompression unterschiedlich gut vertragen.

Die „I”-Familie (IQ4_XS und Freunde) geht weiter mit informationstheoretischen Codebooks aus der Bildkompression. Gleiche Idee, schickere Kodierung: weniger Bits pro Gewicht bei ähnlicher Qualität, auf manchen Backends zum Preis etwas langsamerer Inferenz.

Eine Klarstellung, die den meisten Verwirrung vorbeugt: Quantisierung ändert nur die gespeicherten Gewichte. Architektur, Tokenizer und Kontextbehandlung bleiben unberührt. Eine Q4- und eine Q8-Datei desselben Modells sind dasselbe Modell in unterschiedlichen Mänteln.

Q4 vs. Q8: Ist höhere Quantisierung besser?

Ja, technisch; nein, wahrnehmbar. Mit llama.cpps eigenen Perplexity-Läufen auf Llama-Modellen als Referenz: Q8_0 landet innerhalb von ~0.02 % an FP16 — für jeden praktischen Zweck verlustfrei. Q6_K ist kaum unterscheidbar. Q4_K_M kostet grob 1–2 % Perplexität, Q4_0 etwas mehr, und bei Q2_K fällt bei kleinen Modellen das erste Mal auseinander, was zusammenhängende Antworten ausmacht.

Zwei Regeln, die die Zahlen implizieren:

• Modellgröße kauft Quantisierungsspielraum. Ein 70B-Modell übersteht Q2/Q3 deutlich besser als ein 7B, weil größere Modelle redundanter sind. Einen 7B auf Q2 zu quantisieren ist Amputation; einen 70B auf Q3 ist Schneidersarbeit.
• Die Qualitätsschwelle wandert mit der Aufgabe. Chat verzeiht Q4. Exakte Codegenerierung, Mathe und RAG über präzise Dokumente holen Quantisierungsrauschen früher an die Oberfläche. Schreibt ein Q4-Modell dauerhaft subtil falschen Code, teste dasselbe Modell als Q6_K, bevor du dem Modell die Schuld gibst.

Level	Bit/Gewicht	Größe vs. FP16	Qualitätsverlust	Einsetzen, wenn
Q2_K	~3.4	~21 %	Ernsthaft unter 13B	Nichts anderes passt, nur große Modelle
Q3_K_M	~3.9	~25 %	Deutlich	Knapper VRAM, ≥14B-Modelle
Q4_K_S	~4.6	~29 %	Klein	Q4_K_M passt nicht und es ist nah dran
Q4_K_M	~4.85	~30 %	~1 % Perplexität	Der Standard. Bester Kompromiss aus Qualität und Größe
Q5_K_M	~5.7	~35 %	~0.5 %	VRAM vorhanden, qualitätskritische Aufgaben
Q6_K	~6.6	~41 %	Beinahe keiner	Code/Mathe, passt noch bequem
Q8_0	~8.5	~53 %	Effektiv keiner	Referenzläufe, Fine-Tune-Basen
IQ4_XS	~4.3	~27 %	≈Q4_K_M	Q4_K_M knapp zu groß, Backend kann i-quants

Wie viel VRAM braucht jedes Level?

Rechne die Größen-Mathe selbst, statt Tabellen zu pauken — sie ist eine Zeile:

size_GB ≈ (bits_per_weight × params) / 8
# 8B-Modell @ Q4_K_M: 4.85 × 8 / 8 ≈ 4.9 GB
# 8B-Modell @ Q8_0:   8.50 × 8 / 8 ≈ 8.5 GB

Dann addiere die Teile, die die Formel auslässt: den KV-Cache (wächst mit der Kontextlänge — ein paar hundert MB bis mehrere GB), Aktivierungen und Compute-Buffer. Praktische Marge: Ein „4.9 GB”-Modell will eine 6-GB-Karte bei 4k Kontext — und Flash Attention plus KV-Cache-Quantisierung, um auch bei 16k dort zu bleiben. Die Gewichte sind die Schlagzeile, nicht die ganze Rechnung.

Welche GGUF-Quantisierung solltest du nutzen?

Entscheidungsreihenfolge, ohne auswendig lernbare Ausnahmen:

1. Erst Kontext- und KV-Budget rechnen, dann die Gewichte. Kontext, der nicht passt, ist schlimmer als Qualität, die du nicht messen kannst.
2. Default Q4_K_M. Es ist aus gutem Grund der Community-Standard — rund 1 % Perplexität für 70 % der Größe. Jede Registry, auch Ollamas, schickt es als Baseline mit.
3. Ein Level hoch auf Q6_K, wenn die Aufgabe Rauschen bestraft: Code, Mathe, Extraktion, alles, was unbeaufsichtigt in eine Pipeline geht.
4. Q8_0 nur als Referenz — A/B-Tests, Messung des Quantisierungsschadens oder Fine-Tune-Basis. Als Daily Driver kauft es dir vor allem Wärme in deinen VRAM-Sensoren.
5. Unter Q4 nur unter Zwang, und nur bei großen Modellen. Vor dem Vertrauen mit einem bekannt harten Prompt testen.

Wenn du auf Hugging Face die Datei wählst, nimm eine einzelne Q4_K_M.gguf über Sharded-Splits, außer der Uploader liefert nur Letztere — weniger bewegliche Teile. Und wenn du wählst, wo du sie laufen lässt, ist die Engine-Wahl eine eigene Achse: siehe llama.cpp vs. Ollama.

Wie misst du den Quantisierungsschaden selbst?

Benchmarks unterscheiden sich; dein Prompt ist konstant. Baue llama.cpp einmal, lade zwei Level desselben Modells und miss Perplexität (niedriger ist besser) und Tokens/Sekunde:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf 
  --local-dir models

# Perplexität auf einem Wiki-Text-Abschnitt (niedriger = näher am Originalmodell)
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99

# und Tempo auf derselben Hardware
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

Die Q4_K_M-Zahl wird ein paar Hundertstel schlechter sein als Q8_0, und die Datei ist ~40 % kleiner. Wenn deine nachgelagerte Aufgabe den Unterschied nicht sieht — und bei den meisten sieht sie es nicht —, hast du deine Antwort, ohne die Leaderboard eines Fremden zu lesen.

Schadet Quantisierung der Privatsphäre oder dem Local-Only-Versprechen?

Nein — es ist Arithmetik auf Gewichten, komplett offline, und die quantisierte Datei ist nur ein kleinerer Behälter derselben Parameter. Ein Q4_K_M lokal zu betreiben leakt exakt so viel (oder wenig) wie das Vollpräzisionsmodell lokal: nichts verlässt die Maschine. Die privatsphäre-relevante Variable ist wo die Inferenz läuft, nicht die Bitbreite. Die üblichen Vorbehalte zur Herkunft eines Modells gelten für jedes Quant-Level gleichermaßen: Ein „uncensored” Fine-Tune auf gestohlener Basis als Q8 ist nicht sicherer als dieselben Gewichte als Q4. Zur Dateiformat-Seite davon: GGUF-Modelle lokal ausführen.

Welches Level solltest du wählen?

Q4_K_M — und hör auf, in Foren darüber zu lesen. Stufe auf Q6_K auf für präzisionshungrige Arbeit, wenn der VRAM es erlaubt, halte ein Q8_0 für A/B-Vergleiche parat und behandle alles unter Q4 als Notration für große Modelle. Der eine Fehler, den es zu vermeiden gilt, ist symmetrisch: sich über Q4-gegen-Q5 den Kopf zu zerbrechen, während man die Kontextlänge ignoriert — die hat mehr lokale Setups ruiniert als jedes Quant je.