GPT-OSS 120B (Thinking)

Mit einem Gesamtscore von 73.41% zeigt GPT-OSS 120B (vLLM, MXFP4) im hier ausgewerteten Thinking-Modus ein klares Profil: ein lokaler Generalist der Server-Klasse, gebaut als MoE mit 116,8 Milliarden Gesamtparametern, aber nur 5,1 Milliarden aktiven Parametern pro Token. Das ist wichtig, weil sich die Leistung nicht wie ein brachialer 120B-Dense-Klotz anfühlt, sondern wie ein effizienter Spezialist mit breiter Werkzeugkiste. Der Speed Profile Badge lautet Interactive Tool Expert. Das passt erstaunlich gut: Das Modell ist nicht die Schreibmaschine für poetische Feinarbeit, aber ein zügiger, strukturierter Operator für technische und werkzeugnahe Aufgaben. Sovereign Risk: HIGH — die Model- und Vendor-Daten verweisen auf OpenAI als US-Unternehmen unter CLOUD-Act-Jurisdiktion; beim hier vorliegenden lokalen Open-Weights-Betrieb fließt aber kein API-Traffic an OpenAI.

Kopfnoten: Stabilität und Zuverlässigkeit

Architektur und Charakter: Was diese Einstufung über das Modell verrät

Die Metadaten treffen den Kern dieses Modells ziemlich genau. Als Generalist muss GPT-OSS 120B (vLLM, MXFP4) in der vollen Breite bestehen, nicht nur auf einer Lieblingsstrecke. Als Server-Modell sind die Erwartungen hoch. Hier reicht es nicht, „ganz ordentlich für lokal“ zu sein. Es muss sich bei Code, Logik, Doku, Spracharbeit und Werkzeugnutzung wie ein ernstzunehmendes Produktivmodell benehmen. Und als MoE-Architektur sollte man die Messlatte eben nicht an 116,8 Milliarden Gesamtparametern anlegen, sondern an den 5,1 Milliarden aktivierten Parametern pro Token. Das erklärt, warum das Modell oft sehr kompetent wirkt, aber nicht die souveräne Tiefenschärfe eines wirklich schweren Frontier-Dense-Modells erreicht.

Dazu kommt die Configurable-Reasoning/Harmony-Tool-Use-Schiene. GPT-OSS 120B ist nicht als blanker Antwortautomat gebaut, sondern als System, das Analyse, Werkzeugaufruf und Schlussantwort klar trennen kann. In diesem Test lief es explizit im Thinking-Modus. Ausführlichere, stärker begründete Antworten sind also keine Entgleisung, sondern Programmatik. Genau daran muss es sich messen lassen. Wenn ein solches Modell gut argumentiert, ist das Pflicht. Wenn es sich trotzdem in Tool-Halluzinationen verheddert, ist das umso ärgerlicher.

Geschwindigkeit und Effizienz: schnell genug, aber nicht ohne langen Schatten

Weil es sich um ein lokales Modell handelt, evaluiert auf ASUS GX10 / NVIDIA DGX Spark (GB10 Grace Blackwell Superchip, ~115 GB Unified Memory — kein praktisches Speicherlimit für getestete Modellgrößen), zählt hier nicht nur die reine Qualität, sondern auch das Laufverhalten auf dem Testsystem. Der Badge Interactive Tool Expert bedeutet in der Praxis: Das Modell fühlt sich eher wie ein direkt ansprechbarer Arbeitshelfer für technische Interaktion an als wie ein Batch-Schreiber für stundenlange Langtexte.

Diese Einordnung trägt. GPT-OSS 120B (vLLM, MXFP4) generiert auf dem Testsystem qualitativ in einem Bereich, der interaktive Nutzung plausibel macht. Gleichzeitig zeigt die Stabilitätstabelle, dass die langen Ausreißer real sind. Nicht ständig, aber oft genug, um den Fluss zu brechen. Das ist kein Totalschaden. Es ist der Unterschied zwischen „angenehm benutzbar“ und „blind in eine Agentenkette hängen“. Für Letzteres fehlt die letzte Ruhe.

Positiv ist die Token-Ökonomie. Das Modell verhält sich token-ökonomisch. Kein Modul übersteigt den erwarteten Verbosity-Rahmen. Bemerkenswert ist sogar, dass Reasoning und Metakognition mit durchschnittlich 1151 Tokens unter dem Fleet-Median von 1207 liegen. In den normalen Arbeitsmodulen bleibt es ebenfalls diszipliniert. Nur bei CLI und Cultural Intelligence redet es sichtbar mehr als der Median, aber noch nicht ausufernd. Für ein lokales Modell heißt das vor allem: keine künstlich aufgeblähten Antworten, keine teure Textwatte, keine überflüssige Latenz durch Selbstbespiegelung. Das ist seltener, als es sein sollte.

