GGUF-Quantisierung für Ollama: Was bedeuten Q4_K_M, Q8_0 und IQ4_XS und welche sollte man für seine Hardware wählen

Wenn Sie Modelle über Ollama oder andere lokale Runtimes ausführen, sind Sie wahrscheinlich schon auf Bezeichnungen wie Q4_K_M, Q8_0 oder IQ4_XS gestoßen. Was bedeuten sie? Welche sollten Sie wählen? Warum ist Q4 oft besser als Q8 – und wann ist das nicht der Fall?

In diesem Artikel erkläre ich Quantisierung ohne unnötige Theorie – mit Tabellen, echten Zahlen und Beispielen aus meinen eigenen Projekten auf einem MacBook M1 mit 16 GB.

Was ist die Quantisierung eines Sprachmodells – einfach erklärt

Ein Sprachmodell ist eine Sammlung von numerischen Gewichten. Jedes Gewicht bestimmt, wie ein Neuron auf Eingabedaten reagiert. In voller Präzision (FP16) belegt jedes Gewicht 16 Bit – zwei Bytes. Ein Modell mit 7 Milliarden Parametern wiegt dann etwa 14 GB.

Quantisierung ist die Reduzierung der Anzahl der Bits pro Gewicht. Q8 – 8 Bit, Q4 – 4 Bit, Q2 – nur 2. Je weniger Bits, desto kleiner die Datei und desto weniger Speicher wird für den Betrieb benötigt.

Eine gute Analogie ist JPEG im Vergleich zu RAW-Fotos. RAW – maximale Detailgenauigkeit, aber 25 MB groß. JPEG mit 85% Qualität – 3 MB, und die meisten Leute sehen keinen Unterschied. Aber wenn Sie das Bild skalieren oder stark zuschneiden – werden Artefakte sichtbar. Dasselbe gilt für Modelle: In einem normalen Chat sind Q4 und Q8 praktisch identisch, aber in Mathematik oder komplexem Code ist der Unterschied bereits spürbar.

Hauptgedanke: Quantisierung ist Komprimierung, keine Verschlechterung. Eine richtig gewählte Quantisierung behält 92–95 % der Qualität bei einer 3–4-fachen Größenreduzierung.

Praxisbeispiel: In meinem Projekt AskYourDocs verarbeitet ein RAG-System Unternehmensdokumente über lokales Ollama auf einem M1. Das Qwen3-14B-Modell in Q4_K_M belegt ~8,5 GB und passt in den 16 GB Unified Memory – es bleibt Platz für Kontext und das Embedding-Modell. In FP16 würde es ~28 GB belegen und einfach nicht starten.

Warum Quantisierung für lokales KI benötigt wird

Ohne Quantisierung ist lokales KI auf Consumer-Hardware schlichtweg unmöglich. Hier sind die Zahlen:

• Llama 3.3 70B in FP16 – ~140 GB. Solche Hardware kostet Zehntausende von Dollar.
• Dasselbe Llama 3.3 70B in Q4_K_M – ~40 GB. Läuft auf einem Mac Studio oder zwei RTX 4090.
• Ein 7B-Modell in FP16 – 14 GB. In Q4_K_M – 4,1 GB. Läuft sogar auf einer Grafikkarte mit 6 GB VRAM – welche Modelle öffnen sich auf 8 und 16 GB RAM.

Neben der Speichereinsparung bietet Quantisierung auch einen schnelleren Start: Eine kleinere Datei wird schneller in den Speicher geladen. Und dank des geringeren Datenvolumens, das gelesen werden muss, beschleunigt sich auch die Token-Generierung (mehr dazu im Abschnitt über Q4 vs Q8).

Hauptgedanke: Quantisierung ist kein Kompromiss, sondern der einzige Weg, moderne LLMs auf einem Heim-PC oder Laptop auszuführen.

Wo es angewendet wird: Lokale RAG-Systeme, persönliche Assistenten, autonome Agenten ohne Cloud, Unternehmenswerkzeuge auf isolierten Servern – überall dort, wo das Modell ohne API-Schlüssel und ohne Datenübertragung nach außen laufen soll.

Was ist das GGUF-Format und warum hat es sich durchgesetzt

GGUF (GPT-Generated Unified Format) ist ein Dateicontainer für quantisierte Modelle. Er wurde von Georgi Gerganov, dem Autor von llama.cpp, im Jahr 2023 als Ersatz für das alte GGML-Format entwickelt.

