gpt-oss-120b Hardware-Anforderungen: VRAM und GPUs für 1 bis 100 Nutzer, mit gpt-oss-20b

Hardware-Anforderungen von gpt-oss-120b

Die Hardware-Anforderungen von gpt-oss-120b ergeben sich aus etwa 61 GiB GPU-Speicher für die Gewichte und einem KV-Cache für jedes laufende Gespräch, deshalb betreibt eine RTX PRO 6000 mit 96 GB, eine H200 NVL mit 141 GB oder ein DGX Spark mit 128 GB Unified Memory es für einen Nutzer. Für 20 gleichzeitige Gespräche mit 32.768 Token braucht es nach unserer Schätzung eine H200 NVL oder zwei RTX PRO 6000, für 100 zwei H200 NVL oder vier RTX PRO 6000. Das kleinere gpt-oss-20b belegt 12,8 GiB und bedient 100 solche Gespräche auf einer H200 NVL oder zwei RTX PRO 6000.

Laut OpenAIs Model Card läuft gpt-oss-120b dank der MXFP4-Quantisierung der MoE-Gewichte auf einer einzigen GPU mit 80 GB und gpt-oss-20b innerhalb von 16 GB Speicher. Unsere LLM-Hardware-Anforderungen je Modell vergleichen es mit anderen offenen Modellen.

gpt-oss-Varianten und Checkpoint-Größen im Oktober 2026

OpenAI hat zwei gpt-oss-Modelle auf Hugging Face veröffentlicht und zwei darauf aufbauende Safety-Reasoning-Modelle. Am 9. Oktober 2026 zeigte die Organisationsseite von OpenAI kein neueres gpt-oss-Textmodell.

Model Cards und Dateilisten auf Hugging Face, abgerufen am 9. Oktober 2026; der Checkpoint ist die Summe der safetensors-Dateien auf oberster Ebene. OpenAIs Model Card nennt 60,8 GiB und 12,8 GiB für die beiden Basis-Checkpoints. Dass der Rest von Puzzle in BF16 vorliegt, folgt aus seinen aufgeführten Tensortypen.

Beide Basismodelle sind Mixture-of-Experts-Transformer. gpt-oss-120b hat 36 Layer mit 128 Experten, gpt-oss-20b 24 Layer mit 32, und beide leiten jedes Token an 4 Experten weiter. Nur die Expertengewichte liegen in MXFP4 vor; die Model Card gibt dafür 4,25 Bit je Parameter und einen Anteil von mehr als 90 Prozent aller Parameter an. Attention, Router, Embeddings und Output-Head bleiben in BF16, wie die config.json-Dateien aufführen. Beide Modelle akzeptieren 131.072 Token Kontext, mit YaRN von ursprünglich 4.096 erweitert.

Mit seinem Ordner „original“ von 65,2 GB und einem Ordner „metal“ umfasst das Repository von gpt-oss-120b insgesamt 196 GB, das von gpt-oss-20b 41,3 GB; so viel Speicherplatz braucht ein vollständiger Download.

Die Safeguard-Modelle klassifizieren Text anhand einer Sicherheitsrichtlinie, die Sie vorgeben, und brauchen dieselbe Hardware wie ihre Basismodelle. NVIDIAs gpt-oss-puzzle-88B, veröffentlicht am 26. März 2026, ist von gpt-oss-120b abgeleitet, ersetzt einen Teil der globalen Attention-Layer durch ein Fenster von 8K und hält seinen Cache in FP8. Seine Card führt nur die B200 und die H100-80GB als unterstützte Hardware, testen Sie es also zuerst auf Ihrer Karte.

KV-Cache je Gespräch aus der config.json

Die allgemeine Methode steht in unserem Leitfaden dazu, wie viel VRAM ein LLM braucht. Nutzbar sind 90 Prozent dessen, was der Treiber meldet, abzüglich 3 GiB je Karte, und was nach den Gewichten bleibt, fasst den Cache. Das ergibt 83,0 GiB je RTX PRO 6000 und 123,4 GiB je H200 NVL. Für einen DGX Spark (128 GB) setzen wir wie in unserem Überblick je Modell 102 GB an, etwa 95 GiB.

