← Resources
By Ren Sugaya
— Performance Engineer, GPU & Inference
·
· INSIGHT
LLM-Quantisierung erklärt: GGUF, Q4 vs Q8 und Qualität
Quantisierung verkleinert ein LLM, indem seine Gewichte mit geringerer Präzision gespeichert werden, wodurch sich der VRAM-Bedarf bei 4-Bit etwa vervierfacht reduziert. Diese Anleitung erklärt die VRAM-Berechnung, entschlüsselt GGUF-Quantisierungsnamen wie Q4_K_M, vergleicht GGUF mit GPTQ und AWQ und zeigt, wo die Qualität tatsächlich nachlässt.
Was Quantisierung ist und warum sie wichtig ist
Quantisierung reduziert die numerische Präzision, mit der Modellgewichte gespeichert werden — typischerweise von FP16 (16 Bit, 2 Byte pro Gewicht) auf 8-Bit oder 4-Bit. Da der Speicher linear mit den Bits pro Gewicht skaliert, benötigt 4-Bit etwa viermal weniger VRAM als FP16. Das beschleunigt auch die Inferenz, da die Token-Generierung durch die Speicherbandbreite begrenzt wird, nicht allein durch die Rechenleistung.
Die Größenberechnung ist einfach: Byte ≈ (Parameter × Bits-pro-Gewicht) ÷ 8. Ein 8B-Modell in FP16 ist etwa 16 GB groß; bei 4-Bit sind es rund 4,5 GB. Dieser Unterschied macht aus einem Modell, das eine Rechenzentrums-GPU benötigt, eines, das auf einem Laptop läuft.
GGUF ist ein Dateiformat, keine Methode
GGUF ist ein Einzeldateiformat, das quantisierte Gewichte zusammen mit den Modell-Metadaten (Tokenizer, Architektur, Hyperparameter) speichert. Es ist der Nachfolger von GGML aus dem llama.cpp-Projekt, optimiert für CPU, Apple Silicon (Metal) und gemischten CPU/GPU-Offload — weshalb es die lokale und Laptop-Inferenz über llama.cpp, Ollama und LM Studio dominiert.
Die Quantisierungsstufe steht im Dateinamen. Die Zahl ist der Durchschnitt der Bits pro Gewicht; `_K` steht für k-Quants (die moderne Superblock-Methode mit doppelt quantisierten Skalierungsfaktoren und schichtsensitiver Bitzuteilung); `_S`, `_M`, `_L` sind die kleine, mittlere und große Variante. `_M` hält sensible Schichten — Attention und Output — selektiv auf höherer Präzision, weshalb Q4_K_M eine gleichmäßige 4-Bit-Quantisierung übertrifft.
Q4 vs Q5 vs Q8: Größe und Qualität, mit Zahlen
Eine peer-reviewte Evaluierung auf Llama-3.1-8B macht die Kompromisse greifbar (die Größen gelten für dieses Modell; die Verhältnisse lassen sich verallgemeinern). Gegenüber einer FP16-Basisperplexität von etwa 7,32 (niedriger ist besser):
- Q8_0 — 8,5 Bit/Gewicht, ~7,95 GiB, Perplexität 7,33: praktisch verlustfrei.
- Q6_K — 6,56 bpw, ~6,14 GiB, Perplexität 7,35.
- Q5_K_M — 5,70 bpw, ~5,33 GiB, Perplexität 7,40.
- Q4_K_M — 4,89 bpw, ~4,58 GiB, Perplexität 7,56: der praktische Sweet Spot, unter einem halben Prozent unter dem Basiswert.
- Q3 und darunter — starke, konsistente Verschlechterung, besonders bei Reasoning-Aufgaben.
Der Bereich von 4 bis 5 Bit ist die sichere Zone. Unterhalb von 3 Bit braucht man Importance-Matrix-Quants (IQ), die Kalibrierungsdaten nutzen, um Präzision dort einzusetzen, wo sie am wichtigsten ist — nutzbar, aber nur als letzter Ausweg bei sehr knappem Speicher.
GGUF vs GPTQ vs AWQ
GGUF ist nicht die einzige Option; die richtige hängt davon ab, wo man das Modell ausführt.
- GGUF: entwickelt für CPU, Mac und gemischten Offload. Wählen Sie es für lokale und Desktop-Inferenz.
- GPTQ: nach dem Training, kalibrierungsbasiert, nutzt Informationen zweiter Ordnung, um den Fehler pro Schicht zu minimieren. Am präzisesten Gewicht für Gewicht bei einer gegebenen Bitbreite, aber langsam zu erzeugen und auf GPU-Serving ausgerichtet (vLLM, TGI, TensorRT-LLM).
- AWQ: schützt die rund 1 % wichtigsten Gewichte anhand der Aktivierungsmagnituden; schneller zu erzeugen als GPTQ und GPU-optimiert bei 4-Bit.
- bitsandbytes: quantisiert beim Laden zur Laufzeit, ohne vorquantisierten Checkpoint oder Kalibrierung — der einfachste Weg, weit verbreitet für QLoRA-Finetuning.
Die praktische Aufteilung: GGUF für lokal und Laptop, AWQ oder GPTQ für den Durchsatz auf GPU-Servern.
Wie viel Qualität verliert man wirklich?
Weniger, als die meisten bei 4-Bit befürchten, und mehr, als sie unterhalb von 3-Bit erwarten. Bei der Evaluierung von Llama-3.1-8B lag Q8 innerhalb der Rundungsgenauigkeit der vollen Präzision, Q4_K_M verlor unter einem halben Prozent bei durchschnittlichen Benchmarks, und der Einbruch trat bei 3-Bit auf, mit der deutlichsten Verschlechterung bei reasoning-intensiven Evaluierungen wie Grundschulmathematik. Beachten Sie, dass absolute Perplexitäts- und Größenwerte modellspezifisch sind — die Prozentwerte lassen sich verallgemeinern, aber prüfen Sie die Zahlen immer für Ihr Basismodell. Und planen Sie VRAM über die Dateigröße hinaus ein: Der KV-Cache und etwa 10–15 % Framework-Overhead benötigen ebenfalls Spielraum.
Quantisierung in osFoundry
Eine Quantisierung zu wählen bedeutet normalerweise, Bits-pro-Gewicht zu verstehen, Platz für den KV-Cache zu lassen und sich durch eine Wand kryptischer GGUF-Suffixe zu wühlen, um die eine Datei zu finden, die passt, ohne abzustürzen. Die lokale Inferenz von osFoundry nimmt Ihnen diesen Schritt ab: Sie erkennt Ihren verfügbaren Speicher und wählt automatisch die richtige Quantisierung — Q4_K_M bei knappem VRAM, Q5_K_M oder Q8_0, wenn Spielraum vorhanden ist — sodass das Modell mit der besten Qualität läuft, die Ihre Hardware unterstützt. Der Katalog zeigt nur kompatible Builds statt jeder Variante und greift bei Bedarf elegant auf eine leichtere Quantisierung zurück, wenn eine schwerere nicht passt. Sie erhalten den optimalen Kompromiss zwischen Größe und Qualität eines handverlesenen GGUF, ohne wissen zu müssen, was Q4_K_M bedeutet.
Frequently asked questions
- Was ist LLM-Quantisierung in einfachen Worten?
- Es bedeutet, die Gewichte eines Modells mit geringerer numerischer Präzision zu speichern — zum Beispiel 4-Bit statt 16-Bit — um es zu verkleinern. Da der Speicher mit den Bits pro Gewicht skaliert, benötigt die 4-Bit-Quantisierung etwa viermal weniger VRAM als FP16 und läuft schneller, bei einem geringen und meist akzeptablen Qualitätsverlust.
- Wofür steht GGUF und was ist es?
- GGUF ist das Einzeldatei-Modellformat des llama.cpp-Projekts (der Nachfolger von GGML), das quantisierte Gewichte mit den Modell-Metadaten bündelt. Es ist für CPU, Apple Silicon und gemischte CPU/GPU-Inferenz optimiert, weshalb es der Standard für lokale Tools wie llama.cpp, Ollama und LM Studio ist. Es ist ein Dateiformat, kein Quantisierungsalgorithmus.
- Was ist der Unterschied zwischen Q4, Q5 und Q8?
- Die Zahl ist der Durchschnitt der Bits pro Gewicht, also ist Q8 größer und originalgetreuer als Q5, das wiederum größer als Q4 ist. Bei einem typischen 8B-Modell ist Q8 mit etwa 8 GB nahezu verlustfrei, Q5_K_M liegt mit etwa 5,3 GB eine Stufe darunter, und Q4_K_M ist der Sweet Spot zwischen Größe und Qualität mit etwa 4,6 GB und unter einem halben Prozent Qualitätsverlust.
- Welche GGUF-Quantisierung sollte ich verwenden?
- Q4_K_M in den meisten Fällen — es ist die beste Balance aus Größe und Qualität und der Standard-Ausgangspunkt. Wechseln Sie zu Q5_K_M oder Q8_0, wenn Sie VRAM übrig haben und höhere Wiedergabetreue wünschen, und gehen Sie nur unter Q4 (mit Importance-Matrix-IQ-Quants), wenn der Speicher wirklich knapp ist, da die Qualität bei 3-Bit und darunter stark abfällt.
- Wie viel Qualität verliert man bei 4-Bit-Quantisierung?
- Überraschend wenig. Bei einer peer-reviewten Evaluierung von Llama-3.1-8B lag Q4_K_M bei durchschnittlichen Benchmarks unter einem halben Prozent unter dem Vollpräzisions-Basiswert. Die spürbare Verschlechterung beginnt bei 3-Bit, besonders bei Reasoning- und Mathe-Aufgaben. Die genauen Zahlen variieren je nach Modell, aber 4 bis 5 Bit gilt weithin als sichere Zone.
- GGUF vs GPTQ vs AWQ — welches soll ich wählen?
- GGUF für lokale, Laptop- und Apple-Silicon-Inferenz über llama.cpp oder Ollama. GPTQ und AWQ speichern ein GPU-freundliches Layout und sind die bessere Wahl für GPU-Server-Durchsatz mit vLLM oder TGI — AWQ ist schneller zu erzeugen, GPTQ ist oft das genaueste Gewicht für Gewicht. bitsandbytes ist am einfachsten, da es ohne Kalibrierung beim Laden quantisiert.
- Wie berechne ich den VRAM-Bedarf eines quantisierten Modells?
- Verwenden Sie Byte ≈ (Parameter × Bits-pro-Gewicht) ÷ 8. Bei 4-Bit sind das etwa 0,5 bis 0,6 GB pro Milliarde Parameter, also rund 4,5 GB für ein 8B-Modell. Rechnen Sie dann Puffer für den KV-Cache und etwa 10 bis 15 % Framework-Overhead hinzu — der Speicherbedarf zur Laufzeit ist immer größer als die Datei auf der Festplatte.
Sources