Qwen 3.8 27B auf einem VPS mit Ollama ausführen

Kann man Qwen 3.8 27B auf einem VPS ohne GPU ausführen?

Um Qwen 3.8 27B auf einem VPS auszuführen, benötigen Sie das Tag qwen3.8:27b. Seit dem 21. Oktober 2026 führt die Ollama-Bibliothek dieses als lokal abrufbares Tag: 27,3 Milliarden Parameter, Q4_K_M-Quantisierung, Apache 2.0-Lizenz, ein 256K-Kontextfenster und ein 18 GB großer Download, der einen Vision-Projektor von etwa 0,9 GB enthält. Ollama hat die Unterstützung für Qwen 3.8 27B in v0.32.12 hinzugefügt, die am 14. August 2026 veröffentlicht wurde; eine ältere Installation erfordert daher zuerst ein Upgrade. Stand 29. Oktober 2026 ist die aktuelle stabile Version v0.40.13, die am 28. Oktober 2026 veröffentlicht wurde.

Die kurze Antwort lautet: Ja, auf einem VPS mit 32 GB RAM oder mehr, allerdings langsam. Ein dichtes 27B-Modell benötigt bei Q4 etwa 17 GB RAM allein für die Gewichte, noch bevor ein einziges Token an Kontext gespeichert wird. Das schließt 8 GB- und 16 GB-Pläne vollständig aus. Auf einem üblichen Zweikanal-DDR4-VPS liegt die Obergrenze bei etwa 3 Token pro Sekunde, was langsamer ist als die Lesegeschwindigkeit der meisten Menschen.

Die früheren 27B-Tags sind weiterhin in der Bibliothek verfügbar: qwen3.6:27b und qwen3.5:27b sind beides Q4_K_M-Builds ähnlicher Größe. Qwen3.8-27B behält die Architektur von Qwen3.6-27B bei, und die offiziellen Konfigurationsdateien für beide weisen das gleiche Layer-Layout auf, sodass die unten stehende Speicherberechnung für beide gilt. Überprüfen Sie die aktuelle Liste, bevor Sie einen Befehl kopieren, auf der Ollama qwen3.8 Tag-Seite. Die Berechnung hier hängt von der Parameteranzahl, den Bits pro Gewicht und dem Attention-Layout ab, nicht von der Versionsnummer.

Welchen Ollama-Tag Sie abrufen sollten und wie Sie ihn prüfen

Das Abrufen eines nicht vorhandenen Tags führt zu einer eindeutigen Fehlermeldung. Daher lässt sich dies direkt auf dem System schnell klären. Ein vorhandener Tag kann lokal trotzdem nicht ausführbar sein. Genau das führt bei GLM 5.2, das in der Bibliothek aufgeführt, aber nur aus Ollamas Cloud bereitgestellt wird häufig zu Problemen.

ollama --version
ollama pull qwen3.8:27b
ollama show qwen3.8:27b

ollama show gibt die Architektur, die Parameteranzahl, die Kontextlänge und die Quantisierung des tatsächlich vorhandenen Tags aus. Wenn die Parameterzeile 27.3B und die Quantisierungszeile Q4_K_M enthält, verwenden Sie den Build, auf den sich diese Anleitung bezieht. Die Bibliothek enthält außerdem qwen3.8:27b-q8_0 und qwen3.8:27b-bf16 für dieselben Gewichte mit höherer Präzision, 27b-mtp-Varianten sowie die Tags 27b-nvfp4, 27b-mxfp8, 27b-mlx und 27b-mlx-bf16, die auf der Tag-Seite als MLX gekennzeichnet sind. Dieses Format ist für Apple Silicon und nicht für eine Linux-VPS vorgesehen. Im Gegensatz zu qwen3.6 enthält der Eintrag qwen3.8 keine 35b-a3b-Tags. Diese MoE-Modelle (Mixture of Experts) befinden sich weiterhin unter qwen3.6 und verhalten sich auf der CPU deutlich anders. Weitere Informationen dazu folgen unten.

Parameteranzahl mal Bytes pro Gewichtung

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.98,
    "notes": "published tag qwen3.8:27b, language model file"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.5,
    "bits_per_weight": 5.7,
    "notes": "computed, no official library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 18,
    "bits_per_weight": 5.27,
    "notes": "published tag 27b-nvfp4, MLX build, one file including the vision encoder"
  },
  {
    "label": "Q8_0",
    "size_gb": 29,
    "bits_per_weight": 8.5,
    "notes": "published tag 27b-q8_0, language model file"
  },
  {
    "label": "BF16",
    "size_gb": 55,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16, language model file"
  }
]

