gpt-oss-120b auf einem GPU VPS ausführen (96 GB VRAM)

gpt-oss-120b ist das Open-Weight-Reasoning-Modell von OpenAI und läuft auf einem einzelnen GPU VPS mit 96 GB VRAM. Seine Mixture-of-Experts-Gewichte liegen nativ im 4-Bit-Format MXFP4 vor. Laut OpenAI benötigt das Modell dadurch weniger als 80 GB Speicher, sodass Platz für den KV-Cache bleibt. Diese Anleitung behandelt den Speicherbedarf, die Einrichtung mit Ollama und vLLM sowie realistische Erwartungen.

Was ist gpt-oss? Modelle, Lizenz und Architektur

gpt-oss bezeichnet zwei Open-Weight-Reasoning-Modelle mit Mixture-of-Experts-Architektur von OpenAI. Sie wurden am 5. August 2025 als gpt-oss-120b und gpt-oss-20b veröffentlicht. „Open Weight“ bedeutet, dass du die trainierten Gewichte herunterladen und selbst ausführen kannst. Das entspricht nicht vollständig Open Source: Die Gewichte sind veröffentlicht, über Trainingsdaten oder Trainingscode sagt das jedoch nichts aus.

Beide Modelle stehen unter der Apache-2.0-Lizenz. Der Beitrag zur Veröffentlichung bei Hugging Face nennt zusätzlich eine kurze ergänzende Nutzungsrichtlinie. Lies daher beide Texte, bevor du ein kommerzielles Produkt veröffentlichst. Intern besitzt gpt-oss-120b 36 Schichten mit jeweils 128 Experten, von denen pro Token vier aktiv sind. gpt-oss-20b hat 24 Schichten, 32 Experten und ebenfalls vier aktive Experten. Die Attention wechselt zwischen Schichten mit vollständigem Kontext und Schichten mit einem Sliding Window von 128 Token. Beide Modelle unterstützen bis zu 128K Token Kontext.

VRAM-Bedarf von gpt-oss: Passt 120b in 96 GB?

Ja. Die Ollama-Bibliothek gibt für die Gewichte von gpt-oss:120b eine Größe von 65 GB an. Auf einer Grafikkarte mit 96 GB bleiben damit etwa 31 GB für KV-Cache, Aktivierungen und CUDA-Kontext. Die Gewichte belegen einen festen Speicheranteil; der KV-Cache wächst mit jedem Kontext-Token und jeder gleichzeitigen Anfrage.

Die Formel für den KV-Cache lautet: Byte pro Token = 2 (Keys und Values) × Schichten × KV-Heads × Head-Dimension × Byte pro Element. Für gpt-oss-120b ergibt das 2 × 36 Schichten × 8 KV-Heads × 64 Head-Dimension × 2 Byte (BF16) = 73.728 Byte, also etwa 72 KiB pro Token. Die Werte für Heads und Dimension stammen aus der gpt-oss-Modelldokumentation von NVIDIA. Das ist der ungünstigste Fall, bei dem jede Schicht den vollständigen Kontext zwischenspeichert. Die Hälfte der Schichten nutzt ein Sliding Window mit 128 Token. Eine Engine, die das berücksichtigt, benötigt je nach Engine und Version weniger Speicher.

Betrachte diese Werte als Obergrenze: Der Pool mit 26 GB reicht ungefähr für zwei vollständige 128K-Sequenzen, zehn Sequenzen mit 32K oder vierzig mit 8K. Für eine andere Grafikkarte ersetzt du die Zeilen für VRAM und Gewichte und wiederholst die Berechnung. Die allgemeine Methode findest du in der Anleitung zur VRAM-Berechnung für LLMs.

GPU VPS vorbereiten: Treiber und Docker

Bereite zuerst den Host vor. Für einen neuen GPU VPS reicht diese kurze Checkliste:

• Prüfe, ob der Treiber die Grafikkarte erkennt. nvidia-smi sollte die GPU und ungefähr 96 GB Speicher anzeigen.
• Installiere Docker nach der Anleitung zum Installieren von Docker unter Ubuntu, wenn du vLLM oder Open WebUI verwenden möchtest.
• Ermögliche Containern den GPU-Zugriff mithilfe der Anleitung zum NVIDIA Container Toolkit, statt die Treiberschritte hier zu wiederholen.
• Gib keinen Inferenz-Port im Internet frei. Binde ihn an localhost oder beschränke den Zugriff und informiere dich über die Konfiguration von UFW, bevor du einen Port öffnest.

nvidia-smi
docker run –rm –gpus all ubuntu nvidia-smi

Inferenz-Engine wählen: Ollama, vLLM oder llama.cpp

Der Beitrag zur Veröffentlichung bei Hugging Face nennt transformers, vLLM, llama.cpp und Ollama als Engines für gpt-oss. Welche davon passt, hängt von deinem Workload und nicht vom Modell ab.

Beginne mit Ollama, wenn du in wenigen Minuten einen funktionierenden Endpoint brauchst. Wechsle zu vLLM, sobald gleichzeitige Anfragen wichtiger als eine schnelle Einrichtung werden.

