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?

Um Qwen 3.8 27B auf einem VPS auszuführen, benötigen Sie zunächst einen vorhandenen Model-Tag. Am 4. August 2026 enthält die Ollama-Bibliothek überhaupt keinen qwen3.8-Eintrag. Der 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 diesen 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 Context-Token gespeichert wird. Damit scheiden Tarife mit 8 GB und 16 GB vollständig aus. Auf einem üblichen VPS mit zweikanaligem DDR4 liegt die Obergrenze bei ungefähr 3 Tokens pro Sekunde. Das ist langsamer, als die meisten Menschen lesen.

Woher kommt die 3.8? Wahrscheinlich von der Parameteranzahl. Die Ollama-Seite für qwen3.6:27b nennt 27.8B Parameter. 27.8 lässt sich später leicht als 3.8 erinnern. Außerdem gibt es ein qwen3.5:27b, denselben Q4_K_M-Build aus der vorherigen Version. Prüfen Sie die aktuelle Liste, bevor Sie einen Befehl kopieren, auf der Ollama-Seite mit den qwen3.6-Tags. Falls später ein echter qwen3.8 veröffentlicht wird, gelten die Berechnungen hier weiterhin. Sie hängen von der Parameteranzahl und der Bitanzahl pro Gewicht 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. Die Auswahl lässt sich daher direkt auf dem System schnell klären.

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 dem diese Anleitung basiert. Die Library enthält außerdem qwen3.6:27b-q8_0 und qwen3.6:27b-bf16 für dieselben Gewichte mit höherer Präzision. Zusätzlich gibt es mehrere 35b-a3b-Tags für MoE-Modelle (Mixture of Experts), die sich auf der CPU deutlich anders verhalten. Weitere Informationen folgen weiter unten.

Anzahl der Parameter 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 exakt 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 nominalen 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 gibt einen Durchschnittswert an. Dieser liegt im Durchschnitt nahe bei 4.9. Derselbe Effekt zeigt sich am anderen Ende der Skala: 56 GB für BF16 entsprechen 16.1 Bits pro Gewicht statt pauschal 16 Bits, 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. Deshalb wird die Zeile mit 19.8 GB mit den 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 ausschließlich die CPU verwendet, verdoppelt sich dadurch der Speicherverkehr pro Token. Dadurch halbiert sich auch ungefähr die Anzahl der Tokens pro Sekunde. Q4_K_M ist allein aus diesem Grund die richtige Standardeinstellung.

Die 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. Dort geht den meisten Anwendern tatsächlich 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 dichten Modellen dieser Größenklasse verwendet: 64 Layer, 8 Key/Value-Heads mit GQA (Grouped-Query Attention) und eine Headdimension von 128. Das ergibt bei f16 256 KiB pro Token, also 8 GB bei 32k Tokens und 32 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.

Deshalb ist der Kontext von 256K auf der Modellseite eher eine Schlagzeile als ein konkreter Plan. Ihn bei f16 vollständig zu belegen, würde zusätzlich zu den Gewichten 64 GB Cache benötigen. Auf der Maschine wurden bereits 17 GB für die Gewichte belegt. Ollama verwendet standardmäßig nicht das gesamte Kontextfenster. Es lädt ein deutlich kleineres Fenster. Sie können es mit OLLAMA_CONTEXT_LENGTH gezielt vergrößern. Erhöhen Sie den Wert schrittweise und prüfen Sie nach jeder Änderung ollama ps.

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. Dadurch sinkt der Bedarf für 32k Tokens von 8 GB auf 4 GB. Dafür ist Flash Attention erforderlich. Setzen Sie daher zusätzlich OLLAMA_FLASH_ATTENTION=1 und bestätigen Sie die Reduzierung in ollama ps, statt anzunehmen, dass die Einstellung übernommen wurde. OLLAMA_NUM_PARALLEL=1 ist ebenso wichtig. Ollama kann mehrere Anfragen gleichzeitig verarbeiten. Jeder Slot erhält dabei einen eigenen Kontextbereich. Wenn Sie die Parallelität auf dem Standardwert belassen, vervielfacht sich der eingeplante Cache unbemerkt.

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 Kontext-Token, die neben den Gewichten bei einem f16-Cache auf einem Linux-VPS ohne grafische Oberfläche passen. Dabei bleiben etwa 1.5 GB für das Betriebssystem und ein kleiner zusätzlicher Puffer frei. Eine 0 bedeutet, dass bereits die Gewichte selbst nicht 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 schafft keine Abhilfe. Ollama bildet die GGUF-Datei per Memory-Mapping ab. Sobald die residenten Speicherseiten den RAM übersteigen, beginnt der Kernel, sie auszulagern und erneut einzulesen. Für jedes Token müssen dann Gigabytes vom Datenträger gelesen werden. Die Maschine verbringt viel Zeit mit iowait und verarbeitet deutlich weniger als ein Token pro Sekunde.

