Ollama Quantisierung: Q4, Q8 oder fp16?

Was sich durch 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 ungefähr vier Bit 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 Bit antworten die meisten Modelle weiterhin annähernd so wie mit voller Präzision.

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

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

So lesen Sie einen Ollama-Quantisierungs-Tag wie q4_K_M

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

Die Zahl bezeichnet die Zielbreite. 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 Präzision, 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. Ein Block, dessen Gewichte alle nahe bei 0.01 liegen, erhält eine feine Skalierung. Ein Block mit einem einzelnen großen Ausreißer erhält eine grobe Skalierung. Diese blockweisen Skalierungen machen eine Datei mit vier Bit überhaupt nutzbar. Sie sind auch der Grund dafür, dass eine Datei mit vier Bit niemals genau vier Bit pro Gewicht benötigt.

Der letzte Buchstabe bezeichnet die Mischung. S, M und L legen fest, wie viele Tensoren mit einer höheren Zielbreite gespeichert werden. Bei q4_K_M werden die Tensoren, die durch Rundung am stärksten beeinträchtigt werden, mit höherer Breite gespeichert. Der größte Teil bleibt bei vier Bit. Deshalb erzeugt q4_K_M bei nahezu gleicher Dateigröße bessere Ausgaben als das ältere q4_0.

Fragen Sie Ollama ab, welche Dateien tatsächlich auf dem Datenträger liegen, statt den Namen zu erraten, 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 für jedes Gewicht in der gesamten Datei? llama.cpp veröffentlicht in seiner Quantize-Dokumentation gemessene Werte für Llama 3.1 8B. Diese Werte lassen sich gut auf jedes dichte Modell 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 4 Bits pro Gewicht. Der gemessene Wert beträgt 4.89 Bits, weil die Block-Skalierungswerte und die höher präzisen Tensoren zusätzlichen Speicherplatz benötigen. Q8_0 verwendet aus demselben Grund 8.5 statt 8 Bits. Verwenden Sie den gemessenen Wert. Dann liegt das Ergebnis der Berechnung nur wenige Prozent von der tatsächlichen Dateigröße entfernt:

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 für 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. Jeder Block wird konvertiert, sobald er verwendet wird.

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

Die Bibliothek veröffentlicht für die meisten Modellfamilien ein q4_K_M-, ein q8_0- und ein fp16-Tag. Einige neuere Familien weichen von diesem Muster ab und erscheinen in der Bibliothek ausschließlich mit Cloud-Tags. Für diese Tags kann unabhängig von der Größe nichts heruntergeladen werden. Das ist die Grenze, auf die Sie stoßen, wenn Sie GLM 5.2 auf einem VPS ausführen möchten. Dies sind die Qwen3-Größen mit Stand August 2026, aus der Tag-Liste auf der Modellseite übernommen. Alle folgenden Werte beziehen sich zunächst auf den Speicherplatz auf der Festplatte, nicht auf den RAM. Zwei oder drei davon füllen bereits das Root-Volume eines kleinen VPS. Daher sollten Sie wissen, wo Ollama die heruntergeladenen Modelle speichert, bevor Sie Tags sammeln.

[
  {
    "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, weil das Tag ohne Suffix dem q4_K_M-Build entspricht. Q4_K_M ist kein Kompromiss, den die Bibliothek widerwillig anbietet. Es ist die vom Upstream gewählte Standardeinstellung. Daher ist es sinnvoll, zunächst diesen Build für jedes Modell zu verwenden, das Sie nicht selbst getestet haben. Dieselbe Überlegung bestimmt die Tag-Auswahl beim Ausführen von Qwen 3 auf einem VPS.

Die Verhältnisse gelten für jede Zeile. Der Wechsel von q4_K_M zu q8_0 benötigt etwa siebzig Prozent mehr Speicher statt exakt doppelt so viel, weil die Embedding- und Output-Tensoren nicht im selben Verhältnis skalieren wie der übrige Teil. fp16 benötigt ungefähr das Dreifache von q4_K_M. Ein 32B-Modell mit q4_K_M belegt 20 GB für die Gewichte. Damit überschreitet es bereits die Kapazität eines Systems mit 16 GB, sobald überhaupt ein Kontextfenster hinzukommt. Einen breiteren Überblick darüber, welche Modelle auf welche Systeme passen, finden Sie unter welche Modelle Sie selbst hosten können.

Warum der KV-Cache ein zweiter, vom Kontext abhängiger Kostenfaktor ist

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

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 Ebenen, 8 Key/Value-Heads und eine Head-Dimension von 128. ollama show liefert die Architektur und die Parameteranzahl. Die config.json 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 vernachlässigbarer 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
  }
]

