Wenn ein Kunde die Anforderungen für den lokalen Betrieb eines 70B-Modells zeigt und ein einzelner Server mit zwei GPUs zur Verfügung steht, ist die erste Reaktion meistens dieselbe: „Das passt nicht rein." In FP16 stimmt das — ein solches Modell benötigt 140–168 GB VRAM, was keine gewöhnliche Konfiguration ist. In 4-Bit-Quantisierung sinkt dasselbe Modell auf 35–40 GB, was zwei mittelstarken Karten entspricht. Und der Qualitätsverlust? Bei der richtigen Methode ist er kleiner, als die meisten erwarten.
Quantisierung ist heute eine der wichtigsten praktischen Fertigkeiten beim Einsatz von LLMs auf eigener Hardware. Dieser Artikel erklärt, was bei der Quantisierung mit den Modellgewichten passiert, worin der Unterschied zwischen den Formaten GGUF, AWQ und GPTQ besteht, wie viel Qualität Sie auf den einzelnen Stufen realistisch verlieren — und wie sich das von Destillation unterscheidet, die häufig mit Quantisierung verwechselt wird.
Was Quantisierung mit den Gewichten macht
Moderne LLMs werden im Format BF16 oder FP16 trainiert — jeder Parameter belegt 16 Bit. Ein Modell mit 7 Milliarden Parametern benötigt damit rund 14 GB allein für die Gewichte (KV-Cache und Aktivierungen kommen noch hinzu).
Quantisierung repräsentiert dieselben Gewichte in geringerer numerischer Präzision. Statt eines 16-Bit-Floats verwenden Sie einen 8-Bit- oder 4-Bit-Integer. Die Formel ist direkt: VRAM (GB) ≈ (Parameteranzahl in Milliarden × Bits) / 8. Bei 4-Bit-Quantisierung eines 7B-Modells erhalten Sie 5–7 GB — das passt auf eine handelsübliche Workstation.
Der Preis dieser Einsparung ist Informationsverlust. Die numerische Präzision sinkt, einige feine Unterschiede zwischen Gewichten werden auf denselben darstellbaren Wert „geglättet". Das Ergebnis ist ein leichter Qualitätsrückgang bei den Ausgaben — die Frage ist, wie stark er ausfällt.
Wichtig ist zu verstehen, was Quantisierung nicht ist: keine Destillation. Quantisierung bewahrt die Architektur und die Parameteranzahl des ursprünglichen Modells und ändert lediglich das numerische Format der Gewichte. Destillation hingegen überträgt Wissen in ein kleineres Modell mit anderer Architektur — es geht um Wissenstransfer, nicht um Komprimierung. Mehr zu Destillation im Artikel Modelldestillation: wie man aus einem großen Modell ein kleines, schnelles macht.
GGUF — Format für CPU und plattformübergreifende Deployments
GGUF ist ein Binärformat, das für llama.cpp entwickelt wurde und heute auch nativ in Ollama unterstützt wird. Seine Kerneigenschaft: Das Modell kann rein auf der CPU laufen oder in einer hybriden CPU+GPU-Kombination, bei der ein Teil der Schichten auf der GPU läuft und der Rest auf der CPU unter Nutzung des RAM.
Für Unternehmens-Deployments bedeutet das einen praktischen Vorteil: Ein Entwickler kann ein 13B-Modell auf einer Workstation ohne dedizierte GPU betreiben oder auf einem Server mit weniger VRAM, als das Modell in FP16 erfordern würde.
Quantisierungsstufen in GGUF
Die Bezeichnung folgt dem Schema Q<Bits>_<Variante>. Die wichtigsten Stufen:
- Q8_0 — 8-Bit-Quantisierung, geringstem Qualitätsverlust (~1–2 % gegenüber FP16). Empfohlen, wenn ausreichend VRAM vorhanden ist und maximale Präzision gewünscht wird.
- Q4_K_M — 4-Bit, „medium"-Variante mit adaptiver Quantisierung für empfindliche Schichten. Erhält ~92–95 % der FP16-Qualität. Standard-Sweet-Spot für die meisten Use-Cases.
- Q4_K_S — 4-Bit, „small"-Variante, etwas kleiner als K_M bei ähnlicher Qualität.
- Q3_K_M — 3-Bit, deutlich kleinerer Footprint, spürbare Degradation bei komplexem Schlussfolgern.
- Q2_K — 2-Bit, erhebliche Degradation. Nur bei extrem eingeschränkter Hardware und unkritischen Aufgaben verwendbar.
Der Buchstabe K in der Bezeichnung steht für „k-quants" — eine ausgefeiltere Methode, die auf quantisierungsfehlerempfindliche Schichten (typischerweise Embedding- und Ausgabeschichten) höhere Präzision anwendet und weniger kritische Teile aggressiver komprimiert. Das Ergebnis ist ein besseres Qualitäts-zu-Größe-Verhältnis gegenüber einfacher uniformer Quantisierung.
AWQ — kalibrierte Quantisierung für den GPU-Stack
AWQ (Activation-aware Weight Quantization) ist eine Methode, die bei der Quantisierung die Statistik der Aktivierungen berücksichtigt — also die Eingabewerte, die das Modell in der Praxis zu sehen bekommt. Anhand dieser Statistik identifiziert sie „wichtige" Gewichte und bewahrt ihnen höhere Präzision, während der Rest aggressiver quantisiert wird.
Das Ergebnis: Das AWQ-4-Bit-Format erhält ~93–96 % der FP16-Qualität — etwas besser als GPTQ bei gleicher Größe. Der Unterschied ist besonders bei längeren Textgenerierungen und Code spürbar, wo die Kohärenz bei unkalibrierter Quantisierung schneller degeneriert.
AWQ erfordert eine GPU bei der Inferenz — es ist nicht für reine CPU-Umgebungen gedacht. Nativ unterstützt wird es von vLLM und TGI. Für produktive NVIDIA-Deployments ist es heute eines der bevorzugten Formate.
GPTQ — maximaler Throughput auf NVIDIA-GPUs
GPTQ (Generative Pre-trained Transformer Quantization) ist eine ältere und etablierte Methode. Sie nutzt zweite Ableitungen (Hessian), um den Quantisierungsfehler bei einer gegebenen Batch-Kalibrierung zu minimieren. In der Praxis liegt GPTQ 4-Bit bei der Qualitätserhaltung leicht hinter AWQ (~90–93 % gegenüber FP16), bietet aber maximalen Throughput auf NVIDIA-GPUs durch den Einsatz von fusionierten Kernels.
Für Szenarien, in denen die höchstmögliche Token-Ausgabe pro Sekunde Priorität hat (beispielsweise beim Serving für mehrere gleichzeitige Nutzer), liefert GPTQ in Kombination mit vLLM starke Ergebnisse. Wie AWQ erfordert es eine GPU — CPU-Inferenz wird nicht nativ unterstützt.
Formatvergleich — wann was verwenden
- GGUF — wenn plattformübergreifendes Deployment benötigt wird, CPU-Inferenz oder hybrider CPU+GPU-Modus, oder wenn das Deployment über
Ollamaauf Developer-Workstations erfolgt - AWQ — reiner GPU-Stack (NVIDIA), produktives Deployment über
vLLModerTGI, Priorität liegt auf Ausgabekohärenz - GPTQ — reiner GPU-Stack (NVIDIA), produktives Deployment über
vLLM, Priorität liegt auf maximalem Throughput beim Multi-User-Serving
Diese Formate sind weder austauschbar noch untereinander kompatibel — ein in GPTQ quantisiertes Modell lässt sich nicht direkt in llama.cpp laden und umgekehrt. Vor der Formatwahl muss klar sein, welchen Serving-Stack und welche Hardware Sie einsetzen möchten.
Realer Qualitätsverlust — was die Zahlen sagen
Die Frage, die Kunden am häufigsten stellen: „Wie viel Qualität verlieren wir?"
Die Antwort hängt von der Quantisierungsstufe und der Art der Aufgabe ab. Messungen über verschiedene Modelle (Qwen, DeepSeek, Mistral, Llama) zeigen ein konsistentes Muster:
- Q8_0 / 8-Bit: Perplexitätsunterschied unter 1–2 % gegenüber FP16. Im normalen Gespräch praktisch nicht erkennbar.
- Q4_K_M / AWQ 4-Bit: Perplexitätsunterschied typischerweise unter 5–8 % gegenüber BF16. Bei den meisten Aufgaben — Informationsextraktion, Zusammenfassung, Klassifikation — ist der Unterschied mit bloßem Auge nicht sichtbar. Bei komplexem mehrstufigem Schlussfolgern (Mathematik, Code, lange Schrittfolgen) kann ein leichter Rückgang beobachtbar sein.
- Q3 und darunter: Die Degradation ist spürbar. Das Modell beginnt, weniger kohärente Ausgaben zu produzieren, besonders bei langen Generierungen oder bei Aufgaben, bei denen Präzision wichtig ist.
- Q2: Erhebliche Degradation. Geeignet nur bei extremen Hardware-Einschränkungen und unkritischen Aufgaben.
Eine wichtige Nuance: Der Qualitätsverlust ist nicht gleichmäßig verteilt. Modelle mit mehr Parametern tolerieren aggressivere Quantisierung besser — ein 70B-Modell in Q4_K_M bewahrt in der Regel mehr Fähigkeiten als ein 7B-Modell in derselben Konfiguration. Bei kleinen Modellen (7B und weniger) ist der Unterschied zwischen Q8 und Q4 deutlicher sichtbar.
Zweite Nuance: Benchmarks messen Durchschnittswerte. Für einen spezifischen domänenspezifischen Use-Case (etwa die Analyse technischer Dokumentation) ist es sinnvoll, einen eigenen Vergleich FP16 vs. Q4 an einer Stichprobe realer Eingaben durchzuführen — einige Dutzend Beispiele reichen typischerweise für eine orientierende Einschätzung.
VRAM-Einsparung in der Praxis
Konkrete Zahlen für die häufigsten Modellgrößen:
- 7–9B-Modell: FP16 ~16–19 GB → Q8_0 ~8–13 GB → Q4_K_M ~5–7 GB
- 13B-Modell: FP16 ~26 GB → Q8_0 ~14 GB → Q4_K_M ~8 GB
- 27–34B-Modell: FP16 ~54–68 GB → Q8_0 ~30–34 GB → Q4_K_M ~17–20 GB
- 70B-Modell: FP16 ~140–168 GB → Q8_0 ~70–75 GB → Q4_K_M ~35–40 GB
Zu diesen Zahlen kommt der KV-Cache hinzu, der mit der Kontextlänge und der Anzahl gleichzeitiger Anfragen wächst. Ein 70B-Modell kann bei langem Kontext zusätzlich 20–40 GB für den KV-Cache bei mehreren parallelen Konversationen verbrauchen. Bei der Infrastrukturplanung sollten Sie daher nicht nur die Gewichte berücksichtigen — der KV-Cache ist eine ebenso wichtige Variable. Mehr dazu im Artikel Welche GPU für LLM-Inferenz.
Quantisierung und Serving-Stack — was vLLM und Ollama dazu wissen
Ollama ist ein hervorragendes Tool für Developer-Deployments — ein GGUF-Modell laden Sie mit einem einzigen Befehl herunter, es läuft lokal ohne Konfiguration. Unter der Haube steckt llama.cpp. Die entscheidende Einschränkung: Ollama ist kein produktiver Serving-Framework. Bei mehreren gleichzeitigen Nutzern kann der Throughput deutlich unter dem von vLLM liegen — unabhängig von der Quantisierung.
vLLM mit AWQ- oder GPTQ-Modellen ist für produktive Umgebungen mit mehreren gleichzeitigen Anfragen ausgelegt. Es nutzt PagedAttention für effizientes KV-Cache-Management und Continuous Batching — der resultierende Throughput kann bei mehreren gleichzeitigen Nutzern deutlich höher sein als bei Ollama. Der Preis ist ein komplexeres Setup und die Anforderung an eine GPU.
Für Unternehmens-Deployments ist die typische Vorgehensweise: Entwickler und Tester arbeiten mit GGUF-Modellen über Ollama, der produktive Inference-Server läuft auf vLLM mit AWQ oder GPTQ. Beide Ansätze koexistieren — es ist kein Entweder-oder. Einen detaillierten Vergleich dieser Serving-Tools finden Sie im Artikel vLLM vs. SGLang vs. Ollama.
Quantisierung vs. Destillation — ein wichtiger Unterschied
Diese beiden Begriffe werden in der Praxis häufig verwechselt, aber es handelt sich um grundlegend unterschiedliche Techniken.
Quantisierung bewahrt die ursprüngliche Modellarchitektur — Sie ändern lediglich das numerische Format der Gewichte. Der Prozess ist schnell, erfordert kein Training, und bestehende Quantisierungstools schaffen ein 70B-Modell in wenigen Stunden auf einem handelsüblichen Server. Informationsverlust entsteht durch geringere numerische Präzision.
Destillation erzeugt ein neues, kleineres Modell durch Training an den Ausgaben eines größeren (Teacher-)Modells. Das ist ein vollwertiger Trainingsprozess — er erfordert Daten, Rechenzeit und Hyperparameter-Tuning. Das Ergebnis ist ein Modell mit weniger Parametern und anderer Architektur, das „gelernt" hat, den Teacher nachzuahmen. Der Verlust betrifft die Kapazität — ein kleineres Modell hat schlicht nicht genug Parameter für manche komplexen Aufgaben.
In der Praxis ergänzen sich beide Ansätze: Ein destilliertes Modell lässt sich anschließend quantisieren. Beispielsweise kann ein durch Destillation aus einem Frontier-Modell entstandenes kleines Modell als GGUF Q4 für Edge-Deployments verteilt werden.
Wie man die Quantisierung in einem Projekt auswählt
Einige praktische Empfehlungen aus Deployments, die wir begleitet haben:
- 1.Starten Sie mit Q4_K_M — für die meisten Unternehmens-Use-Cases (Extraktion, Klassifikation, Q&A über Dokumente) bietet Q4_K_M ausreichende Qualität und einen vernünftigen VRAM-Footprint
- 2.Validieren Sie an eigenen Daten — wenn die Anwendung spezifische Anforderungen hat (z. B. präzise Extraktion numerischer Werte aus technischen Berichten), vergleichen Sie FP16 und Q4 an einer Stichprobe von 50–100 realen Eingaben, bevor Sie die finale Entscheidung treffen
- 3.Unterschätzen Sie den KV-Cache nicht — rechnen Sie bei der Hardware-Planung den KV-Cache über die Gewichtsgröße hinaus ein, besonders wenn Sie lange Kontexte planen
- 4.Berücksichtigen Sie den Serving-Stack — wenn Sie auf vLLM setzen, ist AWQ eine gute Wahl; bei Ollama oder plattformübergreifend GGUF; wenn Sie Throughput auf NVIDIA priorisieren, GPTQ
- 5.Q2 lieber nicht — die Degradation ist erheblich; besser ein kleineres Modell in Q4 als ein größeres Modell in Q2
Häufige Fragen
Kann ich ein beliebiges Modell selbst quantisieren?
Ja, Tools wie llama.cpp (für GGUF), AutoAWQ und AutoGPTQ sind Open-Source und frei verfügbar. Für gängige Größen (7–34B) schafft ein handelsüblicher Server die Quantisierung in wenigen Stunden. Für 70B und größere Modelle benötigen Sie deutlich mehr RAM (Quantisierung erfolgt in FP16 vor der Konvertierung). In der Praxis ist es für die meisten Teams einfacher, auf vorquantisierte Modelle von Hugging Face zurückzugreifen — die Qualität ist geprüft, und Sie sparen Zeit.
Ist der Unterschied zwischen Q4_K_M und Q4_K_S spürbar?
In der täglichen Praxis minimal. Q4_K_S ist eine etwas kleinere Datei bei sehr ähnlicher Qualität. Q4_K_M ist die konservativere Wahl, die in den empfindlichen Schichten etwas mehr Präzision bewahrt. Für die meisten Use-Cases empfehlen wir Q4_K_M als Ausgangspunkt.
Quantisierung und DSGVO — gibt es etwas zu bedenken?
Nicht direkt — Quantisierung ändert nicht das Verhalten des Modells bei der Datenverarbeitung, sondern nur seinen VRAM-Footprint und seine Geschwindigkeit. DSGVO-Implikationen hängen davon ab, *wo* das Modell läuft und *wer* Zugriff auf die Daten hat. Ein On-Prem-Deployment eines quantisierten Modells kann Ihnen in Bezug auf Datenlokation helfen (Daten verlassen die eigene Infrastruktur nicht), aber Compliance erfordert weit mehr — Audit-Logs, Zugriffskontrollen, einen dokumentierten DPA-Prozess. Mehr dazu im Artikel On-Prem-LLM für regulierte Branchen.
Kann ich ein quantisiertes Modell weiter fine-tunen?
Direktes Fine-Tuning eines quantisierten Modells (z. B. GGUF Q4) ist kein Standardverfahren — die meisten Fine-Tuning-Frameworks arbeiten mit FP16- oder BF16-Gewichten. QLoRA ist die Ausnahme: Es ermöglicht Training mit 4-Bit-quantisierten Basisgewichten, wobei die LoRA-Adapter in höherer Präzision trainiert werden. Details dazu im Artikel LoRA vs. QLoRA vs. Full Fine-Tuning.
Was ist der Unterschied zwischen NVFP4 und Standard-4-Bit-Quantisierung?
NVFP4 ist ein hardware-natives Format, das spezifisch für die neuesten NVIDIA-GPUs mit Blackwell-Architektur ist. Im Gegensatz zu softwarebasierten 4-Bit-Methoden (GPTQ, AWQ, GGUF Q4) wird NVFP4 direkt in den Tensor-Cores des Chips beschleunigt. Das Ergebnis sind höhere Throughputs gegenüber generischen 4-Bit-Formaten auf derselben Hardware. Wenn Sie keine Blackwell-GPU besitzen, ist dieses Format nicht relevant für Sie — Standard-AWQ oder GPTQ sind die richtige Wahl.
*Die Wahl des richtigen Quantisierungsformats und Serving-Stacks ist eine Entscheidung, die Kosten und Leistung des produktiven Deployments erheblich beeinflusst. Bei MP Industrial Solutions begleiten wir Unternehmen vom ersten Experiment mit einem lokalen LLM bis zur Produktionsinfrastruktur — einschließlich Hardware-Bewertung, Modellauswahl und Formatwahl für den konkreten Use-Case. Wenn Sie ein On-Prem-LLM-Deployment in Betracht ziehen, sprechen Sie uns gerne für ein erstes Beratungsgespräch an.*