LLM quantisieren: GGUF, GPTQ & AWQ bis 75% kleiner [2026]

Ein 27-Milliarden-Parameter-Modell in voller Präzision braucht über 50 GB Speicher. Auf einer Grafikkarte mit 12 GB VRAM, wie sie in vielen deutschen Gaming-PCs steckt, lässt sich das schlicht nicht laden. Genau hier setzt Quantisierung an: Sie drückt die Gewichte eines Sprachmodells von 16-Bit-Gleitkommazahlen auf 8, 6, 4 oder sogar 2 Bit zusammen, ohne das Modell komplett neu zu trainieren. Das Ergebnis läuft auf Consumer-Hardware, oft mit kaum messbarem Qualitätsverlust.

Dieses Tutorial zeigt Schritt für Schritt, wie man ein offenes LLM selbst quantisiert, und zwar mit drei der wichtigsten Werkzeuge im September/Oktober 2026: dem GGUF-Workflow von llama.cpp, dem GPTQModel-Toolkit in Version 7.5.0 und AWQ über Transformers. Am Ende steht ein komplettes, lauffähiges Projekt, das ein Basismodell einliest, in mehrere Quantisierungsstufen umwandelt und die Ergebnisse nach VRAM-Bedarf, Tokens pro Sekunde und Antwortqualität vergleicht.

Was Quantisierung technisch bedeutet

Ein neuronales Netz besteht aus Milliarden Gewichten, die normalerweise als 16-Bit- oder 32-Bit-Gleitkommazahlen gespeichert sind. Quantisierung rundet diese Werte auf ein gröberes Raster herunter, etwa auf 4-Bit-Integer, und speichert zusätzlich kleine Skalierungsfaktoren, um den Fehler pro Gewichtsblock klein zu halten. Je kleiner die Bit-Breite, desto weniger Speicher und Bandbreite braucht das Modell zur Inferenz, aber auch desto größer der potenzielle Qualitätsverlust.

Schon vor der eigentlichen Quantisierung lohnt sich ein Blick auf das Ausgangsformat. Die meisten aktuellen Modelle werden in bf16 (Bfloat16) statt im klassischen fp16 veröffentlicht, weil bf16 den größeren Wertebereich von 32-Bit-Zahlen beibehält, bei der Präzision aber wie fp16 nur 16 Bit belegt. Für die Quantisierung selbst macht das kaum einen Unterschied, wichtig ist aber, beim Laden des Basismodells das richtige Format anzugeben, da ein falsch interpretiertes bf16-Modell zu numerisch instabilen Zwischenergebnissen führen kann, lange bevor überhaupt die eigentliche 4-Bit- oder 8-Bit-Rundung beginnt.

Drei Formate dominieren aktuell die Praxis. GGUF ist ein Containerformat aus dem llama.cpp-Projekt (ggml-org), das Gewichte, Tokenizer und Chat-Template in einer Datei bündelt und damit besonders portabel ist, dokumentiert direkt auf der Hugging-Face-Dokumentationsseite zu GGUF. GPTQ ist ein kalibrierungsbasiertes Post-Training-Quantisierungsverfahren, das mit einem kleinen Kalibrierungsdatensatz pro Layer optimiert, welche Gewichte am empfindlichsten sind. AWQ (Activation-aware Weight Quantization) geht einen ähnlichen Weg, gewichtet aber zusätzlich nach der Aktivierungsverteilung, um besonders wichtige Kanäle zu schonen.

Ein weiterer Unterschied liegt in der Granularität der Rundung. Manche Verfahren runden pro Tensor insgesamt (per-tensor), andere pro Kanal (per-channel) oder sogar pro kleiner Gewichtsgruppe (per-group), wie es die GGUF-k-Quants und GPTQ mit ihrem group_size-Parameter tun. Je feiner die Granularität, desto genauer das Ergebnis, aber desto mehr zusätzliche Skalierungsfaktoren muss das Format mitspeichern. Außerdem unterscheidet man symmetrische Quantisierung, bei der der Wertebereich um null zentriert ist, von asymmetrischer Quantisierung mit einem zusätzlichen Offset. Für die meisten LLM-Gewichte reicht symmetrische Quantisierung aus, bei Aktivierungen mit stark verschobener Verteilung liefert die asymmetrische Variante oft bessere Ergebnisse.

Für deutsche Entwicklerteams ist dabei ein praktischer Punkt wichtig: Die Wahl des Formats entscheidet nicht nur über Speicherbedarf, sondern auch darüber, welche Inferenz-Engine später zum Einsatz kommt. GGUF ist eng an llama.cpp und darauf aufbauende Tools wie Ollama oder LM Studio gekoppelt. GPTQ und AWQ dagegen laufen meist über Transformers, vLLM oder spezialisierte Serving-Frameworks, die stärker auf Durchsatz in Multi-User-Szenarien ausgelegt sind. Wer also ein Modell für einen einzelnen Entwickler-Laptop quantisiert, trifft eine andere Entscheidung als jemand, der ein Modell hinter einer internen API für ein ganzes Team bereitstellen will.

Wichtig für die Einordnung: AutoAWQ und AutoGPTQ, lange die Standardwerkzeuge für diese Formate, gelten laut aktuellen Mistral-Ressourcenübersichten inzwischen als archiviert beziehungsweise nicht mehr aktiv gepflegt. Wer heute neu einsteigt, sollte direkt auf GPTQModel oder die native Quantisierungsunterstützung in Transformers setzen, siehe die Transformers-Dokumentation zu Quantisierungsverfahren. Dieses Tutorial folgt deshalb konsequent dem aktiven Toolchain-Pfad.

Voraussetzungen und Versionen

Bevor es losgeht, sollten folgende Komponenten in diesen oder neueren Versionen installiert sein. Die Angaben gelten für den Stand Oktober 2026:

