GPT-OSS-120B läuft selbst mit nur 8 GB VRAM hervorragend

• Mit der Option --cpu-moe von llama-cpp werden die MoE-Experten-Layer auf der CPU verarbeitet, während nur die Attention-Layer auf die GPU ausgelagert werden. So wird mit 5–8 GB VRAM eine hohe Prompt-Prefill-Leistung erreicht
• Auf der GPU verbleiben nur KV-Cache, Attention-Gewichte und -Aktivierungen, Routing-Tabellen, LayerNorm usw. als nicht-expertenbezogene Parameter, wodurch der Speicherverbrauch niedrig bleibt
• Selbst mit einer GPU auf dem Niveau einer RTX 3060 Ti und 64–96 GB System-RAM lässt sich ein 120B-Modell problemlos betreiben; optimale Leistung gibt es mit BF16-fähigen GPUs (RTX 3000+)
• Bei 5 GB VRAM wurden 8,15 ms pro Token (122,66 Token/s) erreicht, bei 8 GB VRAM verbesserte sich das auf 7,44 ms pro Token (134,44 Token/s)
• Die 120B-Architektur ist für Consumer-Hardware optimiert und ermöglicht auch bei knappen GPU-Ressourcen eine schnelle Ausführung

---

CPU-MoE- und GPU-Offloading-Struktur

• Mit der Option --cpu-moe werden die Experten-(MoE-)Layer vollständig auf der CPU verarbeitet
  • Beispiel: --n-cpu-moe 36 → alle 36 MoE-Blöcke laufen auf der CPU
  • Bei Bedarf können einige MoE-Blöcke zur Leistungsanpassung auf die GPU verschoben werden
• Auf der GPU verbleiben nur die folgenden Komponenten, um VRAM zu sparen
  • KV-Cache (Sequenz)
  • Attention-Gewichte und -Aktivierungen
  • Routing-Tabellen
  • LayerNorm und andere nicht-expertenbezogene Parameter
• Da die MoE-Gewichte nicht auf der GPU liegen, entfällt die Last großer MLP-Parameter

Speicher- und Hardware-Anforderungen

• GPU: 5–8 GB VRAM sind ausreichend (z. B. RTX 3060 Ti)
• Optimal ist eine GPU mit BF16-Unterstützung (RTX 3000-Serie oder neuer)
• System-RAM: mindestens 64 GB, idealerweise 96 GB
  • Mit Linux mmap können „heiße“ Experten-Layer im Speicher gehalten werden, auch wenn nicht das gesamte Modell in den RAM passt

Leistungswerte

Umgebung mit 5 GB VRAM

• Prompt-Verarbeitung: 8,15 ms/Token (122,66 Token/s)
• Inferenz: 55,44 ms/Token (18,04 Token/s)

Umgebung mit 8 GB VRAM (--n-cpu-moe 36, Rest auf GPU)

• Prompt-Verarbeitung: 7,44 ms/Token (134,44 Token/s)
• Inferenz: 39,03 ms/Token (25,62 Token/s)

Umgebung mit 22 GB VRAM (einige MoE-Blöcke auf GPU)

• Prompt-Verarbeitung: 6,13 ms/Token (163,01 Token/s)
• Inferenz: 32,45 ms/Token (30,82 Token/s)

Fazit

• Das Design von GPT-OSS-120B ist darauf optimiert, große Modelle auch auf Consumer-Hardware schnell auszuführen
• Dank der CPU-MoE-Struktur, die den VRAM-Bedarf senkt und gleichzeitig die Geschwindigkeit hält, eignet es sich besonders für Umgebungen mit begrenzten GPU-Ressourcen

---

Zentrale Fragen & Antworten

F1. Wie hoch ist der tatsächliche VRAM-Verbrauch in diesem Setup?

