GGUF, AWQ und GPTQ erklärt: Welches Quantisierungsformat für welchen Zweck

Wer ein Large Language Model lokal betreiben will, steht früher oder später vor der Frage: Welches Quantisierungsformat soll ich nehmen – GGUF, AWQ oder GPTQ? Alle drei reduzieren ein Modell von 16-Bit-Halbpräzision (FP16) auf typischerweise 4 Bit und sparen dabei 60–75 % Speicher. Die Qualitätsunterschiede zwischen den Formaten sind bei 4-Bit-Quantisierung minimal (weniger als 0,03 Perplexitätspunkte im Benchmark). Was sich dagegen erheblich unterscheidet, sind Geschwindigkeit, Hardware-Kompatibilität und Workflow. Diese Anleitung liefert dir einen klaren Entscheidungsbaum statt Theorie: Wer eine CPU oder einen Apple-Silicon-Mac nutzt, nimmt GGUF; wer NVIDIA-GPU-Produktion betreibt, nimmt AWQ oder GPTQ – mit konkreten Zahlen als Beleg.

Voraussetzungen

1. GGUF / CPU: x86-CPU mit AVX2 (alle modernen CPUs seit ca. 2013), mindestens 16 GB RAM für ein 7B-Modell (Q4_K_M benötigt ca. 6 GB Modell + Overhead); kein GPU nötig
2. GGUF / Apple Silicon: Mac mit M1, M2, M3 oder M4 – Metal-Beschleunigung ist ab Werk unterstützt; Ollama oder LM Studio reichen als Tool
3. AWQ / GPTQ: NVIDIA-GPU mit CUDA-Unterstützung, mindestens 8 GB VRAM für 7B-Modelle; CUDA 12.1+ empfohlen; AMD ROCm wird von beiden Formaten ebenfalls unterstützt
4. Python-Umgebung: Python 3.10+ mit pip für autoawq, gptqmodel und transformers; venv empfohlen
5. Hugging-Face-Konto (kostenlos) für den Zugriff auf Gated-Modelle wie Llama 3.1
6. Bei eigener Quantisierung: Kalibrierungsdatensatz (C4 oder Wikitext für GPTQ, 128–512 Samples für AWQ); für GPTQ eines 7B-Modells auf A100 mindestens 2–4 Stunden Zeit einplanen

Was Quantisierung bedeutet – und warum das Format zählt

Post-Training-Quantisierung (PTQ) komprimiert die Modellgewichte nach dem Training, ohne erneutes Training. Ein FP16-Modell mit 7 Milliarden Parametern belegt rund 14 GB; dieselbe Architektur als Q4_K_M-GGUF oder AWQ/GPTQ 4-Bit kommt auf 3,5–5,5 GB. Der Qualitätsverlust fällt bei 4-Bit-Quantisierung überraschend gering aus: Im oobabooga-Benchmark auf einem RTX 3090 mit Llama 2 13B und dem Wikitext-Datensatz lagen die Perplexitätswerte bei 4,325 (AWQ), 4,333 (GGUF Q4_K_M) und 4,338 (GPTQ) – eine Differenz von weniger als 0,03 Punkten, die in der Praxis nicht spürbar ist.

Die Formate unterscheiden sich hingegen deutlich in ihren Algorithmen und Geschwindigkeiten: GGUF nutzt k-quants und GGML-Tensoren, die generisch auf CPU und GPU laufen. AWQ (Activation-aware Weight Quantization) schützt gezielt das 1 % der Gewichte mit der höchsten Aktivierungsrelevanz und kann durch Kernel-Fusion auf Llama/Mistral-Architekturen bis zu 106 tokens/s erreichen. GPTQ basiert auf OBQ (Optimal Brain Quantization) und quantisiert jede Gewichtszeile unabhängig; der ExLlamaV2-Kernel holt auf NVIDIA bis zu 64 tokens/s heraus.

Entscheidungsbaum: Welches Format passt zu dir?