gpt-oss-120b mit Ollama auf einem GPU VPS ausführen

Installiere Ollama und lade anschließend gpt-oss:120b herunter. Vermeide den Tag gpt-oss:120b-cloud: Er läuft im Ollama-Dienst und nicht auf deinem Server.

curl -fsSL https://ollama.com/install.sh | sh
ollama pull gpt-oss:120b
ollama run gpt-oss:120b

Prüfe, ob das Modell vollständig auf der GPU liegt und nicht zwischen GPU und CPU aufgeteilt ist: ollama ps zeigt das geladene Modell und die Prozessoraufteilung an. nvidia-smi sollte ungefähr 65 GB oder mehr belegten VRAM melden.

ollama ps
nvidia-smi

Die API lauscht auf Port 11434; die OpenAI-kompatiblen Endpoints liegen unter /v1. Ollama verwendet eine eigene Standardkontextlänge, die weit unter den 128K des Modells liegen kann. Prüfe sie und erhöhe sie gezielt. Nutze dabei die Tabelle oben, um den KV-Cache zu berechnen.

curl http://localhost:11434/v1/chat/completions \
  -H „Content-Type: application/json“ \
  -d ‚{„model“:“gpt-oss:120b“,“reasoning_effort“:“medium“,
       „messages“:[{„role“:“user“,“content“:“Explain MXFP4 in two sentences.“}]}‘

gpt-oss-120b mit vLLM und OpenAI-kompatibler API bereitstellen

Dieser Abschnitt behandelt nur die Besonderheiten von gpt-oss. Für die allgemeine Container-Einrichtung verwendest du die Anleitung zu vLLM mit Docker. Das vLLM-Rezept setzt vLLM 0.10.1 oder neuer voraus und nutzt das Image vllm/vllm-openai.

docker run –gpus all –ipc=host -p 127.0.0.1:8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:latest \
  –model openai/gpt-oss-120b \
  –max-model-len 32768 \
  –gpu-memory-utilization 0.90 \
  –tool-call-parser openai \
  –enable-auto-tool-choice

• –max-model-len verwendet standardmäßig das Maximum des Modells. Der Wert 32.768 begrenzt den KV-Cache pro Sequenz. Wähle ihn anhand der Speichertabelle.
• –gpu-memory-utilization legt fest, welchen Anteil des VRAM vLLM belegen darf. Die Beispiele im Rezept verwenden Werte zwischen 0,85 und 0,95.
• –tool-call-parser openai aktiviert zusammen mit –enable-auto-tool-choice Funktionsaufrufe. vLLM unterstützt für tool_choice nur den Wert auto.
• Die Werte 0,90 und 32.768 sind Ausgangspunkte aus der obigen Speicherberechnung und keine Herstellerempfehlungen. Lege einen getesteten Image-Tag fest, sobald das Setup funktioniert.

Die Rezeptseiten von vLLM nennen H100, H200 und B200 als unterstützte NVIDIA-GPUs, jedoch nicht die RTX PRO 6000. Lies deshalb die Release Notes für den Tag, den du herunterlädst. Nach dem Start antwortet der Endpoint unter http://localhost:8000/v1.

Reasoning-Stufen, Tool-Nutzung und Kontextlänge bei gpt-oss

• Reasoning-Aufwand: low, medium und high gewichten Latenz und Antwortqualität unterschiedlich. medium ist die Voreinstellung in Ollama. Laut Model Card lässt sich die Stufe im System-Prompt festlegen, etwa mit „Reasoning: high“. Ollama akzeptiert außerdem reasoning_effort unter /v1/chat/completions.
• Reasoning-Ausgabe: Das Modell erzeugt vor der Antwort eine Gedankenkette. Ollama gibt sie in einem separaten message.thinking-Feld zurück; vLLM kann sie überspringen, wenn include_reasoning auf false gesetzt ist. Blende sie in Ansichten für Endnutzer standardmäßig aus.
• Funktionsaufrufe und strukturierte Ausgaben: Beides sind native Funktionen. Ollama akzeptiert tools unter /v1/chat/completions, aber kein tool_choice, und bietet einen JSON-Modus. vLLM benötigt die beiden Flags aus dem vorherigen Abschnitt.
• Kontextlänge: nativ 128K Token. Im oben berechneten ungünstigsten Fall belegt eine vollständige Sequenz etwa 9,7 GB KV-Cache.
• Prompt-Format: Das Modell funktioniert nur mit dem Harmony-Format korrekt. Engines wenden es über Chat-Templates an, daher solltest du die Chat-Endpoints verwenden.

Welche Leistung bietet gpt-oss-120b auf einer GPU?

Konkrete Token pro Sekunde nennen wir nicht: Die veröffentlichten Messwerte, die sich finden ließen, beziehen sich nicht auf diese GPU. Ein Wert von einer anderen Grafikkarte wäre irreführend. Folgende Faktoren bestimmen das Ergebnis.

