Ein Sprachmodell besitzt Milliarden Parameter.
Nehmen wir stark vereinfacht ein Modell mit:
20 Milliarden Parametern
Wenn jeder Parameter als 16-Bit-Wert gespeichert wird, benötigen allein die Modellgewichte ungefähr:
20 Milliarden
×
16 Bit
÷
8
≈
40 GB
Für einen gewöhnlichen Rechner ist das bereits eine erhebliche Menge Speicher.
Nun speichern wir dieselben Modellgewichte mit ungefähr vier Bit pro Parameter.
Theoretisch ergibt sich:
20 Milliarden
×
4 Bit
÷
8
≈
10 GB
Plötzlich bewegt sich dasselbe Grundmodell in einer völlig anderen Hardwareklasse.
Genau darum geht es bei Quantisierung.
Die Zahlen, aus denen ein neuronales Netz besteht, werden mit geringerer Präzision dargestellt. Dadurch sinken Speicherbedarf und häufig auch die Anforderungen an Speicherbandbreite und Rechenleistung. Moderne KI-Frameworks unterstützen deshalb verschiedenste Quantisierungsverfahren bis hinunter zu sehr niedrigen Bitbreiten. (Hugging Face)
Ein Sprachmodell besteht letztlich aus sehr vielen Zahlen
Wenn wir von Milliarden Parametern sprechen, meinen wir trainierte Zahlenwerte innerhalb des neuronalen Netzes.
Vereinfacht:
0,038274
-0,741962
0,122811
...
Ein großes Modell besitzt davon nicht:
hundert,
tausend
oder:
eine Million,
sondern Milliarden.
Diese Zahlen müssen irgendwo gespeichert werden.
Damit beeinflusst die Art ihrer Speicherung unmittelbar:
Dateigröße,
RAM-Bedarf,
VRAM-Bedarf
und teilweise die Geschwindigkeit der Inferenz.
Computer können Zahlen mit unterschiedlicher Präzision speichern
Eine Zahl könnte sehr genau repräsentiert werden.
Oder weniger genau.
Vereinfacht:
0,123456789
könnte in einer kompakteren Darstellung eher angenähert werden als:
0,1235
Bei einem einzelnen Wert wirkt dieser Unterschied gering.
Bei:
30 Milliarden Parametern
wird daraus ein riesiger Speicherunterschied.
Was bedeutet Bit?
Ein Bit kann zwei Zustände darstellen:
0
oder
1
Mit mehreren Bits lassen sich entsprechend mehr unterschiedliche Werte codieren.
Vier Bit ermöglichen beispielsweise:
2^4
=
16
verschiedene Bitkombinationen.
Acht Bit:
2^8
=
256
16 Bit:
2^16
=
65.536
Das bedeutet allerdings nicht, dass alle KI-Zahlenformate einfach positive Ganzzahlen von 0 bis zu dieser Obergrenze darstellen.
Die tatsächliche Codierung kann wesentlich komplexer sein.
Der grundlegende Zusammenhang bleibt jedoch:
mehr Bits
→ mehr mögliche Darstellungen
und:
weniger Bits
→ weniger Speicher
Was bedeutet FP32?
FP steht für Floating Point, also Gleitkommazahl.
32 bedeutet:
Die Zahl wird in einem 32-Bit-Format gespeichert.
Historisch ist FP32 in vielen Machine-Learning-Berechnungen ein wichtiges Standardformat.
Für große Sprachmodelle ist der Speicherbedarf allerdings enorm.
Ein Modell mit zehn Milliarden Parametern benötigt allein für die Gewichte in einer vereinfachten FP32-Rechnung:
10 Milliarden
×
32 Bit
÷
8
=
40 GB
Noch ohne weitere Laufzeitdaten.
FP16 halbiert diesen groben Gewichtsspeicher
Bei 16 Bit:
10 Milliarden
×
16
÷
8
=
20 GB
Das ist bereits eine erhebliche Reduktion.
Moderne Modelle werden deshalb häufig ohnehin in halbpräzisen Formaten wie FP16 oder BF16 verteilt beziehungsweise verarbeitet. Hugging Face weist darauf hin, dass FP16 und BF16 wegen der Größe moderner Modelle zunehmend als Ausgangsformate verwendet werden, während Quantisierung die Präzision noch weiter reduzieren kann. (Hugging Face)
Was ist BF16?
BF16, BFloat16, besitzt ebenfalls 16 Bit.
Es verteilt diese Bits allerdings anders als FP16.
Dadurch besitzt BF16 einen größeren Zahlenbereich, aber weniger Präzision für die Mantisse.
Für diesen Artikel reicht zunächst:
FP16
→ 16-Bit-Gleitkommazahl
BF16
→ ebenfalls 16 Bit,
aber anderes Zahlenformat
Beide sind wesentlich größer als typische 4-Bit-Quantisierungen.
Ist FP16 bereits Quantisierung?
Der Begriff wird nicht immer vollkommen einheitlich verwendet.
Im weiten Sinn reduziert auch der Wechsel von FP32 auf FP16 die numerische Präzision.
Im heutigen LLM-Alltag meint Quantisierung aber häufig eine deutlich aggressivere Kompression, beispielsweise auf:
INT8
8 Bit
6 Bit
5 Bit
4 Bit
oder noch weniger.
FP16 beziehungsweise BF16 dienen dabei häufig eher als hochpräzise Ausgangs- oder Vergleichsformate.
Was bedeutet INT8?
INT steht für Integer.
Also:
Ganzzahl.
Eine einfache 8-Bit-Quantisierung versucht, einen Bereich ursprünglich präziser Modellwerte auf eine deutlich kleinere Menge diskreter Werte abzubilden.
Vereinfacht:
viele mögliche FP-Werte
↓
Skalierung
↓
256 mögliche 8-Bit-Stufen
Die ursprünglichen Werte werden angenähert.
Quantisierung ist deshalb eine Näherung
Angenommen, das Originalgewicht lautet:
0,137482
Das Quantisierungssystem kann vielleicht nur einen nahegelegenen Wert darstellen:
0,1369
Die Differenz:
Original
-
Quantisierung
=
Quantisierungsfehler
Bei Milliarden Parametern entstehen sehr viele solcher kleinen Fehler.
Die Kunst eines guten Quantisierungsverfahrens besteht darin, diese Fehler so zu verteilen beziehungsweise zu minimieren, dass die Fähigkeiten des Modells möglichst gut erhalten bleiben.
Naive Quantisierung wäre einfach
Man könnte sagen:
Teile den gesamten Zahlenbereich einfach gleichmäßig auf.
Angenommen:
Minimum = -1
Maximum = +1
Bei einer sehr kleinen Zahl möglicher Stufen könnten Werte auf die jeweils nächstgelegene Stufe gerundet werden.
Vereinfacht:
0,13
→
0,12
0,46
→
0,47
Das funktioniert prinzipiell.
Bei großen neuronalen Netzen ist allerdings nicht jeder Parameter gleich empfindlich gegenüber solchen Fehlern.
Manche Gewichte sind wichtiger als andere
Ein kleiner Quantisierungsfehler an einer Stelle kann nahezu keine Auswirkung besitzen.
An einer anderen Stelle kann derselbe Fehler die Modellausgabe stärker beeinflussen.
Darum sind moderne Quantisierungsverfahren deutlich intelligenter als:
einfach jede Zahl
gleich grob runden
Verfahren wie AWQ nutzen beispielsweise Informationen aus Modellaktivierungen, um besonders wichtige Gewichte bei der Quantisierung besser zu schützen. Die ursprüngliche AWQ-Arbeit zeigt genau diese Idee: Ein kleiner Anteil besonders relevanter Gewichte kann überproportional wichtig für die Modellqualität sein. (Proceedings MLSys)
Quantisierung ist damit ein Optimierungsproblem
Wir möchten gleichzeitig:
weniger Speicher
hohe Geschwindigkeit
möglichst wenig Qualitätsverlust
Diese Ziele widersprechen sich teilweise.
Sehr hohe Präzision:
viel Speicher
+
hohe Qualität
Sehr starke Quantisierung:
wenig Speicher
+
größeres Qualitätsrisiko
Die Aufgabe besteht darin, einen geeigneten Punkt dazwischen zu finden.
Warum ist 4-Bit-Quantisierung so interessant?
Vier Bit bieten theoretisch nur:
16 verschiedene Codes
pro quantisiertem Wert.
Trotzdem können moderne Verfahren große Sprachmodelle erstaunlich gut in dieser Größenordnung repräsentieren.
Dadurch sinkt der Gewichtsspeicher gegenüber 16 Bit theoretisch ungefähr auf ein Viertel.
16 Bit
→ 100 %
4 Bit
→ ungefähr 25 %
Die reale Modelldatei ist etwas größer als diese idealisierte Rechnung, weil zusätzliche Informationen wie Skalen und Metadaten gespeichert werden müssen.
Ein Q4-Modell benötigt deshalb nicht exakt vier Bit pro Gewicht
Das ist ein ausgesprochen wichtiger Punkt.
Nehmen wir eine Quantisierung, die im Namen:
Q4
trägt.
Das bedeutet nicht zwangsläufig:
exakt 4,000 Bit
pro Parameter
Denn gruppierte Quantisierungen benötigen zusätzliche Informationen.
Zum Beispiel:
Skalierungswerte,
Blockmetadaten,
weitere höherpräzise Tensoren.
Die aktuelle llama.cpp-Dokumentation zeigt diesen Unterschied sehr anschaulich: Bei einem getesteten Modell benötigt beispielsweise Q4_K_M effektiv knapp 4,9 Bit pro Gewicht statt exakt vier. (GitHub)
Warum braucht Quantisierung zusätzliche Skalierungswerte?
Angenommen, wir quantisieren eine Gruppe von Gewichten.
Original:
-0,831
-0,122
0,039
0,248
0,793
Wir wollen sie durch kleine Ganzzahlen darstellen.
Beispielsweise:
-7
-1
0
2
7
Nun benötigen wir zusätzlich eine Information:
Wie wird aus diesen kleinen Ganzzahlen wieder ungefähr der ursprüngliche Wertebereich?
Dafür kann eine Skalierung gespeichert werden.
Vereinfacht:
quantisierter Wert
×
scale
≈
ursprünglicher Wert
Gruppenquantisierung reduziert Fehler
Statt eine einzige Skalierung für Milliarden Gewichte zu verwenden, werden Gewichte häufig in kleinere Gruppen beziehungsweise Blöcke eingeteilt.
Gewichte
↓
Block 1
Block 2
Block 3
...
Jeder Block kann eigene Quantisierungsparameter besitzen.
Dadurch passt die Darstellung besser zur lokalen Werteverteilung.
Kleinere Gruppen können Qualität verbessern
Sehr große Gruppe:
eine Skala
für sehr unterschiedliche Werte
Kleinere Gruppe:
mehrere passendere Skalen
Das kann den Quantisierungsfehler reduzieren.
Dafür müssen aber mehr Skalen gespeichert werden.
Wieder entsteht ein Trade-off:
kleinere Gruppen
→ möglicherweise bessere Qualität
→ mehr Metadaten
Deshalb ist „4 Bit“ nur eine grobe Klasse
Zwei unterschiedliche 4-Bit-Quantisierungen können:
unterschiedlich groß,
unterschiedlich schnell,
unterschiedlich genau
sein.
Die Bitzahl allein reicht deshalb nicht zur Auswahl.
Was bedeutet Weight-Only-Quantisierung?
Nicht alle Teile einer KI-Berechnung müssen auf dieselbe Präzision reduziert werden.
Bei Weight-Only Quantization werden primär die Modellgewichte quantisiert.
Weights
→ niedrigere Präzision
während andere Berechnungen beziehungsweise Aktivierungen mit höherer Präzision stattfinden können.
AWQ ist beispielsweise ein Verfahren für Low-Bit-Weight-Only-Quantisierung. (Proceedings MLSys)
Warum quantisiert man nicht einfach alles auf vier Bit?
Weil unterschiedliche Bestandteile des Modells unterschiedlich empfindlich sind.
Ein niedrigpräziser Speicherwert kann gut funktionieren.
Eine Zwischenberechnung könnte jedoch mehr Präzision benötigen.
Deshalb kann eine Engine beispielsweise:
Gewichte
→ 4 Bit gespeichert
aber:
Berechnung
→ 16 Bit oder anderes Format
verwenden.
Speicherformat und Rechenformat sind nicht dasselbe
Das wird häufig missverstanden.
Eine Modelldatei kann quantisierte Gewichte enthalten.
Während der Berechnung können Werte jedoch:
teilweise dequantisiert
oder:
in einem anderen Datentyp verarbeitet
werden.
Hugging Faces GGUF-Unterstützung beschreibt beispielsweise explizit, dass quantisierte Gewichte in kompakter Form vorliegen können, während sie für bestimmte Berechnungen in einen konfigurierten Compute-Datentyp überführt werden. (Hugging Face)
Quantisierung spart deshalb nicht automatisch exakt proportional Rechenleistung
Vier Bit statt 16 Bit bedeutet:
wesentlich weniger Gewichtsspeicher.
Es bedeutet aber nicht zwingend:
viermal schneller
Die tatsächliche Geschwindigkeit hängt davon ab:
Welche Hardware?
Welche Quantisierung?
Welche Kernel?
Welche Inference Engine?
Welche Speicherbandbreite?
Wie viel Dequantisierung ist notwendig?
Quantisierung kann sogar langsamer sein
Das klingt zunächst widersprüchlich.
Ein kleineres Modell muss weniger Daten bewegen.
Das ist gut.
Aber wenn die Hardware bestimmte Quantisierungsoperationen schlecht unterstützt, können zusätzliche Umwandlungen entstehen.
Dann kann eine stärkere Quantisierung:
kleiner
aber nicht unbedingt:
schneller
sein.
Deshalb sollte Geschwindigkeit gemessen werden
Nicht:
Q4 ist kleiner als Q8
→ also automatisch schneller
sondern:
Modell
+
Quantisierung
+
Hardware
+
Inference Engine
↓
Benchmark
Das Ergebnis kann je nach System unterschiedlich ausfallen.
Speicherbandbreite erklärt einen Teil des Geschwindigkeitsgewinns
Bei der Token-Generierung großer LLMs müssen immer wieder große Mengen Modellgewichtsdaten gelesen werden.
Wenn ein Modell statt:
16 GB
nur:
5 GB
Gewichte benötigt, müssen potenziell wesentlich weniger Daten durch den Speicher bewegt werden.
Das kann die Generierung beschleunigen.
Die llama.cpp-eigenen Benchmarks zeigen beispielsweise, dass verschiedene quantisierte Varianten auf derselben Hardware deutlich andere Generationsgeschwindigkeiten als F16 erreichen können – allerdings nicht in einer simplen Reihenfolge „weniger Bits = immer schneller“. (GitHub)
Quantisierung kann deshalb zwei Vorteile gleichzeitig bringen
weniger Speicher
und möglicherweise:
höhere Geschwindigkeit
Der erste Vorteil ist relativ zuverlässig.
Der zweite hängt stärker von der Implementierung ab.
Was ist Post-Training Quantization?
Ein großes Modell wurde bereits vollständig trainiert.
Danach wird es quantisiert.
Training
↓
hochpräzises Modell
↓
Quantisierung
↓
kompakteres Modell
Das nennt man Post-Training Quantization, kurz PTQ.
Der große Vorteil:
Das ursprüngliche Modell muss nicht vollständig neu trainiert werden.
Viele lokale Modelle sind genau solche quantisierten Ableitungen
Ein Anbieter veröffentlicht beispielsweise ein Modell in BF16.
Danach erstellt jemand daraus:
Q8
Q6
Q5
Q4
Varianten.
Alle stammen vom selben Grundmodell.
Sie unterscheiden sich hauptsächlich in der quantisierten Repräsentation der Gewichte.
Quantisierung verändert also nicht das Training des Grundmodells
Ein 4-Bit-Modell besitzt nicht:
weniger trainierte Texte
oder:
weniger ursprüngliche Parameter
Die vorhandenen Gewichte werden kompakter dargestellt.
Das ist etwas völlig anderes als ein kleineres Modell mit weniger Parametern.
8B Q4 und 4B FP16 sind unterschiedliche Dinge
Beispiel:
Modell A
8 Milliarden Parameter
4-Bit-quantisiert
gegen:
Modell B
4 Milliarden Parameter
16 Bit
Beide könnten eine ähnliche Speichergröße besitzen.
Aber:
Modell A besitzt weiterhin eine Architektur mit ungefähr acht Milliarden Parametern.
Modell B nur ungefähr vier Milliarden.
Welche Variante qualitativ besser ist, lässt sich nicht allein aus dem Speicherbedarf ableiten.
Quantisierung und Modellverkleinerung sind deshalb nicht identisch
Quantisierung:
gleiche Modellarchitektur
↓
weniger präzise Zahlenrepräsentation
Kleineres Modell:
weniger Parameter
↓
andere Modellkapazität
Das sollte man bei Modellvergleichen sauber auseinanderhalten.
Was ist Quantization-Aware Training?
Eine weitere Möglichkeit besteht darin, das Modell bereits während des Trainings auf die spätere Quantisierung vorzubereiten.
Das nennt man:
Quantization-Aware Training, kurz QAT.
Vereinfacht:
Training
↓
Quantisierungseffekte werden simuliert
↓
Modell lernt damit umzugehen
Das kann hohe Qualität bei niedriger Präzision ermöglichen.
Ist aber deutlich aufwendiger als reine Post-Training Quantization.
Für lokale Anwender ist PTQ häufiger relevant
Wenn du ein fertiges Open-Weight-Modell herunterladen möchtest, willst du normalerweise nicht:
das gesamte Grundmodell neu trainieren.
Du verwendest:
eine vorhandene Quantisierung
oder:
quantisierst selbst ein bereits trainiertes Modell.
Genau dafür existieren Werkzeuge wie llama-quantize, das hochpräzise GGUF-Modelle beispielsweise in verschiedene quantisierte Formate umwandeln kann. (GitHub)
Was ist Calibration?
Einige Quantisierungsverfahren verwenden Beispieldaten, um herauszufinden:
Welche Gewichtsteile sind empfindlich?
Welche Wertebereiche treten typischerweise auf?
Wie sollten Quantisierungsgrenzen gewählt werden?
Diese Beispieldaten nennt man häufig:
Calibration Dataset.
Kalibrierung ist kein neues Modelltraining
Das Modell lernt normalerweise nicht im klassischen Sinne eine neue Aufgabe.
Die Kalibrierungsdaten helfen dem Quantisierungsverfahren lediglich dabei, die Kompression besser auf das tatsächliche Modellverhalten abzustimmen.
Modell
+
repräsentative Beispiele
↓
Quantisierungsanalyse
↓
bessere Quantisierung
Gute Kalibrierungsdaten sollten repräsentativ sein
Wenn das Modell hauptsächlich:
deutsche Fachtexte
verarbeiten soll, kann es sinnvoll sein, bei empfindlichen Quantisierungsverfahren Daten zu verwenden, die diesem Einsatz halbwegs entsprechen.
Nicht unbedingt ausschließlich:
zufällige mathematische Formeln.
Wie stark dies nötig ist, hängt allerdings vom konkreten Verfahren ab.
Was ist eine Importance Matrix?
Im llama.cpp-Ökosystem gibt es beispielsweise eine sogenannte Importance Matrix, oft kurz imatrix.
Sie enthält Informationen darüber, welche Modellgewichte beziehungsweise Aktivierungsmuster während repräsentativer Eingaben besonders relevant sind.
Diese Informationen können bei der Quantisierung genutzt werden, um Fehler an wichtigen Stellen stärker zu vermeiden. Die aktuelle llama.cpp-Quantisierungsimplementierung unterstützt eine solche Importance Matrix ausdrücklich. (GitHub)
Das Grundprinzip ist wichtiger als der konkrete Name
nicht jedes Gewicht gleich behandeln
sondern:
wichtige Bereiche
→ vorsichtiger quantisieren
Das ist ein wiederkehrendes Prinzip moderner Quantisierung.
Was ist GPTQ?
GPTQ ist ein bekanntes Post-Training-Quantisierungsverfahren für große Transformermodelle.
Es versucht, Quantisierungsfehler beim Komprimieren der Gewichte intelligent zu kompensieren.
Die ursprüngliche GPTQ-Arbeit zeigte, dass sehr große Transformer auf niedrige Bitbreiten wie drei oder vier Bit reduziert werden können, ohne die Qualität zwangsläufig massiv zu zerstören. (arXiv)
GPTQ ist vor allem ein Verfahren, nicht einfach ein Dateiformat
Das ist wichtig.
GPTQ
→ Quantisierungsalgorithmus beziehungsweise Modellrepräsentation
Es ist nicht dasselbe wie:
GGUF
Diese Begriffe begegnen häufig nebeneinander, erfüllen aber unterschiedliche Rollen.
Was ist AWQ?
AWQ steht für:
Activation-aware Weight Quantization.
Die Kernidee lautet:
Nicht alle Gewichte eines Sprachmodells sind gleich wichtig.
Informationen aus den Aktivierungen helfen zu erkennen, welche Gewichte besonders sensibel sind.
Diese können beim Quantisieren besser geschützt werden. Die AWQ-Arbeit verfolgt genau dieses aktivierungsabhängige Weight-Only-Prinzip. (Proceedings MLSys)
GPTQ und AWQ verfolgen dasselbe grobe Ziel
großes Modell
↓
weniger Bits
↓
möglichst wenig Qualitätsverlust
Sie verwenden dafür unterschiedliche mathematische Strategien.
Welche Variante praktisch am besten ist, hängt auch von:
Inference Engine,
GPU,
Modell,
Deployment
ab.
Was ist bitsandbytes?
bitsandbytes ist eine häufig eingesetzte Bibliothek für niedrigpräzise Modellnutzung und Training.
In Kombination mit Hugging Face Transformers kann sie beispielsweise Modelle in:
8 Bit
oder:
4 Bit
laden.
Hugging Face beschreibt die 8-Bit-Variante als Speicherreduktion gegenüber höherpräziser Modellnutzung und die 4-Bit-Variante insbesondere als wichtige Grundlage für QLoRA. (Hugging Face)
Nicht jede Quantisierung ist für dieselbe Laufzeit gedacht
Eine lokale Desktop-Engine verwendet vielleicht:
GGUF.
Ein GPU-Server:
AWQ.
Ein Fine-Tuning-Workflow:
bitsandbytes / NF4.
Darum sollte man nicht fragen:
Was ist das beste Quantisierungsformat?
Sondern:
Für welches Modell, welche Hardware und welche Software?
Was ist GGUF?
GGUF begegnet besonders häufig bei lokalen Sprachmodellen.
Dabei ist wichtig:
GGUF ist zunächst ein Dateiformat.
Es kann enthalten:
Modelltensoren,
Tokenizerinformationen,
Metadaten
und verschiedene quantisierte Datentypen.
Hugging Face beschreibt GGUF als Single-File-Format für Modelle im GGML-/llama.cpp-Ökosystem, das zahlreiche Quantisierungstypen speichern kann. (Hugging Face)
GGUF ist also nicht selbst „die Quantisierung“
Das Modell könnte in einer GGUF-Datei beispielsweise gespeichert sein als:
F32
oder:
BF16
oder:
Q8
oder:
Q4
GGUF ist der Container.
Die Quantisierung beschreibt die konkrete Repräsentation der Tensoren.
Das lässt sich mit Bilddateien vergleichen
Vereinfacht:
JPEG-Datei
ist ein Dateiformat.
Innerhalb dieses Konzepts existieren unterschiedliche Qualitäts- beziehungsweise Kompressionseinstellungen.
GGUF und Quantisierung sind technisch nicht genau dasselbe wie JPEG-Kompression, aber der Vergleich hilft:
Dateiformat
≠
Qualitätsstufe
Warum ist GGUF für lokale KI so beliebt?
Das llama.cpp-Ökosystem ist auf effiziente lokale Inferenz ausgerichtet und kann GGUF-Modelle auf unterschiedlichen Hardwarekonfigurationen ausführen. Das Projekt unterstützt unter anderem CPU- und GPU-Backends und stellt zugleich einen lokalen API-Server bereit. (GitHub)
Damit eignet sich GGUF gut für:
Desktoprechner,
Heimserver,
CPU/GPU-Offloading,
lokale APIs.
Was bedeuten Namen wie Q4_K_M?
Bei GGUF-Modellen findest du häufig Bezeichnungen wie:
Q4_K_M
Q5_K_M
Q6_K
Q8_0
Diese Namen bezeichnen konkrete Quantisierungstypen im llama.cpp-/GGML-Ökosystem.
Die erste Zahl vermittelt ungefähr die Präzisionsklasse.
Aber:
Q4
bedeutet nicht automatisch exakt vier Bit pro Modellparameter.
Das zeigt die reale Speicherrechnung
Für ein von llama.cpp dokumentiertes 8B-Modell liegen die effektiven Größen beispielsweise ungefähr bei:
Q4_K_M
→ knapp 4,9 Bit pro Gewicht
Q5_K_M
→ knapp 5,7 Bit pro Gewicht
Q6_K
→ gut 6,5 Bit pro Gewicht
Q8_0
→ ungefähr 8,5 Bit pro Gewicht
Die zusätzlichen Bruchteile entstehen unter anderem durch die Struktur der jeweiligen Quantisierung und gespeicherte Zusatzinformationen. (GitHub)
Q4_K_M ist also nicht einfach „4 Bit“
Besser wäre das mentale Modell:
Q4_K_M
→ ungefähr 4-Bit-Klasse
→ mit konkretem Block- und Mischschema
Die genaue technische Bedeutung ist implementierungsspezifisch.
Für den normalen Anwender ist wichtiger:
Dateigröße,
Qualität,
Geschwindigkeit
und:
Hardwarekompatibilität.
Was bedeuten S, M und L?
Bei manchen Quantisierungsfamilien begegnen Varianten wie:
S
M
L
Sie können für unterschiedliche Mischungen beziehungsweise Qualitäts- und Größenabstufungen stehen.
Wichtig:
Diese Buchstaben sind keine universellen KI-Standards.
Sie gehören zum jeweiligen Quantisierungsschema.
Man sollte deshalb nicht automatisch erwarten, dass:
M
in einem völlig anderen Format dasselbe bedeutet.
Quantisierungsnamen sind Ökosystem-spezifisch
GGUF Q4_K_M
GPTQ 4-bit
AWQ 4-bit
bitsandbytes NF4
können alle ungefähr im 4-Bit-Bereich arbeiten.
Sie sind trotzdem nicht dieselbe Quantisierung.
Was ist NF4?
NF4, NormalFloat4, wurde im Zusammenhang mit QLoRA eingeführt.
Es ist ein spezielles 4-Bit-Datenformat, das für die Verteilung trainierter neuronaler Netzgewichte ausgelegt wurde.
QLoRA kombiniert ein eingefrorenes 4-Bit-quantisiertes Grundmodell mit trainierbaren LoRA-Adaptern, um Fine-Tuning mit stark reduziertem Speicherbedarf zu ermöglichen. (arXiv)
NF4 ist damit besonders im Fine-Tuning-Kontext bekannt
quantisiertes Basismodell
↓
NF4
↓
LoRA-Adapter trainieren
Das bedeutet nicht automatisch, dass NF4 für jede reine lokale Inferenz die beste Wahl ist.
Wieder entscheidet der Einsatzzweck.
Was ist Double Quantization?
Bei einer Quantisierung müssen zusätzlich:
Skalen,
Quantisierungskonstanten
gespeichert werden.
Auch diese benötigen Speicher.
QLoRA verwendet unter anderem das Konzept der Double Quantization:
Gewichte quantisieren
+
Quantisierungsinformationen
ebenfalls kompakter darstellen
Dadurch lässt sich der Speicherbedarf weiter reduzieren. (arXiv)
Quantisierung kann also selbst quantisiert werden
Das klingt zunächst ungewöhnlich.
Aber logisch:
Wenn Milliarden Gewichte in Gruppen organisiert werden und jede Gruppe zusätzliche Skalierungsinformationen benötigt, summieren sich diese Informationen.
Dann kann es sinnvoll sein, auch sie kompakter darzustellen.
Was bedeutet Mixed Precision?
Nicht jeder Tensor eines Modells muss mit derselben Präzision gespeichert werden.
Zum Beispiel:
großer Teil des Modells
→ 4 Bit
aber:
besonders sensible Gewichte
→ 6 oder 8 Bit
oder:
Output Layer
→ höhere Präzision
Das nennt man vereinfacht eine Mixed-Precision-Strategie.
Dadurch kann Qualität geschützt werden
Vielleicht verursachen:
95 Prozent der Gewichte
bei vier Bit kaum Probleme.
Ein kleiner sensibler Bereich dagegen schon.
Dann ist es verschwenderisch, das gesamte Modell mit acht Bit zu speichern.
Besser:
unempfindliche Bereiche
→ stärker quantisieren
empfindliche Bereiche
→ höhere Präzision
Das ist ein weiterer Grund, warum moderne Quantisierungen besser sein können als eine einfache pauschale Bitreduktion.
llama.cpp verwendet ebenfalls gemischte Tensorstrategien
Die aktuelle Quantisierungsimplementierung erlaubt beispielsweise, bestimmte Tensoren gezielt in anderen Quantisierungstypen zu speichern und einzelne Ausgabetensoren höherpräzise zu belassen. (GitHub)
Damit lässt sich Qualität gezielt schützen, ohne das gesamte Modell größer zu machen.
Warum kann ein Q5-Modell besser sein als Q4?
Weil mehr Präzision erhalten bleibt.
Vereinfacht:
Q4
→ kleiner
→ stärkerer Informationsverlust
Q5
→ etwas größer
→ geringerer Informationsverlust
Aber:
Der Unterschied hängt stark vom Modell ab.
Manchmal ist der Qualitätsunterschied kaum sichtbar
Bei:
alltäglichen Chats,
Zusammenfassungen,
einfachen Texten
kann eine gute 4-Bit-Quantisierung sehr nahe an einer höherpräzisen Variante liegen.
Bei:
schwieriger Logik,
Mathematik,
Code,
mehrsprachigen Aufgaben,
kleinen empfindlichen Modellen
können Unterschiede stärker auffallen.
Deshalb braucht Quantisierung eigene Evals
Nimm nicht einfach die Aussage:
Q4 ist praktisch genauso gut.
Teste:
deine Aufgaben.
Zum Beispiel:
50 reale Supporttickets
50 Dokumentextraktionen
50 Textbriefings
mit:
BF16
Q8
Q6
Q5
Q4
Dann kannst du vergleichen.
Eine einfache Vergleichsmatrix
Qualität
Geschwindigkeit
VRAM
Dateigröße
Für jede Quantisierung.
Nun wird aus Bauchgefühl eine technische Entscheidung.
Perplexity ist eine mögliche Qualitätsmetrik
Bei Sprachmodellen kann man beispielsweise betrachten, wie gut ein Modell Textfolgen vorhersagt.
Eine verbreitete technische Kennzahl dafür ist:
Perplexity.
llama.cpp verwendet bei seinen Quantisierungsanalysen unter anderem Perplexity beziehungsweise Abweichungsmetriken, um den Informationsverlust verschiedener Quantisierungen zu beurteilen. (GitHub)
Perplexity allein beantwortet aber nicht deine Geschäftsfrage
Ein Modell kann eine ausgezeichnete Perplexity besitzen.
Aber vielleicht:
deine Rechnungsdaten falsch extrahieren.
Darum braucht man zusätzlich aufgabenbezogene Tests.
Technischer Benchmark
+
echte Aufgaben
ist wesentlich aussagekräftiger.
Für Klassifikation misst man andere Dinge
Zum Beispiel:
Accuracy
Precision
Recall
pro Kategorie.
Wenn Q4 dieselbe Klassifikationsqualität wie Q8 erreicht:
Warum doppelt so viel Gewichtsspeicher verwenden?
Für strukturierte Ausgaben misst man Formatstabilität
Zum Beispiel:
100 Testfälle
davon:
Q8:
99 gültige JSON-Ausgaben
Q4:
91 gültige JSON-Ausgaben
Dann kann der Unterschied geschäftlich relevant sein.
Selbst wenn beide Modelle in normalen Chats nahezu gleich wirken.
Quantisierung kann Halluzinationen beeinflussen
Eine aggressive Quantisierung verändert das Modell.
Sie kann daher auch:
Argumentation,
Faktenwiedergabe,
Formatverhalten
beeinflussen.
Aber Quantisierung ist nicht die alleinige Ursache von KI-Halluzinationen.
Auch ein hochpräzises Modell kann halluzinieren.
Man sollte Quantisierung nicht für jedes Modell gleich beurteilen
Ein großes Modell besitzt möglicherweise genügend Redundanz, um starke Quantisierung gut zu verkraften.
Ein sehr kleines Modell kann empfindlicher sein.
Oder umgekehrt kann eine bestimmte Architektur besonders quantisierungsfreundlich sein.
Deshalb gibt es keine universelle Regel:
Q4 verliert exakt X Prozent Qualität
Auch einzelne Fähigkeiten können unterschiedlich empfindlich sein
Ein Modell bleibt vielleicht hervorragend bei:
deutscher Alltagssprache.
Aber verliert überproportional bei:
Programmiercode
oder:
Mathematik.
Daher müssen Evals die tatsächlichen Aufgaben repräsentieren.
Re-Quantisierung ist problematisch
Angenommen, du hast bereits:
Q8
und möchtest daraus:
Q4
machen.
Das funktioniert technisch teilweise.
Aber du quantisierst dann bereits angenäherte Werte erneut.
Original
↓
erste Rundung
↓
zweite Rundung
Dabei können sich Fehler verstärken.
llama.cpp warnt bei seiner Re-Quantisierungsoption ausdrücklich, dass erneutes Quantisieren bereits quantisierter Tensoren die Qualität gegenüber einer Quantisierung direkt aus 16- oder 32-Bit-Quellen deutlich stärker verschlechtern kann. (GitHub)
Deshalb möglichst vom hochwertigen Ausgangsmodell quantisieren
Besser:
BF16
↓
Q4
als:
Q8
↓
Q6
↓
Q4
wenn eine hochwertige Ausgangsdatei verfügbar ist.
Das gilt besonders beim Erstellen eigener GGUF-Varianten
Ein sinnvoller Prozess lautet:
Originalmodell
↓
hochwertiges GGUF
↓
gewünschte Quantisierung
Nicht:
irgendeinen vorhandenen Quant
↓
immer weiter verkleinern
Wie wählt man eine Quantisierung praktisch aus?
Die einfachste Frage lautet zunächst:
Wie viel Speicher steht zur Verfügung?
Angenommen, du besitzt:
16 GB VRAM
und möchtest ein Modell mit:
ungefähr 14 Milliarden Parametern
betreiben.
Dann könnte die theoretische Gewichtsschätzung lauten:
FP16
≈ 28 GB
8 Bit
≈ 14 GB
4 Bit
≈ 7 GB
Da noch VRAM für Kontext und Laufzeitdaten benötigt wird, wäre eine geeignete 4- bis 6-Bit-Variante womöglich deutlich komfortabler als 8 Bit.
Zweite Frage: Wie wichtig ist maximale Qualität?
Experiment:
Q4
→ ausreichend gut
Dann:
verwenden.
Wenn:
Q4
→ messbare Probleme
teste:
Q5
und danach:
Q6
Nicht automatisch direkt zur größten Variante springen.
Ein sinnvoller Suchprozess
kleinste plausible Quantisierung
↓
testen
↓
Qualität ausreichend?
├── ja → verwenden
└── nein → nächsthöhere Qualität testen
Damit findest du den kleinsten Speicherbedarf, der deine Qualitätsanforderung erfüllt.
Das ist besser als die größte Variante zu wählen, die gerade noch passt
Denn freier VRAM kann ebenfalls wertvoll sein.
Er kann genutzt werden für:
längeren Kontext
mehr parallele Nutzer
Embeddingmodell
Reranker
größere Batches
Beispiel: Q8 nutzt fast den gesamten VRAM
Modell Q8
→ 15 GB
GPU:
16 GB
Dann bleibt kaum Reserve.
Alternative:
Q5
→ 10 GB
Vielleicht verliert das Modell für deinen Anwendungsfall praktisch kaum Qualität.
Nun bleiben:
6 GB
für:
KV-Cache
und:
weitere Verarbeitung.
Q5 kann dadurch praktisch besser sein, obwohl Q8 numerisch präziser ist.
Die beste Quantisierung ist deshalb systemabhängig
Nicht:
höchste Präzision gewinnt
sondern:
Gesamtsystem funktioniert am besten
Das beinhaltet:
Qualität,
Latenz,
Kontext,
Parallelität,
Kosten.
Ein lokaler Chat hat andere Anforderungen als ein Server
Einzelplatz:
1 Nutzer
Da kann man viel VRAM für maximale Modellqualität reservieren.
Server:
20 Nutzer
Nun kann eine kompaktere Quantisierung mehr parallele Kontexte ermöglichen.
Damit könnte die etwas stärker quantisierte Variante für das Gesamtsystem besser sein.
Batchverarbeitung verändert die Rechnung erneut
Du verarbeitest nachts:
100.000 Texte
Dann zählt:
Durchsatz.
Vielleicht liefert:
Q4
genügend Qualität und deutlich mehr Verarbeitungskapazität.
Ein etwas stärkeres Modell mit Q4 kann eventuell sogar besser sein als ein kleineres Modell in FP16.
Das muss gemessen werden.
Quantisierung und Modellgröße können gegeneinander getauscht werden
Angenommen:
Variante A:
8B
8 Bit
Variante B:
14B
4 Bit
Beide benötigen möglicherweise eine ähnliche Größenordnung an Gewichtsspeicher.
Welche besser ist?
Keine pauschale Antwort.
Das größere, stärker quantisierte Modell kann leistungsfähiger sein.
Oder der Quantisierungsverlust kann bei deiner Aufgabe stärker stören.
Nur ein Test entscheidet.
Genau deshalb ist VRAM allein kein Modellbenchmark
Der Speicherbedarf sagt:
Wie groß ist die Repräsentation?
Nicht:
Wie intelligent ist das Modell?
Quantisierung kann auch Kosten reduzieren
Cloudserver mit:
80-GB-GPU
sind meist teurer als solche mit:
24-GB-GPU
Wenn Quantisierung ein Modell von:
40 GB
auf:
18 GB
reduziert, kann sich die notwendige Hardwareklasse ändern.
Damit wird Quantisierung nicht nur zum technischen, sondern auch zum wirtschaftlichen Werkzeug.
Dasselbe gilt für lokale Hardware
Vielleicht würde ein Modell unquantisiert eine professionelle GPU verlangen.
Quantisiert läuft es auf einer vorhandenen Consumerkarte.
Der Unterschied kann:
tausende Euro
ausmachen.
Quantisierung senkt außerdem Speicherverkehr
Kleinere Gewichte müssen:
von SSD geladen,
in RAM gehalten,
in VRAM übertragen
und während der Inferenz gelesen
werden.
Auch dadurch kann sich das Gesamtsystem verbessern.
Modellladezeiten können sinken
Modelldatei A:
50 GB
Modelldatei B:
12 GB
Beim Laden von SSD und Übertragen in den Speicher ist die kleinere Datei natürlich im Vorteil.
Das fällt besonders auf, wenn Modelle häufig gewechselt werden.
Quantisierung kann mehr Modelle gleichzeitig ermöglichen
GPU:
24 GB
Modell A:
8 GB
Modell B:
5 GB
Embeddingmodell:
1 GB
Nun können mehrere Dienste möglicherweise gleichzeitig resident bleiben.
Ohne Quantisierung würde vielleicht bereits Modell A den gesamten Speicher beanspruchen.
Das ist für einen lokalen KI-Server besonders wertvoll
GPU
├── Chatmodell
├── Embeddings
└── Reranker
oder:
GPU 1
→ großes Modell
GPU 2
→ weitere quantisierte Modelle
Quantisierung wird damit Teil der Infrastrukturplanung.
Auch CPU-Inferenz profitiert
Bei reiner CPU-Inferenz müssen Modellgewichte ebenfalls durch den Speicher bewegt und verarbeitet werden.
Kompaktere Modelle können dadurch:
weniger RAM benötigen
und:
besseren Durchsatz ermöglichen.
Das ist einer der Gründe, warum GGUF-Quantisierungen auch für CPU-basierte lokale KI so verbreitet sind.
Sehr aggressive Quantisierung hat Grenzen
Wenn wir immer weiter reduzieren:
8 Bit
↓
6 Bit
↓
4 Bit
↓
3 Bit
↓
2 Bit
wird irgendwann der Informationsverlust erheblich.
Moderne Verfahren können erstaunlich weit gehen, aber es gibt keinen kostenlosen Weg zu:
0 Bit
+
100 % Qualität
Unter vier Bit wird die Auswahl anspruchsvoller
Es existieren Verfahren im Bereich:
3 Bit
2 Bit
und sogar darunter.
llama.cpp unterstützt heute ebenfalls Quantisierungsklassen in diesem Bereich. Seine eigenen Tabellen zeigen jedoch deutlich, dass niedrige Bitklassen nicht einfach linear mit Qualität oder Geschwindigkeit skalieren. (GitHub)
Für allgemeine lokale Nutzung sind solche extremen Quantisierungen daher eher etwas, das gezielt getestet werden sollte.
2 Bit kann für ein großes Modell trotzdem interessant sein
Angenommen:
ein sehr großes Modell passt sonst überhaupt nicht auf deine Hardware.
Dann lautet die Entscheidung vielleicht:
großes Modell
stark quantisiert
gegen:
kleines Modell
weniger quantisiert
Welche Variante besser ist, kann wiederum nur der reale Anwendungsfall zeigen.
Nicht jede Quantisierung ist auf jeder GPU gleich schnell
Manche GPUs besitzen besonders gute Hardwareunterstützung für:
FP16,
BF16,
INT8
oder bestimmte andere Datentypen.
Eine exotische Quantisierung kann theoretisch extrem kompakt sein, aber schlechter optimierte Kernel besitzen.
Deshalb sollte man bei Serverdeployments immer prüfen:
Hardware
+
Runtime
+
Quantisierung
als Kombination.
Ein Modellformat kann die Hardwarewahl beeinflussen
Wenn dein gesamter Stack:
llama.cpp
+
GGUF
ist, hast du andere optimale Varianten als bei einem Stack mit:
PyTorch
+
Transformers
+
bitsandbytes
oder einem spezialisierten GPU-Serving-System.
Nicht jedes Format ist überall gleich gut unterstützt.
Darum zuerst die Laufzeitumgebung bestimmen
Für einen Heim-PC:
einfaches lokales Serving
kann GGUF hervorragend passen.
Für:
hochparalleles GPU-Serving
kann ein anderes Format attraktiver sein.
Für:
QLoRA-Training
wieder ein anderes.
Quantisierung ist kein isolierter Dateidownload.
Sie gehört zur gesamten Softwarearchitektur.
Was ist Dynamic Quantization?
Bei bestimmten Verfahren wird Quantisierung teilweise während des Ladens oder während der Ausführung vorgenommen.
hochpräzises Modell
↓
Runtime
↓
quantisierte Darstellung
Das kann sehr bequem sein.
Der Nachteil:
Der Quantisierungsschritt muss gegebenenfalls beim Laden durchgeführt werden und die genaue Performance hängt vom Framework ab.
Was ist statische Quantisierung?
Ein Modell wird vorher quantisiert.
Original
↓
Quantisierungsprozess
↓
fertiges quantisiertes Modell
Danach wird genau diese Variante verteilt.
GGUF-Modelle sind häufig bereits in der gewünschten Quantisierung gespeichert.
Vorgerechnete Quantisierung hat Vorteile
einmal quantisieren
↓
viele Male laden
Statt bei jedem Serverstart erneut Arbeit zu investieren.
Außerdem lässt sich genau diese Datei:
testen,
versionieren,
archivieren.
Für produktive Systeme sollte die Quantisierung dokumentiert werden
Nicht nur:
Modell:
XYZ
sondern:
Modell:
XYZ
Version:
...
Quantisierung:
Q5_K_M
Kontext:
...
Engine:
...
Denn dieselbe Modellfamilie kann je nach Quantisierung ein deutlich anderes Verhalten zeigen.
Quantisierung gehört zur Modellversion
Praktisch betrachtet sind:
Modell X BF16
und:
Modell X Q4
nicht vollständig austauschbare Produktionsartefakte.
Sie sollten separat evaluiert werden.
Ein Modellwechsel kann dadurch sehr klein aussehen
Dateiname vorher:
model-Q5.gguf
nachher:
model-Q4.gguf
Aber daraus können folgen:
anderer VRAM-Bedarf,
andere Geschwindigkeit,
andere Qualität.
Deshalb sollte auch ein Quantisierungswechsel durch Tests gehen.
Ein guter Produktionsprozess
neue Quantisierung
↓
Testset
↓
Qualitätsvergleich
↓
Performancevergleich
↓
Shadow Test
↓
Produktionsfreigabe
Dasselbe Prinzip wie bei einem neuen Modell.
Quantisierung kann für unterschiedliche Aufgaben unterschiedlich gewählt werden
Ein Server könnte sogar dasselbe Grundmodell mehrfach halten.
Q4
→ Batchklassifikation
Q6
→ hochwertige Textgenerierung
Der Workflow entscheidet je nach Aufgabe.
Ob das sinnvoll ist, hängt davon ab, ob genug Speicher für mehrere Varianten vorhanden ist.
Modellrouting und Quantisierung können zusammenspielen
Zum Beispiel:
einfache Aufgabe
↓
kleines Modell Q4
mittlere Aufgabe
↓
größeres Modell Q4
anspruchsvolle Aufgabe
↓
größeres Modell Q6
Damit wird nicht nur zwischen Modellen, sondern zwischen Qualitätsstufen geroutet.
Für RAG muss nicht automatisch höchste Präzision verwendet werden
Ein gutes RAG-System liefert dem Modell hochwertige relevante Quellen.
Dadurch kann ein mittelgroßes quantisiertes Modell bei bestimmten Wissensfragen hervorragend funktionieren.
Die Qualität des Retrievals kann wichtiger sein als der Unterschied zwischen:
Q5
und:
Q8
Das muss allerdings mit realen Fragen geprüft werden.
Embeddingmodelle können ebenfalls quantisiert werden
Auch Embeddings werden von neuronalen Modellen erzeugt.
Diese Modelle können ebenfalls von niedrigeren Präzisionen profitieren.
Dabei sollte aber besonders getestet werden:
Verändert sich die Qualität der semantischen Suche?
Denn kleine Änderungen in Embeddings können Rankings beeinflussen.
Reranker ebenso
Ein Reranker bewertet:
Query
+
Dokument
und sortiert Suchergebnisse.
Wenn eine Quantisierung dessen Rankingqualität verschlechtert, kann die gesamte RAG-Pipeline schlechter werden.
Deshalb gilt wiederum:
Optimierung nicht isoliert betrachten.
Fine-Tuning und Quantisierung lösen unterschiedliche Probleme
Quantisierung:
Wie speichere und betreibe ich
das Modell effizienter?
Wie verändere ich
das Verhalten des Modells?
Man kann beide kombinieren.
Aber eine Quantisierung macht ein Modell nicht automatisch fachlich besser.
Quantisierung repariert keinen schlechten Prompt
Prompt schlecht.
Modell antwortet schlecht.
Q8 statt Q4:
vielleicht weiterhin schlecht.
Zuerst:
Aufgabe,
Prompt,
Kontext,
Retrieval
prüfen.
Nicht jedes Qualitätsproblem ist ein Präzisionsproblem.
Quantisierung repariert auch keine fehlenden Fakten
Ein Modell kennt eine Information nicht.
Dann hilft:
Q8
statt:
Q4
nicht zwingend.
Vielleicht brauchst du:
RAG
oder:
API.
Quantisierung ist Speicheroptimierung, kein Wissensupdate.
Ebenso wenig beseitigt sie Halluzinationen
Ein nicht quantisiertes Modell kann halluzinieren.
Ein quantisiertes ebenfalls.
Die KI-Halluzinationen müssen über:
Quellen,
Validierung,
RAG,
Systemarchitektur
behandelt werden.
Wann sollte man möglichst hohe Präzision verwenden?
Zum Beispiel beim:
Erstellen einer Referenzbaseline.
Wenn du prüfen möchtest:
Wie gut kann dieses Modell maximal auf meiner Aufgabe sein?
Dann ist eine hochwertige Variante sinnvoll.
Baseline
↓
BF16 / hohe Qualität
Danach:
Q8
Q6
Q5
Q4
vergleichen.
Ohne Baseline weißt du nicht, was Quantisierung kostet
Angenommen Q4 erzielt:
86 % Genauigkeit
Ist das gut?
Vielleicht erreicht das Original:
87 %
Dann hervorragend.
Vielleicht erreicht es:
98 %
Dann ist der Quantisierungsverlust problematisch.
Man braucht einen Referenzwert.
Der richtige Test lautet deshalb nicht
Funktioniert Q4?
Sondern:
Wie viel verliere ich gegenüber meiner Qualitätsbaseline – und ist dieser Verlust für die Speicherersparnis akzeptabel?
Das ist eine wesentlich bessere Frage.
Quantisierung sollte am End-to-End-Ergebnis gemessen werden
Bei einem Contentworkflow könnte die relevante Frage sein:
Wie viele Texte bestehen die
redaktionelle Qualitätsprüfung?
Nicht nur:
Wie hoch ist die Perplexity?
Bei einem Supportsystem:
Wie viele Tickets werden
richtig klassifiziert?
Bei RAG:
Wie häufig wird die Frage
korrekt und quellenbasiert beantwortet?
Ein praktischer Quantisierungstest
Nehmen wir beispielsweise 100 repräsentative Aufgaben.
Referenz:
BF16
Dann:
Q8
Q6
Q5
Q4
Für jede Variante messen:
Aufgabenqualität
Formatfehler
Halluzinationen
Tokens pro Sekunde
VRAM
Modellgröße
Nun entsteht eine Entscheidungsgrundlage.
Die Ergebnisse könnten beispielsweise so aussehen
Nur als hypothetisches Beispiel:
BF16
Qualität: 100 %
VRAM: hoch
Q8
Qualität: 99,8 %
VRAM: deutlich geringer
Q6
Qualität: 99,5 %
VRAM: geringer
Q5
Qualität: 99 %
VRAM: nochmals geringer
Q4
Qualität: 97 %
VRAM: sehr gering
Wenn deine Mindestanforderung:
98 %
lautet, wäre Q5 vielleicht der beste Kompromiss.
Nicht BF16.
Nicht Q4.
Genau darin liegt die Idee des Sweet Spots
möglichst klein
aber:
noch ausreichend gut
Der Sweet Spot hängt vom konkreten Einsatz ab.
Für interaktive Experimente kann man aggressiver sein
Du möchtest:
lokale Modelle ausprobieren.
Dann ist ein Q4-Modell vielleicht perfekt.
Kleine Datei.
Schnell geladen.
Passt auf vorhandene GPU.
Ein kleiner Qualitätsverlust spielt kaum eine Rolle.
Für kritische Extraktion kann man konservativer sein
Beispiel:
Vertragsdaten.
Beträge.
Fristen.
Wenn ein Quantisierungsschritt messbar mehr Fehler verursacht:
höhere Präzision verwenden.
Oder:
das Ergebnis durch deterministische Validierung absichern.
Für Massendaten kann Speicherersparnis enorm wichtig sein
Du klassifizierst:
Millionen Datensätze.
Ein Q4-Modell erreicht fast dieselbe Qualität, aber wesentlich mehr Durchsatz.
Dann kann es wirtschaftlich klar überlegen sein.
Quantisierung ist damit eine wirtschaftliche Stellschraube
mehr Präzision
→ mehr Hardware
gegen:
mehr Quantisierung
→ weniger Hardware
bis die Qualität unter deine Grenze fällt.
Ein lokaler KI-Server sollte mehrere Größenordnungen kennen
Nicht zwangsläufig jede Quantisierung installieren.
Aber sinnvoll dokumentieren:
Standard:
Q5
High Quality:
Q8
Low Resource:
Q4
Dann können Workflows gezielt entscheiden.
Manche Modelle werden bereits speziell quantisiert veröffentlicht
Dann brauchst du nicht selbst quantisieren.
Das ist bequem.
Trotzdem sollte geprüft werden:
Wer hat die Datei erstellt?
Von welchem Original?
Mit welcher Methode?
Welche Lizenz?
Welche Checksums beziehungsweise Herkunft?
Lokale Modelldateien sind ausführbarer beziehungsweise von Software geladener Datenbestand und sollten aus vertrauenswürdigen Quellen stammen.
Quantisierte Modelle sind nicht automatisch sicher
Quantisierung betrifft:
numerische Repräsentation.
Nicht:
Modellsicherheit.
Ein Q4-Modell kann genauso:
gefährliche Inhalte erzeugen,
Prompt Injection verarbeiten,
falsche Toolaufrufe vorschlagen
wie eine andere Modellvariante.
Sicherheitsarchitektur bleibt separat notwendig.
Bei Agenten gilt das besonders
Ein KI-Agent mit stark quantisiertem Modell könnte eventuell häufiger:
Tool falsch auswählen,
Argumente verwechseln,
Instruktionen missverstehen.
Wenn das bei deinem Modell tatsächlich messbar ist, kann eine höhere Präzision für den Agenten sinnvoll sein.
Aber auch ein unquantisiertes Modell darf nicht unbegrenzt handeln.
Agentensicherheit darf nicht von Quantisierung abhängen
Agent
↓
Tool
↓
Berechtigungsprüfung
↓
Business Rules
↓
eventuell Human Approval
Diese Kontrollschichten bleiben identisch.
Quantisierung beeinflusst auch den Modellserver
Kleineres Modell:
weniger VRAM
Dadurch vielleicht:
mehr parallele Requests
oder:
mehr KV-Cache
oder:
zweite Modellinstanz
Damit kann dieselbe Hardware mehr Nutzer bedienen.
Ein Server kann dadurch horizontal weniger Hardware benötigen
Beispiel:
Unquantisiert braucht jede Modellinstanz:
40 GB
Quantisiert:
15 GB
Nun könnten auf einer entsprechend großen GPU möglicherweise mehrere Instanzen beziehungsweise größere Servingreserven möglich werden.
Das kann Infrastrukturkosten massiv verändern.
Quantisierung kann aber GPU-Auslastung verändern
Kleinere Gewichte reduzieren Speicherverkehr.
Gleichzeitig können bestimmte Quantisierungs-Kernel mehr Rechenoperationen benötigen.
Ob eine GPU danach:
schneller
oder:
langsamer
läuft, hängt von ihrem Flaschenhals ab.
Deshalb:
Benchmark.
Was ist die beste Quantisierung für lokale KI?
Es gibt keine allgemeingültige Antwort.
Für viele Anwender ist die sinnvollste Denkweise:
Q4
→ erste kompakte Testvariante
Q5 / Q6
→ mögliche Qualitäts-/Größenkompromisse
Q8
→ hohe Präzision bei weiterhin reduziertem Speicher
BF16 / FP16
→ hochwertige Referenz,
wenn Hardware ausreichend
Das ist bewusst keine starre Empfehlung für jedes Modell.
Moderne Q4-Varianten sind häufig ein guter Startpunkt
Nicht weil:
vier Bit magisch optimal wären.
Sondern weil sie:
erhebliche Speicherersparnis
mit oft noch brauchbarer bis sehr guter Modellqualität
kombinieren.
Welche Q4-Variante sinnvoll ist, hängt vom konkreten Ökosystem ab.
Wenn Q4 schlecht funktioniert, nicht sofort Modell verwerfen
Teste zuerst:
Q5
oder:
Q6
Vielleicht liegt das Qualitätsproblem nur an einer zu aggressiven Quantisierung.
Wenn Q8 ebenfalls schlecht ist, liegt es wahrscheinlich eher am Modell
Dann bringt:
noch mehr Präzision
möglicherweise wenig.
Vielleicht ist das Grundmodell für die Aufgabe ungeeignet.
Das ist ein wichtiger Diagnoseweg.
Ein hilfreicher Testbaum
Modell grundsätzlich gut?
│
├── nein
│ → anderes Modell
│
└── ja
↓
Q4 testen
│
├── ausreichend
│ → verwenden
│
└── nicht ausreichend
↓
Q5 / Q6 testen
↓
immer noch nicht ausreichend?
↓
Q8 / hohe Präzision vergleichen
Damit trennt man:
Modellproblem
von:
Quantisierungsproblem.
Speicherberechnung bleibt trotzdem nur eine Näherung
Angenommen:
32B
×
4 Bit
÷
8
=
16 GB
Das heißt nicht:
Eine 16-GB-GPU reicht.
Denn wir wissen aus dem Artikel über VRAM:
Gewichte
+
Quantisierungsoverhead
+
KV-Cache
+
Runtime
+
Reserve
müssen gemeinsam hineinpassen.
Ein reales Q4 kann eher fünf als vier Bit pro Gewicht benötigen
Wie bereits erwähnt, liegen konkrete GGUF-Quantisierungen durch zusätzliche Blockinformationen über der nominalen Bitbreite. Die aktuelle llama.cpp-Tabelle zeigt für Q4_K_M beim dort getesteten Modell rund 4,9 Bit pro Gewicht. (GitHub)
Die Überschlagsformel ist daher nur:
erste Größenordnung
nicht:
exakte Kaufentscheidung
Der Dateidownload liefert einen besseren Anhaltspunkt
Wenn die konkrete Modelldatei:
18 GB
groß ist, weißt du:
Die Gewichte und zugehörigen Quantisierungsinformationen liegen ungefähr in dieser Größenordnung.
Trotzdem braucht die Runtime zusätzlich Speicher.
Deshalb Modell tatsächlich laden
Die beste Methode bleibt:
gewünschte Modelldatei
↓
gewünschte Engine
↓
gewünschter Kontext
↓
VRAM messen
Keine theoretische Formel ist genauer als dein reales System.
Beim Modellserver zusätzlich Parallelität testen
1 Request
↓
VRAM
dann:
2 Requests
↓
VRAM
dann:
realistische Anzahl paralleler Nutzer
↓
VRAM
Erst dann weißt du, ob die Konfiguration produktionsgeeignet ist.
Quantisierung und Kontext sollten gemeinsam optimiert werden
Du hast zwei Möglichkeiten:
Q8
+
kleiner Kontext
oder:
Q5
+
großer Kontext
Welche besser ist?
Für einen Chat über lange Dokumente könnte:
mehr Kontext
wichtiger sein als die zusätzliche Gewichtpräzision.
Für kurze komplexe Mathematik könnte:
höhere Modellpräzision
wichtiger sein.
Wieder entscheidet der Workload.
Quantisierung und Parallelität konkurrieren ebenfalls um VRAM
Ein:
Q8-Modell
kann vielleicht:
einen Nutzer
bedienen.
Dasselbe Modell in Q4:
vielleicht:
mehrere gleichzeitig.
Dann ist die etwas niedrigere Präzision wirtschaftlich möglicherweise klar sinnvoller.
Quantisierung macht lokale KI überhaupt erst flexibel
Ohne Quantisierung wäre Hardwarewahl häufig binär:
Modell passt
oder
Modell passt nicht
Mit Quantisierung entsteht ein Spektrum:
mehr Qualität
↔
weniger Speicher
und damit viele sinnvolle Kompromisse.
Was du dir über Quantisierung merken solltest
Quantisierung reduziert die numerische Präzision eines KI-Modells, um Speicherbedarf und häufig auch den Rechenaufwand beziehungsweise Speicherverkehr zu verringern. Moderne Frameworks verwenden dafür unterschiedliche Verfahren von 8 und 4 Bit bis hin zu noch niedrigeren Präzisionen. (Hugging Face)
Ein Sprachmodell besteht aus Milliarden Parametern.
Der theoretische Gewichtsspeicher lässt sich grob abschätzen über:
Parameter
×
Bits
÷
8
Ein Modell mit zehn Milliarden Parametern benötigt damit theoretisch ungefähr:
FP32
→ 40 GB
FP16 / BF16
→ 20 GB
8 Bit
→ 10 GB
4 Bit
→ 5 GB
Das sind lediglich Größenordnungen für die Gewichte.
Der reale VRAM-Bedarf ist höher beziehungsweise komplexer, weil zusätzlich:
Quantisierungsmetadaten
KV-Cache
temporäre Daten
Runtime
Parallelität
Speicher benötigen.
Ein Q4-Modell besitzt zudem nicht zwangsläufig exakt vier Bit pro Gewicht. Blockskalen und andere Zusatzinformationen erhöhen den effektiven Speicherbedarf; konkrete llama.cpp-Quantisierungen zeigen diesen Unterschied deutlich. (GitHub)
Quantisierung bedeutet:
Originalwert
↓
kompaktere Näherung
Dabei entsteht:
Quantisierungsfehler
Moderne Verfahren versuchen diesen Fehler intelligent zu minimieren.
Manche berücksichtigen beispielsweise besonders empfindliche Gewichtsteile.
AWQ nutzt Aktivierungsinformationen, um wichtige Gewichte bei niedriger Bitbreite besser zu schützen. (Proceedings MLSys)
GPTQ verwendet wiederum ein anderes Post-Training-Verfahren zur möglichst genauen Kompression großer Transformermodelle. (arXiv)
GGUF sollte dabei nicht mit einer Quantisierungsmethode verwechselt werden.
GGUF
→ Dateiformat
innerhalb dessen unterschiedliche:
F32
BF16
Q8
Q6
Q5
Q4
...
Tensorrepräsentationen gespeichert werden können. (Hugging Face)
Auch:
Q4_K_M
GPTQ 4-bit
AWQ 4-bit
NF4
sind nicht automatisch dasselbe.
Sie gehören zu unterschiedlichen Quantisierungsverfahren beziehungsweise Softwareökosystemen.
Für Fine-Tuning ist insbesondere QLoRA interessant.
4-Bit-Basismodell
↓
eingefroren
↓
LoRA-Adapter trainieren
Dadurch kann der Speicherbedarf gegenüber vollständigem Fine-Tuning massiv reduziert werden. (arXiv)
Quantisierung hat vor allem vier mögliche Vorteile:
kleinere Modelldatei
weniger RAM
weniger VRAM
potenziell höhere Inferenzgeschwindigkeit
Der letzte Punkt ist allerdings nicht garantiert.
weniger Bits
≠
automatisch schneller
Die Geschwindigkeit hängt von:
Hardware,
Kernel,
Engine,
Speicherbandbreite,
Quantisierung
ab.
Deshalb sollte man immer messen.
Die zentrale praktische Strategie lautet:
hochwertige Referenz
↓
Q8
↓
Q6
↓
Q5
↓
Q4
↓
Qualität vergleichen
Das Ziel ist nicht:
die kleinste Datei.
Und auch nicht:
die höchstmögliche Präzision.
Das Ziel ist:
die kleinste Variante, die deine Qualitätsanforderungen zuverlässig erfüllt.
Genau dieser Punkt ist bei lokaler KI entscheidend.
Denn jeder eingesparte Gigabyte VRAM kann anschließend genutzt werden für:
größeres Modell
mehr Kontext
mehr parallele Nutzer
weitere KI-Modelle
Damit wird Quantisierung nicht nur zu einem Kompressionsverfahren.
Sie ist ein zentraler Bestandteil der Architektur und Wirtschaftlichkeit lokaler KI.