Die Formel besteht aus einer Zeile. Bytes der Gewichtungen = Parameter * Bits pro Gewichtung / 8. Bei sauberen 4 Bit entsprächen 27,3 Milliarden Parameter 13,7 GB. Die Sprachmodelldatei im ausgelieferten Q4_K_M-Tag ist 17 GB groß, was in der Praxis 4.98 Bit pro Gewichtung entspricht.

Diese Differenz ist kein Fehler. K-Quant-Formate speichern nicht jeden Tensor mit der nominellen Breite. Die Tensoren, die bei der Komprimierung am meisten an Qualität verlieren, erhalten mehr Bits. Die Tensor-Auflistung von Ollama für die ausgelieferte qwen3.8:27b-Datei zeigt diese bei Q6_K: die Ausgabeschicht, etwa die Hälfte der Feed-Forward-Down-Projektionen, die Attention-V-Projektionen in etwa der Hälfte der Full-Attention-Schichten und etwa die Hälfte der fusionierten QKV-Projektionen in den Linear-Attention-Schichten. Die kleinen Normalisierungstensoren verbleiben bei voller 32-Bit-Präzision. Das Token-Embedding, die Attention-Q- und K-Projektionen sowie die Feed-Forward-Gate- und Up-Projektionen verbleiben wie der Großteil des Modells bei Q4_K. Der Name des Formats ist ein Durchschnittswert, und dieser Durchschnitt liegt nahe bei 5. Der gleiche Effekt zeigt sich am anderen Ende der Skala: 55 GB für BF16 entsprechen 16.1 Bit pro Gewichtung statt glatten 16. Hier ist das Token-Embedding wie alles andere BF16, und der geringe Überschuss stammt aus den Metadaten der Datei, den auf 32-Bit belassenen Normalisierungstensoren und der Tatsache, dass die angegebene Größe auf das nächste Gigabyte gerundet ist.

Planen Sie das Budget für das gesamte Tag ein, nicht nur für die Sprachmodelldatei. Jedes GGUF-Tag von qwen3.8:27b liefert zusätzlich einen Vision-Projektor von etwa 0,9 GB aus, weshalb das Q4_K_M-Tag mit 18 GB gelistet ist.

Q5_K_M hat keinen veröffentlichten Tag im offiziellen qwen3.8-Bibliothekseintrag, daher wird die Zeile mit 19.5 GB für dieses Format mit den üblichen 5,7 Bit pro Gewichtung berechnet, statt gemessen. Q8_0 verdoppelt Q4 fast auf 29 GB. Auf einem System, das nur über eine CPU verfügt, verursacht diese Verdopplung den doppelten Speicherverkehr pro Token, was die Tokens pro Sekunde in etwa halbiert. Allein aus diesem Grund ist Q4_K_M hier die richtige Standardeinstellung. Wenn Sie bei dieser Entscheidung eher die Qualitätsseite als die Speicherseite betrachten möchten, zeigt ein genauerer Vergleich von Q4, Q8 und fp16, ab wann die Ausgabe tatsächlich an Qualität verliert.

Was der KV-Cache bei wachsendem Kontext kostet

Die Gewichte sind ein fester Kostenfaktor. Der KV-Cache (Key- und Value-Cache, also der Attention-Zustand, den das Modell für jedes bereits verarbeitete Token speichert) wächst linear mit der Kontextlänge. Hier geht den meisten Benutzern tatsächlich der RAM aus.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 0.25,
    "kv_q8_gb": 0.13
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 0.5,
    "kv_q8_gb": 0.25
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  }
]

Diese Werte stammen aus der Konfigurationsdatei des Modells. Qwen3.8-27B ist wie Qwen3.6-27B ein Modell mit hybrider Attention. Nur 16 der 64 Layer verwenden vollständige Attention und behalten einen Cache, der mit jedem Token wächst. Diese Layer haben unter GQA (Grouped-Query Attention) 4 Key/Value-Heads und eine Head-Dimension von 256. Die übrigen 48 Layer verwenden lineare Attention (Gated DeltaNet) und halten stattdessen einen Zustand fester Größe. Nach meiner Berechnung sind das unabhängig von der Kontextlänge etwa 150 MB pro Konversations-Slot. Das entspricht bei f16 64 KiB pro Token, also 2 GB bei 32k Tokens und 8 GB bei 128k. Verlassen Sie sich bei Ihrer eigenen Maschine nicht auf meine Berechnung. Laden Sie das Modell und lesen Sie die Spalte SIZE von ollama ps. Sie weist Gewichte, Cache und Overhead als einen Gesamtwert aus.

