GGUF, AWQ und GPTQ erklärt: Welches Quantisierungsformat für welchen Zweck
GGUF, AWQ und GPTQ im Vergleich: welches Quantisierungsformat zu CPU, Apple Silicon, NVIDIA- oder AMD-GPU passt, mit Befehlen für Ollama, llama.cpp, vLLM und aktuellen Quantisierungswerkzeugen.
Geprüft am 30.09.2026 · für vllm 0.30.0, llmcompressor 0.14.0, gptqmodel 7.5.0
WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu

Wer ein Large Language Model lokal betreibt, muss sich zwischen den Quantisierungsformaten GGUF, AWQ und GPTQ entscheiden. Alle drei reduzieren ein Modell von 16-Bit-Gewichten (FP16/BF16) typischerweise auf 4 Bit und sparen damit rund 70 % Speicher. Bei 4 Bit liegen die Formate in der Qualität nah beieinander, sie unterscheiden sich aber deutlich in Hardware-Unterstützung, Werkzeugen und Geschwindigkeit. Diese Anleitung ordnet die Formate ein, zeigt die Einrichtung mit Ollama, llama.cpp, Transformers und vLLM und nennt die typischen Fallstricke.
Voraussetzungen
- GGUF auf der CPU: x86-CPU mit AVX2 oder ARM64, mindestens 8 GB RAM für ein 8B-Modell in Q4_K_M (16 GB empfohlen).
- GGUF auf Apple Silicon: Mac mit M1 oder neuer, Metal wird von llama.cpp, Ollama und LM Studio direkt genutzt.
- AWQ/GPTQ: NVIDIA-GPU mit mindestens 8 GB VRAM für 8B-Modelle, aktueller Treiber mit CUDA 12. Für die Marlin-Kernel in vLLM ist eine GPU ab Ampere (RTX 30, A100) nötig.
- Python 3.10 oder neuer in einer virtuellen Umgebung für Transformers, vLLM, LLM Compressor und GPT-QModel.
- Hugging-Face-Konto und Token für zugangsbeschränkte Modelle wie Llama 3.1.
Was Quantisierung bedeutet und warum das Format zählt
Post-Training-Quantisierung (PTQ) komprimiert die Gewichte nach dem Training. Ein Modell mit 8 Milliarden Parametern belegt in BF16 rund 16 GB, als 4-Bit-Variante 4,5 bis 5 GB. Im Vergleich von oobabooga (Llama 2 13B, RTX 3090) lagen die Perplexitätswerte von AWQ, GPTQ und GGUF Q4_K_M bei 4 Bit sehr nah beieinander, der Unterschied ist im Alltag kaum spürbar.
Die Verfahren unterscheiden sich im Algorithmus: GGUF ist das Dateiformat von llama.cpp mit k-quants, bei denen wichtige Tensoren eine höhere Bitbreite behalten. AWQ (Activation-aware Weight Quantization) schützt anhand von Kalibrierungsdaten den kleinen Anteil der Gewichte, der für die Aktivierungen am wichtigsten ist. GPTQ quantisiert schichtweise und korrigiert den Fehler mithilfe von Informationen zweiter Ordnung.
Entscheidungsbaum: Welches Format passt zu Ihrer Hardware?
| Situation | Empfehlung | Begründung |
|---|---|---|
| Mac mit Apple Silicon | GGUF (alternativ MLX) | Metal-Beschleunigung in llama.cpp, Ollama und LM Studio |
| Server ohne GPU | GGUF | Optimierte CPU-Kernel (AVX2, AVX-512, NEON) |
| Modell größer als der VRAM | GGUF | llama.cpp verteilt Schichten auf GPU und CPU |
| NVIDIA-GPU, Einzelplatz | GGUF, AWQ oder GPTQ | Alle laufen; GGUF ist mit Ollama am einfachsten |
| NVIDIA-GPU, API mit vielen parallelen Anfragen | AWQ oder GPTQ mit vLLM | Hoher Durchsatz durch Batching und Marlin-Kernel |
| AMD-GPU | GGUF (ROCm/HIP oder Vulkan), GPTQ | llama.cpp und GPT-QModel unterstützen ROCm |
| Eigenes feinabgestimmtes Modell | AWQ oder GPTQ, für Endgeräte GGUF | Quantisierung mit LLM Compressor, GPT-QModel oder llama-quantize |
Format-Direktvergleich: GGUF, AWQ und GPTQ
| Merkmal | GGUF | AWQ | GPTQ |
|---|---|---|---|
| Verfahren | k-quants, gemischte Bitbreiten | aktivierungsbasiert | schichtweise Fehlerkorrektur |
| Bitbreiten | 1,5 bis 8 Bit | 4 Bit | 2, 3, 4, 8 Bit |
| CPU | ja, schnell | nicht sinnvoll | über GPT-QModel, langsam |
| Apple Silicon | ja (Metal) | über MLX-LM | über GPT-QModel |
| NVIDIA CUDA | ja | ja | ja |
| AMD ROCm | ja (HIP, Vulkan) | eingeschränkt | ja (GPT-QModel) |
| Kalibrierungsdaten | optional (imatrix) | ja, wenige hundert Beispiele | ja |
| Werkzeuge | llama.cpp, Ollama, LM Studio | vLLM, Transformers, LLM Compressor | vLLM, Transformers, GPT-QModel |
Schritt 1: GGUF-Modelle mit Ollama oder llama.cpp laden
Ollama verwaltet GGUF-Modelle selbst, der Standard-Tag der meisten Modelle ist Q4_K_M:
# Ollama installieren (Linux)
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
# Bestimmte Quantisierung über den Tag wählen
ollama run llama3.1:8b-instruct-q5_K_MDie verfügbaren Quantisierungen eines Modells zeigt die Tag-Liste auf ollama.com/library. Mit llama.cpp laden Sie GGUF-Dateien direkt von Hugging Face:
# llama.cpp mit CUDA bauen (ohne GPU: -DGGML_CUDA=ON weglassen)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j
# Modell von Hugging Face laden und starten
./build/bin/llama-cli -hf bartowski/Meta-Llama-3.1-8B-Instruct-GGUF:Q4_K_M
# Eigenes HF-Modell konvertieren und quantisieren
python convert_hf_to_gguf.py ./mein-modell --outfile mein-modell-f16.gguf
./build/bin/llama-quantize mein-modell-f16.gguf mein-modell-Q4_K_M.gguf Q4_K_MVerifizieren: Das Modell antwortet im Terminal. ollama list zeigt für llama3.1:8b rund 4,9 GB, ollama ps zeigt unter PROCESSOR, ob das Modell vollständig auf der GPU läuft (100% GPU).
GGUF-Quantisierungsstufen: welche Stufe für welchen Bedarf?
Die k-quant-Varianten (K_S = small, K_M = medium) halten ausgewählte Tensoren in höherer Bitbreite. Die Dateigrößen gelten für Llama 3.1 8B Instruct (bartowski). Im Betrieb kommen Kontext-Cache und Laufzeit hinzu, rechnen Sie mit 1 bis 2 GB mehr.
| Stufe | Dateigröße (8B) | Qualität | Einsatz |
|---|---|---|---|
| Q2_K | 3,2 GB | deutlich reduziert | nur bei extremem Speichermangel |
| Q3_K_M | 4,0 GB | spürbar reduziert | sehr knappe Hardware |
| Q4_K_S | 4,7 GB | gut | wenig Speicher |
| Q4_K_M | 4,9 GB | gut | Standard für lokale Nutzung |
| Q5_K_M | 5,7 GB | sehr gut | wenn Speicher reicht |
| Q6_K | 6,6 GB | nahezu verlustfrei | hohe Qualitätsansprüche |
| Q8_0 | 8,5 GB | praktisch verlustfrei | Referenz |
Q4_K_M kostet gegenüber Q4_K_S rund 230 MB mehr und ist meist die bessere Wahl. Unter 4 Bit leidet die Qualität bei komplexen Aufgaben sichtbar, bei kleinen Modellen stärker als bei großen.
Schritt 2: AWQ-Modelle nutzen und selbst erstellen
Für den Produktivbetrieb laden Sie AWQ-Modelle in vLLM. vLLM erkennt das Format aus der Modellkonfiguration und wählt auf NVIDIA ab Ampere den Marlin-Kernel (awq_marlin):
python3 -m venv ~/venv-vllm && . ~/venv-vllm/bin/activate
pip install vllm
vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ --host 127.0.0.1 --port 8000Die Angabe --quantization awq ist optional und erzwingt den langsameren Kernel ohne Marlin. Binden Sie vLLM wie oben an 127.0.0.1 und veröffentlichen Sie die API nur über einen Reverse Proxy mit Authentifizierung.
Eigene AWQ-Modelle erstellen Sie mit LLM Compressor aus dem vLLM-Projekt (pip install llmcompressor). Das frühere AutoAWQ ist laut seinem Entwickler eingestellt und wurde vom vLLM-Projekt übernommen:
from transformers import AutoModelForCausalLM, AutoTokenizer
from llmcompressor import oneshot
from llmcompressor.modifiers.quantization import QuantizationModifier
from llmcompressor.modifiers.transform.awq import AWQModifier
MODEL_ID = "meta-llama/Meta-Llama-3.1-8B-Instruct"
model = AutoModelForCausalLM.from_pretrained(MODEL_ID)
tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)
recipe = [
AWQModifier(),
QuantizationModifier(ignore=["lm_head"], scheme="W4A16_ASYM", targets=["Linear"]),
]
oneshot(model=model, dataset="open_platypus", recipe=recipe,
max_seq_length=512, num_calibration_samples=256)
model.save_pretrained("Llama-3.1-8B-Instruct-AWQ", save_compressed=True)
tokenizer.save_pretrained("Llama-3.1-8B-Instruct-AWQ")Das Ergebnis liegt im Format compressed-tensors vor, das vLLM direkt lädt.
Verifizieren: curl -s http://127.0.0.1:8000/v1/models listet das Modell, das vLLM-Log nennt beim Start die gewählte Quantisierung (zum Beispiel awq_marlin), und nvidia-smi zeigt den belegten VRAM. vLLM reserviert standardmäßig 90 % des VRAM für Modell und Cache (--gpu-memory-utilization).
Schritt 3: GPTQ-Modelle nutzen und mit GPT-QModel erstellen
GPTQ-Modelle gibt es auf Hugging Face in großer Zahl. vLLM lädt sie ebenfalls automatisch und nutzt ab Ampere gptq_marlin:
vllm serve Qwen/Qwen2.5-7B-Instruct-GPTQ-Int4 --host 127.0.0.1 --port 8000In Transformers ersetzt GPT-QModel das nicht mehr unterstützte AutoGPTQ. GPT-QModel läuft zusätzlich auf AMD ROCm, Apple Silicon und CPUs:
# pip install --upgrade accelerate optimum transformers
# pip install gptqmodel --no-build-isolation
from transformers import AutoModelForCausalLM, AutoTokenizer, GPTQConfig
MODEL_ID = "meta-llama/Meta-Llama-3.1-8B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)
gptq_config = GPTQConfig(bits=4, dataset="c4", tokenizer=tokenizer)
model = AutoModelForCausalLM.from_pretrained(
MODEL_ID, device_map="auto", quantization_config=gptq_config
)
model.save_pretrained("Llama-3.1-8B-Instruct-GPTQ")
tokenizer.save_pretrained("Llama-3.1-8B-Instruct-GPTQ")Laut Hugging Face dauert die Quantisierung eines 175B-Modells auf einer A100 rund 4 Stunden, ein 8B-Modell ist je nach GPU und Kalibrierungsdaten deutlich schneller fertig.
Verifizieren: Im Ausgabeordner liegt eine config.json mit "quant_method": "gptq" und "bits": 4. Ein Testaufruf mit model.generate() liefert sinnvollen Text, und vllm serve ./Llama-3.1-8B-Instruct-GPTQ startet ohne Fehler.
Speicherbedarf im Überblick: Llama 3.1 8B
| Format | Gewichte | Anmerkung |
|---|---|---|
| BF16 (unquantisiert) | ca. 16 GB | Referenz |
| GGUF Q8_0 | 8,5 GB | praktisch verlustfrei |
| GGUF Q4_K_M | 4,9 GB | Standard in Ollama |
| AWQ oder GPTQ 4 Bit, Group Size 128 | ca. 5,5 GB | Einbettung und Ausgabeschicht bleiben meist in 16 Bit |
Hinzu kommt der Kontext-Cache, der mit Kontextlänge und Zahl paralleler Anfragen wächst. Eine kleinere Group Size (32 statt 128) speichert mehr Skalierungsfaktoren, vergrößert das Modell leicht und verbessert die Genauigkeit etwas. 128 ist der übliche Standard.
Typische Fehler und Lösungen
AutoGPTQ und AutoAWQ sind eingestellt
Code mit from auto_gptq import ... funktioniert mit aktuellen Transformers-Versionen nicht mehr, stellen Sie auf GPT-QModel um. AutoAWQ ist ebenfalls eingestellt und setzt Transformers bei der Installation auf eine ältere Version zurück. Für neue AWQ-Modelle nutzen Sie LLM Compressor, zum Ausführen vLLM.
GGUF über Transformers verliert die Kompression
Transformers entpackt GGUF-Dateien beim Laden in der Regel in unquantisierte Gewichte, der Speichervorteil entfällt. Betreiben Sie GGUF-Modelle mit llama.cpp, Ollama oder LM Studio.
Fused Modules in Transformers greifen nicht
Fused Modules für AWQ gibt es in Transformers nur für Llama- und Mistral-Architekturen, andere brauchen eine eigene modules_to_fuse-Konfiguration. Sie lassen sich nicht mit FlashAttention 2 kombinieren. Für schnelle Inferenz ist vLLM der einfachere Weg.
Selbst quantisieren ist oft unnötig
Suchen Sie vorher auf Hugging Face nach fertigen Varianten, etwa beim Modellhersteller oder bei bartowski und unsloth. Eigenes Quantisieren lohnt sich vor allem für feinabgestimmte Modelle.
AWQ auf Apple Silicon schlägt fehl
Transformers und vLLM unterstützen AWQ auf Metal nicht. Nutzen Sie auf dem Mac GGUF (Ollama, LM Studio) oder MLX-Modelle.
Schlechte Qualität nach der Quantisierung eines Code-Modells
Passen die Kalibrierungsdaten (Standard: C4 oder Wikitext) nicht zum Einsatzzweck, leidet die Qualität. Kalibrieren Sie Code-Modelle mit Code-Beispielen und prüfen Sie das Ergebnis mit eigenen Testaufgaben.
vLLM lehnt den Quantisierungswert ab
--quantization gguf und --quantization bitsandbytes sind in aktuellen vLLM-Versionen keine gültigen Werte. Lassen Sie den Parameter weg, vLLM erkennt das Format selbst. GGUF ist in vLLM laut Dokumentation experimentell. Für GGUF auf GPU-Servern ist llama-server aus llama.cpp die robustere Wahl, für hohen Durchsatz AWQ oder GPTQ.
Häufige Fragen
Welches Format nehme ich für einen Mac mit Apple Silicon?
GGUF mit Ollama oder LM Studio, Q4_K_M als Standard. Alternativ MLX-Modelle, die LM Studio ebenfalls lädt.
Was ist der Unterschied zwischen Q4_K_M und Q4_K_S?
Q4_K_M hält mehr Tensoren in höherer Bitbreite und ist etwas genauer. Q4_K_S ist rund 5 % kleiner und passt, wenn der Speicher knapp ist.
Kann ich quantisierte Modelle auf einer AMD-GPU betreiben?
Ja. llama.cpp unterstützt AMD-GPUs über HIP (ROCm) und Vulkan, Ollama bringt ROCm-Unterstützung mit. GPTQ läuft über GPT-QModel auf ROCm, vLLM hat ein eigenes ROCm-Image. Prüfen Sie die unterstützten GPU-Modelle in der jeweiligen Dokumentation.
Muss ich Modelle selbst quantisieren?
Meist nicht. Für verbreitete Modelle wie Llama, Mistral, Qwen und Gemma gibt es fertige GGUF-, AWQ- und GPTQ-Varianten, oft direkt vom Hersteller.
Welches Format nimmt man für vLLM in der Produktion?
AWQ oder GPTQ in 4 Bit, auf Hopper- und Blackwell-GPUs auch FP8. vLLM wählt den passenden Kernel selbst. GGUF eignet sich für vLLM nur eingeschränkt.
Lohnt sich 8 Bit statt 4 Bit?
Q8_0 ist praktisch verlustfrei, braucht aber etwa 75 % mehr Speicher als Q4_K_M und läuft langsamer. Oft ist ein größeres Modell in Q4_K_M die bessere Wahl als ein kleines in Q8_0.
Fazit
Die Wahl zwischen GGUF, AWQ und GPTQ ist vor allem eine Hardware- und Werkzeugfrage. CPU, Mac und Einzelplatzrechner: GGUF mit Q4_K_M. GPU-Server mit vielen parallelen Anfragen: AWQ oder GPTQ mit vLLM. Laden Sie bevorzugt fertig quantisierte Modelle und nutzen Sie zum Selbstquantisieren die gepflegten Werkzeuge LLM Compressor und GPT-QModel statt AutoAWQ und AutoGPTQ.
Weiterführende Anleitungen und Quellen
- Ollama-Modelle richtig auswählen: VRAM, Quantisierung und Modellvergleich für KMU
- Offene LLMs selbst serven mit vLLM (Llama, Mistral, Hermes)
- DeepSeek R1 lokal betreiben: Modellwahl, Quantisierung und VRAM-Bedarf
- GPU für lokale KI auswählen: VRAM-Bedarf und RTX-Generationen
- Hugging Face: Quantization Overview
- vLLM: Quantization
- LLM Compressor (GitHub)
- oobabooga: GPTQ vs. AWQ vs. EXL2 vs. llama.cpp (RTX 3090)