Die folgende Tabelle fasst die wichtigsten Hardware- und Use-Case-Kombinationen zusammen:

Format-Direktvergleich: GGUF, AWQ und GPTQ

Schritt 1: GGUF – Modelle mit Ollama laden (CPU und Apple Silicon)

Für CPU- und Mac-Nutzer ist Ollama der einfachste Einstieg. Das Tool verwaltet GGUF-Modelle automatisch und wählt standardmäßig Q4_K_M als beste Balance aus Größe und Qualität.

# Ollama installieren (Linux/macOS)
curl -fsSL https://ollama.com/install.sh | sh

# Llama 3.1 8B laden und starten (Standard-Tag = Q4_K_M)
ollama run llama3.1:8b

# Größeres Modell mit explizitem GGUF-Tag
ollama run llama3.1:70b-instruct-q4_K_M

# Alle verfügbaren Quantisierungen eines Modells anzeigen
ollama show llama3.1:8b --modelfile

Wer llama.cpp direkt nutzen will oder eigene GGUF-Dateien von Hugging Face lädt, kann das Modell auch über die Kommandozeile starten:

# llama.cpp bauen (Linux, mit CUDA-Unterstützung)
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release

# GGUF-Modell starten
./build/bin/llama-cli \
  -m Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -p "Erkläre Quantisierung:" \
  -n 200

# HF-Modell ins GGUF-Format konvertieren
python llama.cpp/convert_hf_to_gguf.py ./mein_modell_verzeichnis

Prüfkriterium: Nach ollama run llama3.1:8b antwortet das Modell direkt im Terminal. Mit ollama list siehst du die geladenen Modelle und ihre Größe – Q4_K_M sollte für Llama 3.1 8B rund 4,9 GB anzeigen.

GGUF-Quantisierungsstufen: welche Stufe für welchen Bedarf

GGUF bietet Quantisierungen von 1 bis 8 Bit. Die k-quant-Varianten (K_S = small, K_M = medium) nutzen gemischte Präzision: Einige Schichten bleiben in höherem Bitformat, was die Qualität bei moderatem Speicherzuwachs verbessert.

Der Unterschied zwischen Q4_K_S und Q4_K_M: K_M hält einige kritische Schichten in höherer Präzision und kostet rund 400 MB mehr. Für die meisten Anwendungen ist Q4_K_M die klügere Wahl. Unter 4 Bit (Q2, Q3) lohnt sich das Einsparen in der Regel nicht – bei komplexen Reasoning-Aufgaben wird der Qualitätsabfall spürbar.

Schritt 2: AWQ – schnelle GPU-Inferenz mit Fused Modules

AWQ-Modelle lassen sich in Hugging Face Transformers direkt laden. Wer das Maximum an Geschwindigkeit herausholen will, aktiviert Fused Modules – das verdoppelt bis verdreifacht die Decode-Geschwindigkeit auf Llama- und Mistral-Architekturen.

# autoawq installieren
pip install autoawq
from transformers import AutoModelForCausalLM, AwqConfig

# Standard: AWQ-Modell von Hugging Face laden
model = AutoModelForCausalLM.from_pretrained(
    "TheBloke/zephyr-7B-alpha-AWQ",
    device_map="cuda:0"
)

# Mit Fused Modules: ca. 2–3× schneller (nur Llama/Mistral)
quantization_config = AwqConfig(bits=4, fuse_max_seq_len=2048, do_fuse=True)
model = AutoModelForCausalLM.from_pretrained(
    "TheBloke/Mistral-7B-OpenOrca-AWQ",
    quantization_config=quantization_config
).to(0)

# Mit ExLlamaV2-Kernel (schneller auf NVIDIA)
quantization_config = AwqConfig(version="exllama")
model = AutoModelForCausalLM.from_pretrained(
    "TheBloke/Mistral-7B-Instruct-v0.1-AWQ",
    quantization_config=quantization_config,
    device_map="auto"
)