Der Kontext von 256K, der auf der Modellseite angegeben ist, ist mit dieser Architektur erreichbar. Er ist aber nicht kostenlos. Das Füllen des gesamten Kontexts mit f16 benötigt zusätzlich zu den Gewichten etwa 16 GB Cache. Die Gewichte belegen auf einer Maschine bereits 17 GB. Ollama stellt standardmäßig nicht das vollständige Kontextfenster bereit. Die Dokumentation zur Kontextlänge legt den Standardwert anhand des VRAM fest: 4k Tokens bei weniger als 24 GiB, 32k zwischen 24 und 48 GiB und 256k ab 48 GiB. Ein VPS, der nur die CPU verwendet, hat überhaupt keinen VRAM und landet daher in der 4k-Stufe. Sie erhöhen den Wert gezielt mit OLLAMA_CONTEXT_LENGTH. Diese Variable gilt für den gesamten Server und ist nicht die einzige Stellschraube. Mit der Einstellung von num_ctx für die einzelne Anfrage können Sie für alle anderen Anfragen einen niedrigen Standardwert beibehalten, während ein längerer Auftrag ein größeres Kontextfenster erhält. Erhöhen Sie den Wert schrittweise und prüfen Sie nach jeder Änderung ollama ps.

Zwei Einstellungen halten den Cache klein. OLLAMA_KV_CACHE_TYPE=q8_0 speichert den Cache mit 8 statt 16 Bit und reduziert ihn bei 32k Tokens von 2 GB auf 1 GB. Dafür ist Flash Attention erforderlich. Setzen Sie daher auch OLLAMA_FLASH_ATTENTION=1 und prüfen Sie die Verringerung in ollama ps, statt davon auszugehen, dass die Einstellung übernommen wurde. Wenn Sie den Cache-Typ bisher nicht geändert haben, erklärt eine Anleitung zu q8_0 und f16 für den KV-Cache von Ollama, wie Sie beide Variablen setzen und die Werte vor und nach der Änderung ablesen. OLLAMA_NUM_PARALLEL=1 ist ebenso wichtig. Ollama kann mehrere Anfragen gleichzeitig bedienen. Jeder Slot erhält einen eigenen Kontextbereich. Eine höhere Parallelität vervielfacht daher unbemerkt den Cache, den Sie einplanen müssen. Der aktuelle Standardwert ist bereits 1. Die nachfolgende Überschreibung setzt ihn fest auf diesen Wert. Wenn mehr als eine Person diese Maschine verwendet, beginnen die Probleme an dieser Stelle der Vervielfachung. Wie viele gleichzeitige Benutzer ein selbst gehostetes Modell bedienen kann wird lange vor der Anzahl der CPU-Kerne durch Cache-Slots und die Warteschlangentiefe bestimmt.

Was passt in 8, 16, 32 und 64 GB RAM

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": null,
    "notes": "Q4 fits with room for long context. Q8 weights fit, but usable context needs a measured total memory budget."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 256,
    "q8_max_ctx_ktok": 256,
    "notes": "Both fit with the full 256K window."
  }
]

Lesen Sie die beiden Zahlen als Tausende von Token an Kontext, die neben den Gewichten und dem Vision-Projektor bei f16-Cache auf einen kopflosen Linux-VPS passen, wobei etwa 1,5 GB für das Betriebssystem und ein kleiner Puffer verbleiben. Eine Null bedeutet, dass die Gewichte selbst nicht in den Speicher passen, also gar nichts möglich ist; null bedeutet, dass die Gewichte passen, aber für diese Stufe kein nutzbarer Kontextwert bestätigt ist.

8 GB und 16 GB sind keine knappen Fälle. 17 GB an Gewichten passen nicht in 16 GB RAM, und keine Kontexteinstellung ändert daran etwas. Auch das Hinzufügen von Swap rettet das System nicht. Ollama verwendet Memory-Mapping für die GGUF-Datei; sobald die residenten Seiten den RAM überschreiten, beginnt der Kernel mit dem Auslagern und erneuten Einlesen, wodurch jedes Token Gigabytes von der Festplatte lädt. Der Server verharrt bei hohem iowait und generiert deutlich weniger als ein Token pro Sekunde.

