Ollama Quantisierung: q4_K_M, q8_0 oder fp16?

Was sich durch die Quantisierung in Ollama ändert

Bei der Quantisierung in Ollama wird jedes Gewicht eines Modells mit weniger Bits gespeichert als in der Datei, mit der es trainiert wurde. Ein Tag mit der Endung 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 jedes erzeugte Token ungefähr ein Viertel so viele Bytes lesen. Die Gewichte werden auf ein grobes Raster gerundet, nicht verworfen. Bei vier Bits antworten die meisten Modelle fast so wie mit voller Präzision.

Das ist der gesamte Zielkonflikt: deutlich weniger 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 abschätzen, bevor Sie zwanzig Minuten lang eine Datei herunterladen, die nicht in den Speicher passt.

Wenn Ollama noch nicht läuft, 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 veröffentlicht. Dieses Format verwendet llama.cpp zum Speichern der Gewichte auf dem Datenträger. Ollama basiert auf llama.cpp. Daher übernimmt Ollama 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. Es handelt sich um das Modell mit 16-Bit-Gleitkommazahlen, also mit der 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 nie exakt vier Bit pro Gewicht benötigt.

Der letzte Buchstabe gibt die Mischung an. S, M und L legen fest, wie viele Tensoren mit einer größeren Zielbreite gespeichert werden. Bei q4_K_M werden die Tensoren, bei denen sich Rundungsfehler am stärksten auswirken, mit größerer Breite gespeichert. Der Groß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 Datei tatsächlich auf dem Datenträger liegt, 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 genau 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 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 ist die zweite Spalte. Q4_K_M verwendet nicht vier Bits pro Gewicht. Der gemessene Wert beträgt 4.89 Bits, weil auch die Block-Skalierungswerte und die hochgestuften Tensoren Speicherplatz benötigen. Q8_0 verwendet aus demselben Grund 8.5 Bits statt acht. Verwenden Sie den gemessenen Wert. Dann liegt die 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 ist die 4.58-GiB-Datei mit Q4_K_M, berechnet aus zwei Zahlen. Näherungsweise entspricht das auch dem Speicherbedarf der Gewichte nach dem Laden. Ollama entpackt beim Laden nichts. Die quantisierten Gewichte bleiben im Speicher in derselben gepackten Form. Jeder Block wird konvertiert, sobald er verwendet wird.

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

Die Library 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 Library ausschließlich mit Cloud-Tags, für die unabhängig von der Größe kein Modell heruntergeladen werden kann. Auf diese Grenze stoßen Sie, wenn Sie versuchen, GLM 5.2 auf einem VPS auszuführen. Dies sind die Qwen3-Größen im August 2026, basierend auf der Tag-Liste auf der Modellseite. Alle folgenden Werte beziehen sich auf den Speicherplatz auf der Festplatte, bevor das Modell überhaupt in den RAM geladen wird. Zwei oder drei davon füllen zusammen 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 mit 5.2 GB exakt dieselbe Datenmenge 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 Library nur widerwillig anbietet. Es ist die Standardvariante, die der Upstream gewählt hat. Daher ist sie der sinnvolle erste Ansatz für jedes Modell, das Sie noch 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 kostet etwa siebzig Prozent mehr Speicherplatz und nicht exakt das Doppelte, weil die Embedding- und Output-Tensoren nicht im selben Maß skalieren wie die übrigen Tensoren. fp16 ist ungefähr dreimal so groß wie q4_K_M. Ein 32B-Modell belegt mit q4_K_M 20 GB für die Gewichte. Damit überschreitet es bereits die Kapazität eines Systems mit 16 GB, sobald überhaupt ein Context Window verwendet werden soll. Eine umfassendere Übersicht darüber, welches Modell auf welches System passt, finden Sie unter welche Modelle Sie selbst hosten können.

