GPT-OSS 120B (Thinking)

GPT-OSS 120B ist seit August 2025 OpenAIs grösstes Open-Weights-Modell, veröffentlicht unter Apache-2.0-Lizenz mit freier kommerzieller Nutzung. Das MoE bündelt 116,8 Milliarden Gesamt- bei nur 5,1 Milliarden aktiven Parametern pro Token und läuft dank nativer MXFP4-Quantisierung auf einer einzelnen High-Memory-GPU. Drei Reasoning-Stufen und natives Tool-Use im Harmony-Format runden das Profil ab.

OpenAI Version 1.0 Kommerzielle Nutzung erlaubt MoE 116.8 B (5.1 B aktiv) 131 K Context local getestet

  • Open Weights
  • Server
  • vLLM
  • Text
  • Native Quantisierung
  • Harmony-Format
  • Interactive

Sovereign Risk: LOW OpenAI ist ein US-Unternehmen; das Modell wird unter Apache-2.0 als Open Weights veröffentlicht. Lokales Deployment vermeidet vollständig jeglichen API-Datenabfluss an OpenAI-Server, wodurch das Risiko trotz US-Jurisdiktion (CLOUD Act) als gering eingestuft wird.

LLM Model Review

Erstellt am · Native Quantisierung · Harmony-Format

Mit einem Gesamtscore von 74,36 % und dem Speed-Profile-Badge Interactive DevOps Expert gibt sich GPT-OSS 120B als ehrgeiziger Generalist mit Werkzeugkasten: schnell genug für den Dialog, technisch genug für ernsthafte Arbeit, aber nicht frei von Ecken, an denen man sich im Alltag stoßen kann. Für ein Server-Klasse-Modell mit MoE-Architektur ist dabei nicht die Gesamtgröße von 116,8 Milliarden Parametern der faire Maßstab, sondern die aktive Kapazität von 5,1 Milliarden Parametern pro Token. Genau daraus bezieht dieses Modell seinen Charakter: erstaunlich effizient, oft klug, manchmal zu knapp, und beim Faktenhalt in Tool-Use-Momenten nicht so souverän, wie man es sich von einem Modell mit OpenAI-Logo wünschen würde.

Kopfnoten: Stabilität und Zuverlässigkeit

Metrik Wert Bewertung Analyse
Timeout-Rate 0/49 Stabil Das Modell lief im Test absolut stabil und zuverlässig.
P95-Antwortzeit 91.35 s Problematisch Signifikante Ausreißer, die den Arbeitsfluss unterbrechen.

Architektur und Einordnung

GPT-OSS 120B tritt hier in einer interessanten Doppelrolle an. Auf dem Papier ist es als Thinking-Optional klassifiziert, also als Modellfamilie, die erweitertes Reasoning grundsätzlich unterstützt. Der konkrete Testlauf erfolgte jedoch explizit im Thinking-Modus. Das ist keine Petitesse, sondern prägt den gesamten Eindruck: Man sieht häufiger strukturierte, durchdachte Antworten, muss dafür aber auch mit spürbaren Ausreißern bei der Antwortzeit leben.

Dazu kommt die MoE-Architektur, also ein Mixture-of-Experts-Ansatz. Vereinfacht gesagt: Nicht alle Gewichte arbeiten bei jedem Token mit, sondern nur ein ausgewählter Teil. Das spart Rechenarbeit und erklärt, warum ein Modell dieser nominellen Größe eher wie ein disziplinierter Spezialtrupp wirkt als wie ein träger Tanker. Der Nutzen liegt in Effizienz und Spezialisierung, nicht in schierer Brechstangen-Kapazität. Für die Bewertung heißt das: GPT-OSS 120B muss sich an anderen starken Generalisten messen lassen, aber eben mit Blick auf seine aktive Modellkapazität.

Die Metadaten Native-Quant und Harmony sind ebenfalls mehr als Etiketten. Native Quantisierung bedeutet hier: Das Modell ist für quantisierten Betrieb gebaut und nicht erst nachträglich zurechtgestutzt worden. Harmony wiederum verweist auf das interne Antwortschema mit klar getrennten Analyse- und Ergebnis-Kanälen. Das macht sich im Test positiv bemerkbar: Reasoning wirkt meist geordnet, nicht improvisiert. Und das Tag Tool-Use ist verdient, aber mit Einschränkung. Das Modell kann Werkzeuge nutzen. Es hält sich dabei nur nicht immer streng genug an deren Resultate.

Geschwindigkeit und Effizienz