gpt-oss hält den vollen Kontext nur in der Hälfte seiner Layer. Laut Model Card wechseln die Attention-Blöcke zwischen gebänderten Fenstern und vollständig dichten Mustern, bei einer Bandbreite von 128 Token, und vLLM reserviert in solchen Layern Cache nur für das Fenster. Jeder volle Layer speichert Keys und Values für 8 KV-Heads der Dimension 64. Ein Token kostet deshalb bei gpt-oss-120b in 16 Bit 2 × 18 × 8 × 64 × 2 Byte, also 36 KiB, und über die 12 vollen Layer von gpt-oss-20b 24 KiB. Die Layer mit Fenster bringen beim größeren Modell bei jeder Länge etwa 4,5 MiB je Gespräch hinzu.

Unsere Rechnung aus den config.json-Dateien: Layer mit voller Attention × 2 × 8 KV-Heads × 64 × Byte je Wert × Token, je Gespräch bei dieser Länge; die Layer mit dem Fenster von 128 Token sind nicht eingerechnet.

Die Länge eines Gesprächs umfasst den System-Prompt, den Verlauf und alles, was das Modell schreibt, einschließlich seines Reasonings, bis zu dem Kontext, den Sie festlegen.

Reasoning-Aufwand, harmony und die Last je Anfrage

gpt-oss erzeugt vor jeder Antwort ein Reasoning, in drei Stufen, die im System-Prompt mit einer Zeile wie Reasoning: high gesetzt werden. Laut OpenAIs harmony-Leitfaden nutzt das Modell standardmäßig die Stufe medium. Die Model Card hält fest, hier aus dem Englischen übersetzt: „Eine höhere Reasoning-Stufe führt dazu, dass die durchschnittliche CoT-Länge des Modells steigt.“

Für das Sizing bedeutet eine längere Chain of Thought, dass jede Anfrage mehr Token schreibt, mehr Cache füllt und länger läuft, sodass dieselbe Zahl von Beschäftigten mehr gleichzeitige Anfragen erzeugt. OpenAIs Model Card zeigt die durchschnittliche Reasoning-Länge je Stufe nur für zwei Benchmarks und berichtet, dass gpt-oss-20b je AIME-Aufgabe im Schnitt über 20.000 Reasoning-Token verwendete. Messen Sie die Länge während eines Piloten mit Ihren eigenen Prompts und rechnen Sie sie zu dem Kontext hinzu, den Sie festlegen.

Harmony ist OpenAIs Antwortformat für gpt-oss, mit dem Reasoning im Kanal „analysis“ und der Antwort im Kanal „final“. OpenAIs harmony-Repository hält fest, dass gpt-oss nicht ohne das harmony-Format verwendet werden sollte, da es sonst nicht korrekt funktioniert, und vLLM, Ollama und Hugging Face wenden es für Sie an. OpenAIs Leitfaden ergänzt, dass frühere CoT-Inhalte beim nachfolgenden Sampling zu verwerfen sind, sobald eine Antwort im Kanal „final“ geendet hat, außer bei Tool- und Function-Calls, bei denen das frühere Reasoning wieder in den Kontext kommt. Ein Chatverlauf wächst daher um Fragen und Antworten, während ein Agent, der Tools aufruft, sein Reasoning mitführt und früher einen langen Kontext erreicht.

GPUs für gpt-oss: 1, 20 und 100 gleichzeitige Nutzer

Die Tabelle zählt Gespräche, die zur selben Zeit mit der vollen angegebenen Länge laufen, mit einem Cache in 16 Bit. Zwei oder vier Karten bedeuten eine mit Tensor-Parallelismus aufgeteilte Kopie, sofern der Text nicht Kopien nennt. Laut dem Leitfaden von vLLM zu Context Parallelism verteilt die Aufteilung den Cache nach KV-Heads und dupliziert ihn nur, wenn die Tensor-Parallel-Größe die Zahl der KV-Heads übersteigt; gpt-oss hat acht, deshalb addiert sich der Cache von bis zu acht Karten.