Komponente	Mindestversion	Zweck
Python	3.11 oder 3.12	Laufzeitumgebung für alle Skripte
CUDA Toolkit	12.4+ (bei Nvidia-GPU)	Beschleunigte Quantisierung und Inferenz
PyTorch	2.5+	Basis für Transformers und GPTQModel
Transformers	aktuelle Version aus PyPI	Modell laden, AWQ-Pfad, GGUF-Inferenz
GPTQModel	7.5.0 (Stand September 2026)	GPTQ-, AWQ- und GGUF-Quantisierung aus einem Toolkit
llama.cpp	aktueller Git-Stand	GGUF-Konvertierung und CPU/GPU-Inferenz
Arbeitsspeicher	mind. 32 GB RAM	Laden des unquantisierten Basismodells
GPU-VRAM	mind. 8 GB, empfohlen 12-16 GB	Kalibrierung bei GPTQ/AWQ
Festplatte	mind. 60 GB frei	Basismodell plus mehrere Quantisierungsvarianten

Als Beispielmodell nutzt dieses Tutorial ein offenes 7B-Instruct-Modell aus der Qwen- oder Llama-Familie. Das Prinzip bleibt bei größeren Modellen wie einem 27B-Modell identisch, nur Zeit- und Speicherbedarf steigen proportional. GPTQModel 7.5.0 selbst brachte im September 2026 unter anderem Quantisierungsunterstützung für weitere Architekturen wie Qwen3-VL-MoE, OLMoE, EXAONE 4.5, InterVL und SmolVLM hinzu, sowie fortsetzbare Quantisierungs-Checkpoints, mit denen ein unterbrochener Lauf bei großen Modellen nicht komplett neu starten muss.

Ein Hinweis zur Zeitplanung: Für ein 7B-Modell dauert die GGUF-Konvertierung samt Q4_K_M-Quantisierung auf einer Mittelklasse-GPU üblicherweise zwischen fünf und zehn Minuten. GPTQ- und AWQ-Kalibrierung mit 128 Prompts brauchen je nach Hardware zwischen fünf und fünfzehn Minuten zusätzlich, weil hier tatsächlich Forward-Pässe durch das gesamte Modell laufen. Bei einem 27B-Modell verzehnfacht sich die Zeit grob, weshalb sich für größere Modelle ein Blick auf Cloud-GPU-Stunden lohnt, siehe weiter unten im Abschnitt zu Cloud-Optionen. Wer ohnehin nur gelegentlich quantisiert, kommt mit einer gemieteten GPU günstiger weg als mit eigener Hardware, die den Großteil der Zeit ungenutzt bleibt.

Welche Quantisierungsstufe zu welcher Hardware passt

Bevor es an die eigentliche Konvertierung geht, lohnt sich ein Blick darauf, welche Hardware in deutschen Haushalten und Büros tatsächlich verbreitet ist. Die folgende Übersicht ordnet gängige Grafikkarten und Apple-Silicon-Chips den passenden Quantisierungsstufen für ein 7B- bis 8B-Modell zu. Bei größeren Modellen verschiebt sich die Empfehlung automatisch eine oder zwei Stufen nach unten.

Hardware	VRAM / Unified Memory	Empfohlene Stufe	Hinweis
RTX 4060 / 4060 Ti	8-16 GB	Q4_K_M oder GPTQ-4Bit	Bei 8 GB bleibt wenig Puffer für langen Kontext
RTX 4070 / 4070 Super	12 GB	Q5_K_M bis Q6_K	Guter Kompromiss zwischen Qualität und Tempo
RTX 4080 / 4090	16-24 GB	Q6_K bis Q8_0	Kaum spürbarer Qualitätsverlust bei viel Puffer
Apple M3 Pro / M4 Pro	18-36 GB Unified Memory	Q5_K_M bis Q6_K (GGUF/MLX)	MLX-Builds oft etwas schneller als reines GGUF
Ältere Laptop-GPU, 6 GB	6 GB	Q3_K_M bis Q4_K_M	Kontextlänge bewusst klein halten

Diese Tabelle ist ein Startpunkt, kein Ersatz für den eigenen Benchmark aus Schritt 9. Faustregel für den groben Überschlag: Die Dateigröße der GGUF-Variante sollte mindestens 1,5 GB Puffer unter dem verfügbaren VRAM liegen, damit auch bei längeren Kontexten und mehreren offenen Anwendungen noch Platz bleibt. Wer regelmäßig mit 8.000 oder 16.000 Tokens Kontext arbeitet, sollte den Puffer eher auf 2,5 bis 3 GB erhöhen, da der Key-Value-Cache mit der Kontextlänge wächst und zusätzlich zum Modell selbst Speicher braucht.

Schritt 1: Projektumgebung aufsetzen

Zuerst ein isoliertes virtuelles Environment anlegen, damit Paketversionen zwischen Projekten nicht kollidieren. Das ist besonders wichtig, weil GPTQModel, Transformers und llama.cpp jeweils eigene Abhängigkeitsbäume mitbringen.

mkdir llm-quantisierung && cd llm-quantisierung
python3 -m venv venv
source venv/bin/activate

pip install --upgrade pip
pip install torch --index-url https://download.pytorch.org/whl/cu124
pip install transformers accelerate huggingface_hub
pip install gptqmodel

Auf macOS mit Apple Silicon fällt die CUDA-Zeile weg, PyTorch nutzt dort automatisch das MPS-Backend. Die Kalibrierung für GPTQ und AWQ profitiert jedoch deutlich von einer Nvidia-GPU, auf Mac dauert dieser Schritt entsprechend länger.

Schritt 2: llama.cpp für den GGUF-Pfad bauen

Für die GGUF-Konvertierung wird das llama.cpp-Repository von ggml-org direkt aus den Quellen gebaut. Das Projekt liefert sowohl das Konvertierungsskript als auch den Quantisierungs-Binary mit.

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j$(nproc)
pip install -r requirements.txt
cd ..

Ohne Nvidia-GPU lässt sich -DGGML_CUDA=ON einfach weglassen, llama.cpp läuft dann auf der CPU oder nutzt bei Apple Silicon automatisch Metal. Der Build dauert je nach Rechner zwischen drei und zehn Minuten.

Schritt 3: Basismodell herunterladen

