Ollama Modell-Quantisierung: GGUF-Format und Genauigkeitsverluste erklärt

RTX 3060, 12 GB VRAM – Llama 3 70B starten? CUDA out of memory – selbst 14B passt nicht. Quantisierung komprimiert ein 70B-Modell von 140 GB auf 40 GB – aber wie groß ist der Genauigkeitsverlust?

Red Hats über 500.000 Evaluations liefern die Antwort: 8-bit-Quantisierung stellt >99 % Genauigkeit wieder her, 4-bit 98,9 %. Im Alltag merken Sie kaum einen Unterschied – nur extreme akademische Benchmarks zeigen feine Abweichungen.

Dieser Artikel erklärt GGUF-Quantisierung, vergleicht Quantisierungsstufen und gibt Empfehlungen für Consumer-GPUs. Wenn VRAM knapp ist oder Sie der Qualität quantisierter Modelle misstrauen – hier finden Sie Antworten.

1. Was ist Quantisierung: Die „Schlankmach“-Technik für große Modelle

Kennen Sie das? Ein HD-Foto mit über 10 MB wird per Messenger auf wenige hundert KB komprimiert. Qualitätsverlust? Ja. Trotzdem erkennbar? Ja.

Modell-Quantisierung funktioniert ähnlich.

1.1 Das Wesen der Quantisierung

Gewichte großer Modelle liegen als FP16 (16-Bit-Gleitkomma) vor. Ein 7B-Modell braucht in FP16 etwa 14 GB Speicher – jeder Parameter 2 Byte.

Quantisierung wandelt diese hochpräzisen Werte in niedrigpräzise Formate um. Bei INT4 (4-Bit-Integer) braucht jeder Parameter nur 0,5 Byte. Aus 14 GB werden rund 3,5 GB.

Vergleich: FP16 speichert jeden Parameter als „sehr genaue Dezimalzahl“, z. B. 0,12345678. Nach Quantisierung zu INT4 bleibt nur eine „grobe Ganzzahl“, z. B. 3. Präzision geht verloren – die Information bleibt größtenteils erhalten.

1.2 Wie stark ist die Kompression?

Eine Übersicht (Quelle: Will It Run AI, gemessen am 7B-Modell):

Quantisierungsstufe	VRAM-Bedarf	Speicherersparnis	Qualitätsbewertung
F16 (Original)	14,0 GB	Referenz	Beste
Q8_0	7,4 GB	47 %	Excellent
Q5_K_M	4,8 GB	65 %	Good
Q4_K_M	3,9 GB	72 %	Acceptable
Q3_K_M	3,1 GB	78 %	Poor
Q2_K	2,6 GB	81 %	Very Poor

Q4_K_M spart 72 % Speicher. Ein Modell, das 14 GB VRAM brauchte, läuft auf einer 4-GB-Grafikkarte.

Als ich das erste Mal ein 7B-Modell auf einer RTX 3060 startete, fühlte sich das an wie Turbo für ein altes Auto – statt 3B jetzt 7B.

1.3 Was kostet die Quantisierung?

Kompression hat ihren Preis – wie bei Fotos. Zu stark komprimierte Bilder werden unscharf und verrauscht. Bei Modellen gilt:

• Genauigkeitsverlust: Niedrigpräzise Werte können Originalwerte nicht exakt abbilden – Fehler entstehen.
• Kontinuitätsverlust: INT4 sind diskrete Ganzzahlen, FP16 kontinuierliche Dezimalzahlen – feine Unterschiede können verschwinden.

Die zentrale Frage: Wie groß ist dieser Verlust? Lohnt es sich?

Darauf kommen wir gleich mit 500.000 Evaluations – erst weiterlesen.

2. GGUF-Format: Warum es der Standard für quantisierte Modelle ist

Beim Download quantisierter Modelle fällt die Endung .gguf auf. Was macht dieses Format besonders?

2.1 Was ist GGUF?

GGUF steht für GPT-Generated Unified Format – ein speziell für Inferenz konzipiertes Modell-Containerformat.

Entwickelt vom llama.cpp-Team. Ihre Idee war pragmatisch: Ein trainiertes Modell braucht ein praktisches Format zum Ausführen – daraus wurde GGUF.

Drei Kernvorteile:

Einzeldatei-Container. Früher mussten Sie von Hugging Face viele Dateien laden – Gewichte, Tokenizer, config.json … GGUF packt alles in eine Datei. Ein .gguf reicht.

Memory-Mapped Loading (mmap). Die Datei wird direkt in den Speicheradressraum gemappt, das System liest bei Bedarf. Vorteil: Nicht das gesamte Modell muss vorab geladen werden – nur genutzte Teile. Bei 70B-Modellen entscheidend: Vollständiges Laden dauert Dutzende Sekunden, mit mmap oft nur wenige Sekunden bis zur ersten Antwort.