Der Badge Interactive DevOps Expert ist eine nützliche Kurzformel. Er sagt: Dieses Modell ist nicht bloß für nächtliche Batch-Läufe gebaut, sondern soll in technischen Arbeitsabläufen direkt reagieren können. Qualitativ passt das. GPT-OSS 120B wirkt auf dem Testsystem im Regelfall zügig genug für interaktive Nutzung, ohne in hektische Kurzantworten zu verfallen. Die Kehrseite steht allerdings ebenfalls klar im Datenbild: Der Tail ist lang. Im Normalfall antwortet das Modell ordentlich, in einem relevanten Anteil der Fälle zieht es den Nutzer aber aus dem Fluss.

Immerhin arbeitet GPT-OSS 120B token-ökonomisch. Kein Modul überschreitet den erwarteten Verbosity-Rahmen. Das ist gerade bei einem Thinking-Lauf bemerkenswert, weil viele Reasoning-Modelle sich in Textmasse verlieren. Hier passiert das nicht. Im CLI-Bereich und bei Cultural Intelligence produziert das Modell zwar sichtbar mehr Text als der Flottenmedian, bleibt aber sauber innerhalb vernünftiger Grenzen. Das ist keine Schwäche, eher eine Handschrift: leicht erklärfreudig, selten schwatzhaft.

Code Quality und Security: kompetent, aber nicht forensisch

Im Code-Quality-Modul zeigt GPT-OSS 120B eine klassische Stärke guter Generalisten. Es erkennt viel, strukturiert ordentlich und liefert verwertbare Tabellen statt wolkiger Allgemeinplätze. Die sichtbare Antwort im geprüften Sicherheits-Audit war vollständig auf Deutsch, sauber als Markdown-Tabelle formatiert und mit den geforderten Spalten versehen. Das ist die Pflicht. Die Kür wäre gewesen, die Schwachstellen nicht nur zu benennen, sondern mit der nötigen Schärfe zu priorisieren. Genau dort wird das Modell angreifbar.

Der Richter attestiert 20 identifizierte Schwachstellen und damit eine breite Erfassung des Problems. Das klingt stark und ist es im ersten Zugriff auch. Doch bei kritischen Punkten bleibt GPT-OSS 120B zu flach. Besonders auffällig ist die Fehlkalibrierung rund um IDOR, also unberechtigten Objektzugriff über manipulierbare Parameter. Was als kritische Eskalationskette hätte markiert werden müssen, wird auf eine Validation-Nebensache heruntergedimmt. Ähnlich bei SQL-Injection im Password-Reset-Pfad: erkannt im Material, aber nicht sauber als eigenständiger kritischer Befund herauspräpariert. Für eine Entwickler-Checkliste reicht das. Für ein belastbares Security-Review nicht.

Das zweite Problem ist die fehlende Angriffserzählung. Gute Sicherheitsmodelle listen nicht nur Lücken, sie zeigen, wie aus zwei mittelgroßen Fehlern ein Vollschaden wird. GPT-OSS 120B liefert Fixes und Benennungen, aber kaum Angriffsketten, kaum Proof-of-Concept-Denken, kaum jene zweite Ebene, auf der Security von Fleißarbeit zu echter Expertise wird. Das Modell weiß, wo es brennt. Es erklärt nur nicht immer, wie das Feuer durchs Gebäude läuft.

Gerade weil GPT-OSS 120B als Generalist antritt, ist dieses Ergebnis dennoch respektabel. Ein Score im mittleren 70er-Bereich für Code Quality, plus starke Formatdisziplin, zeigt: Für Code-Reviews, Buglisten, erste Audits und Entwicklerkommunikation ist das Modell gut brauchbar. Wer jedoch Bedrohungsmodelle, Exploit-Pfade oder Schweregrade belastbar priorisieren will, sollte eine zweite Instanz danebenstellen. GPT-OSS 120B ist hier ein solider Analyst, kein digitaler Incident-Responder.

Reasoning und Logik: richtig gedacht, nicht immer tief genug

Im Reasoning-Teil profitiert GPT-OSS 120B sichtbar vom aktivierten Thinking-Modus. Das Modell löst die logische Wächter-Aufgabe korrekt, erklärt die doppelte Inversion sauber und bleibt dabei sprachlich klar. Das ist mehr wert, als es in Zeiten von Reasoning-Marketing manchmal klingt. Viele Modelle produzieren bei Logikaufgaben beeindruckende Textmengen und stolpern trotzdem über die Grundstruktur. GPT-OSS 120B tut das nicht. Es versteht die Mechanik.

Was fehlt, ist die zweite Schicht. Der Judge bemängelt zu Recht die geringe didaktische Tiefe: keine Verifikationstabelle, keine alternativen Formulierungen, wenig Abstraktion zum allgemeinen Prinzip hinter der Lösung. Das Modell beantwortet die Frage. Es lehrt sie nicht. Für Nutzer, die einfach vorankommen wollen, ist das völlig ausreichend. Für Lern- oder Erklärkontexte bleibt Potenzial liegen.