Der Hauptvorteil von GGUF ist seine Eigenständigkeit: Eine einzige Datei enthält alles, was zum Ausführen benötigt wird:

• quantisierte Modellgewichte;
• Tokenizer und seine Konfiguration;
• Architektur-Metadaten;
• Hyperparameter.

Mit dem alten GGML mussten separate Dateien für Gewichte und Konfigurationen aufbewahrt werden, was die Distribution erschwerte. GGUF löste dieses Problem und wurde schnell zum Standard: Heute unterstützen es Ollama, LM Studio, Open WebUI, Jan, KoboldCpp und die meisten anderen lokalen Runtimes.

Persönlich nutze ich für die tägliche Arbeit mit GGUF-Modellen LM Studio – auf meinem MacBook M1 ist die Generierung spürbar schneller als bei Ollama, und die Benutzeroberfläche ist praktisch, um schnell zwischen Modellen und Quantisierungen zu wechseln. Wenn Sie es noch nicht ausprobiert haben – ich empfehle es als Ausgangspunkt.

Kurz gesagt: GGUF ist keine Art der Quantisierung, sondern ein Container. Quantisierung (Q4, Q8 usw.) ist das, was sich im GGUF-Container befindet.

Beispiel: Wenn Sie ollama pull qwen3:14b ausführen, lädt Ollama standardmäßig eine GGUF-Datei mit Q4_K_M-Quantisierung herunter. Sie können aber auch explizit eine andere angeben: ollama run hf.co/bartowski/Qwen3-14B-GGUF:Q8_0.

Von FP16 bis Q2: Quantisierungsstufen in einer Tabelle

Jede Quantisierungsstufe ist ein Kompromiss zwischen Qualität und Größe. So sieht ein 7B-Modell auf verschiedenen Stufen aus:

Die Dateigrößenangaben stammen aus realen GGUF-Messungen von llama.cpp. Die Qualitätsangaben in Prozent sind ungefähre Perplexitätswerte relativ zu FP16.

Das Wichtigste hier: Der Qualitätsunterschied zwischen Q4_K_M und Q8_0 beträgt etwa 4 %. Der Größenunterschied beträgt fast das Doppelte. Deshalb gewinnt Q4_K_M in den meisten Szenarien.

Beispiel: Eine Studie von Anfang 2026 bestätigt, dass logisches Denken sehr widerstandsfähig gegen Quantisierung ist, während Arithmetik unter Q4 zu degradieren beginnt. Für normale Chats und Übersetzungen ist Q4 absolut ausreichend.

Was bedeuten Q4_K_M, Q5_K_M, Q8_0 – Entschlüsselung der Suffixe

Dies ist eine der häufigsten Fragen von Anfängern, und fast kein Artikel erklärt sie richtig. Lassen Sie uns das im Detail aufschlüsseln.

Struktur des Namens: Q[Bits]_[Methode]_[Variante]

Q4 – Anzahl der Bits pro Gewicht (ungefähr). Nicht immer eine ganze Zahl: Q4_K_M verwendet tatsächlich ~4,5 Bit durch gemischte Präzision.

_K – K-Quants. Dies ist ein intelligenteres Quantisierungsschema, das Bits ungleichmäßig verteilt: Schichten, die die Qualität am stärksten beeinflussen (Attention, Output Projection), erhalten mehr Bits, der Rest weniger. Dies ermöglicht es, bei gleicher durchschnittlicher Größe eine höhere Qualität als beim alten gleichmäßigen Ansatz zu erhalten.

_M / _S / _L – Größe der Variante innerhalb einer Stufe:

• _S (Small) – minimale Größe in seiner Klasse, etwas geringere Qualität.
• _M (Medium) – Balance zwischen Größe und Qualität. Dies ist die Standardempfehlung.
• _L (Large) – maximale Qualität in seiner Klasse, etwas größere Datei.

_0 – altes gleichmäßiges Schema (z. B. Q4_0, Q8_0). Alle Gewichte werden gleichmäßig ohne Prioritäten quantisiert. Q8_0 ist aufgrund seiner Einfachheit weit verbreitet, aber Q4_0 wird bei gleicher Größe bereits praktisch von Q4_K_M verdrängt.

Vergleichstabelle beliebter Quantisierungen

