LLM-Quantisierung erklärt: FP8, NVFP4, AWQ, GPTQ und GGUF

Welches Modell in welchem Format auf Ihre Hardware passt? WZ-IT richtet lokale Sprachmodelle auf eigener Infrastruktur ein, wählt Modell und Quantisierung passend zu GPU, Kontextlänge und Nutzerzahl und prüft die Qualität mit Ihren eigenen Aufgaben. Managed GPU-Server ansehen · AI Cube ansehen · Termin vereinbaren

Ob ein Sprachmodell auf eine GPU passt und wie viele Anfragen es gleichzeitig bedient, entscheidet sich zu einem großen Teil an der Zahlenpräzision. Ein Modell mit 32 Milliarden Parametern belegt in BF16 rund 66 GB, als 4-Bit-Variante weniger als ein Drittel davon. Dazwischen liegen Formate mit unterschiedlichen Annahmen über Hardware und Software: FP8, NVFP4, MXFP4, AWQ, GPTQ und GGUF. Dieser Artikel ordnet die Formate ein, zeigt, welche GPU welches Format nativ beschleunigt, und erklärt, wie der KV-Cache in die Rechnung eingeht. Stand Oktober 2026.

Inhaltsverzeichnis

• Was Quantisierung bei LLMs bedeutet
• Die Formate im Überblick
• FP8: der Standard ab Ada und Hopper
• NVFP4 und MXFP4: 4 Bit als Gleitkommazahl
• AWQ und GPTQ: 4-Bit-Gewichte mit Kalibrierung
• GGUF: das Format von llama.cpp und Ollama
• Speicherbedarf an einem Beispiel
• KV-Cache quantisieren
• Welches Format für welche Hardware
• Qualitätsverlust messen statt schätzen

Was Quantisierung bei LLMs bedeutet

Sprachmodelle werden heute meist in BF16 veröffentlicht, also mit 16 Bit je Parameter. Quantisierung bildet diese Werte auf ein Format mit weniger Bits ab, typischerweise 8 oder 4 Bit. Damit die kleinen Zahlen den ursprünglichen Wertebereich abdecken, speichern alle Verfahren zusätzlich Skalierungsfaktoren, je Tensor, je Kanal oder je Block aus wenigen Werten.

Drei Dinge lassen sich quantisieren, und die Kurzschreibweise zeigt, was gemeint ist:

Der Nutzen hat zwei Seiten. Erstens sinkt der Speicherbedarf der Gewichte, das Modell passt auf kleinere oder weniger GPUs. Zweitens liest die GPU beim Erzeugen jedes Tokens alle aktiven Gewichte aus dem Speicher. Kleinere Datentypen verbrauchen weniger Speicherbandbreite, was laut vLLM-Dokumentation zu LLM Compressor gerade bei speichergebundenen Lasten oft höheren Durchsatz bedeutet. Ob zusätzlich die Rechenoperation in niedriger Präzision läuft (W8A8, W4A4), hängt davon ab, ob die GPU dafür Tensor Cores hat.

Wie sich Gewichte, KV-Cache und Overhead zum gesamten VRAM-Bedarf addieren, rechnet GPU und VRAM für LLMs dimensionieren durch.

Die Formate im Überblick

Quellen: vLLM, FP8 W8A8, vLLM, Quantization, NVIDIA, Introducing NVFP4, llama.cpp, quantize. Die GGUF-Werte gelten für Llama 3.1 8B laut llama.cpp-Messung; bei anderen Modellen weichen sie leicht ab.

Zu beachten: Die Übersichtstabelle der vLLM-Dokumentation endet in der Spalte Hopper (Stand Oktober 2026). Blackwell ist auf den Seiten der einzelnen Verfahren aufgeführt, etwa bei FP8 W8A8 und INT4 W4A16.

FP8: der Standard ab Ada und Hopper

FP8 halbiert den Speicherbedarf gegenüber BF16. Für Inferenz ist vor allem E4M3 verbreitet: 1 Vorzeichenbit, 4 Exponentenbits, 3 Mantissenbits, Werte bis ±448. Die Variante E5M2 hat mehr Wertebereich (bis ±57.344), aber weniger Genauigkeit (vLLM, FP8 W8A8).

