KI & LLM 7 Min Lesezeit

LLM-Quantisierung erklärt 2026 – GGUF, GPTQ, AWQ

Warum Quantisierung 2026 der Standardfall ist

Noch 2023 war ein 70B-Modell in FP16 ein Luxusproblem: 140 GB VRAM, also zwei A100-80GB oder vier RTX 4090. 2026 ist das anders. Wer heute ein Llama-3.3-70B, Qwen3-32B oder Mistral-Large lokal betreibt, lädt in der Regel eine 4-Bit-Variante mit 20 bis 45 GB – und bekommt dafür rund 95 bis 98 % der Originalqualität.

Quantisierung ist damit kein Kompromiss mehr, sondern der Default. Der Grund ist banal: Speicherbandbreite ist der Flaschenhals bei der Token-Generierung. Ein Modell mit halbierter Gewichtsgröße läuft auf derselben GPU fast doppelt so schnell, weil pro Token weniger Bytes durch den HBM müssen.

Dieser Guide zeigt dir, wie GGUF, GPTQ und AWQ technisch funktionieren, welches Format du für welchen Stack nimmst, wie du den Qualitätsverlust messbar prüfst und welche Server-Hardware 2026 dafür sinnvoll ist.

Grundlagen: Bits, Gruppen und Skalen

Ein Sprachmodell besteht aus Milliarden von Gewichten, die im Training als FP16 oder BF16 vorliegen – je 16 Bit. Quantisierung bildet diese Werte auf weniger Bits ab, meist 4 oder 8. Der einfachste Weg ist absmax-Quantisierung: Man nimmt den betragsmäßig größten Wert einer Gruppe, teilt ihn durch den maximal darstellbaren Integer und speichert den Skalierungsfaktor.

Entscheidend ist die Gruppengröße (group size). Statt ein ganzes Layer mit einem Skalenfaktor zu versehen, teilt man es in Blöcke von 32, 64 oder 128 Gewichten. Kleinere Gruppen = bessere Qualität, mehr Overhead. Bei 4 Bit und group_size 128 kostet der Skalenfaktor 16 Bit pro 128 Gewichte, also zusätzliche 0,125 Bit pro Gewicht – praktisch vernachlässigbar.

Die effektive Bitbreite eines Q4_K_M-Modells liegt deshalb nicht bei 4,0, sondern bei etwa 4,85 Bit pro Gewicht. Das erklärt, warum eine 7B-Q4-Datei nicht 3,5 GB groß ist, sondern rund 4,4 GB.

FP16/BF16 – 16 Bit, Referenzqualität, 2 Byte pro Gewicht
INT8 / Q8_0 – 8 Bit, praktisch verlustfrei, halber Speicher
INT4 – 4 Bit, der Sweet Spot für Consumer-Hardware
INT2/INT3 – nur mit i-quants oder neuen Verfahren brauchbar

GGUF – das universelle Format für llama.cpp

GGUF (GPT-Generated Unified Format) ist das Containerformat von llama.cpp und hat die alten GGML-Dateien 2023 abgelöst. Es ist ein Single-File-Format: Gewichte, Tokenizer, Chat-Template und Metadaten stecken in einer Datei. Das macht es zum De-facto-Standard für lokale Inferenz auf CPU, Apple Silicon und gemischten CPU/GPU-Setups.

GGUF kennt die größte Auswahl an Quantisierungsstufen. Die K-Quants (Q2_K bis Q6_K) nutzen eine Mischung aus verschiedenen Bitbreiten pro Block – Aufmerksamkeits- und Feed-Forward-Gewichte werden unterschiedlich stark komprimiert. Die i-quants (IQ1_S bis IQ4_XS) verwenden Gitterquantisierung und sind bei sehr niedrigen Bitbreiten deutlich besser als K-Quants.

GGUF-Typ	Eff. Bit/Gewicht	7B-Größe	70B-Größe	Empfehlung
Q8_0	8,50	7,2 GB	71 GB	Wenn VRAM reichlich da ist
Q6_K	6,56	5,5 GB	55 GB	Nahezu verlustfrei
Q5_K_M	5,69	4,8 GB	48 GB	Guter Allrounder
Q4_K_M	4,85	4,4 GB	42,5 GB	Standard-Empfehlung
IQ4_XS	4,25	3,8 GB	38 GB	Etwas kleiner, ähnliche Qualität
Q3_K_M	3,91	3,5 GB	32,5 GB	Nur bei knappem VRAM
Q2_K	2,96	2,8 GB	26,5 GB	Spürbare Qualitätsverluste

Faustregel 2026: Q4_K_M ist der beste Kompromiss. Unter Q4 wird der Qualitätsabfall bei Reasoning- und Coding-Aufgaben deutlich sichtbar, oberhalb von Q5 zahlst du viel Speicher für wenig Gewinn.