32 GB sind der Einstiegspunkt. Die Gewichte belegen 17 GB, der Vision-Projektor benötigt etwa 0,9 GB, und es verbleiben grob 12,5 GB, was für etwa 128k Token an f16-Kontext inklusive Puffer ausreicht. Q8_0-Gewichte mit 29 GB passen zwar in 32 GB, aber der nutzbare Kontext hängt auch vom Vision-Projektor, dem Cache, dem Betriebssystem und dem Laufzeitspeicher ab. Überprüfen Sie den gesamten Speicherbedarf auf Ihrem System, bevor Sie Q8 auf dieser Stufe als lauffähig betrachten.

64 GB bieten Komfort. Q4 lässt Raum für das volle 256k-Fenster, und Q8_0-Gewichte passen zusammen mit den vollen 256k an Kontext ebenfalls hinein. Bevor Sie für 64 GB bezahlen, um Q8 nutzen zu können, sollten Sie sich über den Nutzen im Klaren sein: etwas bessere Ergebnisse bei halber Geschwindigkeit auf einer Maschine, die ohnehin bereits langsam war. Q4 erreicht bereits 128k Token auf einem 32-GB-System, was für fast jeden den besseren Kompromiss darstellt.

Wie schnell ist die CPU-Inferenz auf einem VPS?

Für die Erzeugung eines Tokens aus einem dichten Modell muss jeder Gewichtswert einmal aus dem Speicher gelesen werden. Nicht nur einige davon. Alle. Die Geschwindigkeitsgrenze wird daher nicht durch die Anzahl der Kerne bestimmt, sondern durch die Speicherbandbreite geteilt durch die Größe der Gewichtswerte. Bei Q4 entspricht das 17 GB Speicherverkehr pro Token.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

Das sind Obergrenzen, keine Messwerte. Die tatsächliche Ausgabe erreicht ungefähr 50 bis 70 Prozent des angezeigten Werts, weil Speicherlatenz und unvollständiges Prefetching verhindern, dass die theoretische Spitzenleistung erreicht wird. Ein VPS mit zweikanaligem DDR4-3200 hat eine Obergrenze von 3 Tokens pro Sekunde. Rechnen Sie daher mit ungefähr 2. Ein System mit zweikanaligem DDR5-4800 hat eine Obergrenze von 4.5. Rechnen Sie daher mit ungefähr 3.

Bei den großen Serverzeilen ist ein Hinweis erforderlich. Eine EPYC-Plattform mit zwölf Speicherkanälen erreicht 460.8 GB/s und eine Obergrenze von 27.1 Tokens pro Sekunde. Sie mieten jedoch keinen vollständigen EPYC-Server. Die Speicherbandbreite ist eine hostweite Ressource, die von allen Mandanten auf diesem Rechner gemeinsam verwendet wird. Ein Slice mit 8 vCPUs verfügt daher nicht über zwölf exklusive Speicherkanäle. Anleitungen mit Schwerpunkt auf GPUs lassen diesen Punkt vollständig außer Acht. Das ist der Grund, warum sich zwei VPS-Tarife mit identischer vCPU-Anzahl beim gleichen Modell um den Faktor drei unterscheiden können.

Mehr vCPUs helfen aus demselben Grund nur kurze Zeit. Sobald die Kerne Daten schneller anfordern, als der Speichercontroller sie liefern kann, verursachen zusätzliche Threads nur noch Scheduling-Overhead. Ollama bietet keine systemweite Umgebungsvariable für die Thread-Anzahl. Setzen Sie daher num_thread in der Anfrage options auf die Anzahl Ihrer physischen Kerne, messen Sie und versuchen Sie es anschließend mit der Hälfte dieser Anzahl. Bei vielen gemeinsam genutzten Tarifen ist die niedrigere Einstellung schneller.

Die Prompt-Verarbeitung verhält sich anders. Prefill, also der Durchlauf über Ihre Eingabe vor dem ersten ausgegebenen Token, ist eher rechengebunden als bandbreitengebunden und skaliert daher mit der Anzahl der Kerne. Praktisch bedeutet das eine lange Pause vor dem Beginn der Ausgabe bei einem großen Prompt, gefolgt von der oben genannten gleichmäßigen, langsamen Rate. Messen Sie beide Phasen getrennt mit --verbose. Dieser Befehl gibt für jede Anfrage einen prompt eval rate und einen eval rate aus.

