Was ist Quantisierung? Modell-Gewichte komprimieren ohne Qualitätsverlust

Was ist Quantisierung?

Quantisierung ist eine Technik, mit der die Gewichte eines neuronalen Netzes mit weniger Bits pro Zahl gespeichert werden. Ein typisches grosses Sprachmodell wird im Training mit FP32 (32-Bit-Floats) oder FP16/BF16 (16-Bit-Floats) berechnet. Quantisierung wandelt diese Gewichte nach dem Training in kleinere Datentypen um: INT8 (8 Bit), INT4 (4 Bit), oder gemischte Schemata wie Q4_K_M, die Teile des Modells mit unterschiedlichen Bittiefen speichern.

Die Idee: ein Sprachmodell ist robust gegen kleine Störungen seiner Gewichte. Eine Gewichts-Zahl, die im Training als 0.347291 berechnet wurde, liefert auch als 0.34 oder als 0.3 noch ein fast identisches Ergebnis. Wenn man also die Präzision systematisch reduziert, schrumpft das Modell – bei kleinem Qualitätsverlust.

Mai 2026 ist Quantisierung Standard für Inference, nicht mehr Spezial-Trick. Llama 3.1 70B in FP16 belegt 140 GB Speicher (70 Mrd. Parameter × 2 Byte). In Q4_K_M sind es 42 GB – läuft auf einer einzigen A100-80GB-GPU statt auf einem Cluster. Auf Consumer-Hardware: Llama-3.1-8B in Q4_K_M ist 4-5 GB gross, läuft auf einem M2-MacBook mit 16 GB RAM problemlos. Llama-3.1-70B in Q4_K_M ist mit 2x RTX 4090 (jeweils 24 GB) oder einem Mac Studio mit 64 GB+ RAM betreibbar.

Die wichtigsten Quantisierungs-Schemata Mai 2026: GGUF (das Format von llama.cpp und Ollama, sehr breit unterstützt, mit verschiedenen Q-Stufen Q2_K bis Q8_0), AWQ (Activation-aware Weight Quantization, Lin et al. 2023, gut für vLLM-Inference), GPTQ (Frantar et al. 2022, älter, weiterhin in vLLM und text-generation-inference verwendet), BitsAndBytes (NF4 für Training, INT8 für Inference, gut integriert in Hugging Face Transformers).

Warum es jetzt zählt

Quantisierung löst das Hardware-Problem für self-hosted Modelle. Drei konkrete Effekte.

Erstens: Self-Hosting wird bezahlbar. Ohne Quantisierung braucht ein 70-Milliarden-Parameter-Modell mehrere A100/H100-GPUs – Investition CHF 100000+. Mit Q4_K_M reicht eine A100 80GB oder zwei Consumer-GPUs (2x RTX 4090, total CHF 4000-5000). Für ein KMU, das Mandanten-Daten ausschliesslich on-prem verarbeiten muss (Berufsgeheimnis StGB 321, revDSG-Sensitivität, oder reiner CH-Hosting-Wunsch), ist Quantisierung der Hebel, der ein eigenes Modell ökonomisch macht.

Zweitens: Cloud-Inference wird günstiger. Auch Cloud-Anbieter setzen Quantisierung ein. Together.ai, Replicate, Groq und andere bieten Mai 2026 Llama-3.1-70B in Q4-Variante zu CHF 0.0005-0.002 pro 1000 Tokens – das ist 5-10x billiger als die FP16-Variante. Für Anwendungen, bei denen leichte Qualitäts-Einbusse akzeptabel ist (Klassifikation, Triage, Routine-Antworten), ist quantisiertes Cloud-Inference eine konkrete Kosten-Optimierung.

Drittens: Edge-Fähigkeit. Quantisierte Modelle laufen auf Mobilgeräten und in Embedded-Setups. Mai 2026 ist Llama-3.2-3B in Q4 auf einem iPhone 15 Pro oder einem aktuellen Android-Flaggschiff lauffähig (15-30 Tokens/Sekunde Generierung). Das ermöglicht offline-AI in Apps, Daten-souveräne Mobile-Lösungen, oder lokale Vor-Verarbeitung vor einer Cloud-Anfrage.

Qualitäts-Trade-off ist klein, aber nicht null. Standard-Benchmarks Mai 2026 zeigen: Q8_0 verliert unter 0.5% Genauigkeit vs FP16. Q4_K_M verliert 1-2%. Q4_0 (älteres einfaches 4-Bit-Schema) verliert 3-5%. Q3_K_M verliert 5-10% und ist nur für sehr restriktive Hardware sinnvoll. Q2_K ist meist zu stark quantisiert – Modell-Qualität sinkt deutlich.