GPTQ – der GPU-Klassiker mit ExLlama-Kernels

GPTQ (Generative Pre-trained Transformer Quantization) stammt aus einer Paper-Veröffentlichung von 2022 und war das erste Verfahren, das 4-Bit-Quantisierung für LLMs praxistauglich machte. Der Ansatz ist layerweise und fehlerkorrigierend: Für jedes Layer wird die Quantisierung so gewählt, dass der Ausgabefehler minimiert wird – man nutzt die Hessische Matrix der Eingangsaktivierungen (aus einem Kalibrierdatensatz), um zu entscheiden, welche Gewichte wie stark gerundet werden dürfen.

Wichtige Parameter beim Erstellen eines GPTQ-Modells:

bits – 3, 4 oder 8 (4 ist Standard)
group_size – 32, 64, 128 (128 ist Standard, 32 kostet ~10 % mehr Speicher für bessere Qualität)
desc_act / act-order – sortiert Spalten nach Aktivierungsstärke, kostet etwas Speed, bringt Qualität
damp_percent – Dämpfung der Hessischen Matrix, 0,01 ist ein guter Default

Der Vorteil von GPTQ liegt in der Inferenz-Geschwindigkeit. Mit den ExLlamaV2-Kernels erreicht ein 4-Bit-GPTQ-Modell auf einer RTX 4090 oft 100+ Tokens/s bei einem 7B-Modell – deutlich mehr als llama.cpp mit denselben Gewichten. Nachteil: GPTQ ist GPU-only, die Dateien sind nicht portabel auf CPU-Setups und die Qualität bei 3 Bit ist schlechter als bei GGUF-i-quants.

AWQ – aktivierungsbewusst und schnell

AWQ (Activation-aware Weight Quantization) kam 2023 von MIT und ist heute das bevorzugte Format für vLLM-Produktionsdeployments. Die Kernidee: Nicht alle Gewichte sind gleich wichtig. Etwa 1 % der Kanäle trägt überproportional viel zur Ausgabe bei – AWQ identifiziert diese über die Aktivierungsverteilung und schützt sie, indem es die Gewichte vor der Quantisierung per Skalierung umverteilt.

Der praktische Unterschied zu GPTQ: AWQ braucht keine Rückpropagierung und keinen Gradienten, ist damit schneller zu erzeugen und robuster gegenüber Overfitting auf den Kalibrierdatensatz. In Benchmarks liegt AWQ bei 4 Bit meist 0,1 bis 0,3 Perplexity-Punkte vor GPTQ, bei ähnlicher Geschwindigkeit.

# AWQ-Modell mit vLLM servieren
vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \
  --quantization awq \
  --dtype float16 \
  --max-model-len 16384 \
  --gpu-memory-utilization 0.92 \
  --port 8000

Nachteil von AWQ: Es gibt praktisch nur 4-Bit-Varianten. Wer 3 Bit oder 6 Bit braucht, ist bei GGUF oder EXL3 besser aufgehoben. Zudem ist die Formatunterstützung außerhalb von vLLM, TGI und SGLang dünn.

Direkter Vergleich: GGUF vs. GPTQ vs. AWQ

Kriterium	GGUF	GPTQ	AWQ
Primäre Engine	llama.cpp, Ollama, LM Studio	ExLlamaV2, vLLM, TGI	vLLM, SGLang, TGI
Hardware	CPU, Metal, CUDA, ROCm	CUDA, ROCm	CUDA, ROCm
Bitbreiten	2–8 Bit, viele Varianten	3, 4, 8 Bit	4 Bit
Single-File	Ja	Nein (Ordner)	Nein (Ordner)
Batching-Qualität	Mittel	Gut	Sehr gut
Tokens/s (7B, RTX 4090)	~95	~135	~140
Qualität @ 4 Bit	Sehr gut (Q4_K_M)	Gut	Sehr gut

Kurzfassung: Einzelplatz und Mac → GGUF. GPU-Server mit vLLM → AWQ. Bestehende GPTQ-Pipeline oder ExLlama-Setup → GPTQ. Für Multi-User-Inferenz mit hohem Durchsatz ist AWQ in vLLM 2026 die klarste Wahl.

Qualitätsverlust messen: Perplexity, KL-Divergenz, Benchmarks

Perplexity allein sagt wenig aus. Ein Modell kann auf WikiText-103 eine Perplexity von 6,1 statt 5,9 haben und trotzdem bei Mathematik-Aufgaben 15 % schlechter abschneiden. Prüfe deshalb immer drei Ebenen:

Perplexity auf einem sauberen Korpus (WikiText-103, C4) – schnelle Sanity-Prüfung
KL-Divergenz gegen das FP16-Modell über 1000+ Prompt-Tokens – sensitiver als Perplexity
Aufgaben-Benchmarks – MMLU, HumanEval, GSM8K mit identischen Seeds

Typische Werte für Llama-3.1-8B auf WikiText-103:

Format	Perplexity	MMLU	HumanEval
FP16 (Referenz)	5,90	68,4 %	72,6 %
Q8_0	5,91	68,3 %	72,6 %
Q6_K	5,94	68,1 %	71,9 %
Q5_K_M	5,98	67,8 %	71,3 %
Q4_K_M	6,07	67,1 %	69,5 %
Q3_K_M	6,38	64,9 %	63,1 %
Q2_K	7,61	58,2 %	49,4 %

Die Zahlen zeigen klar: Bis Q4_K_M sind die Verluste im Rauschen. Ab Q3 bricht vor allem Code-Generierung ein – HumanEval fällt von 69,5 % auf 63,1 %. Bei Q2 ist das Modell für ernsthafte Arbeit unbrauchbar.

Praxis: Modelle selbst quantisieren

Für GGUF brauchst du llama.cpp mit CUDA- oder Metal-Backend. Der Ablauf ist immer gleich: FP16-GGUF erzeugen, dann quantisieren.

# 1. llama.cpp bauen
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp && cmake -B build -DGGML_CUDA=ON && cmake --build build -j

# 2. HuggingFace-Modell nach FP16-GGUF konvertieren
python convert_hf_to_gguf.py ./meta-llama-3.1-8b --outfile model-f16.gguf --outtype f16

# 3. Nach Q4_K_M quantisieren
./build/bin/llama-quantize model-f16.gguf model-Q4_K_M.gguf Q4_K_M

# 4. Mit vollem GPU-Offload testen
./build/bin/llama-cli -m model-Q4_K_M.gguf \
  -p "Erkläre Quantisierung in drei Sätzen." \
  -n 256 -ngl 99 -c 8192 --temp 0.7

Für AWQ und GPTQ nutzt du am einfachsten AutoAWQ bzw. llm-compressor von vLLM. Ein 7B-Modell ist auf einer RTX 4090 in 8 bis 15 Minuten quantisiert, ein 70B-Modell braucht auf einer A100-80GB etwa 45 bis 90 Minuten.

# AWQ-Quantisierung mit llm-compressor
python -m llmcompressor.transformers \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --scheme W4A16 \
  --output-dir ./llama-8b-awq \
  --calibration-dataset ultrachat_200k \
  --num-calibration-samples 512

Wichtig: Kalibrierdaten müssen zur Zielaufgabe passen. Wer ein Modell für deutschen Support quantisiert, sollte deutsche Kalibriertexte nutzen – englische Kalibrierung kostet bei mehrsprachigen Modellen messbar Qualität.

VRAM- und Hardware-Planung mit konkreten Zahlen

Die Formel für den Bedarf lautet: Modellgröße + KV-Cache + Overhead (1–2 GB). Der KV-Cache skaliert linear mit Kontextlänge, Batch-Größe und Layer-Anzahl.

KV-Cache (GB) = 2 × Layer × KV-Heads × Head-Dim × Seq-Len × Batch × Bytes
# Llama-3.1-8B, 8192 Kontext, Batch 1, FP16:
# 2 × 32 × 8 × 128 × 8192 × 1 × 2 Byte ≈ 1,07 GB

Modell	Q4_K_M	Q5_K_M	Q8_0	Passende GPU
Llama 3.2 3B	2,0 GB	2,3 GB	3,4 GB	RTX 3060 12 GB
Qwen3 8B	4,7 GB	5,4 GB	8,1 GB	RTX 4060 Ti 16 GB
Mistral Small 24B	14,3 GB	16,5 GB	24,5 GB	RTX 4090 24 GB
Qwen3 32B	19,8 GB	22,7 GB	34,0 GB	RTX 5090 32 GB
Llama 3.3 70B	42,5 GB	48,0 GB	71,0 GB	2× RTX 5090 / A100 80 GB
DeepSeek-R1 671B	~380 GB	—	—	8× H100 80 GB

Für den Heimgebrauch ist eine 24-GB-Karte 2026 der Sweet Spot: Sie trägt 32B-Modelle in Q4 mit 8K-Kontext. Wer 70B will, kommt um 48 GB VRAM nicht herum – zwei RTX 5090 oder eine gebrauchte A100-80GB.

Neue Formate 2026: MXFP4, NVFP4, EXL3 und BitNet

Die Quantisierungslandschaft hat sich 2025/2026 deutlich bewegt. Die wichtigsten Neuerungen:

MXFP4 – Microsclaing-Format aus dem OCP-Standard, 4 Bit mit gemeinsamem Exponenten pro 32er-Block. Von NVIDIA Blackwell nativ unterstützt.
NVFP4 – NVIDIAs Variante mit FP8-Skalen pro 16er-Block, in TensorRT-LLM und vLLM ab Version 0.9 verfügbar. Praktisch verlustfrei bei 4 Bit für viele Modelle.
EXL3 – ExLlamaV3 mit Trellis-Quantisierung, erreicht bei 3 Bit die Qualität von klassischem 4-Bit. Sehr gut für 70B auf 2× 24 GB.
BitNet b1.58 – ternäre Gewichte (−1, 0, +1), nur mit von Grund auf trainierten Modellen nutzbar, nicht nachträglich anwendbar.

Für die Praxis heißt das: Auf Blackwell-GPUs (B200, RTX 5090) lohnt sich NVFP4, weil die Tensor Cores es nativ beschleunigen. Auf Ampere und Ada bleibt Q4_K_M oder AWQ die beste Wahl.

Hosting: Welcher Server für welches Format

Wer Quantisierung produktiv nutzt, braucht passende Hardware. Die folgende Übersicht zeigt typische Optionen mit Preisen (Stand Anfang 2026, monatlich bei Jahresvertrag):

Setup	GPU / VRAM	Geeignet für	Preis
Hetzner GEX44	RTX 4000 SFF Ada, 20 GB	8B–24B in Q4/Q5, GGUF + vLLM	~184 €
Hetzner GEX130	RTX 6000 Ada, 48 GB	32B Q5, 70B Q3	~720 €
OVH Advance-2	2× RTX 5000 Ada, 64 GB	70B Q4 mit 16K Kontext	~1.100 €
RunPod RTX 4090	24 GB, stündlich	Tests, Batch-Jobs	0,34–0,69 $/h
RunPod A100 80 GB	80 GB, stündlich	70B Q8, 120B Q4	1,19–1,89 $/h

Für den Dauerbetrieb ist ein dedizierter Server meist günstiger als Stundenpreise: Eine RTX 4090 für 400 €/Monat entspricht 730 Stunden bei 0,55 $/h. Für Experimente und unregelmäßige Last ist die stündliche Miete klar im Vorteil.

CPU-seitig gilt: GGUF mit -ngl 99 schiebt alle Layer auf die GPU. Bei zu wenig VRAM lässt du die letzten Layer auf der CPU und verlierst sofort 60–80 % Geschwindigkeit. Besser: kleineres Modell oder niedrigere Quantisierung, aber alles auf der GPU.

FAQ

Was ist besser: GGUF oder AWQ?

Das hängt vom Stack ab. GGUF ist portabler, läuft auf CPU, Mac und GPU und ist ideal für Einzelplatz-Setups mit llama.cpp, Ollama oder LM Studio. AWQ ist schneller bei Multi-User-Batching und die richtige Wahl für vLLM oder SGLang auf Servern. Qualitativ liegen Q4_K_M und AWQ 4-Bit sehr nah beieinander.

Wie viel Qualität verliere ich bei 4-Bit-Quantisierung?

Bei Q4_K_M oder AWQ 4-Bit verlierst du typischerweise 1 bis 2 Prozentpunkte auf MMLU und 2 bis 3 Punkte auf HumanEval. In der Praxis ist das selten spürbar. Ab 3 Bit wird es kritisch, ab 2 Bit bricht die Code-Generierung um 20 Punkte ein.

Reicht eine 24-GB-GPU für ein 70B-Modell?

Nein, nicht vollständig. Ein 70B-Modell braucht in Q4_K_M etwa 42,5 GB plus KV-Cache. Mit 24 GB musst du Layer auf die CPU auslagern, was die Geschwindigkeit auf 3 bis 6 Tokens/s drückt. Für flüssiges Arbeiten brauchst du mindestens 48 GB VRAM.

Kann ich ein quantisiertes Modell nachträglich weiter trainieren?

Nur eingeschränkt. LoRA-Adapter lassen sich auf quantisierte Basismodelle aufsetzen (QLoRA-Prinzip), das Training selbst läuft aber immer in höherer Präzision. Vollständiges Fine-Tuning eines 4-Bit-Modells ist nicht sinnvoll – quantisiere erst nach dem Training.

Welche Quantisierung für deutsche Sprachmodelle?

Für mehrsprachige Modelle gilt dieselbe Faustregel, aber achte auf die Kalibrierdaten. Bei AWQ und GPTQ sollte der Kalibriersatz deutschen Text enthalten, sonst verliert das Modell bei deutschen Aufgaben überproportional. GGUF-Q4_K_M ist hier robuster, weil keine Kalibrierung nötig ist.