Wenn das dichte 27B-Modell einfach zu langsam ist, prüfen Sie vor dem Aufgeben bei der CPU die Tags qwen3.6:35b-a3b. Diese aktivieren pro Token ungefähr 3 Milliarden Parameter statt aller 27.3 Milliarden. Dadurch sinkt der Speicherverkehr pro Token um annähernd eine Größenordnung, obwohl die Datei auf dem Datenträger größer ist. Sie tauschen dabei RAM-Bedarf gegen Geschwindigkeit. Auch die Wahl der Laufzeitumgebung ist hier relevant, und Ollama und llama.cpp bieten unterschiedliche Steuerelemente zur CPU-Optimierung für denselben zugrunde liegenden Inferenzcode.

Wann stattdessen GPU-Stunden mieten

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

Die gleiche Formel, angewendet auf die veröffentlichte Speicherbandbreite von GPUs, führt zu einer anderen Antwortkategorie. Eine Consumer-Karte mit 24 GB hat eine Obergrenze von 59 Token pro Sekunde bei diesen Gewichten. Eine aktuelle Rechenzentrumskarte erreicht 197. Diese Lücke lässt sich nicht durch das Anpassen der Thread-Anzahl schließen. Die Karte betreibt ihren Speicher mit 1008 GB/s, während Ihr VPS nur zweistellige Werte erreicht.

Ziehen Sie die Grenze daher anhand der Arbeitslast und nicht nach persönlichen Vorlieben. CPU-Inferenz ist die richtige Wahl, wenn die Arbeit asynchron erfolgt und niemand darauf wartet: die nächtliche Zusammenfassung eines Dokumentenstapels oder ein nächtlicher Klassifizierungsjob, der läuft, während Sie schlafen. Mieten Sie eine GPU in dem Moment, in dem eine Person auf eine Ausgabe wartet oder Anfragen schneller eintreffen, als Ihr System sie verarbeiten kann. CPU-Laufzeiten sind nicht auf eine Anfrage gleichzeitig beschränkt: Der llama.cpp-Server dokumentiert paralleles Decoding und Continuous Batching sowohl auf der CPU als auch auf der GPU, und Ollama kann ebenfalls parallele Anfragen bedienen, allerdings auf Kosten eines höheren Cache-Verbrauchs. Entscheidend ist Ihre gemessene Verarbeitungsrate im Verhältnis zur Eingangsrate; messen Sie daher einen realistischen Batch auf Ihrem eigenen System. Sobald Anfragen schneller eintreffen, als sie verarbeitet werden, wächst die Warteschlange.

Der Kostenvergleich ist weniger offensichtlich, als er scheint. Ein 64-GB-VPS wird für jede Stunde des Monats berechnet, unabhängig davon, ob das Modell geladen ist oder nicht, während bei einer stündlichen GPU-Miete Rechenkosten von Speicherkosten getrennt werden, die auch nach dem Stoppen der Instanz anfallen können. Wenn Ihre tatsächliche Nutzung zwei Stunden pro Tag beträgt, kann die gemietete GPU sowohl schneller als auch günstiger sein. Ermitteln Sie zuerst Ihren Auslastungsgrad und kalkulieren Sie dann die Kosten. Auswahl eines VPS mit GPU behandelt die Punkte, die Sie auf der Instanz selbst prüfen sollten, und vLLM ist Ollama überlegen, sobald Sie gleichzeitige Anfragen auf einer GPU bedienen, da es diese effizient bündelt.

Es gibt eine dritte Option, die oft vergessen wird. Behalten Sie das 27B-Modell für Batch-Aufgaben auf der CPU und schalten Sie ein gehostetes API-Modell vor den interaktiven Pfad. Nichts zwingt Sie dazu, beide Aufgaben mit einem einzigen Modell zu bedienen.

Ollama installieren und die eigene Hardware messen

