Christoph Kind LogoCHRISTOPH KIND
Quantisierung von LLMs erklärt: Große Modelle auf kleiner Hardware

Quantisierung von LLMs erklärt: Große Modelle auf kleiner Hardware

Quantisierung von LLMs erklärt: Große Modelle auf kleiner Hardware

Artikel-Übersicht

In diesem Leitfaden zeige ich dir, wie du große Sprachmodelle durch Quantisierung so weit komprimierst, dass sie auf deiner eigenen Hardware laufen – auf der Gaming-Grafikkarte, dem MacBook oder sogar auf einem Mini-PC. Wir starten mit der Frage, warum Quantisierung überhaupt nötig ist und was sie dir an VRAM, Geschwindigkeit und Unabhängigkeit bringt. Danach klären wir die Grundlagen: Wie Gewichte als fp32, fp16 oder bf16 gespeichert werden, was passiert, wenn man sie auf int8 oder int4 herunterbricht, und warum das überhaupt funktioniert, ohne dass das Modell kompletten Unsinn redet. Du lernst Perplexity und KL-Divergenz als Qualitätsmaße kennen. Im Hauptteil gehen wir die wichtigsten Formate und Methoden des Jahres 2026 durch: GGUF mit seinen K-Quants (Q4_K_M, Q5_K_M, Q8_0) und I-Quants, dazu GPTQ, AWQ, bitsandbytes mit NF4/QLoRA sowie neuere Verfahren wie MXFP4 und FP8. Wir grenzen Post-Training-Quantisierung gegen quantisierungsbewusstes Training ab und schauen uns den zentralen Trade-off Größe gegen Qualität mit konkreten Faustregeln und Tabellen an. Zum Schluss wird es praktisch: Du ziehst und erzeugst Modelle in verschiedenen Quants mit Ollama und llama.cpp und lernst, wie du die richtige Quantisierung für deine Hardware auswählst.

Einleitung: Warum passt ein 70-Milliarden-Modell plötzlich auf deinen Laptop?

Stell dir vor, du willst ein modernes Sprachmodell mit 70 Milliarden Parametern lokal betreiben. In voller Präzision (fp16) braucht so ein Modell rund 140 Gigabyte Speicher – allein für die Gewichte, ohne den Kontext und die Zwischenrechnungen. Das ist die Liga von zwei oder drei Profi-Grafikkarten für jeweils mehrere Tausend Euro. Für die allermeisten von uns ist das schlicht unerreichbar.

Und jetzt der Trick: Mit Quantisierung schrumpft genau dieses Modell auf etwa 40 Gigabyte oder weniger – und läuft damit auf einer einzigen High-End-GPU oder einem gut ausgestatteten Mac. Ein 8-Milliarden-Modell, das in fp16 noch 16 GB belegt, passt quantisiert in unter 5 GB und tuckert dann sogar auf einer betagten Mittelklasse-Grafikkarte vor sich hin.

Die schönste Analogie dafür ist die JPEG-Kompression. Ein unkomprimiertes RAW-Foto ist riesig und enthält jede noch so feine Farbnuance. Ein JPEG wirft die Informationen weg, die dein Auge ohnehin kaum wahrnimmt – und plötzlich ist das Bild zehnmal kleiner, sieht aber für den Alltag praktisch identisch aus. Quantisierung macht im Grunde dasselbe mit den Zahlen in einem neuronalen Netz: Sie speichert sie gröber, wirft unnötige Präzision weg und behält dabei erstaunlich viel von der ursprünglichen Qualität. Genau das schauen wir uns jetzt im Detail an.

Warum Quantisierung? Speicher, Geschwindigkeit, Unabhängigkeit

