Quantisierung erklärt: GGUF, GPTQ, AWQ — was passt wann?

Ein Llama 3.3 70B in voller FP16-Präzision belegt rund 140 GB VRAM — das passt auf keine einzelne Datacenter-GPU außer einer H200 oder B200. Mit Quantisierung schrumpft das gleiche Modell auf 38 GB und läuft auf einer L40S. Die Frage ist also weniger ob, sondern wie stark und mit welcher Methode man quantisiert. Die Antwort hängt davon ab, ob Sie GPU- oder CPU-Inferenz fahren, welche Toolchain Sie nutzen und wie kritisch Latenz, Durchsatz und Qualität in Ihrem Use-Case sind.

1. Was Quantisierung tatsächlich tut

Sprachmodelle bestehen aus Milliarden Gewichten — Fließkommazahlen, die in der Regel als FP16 oder BF16 gespeichert werden, je 16 Bit pro Wert. Quantisierung ersetzt diese 16-Bit-Werte durch kompaktere Repräsentationen: INT8 (8 Bit), INT4 (4 Bit), in extremen Fällen INT2. Bei 4 Bit speichern wir nur noch 16 mögliche Werte pro Gewicht statt 65.536 — der Speicherbedarf sinkt um den Faktor vier.

Naiv wäre das eine Katastrophe für die Modellqualität. Moderne Verfahren behelfen sich mit zwei Tricks: Erstens werden Gewichte in Gruppen quantisiert (typisch 128 Werte pro Gruppe), für jede Gruppe wird ein eigener Skalierungsfaktor gespeichert. Zweitens wird der Quantisierungsschritt mit Calibration-Daten optimiert — typischerweise einigen tausend Tokens repräsentativen Texts. So wird sichergestellt, dass die Quantisierungsraster dort fein sind, wo das Modell empfindlich reagiert.

Das Resultat ist erstaunlich gut: Bei 4 Bit liegt der Qualitätsverlust messbarer Benchmarks (MMLU, HumanEval) meist unter einem Prozentpunkt. Subjektiv erkennen selbst geübte Nutzer den Unterschied zwischen FP16 und 4-Bit-AWQ in produktiven Aufgaben kaum.

2. Qualitätsverlust messen: PPL, MMLU und Praxistests

Drei Metriken haben sich für Quantisierungsvergleiche etabliert. Perplexity (PPL) misst, wie überrascht das Modell von einem Referenztext ist — niedrigere Werte sind besser. PPL ist hochempfindlich und zeigt selbst kleine Numerikverschiebungen. Ein Anstieg von 5,12 auf 5,18 (etwa 1 Prozent) ist messbar, in der Praxis aber unmerklich.

MMLU testet Faktenwissen über 57 Fachgebiete in Multiple-Choice-Form. Hier erwarten wir bei guter 4-Bit-Quantisierung höchstens 0,5–1,5 Prozentpunkte Verlust gegenüber FP16. Sinkt MMLU um mehr als 2 Punkte, ist die Quantisierung kaputt — typischerweise zu kleine Group-Size, zu wenig Calibration-Daten oder eine ungeeignete Methode für die Modellarchitektur.

Wichtiger als beide Metriken ist der Praxistest mit echten Use-Case-Prompts. Wir empfehlen, vor jedem Produktivgang 50 repräsentative Anfragen aus dem geplanten Einsatzfeld doppelt zu schicken — einmal an FP16, einmal an die Quantisierung — und die Antworten blind von Fachanwendern bewerten zu lassen. Diese Methode deckt Verschlechterungen auf, die kein Benchmark zeigt.

3. GGUF: CPU-freundlich und überall einsetzbar

GGUF ist das Format der llama.cpp-Familie, dem Open-Source-Projekt von Georgi Gerganov. Es wurde primär für CPU-Inferenz entworfen und ist heute das Lingua Franca lokaler Edge-Inferenz. GGUF-Dateien sind eigenständig (alle Tokenizer, Metadaten und Gewichte in einer Datei), portabel über Linux, macOS, Windows und kompatibel mit GPU-Offloading: Sie können beliebig viele Layer auf die GPU verschieben, der Rest läuft auf der CPU.