Das Installationsskript ist die offizielle Variante; es richtet einen systemd-Dienst ein, der unter einem dedizierten ollama-Benutzer läuft.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version sollte 0.32.12 oder neuer ausgeben, die erste Version mit Unterstützung für Qwen 3.8 27B. Prüfen Sie free -g, bevor Sie Daten herunterladen. Da die Ausgabe in GiB erfolgt, kann ein System mit beworbenen 32 GB RAM in der Spalte total etwa 29 anzeigen; vergleichen Sie den verfügbaren Arbeitsspeicher mit den oben genannten Gewichten und dem Cache-Budget.

Legen Sie die Laufzeitoptionen in einem systemd-Override fest, nicht in Ihrer Shell. Das Modell läuft innerhalb des Dienstes und hat daher keinen Zugriff auf Ihre interaktive Umgebung.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.8:27b
ollama run qwen3.8:27b --verbose "Name two Linux distributions."

Die Ausgabe von --verbose ist der Messwert, um den es hier geht. eval rate entspricht Ihren Tokens pro Sekunde während der Generierung. prompt eval rate ist Ihre Prefill-Geschwindigkeit. load duration gibt an, wie lange das Laden der Gewichte von der Festplatte gedauert hat; deshalb ist OLLAMA_KEEP_ALIVE=60m gesetzt: Auf der CPU kostet das Neuladen von 17 GB von der Festplatte bei jeder Anfrage mehr Zeit als die Anfrage selbst. Das standardmäßige Idle-Timeout beträgt fünf Minuten. Dieser Zeitraum ist kurz genug, dass eine Batch-Warteschlange mit Pausen zwischen den Elementen diese Ladekosten wiederholt verursacht. Die Optionen zum dauerhaften Vorhalten eines Modells decken sowohl das Feld keep_alive pro Anfrage ab als auch die dauerhafte Speicherung der Einstellung über einen Neustart hinweg.

Prüfen Sie während das Modell geladen ist den Speicherbedarf von einem zweiten Terminal aus.

ollama ps

Die Spalte SIZE zeigt den tatsächlichen Speicherbedarf inklusive KV-Cache. Dieser sollte nahe bei der Summe aus Gewichten, Vision-Projektor und dem Wert für Ihre Kontextlänge aus der KV-Tabelle liegen. Bei 8192 Tokens mit einem 8-Bit-Cache beträgt der wachsende Teil des Caches nur etwa ein Viertel Gigabyte, im Vergleich zu 0.5 GB bei f16, zuzüglich des fixen linearen Attention-Zustands. In der Spalte PROCESSOR sollte 100% CPU stehen. Falls dort etwas anderes steht, belegt etwas die GPU und die Geschwindigkeitswerte in diesem Leitfaden treffen nicht auf Ihr System zu.

Fehlerbilder und die exakt angezeigten Zeichenfolgen

Das Modell wird nicht geladen. Ollama gibt eine Zeile aus, in der beide Werte genannt werden, etwa in der Form model requires more system memory (18.6 GiB) than is available (15.2 GiB). Das ist der erwartbare Fehler, weil Ollama die Prüfung vor der Speicherzuweisung durchführt, statt dies dem Kernel zu überlassen. Verringern Sie die Kontextlänge, verwenden Sie einen kleineren Tag oder wechseln Sie zu einem größeren Plan.

Der Prozess verschwindet während einer Antwort. Der Client zeigt keine hilfreiche Meldung, und journalctl -u ollama -n 50 zeigt, dass der Dienst neu gestartet wird. Führen Sie dmesg -T | tail aus. Eine Zeile mit Out of memory: Killed process ... (ollama) bedeutet, dass der OOM-Killer des Kernels den Prozess beendet hat. Das geschieht, wenn die Vorabprüfung erfolgreich war, der Cache während einer langen Unterhaltung aber über die Schätzung hinaus gewachsen ist. Verringern Sie die Kontextlänge.

Der Pull schlägt sofort fehl. Error: pull model manifest: file does not exist bedeutet, dass der Tag nicht in der Bibliothek vorhanden ist. Eine noch nicht veröffentlichte Versionsnummer erzeugt genau diesen Fehler. Das gilt auch für jeden Tippfehler im Tag. qwen3.8:27b selbst ist gültig. Wenn genau dieser Tag fehlschlägt, suchen Sie zuerst nach einem Tippfehler. Bestätigen Sie den Tag auf der Bibliotheksseite, bevor Sie die Ursache im Netzwerk suchen. Wenn ein gültiger Tag geladen wird, aber nicht ausgeführt werden kann, prüfen Sie ollama --version gegen 0.32.12.