• Aktive Parameter: Pro Token werden nur 5,1B der insgesamt 117B Parameter verarbeitet, was die Dekodierung auf einer einzelnen Grafikkarte begünstigt.
• Batch-Größe: vLLM fasst gleichzeitige Anfragen zu Batches zusammen. Dadurch steigt der Gesamtdurchsatz, während einzelne Anfragen langsamer werden.
• Kontextlänge: Lange Prompts verlängern die Prefill-Phase. Ein größerer Cache erfordert außerdem mehr Speicherzugriffe pro erzeugtem Token.
• Reasoning-Aufwand: high erzeugt vor der Antwort mehr Reasoning-Token. Die Latenz steigt deshalb auch bei unveränderter Token-Geschwindigkeit.
• Engine und Version: Die Kernel von Ollama, vLLM und llama.cpp unterscheiden sich. Auch die Unterstützung für gpt-oss wird laufend weiterentwickelt.

Führe Lasttests mit deinen echten Prompts durch und beobachte dabei gemeinsam die Zeit bis zum ersten Token, die Geschwindigkeit pro Anfrage und den Gesamtdurchsatz. Ein GPU-Server für KI-Workloads kann sich in einem einzelnen Chat schnell anfühlen, unter zehn gleichzeitigen Anfragen aber ein ganz anderes Bild zeigen.

Chat-Oberfläche für gpt-oss mit Open WebUI einrichten

Open WebUI kommuniziert mit Ollama und jedem OpenAI-kompatiblen Endpoint. Es funktioniert daher mit beiden oben beschriebenen Setups. Die Anleitung zu Open WebUI behandelt den Container; hier folgen die Besonderheiten von gpt-oss.

• Verwende für Ollama die Basis-URL auf Port 11434. Für vLLM fügst du eine OpenAI-kompatible Verbindung hinzu, deren Basis-URL auf /v1 endet, sowie einen Platzhalterschlüssel.
• Innerhalb eines Containers verweist localhost auf den Container selbst. Verwende deshalb die Adresse des Hosts.
• Das Reasoning wird getrennt von der Antwort übertragen. Für eine feste Stufe trägst du „Reasoning: high“ in den System-Prompt einer Modellvoreinstellung ein.

Läuft gpt-oss-20b auf einem kleineren Server?

Ja. gpt-oss-20b besitzt insgesamt 21B Parameter, von denen 3,6B aktiv sind. Laut OpenAI benötigt es weniger als 16 GB Speicher, während der Ollama-Download 14 GB groß ist. Eine GPU mit mindestens 16 GB VRAM bietet dafür eine gute Basis.

Der Betrieb ohne GPU ist möglich, aber langsamer. Laut Ollama läuft das 20b-Modell auf Systemen mit nur 16 GB Speicher. Da allein die Gewichte 14 GB belegen, benötigt ein reiner CPU-VPS deutlich mehr RAM für Betriebssystem und Kontext. Die Geschwindigkeit hängt von Speicherbandbreite und Kernanzahl ab; konkrete Werte nennen wir nicht. Ein CPU-Server mit viel RAM eignet sich für einen Nutzer, einen Prototyp oder einen Agenten mit wenig Traffic. Bei gleichzeitigen Nutzern, langen Kontexten oder gpt-oss-120b solltest du auf eine GPU wechseln. Die 65 GB großen Gewichte von gpt-oss-120b sind auf einem CPU-VPS kaum praktikabel.

Warum gpt-oss auf einem Contabo GPU VPS ausführen?

Die obige Speicherberechnung setzt eine Grafikkarte mit 96 GB voraus. Genau das bietet der GPU VPS bei Contabo: eine dedizierte NVIDIA RTX PRO 6000 Blackwell Server Edition mit 96 GB GDDR7-VRAM. Laut dem Beitrag zur Markteinführung umfasst der Plan außerdem 18 vCPU, 96 GB RAM und 900 GB NVMe-Speicher für 999 € pro Monat zuzüglich Mehrwertsteuer.

Ein rund um die Uhr laufender Inferenz-Endpoint oder Agent passt gut zu einem festen Monatspreis, da die Rechnung nicht mit der Nutzung steigt. Vergleiche die Preise für GPU VPS verschiedener Anbieter, um die Optionen abzuwägen. Für gpt-oss-20b oder ein kleines Experiment ist ein Cloud VPS mit viel RAM ein günstiger Ausgangspunkt. Hier zahlt sich das gute RAM-pro-Euro-Verhältnis der Core-Reihe aus. Weitere Grundlagen findest du in der Anleitung zur LLM-Inferenz auf einem GPU VPS.

FAQ: gpt-oss auf einem GPU VPS ausführen

Haftungsausschluss: Die in diesem Artikel genannten Produktspezifikationen, Funktionen und Preise können sich ändern und je nach Region, Abrechnungszeitraum und laufenden Aktionen abweichen. Aktuelle Angaben, Preise und lokale Wechselkurse findest du auf der offiziellen Website des jeweiligen Anbieters oder der jeweiligen Marke.