FP8 ist für vLLM auf aktuellen NVIDIA-GPUs der naheliegende Ausgangspunkt, weil viele Hersteller offizielle FP8-Checkpoints veröffentlichen. Ein Beispiel ist Qwen3-8B-FP8 mit blockweiser FP8-Quantisierung in Blöcken von 128 × 128. vLLM erkennt solche Checkpoints anhand der quantization_config und lädt sie ohne weitere Parameter. Mit --quantization fp8_per_tensor oder fp8_per_block rechnet vLLM ein BF16-Modell außerdem beim Laden in FP8 um, ohne vorab quantisierten Checkpoint (vLLM, Online Quantization). Für produktive Systeme ist ein geprüfter Checkpoint, etwa aus llm-compressor, die nachvollziehbarere Variante.

NVFP4 und MXFP4: 4 Bit als Gleitkommazahl

NVFP4 ist NVIDIAs 4-Bit-Format für Blackwell. Jeder Wert ist eine 4-Bit-Gleitkommazahl (E2M1, Wertebereich etwa -6 bis +6). Je 16 Werte teilen sich einen Skalierungsfaktor in FP8 (E4M3), zusätzlich gibt es einen FP32-Faktor je Tensor. Mit den Skalen ergeben sich rund 4,5 Bit je Wert (NVIDIA, Introducing NVFP4).

Die kleineren Blöcke und die feinere FP8-Skala sollen den Rundungsfehler gegenüber MXFP4 senken. Native FP4-Rechenwerke bringen die Tensor Cores der fünften Generation mit, also Blackwell-GPUs wie die RTX PRO 4000 und RTX PRO 6000 Blackwell sowie der GB10-Chip.

vLLM lädt NVFP4-Checkpoints aus NVIDIA Model Optimizer und aus llm-compressor (vLLM, NVIDIA Model Optimizer). Beim Start wählt vLLM einen passenden GEMM-Kernel. Fehlt auf der GPU ein nativer FP4-Kernel, fällt vLLM auf W4A16 über Marlin zurück und protokolliert eine Warnung; der Speichervorteil bleibt, der Rechenvorteil entfällt. Welcher Kernel tatsächlich aktiv ist, steht im Startprotokoll und gehört bei jeder Inbetriebnahme geprüft.

MXFP4 ist vor allem durch gpt-oss bekannt geworden: Die MoE-Gewichte wurden laut Modellkarte bereits im Post-Training mit MXFP4 quantisiert, alle veröffentlichten Benchmarks beziehen sich auf diese Variante. gpt-oss-120b läuft damit auf einer einzelnen 80-GB-GPU, gpt-oss-20b mit 16 GB Speicher.

Zur Qualität gibt es Herstellerangaben, keine unabhängige Garantie:

Die Tendenz ist eindeutig: Große Modelle und MoE-Modelle vertragen 4 Bit besser als kleine dichte Modelle.

AWQ und GPTQ: 4-Bit-Gewichte mit Kalibrierung

AWQ und GPTQ sind keine Datentypen, sondern Verfahren, die Gewichte nach dem Training (Post-Training Quantization) meist in 4-Bit-Ganzzahlen umrechnen. Beide nutzen eine kleine Menge Kalibriertexte, um die Rundungsfehler gezielt klein zu halten. Die Aktivierungen bleiben in 16 Bit (W4A16).

Die AWQ-Autoren zeigen, dass schon der Schutz von rund 1 % der wichtigsten Gewichte den Quantisierungsfehler deutlich senkt. GPTQ quantisierte laut Paper ein Modell mit 175 Mrd. Parametern in etwa vier GPU-Stunden auf 3 bis 4 Bit.

In vLLM sind AWQ und GPTQ laut Hardware-Tabelle auf Turing, Ampere, Ada und Hopper unterstützt, GPTQ auch auf Volta. Die INT4-Seite nennt als Rechenplattform Ampere, Ada Lovelace, Hopper und Blackwell (vLLM, INT4 W4A16). Für GPUs ohne FP4-Rechenwerke sind AWQ und GPTQ damit die gängigen 4-Bit-Formate. Auf Blackwell ist NVFP4 eine Alternative, sofern ein Checkpoint verfügbar ist.