Als Ausgangspunkt dient das unquantisierte Modell im Safetensors-Format von Hugging Face. Für dieses Tutorial reicht ein 7B-Instruct-Modell, das Prinzip lässt sich später 1:1 auf größere Modelle übertragen.

huggingface-cli download Qwen/Qwen2.5-7B-Instruct \
  --local-dir ./basis-modell \
  --local-dir-use-symlinks False

Der Download zieht etwa 15 GB an Gewichten, Tokenizer-Dateien und Konfiguration. Bei langsamer Leitung lohnt es sich, den Befehl in einer tmux-Session laufen zu lassen, da ein Abbruch mitten im Download zu beschädigten Shard-Dateien führen kann.

Schritt 4: Nach GGUF konvertieren

Der erste Quantisierungspfad führt über GGUF. Zunächst wird das Safetensors-Modell in eine unquantisierte GGUF-Datei (F16) umgewandelt, danach erst auf die gewünschte Bit-Breite heruntergerechnet.

python llama.cpp/convert_hf_to_gguf.py ./basis-modell \
  --outfile ./modell-f16.gguf \
  --outtype f16

./llama.cpp/build/bin/llama-quantize \
  ./modell-f16.gguf \
  ./modell-q4_k_m.gguf \
  Q4_K_M

Die zweistufige Konvertierung ist kein Zufall: Das Quantisierungsprogramm braucht die F16-Zwischendatei als Referenz, um die Rundungsfehler pro Tensor-Block zu berechnen. Wer direkt von Safetensors auf 4-Bit springen will, ohne die F16-Datei zu behalten, kann sie nach dem Quantisieren wieder löschen, braucht aber während der Konvertierung selbst den vollen Festplattenplatz für beide Dateien gleichzeitig.

Gängige GGUF-Varianten und ihre Eigenschaften im Überblick:

GGUF-Variante	Effektive Bit-Breite	Typische Dateigröße (7B-Modell)	Empfehlung
Q8_0	~8 Bit	ca. 7,5 GB	Kaum Qualitätsverlust, für 16+ GB VRAM
Q6_K	~6 Bit	ca. 5,5 GB	Guter Kompromiss bei viel Speicher
Q5_K_M	~5 Bit	ca. 4,8 GB	Solide Qualität, moderater Speicherbedarf
Q4_K_M	~4 Bit	ca. 4,1 GB	Hugging Face empfiehlt diesen Einstiegspunkt
Q3_K_M	~3 Bit	ca. 3,3 GB	Nur bei sehr engem VRAM-Budget
Q2_K	~2 Bit	ca. 2,6 GB	Deutlich sichtbarer Qualitätsverlust möglich

Die Namensgebung von GGUF folgt einem Muster: Der Buchstabe nach der Bit-Zahl (K) steht für k-Quants, ein neueres Verfahren, das innerhalb eines Blocks unterschiedlich wichtige Gewichte unterschiedlich fein rundet. Das _M am Ende steht für “medium” innerhalb dieser Quant-Familie, es gibt zusätzlich _S (small) und _L (large) Varianten mit jeweils anderer Speicher/Qualität-Abwägung.

Für noch genauere Ergebnisse lässt sich llama.cpp zusätzlich mit einer Importance Matrix (kurz imatrix) füttern. Dabei läuft das F16-Modell vorab über einen Beispieltext, und das Tool zeichnet auf, wie stark jedes Gewicht tatsächlich zur Ausgabe beiträgt. Die Quantisierung rundet anschließend wichtige Gewichte feiner und unwichtige gröber, ganz ähnlich wie es GPTQ und AWQ auf ihre Weise tun, nur eben innerhalb des GGUF-Ökosystems. Der Zusatzaufwand lohnt sich besonders bei den aggressiveren Stufen wie Q3_K_M oder Q2_K, wo jedes Prozent an zusätzlicher Präzision einen messbaren Unterschied in der Antwortqualität macht. Der Befehl dafür sieht in der Praxis so aus:

./llama.cpp/build/bin/llama-imatrix \
  -m ./modell-f16.gguf \
  -f kalibrierungstext.txt \
  -o imatrix.dat

./llama.cpp/build/bin/llama-quantize \
  --imatrix imatrix.dat \
  ./modell-f16.gguf \
  ./modell-q3_k_m_imatrix.gguf \
  Q3_K_M

Schritt 5: GPTQ-Quantisierung mit GPTQModel

GPTQ unterscheidet sich fundamental von der reinen Rundungslogik der GGUF-k-Quants: Es braucht einen kleinen Kalibrierungsdatensatz, um pro Layer zu bestimmen, welche Gewichte den größten Einfluss auf den Ausgabefehler haben. Das GPTQModel-Repository bündelt diesen Prozess in wenigen Codezeilen.

from gptqmodel import GPTQModel, QuantizeConfig

kalibrierungsdaten = [
    "Erkläre die Vorteile von Quantisierung in der KI-Entwicklung.",
    "Schreibe eine kurze Zusammenfassung über erneuerbare Energien.",
    "Was sind die Grundlagen der Transformer-Architektur?",
    # 128-256 repräsentative Prompts liefern stabilere Ergebnisse
]

quant_config = QuantizeConfig(bits=4, group_size=128)

modell = GPTQModel.load("./basis-modell", quant_config)
modell.quantize(kalibrierungsdaten)
modell.save("./modell-gptq-4bit")

Die group_size bestimmt, wie viele Gewichte sich einen gemeinsamen Skalierungsfaktor teilen. Kleinere Gruppen (64 statt 128) erhöhen die Genauigkeit, aber auch den Speicherbedarf für die Skalierungsfaktoren selbst, bei sehr kleinen Gruppen kann der Overhead den Speichervorteil der Quantisierung teilweise wieder aufheben. Die Kalibrierungsdaten sollten idealerweise aus der Zieldomäne stammen: Wer das Modell später für deutsche Kundenservice-Texte einsetzt, kalibriert mit deutschen Kundenservice-Beispielen statt mit generischen englischen Sätzen.

Schritt 6: AWQ als Alternative kalibrieren