Wichtige Unterscheidung: Inference-Quantisierung (das hier beschriebene) ist post-training und verändert das Original-Modell nicht. Training-Quantisierung (QLoRA, NF4-Adapter) ist eine andere Disziplin und betrifft das Fine-Tuning (siehe was-ist-fine-tuning-vs-rag).

Technik im Detail

Quantisierung folgt einem einfachen Grundprinzip mit verschiedenen Verfeinerungen.

Grundprinzip – Linear Quantization. Jeder Gewichtsblock wird in einen Bereich [min, max] gemappt. Der Bereich wird durch 2^bits gleich grosse Stufen geteilt. Jedes Gewicht wird zur nächsten Stufe gerundet. Beim Inference wird die Rundung rückgängig gemacht (dequantize), die Multiplikation erfolgt in hoher Präzision. Das funktioniert, weil benachbarte Gewichts-Werte ähnliche Effekte produzieren – die kleinen Rundungsfehler heben sich teils auf.

Block-weise Quantisierung. Statt ein Min/Max für das ganze Modell zu nehmen, wird pro Block (z.B. 32 oder 64 Gewichte) ein eigenes Min/Max gespeichert. Das reduziert Quantisierungs-Fehler bei Ausreissern, kostet aber etwas Speicher für die Block-Skalen. Q4_K_M nutzt das.

GGUF Q-Levels. Q2_K (2 Bit, aggressivst, Qualitätsverlust 10%+), Q3_K_S/M/L (3 Bit, 5-10% Verlust), Q4_0/Q4_1 (4 Bit, alt, 3-5% Verlust), Q4_K_S/M (4 Bit mit K-Blocks, 1-2% Verlust – der Sweet-Spot), Q5_K_M (5 Bit, < 1% Verlust), Q6_K (6 Bit, < 0.5% Verlust), Q8_0 (8 Bit, < 0.3% Verlust). Faustregel Mai 2026: Q4_K_M ist die richtige Antwort für 80% der Fälle. Q5_K_M wenn ein Tick mehr Qualität wichtig ist. Q8_0 nur bei sehr hohen Qualitäts-Anforderungen.

AWQ (Lin et al. 2023). Activation-aware: betrachtet, welche Gewichte tatsächlich wichtige Aktivierungen produzieren, und schützt diese vor Quantisierung. Liefert oft etwas bessere Qualität als GGUF bei gleicher Bittiefe, ist aber komplexer zu generieren. In vLLM und text-generation-inference oft verwendet.

GPTQ (Frantar et al. 2022). Älter, eines der ersten produktiven Quantisierungs-Schemata. Iterative Optimierung der Quantisierungs-Werte. Mai 2026 noch in Verwendung, aber durch AWQ und GGUF zunehmend abgelöst.

BitsAndBytes. Hugging-Face-Integration. NF4 (4-Bit Normal-Float) primär für QLoRA-Training, INT8 für einfache Inference-Quantisierung. Bequem in Python-Inference-Pipelines.

Praktischer Hinweis. Auf Ollama-Hub und HuggingFace gibt es für fast jedes Open-Weight-Modell die GGUF-Quantisierungen vom Maintainer (z.B. TheBloke, Bartowski) gleich mit. Selbst quantisieren ist mit llama.cpp möglich (Befehl `quantize`), nimmt 5-30 Minuten pro Modell auf einer GPU. Für 99% der KMU-Fälle: Quantisierungen herunterladen, nicht selbst machen.

Quantisierungs-Wahl in 5 Schritten

1. 01Hardware-Budget klären: wie viel RAM/VRAM ist verfügbar? Bestimmt, welche Modellgrösse und welche Quantisierungs-Stufe überhaupt passt.
2. 02Modellgrösse wählen: 8B für einfache Aufgaben und Edge, 30-70B für Production-RAG, 70B+ für höchste Qualität (mit entsprechender Hardware).
3. 03Quantisierungs-Stufe: Q4_K_M als Default. Q5_K_M wenn Hardware Spielraum hat. Q8_0 nur bei besonderem Qualitäts-Bedarf. Q3 nur wenn unbedingt nötig.
4. 04Eval-Suite gegen FP16-Referenz: 50-200 reale Aufgaben mit erwartetem Ergebnis, beide Varianten testen, Qualitäts-Verlust beziffern.
5. 05Production-Setup mit Monitoring: Latenz, Qualitäts-Score, Memory-Footprint im Auge behalten; bei Modell-Updates die Eval-Suite neu durchlaufen.

Wann Quantisierung sich lohnt

Vier konkrete Anwendungs-Szenarien Mai 2026.

1. Self-hosted Modell auf eigener Hardware. Wer Ollama auf eigenem Server betreibt oder ein Modell über vLLM/TGI selbst hostet, nimmt fast immer eine quantisierte Variante. Llama-3.1-8B in Q4_K_M (5 GB) statt FP16 (16 GB), Llama-3.1-70B in Q4_K_M (42 GB) statt FP16 (140 GB). Hardware-Kosten sinken um den Faktor 3-4. Siehe self-hosted-ollama-evaluation.