GGUF: das Format von llama.cpp und Ollama

GGUF ist das Dateiformat von llama.cpp. Es enthält Gewichte, Tokenizer und Metadaten in einer Datei und bringt eigene Quantisierungstypen mit. Gebräuchlich sind die K-Quants (etwa Q4_K_M, Q5_K_M, Q6_K) und die I-Quants für sehr niedrige Bitbreiten. Eine Importance Matrix (imatrix) aus Kalibriertexten senkt laut llama.cpp den Qualitätsverlust; gemessen wird er dort über Perplexity und KL-Divergenz.

Messwerte aus der llama.cpp-Dokumentation für Llama 3.1 8B:

Ollama nutzt GGUF als Modellformat. Laut Ollama-Dokumentation quantisiert Ollama GGUF-Modelle beim Import nicht; die Quantisierung erfolgt vorher mit llama-quantize. GGUF läuft auf CPU, NVIDIA- und AMD-GPUs sowie Apple Silicon und kann Schichten zwischen GPU und Arbeitsspeicher aufteilen. Das macht es zur ersten Wahl für Einzelplatz und kleine Installationen. vLLM unterstützt GGUF nur über ein separates Plugin und bezeichnet die Unterstützung als „highly experimental and under-optimized" (vLLM, GGUF). Für vLLM sind FP8, NVFP4, AWQ oder GPTQ die passenden Formate. Die Abwägung zwischen beiden Engines vertieft vLLM vs. Ollama.

Speicherbedarf an einem Beispiel

Qwen3-32B hat rund 32,8 Mrd. Parameter (Apache 2.0). Der Speicherbedarf der Gewichte ergibt sich aus Parameterzahl mal Bits je Gewicht geteilt durch 8:

Das sind Rechenwerte. Reale Dateien weichen ab, weil einzelne Schichten wie Embeddings oder die Ausgabeschicht oft in höherer Präzision bleiben.

Die Tabelle zeigt die Abstufung: In BF16 braucht das Modell eine Karte mit 96 GB, in FP8 passt es dort mit viel Raum für den KV-Cache. Eine 24-GB-Karte trägt es nur in 4 Bit, und dann bleiben für KV-Cache und Laufzeit nur wenige Gigabyte.

KV-Cache quantisieren

Neben den Gewichten belegt der KV-Cache Speicher: Für jedes Token im Kontext speichert jede Schicht Keys und Values. Der Bedarf je Token ist:

KV je Token = 2 × Schichten × KV-Köpfe × Kopfdimension × Bytes je Wert

Für Qwen3-32B (64 Schichten, 8 KV-Köpfe, Kopfdimension 128 laut config.json) ergibt das:

Der KV-Cache wächst mit Kontextlänge und Parallelität, nicht mit der Quantisierung der Gewichte. Ein 4-Bit-Modell mit langem Kontext und vielen Nutzern kann deshalb mehr Speicher für den Cache als für die Gewichte brauchen.

vLLM: --kv-cache-dtype fp8 (oder fp8_e4m3, fp8_e5m2) speichert den Cache in FP8. Ohne Kalibrierung setzt vLLM alle Skalierungsfaktoren auf 1,0; empfohlen sind kalibrierte Faktoren über llm-compressor. Mit dem Backend Flash Attention 3 werden zusätzlich die Queries in FP8 gerechnet (vLLM, Quantized KV Cache).

Ollama: OLLAMA_KV_CACHE_TYPE erlaubt f16 (Standard), q8_0 (rund halber Speicher, laut Dokumentation meist ohne spürbaren Qualitätsunterschied) und q4_0 (rund ein Viertel, kleiner bis mittlerer Präzisionsverlust, bei langem Kontext eher spürbar). Voraussetzung ist Flash Attention, die Einstellung gilt global für alle Modelle (Ollama FAQ).

Welches Format für welche Hardware

