QLoRA, Quantisierung und effizientes Training großer Modelle

Quantisierung — das Reduzieren der Bitbreite von Modellgewichten — ist die zweite große Demokratisierung der LLM-Welt nach LoRA. Was 2022 noch Vorbehalten gegenüberstand, ist 2026 Standard: Modelle in 4 Bit zu trainieren und zu betreiben, oft ohne spürbaren Qualitätsverlust. Dieser Beitrag erklärt, wie das funktioniert, welche Verfahren wofür taugen und wo die Grenzen liegen.

1. Das Speicherproblem moderner LLMs

Ein modernes LLM hat 8 bis 70 Milliarden Parameter. In voller Präzision (FP32, 32 Bit) braucht ein 70B-Modell allein für die Gewichte 280 GB — das passt auf keine einzelne GPU der Welt. In halber Präzision (FP16, 16 Bit) sind es noch 140 GB — immer noch zu viel für eine GPU. Für Training kommt der mehrfache Speicherbedarf für Gradienten und Optimizer-Zustände hinzu.

Quantisierung löst dieses Problem. Statt jeden Wert in 16 Bit zu speichern, wird er auf 8, 4 oder sogar 2 Bit reduziert. Bei 4-Bit-Quantisierung sinkt der Speicherbedarf eines 70B-Modells auf rund 35 GB — und passt damit auf eine einzelne A100-80GB oder L40S-48GB.

2. Quantisierung — die Grundlagen

Die Grundidee: Statt jeden Parameter als unabhängige Fließkommazahl zu speichern, definiert man einen Codebook mit den häufigsten Werten und referenziert jeden Parameter über einen kurzen Index. Bei 4 Bit gibt es 16 mögliche Werte pro Block; bei 8 Bit 256.

Damit das ohne Qualitätsverlust funktioniert, wird der Codebook so gewählt, dass er die Verteilung der echten Gewichte gut approximiert. Außerdem werden Skalierungsfaktoren pro Block (etwa 64 oder 128 Parameter) gespeichert, die den Quantisierungsfehler weiter reduzieren.

Zwei Modi sind wichtig:

• Post-Training Quantization (PTQ). Ein fertig trainiertes Modell wird quantisiert. Schnell, oft mit minimalem Qualitätsverlust.
• Quantization-Aware Training (QAT). Das Modell wird bereits mit Quantisierung im Hinterkopf trainiert. Aufwändiger, aber für sehr niedrige Bitbreiten (2 Bit) nötig.

3. QLoRA: 4-Bit-Training, das funktioniert

QLoRA (Quantized LoRA), 2023 veröffentlicht, war der Durchbruch. Die Idee:

• Basismodell in 4-Bit (NF4). Eingefroren, kein Gradient erforderlich. Das spart 75% Speicher gegenüber FP16.
• LoRA-Adapter in FP16 oder BF16. Werden trainiert, in voller Präzision, aber klein.
• Doppelte Quantisierung. Auch die Skalierungsfaktoren werden noch einmal quantisiert — minimaler Effekt auf Qualität, weiteres Sparen.
• Paged Optimizer. Optimizer-Zustände werden bei Bedarf zwischen GPU und CPU verschoben, was Spitzenlast abfedert.

Das Ergebnis: Ein 70B-Modell lässt sich auf einer einzelnen 48-GB-GPU (zum Beispiel L40S oder RTX 6000 Ada) fine-tunen. Auf einer 80-GB-A100 oder H100 sogar mit komfortablem Spielraum. Mehr zu LoRA selbst in LoRA erklärt.

4. NF4, GPTQ, AWQ, GGUF — Verfahren im Vergleich

NF4 (Normal-Float 4). Optimiertes 4-Bit-Format, das die typische Normalverteilung von LLM-Gewichten ausnutzt. Standard für QLoRA-Training. Sehr gute Qualität, moderat schnell.

GPTQ. Inferenz-orientierte 4-Bit-Quantisierung. Nutzt Hessian-Informationen, um Quantisierungsfehler über die Layer hinweg zu minimieren. Wird offline berechnet (Calibration-Datensatz nötig), läuft dann sehr schnell mit vLLM und TGI.

