Q4_K_M vs Q5_K_M vs Q6_K: Welche Ollama-Quantisierung ist sinnvoll?

Q4_K_M hat sich als inoffizieller Standard in der Ollama-Community etabliert. Wenn jemand fragt, welches Quantisierungsformat er laden soll, lautet die Antwort fast reflexartig: «Q4_K_M, guter Kompromiss.» Das stimmt für viele Fälle, aber es ist kein universeller Default. Wer längere deutsche Dokumente verarbeitet, RAG-Pipelines betreibt oder auf einem Mac mini mit genug Unified Memory sitzt, verschenkt Qualität. Dieser Artikel erklärt, was Q4_K_M, Q5_K_M und Q6_K wirklich voneinander trennt, wo die Unterschiede messbar werden, und wann ein Upgrade die Speicherkosten wert ist.

Was K-Quants von älteren Formaten trennt

GGUF-Quantisierung im llama.cpp-Ökosystem kennt mehrere Formatfamilien. Die älteren Formate Q4_0, Q4_1, Q5_0, Q5_1 und Q8_0 arbeiten mit klassischen blockweisen Integer-Formaten. Q8_0 gehört nicht zur K-Quant-Familie; es ist eine sehr hochwertige 8-Bit-Referenz ausserhalb dieser Familie. Die K-Quants umfassen Q2_K, die Q3_K-, Q4_K- und Q5_K-Varianten sowie Q6_K. Sie nutzen Superblöcke und zusätzliche Skalen- beziehungsweise Min-Parameter, um bei niedriger Bitbreite weniger Qualität zu verlieren.

Das «M» in Q4_K_M bezeichnet keine abstrakte Schichtqualität. Gemeint ist eine konkrete Mischung: Der ursprüngliche k-quants-PR quantisiert ausgewählte Tensoren, insbesondere attention.wv beziehungsweise attn_v und feed_forward.w2 beziehungsweise ffn_down, höher als den Rest. Bei Q4_K_M werden Teile dieser Tensoren mit Q6_K behandelt, während die übrigen Gewichte überwiegend Q4_K nutzen. Das ist der praktische Grund, warum Q4_K_M etwas grösser ist als Q4_K_S, aber meist robuster.

Das Ergebnis ist in Messungen sichtbar, aber man muss die Quelle sauber benennen. Der ursprüngliche llama.cpp-k-quants-PR zeigt auf LLaMA-7B für Q4_K_M eine Perplexität von 5,9601 gegenüber 5,9066 bei FP16; Q6_K liegt mit 5,9110 sehr nahe an FP16. Das sind kleinere Deltas als viele Community-Tabellen später suggerieren. Für moderne Downstream-Benchmarks ist die Studie von Uygar Kurt (arXiv, Januar 2026) relevanter: Sie testet 13 GGUF-Konfigurationen auf Llama-3.1-8B-Instruct, darunter K-Quants und Legacy-Formate, auf GSM8K, HellaSwag, MMLU, IFEval und TruthfulQA. Einschränkung: Getestet wurde ein 8B-Modell in englischer Sprache. Übertragbarkeit auf andere Modellgrössen und andere Sprachen ist nicht direkt gegeben.

Was die Stufen wirklich unterscheidet

Die wichtigsten Stufen für Ollama-Nutzer im Vergleich. Q8_0 steht bewusst als Referenz daneben, ist aber kein K-Quant:

Q4_K_M ist der kleinste der hier verglichenen K-Quant-Stufen, aber nicht der kleinste K-Quant insgesamt; Q2_K und Q3_K sind kleiner und deutlich aggressiver. Q5_K_M reduziert das Perplexitätsdelta gegenüber Q4_K_M bei moderatem Speicherzuwachs. Q6_K kommt Q8_0 so nah, dass der Restunterschied in vielen Praxis-Setups nicht mehr wahrnehmbar ist. Q8_0 ist eine sehr hochwertige Referenz, aber der Speicherbedarf liegt rund 74 Prozent über Q4_K_M.