Die Formatwahl folgt aus Compute Capability, Speichergröße und Speicherbandbreite der GPU. Die Hardwaredaten stammen von NVIDIA (CUDA GPUs, RTX PRO 4000 Blackwell, RTX PRO 6000 Blackwell Max-Q, DGX Spark Hardware), Stand Oktober 2026:

Daraus ergeben sich typische Ausgangspunkte:

Die Grenzen sind fließend und hängen vom Modell ab. Welche Modelle auf 128 GB Unified Memory sinnvoll laufen, zeigt LLM-Modelle auf 128 GB Unified Memory, den Betrieb von gpt-oss-120b auf dem AI Cube beschreibt der Beitrag gpt-oss-120b auf dem AI Cube. Ein Praxisbeispiel für FP8 auf zwei 96-GB-Karten ist Qwen 122B mit vLLM auf zwei RTX PRO 6000. Wann ein Modell auf mehrere GPUs verteilt wird, behandelt Multi-GPU-Inferenz ohne NVLink.

Qualitätsverlust messen statt schätzen

Herstellerzahlen beziehen sich auf öffentliche Benchmarks wie MMLU, GPQA oder HumanEval. Sie zeigen die Richtung, aber nicht, wie sich ein quantisiertes Modell bei deutschen Vertragsklauseln, strukturierten Ausgaben oder Werkzeugaufrufen verhält. Gerade bei kleinen Modellen und bei 4 Bit lohnt ein eigener Vergleich.

Ein sauberer Vergleich hat vier Schritte:

1. Referenz festlegen. Das Modell in BF16 oder FP8 auf denselben Aufgaben laufen lassen.
2. Aufgaben aus dem Alltag wählen. 50 bis 200 echte Anfragen mit erwarteten Antworten, dazu Fälle mit JSON-Ausgabe oder Tool-Calls, wenn das System sie nutzt.
3. Gleich konfigurieren. Gleicher Prompt, gleiche Temperatur, gleiche Kontextlänge; nur das Format ändert sich.
4. Abweichungen auswerten. Nicht nur Treffer zählen, sondern auch Formatfehler, abgebrochene Antworten und Ausreißer prüfen.

Für standardisierte Benchmarks nutzt die vLLM-Dokumentation lm-evaluation-harness. llama.cpp bringt mit llama-perplexity ein Werkzeug für Perplexity und KL-Divergenz gegenüber dem Original mit. Bei RAG-Systemen gehört die Antwortqualität mit Quellen in die Messung, wie in RAG-Qualität messen beschrieben.

Außerdem zählt die Lizenz: Eine quantisierte Variante ist aus dem Originalmodell abgeleitet und unterliegt in der Regel weiterhin dessen Lizenzbedingungen. Mehr dazu in LLM-Lizenzen für kommerzielle Nutzung.

Was das für Ihr Projekt heißt

Quantisierung ist kein Feinschliff am Ende, sondern Teil der Hardwareentscheidung. Wer weiß, welches Modell in welchem Format laufen soll, kann die GPU-Größe, die Kontextlänge und die Zahl gleichzeitiger Nutzer belastbar planen. Wer zuerst die Hardware kauft, legt damit die möglichen Formate fest.

Wir richten Modelle mit vLLM oder Ollama ein, wählen das Format passend zur GPU, prüfen im Startprotokoll, welcher Kernel tatsächlich läuft, und vergleichen die quantisierte Variante mit Ihren eigenen Aufgaben gegen die Referenz. Grundlage sind Managed GPU-Server von WZ-IT mit NVIDIA RTX PRO 4000 Blackwell (24 GB GDDR7 ECC) oder RTX PRO 6000 Blackwell Max-Q (96 GB GDDR7 ECC) und der AI Cube mit 128 GB Unified Memory. Support, Beratung und Implementierung durch WZ-IT.

Die Modellwahl selbst behandelt Welches LLM selbst hosten?, den gesamten Speicherbedarf GPU und VRAM für LLMs dimensionieren. Den Unterschied zwischen Inferenz und Training erklärt Inferenz vs. Training, den Vergleich der Inferenz-Engines der Beitrag vLLM, Ollama und llama.cpp im Vergleich.