Plattformübergreifend. Dieselbe GGUF-Datei läuft in Ollama, LM Studio, llama.cpp, KoboldCPP und mehr. Kein erneuter Download beim Tool-Wechsel.

2.2 GGUF vs. andere Formate

Format	Verwendung	Eigenschaften	Tool-Unterstützung
GGUF	Inferenz	Einzeldatei, quantisierungsfreundlich	Ollama, LM Studio, llama.cpp
Safetensors	Training/Fine-Tuning	Sicher, kein Pickle-Risiko	PyTorch, Hugging Face
GGML	Inferenz (alt)	Veraltet	llama.cpp (alte Versionen)
PyTorch (.pt/.bin)	Training	Flexibel, aber unsicher	PyTorch

Kurz: GGML ist der Vorgänger von GGUF und veraltet. Safetensors dient dem Training und muss für Inferenz konvertiert werden. GGUF ist für Inferenz optimiert – Ollama nutzt es standardmäßig.

Nur Inferenz? GGUF ist die richtige Wahl.

2.3 Ollama und GGUF

Ollama führt Modelle im Hintergrund mit llama.cpp aus. llama.cpp akzeptiert nur GGUF. Alle Ollama-Modelle sind also GGUF-basiert.

Bei ollama pull llama3 lädt Ollama GGUF-Dateien aus dem Modell-Repository. Offizielle Modelle sind vorquantisiert – Standard: Q4_K_M.

Wie Sie andere Quantisierungsstufen von Hugging Face laden, folgt in Abschnitt 5. Erst das Format verstehen, dann die Praxis.

3. Quantisierungsstufen im Detail: Q2 bis Q8 – welche passt?

Der Kern des Artikels. Q4_K_M oder Q5_K_M? Was bedeuten S, M, L?

3.1 Vergleichstabelle der Quantisierungsstufen

Datenquelle: Will It Run AI, gemessen am Llama 3 8B:

Quantisierungsstufe	VRAM-Bedarf	Qualitätsbewertung	Einsatz
Q8_0	~8,5 GB	Excellent	VRAM reichlich, höchste Qualität
Q6_K	~6,1 GB	Very Good	Ausgewogen, nahe am Original
Q5_K_M	~5,3 GB	Good	Sweet Spot, erste Wahl
Q5_K_S	~5,0 GB	Good	Etwas aggressiver als Q5_K_M
Q4_K_M	~4,4 GB	Acceptable	Mainstream, gutes Preis-Leistungs-Verhältnis
Q4_K_S	~4,1 GB	Acceptable	Aggressiver, leicht schlechtere Qualität
Q3_K_M	~3,5 GB	Poor	Letzter Ausweg, spürbarer Qualitätsverlust
Q3_K_S	~3,2 GB	Poor	Nicht empfohlen, außer VRAM reicht nicht
Q2_K	~2,7 GB	Very Poor	Kaum empfohlen, deutlicher Qualitätsverlust

Fett markiert: Q5_K_M und Q4_K_M – unsere Hauptempfehlungen. Warum, gleich.

3.2 Was ist K-quant? S/M/L-Suffixe

Das K steht für k-quant – eine Mischpräzisions-Quantisierungsstrategie.

Kernidee: Nicht alle Parameter werden gleich quantisiert. Präzisionsempfindliche Schichten (z. B. Attention) erhalten höhere Präzision; weniger empfindliche (z. B. FFN) werden stärker komprimiert.

Suffixe S, M, L stehen für drei Aggressivitätsstufen:

• S (Small): am aggressivsten, meiste Kompression, größter Qualitätsverlust
• M (Medium): ausgewogen, empfohlen
• L (Large): konservativ, beste Qualität, größere Datei

Q5_K_M und Q5_K_S sind beide Q5 – Q5_K_M liefert bessere Qualität bei größerer Datei.

Empfehlung: In den meisten Fällen M-Suffix. S ist zu aggressiv, L verschwendet Speicher. M ist der Sweet Spot.

3.3 Aufgabenabhängige Empfindlichkeit

Wofür nutzen Sie das Modell?

Verschiedene Aufgaben reagieren unterschiedlich auf Präzisionsverlust. Will It Run AI sortiert (empfindlich → unempfindlich):

1. Coding (Programmieren): am empfindlichsten. Logik muss stimmen – ein falscher Parameter kann den Code unbrauchbar machen. Q5_K_M oder höher empfohlen.
2. Reasoning/Math (Schlussfolgerung/Mathematik): sehr empfindlich. Q5_K_M oder höher.
3. Creative writing (Kreatives Schreiben): mittel. Q4_K_M akzeptabel.
4. Chat (Unterhaltung): wenig empfindlich. Q4_K_M völlig ausreichend.
5. Summarization (Zusammenfassung): wenig empfindlich. Q4_K_M nutzbar.