Alles funktioniert, ist aber unerträglich langsam. Weniger als ein Token pro Sekunde auf einem System mit ausreichend RAM deutet eher auf Paging als auf fehlende Rechenleistung hin. Führen Sie während der Generierung vmstat 1 aus. Ein Wert ungleich 0 in der Spalte si oder so bedeutet, dass der Kernel den Swap verwendet. Verringern Sie in diesem Fall die Kontextlänge oder laden Sie weniger Modelle. Ein dauerhaft hoher Wert in wa ohne Swap-Aktivität bedeutet, dass die speicherabgebildeten Gewichte erneut von der Festplatte gelesen werden. Die Gewichte passen dann nicht wirklich in den Arbeitsspeicher.

Das erste Token benötigt 30 Sekunden, danach wird die Ausgabe schneller. Das ist Prefill und normal. Ein langer System-Prompt muss für jede Anfrage erneut verarbeitet werden, wenn der Cache nicht verwendet werden kann. Kürzen Sie daher zuerst den System-Prompt, bevor Sie andere Einstellungen anpassen.

Wofür ein 27B-Modell auf reiner CPU-Basis tatsächlich geeignet ist

Setzen Sie Erwartungen auf Basis der Zahlen, nicht auf Basis von Hoffnungen. Bei zwei bis vier Tokens pro Sekunde dauert eine Antwort mit 500 Tokens zwischen zwei und vier Minuten. Das ist für Chats unbrauchbar, aber für Warteschlangenverarbeitung vollkommen praktikabel. Ein Modell, das vor der Antwort nachdenkt, verschlechtert diese Rechnung, da die verborgenen Denk-Tokens mit derselben langsamen Rate generiert werden wie die Antwort. Daher ist die Anpassung des Denkaufwands an die Aufgabe einer der wenigen Hebel, um eine Antwort zu verkürzen, ohne das Modell auszutauschen. Dokumentenzusammenfassungen, Massen-Tagging, Feld-Extraktion aus einem Dateirückstand und unbeaufsichtigte Code-Reviews tolerieren dies, da niemand auf die Antwort wartet. Programmierunterstützung liegt genau an dieser Grenze. Daher zahlt sich die Anbindung eines Coding-Agents an ein selbst gehostetes Modell für Hintergrundaufgaben wie Commit-Nachrichten und Test-Gerüste aus, nicht jedoch für Inline-Vorschläge, auf die Sie aktiv warten.

Das Argument der Privatsphäre ist das entscheidende. Das Modell läuft auf Hardware, die Sie mieten und kontrollieren; keine Anfrage verlässt das System und es gibt keine Abrechnung pro Token. Das ist selbst bei drei Tokens pro Sekunde für regulierte Daten viel wert. Wägen Sie dies ehrlich gegen die Alternative ab: Das Selbst-Hosting eines Frontier-Scale-Modells erfordert eine um eine Größenordnung höhere Hardwareausstattung, und ein 27B-Modell auf der CPU ist der günstigste Punkt auf dieser Kurve, an dem der Output noch lesenswert ist.

Um dies zu benchmarken, benötigen Sie echte strukturierte Eingabedaten. Die meisten öffentlichen Daten-APIs verlangen ein Konto, bevor Sie überhaupt den Durchsatz messen können. Das Demo-Schema von Strasmore (das wir betreiben) dokumentiert schreibgeschütztes SQL über US-Aktien- und Optionsdaten ohne Schlüssel und ohne Registrierung unter Verwendung von datenbankqualifizierten Tabellennamen: https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM global_markets.delayed_stocks_minute_aggs LIMIT 5. Die Demo-Limits liegen bei 500 Zeilen und 20 Sekunden pro Aufruf, mit Historie ab dem 1. Januar 2025 – komfortabel mehr, als ein System mit zwei Tokens pro Sekunde verarbeiten kann. Die vollständige Spaltenliste finden Sie unter https://ai.strasmore.com/api/demo/schema.

Falls dies Ihre erste Ollama-Installation ist, deckt die vollständige Anleitung zum Ausführen von Ollama auf einem VPS die Service-Einrichtung, die HTTP-API und die Firewall-Regeln ab, die dieser Leitfaden als bereits vorhanden voraussetzt. Setzen Sie Port 11434 nicht dem Internet aus. Die lokale API von Ollama erfordert keine Authentifizierung; daher kann jeder, der den Port erreicht, Ihr Modell nutzen.