Wichtig ist der Modusvergleich innerhalb derselben Modellfamilie. In diesem Bericht sehen wir den Thinking-Lauf, und der unterscheidet sich klar vom Standard-Lauf desselben Modells: Der Gesamtscore liegt höher, vor allem weil UX Writing, CLI und Tool-Use anziehen. Dafür büßt das Modell bei Documentation Quality und Content Transformation etwas von seiner Direktheit ein. Das passt ins Bild. Mit aktiviertem Denken wirkt GPT-OSS 120B überlegter und strategischer, aber nicht automatisch in jedem Schreibformat eleganter.

Content Transformation: brauchbar, aber mit einem gefährlichen Hang zur Erfindung

Im Content-Transformation-Modul zeigt GPT-OSS 120B, warum man Benchmark-Protokolle lesen sollte und nicht nur Scores. Auf den ersten Blick ist die Leistung ordentlich: Das Modell erstellt ein verwendbares Videoskript auf Deutsch, mit Timing, Produktionshinweisen und grundsätzlich plausibhem Ablauf. Es trifft die grobe Form. Im Produktionsalltag wäre das bereits mehr als ein leerer Rohling.

Der Richter benennt jedoch eine echte Sollbruchstelle. In der Analysephase bleibt GPT-OSS 120B zu pauschal und arbeitet die geforderten Elemente nicht granular genug auseinander. Noch kritischer ist der sogenannte Easter-Egg-Teil: Das Modell erfindet einen Gratis-Test für einen Premium-Password-Manager, der im Kontext nicht existiert. Das ist kein charmantes Ausschmücken, sondern ein Halluzinationsfehler mit Produktnähe. Genau solche Erfindungen vergiften Recherche-, Tutorial- und Kampagnenarbeit, weil sie professionell aussehen und gerade deshalb gefährlich sind.

In einer Aufgabe im Tool-Use-Bereich halluzinierte das Modell Inhalte, die nicht aus dem tatsächlich abgerufenen Tool-Ergebnis stammten. Der P2-Score wurde deshalb per Halluzinations-Cap begrenzt. Für content-kritische Aufgaben wie Recherche, Faktenberichte oder automatisierte Zusammenfassungen ist das kein Schönheitsfehler, sondern ein Ausschlusskriterium.

Abseits davon ist auch die Stiltreue nicht perfekt. Das Skript bleibt funktional, aber analytisch unterausgeschöpft, mit etwas zu generischem Call-to-Action und weniger editorischer Präzision als die beste Vergleichsarbeit. GPT-OSS 120B kann hier liefern. Es liefert nur nicht mit der letzten Gewissenhaftigkeit. Und bei Content gilt leider: Eine einzige erfundene Zeile kann zehn gute Absätze ruinieren.

UX Writing und Dokumentation: ordentlich, aber ohne Glanz

Die Modulwerte zeichnen ein gemischtes, aber lesbares Bild. Im UX Writing legt GPT-OSS 120B im Thinking-Lauf klar zu. Die Antworten scheinen mit aktiviertem Denken strukturierter und konsistenter zu werden. Das hilft bei Mikrotexten, die nicht nur freundlich, sondern auch zielgenau sein müssen. Ein brillanter Spezialist für Tonalität ist das Modell trotzdem nicht. Es schreibt eher vernünftig als elegant.

In der Documentation Quality ist das Bild umgekehrt. Der Thinking-Lauf fällt hinter den Standard-Lauf zurück. Das ist kein Widerspruch, sondern ein bekanntes Muster: Mehr Nachdenken produziert nicht automatisch bessere Dokumentation. Gerade bei Anleitungen und strukturierter Wissensvermittlung kann zusätzliche innere Komplexität in etwas sperrigere, weniger schnörkellose Texte umschlagen. GPT-OSS 120B dokumentiert brauchbar, aber nicht mit jener kalten Präzision, die starke Doku-Modelle auszeichnet. Man bekommt selten Müll, aber auch selten die Seite, die man direkt ins Handbuch kopieren möchte.

Cultural Intelligence: korrekt, respektvoll, sprachlich sicher

Im Cultural-Intelligence-Modul zeigt das Modell eine der sympathischeren Seiten seiner Persönlichkeit. Die geprüfte Antwort bleibt vollständig auf Deutsch, entschärft toxische Formulierungen, arbeitet inklusiver und hält den professionellen Ton. Das ist nicht spektakulär, aber verlässlich. Der Richter moniert vor allem Nuancen: Plural statt Singular, etwas behördlichere Wortwahl, unsaubere inklusive Schreibweise mit kleinen Formatfehlern. Das ist kein systemischer Ausfall, sondern Schliffverlust.

Gerade bei solchen Aufgaben zählt, ob ein Modell Eskalation vermeidet, ohne in leere PR-Sprache zu kippen. GPT-OSS 120B schafft das meistens ordentlich. Es wirkt hier nicht visionär, aber zivilisiert. Für HR-nahe Umformulierungen, sensible Anpassungen und sprachlich respektvolle Überarbeitungen ist das ein brauchbares Profil.