Wer ein eigenes Fine-Tuned-Modell quantisieren will, nutzt autoawq direkt – deutlich schneller als GPTQ:

from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer

model_path = "meta-llama/Meta-Llama-3.1-8B-Instruct"
quant_path  = "Meta-Llama-3.1-8B-Instruct-AWQ"
quant_config = {
    "zero_point": True,
    "q_group_size": 128,   # WICHTIG: 128 statt 32 – spart VRAM
    "w_bit": 4,
    "version": "GEMM"
}

model     = AutoAWQForCausalLM.from_pretrained(model_path, device_map="auto")
tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True)
model.quantize(tokenizer, quant_config=quant_config)
model.save_quantized(quant_path)

Für Produktions-Serving mit vLLM ist AWQ der empfohlene Standard:

pip install vllm
vllm serve TheBloke/Llama-2-7B-AWQ --quantization awq --port 8000

Prüfkriterium: AWQ mit Fused Modules liefert laut offizieller Hugging-Face-Dokumentation 80–106 tokens/s für Mistral 7B bei 1k Context, gegenüber 31–38 tokens/s ohne Fusion. Mit nvidia-smi sollte der VRAM-Verbrauch bei Group-Size 128 rund 5,4 GB für ein 8B-Modell betragen.

Schritt 3: GPTQ – etabliertes Format mit ExLlamaV2 und Marlin-Kernel

GPTQ-Modelle sind auf Hugging Face am breitesten verfügbar. Für neue Projekte ersetzt GPT-QModel das veraltete AutoGPTQ – es unterstützt zusätzlich AMD ROCm, Apple Silicon und den Marlin-Kernel für NVIDIA-A100-Hardware.

pip install --upgrade accelerate optimum transformers
pip install gptqmodel --no-build-isolation
from transformers import AutoModelForCausalLM

# GPTQ-Modell von Hugging Face laden
model = AutoModelForCausalLM.from_pretrained(
    "TheBloke/Llama-2-7B-GPTQ",
    device_map="auto"
)

# Mit Marlin-Kernel (nur NVIDIA Ampere/A100, deutlich schneller)
from transformers import GPTQConfig
model = AutoModelForCausalLM.from_pretrained(
    "TheBloke/Llama-2-7B-GPTQ",
    device_map="auto",
    quantization_config=GPTQConfig(bits=4, backend="marlin")
)

Wer sein eigenes Modell selbst quantisieren muss (z. B. nach Fine-Tuning), verwendet GPTQConfig über transformers – aber mit realem Zeitplan:

from transformers import AutoModelForCausalLM, AutoTokenizer, GPTQConfig

tokenizer   = AutoTokenizer.from_pretrained("meta-llama/Meta-Llama-3.1-8B-Instruct")
gptq_config = GPTQConfig(bits=4, dataset="c4", tokenizer=tokenizer)

# Achtung: Dauert 2–4 Stunden auf einem A100!
model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Meta-Llama-3.1-8B-Instruct",
    device_map="auto",
    quantization_config=gptq_config
)
model.save_pretrained("Meta-Llama-3.1-8B-Instruct-GPTQ")
tokenizer.save_pretrained("Meta-Llama-3.1-8B-Instruct-GPTQ")

GPTQ mit vLLM starten:

vllm serve TheBloke/Llama-2-7B-GPTQ --quantization gptq --port 8000

Prüfkriterium: ExLlamaV2 erreicht auf einem RTX 3090 rund 64 tokens/s für ein 7B-GPTQ-Modell; GPTQ-4bit-128g belegt laut oobabooga-Benchmark 7,9 GB VRAM (VRAM bei Context=1). Falls du noch AutoGPTQ-Code im Einsatz hast: Seit transformers 4.x wird AutoGPTQ nicht mehr unterstützt – die Migration auf GPT-QModel ist Pflicht.

VRAM-Bedarf im Überblick: Llama 3.1 8B auf RTX 4090