• Originalautor: Etwa 5 GB VRAM, wenn alle MoE-Blöcke auf der CPU laufen und nur die Attention-Layer auf der GPU liegen
• Zusätzliche Erklärung: Auf der GPU verbleiben nur KV-Cache, Attention-Gewichte und -Aktivierungen, Routing-Tabellen und LayerNorm

F2. Wie viel RAM wird mindestens benötigt?

• Originalautor: Mindestens 64 GB, idealerweise 96 GB
• Grund: Linux mmap hält „heiße“ Experten-Layer im Speicher und ermöglicht schnellen Zugriff, ohne das gesamte Modell laden zu müssen

F3. Wird es deutlich schneller, wenn einige MoE-Layer auf die GPU verschoben werden?

• Originalautor: Es kann etwas schneller werden, der Unterschied ist aber nicht groß
• Beispiel:
  • Alle MoE-Blöcke auf CPU: Prompt 134 Token/s, Inferenz 25 Token/s
  • 8 MoE-Blöcke auf GPU: Prompt 163 Token/s, Inferenz 30 Token/s
  • Der VRAM-Verbrauch steigt dabei auf 22 GB

F4. Welche GPU ist geeignet?

• Originalautor: Ab RTX 3060 Ti ist ausreichend, empfohlen wird BF16-Unterstützung (RTX 3000+)
• Grund: Alle Layer außer MoE laufen in BF16

F5. Wie sieht das Kommando-Setup aus?

• Originalautor: Beispiel auf Basis von PR #15157

  ~/build/llama.cpp/build-cuda/bin/llama-server \  
      -m $LLAMA_MODEL_DIR/gpt-oss-120b-mxfp4-00001-of-00003.gguf \  
      --n-cpu-moe 36 \  
      --n-gpu-layers 999 \  
      -c 0 -fa \  
      --jinja --reasoning-format none \  
      --host 0.0.0.0 --port 8502 --api-key "dummy"  
  

[kaydash]

Ich habe es tatsächlich ausprobiert, aber es ist viel zu langsam.
Den GPU-Takt nutzt es fast gar nicht,
stattdessen werden die 8 GB dedizierter GPU-Speicher und 64 GB physischer Arbeitsspeicher vollständig ausgelastet,
und von den 16 vCores wird nur etwa die Hälfte genutzt.
Man sollte dem Ganzen nur die Bedeutung beimessen, dass es überhaupt läuft; es war nicht so, dass dabei alle Ressourcen vollständig genutzt wurden.
Eine einzelne Anfrage dauerte 6 bis 8 Minuten.

[cronex]

Das möchte ich wohl auch mal ähnlich ausprobieren.

[crawler]

Ich dachte, 32 GB würden ausreichen ...

[cnaa97]

Läuft jedenfalls auf dem lm studio M4 max 64gb nicht wein

[jinucho]

Weil es 65 GB sind … schade. schluchz

[GN⁺]

Hacker-News-Kommentare

• Ich frage mich, ob man die Guardrails deaktivieren kann, wenn man das Modell direkt auf eigener Hardware ausführt
  • Um die Guardrails zu umgehen, müsste man wohl eine Art „abliterated finetune“ finden, bei der die Neuronenpfade, die Verweigerungsreaktionen auslösen, nachverfolgt und entfernt werden
  • Laut einem Artikel, den ich kürzlich gelesen habe, wurde GPT-OSS nur mit künstlichen/generierten Daten trainiert, daher besitzt es von vornherein nicht viel „verbotenes Wissen“
    Zugehöriger Artikel
  • Mit Jailbreak-Prompts lässt es sich umgehen; etwas umständlich, aber es funktioniert gut
  • Versionen mit teilweise entfernten Guardrails verlieren stark an Leistung, daher halte ich das persönlich eher für einen Nachteil
  • Im Grunde ist es im Modell eingebaut, aber es gibt eine Community, die das knackt und modifiziert
