Ollama Quantisierung: q4_K_M, q8_0 oder fp16?

Was die Ollama-Quantisierung ändert

Bei der Ollama-Quantisierung wird jedes Gewicht eines Modells mit weniger Bits gespeichert als in der Datei, mit der es trainiert wurde. Ein Tag mit dem Suffix q4_K_M verwendet etwa vier Bits pro Gewicht, während fp16 sechzehn verwendet. Dadurch ist der Download ungefähr ein Viertel so groß, und der Rechner muss für die Erzeugung jedes Tokens etwa ein Viertel so viele Bytes lesen. Die Gewichte werden auf ein grobes Raster gerundet, nicht verworfen. Bei vier Bits antworten die meisten Modelle nahezu so wie bei voller Präzision.

Das ist der gesamte Zielkonflikt: ein deutlich geringerer Speicherbedarf und mehr Tokens pro Sekunde, erkauft durch einen geringfügigen Genauigkeitsverlust. Im Folgenden erfahren Sie, wie Sie beide Seiten für ein bestimmtes Modell auf einem bestimmten System einschätzen können, bevor Sie zwanzig Minuten lang eine Datei herunterladen, die nicht in den verfügbaren Speicher passt.

Wenn Ollama noch nicht ausgeführt wird, beginnen Sie mit Ollama auf einem VPS installieren. Auf dieser Seite wird vorausgesetzt, dass ollama ls bereits funktioniert.

So lesen Sie ein Ollama-Quantisierungs-Tag wie q4_K_M

Lokale Modelle werden als GGUF-Dateien bereitgestellt. Dieses Format verwendet llama.cpp zum Speichern von Gewichten auf dem Datenträger. Ollama basiert auf llama.cpp. Daher übernehmen Ollama-Tags die Quantisierungsbezeichnungen von llama.cpp unverändert.

Die Zahl gibt die Zielbreite an. q4 bedeutet, dass die meisten Gewichtstensoren mit jeweils vier Bit gepackt werden. q8 bedeutet acht Bit. fp16 ist überhaupt nicht quantisiert. Dabei handelt es sich um das Modell mit 16-Bit-Gleitkommazahlen, also um die Genauigkeit, in der die meisten Modelle veröffentlicht werden.

K kennzeichnet eine K-Quantisierung. Die Gewichte werden in kleine Blöcke gruppiert. Jeder Block speichert neben den gepackten Werten eine eigene Skalierung. Bei einem Block, dessen Gewichte alle nahe bei 0.01 liegen, wird eine feine Skalierung verwendet. Ein Block mit einem großen Ausreißer erhält eine grobe Skalierung. Diese blockweisen Skalierungen sorgen dafür, dass eine Datei mit vier Bit praktisch nutzbar bleibt. Sie sind auch der Grund dafür, dass eine Datei mit vier Bit niemals genau vier Bit pro Gewicht benötigt.

Der letzte Buchstabe gibt die Mischung an. S, M und L legen fest, wie viele Tensoren über die Zielbreite hinaus erweitert werden. Bei q4_K_M werden Tensoren, deren Rundung die Ausgabe am stärksten beeinträchtigt, mit größerer Breite gespeichert. Der Großteil bleibt bei vier Bit. Deshalb liefert q4_K_M eine bessere Ausgabe als das ältere q4_0 bei nahezu gleicher Dateigröße.

Fragen Sie Ollama ab, welche Modelle tatsächlich auf dem Datenträger liegen, statt den Namen zu verwenden, den Sie eingegeben haben:

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show gibt architecture, parameters, quantization, context length und embedding length aus. Die Zeile quantization ist die maßgebliche Information für ein Modell, das Sie vor Monaten abgerufen haben und dessen Auswahl Sie nicht mehr kennen.

Bits pro Gewicht bestimmen die Dateigröße

Jede Größenschätzung beginnt mit einer Zahl: Wie viele Bits verwendet das Format durchschnittlich über die gesamte Datei pro Gewicht? llama.cpp veröffentlicht in seiner Quantisierungsdokumentation Messwerte für Llama 3.1 8B. Diese Werte lassen sich gut auf dichte Modelle mit ähnlicher Struktur übertragen.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

Die Überraschung in dieser Tabelle steht in der zweiten Spalte. Q4_K_M verwendet nicht vier Bits pro Gewicht. Der Messwert beträgt 4.89 Bits, weil die Block-Skalierungswerte und die höher aufgelösten Tensoren ebenfalls realen Speicherplatz benötigen. Q8_0 verwendet aus demselben Grund 8.5 Bits statt acht. Verwenden Sie den Messwert. Dann liegt die Berechnung innerhalb weniger Prozent der tatsächlichen Dateigröße:

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

