Quantisierung

Quantisierung ist der Prozess, die Gewichte eines LLM von hochpräzisen Gleitkommazahlen (typischerweise 16-Bit-bfloat oder -float) in Ganzzahlen oder Gleitkommazahlen geringerer Präzision (8 Bit, 4 Bit, manchmal 2 Bit) umzuwandeln, was den Speicherbedarf verringert und die Inferenz beschleunigt, mit nur geringen Qualitätseinbußen. Moderne Open-Source-Bereitstellung, also llama.cpp, Ollama, vLLM, GPTQ und AWQ, läuft fast vollständig auf quantisierten Modellen.

Warum das wichtig ist

Ein Modell mit 70 Mrd. Parametern im nativen 16-Bit-Format benötigt etwa 140 GB GPU-Speicher, außer Reichweite für eine einzelne Consumer-Karte. Dasselbe Modell in 4-Bit-Quantisierung benötigt etwa 35 GB und passt auf zwei Consumer-GPUs, eine einzelne Workstation-Karte oder sogar einen Mac Studio. Die Quantisierung machte lokale LLMs praktikabel: Llama 3 70B, Mixtral 8×22B und DeepSeek-V3 laufen alle auf Hardware für 3.000 US-Dollar, weil es Quantisierung gibt. Für Entwickler ist sie der Unterschied zwischen "wir können uns kein eigenes Hosting leisten" und "wir können unsere eigenen Modelle bereitstellen".

Wie es funktioniert

Präzisionsstufen:

• FP32 (32-Bit-Gleitkomma): Trainingsstandard. 4 Byte pro Gewicht. Selten für Inferenz genutzt.
• FP16 / BF16 (16 Bit): Inferenzstandard. 2 Byte pro Gewicht.
• INT8 (8-Bit-Ganzzahl): Halber Speicher, nahezu identische Qualität.
• INT4 / FP4 (4 Bit): Ein Viertel des Speichers, geringe Qualitätseinbuße (üblicherweise 1 bis 3 % bei Benchmarks).
• INT2 (2 Bit): Ein Achtel des Speichers, spürbarer Qualitätsverlust bei den meisten Aufgaben.

Quantisierungsprozess:

1. Kalibrierung: Das Modell wird über einen kleinen Datensatz ausgeführt, um die Aktivierungsbereiche zu beobachten.
2. Berechnung von Skala und Nullpunkt: Für jeden Gewichtstensor werden Skalierungsfaktoren berechnet, die den ursprünglichen Bereich auf den Ganzzahlbereich abbilden.
3. Gewichtsumwandlung: Jedes Gewicht wird quantisiert und als Ganzzahl plus gruppen- oder kanalweise Skalierungsfaktoren gespeichert.
4. Dequantisierung bei der Inferenz: Zur Rechenzeit werden die Gewichte unmittelbar vor der Matrixmultiplikation wieder in Gleitkommazahlen expandiert.

Quantisierungsmethoden

RTN (Round to Nearest): Einfachste Methode. Gewichte einfach auf den nächsten quantisierten Wert runden. Schnell, geringe Qualität.

GPTQ: Gruppenweise Post-Training-Quantisierung, die den Rekonstruktionsfehler minimiert. Open-Source-Standard für 4 Bit.

AWQ (Activation-aware Weight Quantization): Bewahrt Gewichte, die große Aktivierungen verarbeiten; den Rest quantisiert sie aggressiver. Sehr beliebt für 4-Bit-LLMs.

GGUF (Q4_K_M, Q5_K_M usw.): Die blockweise Quantisierungsformatfamilie von llama.cpp. Die K_M-Varianten wägen Größe und Genauigkeit ab. Q4_K_M ist das Standardformat für lokale Inferenz.

SmoothQuant: Verschiebt Aktivierungsausreißer in die Gewichte, sodass beide sauber quantisiert werden können. Ermöglicht INT8 ohne großen Genauigkeitsverlust bei großen Modellen.

QAT (Quantization-Aware Training): Trainiert das Modell mit der Quantisierung in der Schleife. Beste Qualität, erfordert aber ein erneutes Training.

FP8: Ein hardwarenatives 8-Bit-Gleitkommaformat, das von H100/H200-GPUs unterstützt wird. Schneller als INT8 für Training und Inferenz.

Kompromisse

Qualität vs. Komprimierung: Je geringer die Präzision, desto stärker verschlechtert sich das Modell. 8 Bit ist nahezu kostenlos; 4 Bit ist ein guter Standard; 2 Bit schmerzt sichtbar.

Aufgabenempfindlichkeit: Mathematik, Code und langes Schlussfolgern werden von der Quantisierung stärker getroffen als Chat oder Zusammenfassung.

Geschwindigkeit vs. Speicher: Quantisierung spart Speicher, beschleunigt die Inferenz aber nicht immer auf GPUs mit reichlich Rechenleistung. Auf speichergebundener Hardware (Consumer-GPUs, Apple Silicon) ist sie eine enorme Beschleunigung.

Qualität der Kalibrierungsdaten: Eine schlechte Kalibrierung kann quantisierte Modelle unbemerkt ruinieren. Verwenden Sie repräsentative Prompts.

Was wann zu verwenden ist

Betrieb auf Consumer-GPU (8 bis 24 GB): 4-Bit-GGUF (Q4_K_M) oder AWQ.

Betrieb auf H100/H200: FP8 oder INT8 mit SmoothQuant.

Edge / Mobil: Aggressives 4-Bit- oder 2-Bit-GGUF; akzeptieren Sie Qualitätsverlust.

Benchmarking-Forschung: Behalten Sie FP16/BF16 als Referenz; quantisieren Sie nur für den Bereitstellungsvergleich.

Produktion mit hohem Einsatz: 8 Bit oder 16 Bit. Die Mehrkosten sind die Qualitätsgarantie wert.

Häufige Fehler

Benchmarks über Präzisionen hinweg vergleichen, ohne es zu vermerken: Der MMLU-Wert eines quantisierten Modells ist nicht direkt mit dem FP16-Wert desselben Modells vergleichbar.

Perplexitätsdrift ignorieren: Selbst wenn Benchmarks gut aussehen, kann die Quantisierung bestimmte Fähigkeiten verschlechtern (besonders Mathematik). Testen Sie an Ihrer realen Arbeitslast.

Zu schnell zu aggressiv: Von FP16 direkt auf INT2 zu springen, ohne dazwischen zu testen, verbirgt, wo die Qualität gebrochen ist.

Veraltete Kalibrierungsdaten verwenden: Ein nur auf Englisch kalibriertes Modell verliert an Qualität bei koreanischen Prompts.

Die End-to-End-Latenz nicht messen: Quantisierung wirkt sich sowohl auf die Speicherauslastung als auch auf die Rechenleistung aus. Manchmal verbessert sich der Durchsatz nicht, weil der Engpass woanders lag.

Quellen:

• Ein visueller Leitfaden zur Quantisierung - Maarten Grootendorst
• AWQ Paper - MIT
• GGUF und llama.cpp Quantization - Hugging Face