• In einer Umgebung mit 5950x + 128GB RAM + 12GB 3060 GPU ist die Token-Generierung schnell, aber sobald der Kontext auch nur etwas größer wird, sinkt die Verarbeitungsgeschwindigkeit stark
  Deshalb nutze ich meist andere Modelle wie qwen, mistral und gemma
  • Statt subjektiver Aussagen wie „schnell“ oder „langsam“ würden mich konkrete Token-Werte interessieren
  • Ich frage mich, was man mit diesem Modell außer einfachem Chatten/Textbearbeitung eigentlich machen will
• In einer Umgebung mit 32GB RAM + 16GB VRAM kann man ein 20B-Modell vollständig in den VRAM laden, aber wenn man das Kontextfenster auf mehr als 8k Token erweitert, reicht der VRAM nicht mehr
  Andere betreiben 120B-Modelle mit weniger VRAM; vielleicht liegt das daran, dass ROCm nicht unterstützt wird und stattdessen Vulkan verwendet wird
  Trotzdem macht es Spaß, die Hardware bis an ihre Grenzen auszureizen
  • Je größer der Kontext wird, desto mehr Layer müssen in den System-RAM ausgelagert werden
    In llama.cpp kann man die Anzahl der GPU-Berechnungslayer direkt festlegen, während ollama das automatisch anpasst
    Es wäre gut, wenn man das RAM-/VRAM-Verhältnis je nach Sitzungslänge dynamisch anpassen könnte
• Es ist lustig, 64GB RAM + 8GB VRAM als „gerade so“ zu bezeichnen; für mich ist das ein Setup für mehrere Tausend Dollar
  • Etwa 300 CAD für RAM und etwa 400 CAD für die GPU, also bei einem Desktop durchaus günstig machbar
  • Das liegt auf dem Niveau eines Gaming-PCs der unteren bis mittleren Preisklasse, daher kann man ihn mit ein paar hundert Dollar Upgrade direkt zu Hause betreiben
  • Es gibt auch Vorbestellungsprodukte für etwa $1599~$1999, die nicht allzu teuer sind
  • Mit weniger als 1000 US-Dollar kann man neue Teile zusammenbauen; gebraucht ist es noch günstiger und die GPU-Leistung kann sogar besser sein
  • DDR5 64GB liegt bei etwa $150, eine 12GB 3060 bei etwa $300, und auf eBay bekommt man es noch günstiger
• Ich frage mich, ob jemand das 20B-Modell auf einem MacBook Air M4 oder einer RTX 3060 ausprobiert hat
• Mir fehlt der RAM für große Modelle, aber das 20B-Modell läuft auf dem MacBook schnell und reicht für meinen Einsatzzweck aus
  Allerdings ist Function Calling in llama.cpp noch kaputt
  • Dieser Bug wurde in diesem PR behoben
  • Gut, dass es kein RAM-Limit, sondern ein Bug ist; selbst auf einem MacBook Air mit 16GB RAM laufen mehrere Modelle gut
    Ich plane, in meinem Zimmer mit einem Mini-PC für $149 einen AI-Chatbot zu hosten, und das Qwen3-4B-Modell sieht gut aus
    Zugehöriger Plan
• Ich frage mich, ob sich in OpenWebUI oder einer anderen GUI mit diesen Spezifikationen die Einstellungen optimieren lassen; ich denke, das 20B-Modell wäre besser
• Ich bin LLM-Anfänger und frage mich, ob diese Optimierung auf alle MoE-Modelle anwendbar ist
  • Da sie reguläre Ausdrücke auf Layer-Namen anwendet, funktioniert sie auch bei anderen Modellen mit ähnlicher Benennung
    Zum Beispiel funktionierte sie auch mit Qwen 3, und man kann reguläre Ausdrücke direkt angeben, um bestimmte Layer auf bestimmte Geräte zu verschieben
• Ich frage mich, ob die mlx-optimierte Version auf einem Mac mit 64GB läuft
  • Laut der Schätzung von LM Studio sollte eine 3-Bit-Quantisierung (~50GB) problemlos möglich sein