Das ergibt die 4.58-GiB-Datei im Format Q4_K_M, berechnet aus zwei Zahlen. Näherungsweise entspricht das auch dem Speicher, den die Gewichte nach dem Laden belegen. Ollama entpackt beim Laden nichts. Die quantisierten Gewichte bleiben in ihrer gepackten Form im Speicher, und jeder Block wird bei der Verwendung konvertiert.

Was Ollama für jede Modellgröße tatsächlich bereitstellt

Für die meisten Familien veröffentlicht die Bibliothek ein q4_K_M-, ein q8_0- und ein fp16-Tag. Dies sind die Qwen3-Größen mit Stand August 2026, abgelesen aus der Tag-Liste auf der Modellseite.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

Das Standard-Tag ist hier entscheidend. ollama pull qwen3:8b lädt exakt dieselben 5.2 GB wie ollama pull qwen3:8b-q4_K_M herunter, weil das Tag ohne Suffix der q4_K_M-Build ist. Q4_K_M ist kein Kompromiss, den die Bibliothek widerwillig anbietet. Es ist die von Upstream gewählte Standardeinstellung. Daher ist es sinnvoll, zunächst diese Variante zu verwenden, wenn Sie ein Modell noch nicht selbst getestet haben. Dieselbe Überlegung bestimmt die Tag-Auswahl in Qwen 3 auf einem VPS ausführen.

Die Verhältnisse gelten für jede Zeile. Der Wechsel von q4_K_M zu q8_0 benötigt etwa siebzig Prozent mehr Speicher, nicht exakt das Doppelte, weil Embedding- und Output-Tensoren nicht im gleichen Maß wie der Rest skalieren. fp16 ist ungefähr dreimal so groß wie q4_K_M. Ein 32B-Modell mit q4_K_M belegt 20 GB für die Gewichte. Das übersteigt bereits die Kapazität eines Rechners mit 16 GB, sobald überhaupt ein Kontextfenster verwendet wird. Eine breitere Übersicht darüber, welche Modelle auf welche Maschine passen, finden Sie unter welche Modelle Sie selbst hosten können.

Warum der KV-Cache zusätzliche, kontextabhängige Kosten verursacht

Die Gewichte sind die festen Kosten. Der KV-Cache (Key- und Value-Cache) ist der variable Anteil. Für jedes Token im Kontextfenster werden die Key- und Value-Vektoren jeder Schicht gespeichert. Deshalb wächst der Cache linear mit der erlaubten Fenstergröße. Beim Laden des Modells wird Speicher für das gesamte Fenster reserviert, nicht erst während sich die Unterhaltung füllt. Ein langes Fenster benötigt daher auch bei einer Eingabe mit nur einem Wort zusätzlichen Arbeitsspeicher.

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

Diese Modellwerte stammen aus der Konfiguration des Modells: 36 Schichten, 8 Key/Value-Heads und eine Head-Dimension von 128. ollama show enthält die Architektur und die Parameteranzahl. Die config.json-Datei des Modells auf Hugging Face enthält die übrigen Angaben. Multiplizieren Sie die Kosten pro Token mit der Fenstergröße. Dann ist der Cache kein Rundungsfehler mehr.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

Beim Standardfenster von 4096 Tokens in Ollama fügt der Cache zusätzlich zu den Gewichten 0.6 GB hinzu. Erhöhen Sie das Fenster auf 32k, erreicht der Cache allein 4.83 GB. Das entspricht fast dem Speicherbedarf der quantisierten Gewichte. Der Mindestbedarf für das gesamte Modell beträgt dann 10 GB. Diese Angabe ist ein Mindestwert, weil Compute-Puffer und das Betriebssystem zusätzlichen Speicher benötigen. Lesen Sie den tatsächlichen Wert nach dem Laden des Modells in der Spalte SIZE von ollama ps ab.

Das Fenster wird auf dem Server und nicht pro Anfrage festgelegt, wenn Sie Ollama als Dienst ausführen:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Bei einer systemd-Installation tragen Sie den Wert stattdessen in einem Drop-in ein:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