Kurz: Code und Mathe → hohe Quantisierung (Q5+); Chat und Zusammenfassung → Q4 reicht.

Eigene Erfahrung: Mit Q4_K_M beim Coden gelegentlich seltsame Fehler – falsche Funktionsnamen, chaotische Logik. Mit Q5_K_M deutlich seltener. Beim Chat merke ich Q4 vs. Q5 kaum.

4. Die Wahrheit über Genauigkeitsverlust: 500K+ Evaluationsdaten

Jetzt die harten Zahlen. Viele fürchten, Quantisierung mache Modelle „dümmer“. Red Hats Bericht hat diese Sorge bei mir weitgehend ausgeräumt.

4.1 Was hat Red Hat gemacht?

Im Oktober 2024 veröffentlichte Red Hat: „We ran over half a million evaluations on quantized LLMs“. Über 500.000 Evaluations verglichen quantisierte mit Originalmodellen.

"We ran over half a million evaluations on quantized LLMs to determine the impact of quantization on model quality across multiple benchmarks and real-world tasks."

Kein oberflächlicher Test – systematische Großstudie. Mehrere Evaluations-Frameworks:

• Akademische Benchmarks: OpenLLM Leaderboard v1/v2 (MMLU, HellaSwag, ARC usw.)
• Reale Aufgaben: Arena-Hard (simulierte Nutzerdialoge), HumanEval (Codegenerierung), HumanEval+ (Codetests)
• Textähnlichkeit: ROUGE, BERTScore, STS (semantische Ähnlichkeit)

Getestete Modelle von klein bis groß: Llama 2 7B, 13B, 70B; Mixtral 8x7B MoE; Qwen-Serie …

4.2 Kernergebnis: Genauigkeits-Wiederherstellung

Für llama.cpp-Quantisierung:

Quantisierungsstufe	Durchschnittliche Genauigkeits-Wiederherstellung	Bewertungs-Konfidenz
8-bit	>99 %	95 %-KI überlappt mit BF16
4-bit	98,9 %	Leicht unter Baseline, Abstand minimal
3-bit	~96 %	Deutlicher Rückgang, noch nutzbar

Kernfazit: 8-bit fast verlustfrei, 4-bit im Schnitt 98,9 % Genauigkeit.

Was bedeutet „95 %-KI überlappt mit BF16“? Statistisch unterscheidet sich 8-bit-Quantisierung nicht signifikant vom Original BF16 – Verteilungen der Testergebnisse liegen nahe beieinander.

4.3 Große vs. kleine Modelle: unterschiedliche Quantisierungseffekte

Interessanter Befund: Je größer das Modell, desto geringer der Einfluss der Quantisierung.

70B-Modelle mit 4-bit performen fast wie das Original. Bei 7B-Modellen ist der Rückgang spürbarer.

Grund: Große Modelle haben mehr Parameter und Redundanz – ein Präzisionsverlust lässt sich ausgleichen. Kleine Modelle haben weniger Spielraum.

Konsequenz:

• Große Modelle mit Q4: 70B Q4_K_M nahe am Original
• Kleine Modelle mit Q5+: Bei 7B und genug VRAM lieber Q5_K_M oder Q6_K

4.4 Community-Missverständnis: Warum viele „dümmer“ sagen

Online kursiert: Quantisierung verschlechtere die Qualität deutlich. Red Hat analysiert: Das Problem liegt oft in der Evaluationsmethode, nicht in der Quantisierung.

Viele testen nur einen akademischen Benchmark (z. B. MMLU) und schließen: „5 % weniger MMLU – Modell ist dümmer.“ Ein einzelner Benchmark bildet den Alltag nicht ab.

Red Hat nutzte mehrere Frameworks inklusive realer Aufgaben (Arena-Hard, HumanEval). Dort performen quantisierte Modelle fast wie Originale.

Im Alltag (Chat, Code, Zusammenfassung) merken Sie den Unterschied kaum. Nur in extremen akademischen Benchmarks messbar.

Meine Tests bestätigen das: Q4_K_M chatten und zusammenfassen flüssig; beim Coden gelegentlich Logikfehler – kein „dümmer“, sondern feinere Fehler. Mit Q5_K_M deutlich besser.

5. Ollama in der Praxis: Quantisierungsstufen wählen und ausführen

Theorie genug – zur Praxis.

5.1 Ollamas Standardverhalten

Mit ollama pull oder ollama run laden Sie offizielle Modelle – Standard: Q4_K_M.

ollama pull llama3

Lädt Llama 3 8B als Q4_K_M. Ollama hält Q4_K_M für das beste Preis-Leistungs-Verhältnis.

Andere Quantisierungsstufe gewünscht?