Merken Sie sich: Das Suffix _M im Namen ist der wichtigste Buchstabe. Er bedeutet, dass das Modell gemischte Präzision verwendet und die wichtigsten Schichten mit höherer Detailgenauigkeit speichert.

Beispiel: Wenn Sie auf Hugging Face zwei Dateien sehen – model-Q4_0.gguf und model-Q4_K_M.gguf von ungefähr gleicher Größe – nehmen Sie Q4_K_M. Das alte Q4_0-Schema liefert bei gleichem Speicherplatz eine merklich schlechtere Qualität.

IQ-Quantisierungen: Was ist IQ4_XS und warum ist es 2026 wichtig

Dies ist ein Thema, das in fast keinem Artikel behandelt wird. Dabei sind IQ-Quanten bereits in den Standard-Downloads von bartowski aufgetaucht und werden in der llama.cpp-Community intensiv diskutiert.

Was ist eine ImMatrix (Importance Matrix)

Standardquantisierung verarbeitet alle Gewichte gleich. Importance Matrix (imatrix) ist eine Voranalyse: Kalibrierungsdaten werden durch das Modell geleitet und es wird gemessen, welche Gewichte die Ausgabequalität am stärksten beeinflussen. Diese Gewichte werden vorsichtiger quantisiert, der Rest aggressiver.

Ergebnis: Eine kleinere Datei bei ähnlicher oder sogar besserer Qualität als bei K-Quanten desselben Niveaus.

IQ4_XS vs. Q4_K_M: Praktischer Vergleich

*IQ4_XS bietet nur dann einen Vorteil, wenn eine qualitativ hochwertige imatrix-Datei verwendet wird. Ein schlecht kalibriertes IQ-Quant kann hinter Q4_K_M zurückbleiben.

Für ein 70B-Modell beträgt der Unterschied zwischen IQ4_XS und Q4_K_M 3–4 GB, was entscheidend dafür sein kann, ob das Modell überhaupt in den Speicher passt.

Wo man geprüfte IQ-Quanten findet

Nicht alle GGUF-Dateien auf Hugging Face sind gleich. Drei geprüfte Quellen:

• bartowski – der aktivste und zuverlässigste Uploader, enthält imatrix.
• mradermacher – breite Modellabdeckung.
• TheBloke – klassisches Archiv, 2026 weniger aktiv, aber immer noch zuverlässig.

Hauptgedanke: IQ4_XS ist nicht immer besser als Q4_K_M. Aber wenn Sie ein größeres Modell in denselben Speicher bekommen müssen – IQ4_XS bietet 3–4 GB Gewinn bei ähnlicher Qualität.

Praktisches Szenario: Ich habe ein MacBook M1 mit 16 GB. Qwen3-14B in Q4_K_M belegt ~8,5 GB – passt. Aber wenn man nomic-embed-text (~280 MB) und einen Kontext von 8K hinzufügt – beginnt das Swapping. IQ4_XS desselben Qwen3-14B belegt ~7,9 GB, und das System atmet freier.

In meiner Arbeit verwende ich eine zweistufige Strategie: für Tests, das Schreiben von Artikeln und normale Aufgaben – ein leichteres Modell in Q4_K_M, das schnell startet und das System nicht belastet. Aber wenn der Agent externe Werkzeuge aufruft oder komplexe Logik mit Tool Calling durchführt – wechsle ich zu einem stärkeren Modell in Q5_K_M oder Q6_K, wo die Genauigkeit des JSON-Schemas und die Schrittfolge entscheidend sind. Q4 verliert hier manchmal die Logik mitten in der Kette.

Wie viel RAM und VRAM wird benötigt: Tabelle und Formel

Hier ist eine praktische Tabelle mit den Größen beliebter Modelle in verschiedenen Quantisierungen. Die Daten basieren auf Messungen von willitrunai.com und offiziellen GGUF-Dateien:

Formel für eigene Berechnungen

RAM (GB) = Parameter (Milliarden) × Bytes_pro_Gewicht × 1.2

Bytes pro Gewicht:
  FP16   → 2.0
  Q8_0   → 1.0
  Q5_K_M → 0.69
  Q4_K_M → 0.55
  Q3_K_M → 0.41

Zusätzlich:
  + 1–2 GB für KV-Cache (bei 4K-Kontext)
  + 2 GB für OS und andere Prozesse