GGUF kennt Quantisierungsstufen von Q2 bis Q8 sowie spezialisierte Varianten wie Q4_K_M (4-Bit mit gemischter Präzision) und IQ3_XS (3-Bit mit Importance-Aware-Quantisierung). Q4_K_M ist die meistverwendete Variante: gute Qualität, kompakte Größe, schnell auf modernen CPUs. Auf Apple Silicon ist GGUF mit llama.cpp und Metal-Backend die schnellste Option überhaupt — schneller als MLX bei vergleichbarer Qualität.

Schwäche: Auf NVIDIA-Server-Hardware mit vLLM oder TensorRT-LLM ist GGUF nicht das Format der Wahl. Die GPU-Kernel sind weniger optimiert als bei AWQ, der Throughput liegt 30–50 Prozent unter dem, was GPTQ oder AWQ liefern. Wer einen Datacenter-Server betreibt, sollte GGUF nicht als Primärformat einsetzen.

4. GPTQ: Der Klassiker für GPU-Inferenz

GPTQ (Generative Pre-trained Transformer Quantization) wurde 2023 von der ETH Zürich vorgestellt und war jahrelang das Standardformat für Server-GPU-Inferenz. Es ist ein Post-Training-Verfahren: Ein bereits trainiertes Modell wird mit etwa 128 Calibration-Samples quantisiert, dabei werden die Gewichte spaltenweise so angepasst, dass der Quantisierungsfehler minimiert wird. Die Quantisierung selbst dauert auf einer A100 für ein 70B-Modell rund 2–4 Stunden.

GPTQ-Quantisierungen sind in vLLM, TGI, ExLlama und der Transformers-Bibliothek nativ unterstützt. Typische Konfiguration: 4 Bit, Group-Size 128, Act-Order aktiviert. Damit erhalten Sie auf NVIDIA-GPUs etwa 90 Prozent des FP16-Throughputs bei einem Viertel des Speicherbedarfs.

Schwäche: Bei sehr großen Modellen (70B+) und niedrigen Bit-Tiefen (3 Bit) zeigt GPTQ stärkere Qualitätsverluste als AWQ. Außerdem ist die Inferenz-Performance bei kleinen Batches nicht optimal — hier hat AWQ mit dem Marlin-Kernel inzwischen die Nase vorn.

5. AWQ: Activation-Aware und derzeit beste Balance

AWQ (Activation-Aware Weight Quantization) ist die jüngste Generation und 2026 unsere Standardempfehlung für GPU-Inferenz. Die Kernidee: Nicht alle Gewichte sind gleich wichtig. Während der Calibration misst AWQ, welche Eingaben besonders große Aktivierungen erzeugen, und schützt die zugehörigen "salienten" Gewichte (typisch das oberste Prozent) vor grober Quantisierung. Diese Gewichte bleiben in höherer Präzision, der Rest wird aggressiv komprimiert.

Das Ergebnis ist messbar besser als GPTQ bei gleicher Bit-Tiefe. Bei Llama 3.3 70B liegt die MMLU-Differenz von AWQ-Q4 zu FP16 bei nur 0,3 Prozentpunkten, GPTQ-Q4 verliert etwa 0,8. Auf vLLM mit dem Marlin-Kernel erreicht AWQ-Q4 sogar höheren Throughput als FP16 bei kleinen Batches, weil weniger Daten durch den Speicher geschoben werden müssen.

Praktisch: Suchen Sie auf Hugging Face nach casperhansen/[modellname]-awq oder solidrust/[modellname]-AWQ — beide pflegen aktuelle Quantisierungen in hoher Qualität. In vLLM aktivieren Sie AWQ mit --quantization awq_marlin.

6. Die Vergleichsmatrix

Die folgende Tabelle fasst die Charakteristiken zusammen. Werte beziehen sich auf 4-Bit-Quantisierung eines 70B-Modells, gemessen auf vLLM bzw. llama.cpp mit aktuellem Hardware-Stand.