Warum der KV-Cache ein zweiter, kontextabhä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 speichert jede Schicht seine Key- und Value-Vektoren. 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 des Aufbaus der Unterhaltung. Daher benötigt ein großes Fenster 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 Headdimension von 128. ollama show enthält die Architektur und die Parameteranzahl. Die config.json-Angabe des Modells auf Hugging Face enthält die übrigen Werte. 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 Compute-Puffer und das Betriebssystem zusätzlichen Speicher benötigen. Lesen Sie den tatsächlichen Wert nach dem Laden des Modells aus der Spalte SIZE von ollama ps ab.

Das Fenster wird beim Betrieb von Ollama als Dienst auf dem Server festgelegt, nicht pro Anfrage:

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, um das Fenster zu bestätigen, mit dem das laufende Modell tatsächlich geladen wurde. OLLAMA_KV_CACHE_TYPE quantisiert 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 großen Fenster gibt das Halbieren 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 zwei Anfragen gleichzeitig verarbeitet, verdoppelt sich daher der gerade veranschlagte Wert. Das ist die Grundlage für die Auswahl der Anzahl paralleler Slots und eines Warteschlangenlimits.

Was auf einem VPS mit 8, 16 oder 32 GB passt

Budget für Gewichte, zusätzlich der 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 benötigt 2.6 GB und lässt Raum für ein langes 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, weil die Untergrenze 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 benötigt 8.9 GB, passt also ebenfalls. Der Vergleich dieser beiden Modelle mit Ihren eigenen Prompts ist die nützlichste Stunde, die Sie zu diesem Thema investieren können.

32 GB. 14B mit q8_0 (16 GB) und 32B mit q4_K_M (20 GB) lassen sich beide laden. Der 32B-Build mit einem großen Fenster wird an die Speichergrenze stoßen. Überwachen Sie daher ollama ps, statt dies vorauszusetzen.

Welche Fähigkeiten durch Quantisierung zuerst beeinträchtigt werden

Quantisierungsfehler verteilen sich nicht gleichmäßig auf die Aufgaben eines Modells. Die Sprachflüssigkeit bleibt am längsten erhalten. Genau deshalb wird der Schaden leicht übersehen: Ein stark quantisiertes Modell schreibt weiterhin fehlerfreie Sätze. Als Erstes leidet die Präzision. Dazu gehören die exakte Wiedergabe einer Versionsnummer, einer API-Signatur oder eines Datums. Auch lange Schlussfolgerungsketten sind betroffen, bei denen ein kleiner Fehler in Schritt zwei in Schritt acht zu einer falschen Antwort führt. Dasselbe gilt für strikt vorgegebene Ausgabeformate, bei denen eine falsche Klammer einen Tool-Aufruf scheitern lässt.

Letzteres ist der praktische Test. Wenn ein Modell JSON zurückgeben muss, das Ihr Code verarbeitet, zeigt sich der Quantisierungsschaden als Parserfehler und nicht als vage schlechtere Prosa. Sie bemerken ihn also noch am selben Tag. Ein Coding-Agent ist die strengste Variante dieses Tests, weil er das Modell durch eine Folge von Tool-Aufrufen steuert. Daher wird das Verbinden eines Agents mit Ihrem Ollama-Server eine zu aggressive Quantisierung innerhalb eines Nachmittags sichtbar machen.

Unterhalb von 4 Bit nimmt der Qualitätsverlust stark zu. Der q3- und der 2-Bit-Typ sind für Situationen gedacht, in denen ein großes Modell auf kleiner Hardware betrieben werden soll. Sie sind eine sinnvolle Option, wenn die Alternative darin besteht, das Modell überhaupt nicht auszuführen. Als Standardauswahl sind sie jedoch ungeeignet. Der Unterschied zwischen q4_K_M und q8_0 ist klein genug, dass eine veröffentlichte Perplexity-Tabelle keine verlässliche Entscheidung für Ihren Anwendungsfall ermöglicht. Versuchen Sie daher nicht, die Frage auf diesem Weg zu klären. Führen Sie beide Varianten mit 30 eigenen Prompts aus und prüfen Sie die Ausgabe.

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: bei strukturierter Extraktion, Tool-Aufrufen 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 Baseline, um festzustellen, wie viel Ihr Vier-Bit-Build eingebüßt hat. Die Bereitstellung mit fp16 benötigt dreimal so viel Speicher wie mit q4_K_M. Den Unterschied erkennen die meisten Menschen bei einem Blindtest nicht. Auf einem System, das nur über die CPU arbeitet, 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 entsprechen fast demselben RAM (Arbeitsspeicher). Das größere Modell verfügt über mehr Wissen. Testen Sie dies mit Ihren eigenen Prompts, statt es einfach zu übernehmen.