AWQ verfolgt eine ähnliche Idee wie GPTQ, gewichtet aber zusätzlich nach Aktivierungsgrößen: Kanäle, die bei typischen Eingaben besonders stark aktiviert werden, bleiben präziser, weniger wichtige Kanäle werden aggressiver gerundet. GPTQModel deckt inzwischen auch diesen Pfad ab, sodass sich beide Verfahren mit demselben Toolkit vergleichen lassen.

from gptqmodel import GPTQModel, QuantizeConfig

quant_config_awq = QuantizeConfig(
    bits=4,
    group_size=128,
    quant_method="awq"
)

modell_awq = GPTQModel.load("./basis-modell", quant_config_awq)
modell_awq.quantize(kalibrierungsdaten)
modell_awq.save("./modell-awq-4bit")

In der Praxis liefern GPTQ und AWQ bei 4 Bit meist vergleichbare Qualität, AWQ gilt in mehreren Community-Benchmarks als leicht robuster bei sehr aggressiver Quantisierung unter 4 Bit, während GPTQ oft minimal schnellere Inferenz-Kernels zur Verfügung hat. Der einzig verlässliche Weg, das für den eigenen Anwendungsfall zu beurteilen, ist der direkte Vergleich auf den eigenen Testprompts, siehe Schritt 9.

Ein praktischer Tipp für die Kalibrierungsphase: Beide Verfahren reagieren empfindlich auf die Reihenfolge und Vielfalt der Kalibrierungsdaten. Wer nur sehr ähnliche Sätze verwendet, etwa zwanzig Varianten derselben Frage, bekommt ein Modell, das auf genau diesen Mustern gut funktioniert, aber bei abweichenden Eingaben stärker streut. Besser ist eine Mischung aus kurzen und langen Prompts, Fragen und Anweisungen, sowie, falls die Zielsprache Deutsch ist, ein deutlicher Anteil deutscher Sätze mit Umlauten und zusammengesetzten Wörtern, da diese Tokenisierung sich von rein englischen Texten unterscheidet.

Lizenzfragen bei quantisierten Modellen

Ein Punkt, der in vielen Tutorials untergeht: Die Quantisierung selbst erzeugt kein neues Werk im lizenzrechtlichen Sinne, sie bleibt eine abgeleitete Form des Basismodells. Das bedeutet, die Lizenzbedingungen des Originalmodells gelten unverändert weiter, inklusive eventueller Einschränkungen bei kommerzieller Nutzung, Attributionspflichten oder Beschränkungen für bestimmte Anwendungsfälle. Wer ein Modell unter einer restriktiven Lizenz quantisiert und das Ergebnis dann öffentlich auf Hugging Face teilt, muss weiterhin dieselben Bedingungen einhalten wie beim Originalmodell.

Für Unternehmen in Deutschland und Österreich, die ein quantisiertes Modell produktiv einsetzen wollen, lohnt sich deshalb ein Blick in die Modellkarte auf Hugging Face, noch vor dem ersten Download. Dort stehen in der Regel Angaben zur zugrunde liegenden Lizenz, etwa Apache 2.0, MIT oder eine modellspezifische Lizenz mit Nutzungsbeschränkungen. Bei eigens quantisierten Modellen, die nur intern verwendet werden, ist das Risiko gering, bei einer Weiterverbreitung an Kunden oder einer Integration in ein kommerzielles Produkt sollte die Lizenzprüfung aber Teil des Freigabeprozesses sein, genauso wie es bei jeder anderen Open-Source-Abhängigkeit üblich ist.

Sinnvoll ist außerdem, die Lizenzprüfung direkt in die eigene Projektdokumentation aufzunehmen, etwa als kurze Notiz neben dem Benchmark-Ergebnis: welches Basismodell, welche Lizenz, welches Quantisierungsverfahren, welcher Kalibrierungsdatensatz. Das klingt nach zusätzlichem Aufwand, zahlt sich aber aus, sobald ein Audit, eine Kundenanfrage oder ein internes Compliance-Review ansteht und jemand genau nachvollziehen muss, woher ein produktives Modell eigentlich stammt und unter welchen Bedingungen es weiterverwendet werden darf. Gerade bei schnell wechselnden Modellversionen, wie sie 2026 im Monatstakt erscheinen, geht dieser Überblick ohne feste Dokumentation schnell verloren.

Schritt 7: Ternäre und 2-Bit-Modelle verstehen

Am aggressiven Ende der Skala stehen ternäre Modelle, deren Gewichte nur noch die Werte -1, 0 und +1 annehmen können, sowie klassische 2-Bit-Quantisierung. Im September 2026 veröffentlichte der Anbieter Prism ML mehrere ternär quantisierte Varianten eines 27-Milliarden-Parameter-Basismodells unter dem Namen Bonsai 2, sowohl als GGUF- als auch als MLX-Build für Apple-Silicon-Systeme, mit einem empfohlenen Speicherbedarf ab etwa 8 GB. Das zeigt, wie stark sich die Grenze für “lokal betreibbar” in den letzten Monaten nach unten verschoben hat.

Wichtig für die eigene Praxis: Ternäre und 2-Bit-Modelle werden in aller Regel nicht einfach aus einem beliebigen Basismodell heruntergerechnet, so wie es Q4_K_M oder GPTQ-4Bit tun. Für stabile Ergebnisse bei derart niedriger Präzision muss das Modell meist von Grund auf mit quantisierungsbewusstem Training (Quantization-Aware Training) oder einem speziellen Nachtrainingsschritt vorbereitet werden. Wer ein bestehendes Modell einfach mit llama-quantize auf Q2_K herunterrechnet, erhält zwar eine lauffähige Datei, muss aber mit deutlich sichtbaren Qualitätseinbußen rechnen, besonders bei Faktenfragen und mehrstufigem Rechnen.