Bei Ollamas Standardfenster von 4096 Tokens benötigt der Cache zusätzlich zu den Gewichten 0.6 GB. Erhöhen Sie das Fenster auf 32k, erreicht allein der Cache 4.83 GB. Das entspricht fast dem Speicherbedarf der quantisierten Gewichte. Der Mindestbedarf für das gesamte Modell beträgt dann 10 GB. Dieser Wert ist ein Mindestwert, weil zusätzlich Compute-Puffer und das Betriebssystem Speicher benötigen. Lesen Sie den tatsächlichen Wert aus der Spalte SIZE von ollama ps ab, nachdem das Modell geladen wurde.

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 Installation mit systemd 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, um zu bestätigen, mit welchem Fenster das laufende Modell tatsächlich geladen wurde. OLLAMA_KV_CACHE_TYPE quantisiert auch den Cache selbst: f16 ist die Standardeinstellung, q8_0 benötigt etwa die Hälfte des Speichers von f16 und q4_0 etwa ein Viertel. Dies ist eine globale Option. Daher gilt sie für jedes Modell auf diesem Server. Die Cache-Quantisierung wird nur wirksam, wenn Flash Attention aktiviert ist. Ollama aktiviert Flash Attention automatisch, wenn das Backend dies unterstützt, und OLLAMA_FLASH_ATTENTION=1 erzwingt die Aktivierung. Auf einem kleinen System mit einem großen Fenster gibt die Halbierung des Cache mehr Speicher frei als jede andere einzelne Änderung. num_ctx festlegen und die Kosten verstehen behandelt das Fenster selbst ausführlich. Der Cache wird außerdem einmal pro gleichzeitig verwendbarem Anfrage-Slot dimensioniert und nicht einmal pro Server. Wenn Ollama daher zwei Eingabeaufforderungen gleichzeitig verarbeitet, verdoppelt sich der gerade eingeplante Wert. Darauf basiert die Berechnung für die Anzahl paralleler Slots und ein Warteschlangenlimit auswählen.

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

Budget-Gewichte plus KV-Cache sowie Reserven für das Betriebssystem und alle weiteren 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 Standardfenster von 4k und sehr wenig Reserve. Planen Sie hier nicht mit 8B und einem 32k-Fenster, weil der erforderliche Mindestwert 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 belegt 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. Diese beiden Modelle mit eigenen Prompts zu vergleichen, ist die nützlichste Stunde, die Sie für dieses Thema aufwenden 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 kommt an die Speichergrenze. Überwachen Sie daher ollama ps, statt dies vorauszusetzen.

Was bei der Quantisierung zuerst schlechter wird

Der Quantisierungsfehler wirkt sich nicht gleichmäßig auf alle 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. Als Erstes leidet die Präzision. Dazu gehören der exakte Abruf einer Versionsnummer, einer API-Signatur oder eines Datums. Auch lange Argumentationsketten werden anfällig. Ein kleiner Fehler bei Schritt zwei führt dann bei Schritt acht zu einer falschen Antwort. Dasselbe gilt für strikt vorgegebene Ausgabeformate. Eine falsche Klammer reicht aus, damit ein Tool-Aufruf fehlschlägt.

Letzteres ist der praktische Test. Wenn ein Modell JSON zurückgeben muss, das Ihr Code verarbeitet, äußert sich der Schaden durch die Quantisierung als Parse-Fehler und nicht als nur geringfügig schlechtere Prosa. Sie erkennen ihn daher noch am selben Tag. Ein Coding-Agent ist die strengste Variante dieses Tests. Er führt das Modell durch viele Tool-Aufrufe. Wenn Sie also einen Agenten auf Ihren Ollama-Server ansetzen, wird eine zu aggressive Quantisierung innerhalb eines Nachmittags sichtbar.

