Entwicklung & Code
GPT-OSS: Einblick in die offenen Modelle von OpenAI
Das lange Warten auf das erste OpenAI-Modell mit offenen Gewichten hat ein Ende: OpenAI hat am 5. August GPT-OSS veröffentlicht. Bei genauerer Betrachtung zeigt sich: Das Warten hat sich gelohnt. Das Modell funktioniert hervorragend und enthält viele Innovationen. Außerdem steht es unter der sehr liberalen Apache-2.0-Lizenz zur Verfügung.
Prof. Dr. Christian Winkler beschäftigt sich speziell mit der automatisierten Analyse natürlichsprachiger Texte (NLP). Als Professor an der TH Nürnberg konzentriert er sich bei seiner Forschung auf die Optimierung der User Experience.
Architektur der Modelle
Eigentlich hat OpenAI nicht ein Modell, sondern gleich zwei veröffentlicht. Neben dem großen Modell 120B mit 117 Milliarden Parametern gibt es auch noch ein kleines 20B-Modell mit 21 Milliarden Parametern.
Beide Modelle nutzen die Mixture-of-Experts-Architektur und benötigen damit in der Inferenzphase deutlich weniger aktive Parameter, die in die Berechnung eingehen. Besonders ausgeprägt ist das beim großen Modell, das lediglich vier seiner 128 Experten gleichzeitig nutzt. Dadurch gibt es zwischen den beiden Modellen keinen großen Unterschied bei der Zahl der aktiven Parameter. Das kleinere Modell ist daher nicht viel schneller, benötigt aber deutlich weniger Arbeitsspeicher (dazu später mehr).
Modell | GPT-OSS-120B | GPT-OSS-20B |
Anzahl Parameter | 117 Milliarden | 21 Milliarden |
Anzahl aktive Parameter | 5,1 Milliarden | 3,6 Milliarden |
Anzahl Layer | 36 | 24 |
Anzahl Experten | 128 | 32 |
Anzahl aktive Experten | 4 | 4 |
Anzahl Attention Heads | 64 | 64 |
Interessant ist die Architektur der Layer: OpenAI verwendet abwechselnd eine volle Attention, also den Blick auf den gesamten Inhalt, und eine mit dem sogenannten Sliding Window, bei dem es die Inhalte in kleinere, überlappende Segmente aufteilt. Diese Variante benötigt deutlich weniger Speicher und Rechenzeit, kann aber weniger gut mit langen Kontexten umgehen. Das gleicht die volle Attention in den jeweils dazwischenliegenden Layern aus.
Weniger Speicherbedarf, flexibleres Reasoning
Auf der Model Card bei Hugging Face steht, dass das große Modell auf einer H100-GPU ausführbar ist. Das ist zunächst erstaunlich, denn 121 Milliarden Parameter sind selbst im von DeepSeek verwendeten sparsamen FP8-Format (8-bit Floating Point) zu groß. Allerdings hat OpenAI noch weiter gespart und die Gewichte im noch kompakteren MXFP4-Format (Microscaling 4-bit Floating Point) veröffentlicht, das nur halb so viel Speicher benötigt. Damit erfordert das Modell nur 60 GByte RAM für die Gewichte. Der Nachteil dabei ist, dass nur die in H100- oder RTX 5090-Karten verwendeten Hopper-GPUs von Nvidia mit diesem Format effizient rechnen können.
Auf GPUs der älteren Generation laufen die Modelle zwar, brauchen aber viermal so viel Speicher. Ein Schelm, der dabei an Cross-Sponsoring mit Nvidia denkt. Bemerkenswert ist dennoch, dass sich innerhalb nur eines Jahres das etablierte bfloat16-Format jetzt (zumindest bei diesen Modellen) auf vier Bit verkürzt hat und damit nur noch ein Viertel des Speicherplatzes notwendig ist.
OpenAI erlaubt außerdem, das Reasoning der GPT-OSS-Modelle zu konfigurieren. Man kann also festlegen, wie ausführlich die Modelle ihre Gedanken exponieren sollen. Das ist äußerst nützlich, weil manche Modelle im Reasoning-Mode zu geschwätzig sind und eine Menge Token erzeugen. Man muss also nicht nur lange Ausführungen lesen und auf das Generieren warten, sondern auch für viele Token zahlen. Wie gut diese Einstellung wirklich funktioniert, muss die Praxis zeigen.
Das neue Harmony Response Format
Bei den hybriden Qwen3-Modellen von Alibaba lässt sich durch die Angabe von /no_think
im Prompt das Reasoning ausschalten, was wenig flexibel ist. Hier hat sich OpenAI mehr Gedanken gemacht und gleich ein neues Chatformat definiert: Das Harmony Response Format ist sehr viel flexibler als alle bisherigen Chat-Templates und lässt viele Möglichkeiten der Interaktion mit den Modellen zu.
Bei näherer Betrachtung ist es fast erstaunlich, dass man so lange an den – jetzt überkommen erscheinenden – Chat-Templates festgehalten hat. Spannend ist, dass sich beim Ausprobieren des Harmony-Codes der Knowledge Cut-off von GPT-OSS im Juni 2024 findet, die jüngsten Trainingsdaten für das Modell also über ein Jahr alt sind. Dass es für Harmony auch Rust-Code gibt, könnte ein Hinweis darauf sein, dass OpenAI intern mit der Programmiersprache arbeitet, um die Effizienz der Software zu erhöhen.
Harmony ist ein deutlich flexibleres Format als die bisherigen Chat-Templates. Es erlaubt mehr Meta-Instruktionen und sogenannte Channels, die das Modell auch bei der Antwort berücksichtigt. Bei allen Vorteilen hat Harmony aber auch einen Nachteil: Durch das Verarbeiten der zusätzlichen Bereiche wie Regeln und Channels produziert das System viele Token. Die dadurch verringerte Effizienz kann auch ein abgemildertes Reasoning nicht kompensieren.
(Bild: Sikorka/Shutterstock)
Die Online-Konferenz LLMs im Unternehmen am 29. Oktober zeigt, wie man das passende Modell auswählt, die Infrastruktur aufbaut und die Sicherheit im Griff behält. Außerdem gibt der Thementag von iX und dpunkt.verlag einen Ausblick auf Liquid Foundation Models als nächste Generation von LLMs.
GPT-OSS ist ein agentisches Modell, das Funktionen aufrufen kann. OpenAI geht dabei noch einen Schritt weiter und erlaubt neuerdings das Browsen im Web. Anbieter wie Anthropic ermöglichen jedoch schon länger, mit ihren Modellen den Browser zu steuern, und Perplexity bietet sogar einen eigenen Browser an. GPT-OSS ermöglicht es außerdem, Python-Code auszuführen. Wie weit man dem generierten Code vertrauen kann, lässt sich auf Anhieb nicht gesichert sagen.
Über Details des Trainingsprozesses schweigt OpenAI sich ebenso aus wie über die dafür verwendeten Daten. Hier kocht jeder vermutlich sein eigenes Süppchen, auch die chinesischen Modellanbieter hüllen sich dazu in Schweigen. Nur für Olmo vom Allen AI Institute und SmolLM von Hugging Face sind wirklich alle Details veröffentlicht.