GPT-OSS 120B

Mit einem Gesamtscore von 73.83% ist GPT-OSS 120B (vLLM, MXFP4) ein ernstzunehmender Generalist mit klar erkennbarem Profil, aber ohne die glatte Selbstverständlichkeit der besten Modelle. Das passt zur Einordnung: Server-Klasse, Generalist, MoE-Architektur mit 116,8 Milliarden Gesamtparametern, von denen pro Token nur 5,1 Milliarden aktiv sind. Man bekommt also nicht die rohe Wucht eines voll aktiven 120B-Dense-Modells, sondern die gezielte Arbeit eines Expertensystems auf Diät. Der Speed Profile Badge lautet Interactive Tool Expert: gedacht für dialogische Tool-Aufgaben mit interaktivem Anspruch, nicht für stoisches Massenschreiben. Die getestete Variante lief im Modus Standard, also ohne aktivierten Thinking-Toggle. Kürzere, direktere Antworten sind hier Erwartungswert und kein Mangel.

Kopfnoten: Stabilität und Zuverlässigkeit

Die Stabilitätsnote fällt gespalten aus. Es gibt keine Ausfälle, keine stillen Wegkipper, keine Retry-Lotterie. Das ist gerade bei lokalen Open-Weights-Modellen mehr wert, als es auf den ersten Blick aussieht. Gleichzeitig streut die Antwortzeit in den langen fünf Prozent deutlich zu stark für wirklich zackige Arbeitsabläufe. Wer GPT-OSS 120B (vLLM, MXFP4) als Werkzeug für interaktive Tool-Ketten einsetzen will, bekommt Verlässlichkeit, aber nicht immer Rhythmus.

Architektur und Modus: ein MoE-Generalist mit konfigurierbarem Kopf

Die vorab vergebene Kategorie trifft den Charakter erstaunlich präzise. Dieses Modell ist ein Generalist, kein Spezialist. Es gehört zur Server-Klasse und nutzt eine Mixture-of-Experts-Architektur, kurz MoE. Das heißt: Das Modell trägt nominell sehr viele Gewichte mit sich herum, aktiviert aber pro Token nur einen kleinen Teil davon. Relevanter als die große Zahl auf dem Karton sind hier die 5,1 Milliarden aktiven Parameter. Genau daran sollte man auch die Leistung messen.

Das erklärt viel. GPT-OSS 120B (vLLM, MXFP4) wirkt in mehreren Disziplinen kompetent, oft sogar elegant, aber selten massiv überlegen. Es hat Breite, nicht die Brutalität eines Frontier-Dense-Modells. Das Tag Configurable-Reasoning ist ebenfalls wichtig, auch wenn dieser Testlauf ausdrücklich im Standard-Modus stattfand. Das Modell kann grundsätzlich tieferes Schlussfolgern hochfahren, wurde hier aber ohne diesen Hebel gemessen. Wer also bei Reasoning nicht durchgehend das Maximum sieht, schaut nicht auf einen Defekt, sondern auf die bewusst nüchterne Betriebsart.

Dazu kommen Native-Quant und MXFP4. Das ist keine bloße Implementierungsnotiz, sondern Teil des Charakters. Das Modell ist auf effizienten lokalen Betrieb getrimmt, ohne sich wie ein zusammengefaltetes Notmodell anzufühlen. Harmony und Tool-Use schließlich deuten auf eine Architektur, die Analyse, Werkzeugaufrufe und Endantwort sauberer trennt als viele ältere Instruct-Modelle. In der Praxis hilft das. Es immunisiert aber nicht gegen Halluzinationen, wenn externe Tool-Ergebnisse falsch zusammengebaut oder ausgeschmückt werden.

Geschwindigkeit und Token-Ökonomie

Als lokales Modell auf dem Referenzsystem ASUS GX10 / NVIDIA DGX Spark (GB10 Grace Blackwell Superchip, ~115 GB Unified Memory — kein praktisches Speicherlimit für getestete Modellgrößen) zeigt GPT-OSS 120B (vLLM, MXFP4) ein ungewöhnlich attraktives Geschwindigkeitsprofil für seine nominelle Größe. Der Badge Interactive Tool Expert ist hier gut gewählt. Das Modell fühlt sich nicht wie ein Batch-Schreiber an, der erst einmal tief Luft holt und dann ein Manuskript ausrollt. Es ist eher auf direkte Interaktion, Tool-Antworten und strukturierte Folgearbeit ausgelegt.