Code Quality: fachlich stark, aber nicht mit letzter Angriffslust

Im Code-Quality-Audit spielt GPT-OSS 120B (vLLM, MXFP4) seine technischen Instinkte sauber aus. Die Sicherheitsanalyse ist kein oberflächliches Schwachstellen-Bingo, sondern erkennt die relevanten Klassen von Problemen zuverlässig: SQL Injection in mehreren Varianten, Path Traversal, Header Injection, XSS, Session Fixation, schwache Reset-Tokens, unsichere Cookie-Flags, Hardcoded Secrets, CSRF, IDOR. Vor allem die Beschreibungen und Fix-Vorschläge sind praxisnah. Das Modell nennt nicht nur die Krankheit, sondern meist auch die richtige Medizin.

Sein eigentlicher Makel liegt nicht bei der Erkennung, sondern bei der Gewichtung und Synthese. Der Judge kritisiert zu Recht, dass die explizit verlangte Hervorhebung der fünf impliziten, versteckteren Schwachstellen nicht klar genug ausfällt. Das Modell findet sie zwar, stellt sie aber nicht als eigenes narratives Cluster heraus. Genau dort trennt sich ein guter Auditor von einem exzellenten. Wer nur alles findet, arbeitet gründlich. Wer die versteckten Angriffspfade priorisiert und zu einer Exploit-Kette zusammensetzt, denkt wie ein Angreifer. GPT-OSS 120B arbeitet eher wie ein guter Security-Engineer im Review-Modus als wie ein Red-Teamer mit Messer zwischen den Zähnen.

Hinzu kommt das Fehlen echter Angriffsketten. Die Goldlösung verknüpft einzelne Lücken zu konkreten Eskalationspfaden. Das Modell bleibt stärker in der Tabellenlogik. Das ist nützlich, sauber und im Alltag oft ausreichend. Aber es lässt ein wenig Wirkung liegen. Sicherheit ist eben nicht nur Inventur, sondern auch Dramaturgie der Ausnutzung.

Reasoning und Logik: korrekt, aber didaktisch nicht voll ausgereizt

Im logischen Reasoning liefert GPT-OSS 120B (vLLM, MXFP4) das Entscheidende: Die Lösung stimmt. Beim klassischen Zwei-Wächter-Rätsel landet das Modell sicher bei der richtigen Frage und erklärt sauber, warum beide Wächter auf die falsche Tür zeigen würden. Das ist die Pflicht, und die Pflicht erfüllt es ohne Wackler.

Die Kür bleibt allerdings halb gepackt im Koffer. Die Ausführungen sind ordentlich strukturiert, aber weniger lehrreich als die beste Referenz. Alternative Formulierungen, konzeptionelle Einordnung und die elegante Abstraktion des Lösungsprinzips fehlen oder bleiben zu knapp. Das ist kein Denkfehler, sondern ein Mangel an didaktischer Breite. Das Modell kann schlussfolgern. Es inszeniert dieses Schlussfolgern nur nicht immer so, dass der Leser am Ende das Prinzip auch liebt statt nur versteht.

Gerade im Thinking-Modus fällt dieser Punkt ins Gewicht. Wenn man das Reasoning explizit einschaltet, darf man mehr erwarten als nur Richtigkeit mit höflicher Begründung. Man erwartet den Moment, in dem ein Modell nicht bloß ankommt, sondern den Weg ausleuchtet. GPT-OSS 120B kommt an. Die Taschenlampe ist vorhanden, aber nicht immer hell genug.

Tool-Use und Halluzinationen: starkes Interface, gefährlicher Schönheitsfehler

Die Architektur verspricht hier viel. Harmony-Format, Tool-Use-Fokus, klare Trennung von Analyse und finaler Antwort. Genau deshalb ist der zentrale Befund bitter: Im Tool-Use-Bereich hat das Modell in mindestens zwei Aufgaben Inhalte erfunden, die nicht aus dem tatsächlich abgerufenen Werkzeugergebnis stammten. Das ist keine Petitessenklasse. Das ist die Sorte Fehler, die ein Recherche- oder Agentensystem diskreditiert.