Es gibt drei große Gründe, warum sich praktisch jeder, der lokal mit LLMs arbeitet, mit Quantisierung beschäftigt:

  • Speicher und VRAM: Das ist der offensichtlichste Punkt. Ob ein Modell vollständig in den VRAM deiner GPU passt, entscheidet darüber, ob es flüssig läuft oder quälend langsam (weil Teile in den langsameren System-RAM ausgelagert werden müssen). Quantisierung halbiert, viertelt oder achtelt den Speicherbedarf – und macht damit Modelle überhaupt erst nutzbar.
  • Geschwindigkeit: Bei lokaler Inferenz ist die Geschwindigkeit oft durch die Speicherbandbreite begrenzt, nicht durch die Rechenleistung. Wenn jedes Gewicht statt 16 Bit nur noch 4 Bit belegt, müssen pro Token viermal weniger Daten aus dem Speicher geladen werden. Das beschleunigt die Token-Generierung spürbar – ein quantisiertes Modell ist also nicht nur kleiner, sondern meist auch schneller.
  • Lokales Deployment und Unabhängigkeit: Quantisierung ist der Schlüssel dazu, KI ohne Cloud zu betreiben. Deine Daten bleiben auf deinem Rechner (ein riesiger Pluspunkt beim Datenschutz), du zahlst keine API-Gebühren pro Token, du bist offline lauffähig und niemand ändert dir über Nacht das Modell oder die Preise.

Kurz gesagt: Quantisierung ist die Brücke zwischen den gewaltigen Modellen, die in Rechenzentren trainiert werden, und der Hardware, die bei dir zu Hause oder im Büro steht.

Grundlagen: Wie ein Modell überhaupt Zahlen speichert

Ein Sprachmodell besteht im Kern aus Milliarden von Gewichten – das sind schlicht Zahlen, die während des Trainings gelernt wurden. Wie genau eine einzelne Zahl gespeichert wird, bestimmt der Datentyp:

  • fp32 (32-Bit-Gleitkomma): Der klassische „volle" Datentyp. Jede Zahl belegt 4 Bytes und bietet eine sehr feine Auflösung. Trainiert wird oft hierin, aber für die Inferenz ist es Verschwendung.
  • fp16 (16-Bit-Gleitkomma): Halbe Größe, 2 Bytes pro Zahl. Der Standard für die Inferenz „unquantisierter" Modelle. Kann bei sehr großen oder kleinen Werten an die Grenzen seines Wertebereichs stoßen.
  • bf16 (Brain Float 16): Ebenfalls 2 Bytes, aber anders aufgeteilt. bf16 opfert Nachkommastellen-Genauigkeit zugunsten eines größeren Wertebereichs (gleicher Exponentenbereich wie fp32). Deshalb ist bf16 heute der bevorzugte Datentyp beim Training und der Ausgangspunkt der meisten Quantisierungen.

fp16 und bf16 sind also schon eine Art „Vor-Komprimierung" gegenüber fp32. Die eigentliche Quantisierung geht aber einen großen Schritt weiter und wechselt von Gleitkomma- zu Ganzzahl-Darstellungen (oder sehr kleinen Float-Formaten):

  • int8 (8-Bit-Ganzzahl): Nur noch 1 Byte pro Gewicht, 256 mögliche Werte. Qualitativ meist kaum von fp16 zu unterscheiden.
  • int4 (4-Bit-Ganzzahl): Ein halbes Byte pro Gewicht, gerade einmal 16 mögliche Werte. Das ist der Sweet Spot für lokales Deployment – erstaunlich gut, obwohl die Auflösung brutal grob klingt.

Wie funktioniert reduzierte Präzision, ohne dass alles kaputtgeht?

Die berechtigte Frage lautet: Wie kann ein Modell noch sinnvoll arbeiten, wenn jedes Gewicht nur noch 16 verschiedene Werte annehmen kann? Die Antwort liegt in der Skalierung pro Block.