5.2 Bestimmte Quantisierung von Hugging Face laden

Ollama unterstützt direktes Laden von GGUF-Modellen von Hugging Face:

ollama run hf.co/{Benutzername}/{Repository}:{Quantisierungsstufe}

Beispiel – Llama 3.2 3B als Q8_0:

ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF:Q8_0

Lädt Q8_0 aus bartowskis Hugging-Face-Repository. bartowski ist dort sehr aktiv – viele Modelle und Quantisierungsstufen.

Auf Hugging Face nach GGUF suchen, z. B. Llama-3 GGUF.

Beliebte Quantisierungs-Repositories:

• bartowski: schnelle Updates, viele Modelle
• MaziyarPanahi: viele große Modelle (70B+)
• TheBloke: etablierter Publisher (einige Modelle nicht mehr aktiv)

5.3 Hardware-Empfehlungen

VRAM bestimmt die Quantisierungsstufe. Referenz für NVIDIA-GPUs:

VRAM	Empfohlenes Modell	Empfohlene Quantisierung	Hinweis
4 GB	3B	Q4_K_M	Kleines Modell, niedrige Quantisierung – knapp
6 GB	7B	Q4_K_M (eng)	3B mit Q5_K_M stabiler
8 GB	7B	Q5_K_M	8B mit Q4_K_M, Reserve einplanen
12 GB	7B	Q6_K / Q8_0	14B mit Q5_K_M
16 GB	14B	Q6_K	7B mit Q8_0, 30B MoE mit Q4_K_M
24 GB	30B+	Q5_K_M	70B mit Q4_K_M (Quantisierung nötig)

Hinweise:

• VRAM schwankt: Neben dem Modell brauchen KV Cache und Kontext-Puffer Speicher. 10–20 % Reserve einplanen.
• Kontextlänge: Lange Kontexte brauchen mehr KV Cache – Budget entsprechend erhöhen.
• MoE-Modelle: Mixtral 8x7B hat 47B Parameter, nutzt aber pro Inferenz nur einen Teil – weniger Speicher als dichte Modelle gleicher Parameterzahl.

5.4 Kernprinzip: kleines Modell + hohe Quantisierung schlägt großes + niedrige

Beispiel bei 8 GB VRAM:

• 7B Q5_K_M (~5,3 GB)
• 13B Q2_K (~5,0 GB)

Was performt besser?

7B Q5_K_M > 13B Q2_K.

13B Q2_K ist zu aggressiv quantisiert – trotz mehr Parametern leidet die Qualität. 7B Q5_K_M hält die Präzision und ist insgesamt besser.

Empfehlung: Erst Quantisierungsstufe sichern, dann Modellgröße. Lieber Q5 als Q3; lieber 7B Q5 als 13B Q2.

5.5 Praxis: meine RTX-3060-Konfiguration

Meine RTX 3060 mit 12 GB – typische Setups:

• Alltags-Chat: Llama 3.2 3B Q8_0 (genug Speicher, Qualität priorisiert)
• Code schreiben: Llama 3 8B Q5_K_M (Qualität zuerst)
• Große Modelle testen: Mixtral 8x7B Q4_K_M (MoE, 12 GB reichen gerade)

Q8_0 beim 3B-Modell fühlt sich flüssiger an als Q4_K_M beim 8B – vermutlich Vorteil kleines Modell + hohe Quantisierung. Beim Coden deutlich weniger Fehler mit Q5_K_M als Q4.

Fazit

Kernpunkte zusammengefasst.

Quantisierung ermöglicht große Modelle auf Consumer-Hardware. 70B brauchte 140 GB VRAM – quantisiert rund 40 GB. Damit können normale Nutzer große Modelle nutzen.

Genauigkeitsängste können Sie ablegen. Red Hats 500.000 Evaluations: 8-bit fast verlustfrei (>99 %), 4-bit 98,9 %. Im Alltag kaum spürbar.

Prinzipien für die Quantisierungswahl:

• Innerhalb des VRAM-Budgets höhere Quantisierung: Lieber Q5 als Q3
• Nach Aufgabe anpassen: Code mit Q5+, Chat mit Q4
• Große Modelle tolerieren niedrigere Quantisierung: 70B Q4 stabiler als 7B Q4

Mein Rat: Starten Sie mit Q5_K_M – Sweet Spot, nur ~20 % mehr Speicher als Q4, spürbar bessere Qualität.

Vertiefung in der Serie: Ollama-Einführung und Modelfile-Parameter im Detail. Im Modelfile lässt sich die Quantisierung anpassen – zusammen mit diesem Wissen flexiblere Modellkonfiguration.

Quantisierung ist keine Black Magic – ein Balanceakt zwischen Speicher und Qualität. Beherrschen Sie ihn, und Ihre GPU schafft größere Modelle und mehr Aufgaben.