Quelle der Formel: localaimaster.com.

Berechnungsbeispiel: Qwen3-14B in Q4_K_M → 14 × 0,55 × 1,2 = 9,24 GB für Gewichte + ~1,5 GB KV-Cache bei 4K-Kontext = mindestens 11–12 GB VRAM benötigt.

Kurz gesagt: Die Dateigröße sind nur die Gewichte. Addieren Sie den KV-Cache (abhängig vom Kontext) und 2 GB für das System – und Sie erhalten den tatsächlichen Speicherbedarf.

Wichtig für MacBook Apple Silicon: Unified Memory wird zwischen CPU und GPU geteilt, daher sind etwa 75–80 % des Gesamtspeichers tatsächlich verfügbar. Auf einem M1 mit 16 GB sind das ungefähr 12–13 GB effektiv für das Modell.

Welche Quantisierung für Ihre Hardware wählen

Kurze praktische Spickzettel:

Was tun, wenn das Modell nicht vollständig in den VRAM passt

Wenn das Modell größer als der VRAM ist, verschieben llama.cpp und Ollama automatisch einen Teil der Schichten auf die CPU. Dies wird als teilweises Offloading (Layer Offloading) bezeichnet.

Wann Q4_K_S anstelle von Q4_K_M wählen

Beim teilweisen Offloading durchläuft jede Schicht, die auf die CPU verschoben wird, die PCIe-Schnittstelle. Eine kleinere Datei bedeutet weniger Datenverkehr. Daher wird bei teilweisem Offloading Q4_K_S empfohlen – es ist etwa 8 % kleiner als Q4_K_M bei geringfügigen Qualitätsunterschieden.

KV-Cache-Quantisierung: Ein versteckter Speichergewinn

Wenige wissen, dass neben der Quantisierung der Modellgewichte auch der KV-Cache quantisiert werden kann. Dies ist der Speicher, den das Modell zur Speicherung des Kontexts während der Generierung verwendet.

In Ollama wird dies über eine Umgebungsvariable gesteuert:

OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve

Ergebnisse realer Messungen basierend auf llama.cpp Discussion #20969:

Fazit aus der Tabelle: q8_0 KV-Cache ist ein fast kostenloser Gewinn: doppelt so wenig Speicher ohne spürbaren Qualitätsverlust. q4_0 KV-Cache ist bei langem Kontext gefährlich – bei 110K Tokens sinkt die Generierungsgeschwindigkeit um 37 %, und die Qualität der strukturierten Ausgabe und des Codes verschlechtert sich.

Hauptgedanke: Wenn Sie knapp bei Speicher sind, probieren Sie zuerst OLLAMA_KV_CACHE_TYPE=q8_0. Dies bietet eine Einsparung von ~47 % des KV-Speichers praktisch ohne Verluste. Erst danach sollten Sie eine geringere Gewichtungsquantisierung in Betracht ziehen.

Besonders wichtig hierbei: in RAG-Systemen wie AskYourDocs, wo große Dokumentenfragmente in den Kontext geladen werden – kann der KV-Cache genauso viel Speicher belegen wie das Modell selbst.

Warum Q4_K_M häufiger als Q8 empfohlen wird

Auf den ersten Blick ist die Logik einfach: Q8 – bessere Qualität. Aber es gibt drei Argumente für Q4_K_M, die normalerweise nicht erwähnt werden.

1. Q8_0 ist langsamer als Q4_K_M

Die LLM-Generierung wird durch die Speicherbandbreite begrenzt, nicht durch die Berechnungen. Die GPU verbringt mehr Zeit mit dem Lesen von Gewichten aus dem VRAM als mit der Matrixmultiplikation. Eine größere Datei bedeutet mehr Bytes, die pro Token gelesen werden müssen.

Laut offiziellem README von llama.cpp für Llama-3.1-8B: Q8_0 generiert Tokens 29 % langsamer als Q4_K_M.

2. Größeres Modell in Q4 > kleineres Modell in Q8

Dies ist die wichtigste Regel für die Wahl der Quantisierung, die die meisten ignorieren:

70B in Q4 übertrifft 7B in FP16 bei ähnlicher Dateigröße erheblich.

Die Strategie ist richtig: Nehmen Sie zuerst das größtmögliche Modell, das in den Speicher passt, und reduzieren Sie erst dann die Genauigkeit. Nicht umgekehrt.