Die Benchmark-Unterschiede auf Downstream-Tasks sind messbar, aber nicht linear. In Kurts Tabelle liegt Q4_K_M im Durchschnitt knapp unter F16, Q5_K_M und Q6_K ebenfalls nahe an der Baseline, Q8_0 fast exakt daran. Gleichzeitig zeigt die Tabelle, dass Perplexität nicht alles erklärt: Q5_0 ist ein Legacy-Format und erreicht in dieser Auswertung den höchsten Durchschnittswert, während mehrere 5-Bit-Varianten fast gleiche Perplexität, aber unterschiedliche GSM8K- und IFEval-Werte zeigen. Kurts Pareto-Analyse nennt Q5_0 und Q4_K_S als Frontier-Punkte und stuft Q4_K_M sowie Q5_K_M formal als dominiert ein; der Q5_0-Vorsprung wird im Paper allerdings selbst als möglicherweise rauschbedingt eingeordnet, und Ollamas Model-Library liefert in der Praxis vor allem K-Quant-Varianten aus. Das stützt die eigentliche Aussage besser als eine simple Rangliste: Wer lokal produktiv arbeitet, braucht neben Dateigrösse und PPL immer den Blick auf die eigene Aufgabe.

Zum Verarbeitungsdurchsatz: Kleinere Quants sparen Speicher und können schneller sein, aber das skaliert nicht monoton mit der Bitbreite. Kurts Throughput-Tabelle zeigt zum Beispiel Q5_K_M teils schneller als Q4_K_M. Auf Apple Silicon ist deshalb weniger die Bandbreite das zentrale Argument, sondern die Kapazität: viel Unified Memory erlaubt höhere Quants oder grössere Modelle, ohne dass ein lokales Setup sofort an die Speichergrenze läuft. Eine dedizierte GPU, deren Modell vollständig im VRAM liegt, hat keinen PCIe-Engpass; problematisch wird es erst, wenn Modellteile ausgelagert oder zwischen Speicherbereichen verschoben werden müssen.

Wo Q4_K_M tatsächlich ausreicht

Klarer Anwendungsfall: kurze englischsprachige Prompts, Kontext unter 4K Token, kreative Texte oder Zusammenfassungen ohne strenge Faktentreue. Hier ist Q4_K_M eine vertretbare Wahl. Das Modell antwortet flüssiger, passt in weniger RAM und lässt auf Systemen mit knappem Speicher grössere Modelle laufen, die sonst nicht startfähig wären. Ein gutes 14B-Modell in Q4_K_M kann trotz stärkerer Quantisierung besser sein als ein schwächeres 8B-Modell in Q8_0, wenn das grössere Modell die Aufgabe grundsätzlich besser beherrscht.

Das ist der eigentliche Trade-off: Qualitätsstufe innerhalb desselben Modells erhöhen, oder Parameterzahl des Modells erhöhen. Wer auf einem System mit 16 GB RAM arbeitet, kann etwa zwischen einem 8B-Modell in Q6_K und einem 14B-Modell in Q4_K_M abwägen. Letzteres ist oft die klügere Entscheidung, solange die Aufgabe kurze englische Kontexte umfasst.

Wo Q4_K_M erkennbar verliert: Long-Context, RAG, Deutsch

Hier wird der Default problematisch. Eine peer-reviewte Studie von Mekala et al. (EMNLP 2025) hat Quantisierung auf Long-Context-Aufgaben untersucht und dabei Genauigkeitsverluste von bis zu 59 Prozent bei einzelnen 4-Bit-Setups gemessen. Die Studie testete fünf Methoden: FP8, GPTQ-int8, AWQ-int4, GPTQ-int4 und BNB-nf4. GGUF-K-Quants wurden nicht direkt getestet. Ausserdem beginnen die gemessenen Long-Context-Inputs bei 64K Token; eine Schwelle von 16K ist daher eine vorsichtige Praxis-Extrapolation, keine direkt gemessene Grenze. Die Evidenz rechtfertigt trotzdem eine konservative Empfehlung: Wer sehr lange Dokumente oder RAG-Pipelines mit langen Retrievals betreibt, sollte Q5_K_M oder Q6_K bevorzugen und den eigenen Workload testen.

Der Sprach-Effekt ist ebenfalls aus der EMNLP-Studie belegt. Nicht-englische Aufgaben verlieren bei 4-Bit-Methoden überproportional. Für deutschsprachige Texte bedeutet das, dass Q4_K_M früher in Drift-Territory gerät als bei Englisch. Wer auf einem Mac mini mit Ollama deutschsprachige Dokumente zusammenfasst, sollte diesen Punkt explizit berücksichtigen. Der Aufsatz zu Quantisierungsrisiken in lokalen KI-Setups beschreibt dieses Risikoprofil ausführlicher; mehr dazu im DeepDive zu LLM-Inferenz und Quantisierung.