Wichtiger als reine Geschwindigkeit ist die Ökonomie. Hier arbeitet das Modell diszipliniert. Kein Modul überschreitet den erwarteten Verbosity-Rahmen. Besonders bemerkenswert ist das im Reasoning-Bereich: Die Antworten sind nicht knapp um des Knappseins willen, sondern knapp genug, um nicht in erklärende Watte abzudriften. In den übrigen Modulen bleibt GPT-OSS 120B (vLLM, MXFP4) ebenfalls innerhalb vernünftiger Textmengen. Das ist bei einem Modell mit konfigurierbarem Reasoning keine Selbstverständlichkeit. Manche Kandidaten reden sich zu Tode. Dieses hier nicht.

Code Quality: viel Sicherheitsinstinkt, etwas zu wenig Schärfe

Im Code-Quality-Modul gehört GPT-OSS 120B (vLLM, MXFP4) klar zu den besseren Allroundern. Es erkennt die großen Baustellen zuverlässig: SQL Injection an mehreren Stellen, Klartext-Passwörter, Path Traversal, Privilege Escalation über Cookies, Session Fixation, IDOR, schwache Token-Erzeugung, CSRF, hartkodierte Secrets, Debug-Leaks. Das ist nicht bloß Fleißarbeit, sondern ein Zeichen dafür, dass das Modell Sicherheitsmuster breit und sauber mappt.

Die Schwäche liegt eine Etage tiefer. Ausgerechnet eine vergleichsweise klassische XSS-Stelle in der Welcome-Ausgabe blieb liegen. Das ist kein kosmetischer Kratzer. Wenn ein Modell in einer systematischen Sicherheitsanalyse einen Standard-OWASP-Treffer übersieht, schrumpft das Vertrauen in seine Vollständigkeit sofort. Dazu fehlt der Blick für Angriffsketten. Die Einzelprobleme werden genannt, aber nicht konsequent zu einem realistischen Exploit-Pfad verdichtet, etwa von IDOR über Passwort-Reset bis zur Übernahme. Genau dort trennt sich solide Fehlererkennung von echter Security-Kompetenz.

Positiv ist die Form. Die verlangte Markdown-Tabelle saß, die Erklärungen blieben knapp, die Schweregrade waren meist plausibel gesetzt. Für Entwickler, die erst einmal ein Audit-Raster brauchen, ist das nützlich. Für ein Team, das Priorisierung unter Zeitdruck braucht, fehlt noch die letzte Präzision. GPT-OSS 120B (vLLM, MXFP4) sieht die Rauchwolke zuverlässig. Wo genau das Feuer zuerst gelöscht werden muss, erklärt es nicht immer mit der nötigen Schärfe.

Logik und Reasoning: korrekt, sauber, etwas zu brav

Im Reasoning-Modul zeigt das Modell eine der sympathischeren Seiten seines Charakters. Es löst die klassische Wächteraufgabe korrekt, erklärt den doppelten Inversionsmechanismus sauber und bleibt dabei gut lesbar. Die Antwort ist aufgeräumt, in Deutsch durchgehend konsistent und vermeidet unnötiges Ausschmücken. Für den Standard-Modus ist das ein gutes Signal. GPT-OSS 120B (vLLM, MXFP4) denkt nicht laut bis zum Sonnenuntergang, sondern liefert.

Gerade weil das Modell als konfigurierbares Reasoning-System klassifiziert ist, muss man aber auch benennen, was fehlt. Die Erklärung bleibt auf der richtigen, aber eher nüchternen Ebene. Visualisierung, Robustheitsargument, pädagogische Tiefe und die Verallgemeinerung als Muster selbstreferenzieller Fragen werden nur angerissen oder ganz ausgelassen. Das Ergebnis stimmt. Die didaktische Eleganz bleibt hinter stärkeren Reasoning-Kandidaten zurück.

Immerhin: Der konkrete Metakognitions-Test zeigt, dass das Modell die geforderten <thought>-Tags in diesem Fall verwendet und die Formatvorgabe nicht verweigert hat. Das ist keine Nebensächlichkeit. Gerade Modelle aus Harmony-naher Denkschule ecken an solchen Benchmarks gern an, weil sie intern anders organisiert sind als vom Prompt verlangt. Hier war das Modell kooperativ genug, um nicht an seiner eigenen Architekturhaltung zu scheitern.

Content Transformation und UX-Nähe: praktisch stark, aber nicht immer fein genug

Die Stärke von GPT-OSS 120B (vLLM, MXFP4) in Content-Transformation liegt in seiner praktischen Verwendbarkeit. Das zeigt der lange Videoskript-Test sehr gut. Das Modell liefert ein vollständiges, editorisch brauchbares Skript mit Zeitmarken, Produktionshinweisen, Pausenmarkern, CTA, B-Roll-Ideen und Easter Egg. Das ist mehr als bloße Textproduktion. Es ist anwendungsnahes Arbeiten.