Unsere Schätzungen, keine Messungen: benötigte Karten, in Konfigurationen mit 1, 2, 4 oder 8 Karten, für 1 / 20 / 100 gleichzeitige Gespräche mit 32.768 oder 131.072 Token und einem KV-Cache in 16 Bit; acht Karten laufen als zwei Kopien zu je vier. Beim DGX Spark zeigt die Tabelle, ob der Speicher eines Spark reicht, nicht seine Geschwindigkeit.

Auf einer RTX PRO 6000 lässt gpt-oss-120b 22,2 GiB für den Cache, Platz für 19 Gespräche mit 32K, deshalb brauchen 20 Nutzer eine zweite Karte, und zwei Karten als Replikate fassen 38. Für 100 Nutzer mit 32K fassen vier Karten als eine aufgeteilte Kopie 241 Gespräche, als zwei Kopien zu je zwei Karten 186 und als vier Kopien auf je einer Karte 76. Eine H200 NVL lässt 62,5 GiB, genug für 55 Gespräche mit 32K, und zwei als Replikate fassen 110 ohne Brücke.

Bei vollen 131.072 Token sinken die Zahlen um den Faktor vier. Eine RTX PRO 6000 fasst dann vier Gespräche, eine H200 NVL 13 und ein Spark 7. Vier H200 NVL an einer Vierfach-Brücke fassen 96, deshalb zeigt die Tabelle acht, betrieben als zwei Kopien zu je vier, eine je NVLink-Domäne, die zusammen 192 fassen. Acht RTX PRO 6000 in dieser Anordnung fassen 120, und vier H200 NVL mit FP8-Cache fassen 192.

gpt-oss-20b lässt auf einer RTX PRO 6000 70,2 GiB, Platz für 93 Gespräche mit 32K, und eine H200 NVL fasst 147. Ein Spark fasst vom Speicher her 109, allerdings begrenzt seine Speicherbandbreite von 273 GB/s, wie viele davon mit brauchbarer Geschwindigkeit streamen; die gemessenen Werte stehen in unserem Artikel mit Benchmarks des DGX Spark.

Ein FP8-Cache verdoppelt jede Zahl ungefähr, auf 111 Gespräche mit gpt-oss-120b bei 32K auf einer H200 NVL. Die Support-Matrix von TensorRT-LLM führt einen FP8-KV-Cache für Hopper und für die Generation RTX PRO Blackwell (sm120). Unter den NVIDIA-GPUs setzt das gpt-oss-Rezept von vLLM ihn nur für die B200, prüfen Sie also zuerst die Antwortqualität.

Dimensionieren Sie nach der Spitzenzahl laufender Anfragen, die von der Kopfzahl abweicht; unser Artikel dazu, wie viele Nutzer eine RTX PRO 6000 bedient, zeigt, wie Sie diese Spitze aus den Gateway-Logs ermitteln.

Wir bauen Inferenz-Server mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern. Nennen Sie uns die gpt-oss-Variante, Ihre Kontextlänge und die Spitzenzahl laufender Anfragen, und wir antworten innerhalb eines Werktages mit Konfiguration und Angebot.

H200 NVL, RTX PRO 6000 oder DGX Spark für gpt-oss

Die Support-Matrix von TensorRT-LLM, Version 1.3.0rc29 vom 26. September 2026, führt MXFP4 für Blackwell, einschließlich der RTX-PRO-Generation, und nicht für Hopper. Die RTX PRO 6000 und der DGX Spark haben FP4-Arithmetik, die eine Engine nur nutzt, wenn sie einen MXFP4-Kernel dafür hat; der B200-Pfad von vLLM kombiniert MXFP4-Gewichte mit MXFP8-Aktivierungen. Auch die H200 NVL hält die Gewichte in MXFP4, rechnet diese Layer ohne FP4-Arithmetik aber mit höherer Präzision; der Speicher je Karte ist also derselbe, der Rechenpfad ein anderer.

Das gpt-oss-Rezept von vLLM, aktualisiert am 22. September 2026, nennt unter den NVIDIA-GPUs die H100, H200 und B200 und erwähnt laufende Arbeiten für „Ampere/Ada/RTX 5090“. Die RTX PRO 6000 und den DGX Spark nennt es nicht. StorageReview hat eine NVFP4-Version von gpt-oss-120b mit vLLM auf vier RTX PRO 6000 Server Edition bereitgestellt, wie unser Artikel zu einem Modell auf mehreren GPUs über PCIe und NVLink berichtet. Prüfen Sie die Engine-Version auf der Karte vor dem Produktivbetrieb.