32 GB sind der Einstiegspunkt. Die Gewichte belegen 17 GB. Damit bleiben ungefähr 13 GB frei, was mit einem Puffer für etwa 32k Kontext-Token bei f16 reicht. Q8_0-Gewichte mit 30 GB passen in dieser RAM-Klasse überhaupt nicht.

64 GB bieten ausreichend Spielraum. Bei Q4 bleiben etwa 128k Kontext-Token frei. Q8_0-Gewichte passen mit ungefähr 64k verbleibenden Token. Bevor Sie für Q8 64 GB RAM bezahlen, sollten Sie sich über den Nutzen im Klaren sein: etwas bessere Ausgaben bei halber Geschwindigkeit auf einer Maschine, die bereits langsam war. Für fast alle Anwendungsfälle ist Q4 mit einem längeren Kontext der bessere Kompromiss.

Wie schnell ist CPU-Inferenz auf einem VPS?

Die Erzeugung eines Tokens mit 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 der 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 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 etwa 2. Ein System mit zweikanaligem DDR5-4800 hat eine Obergrenze von 4.5. Rechnen Sie daher mit etwa 3.

Die großen Serverzeilen müssen mit Vorsicht interpretiert werden. Eine EPYC-Plattform mit zwölf Speicherkanälen hat 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 Tenants auf diesem Rechner gemeinsam genutzt wird. Ein Slice mit 8 vCPUs verfügt daher nicht über zwölf exklusive Speicherkanäle. GPU-orientierte Anleitungen behandeln diesen Punkt oft nicht. Er erklärt, 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 kurzzeitig. Sobald die Kerne Daten schneller anfordern, als der Speichercontroller sie liefern kann, verursachen zusätzliche Threads nur noch Scheduling-Overhead. Setzen Sie OLLAMA_NUM_THREAD auf die Anzahl der physischen Kerne, messen Sie und testen Sie anschließend die Hälfte dieses Werts. Bei vielen Shared-Tarifen ist die niedrigere Einstellung schneller.

Die Verarbeitung des Prompts verhält sich anders. Prefill, also der Durchlauf über Ihre Eingabe, bevor das erste Token erscheint, ist eher rechengebunden als bandbreitengebunden. Deshalb skaliert er mit der Anzahl der Kerne. In der Praxis führt das bei einem langen Prompt zu einer längeren Pause vor dem ersten Ausgabetoken, gefolgt von der oben genannten langsamen, gleichmäßigen Rate. Messen Sie beide Phasen separat mit --verbose. Der Befehl gibt für jede Anfrage ein prompt eval rate und ein eval rate aus.

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

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-Grafikkarte mit 24 GB erreicht bei diesen Gewichten maximal 59 Tokens pro Sekunde. Eine aktuelle Data-Center-Karte erreicht 197. Diese Lücke lässt sich nicht durch das Anpassen der Thread-Anzahl schließen. Die Grafikkarte betreibt ihren Speicher mit 1008 GB/s, während Ihr VPS nur einige Dutzend erreicht.

Legen Sie die Grenze daher anhand der Arbeitslast fest, nicht anhand persönlicher Vorlieben. CPU-Inferenz ist die richtige Wahl, wenn die Verarbeitung asynchron erfolgt und niemand auf das Ergebnis wartet: etwa die Zusammenfassung eines Dokumentenbestands über Nacht oder ein nächtlicher Klassifizierungsjob, der läuft, während Sie schlafen. 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 ausreichende Batching-Reserve, und die Warteschlange wächst einfach weiter.

Der Kostenvergleich ist weniger eindeutig, als es zunächst scheint. Ein VPS mit 64 GB wird jede Stunde des Monats berechnet, unabhängig davon, ob das Modell geladen ist. Eine GPU-Instanz wird dagegen nur für die Stunden berechnet, in denen Sie sie betreiben. Wenn Sie die GPU tatsächlich zwei Stunden pro Tag nutzen, kann die gemietete GPU sowohl schneller als auch günstiger sein. Ermitteln Sie zuerst Ihre Auslastung und vergleichen Sie anschließend die Preise. Auswahl eines VPS mit einer GPU beschreibt, was Sie direkt an der Instanz prüfen sollten. vLLM setzt sich bei parallelen Anfragen auf einer GPU gegenüber Ollama durch, weil es diese korrekt bündelt.

Es gibt noch eine dritte Möglichkeit, die oft übersehen wird. Lassen Sie das 27B-Modell für Batch-Verarbeitung auf der CPU laufen und verwenden Sie für interaktive Anfragen ein gehostetes API-Modell. Es gibt keinen Grund, dass ein einziges Modell beide Aufgaben übernehmen muss.