Methode	VRAM-Reduktion	Qualitätsverlust (MMLU)	Inferenz-Speed (rel. FP16)	Empfohlener Stack
GGUF Q4_K_M	~73 %	−0,8 PP	~50 % auf GPU ~100 % auf CPU/Apple	llama.cpp, Ollama, LM Studio
GPTQ 4-bit	~75 %	−0,8 PP	~85 %	vLLM, ExLlamaV2, TGI
AWQ 4-bit	~73 %	−0,3 PP	~95–105 % (Marlin)	vLLM, TensorRT-LLM
EXL2 (4.65 bpw)	~71 %	−0,4 PP	~110 % (Single-User)	ExLlamaV2, Tabby-API
HQQ 4-bit	~73 %	−0,6 PP	~80 %	Hugging Face Transformers
FP8 (E4M3)	~50 %	−0,1 PP	~120 % (auf Hopper/Blackwell)	vLLM auf H100/H200/B200

Bemerkenswert ist FP8: Auf Hopper-Generation (H100) und neuer ist es kein "Sparformat", sondern beschleunigt sogar — die Tensor-Cores rechnen FP8 nativ und doppelt so schnell wie FP16. Wer eine H100 oder H200 betreibt und das Modell ohnehin in den VRAM bekommt, sollte FP8 vor 4-Bit erwägen: bessere Qualität, höhere Geschwindigkeit.

7. EXL2 und HQQ: Nischen mit Berechtigung

EXL2 ist das native Format der ExLlamaV2-Engine, ursprünglich aus der Hobbyisten-Szene rund um OobaboogaUI und SillyTavern. Sein Trick: variable Bit-Tiefe pro Layer (BPW = bits per weight). Wichtige Layer bekommen 5 Bit, weniger relevante 3 oder 2,5 Bit. Damit lassen sich exakte VRAM-Vorgaben treffen, etwa "bitte genau 22 GB für 70B". EXL2 ist die schnellste Single-User-Inferenz auf Consumer-Hardware (RTX 3090/4090) — für Multi-User-Server-Setups mit Continuous Batching aber ungeeignet, weil ExLlamaV2 keine Batch-Optimierung hat.

HQQ (Half-Quadratic Quantization) ist ein neueres Verfahren, das ohne Calibration-Daten auskommt — die Quantisierung ist eine reine Optimierung gegen den Originalwert. Vorteil: Sekundenschnelle Quantisierung selbst von 70B-Modellen. Nachteil: Qualität liegt etwas unter AWQ. HQQ ist interessant, wenn Sie selbst fine-getunte Modelle laufend quantisieren müssen und keine Calibration-Daten pflegen wollen.

Im Mittelstands-Alltag spielen beide Formate eine geringe Rolle. Wer einen vLLM-Server hat, nimmt AWQ. Wer auf einem Mac entwickelt, nimmt GGUF. EXL2 und HQQ sind Speziallösungen.

8. Welche Methode bei welcher Hardware?

Eine pragmatische Entscheidungsmatrix für das Jahr 2026:

• NVIDIA L40S, A100, H100, H200 mit vLLM: AWQ-Q4 mit Marlin-Kernel als Default. FP8 auf H100/H200, falls das Modell in den VRAM passt.
• NVIDIA RTX 3090/4090 für Single-User-Workstation: EXL2 mit ExLlamaV2 oder AWQ mit vLLM. EXL2 ist schneller, vLLM ist OpenAI-kompatibel.
• Apple Silicon (M2/M3/M4): GGUF Q4_K_M mit llama.cpp oder Ollama. MLX-Format als Alternative für Apple-eigene Toolchain.
• CPU-only oder gemischt CPU/GPU: GGUF Q4_K_M mit llama.cpp und partiellem GPU-Offload.
• Edge-Geräte (Jetson, kleine Server): GGUF Q4_K_S oder Q3_K_M, je nach RAM-Budget.
• Multi-Tenant-Plattform mit hoher Concurrency: AWQ oder FP8 auf vLLM, niemals GGUF (kein Continuous Batching).

Eine letzte Warnung: Quantisierung ist kein Ersatz für eine zu kleine Modellgröße. Ein Llama 3.1 8B in FP16 ist in fast allen Tasks besser als ein Llama 3.3 70B in 2-Bit-Quantisierung — die Qualität bricht jenseits 3 Bit zu schnell ein, um sie mit Modellgröße zu kompensieren. Wenn Sie Hardware-bedingt nur ein Q2 fahren könnten, nehmen Sie lieber das nächstkleinere Modell in Q4.

FAQ zur Quantisierung