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

Können Sie Qwen 3.8 27B auf einem VPS ohne GPU ausführen?

Für die Ausführung von Qwen 3.8 27B auf einem VPS benötigen Sie zunächst ein vorhandenes Modell-Tag. Am 4. August 2026 enthält die Ollama-Bibliothek jedoch überhaupt keinen Eintrag qwen3.8. Das nächstgelegene veröffentlichte 27B-Tag ist qwen3.6:27b: 27.8 Milliarden Parameter, Q4_K_M-Quantisierung und Apache-2.0-Lizenz. Alle folgenden Befehle und Zahlen verwenden dieses Tag mit Ollama v0.32.5, veröffentlicht am 27. Juli 2026.

Die kurze Antwort lautet: Ja, auf einem VPS mit 32 GB oder mehr, aber langsam. Ein dichtes 27B-Modell mit Q4 benötigt allein für die Gewichte etwa 17 GB RAM, bevor auch nur ein einziges Kontext-Token gespeichert wird. Damit scheiden Tarife mit 8 GB und 16 GB vollständig aus. Auf einem üblichen VPS mit zweikanaligem DDR4-RAM liegt die Obergrenze ungefähr bei 3 Tokens pro Sekunde. Das ist langsamer, als die meisten Menschen lesen.

Woher kommt die 3.8? Wahrscheinlich aus der Parameteranzahl. Auf der Ollama-Seite für qwen3.6:27b werden 27.8B Parameter angegeben. Die Zahl 27.8 kann später leicht als 3.8 erinnert werden. Außerdem gibt es ein qwen3.5:27b, denselben Q4_K_M-Build aus der vorherigen Veröffentlichung. Prüfen Sie die aktuelle Liste, bevor Sie einen Befehl kopieren, auf der Ollama-Seite für das qwen3.6-Tag. Falls später ein echtes qwen3.8 veröffentlicht wird, gelten die Berechnungen hier weiterhin. Sie hängen von der Parameteranzahl und den Bits pro Gewicht ab, nicht von der Versionsnummer.

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

Wenn Sie einen nicht vorhandenen Tag abrufen, wird ein eindeutiger Fehler ausgegeben. Das lässt sich daher direkt auf dem System schnell prüfen. 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 pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show gibt die Architektur, die Parameteranzahl, die Kontextlänge und die Quantisierung des tatsächlich vorhandenen Tags aus. Wenn die Parameterzeile 27.8B und die Quantisierungszeile Q4_K_M lautet, verwenden Sie den Build, auf den sich diese Anleitung bezieht. Die Bibliothek enthält für dieselben Gewichte außerdem qwen3.6:27b-q8_0 und qwen3.6:27b-bf16 mit höherer Präzision sowie mehrere 35b-a3b-Tags für MoE-Modelle (Mixture of Experts), die sich auf der CPU ganz anders verhalten. Darauf gehen wir weiter unten ein.

Parameteranzahl mal Bytes pro Gewicht

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

Die Formel besteht aus einer Zeile: Bytes der Gewichte = Parameter * Bits pro Gewicht / 8. Bei genau 4 Bits würden 27.8 Milliarden Parameter 13.9 GB belegen. Das ausgelieferte Q4_K_M-Tag hat 17 GB. In der Praxis entspricht das 4.89 Bits pro Gewicht.

Diese Abweichung ist kein Fehler. K-Quant-Formate speichern nicht jeden Tensor mit der nominellen Bitbreite. Tensoren, bei denen die Komprimierung die Qualität am stärksten beeinträchtigt, werden mit 5 oder 6 Bits gespeichert. Die Token-Embedding- und Ausgabeschichten bleiben normalerweise bei Q6_K oder Q8_0. Die Bezeichnung des Formats bezeichnet einen Durchschnitt. Dieser Durchschnitt liegt nahe bei 4.9. Derselbe Effekt zeigt sich am anderen Ende der Skala: 56 GB für BF16 entsprechen 16.1 Bits pro Gewicht und nicht pauschal 16, weil die Datei zusätzlich Metadaten und eine Embedding-Tabelle mit voller Präzision enthält.