Ollama installieren und den eigenen Rechner messen

Das Installationsskript ist das offizielle Skript. Es richtet einen systemd-Dienst ein, der unter einem dedizierten ollama-Benutzer ausgeführt wird.

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 die Anzahl der Tokens pro Sekunde während der Generierung. prompt eval rate ist die Prefill-Geschwindigkeit. load duration ist die Zeit, die zum Lesen der Gewichte vom Datenträger benötigt wurde. Deshalb ist OLLAMA_KEEP_ALIVE=60m gesetzt: Auf der CPU kostet das erneute Laden von 17 GB vom Datenträger bei jeder Anfrage mehr Zeit als die Anfrage selbst.

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 an 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 können Sie zusätzlich zu den Gewichten etwa ein Gigabyte erwarten. Bei einem Cache im f16-Format wären es 2 GB. Die Spalte PROCESSOR sollte 100% CPU anzeigen. Wenn dort etwas anderes steht, verwendet ein Prozess eine GPU. Die Geschwindigkeitswerte in diesem Leitfaden beschreiben dann nicht Ihren Rechner.

Fehlerbilder und die exakt angezeigten Zeichenfolgen

Das Modell wird nicht geladen. 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 gute Fehlerfall, weil Ollama den Speicherbedarf vor der Speicherzuweisung geprüft hat, 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 verwertbaren Informationen 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 passiert, wenn die Prüfung vor dem Laden 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. Dasselbe gilt 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 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 Swap verwendet. Die Lösung besteht in einer geringeren Kontextlänge oder in weniger geladenen Modellen. 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 in den verfügbaren Speicher passen.

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

Wofür ein 27B-Modell ausschließlich auf der CPU 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 einen Chat ist das unbrauchbar, für eine Warteschlange jedoch problemlos geeignet. Dokumentzusammenfassungen, das stapelweise Verschlagworten, die Extraktion von Feldern aus einem Dateibestand und unbeaufsichtigte Code-Reviews tolerieren diese Geschwindigkeit, weil niemand auf die Antwort wartet.

Das Argument des Datenschutzes ist der entscheidende Punkt. Das Modell läuft auf Hardware, die Sie mieten und kontrollieren. Keine Anfrage verlässt den Server. Außerdem fallen keine Kosten pro Token an. Für regulierte Daten ist das selbst bei drei Tokens pro Sekunde viel wert. Vergleichen Sie dies sachlich mit der Alternative: Self-Hosting eines Modells in Frontier-Größe erfordert eine Größenordnung mehr Hardware. Ein 27B-Modell auf der CPU ist der günstigste Punkt auf dieser Skala, an dem die Ausgabe noch lesenswert ist.

Wenn Sie Ollama zum ersten Mal installieren, behandelt 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 vorausgesetzt werden. Veröffentlichen Sie Port 11434 nicht im Internet. Ollama wird ohne eigene Authentifizierung ausgeliefert. Jeder, der den Port erreicht, kann daher 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 qwen3.8-Namespace. 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 fast sicher die als Versionsnummer erinnerte Parameteranzahl von 27.8B. Prüfen Sie https://ollama.com/library/qwen3.6/tags für die aktuelle Liste. Verwenden Sie qwen3.6:27b, wenn Sie das neueste veröffentlichte 27B-Modell laden möchten. 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 ungefähr 1.5 GB. Der KV-Cache benötigt bei f16 ungefähr 1 GB je 4000 Kontext-Tokens. 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 bei jedem Token erneut von der Festplatte liest. 64 GB bieten Platz für einen langen Kontext oder für Q8_0-Gewichte mit 30 GB.

Wie viele Tokens pro Sekunde liefert ein 27B-Modell auf der 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 ungefähr 3 Tokens pro Sekunde und liefert etwa 2. Ein System mit zweikanaligem DDR5-4800 erreicht theoretisch ungefähr 4.5 und liefert etwa 3. Plattformen 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 daher 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. Dafür benötigen Sie einen Tarif mit 64 GB. Außerdem werden pro Token fast doppelt so viele Daten aus dem Speicher gelesen, wodurch sich die Tokens pro Sekunde ungefähr halbieren. 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 gering ist oder eine Person auf die Antwort wartet. Eine GPU mit 24 GB Speicher erreicht mit diesen Gewichten ungefähr 59 Tokens pro Sekunde. Ein typischer VPS erreicht dagegen 2 oder 3. Die GPU wird 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 normalerweise schneller und günstiger. Für kontinuierliche Batch-Verarbeitung mit niedriger Priorität ist der dauerhaft laufende VPS günstiger.