In zwei Tool-Use-Aufgaben griff der Halluzinations-Cap. Der automatische Abzug traf nicht wegen Stil oder Vollständigkeit, sondern weil das Modell Fakten außerhalb des Tool-Outputs generierte. Für content-kritische Aufgaben wie Recherche, Zusammenfassungen externer Daten oder faktengebundene Statusberichte ist das ein disqualifizierendes Signal. Gerade ein Tool-Modell muss wissen, wann es nur noch Bote ist. GPT-OSS 120B will in diesen Fällen offenbar noch Autor sein. Das ist der falsche Ehrgeiz.

Die Tool-Execution-Gesamtleistung bleibt trotzdem hoch, was zeigt: Die mechanische Werkzeugnutzung klappt. Das Problem ist nicht der Schraubendreher in der Hand, sondern der Kommentar dazu. Wer das Modell für Agents, Browser-Workflows oder Retrieval-Aufgaben einsetzt, braucht also ein enges Guardrail: Antworten strikt gegen den Tool-Output validieren, idealerweise mit nachgelagerter Quellenprüfung. Sonst verwandelt sich nützliche Eigenständigkeit in gepflegte Fiktion.

Content Transformation: produktionsreif, aber nicht filmreif

Im Umbau schwacher Vorlagen in brauchbare Zieltexte oder Zielskripte zeigt GPT-OSS 120B (vLLM, MXFP4) viel von seinem praktischen Wert. Das Beispiel eines YouTube-Security-Skripts ist bezeichnend: Das Modell liefert eine vollständige Drei-Akt-Struktur aus Analyse, Transformation und Easter Egg, mit Zeitmarken, Produktionshinweisen, Screen-Anmerkungen, B-Roll-Cues, CTA und vernünftiger Taktung. Das ist keine Alibi-Antwort. Damit kann ein Team tatsächlich arbeiten.

Die Grenze liegt bei der Form und beim dramaturgischen Zug. Die Analyse nennt die fehlenden Bausteine, organisiert sie aber nicht so explizit und prüfbar wie die Referenz. Auch das eigentliche Skript wirkt funktional stark, aber emotional vorsichtiger. Der Hook arbeitet, doch nicht mit voller Fallhöhe. Der Abschnitt zu Backup-Codes erklärt, statt zuzuspitzen. Man bekommt ein brauchbares Produktionsdokument, aber nicht den Text, bei dem man sofort den Sprecher im Kopf hört.

Das ist typisch für dieses Modell: Es ist selten unfähig, häufiger nur etwas zu vernünftig. In der Content-Transformation ist das oft ein Kompliment. Im Aufmerksamkeitsgeschäft von Video und Marketing kann es aber der Unterschied zwischen „professionell“ und „merkfähig“ sein.

UX Writing und Microcopy: die dünnste Stelle im Gesamtbild

Hier zeigt sich ein interessanter Bruch. Während Content-Transformation insgesamt solide läuft, fällt das Modell bei UX Writing deutlicher ab. Der Score in diesem Bereich ist der schwächste der großen Textmodule. Das passt ins qualitative Bild: GPT-OSS 120B formuliert meist korrekt, ordentlich und brauchbar, aber nicht immer mit der Präzision und Lakonie, die gute Produkttexte auszeichnen.

UX-Microcopy verlangt das Gegenteil vieler Thinking-Stärken. Nicht Ausbau, sondern Reduktion. Nicht Begründung, sondern Reibungsfreiheit. Nicht „ich habe verstanden“, sondern „der Nutzer versteht sofort“. Genau dort wirkt GPT-OSS 120B mitunter wie ein kluger Mensch, der in jedem Formularfeld noch einen Halbsatz zu viel sagen möchte. Das ist kein katastrophales Versagen. Es ist schlicht nicht seine eleganteste Disziplin.

Documentation Quality: solide Substanz ohne große literarische Ambition

Bei Dokumentationstexten landet das Modell im guten Mittelfeld seiner eigenen Fähigkeiten. Die Stärke liegt in strukturierter Vollständigkeit. GPT-OSS 120B kann technische Informationen sortieren, schrittweise aufbereiten und sinnvoll erklären. Das harmoniert mit seinem allgemeinen Profil als tool-naher, analytischer Generalist.

Was man weniger bekommt, ist editoriale Politur. Die ganz starken Dokumentationsmodelle schreiben nicht nur korrekt, sondern setzen Prioritäten fast unsichtbar, vermeiden jede Redundanz und führen den Leser mit einer Klarheit, die nach keiner KI riecht. GPT-OSS 120B ist davon nicht weit weg, aber eben auch nicht ganz da. Man merkt häufiger die Maschine, die Ordnung schafft, statt den Autor, der den Leser führt.

Cultural Intelligence: ordentlich lokalisiert, nicht immer fein genug