Für dieses Modell gibt es kein veröffentlichtes Q5_K_M-Tag. Daher wird die Zeile mit 19.8 GB anhand der für dieses Format üblichen 5.7 Bits pro Gewicht berechnet und nicht gemessen. Q8_0 benötigt mit 30 GB fast doppelt so viel Speicher wie Q4. Auf einem System, das nur die CPU verwendet, verdoppelt sich dadurch der Speicherverkehr pro Token. Die Anzahl der Tokens pro Sekunde halbiert sich daher ungefähr ebenfalls. Q4_K_M ist allein aus diesem Grund die richtige Standardeinstellung. Wenn Sie statt der Speicherauslastung die Auswirkungen auf die Qualität vergleichen möchten, zeigt ein genauerer Vergleich von Q4, Q8 und fp16, ab wann die Ausgabe tatsächlich schlechter wird.

Kosten des KV-Cache bei wachsendem Kontext

Die Gewichte verursachen feste Kosten. 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 Systemen tatsächlich zuerst der RAM aus.

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

Diese Werte setzen die Architektur voraus, die Qwen bei seinen aktuellen Dense-Modellen dieser Größenklasse verwendet: 64 Layer, 8 Key/Value-Heads mit GQA (Grouped-Query Attention) und eine Headdimension von 128. Das entspricht bei f16 256 KiB pro Token, also 8 GB bei 32k Tokens und 32 GB bei 128k. Übernehmen Sie diese Berechnung nicht ungeprüft für Ihr eigenes System. Laden Sie das Modell und lesen Sie die Spalte SIZE von ollama ps. Sie enthält Gewichte, Cache und Overhead als eine Gesamtsumme.

Deshalb ist der Kontext von 256K auf der Modellkarte eher eine Leistungsangabe als ein konkreter Plan. Ihn bei f16 vollständig zu nutzen, würde zusätzlich zu den Gewichten 64 GB Cache erfordern. Für die Gewichte sind auf dem System bereits 17 GB belegt. Ollama stellt das vollständige Kontextfenster nicht standardmäßig bereit. Es lädt zunächst ein deutlich kleineres Fenster. Mit OLLAMA_CONTEXT_LENGTH können Sie es gezielt vergrößern. Diese Variable gilt für den gesamten Server und ist nicht der einzige Stellhebel. Mit der Einstellung von num_ctx für die einzelne Anfrage können Sie für alle anderen Anfragen einen kostengünstigen Standardwert beibehalten und nur für einen langen Auftrag ein größeres Fenster verwenden. Erhöhen Sie den Wert schrittweise und prüfen Sie ollama ps nach jeder Änderung.

Zwei Einstellungen halbieren den Cache oder reduzieren ihn noch stärker. OLLAMA_KV_CACHE_TYPE=q8_0 speichert den Cache mit 8 statt 16 Bit und reduziert den Bedarf für 32k Tokens von 8 GB auf 4 GB. Dafür ist Flash Attention erforderlich. Setzen Sie daher auch OLLAMA_FLASH_ATTENTION=1 und prüfen Sie die Reduzierung in ollama ps, statt davon auszugehen, dass die Einstellung angewendet wurde. OLLAMA_NUM_PARALLEL=1 ist ebenso wichtig. Ollama kann mehrere Anfragen gleichzeitig verarbeiten. Jeder Slot erhält einen eigenen Teil des Kontextes. Wenn Sie die Parallelität auf dem Standardwert belassen, vervielfacht sich der eingeplante Cache unbemerkt. Wenn mehrere Personen dieses System nutzen, beginnen hier die Probleme. Die Anzahl der gleichzeitigen Benutzer, die ein selbst gehostetes Modell bedienen kann, hängt lange vor der Kernanzahl von den Cache-Slots und der Warteschlangentiefe ab.

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