Man quantisiert nicht alle Milliarden Gewichte mit einem einzigen Maßstab, sondern teilt sie in kleine Blöcke auf (etwa 32 oder 256 Werte). Für jeden Block wird ein eigener Skalierungsfaktor (und oft ein Nullpunkt) gespeichert. Innerhalb des Blocks merkt man sich dann nur, „welcher der 16 Stufen" das Gewicht am nächsten kommt. Beim Rechnen wird die Stufe wieder mit dem Skalierungsfaktor multipliziert und man erhält eine gute Näherung des Originalwerts.

Hier hilft eine Analogie: Stell dir vor, du sollst die Körpergrößen aller Menschen in einem Raum notieren, hast aber nur ein grobes Lineal mit wenigen Strichen. Statt eines Lineals für die ganze Stadt nimmst du für jede kleine Personengruppe ein eigenes, passend skaliertes Lineal. Die Kindergruppe bekommt ein fein abgestuftes Kinder-Lineal, die Basketball-Mannschaft ein gröberes – und am Ende sind alle Werte verblüffend genau, obwohl jedes Lineal nur wenige Striche hat.

Der unvermeidliche Fehler zwischen Originalwert und quantisiertem Wert heißt Quantisierungsfehler. Das ganze Spielfeld der Quantisierungsmethoden dreht sich darum, diesen Fehler so zu verteilen, dass er möglichst wenig schadet – etwa indem besonders wichtige („saliente") Gewichte feiner aufgelöst werden als unwichtige.

Perplexity und KL-Divergenz: Wie misst man Qualitätsverlust?

Wenn wir Präzision wegwerfen, müssen wir messen können, wie viel Qualität dabei verloren geht. Das wichtigste klassische Maß dafür ist die Perplexity (PPL).

Perplexity beschreibt grob, wie „überrascht" ein Modell vom nächsten Wort in einem Testtext ist. Ein niedriger Wert bedeutet: Das Modell sagt den Text gut voraus, es ist sich seiner Sache sicher. Ein hoher Wert bedeutet das Gegenteil. Wenn ein quantisiertes Modell eine deutlich höhere Perplexity hat als das Original, hat die Quantisierung dem Modell geschadet. Faustregel: Steigt die Perplexity gegenüber fp16 nur um Bruchteile eines Prozents, merkst du in der Praxis nichts.

Perplexity hat aber eine Schwäche – sie misst nur, ob das Modell den Text grob vorhersagen kann, nicht, wie stark sich die gesamte Wahrscheinlichkeitsverteilung verschiebt. Deshalb hat sich 2026 die KL-Divergenz als feineres Maß etabliert. Sie vergleicht direkt, wie stark die Vorhersageverteilung des quantisierten Modells von der des Originals abweicht. Je kleiner die KL-Divergenz, desto näher verhält sich der Quant am Original. In den weiter unten gezeigten Tabellen siehst du genau diese Werte – sie sind heute der Goldstandard, um Quants fair zu vergleichen.

GGUF: Das Format für lokale Inferenz

Wenn du lokal LLMs betreibst, führt kein Weg an GGUF vorbei. GGUF ist das native Dateiformat von llama.cpp, jener C/C++-Inferenz-Engine, die lokale KI auf Consumer-Hardware überhaupt erst praktikabel gemacht hat. Tools wie Ollama, LM Studio und Jan setzen alle darunter auf llama.cpp und GGUF auf.

GGUF ist ein Single-File-Format: Modellgewichte, Tokenizer und Metadaten stecken in einer einzigen .gguf-Datei. Der große Vorteil von GGUF ist seine Flexibilität bei der CPU/GPU-Aufteilung: Du kannst ein Modell, das nicht ganz in den VRAM passt, teilweise auf die GPU und teilweise auf die CPU legen. Genau das macht GGUF zum König der Mischhardware – etwa einer Gaming-GPU mit 12 GB plus reichlich System-RAM. Auf Apple-Silicon-Macs nutzt llama.cpp den gemeinsamen Unified Memory besonders effizient.

Innerhalb von GGUF gibt es zwei moderne Quant-Familien, die du kennen musst: K-Quants und I-Quants.

K-Quants: Der robuste Standard (Q4_K_M & Co.)

Die K-Quants sind die meistgenutzte Quant-Familie. Ihr Clou ist eine hierarchische Super-Block-Struktur: Gewichte werden in Super-Blöcke zu je 256 Werten gruppiert, und innerhalb dieser werden mehrere Skalierungs- und Minimum-Parameter pro Sub-Block gespeichert. Das verteilt die verfügbaren Bits dort hin, wo sie am meisten bringen.

Entscheidend sind die Suffixe _S, _M und _L (small, medium, large). Sie stehen für eine Mixed-Precision-Strategie: Bei Q4_K_M etwa werden besonders sensible Schichten (Attention- und manche Feed-Forward-Tensoren) mit mehr Bits aufgelöst als der Rest. Genau deshalb ist Q4_K_M so beliebt – es kostet kaum mehr Platz als eine reine 4-Bit-Quantisierung, ist aber qualitativ oft kaum vom Original zu unterscheiden.

Die wichtigsten K-Quants in der Praxis:

  • Q4_K_M – der mit Abstand meistgeladene Quant. Niedriger Speicherbedarf, hohe Qualität. Der Standard-Startpunkt für fast jeden.
  • Q5_K_M – eine Stufe besser, für viele Aufgaben praktisch nicht mehr vom Original unterscheidbar.
  • Q6_K – nahezu verlustfrei, wenn du den Platz hast.
  • Q8_0 – 8 Bit, praktisch identisch zum Original. Eigentlich nur sinnvoll, wenn du jedes Quäntchen Qualität willst und genug Speicher hast.

I-Quants: Mehr Qualität bei extrem kleinen Größen

Die neueren I-Quants (erkennbar am IQ-Präfix, z. B. IQ2_XXS, IQ3_M, IQ4_XS, IQ4_NL) verfolgen das Ziel, bei sehr niedrigen Bitraten so viel Qualität wie möglich zu erhalten. Sie nutzen ausgefeiltere Codierungstechniken und schaffen dadurch bessere Qualität pro Bit – ein gut gemachter 4-Bit-I-Quant kann einen naiven 5-Bit-Legacy-Quant schlagen.

Ein konkreter Vergleich aus den offiziellen llama.cpp-Zahlen für Llama-3.1-8B: IQ4_XS liegt bei rund 4,46 bpw / 4,17 GiB, während Q4_K_M bei 4,89 bpw / 4,58 GiB liegt. IQ4_XS ist also kleiner und bei der Token-Generierung oft etwas schneller, dafür beim Prompt-Processing etwas langsamer und empfindlicher dafür, wie sauber der Quant erzeugt wurde. Der Haken: I-Quants brauchen mehr Rechenleistung beim Dekodieren und glänzen vor allem dann, wenn man mit einer Importance-Matrix (imatrix) quantisiert. Auf manchen schwachen CPUs können sie langsamer sein als K-Quants.

Faustregel: Reicht dir der Platz für Q4_K_M, nimm Q4_K_M. Musst du jedes GB herausquetschen (etwa um ein größeres Modell unterzubringen), sind die I-Quants dein Freund.

GPTQ, AWQ und bitsandbytes: Die GPU-Welt

GGUF dominiert die CPU/Mischhardware-Welt. Auf reinen NVIDIA-GPU-Setups – besonders bei Serving-Frameworks wie vLLM – triffst du dagegen auf drei andere Formate.

  • GPTQ: Eine Post-Training-Methode, die die Gewichte Schicht für Schicht so quantisiert, dass der Rekonstruktionsfehler minimiert wird. GPTQ braucht einen kleinen Kalibrierungsdatensatz und liefert sehr gute 4-Bit-Qualität. Inferenz ist schneller als bei bitsandbytes, aber etwas langsamer als AWQ.
  • AWQ (Activation-aware Weight Quantization): AWQ identifiziert vor der Komprimierung, welche Gewichte am wichtigsten sind (anhand der Aktivierungen), und schützt diese gezielt. Das Ergebnis ist hardwarefreundlich und sehr schnell – auf Edge-GPUs sind über 3-fache Beschleunigungen dokumentiert. AWQ ist 2026 oft die erste Wahl für reine GPU-Inferenz mit Fokus auf Geschwindigkeit.
  • bitsandbytes (NF4): Hier steckt das berühmte NF4 (NormalFloat4) drin – ein 4-Bit-Datentyp, der informationstheoretisch optimal für die typische, normalverteilte Gewichtsverteilung neuronaler Netze ist. bitsandbytes quantisiert „on the fly" beim Laden, braucht keinen Kalibrierungsschritt und ist deshalb super unkompliziert.

In einem typischen Genauigkeitsvergleich (INT4) liegen alle drei dicht beieinander: AWQ etwa bei -1,3 %, NF4 bei -1,6 % und GPTQ bei -1,7 % gegenüber dem Originalmodell. Die Wahl hängt also weniger an der reinen Qualität als am Einsatzzweck.

Format Hardware-Fokus Stärke Typischer Einsatz
GGUF (K-/I-Quants) CPU, Mac, Misch, GPU Flexibel, läuft überall Lokal mit Ollama/llama.cpp/LM Studio
AWQ NVIDIA-GPU Schnellste Inferenz Serving mit vLLM
GPTQ NVIDIA-GPU Gute 4-Bit-Qualität GPU-Serving, breite Tool-Unterstützung
bitsandbytes (NF4) NVIDIA-GPU Kein Kalibrieren, QLoRA Fine-Tuning & schnelles Prototyping

QLoRA: Quantisierung trifft Fine-Tuning

Eine Sonderrolle spielt bitsandbytes, weil es das einzige der genannten Formate ist, das Fine-Tuning über QLoRA erlaubt. Die Idee dahinter ist genial sparsam: Das große Basismodell wird in NF4 eingefroren (quantisiert, also klein), und obendrauf trainierst du nur kleine LoRA-Adapter in bf16. Du fummelst also nicht an den Milliarden quantisierter Gewichte herum, sondern trainierst nur ein paar wenige Zusatzparameter „drumherum".

Das ist der Grund, warum sich plötzlich auch 13B- oder 33B-Modelle auf einer einzigen Consumer-GPU feintunen lassen – etwas, das früher ein ganzes Server-Rack gebraucht hätte. Wenn du also nicht nur ein Modell betreiben, sondern es auf deine eigenen Daten anpassen willst, ist bitsandbytes/QLoRA dein Werkzeug.

Neuere Verfahren 2026: MXFP4, NVFP4 und FP8

Die Quantisierung steht nicht still. Drei neuere Formate solltest du auf dem Schirm haben:

  • FP8 (8-Bit-Float): NVIDIAs Hopper- und Blackwell-Architekturen unterstützen FP8 nativ in den Tensor-Kernen. Die Qualität liegt für die meisten Aufgaben praktisch gleichauf mit bf16, dabei ist es speichereffizient und sehr schnell. FP8 ist der neue Standard für hochwertiges Serving großer Modelle in der Cloud.
  • MXFP4 (Microscaling FP4): Ein 4-Bit-Format, standardisiert über das Open Compute Project (OCP). Es kombiniert 4-Bit-Datenelemente (E2M1) mit einem gemeinsamen 8-Bit-Skalierungsfaktor (E8M0) für je 32 Elemente. MXFP4 wurde 2025 prominent, weil OpenAIs gpt-oss-Modelle ihre Gewichte nativ in MXFP4 speichern. Damit passt ein gewaltiges Mixture-of-Experts-Modell in erstaunlich wenig Speicher.
  • NVFP4: NVIDIAs eigene FP4-Variante mit feinerer Block-Skalierung, ebenfalls auf Blackwell zugeschnitten.

Diese Formate zeigen den Trend für 2026: weg von reiner Software-Quantisierung hin zu Datentypen, die direkt in der Hardware verankert sind. Tooling wie der LLM Compressor und NVIDIAs TensorRT Model Optimizer unterstützen sie zunehmend. Für lokale Bastler bleibt GGUF aber vorerst die praktischste Wahl.

PTQ vs. QAT: Zwei Wege zum quantisierten Modell

Es gibt grundsätzlich zwei Strategien, ein Modell zu quantisieren:

Post-Training-Quantisierung (PTQ) passiert nach dem Training. Du nimmst ein fertiges Modell und komprimierst seine Gewichte – manchmal mit einem kleinen Kalibrierungsdatensatz (GPTQ, AWQ), manchmal komplett ohne (bitsandbytes, viele GGUF-Quants). PTQ ist schnell, billig und braucht keine teure GPU-Trainingszeit. Praktisch alles, was du als Endnutzer von Hugging Face herunterlädst, ist per PTQ entstanden. Der Nachteil: Bei sehr niedrigen Bitraten (2–3 Bit) kann die Qualität spürbar leiden.

Quantisierungsbewusstes Training (QAT, Quantization-Aware Training) geht den umgekehrten Weg. Hier wird die Quantisierung schon während des Trainings (bzw. Fine-Tunings) simuliert, sodass das Modell lernt, mit der reduzierten Präzision umzugehen. Das Ergebnis ist bei aggressiver Quantisierung deutlich besser, kostet aber Trainingsaufwand und Rechenzeit. QAT siehst du daher vor allem bei den Modell-Herstellern selbst – etwa wenn Google oder Meta offizielle „QAT"-Versionen ihrer Modelle veröffentlichen, die bei 4 Bit kaum noch von der vollen Version abweichen.

Merksatz: PTQ ist der pragmatische Standard für uns alle. QAT ist die Premium-Variante, die meist die Modell-Anbieter liefern.

Der Trade-off: Größe gegen Qualität mit Faustregeln

Jetzt zur Gretchenfrage: Welche Quant-Stufe wann? Die folgende Tabelle zeigt echte Messwerte für ein 7B-Modell (Mistral-7B), inklusive Bits pro Gewicht (bpw) und KL-Divergenz – je kleiner die KL-Divergenz, desto näher am Original:

Quant bpw Dateigröße (7B) KL-Divergenz (Median) Einordnung
IQ1_S 1,78 ~1,6 GB 0,5495 Notfall, oft kaputt
IQ2_XS 2,43 ~2,2 GB 0,1146 Aggressiv, spürbar schlechter
IQ2_S 2,55 ~2,3 GB 0,0949 Ultra-low, nur bei Platznot
Q3_K_S 3,50 ~3,2 GB 0,0304 Brauchbar, merkbarer Verlust
Q4_K_S 4,57 ~4,1 GB 0,0083 Sehr gut, empfohlen
Q4_K_M 4,83 ~4,4 GB 0,0075 Bester Allrounder
Q5_K_M 5,67 ~5,1 GB 0,0043 Nahezu verlustfrei
Q6_K 6,57 ~5,9 GB 0,0032 Praktisch Original
Q8_0 8,5 ~7,7 GB ~0,001 Referenzqualität

Die Sprünge sind aufschlussreich: Von Q3 auf Q4 fällt die KL-Divergenz dramatisch (von 0,03 auf 0,008), danach flacht der Gewinn stark ab. Das ist der Grund, warum 4-Bit der Sweet Spot ist – darunter wird es schnell schlecht, darüber zahlst du viel Speicher für wenig Mehrwert.

Drei eingängige Faustregeln:

  1. Nimm den größten Quant, der vollständig in deinen VRAM passt. Wenn er passt, lass ihn ganz auf der GPU laufen – das ist immer schneller als eine CPU-Auslagerung.
  2. Ein größeres Modell in niedrigerem Quant schlägt oft ein kleineres in hohem Quant. Ein 13B-Modell in Q4_K_M ist meist besser als ein 7B-Modell in Q8_0 – bei ähnlicher Dateigröße. Mehr Parameter in grob schlagen wenige Parameter in fein.
  3. Geh nie unter Q3, wenn du es vermeiden kannst. Unter 3 Bit wird es bei kleinen Modellen schnell unbrauchbar; bei sehr großen Modellen (70B+) sind selbst 2-Bit-I-Quants noch erstaunlich nutzbar.

Praxis mit Ollama: Quants ziehen in 30 Sekunden

Genug Theorie – legen wir los. Der einfachste Einstieg ist Ollama. Standardmäßig zieht Ollama Modelle in Q4_K_M:

# Standard: lädt Q4_K_M
ollama pull llama3.1:8b

# Bestimmte Quant-Stufe über den Tag wählen
ollama pull llama3.1:70b-instruct-q5_K_M
ollama pull llama3.1:8b-instruct-q8_0

# Verfügbare Tags und aktiven Quant prüfen
ollama show llama3.1:8b

# Modell direkt starten
ollama run llama3.1:8b

Du kannst auch beliebige GGUF-Dateien direkt von Hugging Face ziehen und dabei den Quant per Tag erzwingen:

# GGUF direkt von Hugging Face mit gewähltem Quant
ollama run hf.co/bartowski/Qwen3-14B-GGUF:Q4_K_M
ollama run hf.co/bartowski/Qwen3-14B-GGUF:Q8_0

Willst du eine vorhandene GGUF-Datei lokal einbinden, schreibst du ein kleines Modelfile:

# Modelfile
FROM ./mein-modell-Q4_K_M.gguf
ollama create mein-modell -f Modelfile
ollama run mein-modell

Praxis mit llama.cpp: Eigene Quants erzeugen

Wenn du die volle Kontrolle willst – etwa um ein frisch erschienenes Modell selbst zu quantisieren – nutzt du llama.cpp direkt. Der Ablauf ist immer derselbe: Modell von Hugging Face holen, nach GGUF konvertieren, dann quantisieren.

# 1. llama.cpp holen und bauen
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build && cmake --build build --config Release

# 2. HuggingFace-Modell nach GGUF konvertieren (zunächst in bf16)
python convert_hf_to_gguf.py /pfad/zum/modell \
  --outfile modell-bf16.gguf \
  --outtype bf16

# 3. Auf Q4_K_M quantisieren
./build/bin/llama-quantize modell-bf16.gguf modell-Q4_K_M.gguf Q4_K_M

# Andere Stufen funktionieren genauso:
./build/bin/llama-quantize modell-bf16.gguf modell-Q5_K_M.gguf Q5_K_M
./build/bin/llama-quantize modell-bf16.gguf modell-Q8_0.gguf Q8_0

Für die qualitativ besten Ergebnisse – besonders bei I-Quants – nutzt du eine Importance-Matrix. Sie misst an einem kleinen Textkorpus, welche Gewichte wichtig sind, und steuert damit die Bit-Verteilung:

# Importance-Matrix berechnen
./build/bin/llama-imatrix -m modell-bf16.gguf \
  -f kalibrierungstext.txt -o modell.imatrix

# Mit imatrix einen IQ4_XS-Quant erzeugen
./build/bin/llama-quantize --imatrix modell.imatrix \
  modell-bf16.gguf modell-IQ4_XS.gguf IQ4_XS

Anschließend testest du die Qualität, indem du die Perplexity auf einem Standardtext (z. B. WikiText) misst und mit dem bf16-Original vergleichst:

./build/bin/llama-perplexity -m modell-Q4_K_M.gguf -f wikitext-test.txt

Die richtige Quantisierung für deine Hardware wählen

Zum Abschluss die Praxis-Entscheidung. Der wichtigste Wert ist dein verfügbarer VRAM (bzw. Unified Memory beim Mac). Als grobe Formel gilt: benötigter Speicher ˜ Parameter (in Mrd.) × bpw / 8, plus etwa 1–3 GB Aufschlag für Kontext und Overhead. Ein 8B-Modell in Q4_K_M braucht also rund 5–6 GB inklusive Reserve.

Deine Hardware Empfehlung Beispiel
8 GB VRAM (z. B. RTX 3060) 7–8B in Q4_K_M Llama 3.1 8B Q4_K_M
12 GB VRAM (RTX 3060 12G) 8–13B in Q4_K_M / Q5_K_M Qwen 14B Q4_K_M
16 GB VRAM (RTX 4060 Ti) 14B in Q5_K_M oder 8B in Q8_0 Qwen 14B Q5_K_M
24 GB VRAM (RTX 3090/4090) 32B in Q4_K_M Qwen 32B Q4_K_M
Mac 16 GB (Unified) 8B in Q4_K_M Llama 3.1 8B Q4_K_M
Mac 32–64 GB 32–70B in Q4_K_M Llama 3.x 70B Q4_K_M
2× 24 GB oder mehr 70B in Q5_K_M / Q6_K Llama 3.x 70B Q5_K_M

Konkrete Entscheidungshilfe in vier Schritten:

  1. Reines NVIDIA-GPU-Setup, Modell passt komplett in VRAM? Dann lohnt sich AWQ/GPTQ mit vLLM für maximale Geschwindigkeit – oder du bleibst der Einfachheit halber bei GGUF.
  2. Mac oder Mischhardware (GPU + CPU + RAM)? Immer GGUF, idealerweise Q4_K_M. Es nutzt deine Hardware am flexibelsten.
  3. Modell zu groß für deinen VRAM? Wechsle auf einen kleineren Quant (Q4_K_S, IQ4_XS) oder ein I-Quant, bevor du auf ein schwächeres Modell ausweichst – größeres Modell in grob schlägt meist kleineres in fein.
  4. Du willst feintunen? Dann bitsandbytes mit QLoRA (NF4).

Zusammenfassung und praktische Tipps

Quantisierung ist die Schlüsseltechnologie, die große Sprachmodelle aus den Rechenzentren auf deine eigene Hardware holt. Sie funktioniert wie eine JPEG-Kompression für Modellgewichte: Indem die Präzision der Zahlen von fp16/bf16 auf int8 oder int4 reduziert wird – mit cleverer Skalierung pro Block – schrumpft der Speicherbedarf drastisch, während die Qualität (gemessen an Perplexity und KL-Divergenz) erstaunlich gut erhalten bleibt.

Die wichtigsten Erkenntnisse zum Mitnehmen:

  • GGUF mit Q4_K_M ist der beste Allrounder für lokales Deployment und dein sicherer Startpunkt. Reicht der Platz, geh auf Q5_K_M oder Q6_K.
  • I-Quants (IQ4_XS & Co.) quetschen mehr Qualität in weniger Bits – ideal, um größere Modelle unterzubringen, am besten mit Importance-Matrix erzeugt.
  • AWQ und GPTQ glänzen auf reinen NVIDIA-GPUs beim Serving, bitsandbytes/NF4 ist dein Weg zum Fine-Tuning per QLoRA.
  • 4 Bit ist der Sweet Spot – darunter fällt die Qualität schnell, darüber zahlst du viel Speicher für wenig Gewinn.
  • Größeres Modell in niedrigerem Quant schlägt kleineres Modell in höherem Quant bei vergleichbarer Dateigröße.
  • Nimm immer den größten Quant, der vollständig in deinen VRAM passt – und teste die Qualität für deinen Anwendungsfall selbst.

Mein Tipp zum Loslegen: Installiere Ollama, zieh dir ein 8B-Modell in Q4_K_M, und probiere dann denselben Prompt einmal in Q8_0 aus. Wenn du keinen Unterschied merkst (was sehr wahrscheinlich ist), weißt du, warum Quantisierung gerade die lokale KI-Welt erobert. Viel Spaß beim Experimentieren!

Ressourcen