Starten Sie den Dienst mit sudo systemctl restart ollama neu. Prüfen Sie anschließend die Spalte CONTEXT von ollama ps. Damit bestätigen Sie, mit welcher Fenstergröße das laufende Modell tatsächlich geladen wurde. OLLAMA_KV_CACHE_TYPE quantisiert auch den Cache selbst: f16 ist der Standardwert, q8_0 benötigt etwa halb so viel Speicher wie f16 und q4_0 etwa ein Viertel. Dies ist eine globale Option. Daher gilt sie für jedes Modell auf diesem Server. Auf einem kleinen System mit einem langen Fenster wird durch die Halbierung des Caches mehr Speicher frei als durch jede andere einzelne Änderung. num_ctx festlegen und die Auswirkungen auf den Speicherbedarf behandelt das Fenster selbst ausführlich.

Was auf einen 8-, 16- oder 32-GB-VPS passt

Gewichte des Budgets, dazu der KV-Cache sowie Reserven für das Betriebssystem und alle anderen laufenden Prozesse. Zwei GB Reserve sind auf einem kleinen VPS komfortabel.

8 GB. Ein 4B-Modell mit q4_K_M belegt 2.6 GB und lässt Raum für ein großes Kontextfenster. Ein 8B-Modell mit q4_K_M passt mit dem standardmäßigen 4k-Fenster und sehr wenig Reserve. Planen Sie hier kein 8B-Modell mit einem 32k-Fenster ein, da der Mindestbedarf von 10 GB bereits über dem verfügbaren Arbeitsspeicher liegt.

16 GB. 8B mit q4_K_M und einem 16k- oder 32k-Fenster ist komfortabel. 14B mit q4_K_M benötigt 9.3 GB für die Gewichte und passt mit einem moderaten Fenster. 8B mit q8_0 belegt 8.9 GB und passt daher ebenfalls. Der Vergleich dieser beiden Modelle mit Ihren eigenen Prompts ist die sinnvollste Stunde, die Sie in dieses Thema investieren können.

32 GB. 14B mit q8_0 (16 GB) und 32B mit q4_K_M (20 GB) lassen sich beide laden. Ein 32B-Build mit einem großen Fenster stößt an die Speichergrenze. Beobachten Sie daher ollama ps, statt dies einfach vorauszusetzen.

Welche Fähigkeiten durch Quantisierung zuerst beeinträchtigt werden

Quantisierungsfehler wirken sich nicht gleichmäßig auf die Fähigkeiten eines Modells aus. Sprachfluss bleibt am längsten erhalten. Genau deshalb wird der Schaden leicht übersehen: Ein schlecht quantisiertes Modell schreibt weiterhin saubere Sätze. Präzision leidet zuerst. Dazu gehören das exakte Wiedergeben einer Versionsnummer, einer API-Signatur oder eines Datums. Auch lange Schlussfolgerungsketten sind betroffen, wenn ein kleiner Fehler in Schritt zwei in Schritt acht zu einer falschen Antwort führt. Dasselbe gilt für strikte Ausgabeformate, bei denen eine falsche Klammer einen Tool-Aufruf fehlschlagen lässt.

Letzteres ist der praktische Test. Wenn ein Modell JSON zurückgeben muss, das Ihr Code parst, zeigt sich der Schaden durch Quantisierung als Parse-Fehler und nicht als nur vage schlechtere Prosa. Sie erkennen ihn dadurch noch am selben Tag. Ein Coding-Agent ist die anspruchsvollste Variante dieses Tests. Er führt das Modell durch eine Folge von Tool-Aufrufen. Wenn Sie also einen Agenten auf Ihren Ollama-Server ansetzen, wird eine zu aggressive Quantisierung innerhalb eines Nachmittags sichtbar.

Unter vier Bit nimmt der Qualitätsverlust stark zu. Die q3- und Zwei-Bit-Typen richten sich an Anwender, die ein großes Modell auf kleiner Hardware betreiben wollen. Sie sind eine sinnvolle Option, wenn die Alternative darin besteht, das Modell überhaupt nicht auszuführen. Als Standardauswahl sind sie ungeeignet. Der Abstand zwischen q4_K_M und q8_0 ist klein genug, dass eine veröffentlichte Perplexity-Tabelle die Frage für Ihren Workload nicht entscheiden kann. Versuchen Sie daher nicht, die Entscheidung auf diese Weise zu treffen. Führen Sie beide Varianten mit dreißig eigenen Prompts aus und prüfen Sie die Ausgabe.

Wann sich q8_0 oder fp16 beim RAM lohnt