Unter vier Bit nimmt die Qualität deutlich stärker ab. Der q3- und der Zwei-Bit-Typ sind für Fälle gedacht, in denen ein großes Modell auf kleiner Hardware betrieben werden soll. Sie sind eine echte Option, wenn die Alternative darin besteht, das Modell überhaupt nicht auszuführen. Als Standardauswahl sind sie ungeeignet. Zwischen q4_K_M und q8_0 ist der Abstand klein genug, dass eine veröffentlichte Perplexity-Tabelle die Entscheidung für Ihren Workload nicht klären wird. Versuchen Sie daher nicht, die Entscheidung auf diese Weise zu treffen. Führen Sie beide Varianten mit dreißig eigenen Prompts aus und lesen Sie die Ausgaben.

Wann sich q8_0 oder fp16 für den RAM-Verbrauch lohnt

Verwenden Sie q8_0, wenn der Arbeitsspeicher tatsächlich frei ist und die Aufgabe kleine Fehler stark bestraft: strukturierte Extraktion, Tool-Aufrufe oder Code, der kompiliert werden 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 ermitteln eine Referenz, um festzustellen, wie viel Ihr Vier-Bit-Build aufgegeben hat. Der Betrieb mit fp16 benötigt dreimal so viel Arbeitsspeicher wie q4_K_M, obwohl die meisten Menschen den Unterschied bei einem Blindtest nicht erkennen können. Auf einem Rechner, der nur über eine CPU verfügt, sinkt außerdem die Tokenrate auf ein Drittel.

Die stärkere 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 14B-Gewichte gegenüber 8.9 GB für die 8B-Gewichte entsprechen nahezu demselben RAM (Random Access Memory), und das größere Modell verfügt über mehr Wissen. Testen Sie das mit Ihren eigenen Prompts, statt diese Aussage einfach zu übernehmen.

CPU-only-Inferenz ist durch die Speicherbandbreite begrenzt

Die meisten VPS-Tarife haben keine GPU. Daher läuft das Modell im Arbeitsspeicher des Hosts auf der CPU. Die Generierung wird dann durch die Speicherbandbreite begrenzt, nicht durch die Rechenleistung. Für die Erzeugung eines Tokens müssen alle Gewichtungen einmal gelesen werden. Daraus ergibt sich eine Obergrenze, die unabhängig von der Anzahl der gebuchten CPU-Kerne ist.

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

Fifty GB/s ist ungefähr der theoretische Wert für einen Host mit zweikanaligem DDR4-3200. Ihr Anteil ist kleiner, weil sich ein VPS diesen Bus mit allen anderen Mandanten auf dem Rechner teilt. Betrachten Sie diese Werte daher als Obergrenze, die in der Praxis niemand erreicht. Entscheidend ist der Zusammenhang: Auf der CPU verdoppelt eine Halbierung der Bitanzahl pro Gewichtung ungefähr die Tokenrate. Quantisierung ist auf einem Rechner ohne GPU der größte verfügbare Hebel für mehr Geschwindigkeit. Ob die verbleibende Rate ausreicht, hängt vom Modell ab. Nemotron 3.5 Lightning auf einem VPS rechnet dies für einen konkreten Build mit bestimmtem Tag und angegebener RAM-Größe durch. Die andere Hälfte der Wartezeit hängt davon ab, wie viel das Modell schreibt. Bei zehn Tokens pro Sekunde dauert eine Antwort mit sechshundert Tokens eine volle Minute. Die Antwort mit num_predict begrenzen spart daher oft mehr Wartezeit, als ein weiterer Schritt zu geringerer Präzision.

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 CPU-Kerne helfen dabei, verbessern die Generierungsgeschwindigkeit jedoch kaum. Ein Rechner, der einen 4k-Prompt schnell verarbeitet und anschließend langsam generiert, verhält sich normal.

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

Ein Modell selbst quantisieren

Das ist relevant, wenn Sie ein Modell feinabgestimmt haben und kein Bibliotheks-Tag existiert. Der Weg hängt vom gewünschten Zielformat ab, da Ollama die auf dieser Seite gemessenen GGUF-K-Quants nicht mehr erzeugt.