Da gpt-oss auf eine Karte passt, sind Replikate hinter einem Load Balancer der Normalfall; sie tauschen nichts über PCIe aus und fallen unabhängig voneinander aus. Eine Aufteilung lohnt sich dort, wo der Cache knapp wird, etwa für 100 Gespräche mit 32K auf RTX PRO 6000. Diese Karte hat kein NVLink, die Aufteilung läuft also über PCIe, wo die Peer-to-Peer-Einstellungen die Geschwindigkeit bestimmen, während vier H200 NVL an einer Vierfach-Brücke sie mit 900 GB/s je GPU auf NVLink halten.

vLLM-Einstellungen für gpt-oss-120b

Das Rezept von vLLM stellt gpt-oss-120b auf einer B200 mit --tensor-parallel-size 1 und einer Konfigurationsdatei bereit und beschreibt Hopper als dieselbe Konfiguration ohne kv-cache-dtype und ohne die FlashInfer-MoE-Flags. Der frühere gpt-oss-Leitfaden von vLLM, in der Dokumentation als historische Referenz erhalten, führt beide Dateien: Die Hopper-Datei setzt no-enable-prefix-caching: true und max-num-batched-tokens: 8192, die Blackwell-Datei ergänzt kv-cache-dtype: fp8. Der Leitfaden schaltet Prefix Caching für Läufe mit einem synthetischen Datensatz ab, eine Benchmark-Einstellung; testen Sie Prefix Caching für einen Chat-Dienst also selbst.

Der Leitfaden nennt zwei Voreinstellungen, die für den Speicher zählen. Die Kontextlänge steht standardmäßig auf der maximalen Sequenzlänge, die das Modell unterstützt, also 131.072 Token. Die Zahl der Sequenzen steht auf GPUs mit viel Speicher standardmäßig auf einer großen Zahl wie 1024. Setzen Sie --max-model-len auf den Kontext, den Ihre Nutzer brauchen, dann meldet vLLM für denselben Cache eine höhere maximale Nebenläufigkeit.

Betriebssystem, Treiber, CUDA und eine Container-Runtime installieren wir auf Wunsch, und die Bereitstellung des Modells mit vLLM gehört zu unserer Leistung Private AI/ML. Schreiben Sie uns die Variante, die geplante Reasoning-Stufe und Ihren Rack-Standort.

Lizenz und Nutzungsrichtlinie von gpt-oss

gpt-oss-120b, gpt-oss-20b und beide Safeguard-Modelle sind unter der Lizenz Apache 2.0 veröffentlicht, wie ihre Model Cards angeben. Jedes OpenAI-Repository enthält außerdem eine kurze Datei USAGE_POLICY, die für gpt-oss-120b im englischen Original lautet, hier übersetzt: „Durch die Nutzung von OpenAI gpt-oss-120b erklären Sie sich damit einverstanden, alle geltenden Gesetze einzuhalten.“ NVIDIAs gpt-oss-puzzle-88B steht stattdessen unter der NVIDIA Open Model License. Ob diese Bedingungen zu Ihrer geplanten Nutzung passen, ist eine rechtliche Bewertung für Ihre Rechtsabteilung.

Was wir liefern

Wir liefern die DGX Spark Founders Edition, die RTX PRO 6000 als Workstation, Max-Q und Server Edition sowie die H200 NVL mit ihren Zweifach- und Vierfach-NVLink-Brücken, als Karten oder in nach Auftrag gebauten KI-Servern, unter einem EU-Vertrag und auf einer Rechnung, mit Herstellergarantie. Für gpt-oss legen wir den Server nach Variante, Kontext und Spitzenzahl laufender Anfragen aus und prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Konfiguration und Angebot erhalten Sie innerhalb eines Werktages, und unser Sortiment professioneller GPUs führt jede Karte. Betrieb des Modells, RAG und MLOps auf der Hardware sind unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