Verwenden Sie q8_0, wenn der Arbeitsspeicher tatsächlich frei ist und die Aufgabe kleine Fehler besonders stark bestraft: strukturierte Extraktion, Tool-Aufrufe oder Code, der kompilieren muss. Sie kaufen damit eine Absicherung, kein merklich intelligenteres Modell.

Verwenden Sie fp16 nur aus zwei Gründen. Entweder quantisieren Sie das Modell selbst und benötigen die Quelldatei, oder Sie messen eine Referenz, um festzustellen, wie viel Qualität Ihr Vier-Bit-Build eingebüßt hat. Der Betrieb mit fp16 benötigt dreimal so viel Speicher wie q4_K_M. Der Unterschied ist für die meisten Menschen im Blindvergleich nicht erkennbar. Auf einem Rechner, der nur über eine CPU verfügt, sinkt außerdem die Token-Rate auf ein Drittel.

Die wichtigere Regel bei einem festen Speicherbudget lautet: Ein größeres Modell mit q4_K_M ist normalerweise besser als ein kleineres Modell mit q8_0. 9.3 GB für die Gewichte eines 14B-Modells gegenüber 8.9 GB für die Gewichte eines 8B-Modells ergeben nahezu denselben RAM (Arbeitsspeicher), und das größere Modell verfügt über mehr Wissen. Testen Sie das mit Ihren eigenen Prompts, statt diese Aussage ungeprüft zu übernehmen.

CPU-only-Inferenz ist durch die Speicherbandbreite begrenzt

Die meisten VPS-Tarife haben keine GPU. Das Modell läuft daher im Arbeitsspeicher des Hosts auf der CPU. Die Generierung wird dann durch die Speicherbandbreite begrenzt, nicht durch Rechenleistung. Für die Erzeugung eines Tokens müssen alle Gewichte einmal gelesen werden. Dadurch entsteht eine Obergrenze, die unabhängig davon ist, wie viele Kerne Sie gebucht haben.

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

50 GB/s ist ungefähr der theoretische Wert für einen Host mit zweikanaligem DDR4-3200. Ihr Anteil ist geringer, weil sich ein VPS diesen Speicherbus mit allen anderen Mandanten auf der Maschine teilt. Betrachten Sie diese Zahlen daher als Obergrenze, die niemand erreicht. Entscheidend ist der Verlauf: Auf der CPU verdoppelt eine Halbierung der Bitzahl pro Gewicht ungefähr die Tokenrate. Quantisierung ist auf einem System ohne GPU der größte verfügbare Hebel für die Geschwindigkeit.

Die Verarbeitung des Prompts verhält sich anders. Das Lesen eines langen Prompts ist eher durch die Rechenleistung als durch die Speicherbandbreite begrenzt. Zusätzliche Kerne helfen dabei, bewirken aber fast nichts für die Generierungsgeschwindigkeit. Ein System, das einen 4k-Prompt schnell verarbeitet und anschließend langsam Text generiert, verhält sich normal.

Verlassen Sie sich nicht ungeprüft auf diese Berechnungen. Messen Sie die Tokens pro Sekunde auf Ihrem eigenen System mit demselben Prompt für jede Quantisierung. Ihre Messwerte sind maßgeblich.

Ein Modell selbst quantisieren

Ollama kann aus einer fp16- oder fp32-Quelle ein quantisiertes Modell erstellen. Das ist wichtig, wenn Sie ein Modell feinabgestimmt haben und kein Bibliotheks-Tag dafür existiert. Verweisen Sie in einer Modelfile auf die nicht quantisierten Gewichte:

FROM /path/to/my/model/f16

Erstellen Sie das Modell anschließend und überprüfen Sie es:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize akzeptiert q8_0, q4_K_S und q4_K_M. Eine Option q6_K oder q5_K_M gibt es hier nicht. Für diese Formate quantisieren Sie das Modell daher mit dem eigenen Tool von llama.cpp und importieren anschließend die fertige GGUF-Datei. Mit der Zeile quantization aus ollama show überprüfen Sie, ob der Build wie angegeben ausgeführt wurde.

Was Sie sehen, wenn etwas fehlschlägt

Alles läuft auf der CPU, obwohl Sie die GPU erwartet haben. Lesen Sie die Spalte PROCESSOR:

ollama ps