Für einen K-Quant wie q4_K_M müssen Sie quantisieren, bevor Ollama die Datei verarbeitet. Ollama quantisiert GGUF-Modelle beim Import nicht und lehnt --quantize bei einer GGUF-Quelle ab. Quantisieren Sie das unquantisierte GGUF mit llama-quantize aus llama.cpp und importieren Sie anschließend die fertige Datei. Dieser Importweg hat eine eigene Fehlerquelle: Eine nicht übereinstimmende Chat-Vorlage führt dazu, dass das Modell unbrauchbare Antworten erzeugt. Eine GGUF-Datei in Ollama importieren beschreibt diesen Vorgang. Mit der quantization-Zeile aus ollama show prüfen Sie, ob die importierte Datei dem gewünschten Build entspricht.

Ollamas eigenes --quantize funktioniert nur mit Imports aus safetensors. Verweisen Sie in einer Modelfile auf das Verzeichnis mit den unquantisierten safetensors-Gewichten:

FROM /path/to/safetensors/directory

Erstellen Sie anschließend das Modell:

ollama create --quantize int4 mymodel

Mit Ollama v0.40.0 (geprüft am 2026-10-09) akzeptiert --quantize int4, int8, nvfp4, mxfp4 und mxfp8. Dabei werden q4 und q8 als Aliase für int4 und int8 behandelt. GGUF-Bezeichnungen wie q4_K_M, q4_K_S, q8_0, q6_K und q5_K_M werden mit einem unsupported quantize type-Fehler abgelehnt. Diese Typen sind nicht die GGUF-K-Quants aus den obigen Tabellen. Verwenden Sie daher die Angaben zu Bits pro Gewicht und Dateigröße auf dieser Seite nicht als Vorhersagen für diese Typen.

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

Dort steht 100% GPU, 100% CPU oder eine Aufteilung wie 48%/52% CPU/GPU. Eine Aufteilung bedeutet, dass die Gewichte und der KV-Cache nicht in den VRAM (Video-RAM, den Speicher der Grafikkarte) gepasst haben. 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. Verkleinern 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 das Kernel- und das Dienstprotokoll:

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 Gewichten, KV-Cache und Puffern den verfügbaren Speicher des Systems überschritten hat. Auf einem VPS ohne konfigurierten Swap kann das gesamte System mehrere Sekunden blockieren, bevor diese Zeile erscheint.

Die Antworten sind schlechter geworden, obwohl Sie nichts geändert haben. Zwei Builds desselben Modells können in ollama ls unter verschiedenen Tags nebeneinander vorhanden sein. 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 veröffentlicht. Daher rufen ollama pull qwen3:8b und ollama pull qwen3:8b-q4_K_M dieselbe Datei ab. Wechseln Sie erst zu q8_0, wenn ausreichend Arbeitsspeicher verfügbar ist und die Aufgabe kleine Fehler stark bestraft, etwa 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 Arbeitsspeicher für höhere Präzision reservieren.

Bedeutet q4_K_M tatsächlich vier Bit pro Gewicht?

Nein. Bei Llama 3.1 8B sind es gemessen 4.89 Bit pro Gewicht. Jeder Gewichtsblock speichert eine eigene Skalierung, und die empfindlichsten Tensoren werden in einem breiteren Datentyp gespeichert. Q8_0 erreicht aus demselben Grund 8.5 Bit statt acht. Verwenden Sie beim Schätzen den gemessenen Wert: Die Parameteranzahl multipliziert mit der Bitanzahl pro Gewicht und geteilt durch acht ergibt die Dateigröße in Byte.

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

Berücksichtigen Sie Gewichte, KV-Cache und Reserve. Qwen3 8B mit q4_K_M benötigt für die Gewichte 5.2 GB. Beim standardmäßigen Fenster mit 4096 Tokens kommen für den Cache 0.6 GB hinzu. Damit ergibt sich vor Rechenpuffern und dem Betriebssystem ein Mindestbedarf von etwa 5.8 GB. 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-Auslastung, 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 Hauptspeicher abgelegt. Die häufigste Ursache ist ein Kontextfenster, das größer ist als der Speicher der Grafikkarte. Der Cache wird beim Laden des Modells 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.