3. Q4_K_M behält 92–95 % der FP16-Qualität

Für alltägliche Chats, Übersetzungen, Zusammenfassungen und die meisten Textaufgaben – 5 % Qualitätsunterschied sind praktisch nicht spürbar. Deshalb ist Q4_K_M die Standardquantisierung von Ollama: Ollama wählt diese Option bereits standardmäßig. Sie müssen sich keine Gedanken darüber machen – starten Sie einfach das Modell.

Das Wichtigste hier: Q4_K_M gewinnt nicht, weil Q8 schlecht ist – sondern weil der freigewordene Speicher es ermöglicht, ein doppelt so großes Modell zu starten, was zu einem größeren Qualitätsschub führt.

Beispiel mit Zahlen: Auf einer RTX 4070 mit 12 GB – die Wahl zwischen Qwen3-7B Q8_0 (~7,7 GB) und Qwen3-14B Q4_K_M (~8,5 GB). Die zweite Option liefert in realen Tests spürbar bessere Ergebnisse bei komplexen Aufgaben trotz geringerer Quantisierung.

Wann es sich lohnt, für Q5, Q6 oder Q8 zu bezahlen

Es gibt Szenarien, in denen ein höheres Quantisierungsniveau wirklich gerechtfertigt ist:

Code und strukturierte Ausgabe → Q5_K_M oder Q6_K

Die Code-Generierung erfordert die genaue Einhaltung der Syntax. Eine fehlende Klammer oder ein falscher Einzug – und der Code kompiliert nicht. Q5_K_M reduziert die Häufigkeit von Syntaxfehlern im Vergleich zu Q4 spürbar.

Mathematik und Reasoning → Mindestens Q5_K_M

Studien aus dem Jahr 2026 bestätigen: Arithmetisches Reasoning verschlechtert sich drastisch unter Q4. Für Aufgaben mit schrittweisen Berechnungen, insbesondere mit langen logischen Ketten – Q5_K_M oder Q6_K.

RAG-Systeme mit langem Kontext → Q5_K_M

Beim Laden großer Dokumente in den Kontext muss das Modell Fakten vom Anfang des Textes bis zum Ende der Antwort "behalten". Q4 kommt damit zurecht, aber Q5_K_M ist bei einem Kontext von 16K+ zuverlässiger.

Agenten mit Tool Calling → Q5_K_M+

Agenten müssen das JSON-Schema für den Aufruf von Tools genau einhalten. Q4 generiert unter Last manchmal ungültiges JSON. In meinem Agentensystem bin ich deshalb auf Q5_K_M umgestiegen.

Kleine Modelle (3B–7B) mit viel VRAM → Q8_0

Wenn Sie 16+ GB VRAM haben und ein kleines 7B-Modell ausführen – ist Q8_0 gerechtfertigt: Das Modell passt vollständig hinein, und der Qualitätsgewinn ist spürbar.

Hauptgedanke: Erhöhen Sie die Quantisierung nicht "um der Qualität willen", sondern für eine bestimmte Aufgabe. Für Code und Agenten – mindestens Q5_K_M. Für Chat und Übersetzung – Q4_K_M reicht aus.

Verschlechtert die Quantisierung die Antwortqualität – reale Beispiele

Ich habe Q4_K_M und Q8_0 auf Qwen3-14B über Ollama auf M1 verglichen. Hier sind die Ergebnisse für verschiedene Aufgabentypen:

Merken Sie sich: 80 % der Aufgaben erfordern kein Q8. Aber wenn Ihre Aufgabe – Code, Agenten oder Mathematik ist – wird Q5_K_M eine spürbare Verbesserung sein, auch ohne auf Q8 umzusteigen.

Wichtiger Hinweis: Der Unterschied zwischen Q4_K_M und Q8_0 bei einem 14B-Modell ist geringer als der Unterschied zwischen 7B Q8_0 und 14B Q4_K_M. Die Modellgröße ist wichtiger als die Quantisierungsstufe – wählen Sie immer ein größeres Modell mit geringerer Quantisierung, wenn Sie die Wahl haben.

GGUF vs GPTQ vs AWQ vs EXL2: Was wählen in 2026

GGUF ist nicht das einzige Quantisierungsformat. Hier ist das vollständige Bild:

Mehr Details zu GPTQ und AWQ: LLM Quantization Guide 2026 — tensorrigs.com.

Wenn Sie ein Heimanwender oder Entwickler auf einem MacBook/PC sind – GGUF Q4_K_M über Ollama ist das einzige Format, über das Sie nachdenken müssen. GPTQ und AWQ – für GPU-Server und Produktionsinfrastruktur.

Wo was angewendet wird: GGUF – lokales Dev, RAG-Prototypen, persönlicher Assistent. AWQ – Produktions-API, vLLM-Server mit Dutzenden paralleler Anfragen. EXL2 – Enthusiasten, die das Maximum aus einer einzelnen RTX 4090 herausholen.

So laden Sie die richtige GGUF-Datei von Hugging Face herunter

Ich zeige es anhand meines eigenen Beispiels – ich lade regelmäßig Modelle von hier herunter. Sie können sich die Details auf der Seite bartowski/Qwen_Qwen3-14B-GGUF ansehen – dort finden Sie alle Quantisierungen mit Größenangaben und Empfehlungen:

Schritt 1. Öffnen Sie die Modellseite auf Hugging Face. Suchen Sie nach Repositories von bartowski, mradermacher oder TheBloke – sie haben imatrix und geprüfte Qualität.

Schritt 2. Filtern Sie im Tab "Files and versions" nach der Dateiendung .gguf.

Schritt 3. Bestimmen Sie die benötigte Quantisierung anhand der obigen Tabelle. Für die meisten ist Qwen3-14B-Q4_K_M.gguf geeignet.

Schritt 4. Laden Sie direkt über Ollama herunter:

ollama run hf.co/bartowski/Qwen3-14B-GGUF:Q4_K_M

Oder über die Hugging Face CLI:

pip install huggingface_hub
huggingface-cli download bartowski/Qwen3-14B-GGUF --include "Qwen3-14B-Q4_K_M.gguf"

Überprüfen Sie die Quantisierung eines bereits heruntergeladenen Modells in Ollama:

ollama show qwen3:14b

Suchen Sie in der Ausgabe nach der Zeile quantization – dort wird der Typ angegeben (z. B. Q4_K_M).

Merken Sie sich: Laden Sie keine GGUF-Dateien von unbekannten Autoren herunter, ohne die Modellkarte zu überprüfen. Ein schlechter imatrix macht IQ-Quanten schlechter als normale K-Quanten. Drei zuverlässige Quellen: bartowski, mradermacher, TheBloke.

Typische Fehler bei der Auswahl der Quantisierung

• Q2 oder Q3 wegen der geringen Größe wählen. Unter Q4 bricht die Qualität ungleichmäßig zusammen: Das Modell kann kohärent sprechen, aber mitten in der Antwort die Logik verlieren. Es ist besser, ein kleineres Modell in Q4 zu wählen als ein größeres in Q2.
• Q8 auf Hardware ohne VRAM-Reserve laden. Q8 benötigt nicht nur mehr Speicher, sondern ist auch langsamer. Wenn das Modell gerade so hineinpasst, führt Q8 zu Swapping und tatsächlich weniger Tokens/s als Q4_K_M.
• Modellparameter und Quantisierung verwechseln. "14B Q4" und "7B Q8" sind sehr unterschiedliche Dinge. Die Parameter (7B/14B/70B) beeinflussen die Qualität weitaus stärker als die Quantisierungsstufe.
• Den KV-Cache bei der Speicherberechnung ignorieren. Ein 8,5 GB großes Modell auf 12 GB VRAM scheint normal. Aber bei einem Kontext von 32K kann der KV-Cache weitere 4–6 GB hinzufügen – und das System stürzt ab.
• IQ-Quanten ohne Überprüfung der imatrix-Quelle wählen. IQ4_XS von einem unbekannten Autor ohne Kalibrierungsdatensatz kann schlechter sein als Q4_K_M. Überprüfen Sie die Modellkarte auf das Vorhandensein von imatrix.
• Ein bereits quantisiertes Modell erneut quantisieren. Wenn Sie eine Q8_0-Datei nehmen und sie in Q4 quantisieren, sammeln sich Fehler an. Quantisieren Sie immer vom originalen FP16.

Häufig gestellte Fragen

Was bedeutet Q4 im Modellnamen?