Der Trend zu aggressiverer Quantisierung hat einen klaren Treiber: Offene Modelle werden gleichzeitig größer und sparsamer in der Aktivierung. Im September und Oktober 2026 erschienen mit GLM-5.3-Flash (320 Milliarden Gesamtparameter, 18 Milliarden aktive Parameter) und Step 5 Preview (600 Milliarden Gesamtparameter, 27 Milliarden aktive Parameter) mehrere große Mixture-of-Experts-Modelle, die zwar pro Anfrage nur einen Teil ihrer Parameter aktivieren, insgesamt aber trotzdem erhebliche Speichermengen für alle Experten gleichzeitig vorhalten müssen. Genau solche Architekturen erhöhen den Druck auf effiziente Formate wie GGUF, GPTQ und ternäre Gewichte, weil ohne aggressive Kompression selbst leistungsfähige Workstations an ihre Grenzen stoßen.

Schritt 8: Modelle lokal laden und testen

Nach der Konvertierung folgt der erste Funktionstest. Für GGUF-Dateien eignet sich der eingebaute Server von llama.cpp, der eine OpenAI-kompatible Schnittstelle bereitstellt.

./llama.cpp/build/bin/llama-server \
  -m ./modell-q4_k_m.gguf \
  --port 8080 \
  --ctx-size 4096 \
  --n-gpu-layers 999

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"Erkläre GGUF in zwei Sätzen."}]}'

Für die GPTQ- und AWQ-Varianten übernimmt Transformers selbst das Laden, da GPTQModel die quantisierten Gewichte in einem Format speichert, das die Standard-from_pretrained-Methode direkt versteht.

from transformers import AutoModelForCausalLM, AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("./modell-gptq-4bit")
modell = AutoModelForCausalLM.from_pretrained(
    "./modell-gptq-4bit",
    device_map="auto"
)

eingabe = tokenizer("Erkläre GPTQ in zwei Sätzen.", return_tensors="pt").to("cuda")
ausgabe = modell.generate(**eingabe, max_new_tokens=100)
print(tokenizer.decode(ausgabe[0], skip_special_tokens=True))

Schritt 9: Varianten systematisch benchmarken

Ein Benchmark ohne feste Methodik liefert keine belastbaren Aussagen. Für den Vergleich der eigenen Quantisierungsvarianten hat sich folgendes Raster bewährt: dieselbe Hardware, dieselben Prompts, mehrere Wiederholungen pro Variante.

Messgröße	Wie gemessen	Warum relevant
VRAM-Bedarf	`nvidia-smi` im Leerlauf und während Generierung	Entscheidet, ob die Variante überhaupt auf die Zielhardware passt
Tokens pro Sekunde	Zeitstempel vor/nach Generierung, über 20 Läufe gemittelt	Bestimmt gefühlte Antwortgeschwindigkeit
Antwortqualität	Deutsche Zusammenfassung, Codeaufgabe, Faktenfrage, langer Kontext	Zeigt, wo die Quantisierung tatsächlich etwas kostet
Stabilität	30-50 aufeinanderfolgende Prompts ohne Neustart	Deckt Speicherlecks oder Abstürze auf

import time

def benchmark_lauf(modell, tokenizer, prompt, wiederholungen=20):
    zeiten = []
    for _ in range(wiederholungen):
        eingabe = tokenizer(prompt, return_tensors="pt").to("cuda")
        start = time.perf_counter()
        ausgabe = modell.generate(**eingabe, max_new_tokens=200)
        dauer = time.perf_counter() - start
        tokens = ausgabe.shape[1] - eingabe["input_ids"].shape[1]
        zeiten.append(tokens / dauer)
    return sum(zeiten) / len(zeiten)

print(f"Tokens/Sekunde: {benchmark_lauf(modell, tokenizer, 'Erkläre Quantisierung.'):.1f}")

In der Praxis zeigt sich bei einem 7B-Modell auf einer Mittelklasse-GPU meist folgendes Muster: Q4_K_M und das 4-Bit-GPTQ-Modell liegen bei der Antwortqualität nah beieinander, GPTQ ist aber bei identischer Hardware häufig etwas schneller, weil die Inferenz-Kernels stärker auf diesen Pfad optimiert sind. Q8_0 verhält sich bei Faktentreue praktisch wie das unquantisierte Modell, braucht dafür aber auch deutlich mehr Speicher.

Wichtig für belastbare Zahlen ist die statistische Streuung zwischen einzelnen Läufen. Eine einzelne Messung mit zwanzig Wiederholungen kann je nach Systemlast, Hintergrundprozessen und thermischem Verhalten der GPU um zehn bis fünfzehn Prozent schwanken. Wer die Ergebnisse in einem internen Bericht oder gegenüber Kollegen vertreten will, sollte den Benchmark an mindestens zwei unterschiedlichen Tageszeiten wiederholen und den Median statt des reinen Durchschnitts angeben, da einzelne Ausreißer nach oben den Durchschnitt stärker verzerren als den Median. Bei Produktionssystemen lohnt sich zusätzlich eine Lastmessung über mehrere Stunden, um zu sehen, ob die Geschwindigkeit bei Dauerbetrieb stabil bleibt oder ob thermisches Throttling der GPU die Werte nach ein bis zwei Stunden absinken lässt.

Schritt 10: Qualitätsverlust gezielt prüfen

Reine Geschwindigkeitsmessung reicht nicht aus. Für eine seriöse Einschätzung des Qualitätsverlusts bietet sich die Perplexity-Messung auf einem festen Textkorpus an: Je niedriger die Perplexity, desto besser sagt das Modell den nächsten Token im Testtext vorher.

import torch

def perplexity_messen(modell, tokenizer, text):
    eingabe = tokenizer(text, return_tensors="pt").to("cuda")
    with torch.no_grad():
        ausgabe = modell(**eingabe, labels=eingabe["input_ids"])
    return torch.exp(ausgabe.loss).item()

testtext = "Hier steht ein repräsentativer deutscher Testabsatz aus der Zieldomäne..."
print(f"Perplexity: {perplexity_messen(modell, tokenizer, testtext):.2f}")

Als Faustregel gilt: Ein Anstieg der Perplexity von weniger als 2-3 % gegenüber dem unquantisierten Modell ist im Alltag kaum wahrnehmbar. Steigt der Wert um mehr als 10 %, lohnt sich ein Blick auf die Kalibrierungsdaten oder eine weniger aggressive Bit-Breite.