2. Edge / lokale Anwendung. Eine Anwalts-Anwaltskanzlei, die einen lokalen RAG-Assistenten auf jeder Mitarbeiter-Workstation laufen lassen will (statt zentral), braucht ein Modell, das auf 16-32 GB RAM läuft. Q4-quantisierte 7B-Modelle sind dafür ideal. iPhone/iPad-Anwendungen mit lokalem Modell setzen Q4 oder noch stärker quantisiert ein.

3. Cloud-Inference-Kosten optimieren. Bei Anwendungen mit hohem Volumen (z.B. Triage von 10000 E-Mails pro Tag) ist ein quantisiertes Open-Source-Modell auf Together.ai oder Replicate oft 5-10x billiger als GPT-4 oder Claude 4 für ähnliche Aufgaben-Qualität. Bei Klassifikation und Routine-Antworten reicht das.

4. Spezielles Hardware-Setup. Apple Silicon (M2/M3/M4 Pro/Max/Ultra) mit unified memory läuft sehr effizient mit quantisierten Modellen – die Apple-Neural-Engine ist auf INT8/INT4 optimiert. Ein Mac Studio M2 Ultra (64 GB+ unified memory) ist Mai 2026 ein attraktiver Inference-Server für KMU, der Llama-3.1-70B Q4 mit 8-15 Tokens/Sekunde liefert.

Quantisierung in Cloud-Modellen. OpenAI, Anthropic, Google geben nicht öffentlich an, ob ihre kommerziellen Modelle quantisiert serviert werden – die meisten Anbieter tun das vermutlich teilweise (BF16 oder FP8). Sie als Kunde merken davon nichts; relevante Qualitäts-Faktoren sind veröffentlichte Benchmarks und eigene Eval-Suite, nicht Präzisions-Spezifikationen.

Wann KEINE Quantisierung

Drei Konstellationen, in denen Quantisierung Schaden anrichten kann.

Erstens: Trainings-/Fine-Tuning-Phase mit Full-Fine-Tuning. Wer ein Modell mit allen Gewichten trainiert, braucht hohe Präzision (FP16 oder BF16). Quantisierung erst NACH dem Training anwenden. QLoRA-Training kombiniert ein quantisiertes Basis-Modell (4-Bit eingefroren) mit FP16-Adaptern – das ist anders und funktioniert.

Zweitens: sehr enge Aufgaben mit hoher Präzisions-Anforderung. Mathematische Berechnungen, exakte Logik-Reasoning, Code mit subtilen Bug-Risiken. Mai 2026 zeigen Studien: aggressive Quantisierung (Q3 und niedriger) reduziert die Genauigkeit dieser Spezial-Fähigkeiten stärker als allgemeine Sprachfähigkeiten. Bei Mathe- und Code-kritischen Anwendungen ist Q5/Q6 oder FP16 die sicherere Wahl. Eigene Eval-Suite vor Inbetriebnahme zwingend.

Drittens: kleine Modelle (unter 3B Parametern). Quantisierung wirkt am besten auf grösseren Modellen – sie haben mehr Redundanz und tolerieren Bit-Reduktion besser. Bei Modellen unter 3B kann Q4 spürbaren Qualitäts-Verlust bringen; bei 1B-Modellen ist Q4 oft schon problematisch. Faustregel: ab 7B Q4_K_M problemlos, ab 30B Q3 noch tolerabel, unter 3B mindestens Q5/Q6 oder FP16.

Falle: blindes Vertrauen in Benchmark-Zahlen. Eine Quantisierung mit "2% Qualitätsverlust" laut MMLU oder Hellaswag kann auf Ihrer konkreten Anwendung 5-10% Verlust haben – die Benchmarks decken nicht alle Spracharten und Aufgaben-Typen ab. Eigene Eval-Suite vor Wahl der Quantisierungs-Stufe zwingend.

Falle: Mismatch Modell-Variante. Quantisierte Versionen werden von der Community erstellt und unterscheiden sich. "Llama-3.1-70B Q4_K_M von TheBloke" und "Llama-3.1-70B Q4_K_M von Bartowski" können leicht unterschiedlich performant sein. Bei produktiver Wahl: Eval-Suite auf der konkreten Datei, nicht nur auf der Bezeichnung.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. GGUF – Format Specification and llama.cpp Quantize Documentation · 2026-04
2. Lin et al. – AWQ: Activation-aware Weight Quantization for LLMs · 2023-06
3. Frantar et al. – GPTQ: Accurate Post-Training Quantization · 2022-10
4. Hugging Face – Quantisation Guide (BitsAndBytes, GPTQ, AWQ) · 2026-05