CPU-only inference is limited by memory bandwidth

Die meisten VPS-Tarife haben keine GPU. Daher läuft das Modell im Systemspeicher auf der Host-CPU. Die Generierung wird dann durch die Speicherbandbreite und nicht durch die Rechenleistung begrenzt, weil zur Erzeugung jedes Tokens alle Gewichte einmal gelesen werden müssen. Dadurch entsteht eine Obergrenze, die nicht davon abhängt, 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

Fünfzig GB/s sind 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 Zahlen daher als eine Obergrenze, die niemand erreicht. Entscheidend ist die Tendenz: Auf der CPU verdoppelt eine Halbierung der Bitzahl pro Gewicht 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 akzeptabel ist, hängt vom Modell ab. Nemotron 3.5 Lightning auf einem VPS rechnet das für einen bestimmten Build, Tag und RAM-Wert vollständig 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. Daher spart die Begrenzung der Antwort mit num_predict oft mehr Wartezeit ein als eine weitere Reduzierung der 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 Kerne helfen dabei, erhöhen 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 und lassen Sie Ihre Messwerte diese Angaben überstimmen.

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 existiert. Verweisen Sie in einer Modelfile auf die nicht quantisierten Gewichte:

FROM /path/to/my/model/f16

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

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 mit dem eigenen Tool von llama.cpp und importieren anschließend die fertige GGUF-Datei. Dieser Importweg hat eine eigene Fehlerquelle: Eine nicht übereinstimmende Chat-Vorlage führt dazu, dass das Modell unbrauchbare Antworten erzeugt. Der Import einer GGUF-Datei in Ollama beschreibt diesen Vorgang ausführlich. Mit der Zeile quantization aus ollama show prüfen Sie, ob der Build wie gewünscht durchgeführt wurde.

Was bei Fehlern angezeigt wird

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 zusammen mit dem KV-Cache nicht in den VRAM (Video-RAM, also den Speicher der Grafikkarte) gepasst haben. Deshalb wurde ein Teil des Modells im Systemspeicher abgelegt. Die Geschwindigkeit fällt dann fast auf das reine CPU-Niveau ab, weil jedes Token auf die langsame 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 beim Laden 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 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 wurden schlechter, obwohl Sie nichts geändert haben. Zwei Builds desselben Modells können in ollama ls unter unterschiedlichen 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 exakt dem Tag aus, den Ihr Client anfordert, und lesen Sie die Zeile quantization, anstatt 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 Arbeitsspeicher verfügbar ist und die Aufgabe empfindlich auf kleine Fehler reagiert, beispielsweise beim Tool Calling oder bei 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 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. Außerdem werden die empfindlichsten Tensoren in einem breiteren Datentyp gespeichert. Q8_0 erreicht aus demselben Grund 8.5 Bit statt acht. Verwenden Sie beim Schätzen den Messwert: 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 VPS nur mit CPU?

Addieren Sie Gewichte, KV-Cache und Reserve. Qwen3 8B mit q4_K_M benötigt 5.2 GB für die Gewichte. Bei der standardmäßigen Fenstergröße von 4096 Token benötigt der Cache zusätzlich 0.6 GB. Damit ergibt sich ein Mindestbedarf von etwa 5.8 GB, bevor Speicher für Berechnungspuffer und das Betriebssystem berücksichtigt wird. Bei einer Fenstergröße von 32k 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 zusammen mit dem KV-Cache nicht in den VRAM passten. Ollama hat daher einen Teil oder das gesamte Modell im Arbeitsspeicher des Systems abgelegt. Die häufigste Ursache ist eine Kontextfenstergröße, die die Kapazität der GPU übersteigt. Der Cache wird beim Laden des Modells für das gesamte Fenster reserviert. Verringern 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.