Aber auch hier gilt: brauchbar ist nicht identisch mit brillant. Die vorgeschaltete Analyse blieb zu pauschal und weniger scanbar als die Referenz. Das Skript wirkte funktional, aber in der Taktung leicht zu ausufernd. Der Titel versprach fünf Minuten, der Text lag eher darüber. Solche Differenzen klingen klein, sind im Produktionsalltag aber kein Detail. Videoformate sterben an falscher Länge oft schneller als an mittelmäßiger Sprache.

Sprachlich ist das Modell ordentlich, teils sogar angenehm unprätentiös. Ihm fehlt aber bisweilen die idiomatische Finesse, die aus korrektem deutschen Text einen wirklich treffsicheren deutschen Text macht. Das sieht man auch bei der Umformulierung toxischer Stellen in Recruiting-Texten. Das Modell entschärft offen problematische Begriffe zuverlässig und korrigiert Gender-Schieflagen solide. Gleichzeitig lässt es Restaggressionen wie „die Konkurrenz herausfordern“ stehen, wo eine kultiviertere Lösung den Ton vollständig neutralisiert hätte. Das ist typisch für dieses Modell: selten grob daneben, aber nicht immer mit dem letzten Gefühl für den kulturellen Unterton.

Cultural Intelligence: kompetent, aber nicht maximal kalibriert

Im Bereich Cultural Intelligence zeigt GPT-OSS 120B (vLLM, MXFP4), dass es diskriminierende oder toxische Vorlagelemente durchaus erkennt und in eine professionellere Form überführt. Die deutsche Sprache sitzt, die Antwort bleibt ohne Sprachmischung, die Aufgabe wird formal sauber erfüllt. Auch geschlechtergerechte Neutralisierung gelingt hier grundsätzlich.

Die offene Flanke ist die kulturelle Feinabstimmung. Das Modell entfernt die groben Splitter, schleift aber nicht jede scharfe Kante weg. Gerade im deutschsprachigen Recruiting ist der Unterschied zwischen „formal korrekt“ und „wirklich einladend“ größer, als viele Modelle glauben. Die Referenz löst das psychologisch inklusiver, idiomatischer und mit mehr Gespür für einladende Rahmung. GPT-OSS 120B (vLLM, MXFP4) bleibt dagegen etwas technokratischer. Es säubert den Text. Es verwandelt ihn nicht vollständig in einen Text, der Vertrauen ausstrahlt.

Tool-Use, Halluzinationen und Sicherheitsvertrauen: hier wird es ernst

Die größte Warnlampe des Modells hängt nicht am allgemeinen Schreiben, nicht am Coding, nicht einmal am Reasoning. Sie hängt am Tool-Use. Drei erkannte Halluzinationsverstöße in Tool-Aufgaben sind kein Betriebsrauschen, sondern ein handfester Vertrauensbruch. In den betroffenen Aufgaben generierte das Modell Inhalte, die nicht aus dem abgerufenen Tool-Ergebnis stammten, sondern erfunden waren. Der Score wurde dort per Halluzinations-Cap begrenzt. Das ist methodisch hart und inhaltlich vollkommen richtig.

Für Leser außerhalb des Benchmark-Kosmos die Übersetzung in Alltagssprache: Wenn ein Modell in einer Werkzeugkette recherchiert, Daten abfragt oder externe Resultate zusammenfasst, darf es nichts hinzudichten. Tut es das doch, ist die Antwort für faktenkritische Anwendungen entwertet. Genau das ist hier passiert, und zwar nicht einmalig. Im Tool-Use-Bereich muss man GPT-OSS 120B (vLLM, MXFP4) deshalb mit deutlich mehr Misstrauen behandeln als es sein sonstiger Gesamteindruck nahelegt.

Hinzu kommt ein besonders unangenehmer Befund: In einer Tool-Use-Aufgabe meldete das Modell Erfolg, produzierte aber keinen sichtbaren Antworttext. Das bedeutet entweder eine stille Verweigerung, einen Silent-Failure in der Laufzeitkette oder einen rein internen Reasoning-Output ohne präsentierte Endantwort. In jedem Fall gab es keinen bewertbaren Output. Für Agenten-Frameworks ist so etwas tückisch, weil die Pipeline formal „grün“ meldet, inhaltlich aber nichts vorliegt. Das ist die Sorte Fehler, die nachts Pager auslöst.