FAQ

Gibt es ein Qwen 3.8 27B Modell auf Ollama?

Ja. Zum Stand 21. Oktober 2026 enthält die Ollama-Bibliothek einen qwen3.8-Eintrag, und qwen3.8:27b (auch mit latest getaggt) ist ein 18 GB großes Q4_K_M-Build eines dichten Modells mit 27,3 Milliarden Parametern, einem Vision-Projektor und einem 256K-Kontextfenster. Es läuft lokal und erfordert Ollama v0.32.12 oder neuer. Die älteren Tags qwen3.6:27b und qwen3.5:27b sind weiterhin gelistet. Prüfen Sie https://ollama.com/library/qwen3.8/tags für die aktuelle Liste. Ein Tag, das nicht existiert, schlägt mit Error: pull model manifest: file does not exist fehl.

Wie viel RAM benötige ich, um ein Qwen 27B Modell auf einem VPS auszuführen?

32 GB sind das praktische Minimum für Q4_K_M. Die Gewichte betragen 17 GB, der Vision-Projektor fügt etwa 0,9 GB hinzu, das Betriebssystem benötigt rund 1,5 GB und der KV-Cache beansprucht etwa 1 GB pro 16.000 Token Kontext bei f16, da nur 16 der 64 Schichten des Modells einen wachsenden Cache vorhalten. Ein 16-GB-Tarif kann die Gewichte nicht vollständig laden, und Swap hilft nicht, da die Datei speicherabgebildet (memory-mapped) ist und der Kernel sie bei jedem Token erneut von der Festplatte liest. 64 GB bieten Platz für das volle 256K-Fenster, selbst mit Q8_0-Gewichten bei 29 GB.

Wie viele Token pro Sekunde liefert ein 27B Modell auf der CPU?

Teilen Sie Ihre Speicherbandbreite durch die Größe der Gewichte und nehmen Sie davon 50 bis 70 Prozent. Ein VPS mit zwei Kanälen DDR4-3200 hat eine Obergrenze von etwa 3 Token pro Sekunde und liefert etwa 2. Ein System mit zwei Kanälen DDR5-4800 hat eine Obergrenze von etwa 4.5 und liefert etwa 3. Server-Plattformen mit mehr Kanälen sehen auf dem Papier deutlich besser aus, aber die Speicherbandbreite wird von jedem Mandanten auf dem Host geteilt. Messen Sie daher Ihre eigene Leistung mit ollama run qwen3.8:27b --verbose und lesen Sie die eval rate-Zeile.

Sollte ich auf einem VPS ohne GPU Q4 oder Q8 verwenden?

In fast allen Fällen Q4_K_M. Q8_0 ist 29 GB groß im Vergleich zu 17 GB; die Gewichte passen also in 32 GB, aber der Projektor, der Cache, das Betriebssystem und die Laufzeitumgebung lassen kaum Spielraum. 64 GB bieten Platz für langen Kontext. Q8_0 bewegt pro Token fast doppelt so viel Speicher, was Ihre Token pro Sekunde etwa halbiert. Der Qualitätsunterschied zwischen Q4_K_M und Q8_0 ist bei einem 27B-Modell für die meisten Aufgaben gering. Investieren Sie den RAM lieber in einen längeren Kontext, da dies die Fähigkeiten des Modells verändert, anstatt nur die Ausdrucksweise.

Wann ist das Mieten einer GPU günstiger als ein VPS mit viel RAM?

Wenn Ihre Auslastung gering ist oder eine Person auf die Antwort wartet. Eine GPU mit 24 GB Speicher hat eine theoretische Obergrenze von etwa 59 Token pro Sekunde bei diesen Gewichten, gegenüber geschätzten 2 oder 3 auf einem typischen VPS. Die stündlichen GPU-Rechenkosten enden, wenn die Instanz gestoppt wird, aber persistenter Speicher kann weiterhin Kosten verursachen. Ein 64-GB-VPS wird den ganzen Monat berechnet, egal ob das Modell geladen ist oder nicht. Kalkulieren Sie, wie viele Stunden am Tag Sie tatsächlich Token generieren. Der Break-even-Punkt hängt von den Mietpreisen, der Laufzeit und den Kosten für persistente Speicher ab. Kontinuierliche Batch-Arbeit mit niedriger Priorität ist der Bereich, in dem der ständig laufende VPS gewinnt.