Perplexity allein erfasst aber nicht jede Art von Qualitätsverlust. Für Anwendungsfälle mit Programmierung lohnt sich zusätzlich ein kleiner Satz an Codeaufgaben mit automatisch prüfbarem Ergebnis, etwa “schreibe eine Funktion, die eine Liste sortiert” mit anschließendem Testlauf des generierten Codes. Für Textzusammenfassungen hilft ein manueller Vergleich von drei bis fünf Beispielantworten zwischen unquantisiertem und quantisiertem Modell, bei dem eine Person aus dem Team bewertet, ob wichtige Informationen fehlen oder falsch wiedergegeben werden. Diese Form von menschlicher Stichprobenprüfung lässt sich nicht vollständig automatisieren, liefert aber oft aussagekräftigere Hinweise als eine reine Zahl, weil sie die tatsächliche Nutzungssituation abbildet.

Schritt 11: Modell-Merging als Ergänzung

Ein verwandtes, aber eigenständiges Thema ist Model-Merging: das Zusammenführen mehrerer feingetunter Varianten desselben Basismodells zu einem neuen Checkpoint, meist über gewichtete Mittelung der Parameter. Das lässt sich sinnvoll mit Quantisierung kombinieren, etwa nach dem Muster “zwei spezialisierte Modelle mergen, dann das Ergebnis auf 4 Bit quantisieren”. Für den Einstieg reicht es zu wissen: Merging passiert vor der Quantisierung, auf den vollen Gewichten, da Rundungsfehler aus bereits quantisierten Modellen sich beim Mergen addieren und die Qualität stärker leiden lassen als nötig.

Schritt 12: Deployment-Entscheidung treffen

Am Ende steht die Entscheidung, welche Variante produktiv läuft. Dafür hilft eine einfache Checkliste: Passt die Datei auf die Zielhardware mit Puffer für den Kontext? Liegt die Perplexity-Abweichung unter der eigenen Toleranzschwelle? Reicht die Geschwindigkeit für den Anwendungsfall, etwa Chat in Echtzeit versus Batch-Verarbeitung über Nacht? Wer alle drei Fragen mit Ja beantworten kann, hat die richtige Stufe gefunden, meist landet man für 8-16 GB VRAM bei Q4_K_M oder einem vergleichbaren 4-Bit-GPTQ-Modell.

Häufige Stolperfallen bei der Quantisierung

Falsche Kalibrierungsdaten: Wer mit generischen englischen Sätzen kalibriert, aber deutsche Fachtexte verarbeiten will, verschenkt Qualität an der falschen Stelle.
Zu kleine Group Size ohne Not: Group Size 32 statt 128 erhöht die Genauigkeit kaum messbar, aber der Overhead der Skalierungsfaktoren frisst einen Teil der Speicherersparnis wieder auf.
F16-Zwischendatei vorzeitig gelöscht: Ohne die F16-GGUF-Datei lässt sich keine zweite Quantisierungsstufe mehr ohne erneuten Download erzeugen.
Zu aggressive Bit-Breite ungetestet übernommen: Ein ungeprüfter Sprung direkt auf Q2_K oder 2-Bit-GPTQ kann bei mehrstufigen Rechenaufgaben zu deutlich mehr Fehlern führen als erwartet.
Veraltete Toolchain weiterverwendet: AutoGPTQ und AutoAWQ werden nicht mehr aktiv gepflegt, neue Modellarchitekturen funktionieren dort oft gar nicht mehr.
Kontextlänge beim Benchmark vergessen: Ein Test nur mit kurzen Prompts verdeckt, dass manche Quantisierungsvarianten bei langem Kontext stärker degradieren.
Keine Versionsfixierung: Ohne gepinnte Versionen von Transformers, GPTQModel und llama.cpp ändert sich das Verhalten zwischen zwei Durchläufen unbemerkt.
Imatrix-Datei auf unpassendem Text berechnet: Eine Importance Matrix, die auf reinem Quellcode berechnet wurde, bildet die Gewichtsverteilung für Fließtext-Aufgaben schlechter ab und umgekehrt.
Benchmark nur mit einem einzigen Prompt-Typ: Wer ausschließlich kurze Fragen testet, übersieht oft, dass manche Quantisierungsstufen gerade bei langen, mehrteiligen Anweisungen stärker nachlassen.

Output-Beispiele: So sieht ein gelungener Durchlauf aus

Eine erfolgreiche GGUF-Konvertierung meldet sich mit einer klaren Abschlusszeile, etwa in dieser Form:

[1/291] Converting tensor blk.0.attn_q.weight
...
main: quantize time = 48213.56 ms
main: total time = 48213.56 ms
Model successfully saved to modell-q4_k_m.gguf (4.1 GB)

Bei GPTQModel sieht eine saubere Quantisierung so aus:

Quantizing layer 28/28: 100%|██████████| 28/28 [06:42<00:00, 14.4s/it]
Saved quantized model to ./modell-gptq-4bit
Avg loss: 0.0183

Ein Avg-Loss-Wert deutlich über 0,1 ist ein Warnsignal: Entweder waren die Kalibrierungsdaten unpassend, oder die gewählte Bit-Breite ist für dieses Modell zu aggressiv.

Fehlerbehebung: Die häufigsten Probleme