Die Ausgabe enthält 100% GPU, 100% CPU oder eine Aufteilung wie 48%/52% CPU/GPU. Eine Aufteilung bedeutet, dass die Weights zusammen mit dem KV-Cache nicht in den VRAM (Video-RAM, also den Speicher der Grafikkarte) passten. Deshalb wurde ein Teil des Modells im Systemspeicher abgelegt. Die Geschwindigkeit sinkt dann fast auf die reine CPU-Rate, weil jedes Token auf die langsamere Hälfte warten muss. Verringern Sie das Kontextfenster, quantisieren Sie den Cache oder verwenden Sie einen kleineren Build. Mehr CPU-Kerne helfen nicht.

Das Modell wird während des Ladens beendet. Prüfen Sie den Kernel und das Service-Log:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

Eine Zeile mit Out of memory: Killed process bedeutet, dass die Summe aus Weights, KV-Cache und Puffern den verfügbaren Speicher des Systems überschritten hat. Auf einem VPS ohne konfigurierten Swap kann das gesamte System mehrere Sekunden hängen, bevor diese Zeile erscheint.

Die Antworten sind schlechter geworden, obwohl Sie nichts geändert haben. Zwei Builds desselben Modells können in ollama ls mit unterschiedlichen Tags nebeneinander liegen. Ein Skript, das den Namen ohne Suffix abruft, verwendet dann den Build, auf den die Bibliothek aktuell verweist. Führen Sie ollama show mit genau dem Tag aus, den Ihr Client anfordert, und lesen Sie die Zeile quantization, statt dem Namen in Ihrer Konfigurationsdatei zu vertrauen.

FAQ

Welche Ollama-Quantisierung sollte ich herunterladen?

Beginnen Sie mit q4_K_M. Dies ist der Standard-Tag, den die Ollama-Bibliothek für die meisten Modelle bereitstellt. Daher laden ollama pull qwen3:8b und ollama pull qwen3:8b-q4_K_M dieselbe Datei herunter. Wechseln Sie erst zu q8_0, wenn ausreichend Speicher verfügbar ist und die Aufgabe kleine Fehler stark bestraft, beispielsweise bei Tool-Aufrufen oder strukturierter JSON-Ausgabe. Bei einem festen Speicherbudget ist ein größeres Modell mit q4_K_M in der Regel besser als ein kleineres Modell mit q8_0. Testen Sie diese Kombination daher, bevor Sie zusätzlichen RAM für höhere Präzision einsetzen.

Bedeutet q4_K_M wirklich vier Bits pro Gewicht?

Nein. Bei Llama 3.1 8B sind es gemessen 4.89 Bits pro Gewicht. Jeder Gewichtsblock speichert eine eigene Skalierung, und für die empfindlichsten Tensoren wird ein Datentyp mit größerer Breite verwendet. Aus demselben Grund benötigt Q8_0 gemessen 8.5 Bits statt acht. Verwenden Sie beim Schätzen den gemessenen Wert: Die Parameteranzahl multipliziert mit den Bits pro Gewicht und geteilt durch acht ergibt die Dateigröße in Byte.

Wie viel RAM benötigt ein 8B-Modell auf einer VPS nur mit CPU?

Rechnen Sie die Gewichte, den KV-Cache und zusätzlichen Spielraum zusammen. Qwen3 8B mit q4_K_M benötigt 5.2 GB für die Gewichte. Beim standardmäßigen Fenster mit 4096 Tokens kommen für den Cache 0.6 GB hinzu. Damit ergibt sich ein Mindestbedarf von etwa 5.8 GB, noch ohne Compute-Puffer und Betriebssystem. Bei einem Fenster mit 32k Tokens benötigt der Cache allein 4.83 GB. Planen Sie für ein kurzes Fenster 8 GB und für ein langes Fenster 16 GB ein.

Warum läuft mein Modell mit 100 % CPU, obwohl der Server eine GPU hat?

Führen Sie ollama ps aus und lesen Sie die Spalte PROCESSOR. 100% CPU oder eine Aufteilung wie 48%/52% CPU/GPU bedeutet, dass die Gewichte und der KV-Cache nicht in den VRAM passten. Ollama hat daher einen Teil oder das gesamte Modell im Arbeitsspeicher abgelegt. Die häufigste Ursache ist ein Kontextfenster, das größer ist, als die Grafikkarte aufnehmen kann. Beim Laden des Modells wird der Cache für das gesamte Fenster reserviert. Verkleinern Sie das Fenster mit OLLAMA_CONTEXT_LENGTH, setzen Sie OLLAMA_KV_CACHE_TYPE=q8_0, um die Cache-Größe zu halbieren, oder laden Sie eine kleinere Quantisierung herunter.