Ein weiterer kritischer Punkt: RAG-Pipelines stellen besondere Anforderungen an Instruktionstreue. Das Modell soll aus einem vorgegebenen Kontext korrekt zitieren und nicht halluzinieren. Die IFEval-Werte in Kurts Tabelle sind nicht monoton: Q4_K_M liegt dort nicht einfach unter Q6_K, und Q5_0 schneidet besonders stark ab. Genau das ist der Punkt: PPL allein reicht nicht als Auswahlkriterium. Für RAG-Anwendungen ist Q5_K_M ein sinnvoller Startpunkt; Q6_K ist die konservativere Wahl, wenn Speicher vorhanden ist.

Entscheidungsmatrix nach RAM und Aufgabe

Die Entscheidung hängt von drei Parametern ab: verfügbarem RAM (oder VRAM), Aufgabentyp und Sprachkontext. Als Orientierung:

16 GB RAM oder weniger: Q4_K_M ist der pragmatische Default für englische Kurzkontexte. Bei deutschen Texten oder RAG möglichst auf Q5_K_M wechseln, auch wenn das die Modellgrösse nach unten zwingt.

24 GB RAM: Q5_K_M ist für viele 8B- und 14B-Modelle erreichbar. Q6_K für 8B-Modelle ist in Reichweite und empfehlenswert, wenn Instruktionstreue oder längere Kontexte wichtig sind.

32 GB RAM und mehr (z.B. Mac mini M4 Pro oder Mac Studio mit M4 Max): Q6_K für 14B-Modelle oder Q5_K_M für 30B-Klasse-Modelle sind realistisch. Q8_0 lohnt nur, wenn der Speicher nicht anderweitig gebraucht wird; der Qualitätszuwachs gegenüber Q6_K ist in den meisten Praxis-Aufgaben marginal. Das Setup für Ollama auf dem Mac mini zeigt, welche Modellgrössen auf welcher Ausstattung sinnvoll laufen.

Zur Frage Q6_K vs. Q8_0: Die Perplexitätsdifferenz zwischen Q6_K (+0,03) und Q8_0 (+0,01) gegenüber F16 ist sehr klein. Wer Q6_K nutzt und keine messbaren Qualitätsprobleme hat, muss nicht zu Q8_0 wechseln, ausser Speicher ist im Überfluss vorhanden. Q8_0 ist relevanter für Benchmarking-Zwecke oder als nahezu verlustfreie Baseline beim Modellvergleich.

Abgrenzung: K-Quants vs. GPTQ, AWQ, FP8

Ein häufiger Verständnisfehler: K-Quants sind GGUF-Formate aus dem llama.cpp-Ökosystem und laufen auf CPU oder via Metal/CUDA aus einer einzigen Datei. GPTQ, AWQ, INT8 und FP8 sind andere Quantisierungsansätze, die typischerweise auf GPU-Servern mit PyTorch-basierten Frameworks wie vLLM oder HuggingFace Transformers eingesetzt werden. Die Paper-Lage für GPTQ-int4, AWQ-int4 und FP8 ist deutlich umfangreicher als für K-Quants. Wer in einem Datacenter-Setup mit vLLM arbeitet, trifft andere Entscheidungen als Ollama-Nutzer auf Consumer-Hardware. Die Architekturen sind nicht einfach übertragbar.

IQ4_XS, IQ4_NL und andere I-Quants sind ein eigenes Thema innerhalb des GGUF-/llama.cpp-Umfelds. Sie können bei sehr knappen Speicherbudgets interessant sein, beantworten aber eine andere Frage als dieser Artikel: maximale Kompression statt robuste Default-Auswahl zwischen Q4_K_M, Q5_K_M und Q6_K. Deshalb werden sie hier bewusst ausgeklammert.

Für den Ollama-Alltag auf Mac, Linux-Consumer oder Windows-PC sind K-Quants der relevante Rahmen. Alles andere ist ein anderer Stack. Mehr zu den Unterschieden zwischen Inferenz-Frameworks im Vergleich von vLLM, llama.cpp, Ollama und TensorRT-LLM.