"CUDA out of memory" während der Kalibrierung: Batch-Größe der Kalibrierungsdaten reduzieren oder device_map="auto" nutzen, damit Transformers Layer automatisch auf CPU auslagert.
GGUF-Datei lässt sich nicht laden, Fehler "unknown model architecture": llama.cpp-Version ist älter als das Konvertierungsskript, Repository neu klonen und Build wiederholen.
Quantisiertes Modell antwortet nur mit Wiederholungen: Meist ein Hinweis auf fehlerhafte Kalibrierungsdaten oder eine zu niedrige Bit-Breite für dieses Modell, eine Stufe höher gehen.
Konvertierung bricht mit "Tensor shape mismatch" ab: Das Modell nutzt eine Architektur, die die installierte GPTQModel- oder llama.cpp-Version noch nicht unterstützt, Changelog auf GitHub prüfen.
Geschwindigkeit bleibt trotz GPU sehr niedrig: --n-gpu-layers bei llama.cpp war nicht hoch genug gesetzt, Layer liefen weiter auf der CPU.
Tokenizer-Fehler nach der Konvertierung: Die tokenizer_config.json wurde beim Export nicht mitkopiert, Datei manuell aus dem Basismodell-Ordner ergänzen.
Festplatte läuft während der Konvertierung voll: F16-Zwischendatei und finale Quant-Datei belegen zeitweise gemeinsam Platz, vorab mindestens das Dreifache der Zieldateigröße freihalten.
AWQ-Quantisierung läuft extrem langsam: Ohne GPU-Beschleunigung dauert die Aktivierungsanalyse auf CPU ein Vielfaches länger, für produktive Workflows lohnt sich Cloud-GPU-Zeit.

Fortgeschrittene Tipps für den produktiven Einsatz

Wer quantisierte Modelle dauerhaft betreibt, sollte mehrere Stufen parallel vorhalten und per Konfigurationsschalter zwischen ihnen wechseln können, etwa Q4_K_M für die schnelle Chat-Antwort und Q8_0 für Anfragen, die höchste Faktentreue brauchen. Für Serving-Umgebungen mit mehreren gleichzeitigen Nutzern lohnt sich ein Blick auf kontinuierliches Batching, wie es Inferenz-Server für GPTQ- und AWQ-Modelle mitbringen, das erhöht den Gesamtdurchsatz deutlich gegenüber einzelnen sequenziellen Anfragen. Bei mehrsprachigen Anwendungsfällen mit viel Deutsch im Datensatz empfiehlt es sich außerdem, die Kalibrierung mit einem höheren Anteil deutscher Texte durchzuführen als es ein Standard-Kalibrierungsdatensatz vorsieht, da englisch-zentrierte Kalibrierung deutsche Spezialbegriffe systematisch schlechter abbildet.

Ein weiterer Punkt für die Praxis: Modellkarten auf Hugging Face vor dem produktiven Einsatz immer direkt prüfen, insbesondere Lizenzbedingungen und die exakten Evaluationsdatensätze, mit denen ein Anbieter seine Quantisierungsqualität angibt. Nicht jede Herstellerangabe zu Perplexity-Werten ist mit der eigenen Zieldomäne vergleichbar.

Für Teams, die regelmäßig neue Modellversionen quantisieren, zahlt sich ein kleines Automatisierungsskript aus, das die Schritte 3 bis 10 hintereinander ausführt und die Benchmark-Ergebnisse in eine CSV-Datei schreibt. So lässt sich bei jedem neuen Basismodell-Release innerhalb von wenigen Stunden feststellen, ob sich die gewohnte Quantisierungsstufe noch bewährt oder ob sich durch eine neue Architektur die Abwägung zwischen Geschwindigkeit und Qualität verschoben hat. Gerade bei den derzeit im Wochentakt erscheinenden offenen Modellen ist das kein Luxus, sondern spart in der Praxis viel manuelles Nachtesten.

Ein letzter Hinweis für Teams mit mehreren Zielplattformen: Wer dasselbe Modell sowohl auf Windows-Servern mit Nvidia-GPU als auch auf Mac-Laptops für Entwickler bereitstellen will, kommt um zwei getrennte Build-Pfade kaum herum. Die GGUF-Datei selbst ist plattformunabhängig, der llama.cpp-Build darunter aber nicht, für Apple Silicon lohnt sich ein separater Build mit aktivierter Metal-Unterstützung, für Windows-Server mit Nvidia-GPU der CUDA-Build aus Schritt 2. Beide Builds können parallel im selben Projektordner liegen, ohne sich gegenseitig zu stören, solange die Ausgabeverzeichnisse getrennt bleiben.

Sobald ein quantisiertes Modell produktiv läuft, lohnt sich einfaches Monitoring der Laufzeitwerte, nicht nur der einmaligen Benchmark-Zahlen. Tokens pro Sekunde, durchschnittliche Antwortlänge und die Rate fehlgeschlagener Anfragen lassen sich mit wenigen Zeilen Logging-Code erfassen und in ein bestehendes Monitoring-Dashboard einspeisen. Fällt die Geschwindigkeit über mehrere Tage spürbar ab, deutet das oft auf ein Treiber-Update, eine veränderte Serverauslastung durch andere Prozesse oder schlicht mehr gleichzeitige Nutzer hin als beim ursprünglichen Benchmark berücksichtigt. Ein einfacher Schwellenwert-Alarm, etwa bei einem Abfall von mehr als 20 % gegenüber dem Referenzwert aus Schritt 9, reicht in der Praxis meist aus, um frühzeitig nachzusteuern, bevor Nutzer sich über lange Wartezeiten beschweren.

Lokale Quantisierung versus Cloud-GPUs

Nicht jedes Team besitzt eine eigene GPU mit genug VRAM für die Kalibrierung größerer Modelle. Für ein 27B- oder 70B-Modell lohnt sich dann oft eine gemietete Cloud-GPU für wenige Stunden statt eigener Hardware, die danach ungenutzt im Schrank steht. Der Ablauf unterscheidet sich kaum vom lokalen Setup: Environment aufsetzen, Basismodell herunterladen, quantisieren, fertige Datei herunterladen und die Cloud-Instanz wieder beenden. Wichtig ist, die Rechnung nicht zu unterschätzen, denn der Download eines großen Basismodells auf die Cloud-Instanz zählt bei den meisten Anbietern bereits zur Laufzeit.

Für deutsche und europäische Teams kommt dabei häufig die Frage nach dem Serverstandort auf. Wer mit sensiblen Trainings- oder Kalibrierungsdaten arbeitet, etwa internen Support-Tickets oder Kundendaten, sollte vorab prüfen, ob der gewählte Cloud-Anbieter Instanzen innerhalb der EU anbietet und wie die Auftragsverarbeitung vertraglich geregelt ist. Für reine Kalibrierung mit synthetischen oder bereits anonymisierten Beispieltexten ist das Risiko gering, bei echten Produktionsdaten lohnt sich vorher ein kurzer Check mit der eigenen Datenschutzabteilung.