[
  {
    "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": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

Lesen Sie die beiden Zahlen als Tausende von Kontext-Tokens, die neben den Gewichten bei einem f16-Cache auf einem headless Linux-VPS mit etwa 1.5 GB für das Betriebssystem und einem kleinen zusätzlichen Puffer verfügbar sind. Eine Null bedeutet, dass die Gewichte selbst nicht in den Speicher passen und somit kein Kontext passt.

8 GB und 16 GB sind keine Grenzfälle. 17 GB Gewichte passen nicht in 16 GB RAM. Keine Einstellung für den Kontext ändert daran etwas. Auch zusätzlicher Swap-Speicher hilft nicht. Ollama bildet die GGUF-Datei per Memory-Mapping ab. Sobald mehr Seiten im Arbeitsspeicher benötigt werden, als RAM vorhanden ist, beginnt der Kernel, Seiten auszulagern und erneut einzulesen. Für jedes Token müssen dann Gigabytes von der Festplatte geladen werden. Der Server verbringt den Großteil der Zeit mit hohem iowait und erzeugt deutlich weniger als ein Token pro Sekunde.

32 GB sind der Einstiegspunkt. Die Gewichte belegen 17 GB. Damit bleiben ungefähr 13 GB übrig. Das reicht mit einem Puffer für etwa 32k Kontext-Tokens bei f16. Q8_0-Gewichte mit 30 GB passen auf dieser Stufe überhaupt nicht.

64 GB sind komfortabel. Bei Q4 bleiben etwa 128k Kontext-Tokens frei. Q8_0-Gewichte passen, und dahinter bleiben etwa 64k Tokens verfügbar. Bevor Sie für Q8 64 GB bezahlen, sollten Sie sich klar machen, was Sie dafür erhalten: eine etwas bessere Ausgabe bei halber Geschwindigkeit auf einem Rechner, der bereits langsam war. Q4 mit einem längeren Kontext ist für fast alle die bessere Wahl.

Wie schnell ist CPU-Inferenz auf einem VPS?

Die Erzeugung eines Tokens aus einem Dense-Modell bedeutet, dass jedes Gewicht einmal aus dem Speicher gelesen wird. Nicht nur einige davon. Alle. Die Geschwindigkeitsgrenze ist daher nicht die Anzahl Ihrer Kerne, sondern die Speicherbandbreite geteilt durch die Größe der Gewichte. 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. In der Praxis erreicht die Ausgabe ungefähr 50 bis 70 Prozent des angezeigten Werts, weil Speicherlatenzen und unvollständiges Prefetching verhindern, dass die theoretische Spitzenleistung erreicht wird. Ein VPS mit zweikanaligem DDR4-3200 hat eine Obergrenze von 3 Token pro Sekunde. Rechnen Sie daher mit etwa 2. Ein System mit zweikanaligem DDR5-4800 hat eine Obergrenze von 4.5. Rechnen Sie daher mit etwa 3.

Bei den großen Serverzeilen ist ein Hinweis erforderlich. Eine EPYC-Plattform mit zwölf Speicherkanälen bietet 460.8 GB/s und eine Obergrenze von 27.1 Token pro Sekunde. Sie mieten jedoch keinen vollständigen EPYC-Server. Die Speicherbandbreite ist eine hostweite Ressource, die von allen Mandanten auf diesem Rechner gemeinsam genutzt 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 aus. Das ist der Grund, warum sich zwei VPS-Tarife mit identischer vCPU-Anzahl beim selben 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 Planungsaufwand. Stellen Sie OLLAMA_NUM_THREAD auf die Anzahl Ihrer physischen Kerne, messen Sie und versuchen Sie anschließend die Hälfte dieser Zahl. Bei vielen gemeinsam genutzten Tarifen ist die niedrigere Einstellung schneller.

Die Prompt-Verarbeitung verhält sich anders. Prefill, also der Durchlauf über Ihre Eingabe, bevor der erste Token erscheint, ist eher rechen- als bandbreitengebunden. Deshalb skaliert sie mit der Anzahl der Kerne. In der Praxis entsteht bei einem großen Prompt eine lange Pause, bevor die Ausgabe beginnt. Danach folgt die oben genannte gleichmäßige, langsame Rate. Messen Sie beide Phasen getrennt mit --verbose. Für jede Anfrage werden dabei ein prompt eval rate und ein eval rate ausgegeben.

Wenn das Dense-Modell mit 27B einfach zu langsam ist, prüfen Sie die qwen3.6:35b-a3b-Tags, bevor Sie CPU-Inferenz aufgeben. Diese aktivieren pro Token ungefähr 3 Milliarden Parameter statt aller 27.8 Milliarden. Dadurch sinkt der Speicherverkehr pro Token um nahezu eine Größenordnung, obwohl die Datei auf dem Datenträger größer ist. Sie tauschen RAM-Verbrauch gegen Geschwindigkeit. Auch die Wahl der Runtime ist hier wichtig. Ollama und llama.cpp bieten unterschiedliche CPU-Tuning-Optionen für denselben zugrunde liegenden Inferenzcode.

Wann Sie stattdessen eine GPU-Stunde mieten sollten

[
  {
    "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
  }
]

Dieselbe Formel, auf die veröffentlichte GPU-Speicherbandbreite angewendet, führt zu einer anderen Einschätzung. Eine Consumer-Karte mit 24 GB erreicht bei diesen Gewichten maximal 59 Tokens pro Sekunde. Eine aktuelle Rechenzentrumskarte erreicht 197. Diese Lücke lässt sich nicht durch das Optimieren der Thread-Anzahl schließen. Die Karte arbeitet mit einer Speicherbandbreite von 1008 GB/s, während Ihr VPS nur einige Dutzend GB/s erreicht.

Ziehen Sie die Grenze daher anhand der Arbeitslast und nicht anhand persönlicher Vorlieben. CPU-Inferenz ist die richtige Wahl, wenn die Verarbeitung asynchron erfolgt und niemand auf das Ergebnis wartet: etwa bei der nächtlichen Zusammenfassung eines Dokumentenbestands oder bei einem Klassifizierungsjob, der während Ihres Schlafs läuft. Mieten Sie eine GPU, sobald eine Person auf die Ausgabe wartet oder sobald mehr als eine Anfrage alle 30 Sekunden eintrifft. Ein System ohne GPU hat keine Reserven für Batching, und die Warteschlange wächst einfach weiter.

Der Kostenvergleich ist weniger eindeutig, als es zunächst scheint. Ein VPS mit 64 GB wird für jede Stunde des Monats abgerechnet, unabhängig davon, ob das Modell geladen ist. Eine GPU-Instanz wird dagegen nur für die Stunden berechnet, in denen sie läuft. Wenn Sie die GPU tatsächlich zwei Stunden pro Tag nutzen, kann die gemietete GPU gleichzeitig schneller und günstiger sein. Ermitteln Sie zuerst Ihren Auslastungsgrad und berechnen Sie danach die Kosten. Einen VPS mit GPU auswählen beschreibt, worauf Sie bei der Instanz selbst achten sollten. Außerdem ist vLLM setzt sich bei gleichzeitigen GPU-Anfragen gegenüber Ollama ab, weil vLLM diese Anfragen korrekt bündelt.

Es gibt eine dritte Möglichkeit, die häufig übersehen wird. Lassen Sie das 27B-Modell für Batch-Verarbeitung auf der CPU laufen und schalten Sie für interaktive Anfragen ein gehostetes API-Modell vor. Es gibt keinen Grund, ein einziges Modell für beide Aufgaben zu verwenden.

Ollama installieren und den eigenen Rechner messen

Das Installationsskript ist das offizielle Skript. Es richtet einen systemd-Dienst ein, der als dedizierter Benutzer ollama läuft.

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

ollama --version sollte 0.32.5 oder höher ausgeben. Prüfen Sie free -g, bevor Sie etwas herunterladen. Wenn die Spalte total in der Zeile Mem einen Wert unter 32 anzeigt, brechen Sie hier ab und wählen Sie ein kleineres Modell. Das Herunterladen von 17 GB, die Sie nicht ausführen können, verschwendet eine Stunde und viel Speicherplatz.

Setzen Sie die Laufzeitoptionen in einem systemd-Override und nicht in Ihrer Shell. Das Modell läuft innerhalb des Dienstes und sieht daher Ihre interaktive Umgebung nicht.

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.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

Die Ausgabe von --verbose enthält die gesuchte Messung. eval rate ist Ihre Token-Rate pro Sekunde während der Generierung. prompt eval rate ist Ihre Prefill-Geschwindigkeit. load duration gibt an, wie lange das Einlesen der Gewichte vom Datenträger gedauert hat. Deshalb ist OLLAMA_KEEP_ALIVE=60m gesetzt: Auf der CPU kostet das erneute Einlesen von 17 GB vom Datenträger bei jeder Anfrage mehr Zeit als die Anfrage selbst. Das standardmäßige Leerlauf-Timeout beträgt fünf Minuten. Bei einer Batch-Warteschlange mit Pausen zwischen den Elementen fallen diese Ladekosten dadurch immer wieder an. Die Optionen, mit denen ein Modell resident bleibt decken sowohl das Anfragefeld keep_alive als auch eine Einstellung ab, die einen Reboot übersteht.

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

ollama ps

Die Spalte SIZE zeigt den tatsächlichen Speicherbedarf einschließlich des KV-Cache. Der Wert sollte nahe bei der Größe der Gewichte plus der Zeile für Ihre Kontextlänge in der KV-Tabelle liegen. Bei 8192 Tokens und einem 8-Bit-Cache sind zusätzlich zu den Gewichten etwa ein Gigabyte zu erwarten. Würde der Cache bei f16 bleiben, wären es 2 GB. Die Spalte PROCESSOR sollte 100% CPU anzeigen. Wenn dort etwas anderes steht, verwendet ein anderer Prozess eine GPU. Die Geschwindigkeitswerte in dieser Anleitung beschreiben dann nicht Ihren Rechner.

Fehlerfälle und die exakt angezeigten Zeichenfolgen

Das Modell kann nicht geladen werden. Ollama gibt eine Zeile aus, in der beide Werte genannt werden, im Format model requires more system memory (18.6 GiB) than is available (15.2 GiB). Das ist der unproblematische Fehlerfall, 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 verwertbare Meldung an, 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 jedoch ü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. Die Eingabe von qwen3.8:27b erzeugt genau diese Meldung. Das gilt auch für jeden Tippfehler in der Versionsnummer. Prüfen Sie den Tag auf der Bibliotheksseite, bevor Sie die Ursache im Netzwerk suchen.

Alles funktioniert, ist aber unerträglich langsam. Weniger als ein Token pro Sekunde auf einem System mit ausreichend RAM deutet auf Paging und nicht auf fehlende Rechenleistung hin. Führen Sie während der Generierung vmstat 1 aus. Ein Wert ungleich si oder so in der entsprechenden Spalte bedeutet, dass der Kernel den Swap verwendet. Abhilfe schaffen eine kleinere Kontextlänge oder weniger geladene Modelle. Ein dauerhaft hoher Wert in wa ohne Swap-Aktivität bedeutet, dass die speicherabgebildeten Gewichte erneut von der Festplatte gelesen werden. Das bedeutet, dass sie tatsächlich nicht vollständig in den Speicher passen.

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

Wofür ein CPU-only 27B tatsächlich geeignet ist

Setzen Sie die Erwartungen anhand der Zahlen und nicht anhand von Hoffnungen. Bei zwei bis vier Tokens pro Sekunde dauert eine Antwort mit 500 Tokens zwischen zwei und vier Minuten. Für Chat ist das unbrauchbar, für eine Warteschlange jedoch problemlos geeignet. Ein Modell, das vor der Antwort nachdenkt, verschlechtert diese Rechnung zusätzlich, weil die verborgenen Reasoning-Tokens mit derselben niedrigen Geschwindigkeit wie die Antwort generiert werden. Daher ist der Abgleich der Reasoning-Stufe mit der Aufgabe eine der wenigen Möglichkeiten, eine Antwort zu verkürzen, ohne das Modell zu wechseln. Dokumentzusammenfassungen, Massen-Tagging, Feldermittlung aus einem Rückstand von Dateien und unbeaufsichtigte Code-Reviews tolerieren diese Geschwindigkeit, weil niemand auf die Antwort wartet. Coding-Unterstützung liegt genau an dieser Grenze. Daher lohnt es sich, einen von Ihnen gehosteten Coding-Agent auf ein Modell anzusetzen, wenn Hintergrundaufgaben wie Commit-Nachrichten und Testgerüste erstellt werden sollen, nicht jedoch für Inline-Vorschläge, auf die Sie warten.

Das Datenschutzargument ist der entscheidende Punkt. Das Modell läuft auf Hardware, die Sie mieten und kontrollieren. Keine Anfrage verlässt den Server. Außerdem gibt es keine Abrechnung pro Token. Für regulierte Daten ist das selbst bei drei Tokens pro Sekunde viel wert. Vergleichen Sie dies dennoch ehrlich mit der Alternative: Self-Hosting eines Modells im Frontier-Maßstab benötigt eine Größenordnung mehr Hardware. Ein 27B auf der CPU ist auf dieser Skala der günstigste Punkt, an dem die Ausgabe noch lesenswert ist.

Für einen aussagekräftigen Benchmark benötigen Sie reale strukturierte Eingaben. Die meisten öffentlichen Daten-APIs verlangen jedoch ein Konto, bevor Sie überhaupt den Durchsatz messen können. Der Demo-Endpunkt von Strasmore (wir betreiben ihn) beantwortet schreibgeschützte SQL-Abfragen zu 22 Jahren US-Marktdaten ohne Key und ohne Registrierung. Ein GET auf https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 gibt JSON zurück, das Sie direkt in eine Prompt-Schleife einleiten können. Die Antwort enthält außerdem das exakte SQL, mit dem sie erzeugt wurde. So hat das Modell etwas zum Zusammenfassen, das Sie unabhängig prüfen können. Die Limits liegen bei 500 Zeilen und 20 Sekunden pro Aufruf. Das ist deutlich mehr, als eine Maschine mit zwei Tokens pro Sekunde verbrauchen wird. Die vollständige Spaltenliste finden Sie unter https://api.strasmore.com/v1/schema.

Wenn dies Ihre erste Ollama-Installation ist, beschreibt die vollständige Anleitung zum Ausführen von Ollama auf einem VPS die Einrichtung des Dienstes, die HTTP-API und die Firewall-Regeln, die in dieser Anleitung als bereits vorhanden vorausgesetzt werden. Veröffentlichen Sie Port 11434 nicht im Internet. Ollama wird ohne eigene Authentifizierung ausgeliefert. Daher kann alles, was den Port erreicht, Ihr Modell verwenden und Ihre Prompts lesen.

FAQ

Gibt es ein Qwen 3.8 27B-Modell in Ollama?

Nein. Am 4. August 2026 enthält die Ollama-Bibliothek keinen Namespace qwen3.8. Die vorhandenen 27B-Tags sind qwen3.5:27b und qwen3.6:27b. Beide sind Q4_K_M-Builds eines dichten Modells mit 27.8 Milliarden Parametern. Die 3.8 im Suchbegriff ist mit hoher Wahrscheinlichkeit die gemerkte Parameteranzahl von 27.8B, die fälschlich als Versionsnummer verstanden wurde. Prüfen Sie https://ollama.com/library/qwen3.6/tags auf die aktuelle Liste. Wenn Sie das neueste veröffentlichte 27B-Modell verwenden möchten, laden Sie qwen3.6:27b. Ein nicht vorhandener Tag 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 für Q4_K_M das praktische Minimum. Die Gewichte belegen 17 GB. Das Betriebssystem benötigt etwa 1.5 GB. Der KV-Cache benötigt bei f16 für jeweils 4000 Kontext-Tokens zusätzlich ungefähr 1 GB. Ein Tarif mit 16 GB kann die Gewichte überhaupt nicht aufnehmen. Swap hilft nicht, weil die Datei per Memory-Mapping eingebunden wird und der Kernel sie für jedes Token erneut vom Datenträger einliest. 64 GB lassen Raum für einen langen Kontext oder für Q8_0-Gewichte mit 30 GB.

Wie viele Tokens pro Sekunde liefert ein 27B-Modell auf einer CPU?

Teilen Sie die Speicherbandbreite durch die Größe der Gewichte. Nehmen Sie anschließend 50 bis 70 Prozent dieses Werts. Ein VPS mit zweikanaligem DDR4-3200 erreicht theoretisch fast 3 Tokens pro Sekunde und liefert ungefähr 2. Ein Rechner mit zweikanaligem DDR5-4800 erreicht theoretisch fast 4.5 und liefert ungefähr 3. Serverplattformen mit mehr Speicherkanälen sehen auf dem Papier deutlich besser aus. Die Speicherbandbreite wird auf dem Host jedoch von allen Mandanten gemeinsam genutzt. Messen Sie deshalb Ihren eigenen Wert mit ollama run qwen3.6:27b --verbose und lesen Sie die Zeile eval rate.

Sollte ich auf einem CPU-only-VPS Q4 oder Q8 verwenden?

In fast allen Fällen Q4_K_M. Q8_0 belegt 30 GB statt 17 GB. Daher benötigen Sie einen Tarif mit 64 GB. Außerdem muss pro Token fast doppelt so viel Speicher übertragen werden, wodurch sich die Anzahl der Tokens pro Sekunde ungefähr halbiert. Der Qualitätsunterschied zwischen Q4_K_M und Q8_0 ist bei einem 27B-Modell für die meisten Aufgaben gering. Verwenden Sie den zusätzlichen RAM stattdessen für einen längeren Kontext. Dieser verändert, was das Modell leisten kann, und nicht nur seine Formulierungen.

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

Wenn die Auslastung niedrig ist oder eine Person auf das Ergebnis wartet. Eine GPU mit 24 GB Speicher erreicht mit diesen Gewichten ungefähr 59 Tokens pro Sekunde, während ein typischer VPS 2 oder 3 erreicht. Die GPU wird außerdem nur für die tatsächlichen Betriebsstunden berechnet. Ein VPS mit 64 GB wird den ganzen Monat berechnet, unabhängig davon, ob das Modell geladen ist. Ermitteln Sie, wie viele Stunden pro Tag Sie tatsächlich Tokens generieren. Bei weniger als zwei oder drei Stunden ist die stundenweise GPU-Miete meist sowohl schneller als auch günstiger. Für kontinuierliche Batch-Verarbeitung mit niedriger Priorität ist der dauerhaft laufende VPS günstiger.