Der Fallstrick mit der Group Size: AWQ mit q_group_size=32 statt 128 kann den VRAM-Verbrauch mehr als verdoppeln (von 5,4 GB auf 10,6 GB), ohne nennenswerten Qualitätsgewinn. Immer q_group_size=128 verwenden, sofern kein spezifischer Grund dagegen spricht.

Troubleshooting: Typische Fehler und Fallstricke

AutoGPTQ ist veraltet – Migration auf GPT-QModel

Wer noch from auto_gptq import AutoGPTQForCausalLM im Code hat, bekommt seit neueren transformers-Versionen Fehler. AutoGPTQ-Checkpoints sind zudem nicht vollständig mit dem Marlin-Kernel kompatibel. Lösung: pip install gptqmodel und Code auf GPT-QModel umstellen.

GGUF über transformers.from_pretrained verliert die Kompression

Wenn ein GGUF-Modell über die standard-from_pretrained-Methode geladen wird, dequantisiert transformers es intern nach FP32. Das Modell belegt dann wieder den vollen Speicher – der VRAM-Vorteil ist weg. GGUF-Modelle immer über llama.cpp, Ollama oder LM Studio laden.

AWQ Fused Modules funktioniert nicht bei Qwen oder Phi

Fused Modules sind standardmäßig nur für Llama und Mistral implementiert. Bei anderen Architekturen (Qwen, Phi, Falcon etc.) muss eine manuelle modules_to_fuse-Konfiguration erstellt werden – andernfalls läuft AWQ unfused und erreicht nur 31–38 tokens/s statt 80–106.

GPTQ-Quantisierung dauert viel länger als erwartet

Ein 7B-Modell dauert auf einem A100 2–4 Stunden, ein 70B-Modell bis zu 16 Stunden. Bevor du selbst quantisierst, immer zuerst auf Hugging Face nach fertigen GPTQ-Modellen suchen (TheBloke, unsloth, bartowski). Selbst quantisieren lohnt sich fast nur für eigene Fine-Tuned-Modelle oder sehr neue Releases.

AWQ auf Apple Silicon schlägt fehl

AWQ ist in der offiziellen Hugging-Face-Kompatibilitätsmatrix nicht als nativ für Metal / Apple Silicon gelistet. Auf Mac M-Chips unbedingt GGUF (Ollama, LM Studio) oder MLX verwenden – kein AWQ oder GPTQ.

Schlechte Qualität nach GPTQ-Quantisierung eines Code-Modells

Wenn Kalibrierungsdaten (Standard: Wikitext oder C4) nicht zum Einsatzgebiet des Modells passen, leidet die Ausgabequalität spürbar. Für Code-Modelle aufgabenspezifischen Kalibrierungsdatensatz (z. B. The Stack oder HumanEval-Prompts) verwenden.

GGUF ist für reine GPU-Server die falsche Wahl

Wer GGUF auf einer dedizierten NVIDIA-GPU betreibt, lässt 10–30 % Geschwindigkeit liegen, weil llama.cpp generische statt spezialisierte CUDA-Kernel einsetzt. Für GPU-only-Setups sind AWQ oder GPTQ die bessere Wahl; GGUF ist für CPU und Apple Silicon optimiert.

Häufige Fragen

Welches Format nehme ich für meinen Mac (Apple M1/M2/M3/M4)?

Immer GGUF – es ist das einzige der drei Formate mit nativer Metal/Apple-Silicon-Unterstützung. Ollama oder LM Studio installieren, das Q4_K_M-Modell laden, fertig. AWQ und GPTQ laufen auf Apple Silicon nicht mit nativer GPU-Beschleunigung.

Was ist der Unterschied zwischen Q4_K_M und Q4_K_S bei GGUF?

K_M (medium) verwendet gemischte Präzision – einige Schichten bleiben in höherem Bitformat – und ist qualitativ besser. K_S (small) ist kompakter und schneller. Q4_K_M kostet rund 400 MB mehr, ist aber für die meisten Anwendungen die bessere Wahl. Q4_K_S empfiehlt sich, wenn der Speicher knapp ist und der minimale Qualitätsunterschied keine Rolle spielt.