Q4 bedeutet, dass jedes Gewicht des Modells auf etwa 4 Bit komprimiert wird (statt 16 bei FP16). Dies reduziert die Dateigröße um etwa das 3- bis 4-fache bei gleichzeitiger Beibehaltung von ~92–95% der Qualität.

Was ist besser: Q4 oder Q8?

Das hängt von der Aufgabe ab. Für Chat, Übersetzung und Textgenerierung ist Q4_K_M ausreichend. Für Code, Mathematik und Agenten sind Q5_K_M oder Q8_0 merklich besser. Aber denken Sie daran: Ein größeres Modell in Q4 ist normalerweise besser als ein kleineres Modell in Q8.

Lohnt es sich, Q2 oder Q3 zu verwenden?

Nein, wenn es eine Alternative gibt. Q2 und Q3 führen zu einer erheblichen Verschlechterung der Logik. Es ist besser, ein kleineres Modell (3B oder 7B) in Q4_K_M zu wählen – es wird sowohl qualitativ hochwertiger als auch schneller sein.

Welche Quantisierung ist die beste für Ollama?

Q4_K_M ist der Standard für Ollama und die richtige Wahl für die meisten Benutzer. Wenn Sie über genügend Speicher verfügen und die Aufgaben mit Code zu tun haben, ist Q5_K_M besser.

Beeinflusst die Quantisierung die Generierungsgeschwindigkeit?

Ja. Q8_0 generiert Token etwa 29 % langsamer als Q4_K_M, da mehr Daten gelesen werden müssen. Die LLM-Generierung wird durch die Speicherbandbreite begrenzt, nicht durch die Berechnungen.

Warum ist 70B in Q4 besser als 7B in Q8?

Weil die Anzahl der Modellparameter die Qualität weitaus stärker beeinflusst als die Quantisierungsstufe. Ein 70B-Modell mit 40 GB in Q4 und ein 7B-Modell mit 7,7 GB in Q8 – das erste wird bei den überwiegenden meisten Aufgaben gewinnen.

Was ist IQ4_XS und wie unterscheidet es sich von Q4_K_M?

IQ4_XS verwendet eine Importance Matrix – eine vorherige Analyse, welche Gewichte am wichtigsten sind. Ergebnis: Eine um ca. 5 % kleinere Datei bei ähnlicher Qualität. Es erfordert jedoch eine qualitativ hochwertige imatrix-Datei von einem geprüften Autor. Ohne diese kann IQ4_XS hinter Q4_K_M zurückbleiben.

Wie wirkt sich die Quantisierung auf lange Kontexte aus?

Direkt nicht. Aber bei langem Kontext benötigt der KV-Cache viel Speicher. Stellen Sie OLLAMA_KV_CACHE_TYPE=q8_0 ein – dies reduziert den KV-Puffer um 47 % ohne spürbaren Qualitätsverlust.

Woher bekomme ich geprüfte GGUF-Dateien?

Ich persönlich beginne immer mit zwei Quellen: bartowski – der aktivste Uploader im Jahr 2026, veröffentlicht imatrix-Quanten mit detaillierter Dokumentation sofort nach der Veröffentlichung neuer Modelle, und mradermacher – ein Team mit breiter Modellabdeckung, das ebenfalls imatrix enthält. TheBloke – ein klassisches Archiv, das jedoch praktisch nicht mehr aktualisiert wird: für neue Modelle ist es besser, sofort bei bartowski oder mradermacher zu suchen.

Kann die Quantisierung eines bereits heruntergeladenen Modells geändert werden?

Nein – ohne Neukompilierung. Sie können nur eine andere GGUF-Datei mit der gewünschten Quantisierung herunterladen. Wichtig: Quantisieren Sie nicht von einer bereits quantisierten Datei (z. B. Q8 → Q4) – Fehler sammeln sich an. Quantisieren Sie immer von FP16.

Lesen Sie auch

• Top 10 Ollama-Modelle 2026 – welches Modell wählen, nachdem Sie sich für die Quantisierung entschieden haben
• So starten Sie GGUF von Hugging Face in Ollama – Schritt-für-Schritt-Anleitung mit Befehlen
• Ollama 0.30: GGUF, Vulkan und NVIDIA-Beschleunigung – was gibt es Neues in Verbindung mit llama.cpp
• Ollama REST API: Java, Python, JavaScript – wie Sie ein lokales Modell in Ihr Projekt integrieren