Weil das Modell die Architektur-Tags Harmony und Tool-Use trägt, wiegt dieser Befund doppelt. Man darf von einem so etikettierten System erwarten, dass es Werkzeugergebnisse diszipliniert behandelt. Genau diese Disziplin ist hier nicht stabil genug vorhanden. Wer GPT-OSS 120B (vLLM, MXFP4) für Recherche, Reports oder automatisierte Datenzusammenfassungen nutzen will, braucht eine nachgeschaltete Validierung. Ohne Sicherheitsgurt ist das zu viel Vertrauen in ein Modell, das in diesem Bereich bereits den Bordstein berührt hat.

Dokumentation, CLI und der Allround-Eindruck

Die reinen Teilwerte zeichnen ein Modell, das als Generalist breit anschlussfähig ist. In CLI- und Dokumentationsaufgaben reicht es für ordentliche, teils gute Leistungen, aber nicht für jene mechanische Präzision, mit der sich Spitzenmodelle in DevOps-nahen Benchmarks unangreifbar machen. Das passt wieder zum Gesamtbild: GPT-OSS 120B (vLLM, MXFP4) ist kein Spezialwerkzeug, sondern ein gut trainierter Universalist mit Techniknähe.

Gerade deshalb ist die Kombination aus vernünftiger Code-Qualität, brauchbarer Dokumentationskompetenz und lokalem Betrieb attraktiv. Das Modell scheitert nicht an banalen Formatfragen, produziert keine ausufernden Textlawinen und bleibt in den meisten Disziplinen auf arbeitsfähigem Niveau. Es ist ein brauchbarer Kollege. Nur eben keiner, dem man ungeprüft die Schlüssel zum Serverraum und zur Faktenredaktion zugleich geben sollte.

Datenschutz und Datenhoheit

Da GPT-OSS 120B (vLLM, MXFP4) als lokales Open-Weights-Modell eingesetzt wird, stellt sich die Datenschutzlage hier anders dar als bei einer Cloud-API. Die Gewichte stammen von OpenAI, einem US-Unternehmen, und das Weights-Provenienz-Risiko ist dennoch als LOW eingestuft. Der entscheidende Grund ist schlicht: Beim lokalen Deployment fließen keine Nutzdaten an OpenAI-Server ab. Für europäische Unternehmen ist das ein realer Vorteil, weil Datenhoheit technisch durch die Betriebsform und nicht bloß vertraglich abgesichert wird.

Fazit

GPT-OSS 120B (vLLM, MXFP4) ist ein interessantes Modell mit erwachsenem Profil. Als lokaler Generalist der Server-Klasse liefert es breite Kompetenz, sehr gute Token-Disziplin, hohe Praxisnähe in Transformationsaufgaben und eine solide bis gute technische Grundintelligenz. Die MoE-Architektur mit nur 5,1 Milliarden aktiven Parametern erklärt, warum das Modell effizienter wirkt als sein Gesamtparameterwert vermuten lässt. Es ist kein Blender. Aber es ist auch kein Alleskönner.

Die Schwächen sind präzise benennbar. Im Security-Kontext fehlt gelegentlich der letzte Blick für Vollständigkeit und Angriffsketten. Im Reasoning ist das Modell korrekt, aber nicht außergewöhnlich tief. Im Sprach- und Kulturbereich arbeitet es sauber, jedoch nicht immer mit feinem Ohr. Und beim Tool-Use sitzt die eigentliche Hypothek: wiederholte Halluzinationen auf Basis externer Ergebnisse und ein Fall ohne sichtbare Antwort. Für content-kritische, toolgestützte Prozesse ist das kein Schönheitsfehler, sondern eine rote Linie.

Im direkten Vergleich mit dem ebenfalls vorliegenden Thinking-Lauf zeigt sich ein aufschlussreicher Unterschied: Der Standard-Modus erreicht den leicht höheren Gesamtscore und wirkt balancierter, während der Thinking-Modus etwas stärker im Logik- und Tool-Bereich auftritt, dafür aber in UX-nahen und dokumentarischen Aufgaben an Geschmeidigkeit verliert. Das spricht für eine ungewöhnlich klare Empfehlung. Wer GPT-OSS 120B (vLLM, MXFP4) lokal als Allround-Assistenten, technischen Schreibpartner oder strukturierten Code-Reviewer nutzen will, ist im Standard-Modus besser aufgehoben. Wer gezielt an kniffligeren Denkaufgaben sitzt, kann den Thinking-Schalter erwägen. Für unbeaufsichtigte Tool-Pipelines mit Faktenanspruch bleibt dieses Modell trotz vieler Qualitäten ein Kandidat mit Aufsichtspflicht. Das ist kein Verriss. Es ist ein Respekturteil mit Warnhinweis.

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.