Kann ich AWQ-Modelle auf einer AMD-GPU (ROCm) betreiben?

Ja – AWQ unterstützt AMD ROCm laut offizieller Hugging-Face-Kompatibilitätsmatrix. Auch GPTQ via GPT-QModel läuft auf AMD ROCm. GGUF hat dagegen kein AMD-Äquivalent zum Metal-Backend.

Muss ich Modelle selbst quantisieren oder gibt es fertige Downloads?

Für die meisten populären Modelle (Llama 3, Mistral, Qwen, Phi etc.) gibt es auf Hugging Face fertige quantisierte Versionen von TheBloke, bartowski, unsloth und den Modell-Entwicklern selbst. Selbst quantisieren ist nur nötig für eigene Fine-Tuned-Modelle oder sehr neue Releases.

Welches Format nimmt man für vLLM in der Produktion?

AWQ ist der empfohlene Standard für vLLM-Produktionsdeployments: vllm serve MODEL --quantization awq. GPTQ funktioniert ebenfalls. Beide liefern deutlich höhere Durchsatzraten als GGUF für parallele Batch-Anfragen.

Lohnt sich 8-Bit (Q8) statt 4-Bit (Q4)?

Bei GGUF ist Q8_0 quasi-verlustfrei gegenüber FP16, benötigt aber etwa doppelt so viel VRAM wie Q4_K_M. Für CPU-Inferenz ist Q4_K_M die bessere Balance. Q8_0 empfiehlt sich nur, wenn ausreichend VRAM/RAM vorhanden ist und maximale Qualität bei gleichzeitigem lokalem Betrieb gefragt ist.

Fazit

Die Entscheidung zwischen GGUF, AWQ und GPTQ ist keine Qualitätsfrage – sie ist eine Hardware- und Workflow-Frage. Alle drei Formate liefern bei 4-Bit-Quantisierung nahezu identische Ergebnisse (Perplexitätsunterschied unter 0,03). Der Entscheidungsbaum ist klar: CPU oder Apple Silicon bedeutet GGUF mit Q4_K_M; NVIDIA-GPU für Entwicklung oder Produktion bedeutet AWQ (für einfache Deployments und vLLM) oder GPTQ mit ExLlamaV2/Marlin (für maximale Geschwindigkeit auf Ampere-Hardware). Für die meisten Anwender ist das Herunterladen eines vorgefertigten quantisierten Modells von Hugging Face der schnellste Weg – selbst quantisieren lohnt sich nur bei eigenen Fine-Tuned-Modellen. Wer auf einer AMD-GPU arbeitet, hat mit AWQ oder GPTQ via GPT-QModel beide GPU-Formate als Option. AutoGPTQ ist abgekündigt und sollte durch GPT-QModel ersetzt werden.

Weiterführende Anleitungen und Quellen

1. Ollama-Modelle richtig auswählen: VRAM, Quantisierung und Modellvergleich für KMU
2. Offene LLMs selbst serven mit vLLM (Llama, Mistral, Hermes)
3. DeepSeek R1 lokal betreiben: Modellwahl, Quantisierung und VRAM-Bedarf
4. GPU für lokale KI auswählen: VRAM-Bedarf, RTX-Generationen und Budget-Empfehlungen 2026
5. Hugging Face – Quantization Overview (offizielle Dokumentation)
6. oobabooga – GPTQ vs. AWQ vs. EXL2 vs. llama.cpp Benchmark (RTX 3090)

Passende Anleitungen auf S-EDV

1. GPT-5.5-Cyber: OpenAI startet Sicherheitsmodell als Konkurrenz zu Anthropic Myth
2. Anthropic veröffentlicht Claude Fable 5 und Mythos 5: Frontier-Modell mit Sicher
3. NVIDIA GPU Display Driver: 14 Sicherheitslücken geschlossen – Update dringend nö