AWQ (Activation-aware Weight Quantization). Ähnlich wie GPTQ, aber berücksichtigt die Aktivierungen — also welche Gewichte für den Modelloutput am wichtigsten sind. Etwas bessere Qualität als GPTQ, ähnliche Geschwindigkeit.

GGUF. Das Format von llama.cpp, optimiert für CPU- und Mac-Inferenz mit Apple-Silicon. Verschiedene Bit-Varianten (Q2, Q3, Q4, Q5, Q6, Q8). Standard für lokale Inferenz und Edge-Deployments.

FP8. Native 8-Bit-Fließkomma-Unterstützung auf H100 und neueren GPUs. Sehr nahe an FP16-Qualität, doppelt so schnell, weniger Speicher. Standard für moderne Trainings-Setups bei großen Modellen.

5. Trade-offs zwischen Speicher, Qualität, Geschwindigkeit

Eine Faustregel für die Praxis:

• FP16/BF16: Volle Qualität, voller Speicherbedarf. Standard für Pretraining.
• FP8: ~99% Qualität, halber Speicher, doppelte Geschwindigkeit. Standard für moderne Trainings.
• INT8: ~99% Qualität, halber Speicher, gleiche Geschwindigkeit wie FP16. Für Inferenz beliebt.
• NF4 / 4-Bit: ~97–98% Qualität, viertel Speicher, etwas langsamere Inferenz als INT8.
• 3-Bit: ~94–96% Qualität, weniger Speicher, deutlich langsamer.
• 2-Bit: ~88–92% Qualität, minimaler Speicher, oft erst nach QAT verwendbar.

Für die meisten Produktivsysteme ist 4-Bit der optimale Punkt: Speicher massiv reduziert, Qualität fast unverändert, Inferenz noch ausreichend schnell.

6. Praxis: Wann welche Methode?

• Training (Fine-Tuning): QLoRA mit NF4 ist der De-facto-Standard. Alternative bei H100/MI300: FP8 mit Full-Parameter-Training.
• Server-Inferenz: GPTQ oder AWQ in 4-Bit, betrieben mit vLLM oder TGI. Schnelle Inferenz, gute Qualität.
• Lokale / Mac-Inferenz: GGUF mit llama.cpp oder Ollama. Q4_K_M ist ein guter Kompromiss aus Qualität und Geschwindigkeit.
• Edge / Mobile: GGUF in Q2 oder Q3 für sehr kleine Modelle. Siehe Small Language Models und Edge AI.

In Beratungsprojekten empfehlen wir fast immer eine Trennung: Training mit QLoRA/NF4, Inferenz mit GPTQ oder AWQ. Beide Welten profitieren von ihren spezialisierten Verfahren.

7. Grenzen und Risiken

Quantisierung ist kein Wundermittel:

• Sehr kleine Modelle leiden stärker. Ein 1B-Modell in 4-Bit kann spürbar an Qualität verlieren. Bei Modellen unter 3B ist 8-Bit oft sicherer.
• Reasoning-Aufgaben sind empfindlicher. Bei mehrstufigen Schlussfolgerungen können sich kleine Quantisierungsfehler aufsummieren. Mehr in Reasoning Models.
• Edge-Cases werden schwerer messbar. Quantisierte Modelle können auf seltenen Inputs unerwartet versagen. Eval-Pipelines müssen das einbeziehen — siehe Guardrails, Evals und Prompt Injection.
• Kalibrationsdaten beeinflussen GPTQ/AWQ. Die Wahl der Kalibrationsdaten verändert die Quantisierungsqualität. Repräsentative Domain-Daten verbessern die Inferenzqualität spürbar.

Quantisierung und QLoRA sind 2026 keine experimentelle Spielwiese, sondern unverzichtbare Werkzeuge für produktive LLM-Setups. Wer sie nicht beherrscht, zahlt entweder unnötig viel für Hardware oder lässt Anpassungsmöglichkeiten ungenutzt liegen. Mit etwas Disziplin in Tooling und Eval entsteht aus einer einzelnen GPU und einem kuratierten Datensatz ein produktives domänenspezifisches System — souverän, kontrollierbar und mit klar planbaren Kosten.