CLI und Tool-Use: stark im Zugriff, schwächer in der Treue

Die Modulwerte für CLI und Tool-Use sehen zunächst sehr gut aus. Im CLI-Benchmark erreicht GPT-OSS 120B im Thinking-Lauf ein starkes Ergebnis und bestätigt damit den Badge als DevOps-orientiertes Modell. Das spricht dafür, dass es technische Aufgaben nicht nur sprachlich umkreist, sondern operativ strukturieren kann. Wer Shell-Kommandos, Ablaufpläne oder schrittweise technische Hilfe sucht, bekommt in der Regel Substanz.

Doch beim Tool-Use zeigt sich die zentrale Ambivalenz des Modells. Die Architektur verspricht hier viel: natives Tool-Use, Harmony-Struktur, reasoning-orientierte Trennung von Analyse und finaler Antwort. In der Praxis reicht schon ein einzelner Halluzinationsbefund, um Vertrauen anzukratzen. Denn Tool-Nutzung lebt von Treue zur Quelle. Ein Modell darf elegant formulieren, es darf verdichten, es darf priorisieren. Es darf aber nicht Inhalte dazuerfinden, die das Werkzeug nie geliefert hat. Genau das ist hier passiert.

Das Gesamtbild lautet deshalb: GPT-OSS 120B ist im Umgang mit Werkzeugen fähig, aber nicht narrensicher. Für technische Agenten mit menschlicher Aufsicht ist das akzeptabel. Für unbeaufsichtigte, content-kritische Tool-Pipelines ist es zu riskant.

Datenschutz und Datenhoheit

Da GPT-OSS 120B hier als rein lokales Open-Weights-Modell betrieben wird, entsteht im laufenden Einsatz kein API-bedingter Datenabfluss an einen externen Provider. Relevant bleibt die Provenienz der Gewichte: Das Risiko ist laut Model-Card LOW, weil OpenAI zwar als US-Unternehmen dem CLOUD Act unterliegt, das lokale Deployment aber genau den heiklen Punkt vermeidet, nämlich die Übertragung produktiver Eingaben an OpenAI-Server. Für europäische Unternehmen ist das die gute Nachricht: Die juristische Herkunft bleibt US, die operative Datenhoheit liegt im Eigenbetrieb.

Fazit

GPT-OSS 120B ist ein lokales Modell, evaluiert nativ auf ASUS GX10 / NVIDIA DGX Spark (GB10 Grace Blackwell Superchip, ~115 GB Unified Memory — kein praktisches Speicherlimit für getestete Modellgrößen). In dieser Konfiguration zeigt es ein klares Profil: ein leistungsfähiger Generalist der Server-Klasse, dessen MoE-Architektur aus relativ schlanker aktiver Kapazität erstaunlich viel Kompetenz herauspresst. Der Thinking-Lauf hebt das Modell sichtbar an. Er macht GPT-OSS 120B besser in Logik, UX-naher Formulierung und technischer Interaktion. Der Standard-Lauf derselben Modellfamilie bleibt direkter und ist in einzelnen Schreibmodulen sogar etwas sauberer, insgesamt aber schwächer.

Seine Stärken liegen in strukturierter technischer Arbeit, solider Code-Analyse, brauchbarem Reasoning und ordentlicher Tool-Integration. Seine Schwächen liegen in Tiefe statt Breite: Security-Befunde sind oft richtig, aber nicht scharf genug priorisiert; Erklärungen sind korrekt, aber nicht immer lehrreich; Content-Arbeit kann funktional sein, kippt jedoch im falschen Moment in Halluzination. Genau das ist der kritische Punkt dieses Modells. Nicht die Geschwindigkeit, nicht die Stabilität, sondern die Frage, ob man ihm bei toolgestützten Fakten blind folgen darf. Die Antwort lautet: besser nicht.

Für lokale Entwickler-Setups, technische Assistenz, Code-Reviews, CLI-Hilfe und allgemeine Wissensarbeit ist GPT-OSS 120B eine ernstzunehmende Option. Für automatisierte Recherche, faktenkritische Content-Pipelines oder Security-Audits ohne menschliche Nachkontrolle fehlt ihm die letzte Verlässlichkeit. Ein fähiges Modell also, mit Charakter und Nutzen. Aber auch mit jener kleinen Neigung zur Improvisation, die im Labor spannend wirkt und im Betrieb teuer werden kann.

Diese Auswertung wurde automatisch auf Grundlage der Benchmark-Daten generiert. Eingesetztes Modell: GPT-5.4 von OpenAI. Die Rohdaten und die vollständige Methodik sind im GitHub-Projekt dokumentiert.