Wichtigste Punkte
Stand Mai 2026: Q8_0 ist ~99 % der vollpräzisen Qualität. Q4_K_M ist ~92 %. Der 7-Punkte-Abstand ist unsichtbar bei Chat, Coding und Zusammenfassung — drei Aufgaben, die 95 % der lokalen LLM-Nutzung abdecken. Q8_0 zieht nur bei langem faktischem Abruf, mehrstufiger Mathematik und Code vor, der exakte Syntax über 500+ Zeilen erfordert.
Q4_K_M ist der richtige Standard, weil die zusätzliche Qualität von Q8_0 nur in Randfällen auftaucht: lange Textgenerierung mit exaktem Faktenrückruf oder mathematisches Schlussfolgern, das höhere Präzision erfordert. Für alles andere entspricht Q4_K_M Q8_0 in der Praxis.
Wenn Sie bereits Q4_K_M verwenden und Ihre Ergebnisse falsch erscheinen, liegt das Problem fast nie an der Quantisierung — es liegt an der Modellgröße oder Prompt-Struktur.
Die folgende Tabelle vergleicht Q4_K_M und Q8_0 für ein 7B-Modell. Beide Formate funktionieren mit Ollama, LM Studio und llama.cpp ohne spezielle Konfiguration.
Für Kontext zu Q4_K_M und K-Quant-Kompression, siehe den Q4_K_M Erklärungsleitfaden. Für die vollständige Quantisierungsreferenz, siehe Quantisierungsstufen verglichen.
Drei Aufgaben offenbaren Q4_K_Ms Qualitätslücke: Abruf langer Dokumente (50+ Seiten), mehrstufige Mathematik mit Zwischenzustand und Code-Generierung über 300+ Zeilen. Für diese verhindert Q8_0s höhere Präzision die kleinen Drift-Fehler, die sich über lange Ausgaben akkumulieren. Für alles andere — Chat, Code unter 200 Zeilen, Q&A, Zusammenfassung — ist die Lücke unsichtbar. Für eine Auffrischung, siehe was Q4_K_M bedeutet.
| Metrik | Q4_K_M | Q8_0 |
|---|---|---|
| Dateigröße (7B-Modell) | ~4,1 GB | ~7,7 GB |
| VRAM benötigt (7B) | 5–6 GB | 8–9 GB |
| Qualität vs. vollpräzise | ~92 % | ~99 % |
| Am besten für | 6–8 GB VRAM | 12+ GB VRAM |
ollama pull llama3:8b-q4_K_M und ollama pull llama3:8b-q8_0 sind separate Downloads. Sie wechseln, indem Sie den Tag in ollama run angeben.