Ein Vorteil der lokalen Quantisierung bleibt trotzdem bestehen: Sobald die quantisierte Datei einmal erzeugt ist, läuft sie komplett offline. Für Anwendungsfälle mit hohen Anforderungen an Datenschutz, etwa in der Rechtsberatung oder im Gesundheitswesen, ist das oft der entscheidende Grund, überhaupt in eigene Hardware zu investieren, statt dauerhaft auf eine gehostete API zu setzen. Die einmaligen Kosten für GPU und Kalibrierungszeit amortisieren sich bei regelmäßiger Nutzung meist innerhalb weniger Monate gegenüber laufenden API-Gebühren.

Das komplette Projekt im Überblick

Zusammengefasst besteht das fertige Projekt aus folgenden Bausteinen: einem virtuellen Environment mit Transformers, GPTQModel und PyTorch, einem lokal gebauten llama.cpp für den GGUF-Pfad, dem heruntergeladenen Basismodell, mehreren GGUF-Quantisierungsstufen von Q8_0 bis Q2_K, einem GPTQ-4Bit- und einem AWQ-4Bit-Checkpoint sowie einem Benchmark-Skript, das VRAM, Tokens pro Sekunde und Perplexity für jede Variante erfasst. Diese Struktur lässt sich direkt als Vorlage für eigene Modelle und eigene Zieldomänen wiederverwenden, unabhängig davon, ob das Basismodell am Ende 7B oder 70B Parameter hat.

Der Ordner nach Abschluss aller zwölf Schritte sieht etwa so aus: ein basis-modell-Verzeichnis mit den Original-Safetensors, eine modell-f16.gguf als Zwischenstufe, mehrere fertige GGUF-Dateien nach Bit-Breite benannt, zwei Unterordner für die GPTQ- und AWQ-Checkpoints sowie ein benchmark-ergebnisse.csv mit allen gemessenen Werten. Wer dieses Setup unter Versionskontrolle stellen möchte, sollte die großen Modelldateien selbst über .gitignore ausschließen und nur die Skripte, die Konfigurationsdateien und die Benchmark-Ergebnisse einchecken, da ein einzelnes GGUF-Modell allein schon mehrere Gigabyte belegt und Git-Repositories dafür nicht ausgelegt sind.

Häufig gestellte Fragen zur LLM-Quantisierung

Verliert ein quantisiertes Modell immer merklich an Qualität?
Bei 8-Bit- und gut kalibrierter 4-Bit-Quantisierung ist der Unterschied in den meisten Alltagsaufgaben kaum wahrnehmbar. Spürbar wird der Verlust vor allem bei komplexem mehrstufigem Rechnen und sehr spezifischem Fachwissen, besonders unterhalb von 4 Bit. Ein eigener Benchmark auf realistischen Beispielen bleibt deshalb wichtiger als jede pauschale Prozentangabe.

Welches Format sollte ich als Einstieg wählen, GGUF oder GPTQ?
GGUF eignet sich besser für den schnellen lokalen Einstieg ohne GPU-Pflicht, GPTQ und AWQ spielen ihre Stärken eher in produktiven Serving-Umgebungen mit Nvidia-GPU aus, wo ihre optimierten Inferenz-Kernels Vorteile bei Durchsatz bringen. Für einen ersten Test reicht in der Regel eine einzelne Q4_K_M-GGUF-Datei völlig aus.

Kann ich ein Modell mehrfach quantisieren, etwa erst auf 8 Bit und dann auf 4 Bit?
Technisch möglich, aber nicht empfehlenswert. Jede Quantisierungsstufe führt Rundungsfehler ein, die sich bei mehrfacher Anwendung addieren. Besser ist es, immer vom unquantisierten Originalmodell auszugehen.

Brauche ich für GPTQ und AWQ unbedingt eine GPU?
Für die Kalibrierung selbst ist eine GPU stark empfehlenswert, da die Aktivierungsanalyse auf der CPU ein Vielfaches länger dauert. Für die reine Inferenz des fertigen Modells gibt es CPU-Pfade, die aber deutlich langsamer sind als GGUF auf llama.cpp. Wer nur gelegentlich quantisiert, kann die Kalibrierung auch auf einer gemieteten Cloud-GPU für wenige Stunden durchführen und danach lokal weiterarbeiten.

Sind AutoGPTQ und AutoAWQ für neue Projekte noch eine Option?
Nicht mehr empfehlenswert. Beide Projekte gelten laut aktuellen Übersichten als archiviert beziehungsweise nicht mehr aktiv weiterentwickelt, neue Modellarchitekturen werden dort oft nicht mehr unterstützt. GPTQModel ist der aktiv gepflegte Nachfolgepfad.

Wie groß muss mein Kalibrierungsdatensatz für GPTQ mindestens sein?
128 bis 256 repräsentative Prompts reichen in der Praxis meist aus. Wichtiger als die reine Menge ist, dass die Prompts die spätere Zieldomäne realistisch abbilden.

Was ist der Unterschied zwischen Quantisierung und Fine-Tuning mit LoRA?
Quantisierung reduziert die Speichergröße eines bestehenden Modells, ohne neues Wissen hinzuzufügen. Fine-Tuning mit LoRA passt das Modell dagegen gezielt an neue Aufgaben oder Daten an. Beide Techniken lassen sich kombinieren, etwa ein LoRA-feingetuntes Modell im Anschluss quantisieren.

Lohnt sich ternäre beziehungsweise 2-Bit-Quantisierung für den Heimgebrauch?
Nur, wenn das Modell von Herstellerseite explizit für diese Bit-Breite trainiert oder nachbereitet wurde, wie es Anbieter wie Prism ML im September 2026 mit ternären Varianten gezeigt haben. Ein beliebiges Standardmodell einfach auf 2 Bit herunterzurechnen, führt in der Regel zu deutlich sichtbaren Qualitätseinbußen.

LLM quantisieren: GGUF, GPTQ & AWQ in 12 Schritten [2026]