Quantisierung im Detail
Quantisierung schrumpft Gewichte von 16-Bit-Floats auf weniger Bits und tauscht etwas Qualität gegen viel Speicher. Die Ein-Zeilen-Version (Q8 ≈ verlustfrei, Q4_K_M ≈ Sweet Spot, unter Q3 tut weh) genügt zum Losfahren. Diese Seite geht eine Ebene tiefer: was die Tags wirklich tun, wie sich K-Quants und I-Quants unterscheiden und wo sich Qualitätsverlust zuerst zeigt.
Warum 4-Bit überhaupt funktioniert
Trainierte Gewichte sind kein gleichförmiges Rauschen. Werte in jedem Tensor klumpen in einer schmalen, ungefähr glockenförmigen Verteilung, und das Verhalten des Netzwerks wird von der Form dieser Verteilung getragen — nicht von der letzten Dezimalstelle irgendeines einzelnen Gewichts. Das macht Gewichte komprimierbar: Speichern Sie jedes Gewicht als kleine Ganzzahl plus geteilten Skalierungsfaktor, und Sie verlieren nur Feindetail.
Eine echte Komplikation: Ausreißer-Kanäle. Ein kleiner Anteil der Kanäle trägt Aktivierungen, die weit größer sind als der Rest. Eine einzige Skala für den ganzen Tensor verschwendet ihren gesamten Bereich an diese Ausreißer und zerdrückt alles andere zu Matsch. Jedes ernsthafte Quant-Schema ist im Kern ein Ausreißer-Behandlungsschema — Block-Skalen, activationsbewusster Schutz (AWQ) oder Kalibrierung gegen echte Daten (Imatrix).
Mechanik der Block-Quantisierung
Der Kerntrick: jeden Tensor in kleine Blöcke hacken, die eine Skala teilen. Das Dequantisieren eines Gewichts ist eine einzige Multiplikation:
w ≈ s · q # s: Block-Skala, q: gespeicherte Ganzzahl
Q4_0: block = 32 weights → 1×fp16 scale + 32×4-bit ints ≈ 4.5 bpw
K-quants: super-block = 256 weights
1×fp16 super-scale + 8×fp8 sub-scales + ints ≈ 4.8 bpw
bpw = Bits pro Gewicht, inklusive Skala-Overhead. Dieser Overhead ist der Grund, warum nichts exakt 4,0 ist: Ein 4-Bit-Gewicht ist ein halbes Byte, und eine 2-Byte-Skala, verteilt über 32 Gewichte, addiert 0,5 bpw. K-Quants amortisieren die Kosten mit zweistufiger Skalierung — 256-Gewichts-Superblöcke, deren 8 Subblöcke billige fp8-Skalen bekommen — und landen bei ~4,8 bpw mit besserer Qualität als Q4_0 bei ähnlicher Größe.
K-Quants und die _M- / _S-Suffixe
Q4_K_M ist nicht „Q4_K mit Hut“ — das Suffix ist ein Mix. Der Quantisierer hebt bestimmte Tensoren auf ein höheres Quant, während die Masse bei Q4_K bleibt: Typischerweise gehen Attention-Projektionen (wv, wo) und manchmal die Token-Embedding-Tabelle auf Q6_K. Das Suffix rangiert den Mix:
_S(small) — wenigste Tensoren angehoben, kleinste Datei_M(medium) — die Standardempfehlung, bestes Größe-/Qualitäts-Gleichgewicht_L(large) — mehr Tensoren in höherer Präzision, abnehmender Ertrag
Der Mix existiert, weil Layer ungleich abtragen: Attention-Projektionen und Embeddings sind empfindlicher als die großen Feed-Forward-Matrizen. Ein paar hundert extra MB dort kaufen echte Qualität — weshalb _M der Community-Standard ist statt schlicht Q4_K.
I-Quants: kalibriert, kleiner, CPU-langsam
IQ-Quants (IQ4_XS, IQ3_XXS, IQ2_XS …) fügen einen Kalibrierungsschritt hinzu. Zuerst eine Wichtigkeitsmatrix (Imatrix) berechnen, indem das Model über eine Stichprobe repräsentativen Texts läuft; dann die Quantisierungsstufen dorthin legen, wo die wichtigen Gewichte tatsächlich leben. Der Ertrag: eine gegebene Qualität bei kleinerer Größe als das äquivalente K-Quant — IQ4_XS unterbietet Q4_K_S bei gleicher oder besserer Qualität, und IQ2/IQ3 machen 7–8B-Modelle unter 3 GB überhaupt erst möglich.
Der Kompromiss ist die Decode-Geschwindigkeit. I-Quant-Dequantisierung ist keine schlichte Multiplikation — sie braucht Lookups ohne Zweierpotenzen und strukturierte Rekonstruktion. Auf der CPU zeigt sich diese zusätzliche Mathematik in Tokens pro Sekunde; auf der GPU versteckt sie sich hinter der Speicherlatenz und kostet fast nichts. Faustregel: K-Quants für CPU-Kisten, I-Quants auf der GPU fein, IQ2/IQ3 nur, wenn der VRAM Sie zwingt.
Die Qualitätsleiter, ehrlich
Ungefähre Dateigrößen für ein 7–8B-Modell. Skaliert grob linear mit den Parametern — ein 14B ist etwa doppelt so groß:
| Quant | Größe | bpw | Ehrliche Qualitätsnotiz |
|---|---|---|---|
| Q8_0 | 8,5 GB | 8,5 | transparent; übersteht blindes A/B gegen FP16 |
| Q6_K | 6,6 GB | 6,6 | nahezu transparent; der letzte Halt vor Paranoia |
| Q5_K_M | 5,7 GB | 5,7 | leichter Verlust, im Chat schwer zu bemerken |
| Q4_K_M | 4,9 GB | 4,8 | der Sweet Spot; einstelliger Prozent-Benchmark-Abschlag |
| IQ4_XS | 4,5 GB | 4,25 | ≈ Q4_K_S-Qualität, kleiner; auf der GPU bevorzugen |
| Q3_K_M | 3,9 GB | 3,9 | spürbar beim Faktenabruf und in Mathe |
| IQ3_XXS | 3,2 GB | 3,1 | flüssiger Chat, wackelige Fakten; realistisch nur GPU |
| Q2_K | 3,2 GB | 3,4 | letzte Zuflucht — die Persönlichkeit überlebt, die Präzision nicht |
Behandeln Sie exakte Prozentsätze als Folklore-Klasse: Der Verlust hängt vom Model, der Sprache und der Aufgabe ab. Die Reihenfolge ist stabil, auch wenn die Größenordnungen es nicht sind.
Wo Quantisierung zuerst wehtut
Der Schaden ist über die Fähigkeiten hinweg nicht gleichmäßig. Ungefähr in fallender Reihenfolge:
- Faktenabruf — Namen, Daten, Zahlen driften zuerst. Ein Q3-Modell schreibt selbstsicher falsch zu.
- Mathe und mehrschichtiges Reasoning — kleine Fehler summieren sich durch die Kette.
- Langkontext-Kohärenz — Abruf aus der Tiefe eines langen Prompts wird wackeliger, als das Kurzprompt-Verhalten vermuten lässt.
- Ressourcenärmere Sprachen — Koreanisch degradiert bei harten Quants früher als Englisch; koreanische Tokens waren im Training seltener, also gibt es weniger Präzisions-Spielraum. Wenn Koreanisch für Sie zählt, halten Sie Q5+, wo es geht.
- Chat-Gewandtheit und Stil — zeigt sich kaum. Ein Q2-Modell klingt noch gut, und das ist die Falle: Gewandtheit ist ein schlechter Proxy für Schaden.
Kleine Modelle leiden mehr
Der Quantisierungsfehler frisst Redundanz, und kleine Modelle haben am wenigsten davon. Ein 70B bei Q4 verliert fast nichts; ein 3B bei Q4 verliert sichtbar mehr; unter ~2B können harte Quants dem Model den Bauch aufschneiden. Praktische Regel: Q6_K oder Q8_0 für alles unter ~4B Parametern — die absoluten GB, die das Zerquetschen eines kleinen Modells spart, sind ohnehin winzig. Holen Sie die Größe-gegen-Fähigkeiten-Baseline in Parameter, bevor Sie entscheiden, wo Sie Bits ausgeben.
Der KV-Cache ist eine eigene Entscheidung
Die Gewichte zu quantisieren tut dem KV-Cache nichts — das ist eine eigene Speicherposition (standardmäßig fp16, in llama.cpp separat auf q8_0/q4_0 quantisierbar). Bei langem Kontext kann der Cache den Gewichten die Größe streitig machen; budgetieren Sie ihn unabhängig in KV-Cache.
Eine praktische Entscheidungsleiter
Durchgerechnet — 12-GB-Karte, dichtes 8B-Modell, 8k Kontext:
Gewichte Q4_K_M 4.9 GB
KV-Cache 8k tokens, fp16 1.0 GB (8B GQA ≈ 128 KiB/token)
Overhead compute buffers + ctx ~1.5 GB
─────────────────────────────────────────
gesamt ~7.4 GB → passt mit Luft nach oben
Gegeben die VRAM-Mathematik, die Leiter:
- Budget: VRAM − Kontext − Overhead = was für Gewichte übrig bleibt.
- Q6_K passt → Q6_K fahren. Nur Q4_K_M passt → Q4_K_M ohne schlechtes Gewissen fahren.
- Nur auf IQ4_XS/Q3 fallen, um Kontext unterzubringen oder CPU-Offloaden zu vermeiden — Offloaden kostet mehr Geschwindigkeit, als ein Quant-Schritt Qualität kostet.
- Passt Ihr Zielmodell nicht bei Q4, gehen Sie eine Größenklasse runter, statt auf Q2 zu quantisieren: Ein solides 8B bei Q4 schlägt in der Praxis meist ein zerquetschtes 14B.
Verwandt: VRAM-Mathematik · KV-Cache · Parameter · Modellformate