Die deutsche Stellenanzeigen-Umschreibung aus dem Protokoll ist ein gutes Beispiel für die Ambivalenz dieses Modells. Es entfernt toxische Formulierungen, reduziert Geschlechterbias und hält sich an die Vorgaben. Das ist der funktionale Teil, und der sitzt. Was fehlt, ist die letzte idiomatische Eleganz. Aus „kill the competition“ wird nicht mehr grob, aber noch leicht kompetitiv. Aus aggressiver Männlichkeitsrhetorik wird korrekter HR-Sprech, aber nicht die souveräne, wirklich einladende Sprache einer erfahrenen Recruiterin.

Das Ergebnis ist brauchbar und professionell. Es ist nur nicht maximal feinfühlig. GPT-OSS 120B zeigt hier also keine kulturelle Blindheit, sondern eher einen Mangel an Nuance. Für interne Umschreibungen, Moderation und Erstentwürfe reicht das gut. Für hochsensible Kommunikation mit Marken- oder Diversity-Anspruch sollte ein Mensch den letzten Schliff setzen.

CLI und technische Ausführung: verlässlich in Struktur, nicht überragend in Präzision

Der CLI-Bereich fällt ordentlich aus, aber nicht spektakulär. Das passt zum Gesamtcharakter. GPT-OSS 120B ist in technischen Settings klar stark genug, um Aufgaben sinnvoll zu strukturieren, Befehle plausibel herzuleiten und Werkzeuge kontextbewusst zu nutzen. Es ist kein reines Coder-Modell, und man merkt das. Die Antworten sind nützlich, aber nicht auf Klingenlänge geschliffen.

Gerade in DevOps-nahen Szenarien hilft die Architektur mit Tool-Use-Fokus. Das Modell denkt in Schritten und Kontexten, nicht nur in Einzeilern. Das kann bei komplexeren Arbeitsabläufen wertvoller sein als die perfekte Kürze des einen magischen Kommandos. Wer allerdings millimetergenaue Shell-Präzision ohne jeden Ballast erwartet, findet anderswo schärfere Spezialisten.

Datenschutz und Datenhoheit

Ein eigener Datenschutz-Abschnitt ist hier nicht nötig, weil GPT-OSS 120B (vLLM, MXFP4) als lokales Open-Weights-Modell betrieben wird. Relevant ist vor allem die Provenienz der Gewichte: Das Weights-Provenienz-Risiko ist als LOW eingestuft, weil die Apache-2.0-lizenzierten OpenAI-Gewichte lokal laufen und damit kein API-bedingter Datenabfluss an den Hersteller stattfindet.

Fazit

GPT-OSS 120B (vLLM, MXFP4) im Thinking-Modus ist ein ernstzunehmender lokaler Generalist mit technischem Rückgrat, brauchbarer Sprachkompetenz und einer erfreulich disziplinierten Token-Ökonomie. Er ist kein Blender. Er findet Sicherheitslücken, löst Logikaufgaben korrekt, baut Produktionsskripte vernünftig um und kann Werkzeuge grundsätzlich sinnvoll einbinden. Für lokale Workflows ist das ein starkes Paket.

Aber das Modell hat zwei gut sichtbare Sollbruchstellen. Erstens fehlt ihm in mehreren Disziplinen die letzte redaktionelle oder didaktische Finesse. Die Antwort stimmt oft, aber glänzt nicht immer. Zweitens sind die Halluzinationen im Tool-Use-Bereich kein Schönheitsfehler, sondern ein Vertrauensproblem. Wenn ein Tool-Modell den Werkzeugausgang kreativ ergänzt, sägt es am eigenen Fundament.

Der Vergleich zum Standard-Lauf desselben Modells fällt knapp, aber aufschlussreich aus: Der Thinking-Modus bringt hier keinen großen Qualitätssprung. Der Gesamtscore liegt mit 73.41% sogar leicht unter dem Standard-Lauf mit 73.83%. Reasoning und CLI ziehen etwas an, UX Writing und Documentation verlieren. Der Charakter ändert sich stärker als die Bilanz. Thinking macht GPT-OSS 120B erklärender und etwas analytischer, aber nicht automatisch besser. Wer das Modell lokal für Security-Reviews, technische Analyse, Dokumentationsentwürfe oder agentische Vorarbeit mit kontrollierter Quellenprüfung einsetzen will, bekommt ein leistungsfähiges Werkzeug. Wer faktenkritische Tool-Workflows unbeaufsichtigt laufen lassen will, sollte sehr gute Validatoren haben. Sonst schreibt dieses Modell nicht nur Antworten. Es schreibt manchmal auch Wunschdenken.

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