Quantisierung im Produktivbetrieb: INT4, FP8 und FP4 verständlich erklärt
Quantisierung ist der wichtigste Hebel, um große Sprachmodelle auf moderater Hardware zu betreiben: Modellgrößen sinken um bis zu 87,5 %, ohne dass die Qualität spürbar leidet. Dieses Tutorial erklärt INT4, FP8 und FP4, die gängigen Verfahren AWQ und GPTQ sowie KV-Cache-Quantisierung – praxisnah für On-Premise-Deployments.
Große Sprachmodelle sind beeindruckend – aber hungrig. Ein Modell mit 70 Milliarden Parametern belegt in voller Präzision schnell mehr als 140 GB Grafikspeicher und sprengt damit jedes übliche Hardware-Budget im Mittelstand. Genau hier setzt die Quantisierung an: Sie verkleinert Modelle so weit, dass sie auf bezahlbaren Servern laufen – und das ohne, dass die Antwortqualität spürbar nachlässt.
Quantisierung ist damit der entscheidende Hebel für jeden, der KI on-premise betreiben will: DSGVO-konform, kostenkontrolliert und mit voller Datenhoheit. In diesem Tutorial erklären wir die Formate INT8, INT4, FP8 und FP4, die Verfahren AWQ und GPTQ, die oft übersehene KV-Cache-Quantisierung sowie einen erprobten Praxis-Workflow. Am Ende wissen Sie, welches Format zu welcher Hardware passt – und wie Sie die Qualität absichern.
Was Quantisierung bedeutet
Ein Sprachmodell besteht aus Milliarden von Parametern – Zahlenwerten, die das gelernte Wissen kodieren. Standardmäßig werden diese Gewichte als 32-Bit- oder 16-Bit-Gleitkommazahlen gespeichert (siehe FP16/FP32). Quantisierung bildet diese hochpräzisen Werte auf eine niedrigere Präzision ab – etwa 8 oder 4 Bit pro Gewicht. Statt jede Zahl exakt abzubilden, wird ein gröberes Raster verwendet, das die wesentliche Information erhält.
Die Wirkung ist direkt proportional zur Bitbreite. Wer von FP32 (32 Bit) auf INT4 (4 Bit) wechselt, reduziert den Speicherbedarf pro Gewicht auf ein Achtel – das entspricht einer Reduktion der Modellgröße um bis zu 87,5 %. Das bringt drei konkrete Vorteile:
- Weniger VRAM-Bedarf: Modelle, die vorher zwei High-End-GPUs benötigten, passen plötzlich auf eine einzige Karte.
- Höherer Durchsatz: Kleinere Gewichte bedeuten weniger Speicherbandbreite pro Token – die Inferenz wird schneller.
- Niedrigere Kosten: Günstigere Hardware und mehr Anfragen pro Watt senken die Betriebskosten pro Anfrage deutlich.
Das Ziel ist immer dasselbe: maximale Kompression bei minimalem Qualitätsverlust. Die Kunst liegt darin, den richtigen Punkt auf dieser Kurve zu finden – und genau dabei helfen die unterschiedlichen Formate und Verfahren.
Faustregel: Jede Halbierung der Bitbreite halbiert grob den Speicherbedarf. FP16 belegt die Hälfte von FP32, INT8 ein Viertel, INT4 ein Achtel. Ein 8-Milliarden-Parameter-Modell schrumpft so von rund 32 GB (FP32) auf etwa 4–5 GB (INT4) – inklusive Overhead.
Die Formate: INT8, INT4, FP8 und FP4
Nicht jede Quantisierung ist gleich. Entscheidend ist der Unterschied zwischen Integer-Formaten (INT8, INT4) und niedrigpräzisen Gleitkommaformaten (FP8, FP4). Letztere behalten einen Exponenten und können dadurch einen größeren Wertebereich abbilden – ein Vorteil bei Ausreißern in den Aktivierungen.
INT8 – der sichere Einstieg
INT8 ist das robusteste Format mit dem geringsten Qualitätsrisiko. Ein nach INT8 quantisiertes Llama-3-8B läuft flüssig auf einer Consumer-GPU mit 8–12 GB VRAM. Für viele Mittelstandsanwendungen – Chat-Assistenten, Klassifikation, Textextraktion – ist INT8 die pragmatische Default-Wahl, weil der Unterschied zur vollen Präzision praktisch nicht messbar ist.
FP8 – die neue Referenz für Qualität
FP8 hat sich 2025/2026 als Sweet Spot etabliert. Messungen zeigen, dass FP8-quantisierte Modelle innerhalb von rund 0,4 Punkten zu FP16 auf anspruchsvollen Benchmarks wie MMLU-Pro und HumanEval+ liegen – ein praktisch vernachlässigbarer Abstand. FP8 kombiniert dabei die kompakte Größe von 8 Bit mit dem dynamischen Wertebereich eines Gleitkommaformats und ist daher robuster gegen Genauigkeitsverluste als INT8.
INT4 – maximale Kompression
INT4 holt das Maximum an Kompression heraus: bis zu 87,5 % kleiner als FP32. Der Preis ist ein etwas höheres Genauigkeitsrisiko, das aber mit modernen Verfahren wie AWQ stark gemildert wird. Für große Modelle (30B+), die andernfalls nicht auf die vorhandene Hardware passen würden, ist INT4 oft die einzige Möglichkeit, sie überhaupt lokal zu betreiben – und liefert dann erstaunlich gute Ergebnisse.
FP4 – das Format der Blackwell-Generation
FP4 ist das jüngste Format und entfaltet seine Stärke erst mit nativer Hardware-Unterstützung. Auf NVIDIAs Blackwell-Architektur verdoppelt FP4 die Tokens-per-Watt gegenüber FP8 – ein enormer Effizienzsprung für rechenintensive Deployments. Ohne passende Hardware bleibt FP4 jedoch Nischen-Terrain; auf älteren GPUs sind INT4 oder INT8 die bessere Wahl.
| Format | Größe vs. FP32 | Qualitätsrisiko | Empfohlen für |
|---|---|---|---|
| FP16 | −50 % | keines (Referenz) | Baseline, kleine Modelle |
| FP8 | −75 % | sehr gering (~0,4 Pkt.) | Qualitätskritische Produktion |
| INT8 | −75 % | sehr gering | Robuster Default, ältere GPUs |
| INT4 | −87,5 % | gering–mittel | Große Modelle, knapper VRAM |
| FP4 | −87,5 % | gering (mit HW-Support) | Blackwell, Effizienz-Maximum |
Verfahren: AWQ, GPTQ und mehr
Das Format beschreibt das Ziel – das Verfahren beschreibt den Weg dorthin. Wie ein Modell quantisiert wird, entscheidet maßgeblich über die Endqualität. Die beiden dominierenden Methoden 2026 sind GPTQ und AWQ, beide Vertreter der Post-Training-Quantisierung (PTQ): Das Modell wird nach dem Training quantisiert, ohne es neu trainieren zu müssen.
GPTQ – kalibriert und etabliert
GPTQ (Generative Pre-Trained Transformer Quantization) ist ein Post-Training-Verfahren, das einen kleinen Kalibrierungsdatensatz nutzt, um die Quantisierungsfehler schichtweise zu minimieren. Das Verfahren ist ausgereift, breit unterstützt und liefert besonders bei INT4 zuverlässige Ergebnisse. GPTQ ist die richtige Wahl, wenn ein etabliertes, gut getestetes Verfahren gefragt ist.
AWQ – aktivierungsbewusst und genau
AWQ (Activation-aware Weight Quantization) geht einen Schritt weiter: Es identifiziert die für die Modellqualität wichtigsten Gewichte anhand der Aktivierungsmuster und schützt diese gezielt vor zu grober Quantisierung. Das Ergebnis ist häufig eine spürbar bessere Genauigkeit bei gleicher Bitbreite – besonders bei aggressiver INT4-Kompression. AWQ ist deshalb 2026 oft das Mittel der Wahl, wenn man INT4-Größe mit nahezu FP16-Qualität verbinden will.
GGUF – das Format für lokale Inferenz
Neben den Verfahren spielt das Speicherformat eine Rolle. GGUF hat sich als De-facto-Standard für lokale Inferenz auf CPU und Consumer-GPU etabliert, vor allem im llama.cpp-Ökosystem. GGUF bündelt quantisierte Gewichte und Metadaten in einer einzigen, portablen Datei und bietet zahlreiche Quantisierungsstufen (z. B. Q4_K_M, Q5_K_M, Q8_0) für den Feinschliff zwischen Größe und Qualität.
Eine Alternative zur reinen Quantisierung – oft auch in Kombination – ist das Pruning, bei dem unwichtige Gewichte ganz entfernt werden. In der Praxis liefert Quantisierung jedoch meist das bessere Verhältnis aus Aufwand und Wirkung.
Praxisbeispiel: 70B-Modell auf einer einzelnen GPU
Ein Industrieunternehmen wollte ein 70-Milliarden-Parameter-Modell für die interne Dokumentenanalyse on-premise betreiben. In FP16 hätte das Modell rund 140 GB VRAM benötigt – also mindestens zwei A100-GPUs zu je 80 GB. Nach AWQ-Quantisierung auf INT4 schrumpfte der Bedarf auf etwa 40 GB. Das Modell läuft seitdem auf einer einzigen GPU. Die Hardware-Kosten sanken um mehr als die Hälfte, während ein internes Eval-Set nur einen marginalen Genauigkeitsabfall von unter einem Prozentpunkt zeigte.
KV-Cache-Quantisierung für Long-Context
Ein häufig unterschätzter Speicherfresser ist der KV-Cache. Während der Inferenz speichert das Modell für jeden bereits verarbeiteten Token sogenannte Key- und Value-Vektoren, um sie nicht erneut berechnen zu müssen. Das Problem: Dieser Cache wächst linear mit der Kontextlänge. Bei langen Dokumenten oder umfangreichen RAG-Kontexten kann der KV-Cache schnell mehr VRAM belegen als das Modell selbst.
Hier hilft die KV-Cache-Quantisierung. Statt Keys und Values in voller Präzision zu speichern, werden sie komprimiert abgelegt. Bemerkenswert: Eine Quantisierung auf etwa 3 Bit zeigt nur vernachlässigbare Qualitätseinbußen – der Cache verbraucht dann einen Bruchteil des ursprünglichen Speichers.
- Long-Context wird bezahlbar: Kontextfenster von 32k, 128k Token oder mehr werden auf moderater Hardware praktikabel.
- Ideal für RAG: Wer viele Dokumentenpassagen in den Kontext lädt, profitiert besonders – genau das ist der typische Engpass in Retrieval-Systemen.
- Kombinierbar: KV-Cache-Quantisierung lässt sich unabhängig von der Gewichtsquantisierung einsetzen und addiert deren Einsparungen.
Merksatz: Gewichtsquantisierung verkleinert das Modell, KV-Cache-Quantisierung verkleinert den Arbeitsspeicher pro Anfrage. Für Long-Context-Anwendungen brauchen Sie beides – sonst quillt der Cache über, selbst wenn das Modell schlank ist.
Qualität messen und absichern
Quantisierung ist kein Selbstläufer. Wie stark die Qualität tatsächlich leidet, hängt vom Modell, der Aufgabe und der Bitbreite ab. Verlassen Sie sich deshalb nie auf allgemeine Benchmark-Zahlen allein, sondern messen Sie auf Ihren eigenen Daten. Ein strukturierter Vor/Nach-Vergleich ist Pflicht:
- Domänenspezifisches Eval-Set aufbauen: Sammeln Sie repräsentative Aufgaben aus Ihrem tatsächlichen Einsatzgebiet – nicht generische Testfragen.
- Kennzahlen festlegen: Perplexity gibt einen schnellen Hinweis auf Sprachqualität, Task-Accuracy misst die konkrete Aufgabenleistung. Beide gemeinsam ergeben ein belastbares Bild.
- Edge-Cases gezielt prüfen: Quantisierung kann selten, aber gezielt Halluzinationen oder Formatfehler verstärken. Testen Sie schwierige und seltene Fälle explizit.
- Schwellen und Rollback definieren: Legen Sie vorab fest, welcher Qualitätsabfall akzeptabel ist – und halten Sie ein höherpräzises Format bereit, falls die Schwelle gerissen wird.
In der Praxis bewährt sich ein Stufenmodell: Beginnen Sie mit FP8 oder INT8 als sicherer Variante. Nur wenn der VRAM oder der Durchsatz es erzwingt, gehen Sie auf INT4 – und prüfen dann besonders gründlich. So vermeiden Sie böse Überraschungen im Produktivbetrieb.
Hardware-Matching
Welches Format Sie wählen können, hängt zuallererst von Ihrer GPU ab. Das VRAM-Budget bestimmt die maximal erreichbare Modellgröße, und die GPU-Architektur entscheidet, welche niedrigpräzisen Formate nativ beschleunigt werden.
- VRAM ist die harte Grenze: Modellgewichte plus KV-Cache plus Overhead müssen in den Speicher passen. Quantisierung erlaubt, ein deutlich größeres und damit fähigeres Modell auf derselben Karte zu betreiben.
- Blackwell für FP4: Die aktuelle NVIDIA-Generation bietet native FP4-Unterstützung und verdoppelt damit die Tokens-per-Watt gegenüber FP8 – relevant für hohe Lastszenarien.
- Ältere GPUs: Auf Ampere- oder Ada-Karten ohne FP4-Beschleunigung sind INT8 und INT4 die praktikabelsten Formate. FP8 wird ab Hopper sinnvoll nutzbar.
- Durchsatzgewinn senkt Kosten: Weniger Bits pro Gewicht bedeuten weniger Speicherbandbreite pro Token – mehr gleichzeitige Anfragen pro GPU und damit niedrigere Kosten pro Anfrage.
Die richtige Hardware-Auswahl ist ein zentraler Teil jedes On-Premise-Projekts. In unserem KI-Full-Stack-Providing dimensionieren wir GPU, Speicher und Modell so aufeinander ab, dass Sie weder über- noch unterdimensioniert fahren.
Praxis-Workflow On-Premise
So sieht ein bewährter Ablauf von der Modellauswahl bis zum produktiven Betrieb aus – konkret genug, um ihn direkt nachzuvollziehen:
Schritt 1: Modell und Zielformat wählen
Bestimmen Sie zunächst Ihr VRAM-Budget und leiten daraus Modellgröße und Format ab. Beispiel: Eine 24-GB-GPU trägt komfortabel ein Llama-3-8B in FP8/INT8 oder ein größeres 14B-Modell in INT4. Faustregel: Modellgröße in Milliarden Parametern mal Bytes pro Gewicht ergibt grob den Gewichtsspeicher.
Schritt 2: Quantisieren
Quantisieren Sie das Modell mit dem passenden Verfahren – AWQ für maximale Genauigkeit bei INT4, GPTQ als robuste Alternative. Vereinfacht sieht der Aufruf so aus:
# AWQ-Quantisierung (vereinfacht)
from awq import AutoAWQForCausalLM
model = AutoAWQForCausalLM.from_pretrained("meta-llama/Llama-3-8B")
model.quantize(tokenizer, quant_config={"w_bit": 4, "q_group_size": 128})
model.save_quantized("./llama3-8b-awq-int4")
Schritt 3: In die Serving-Engine laden
Laden Sie das quantisierte Modell in eine produktionsreife Serving-Engine wie vLLM oder SGLang. Diese Engines unterstützen quantisierte Formate nativ, bringen Funktionen wie Continuous Batching mit und ermöglichen die KV-Cache-Quantisierung per Konfigurationsflag.
# Start mit vLLM inkl. KV-Cache-Quantisierung
vllm serve ./llama3-8b-awq-int4 \
--quantization awq \
--kv-cache-dtype fp8
Schritt 4: Eval fahren
Lassen Sie Ihr domänenspezifisches Eval-Set gegen die Referenz (FP16) laufen und prüfen Sie die definierten Schwellen. Erst wenn die Qualität passt, geht es weiter.
Schritt 5: Produktiv ausrollen
Rollen Sie das Modell mit kontinuierlichem Monitoring von Latenz, Durchsatz und Qualität aus. Behalten Sie Stichprobenauswertungen bei, um Qualitätsdrift früh zu erkennen. Der laufende Betrieb gehört in geübte Hände – unsere KI-Administration übernimmt Monitoring, Updates und Skalierung.
Praxisbeispiel: Support-Assistent auf einer Single-GPU
Ein Maschinenbauer wollte einen internen Support-Assistenten betreiben, hatte aber nur eine GPU mit 24 GB VRAM zur Verfügung. In FP16 passte das gewünschte 14B-Modell nicht hinein. Die Lösung: AWQ-Quantisierung auf INT4 plus FP8-KV-Cache. So lief nicht nur das Modell, sondern es blieb genug Speicher für ein 32k-Kontextfenster, um ganze Wartungshandbücher als RAG-Kontext einzuspeisen. Die gemessene Antwortqualität lag auf dem internen Eval-Set nur einen Hauch unter der FP16-Referenz – bei einem Bruchteil der Hardware-Kosten.
Quantisierung ist damit weit mehr als ein technisches Detail: Sie ist der Schlüssel, der leistungsfähige KI überhaupt erst wirtschaftlich on-premise verfügbar macht. Mit dem richtigen Format, einem sauberen Eval und passender Hardware holen Sie maximale Leistung aus minimaler Infrastruktur.
Häufig gestellte Fragen zur Quantisierung
Verliert ein Modell durch Quantisierung an Qualität?
Kaum spürbar bei FP8 (innerhalb ~0,4 Punkten zu FP16) und meist akzeptabel bei INT4. Wichtig ist ein Vor/Nach-Vergleich auf Ihren eigenen Aufgaben, um Edge-Cases auszuschließen. Beginnen Sie im Zweifel mit FP8 oder INT8 und gehen Sie nur auf INT4, wenn der VRAM oder der Durchsatz es erzwingt.
Welches Format soll ich für On-Premise wählen?
Das hängt von der GPU ab: Blackwell-Karten profitieren von FP4, ältere GPUs nutzen INT8/INT4. Für lokale Inferenz ist GGUF weit verbreitet, kombiniert mit AWQ oder GPTQ. AWQ liefert bei INT4 meist die beste Genauigkeit, GPTQ ist die robuste, breit getestete Alternative.
Was bringt KV-Cache-Quantisierung?
Sie reduziert den VRAM-Bedarf bei langen Kontexten erheblich. Eine Quantisierung auf etwa 3 Bit zeigt nur vernachlässigbare Qualitätseinbußen und ist ideal für RAG und lange Dokumente. Da der KV-Cache linear mit der Kontextlänge wächst, ist diese Technik bei großen Kontextfenstern oft entscheidend – unabhängig von der Gewichtsquantisierung einsetzbar.
Wie stark schrumpft ein Modell durch Quantisierung?
Von FP32 auf INT4 sinkt die Modellgröße um bis zu 87,5 %. Das senkt den VRAM-Bedarf drastisch und erlaubt größere Modelle auf derselben Hardware. Ein 8-Milliarden-Parameter-Modell schrumpft so von rund 32 GB (FP32) auf etwa 4–5 GB (INT4) inklusive Overhead.
LLM effizient on-premise betreiben
Wir wählen Modell, Quantisierungsformat und Hardware passgenau aus – DSGVO-konform, kostenoptimiert und produktionsreif. Kostenlose Erstberatung, Eval inklusive.