OpenAI gpt-oss: Architektur, Quantisierung, Tokenizer und Ressourcen
Wir sind beeindruckt von den Open-Source-Modellveröffentlichungen, die wir derzeit sehen – etwa Kimi K2, Qwen3 Coder und GLM-4.5 (ein Artikel dazu folgt bald) – vor allem, wenn man bedenkt, welche starken Fortschritte diese agentischen Modelle mit kluger mehrstufiger Argumentation, Programmierleistung und überzeugender Tool-Nutzung zeigen.
Mit gpt-oss hat OpenAI die erste große Open-Source-Modellveröffentlichung seit über fünf Jahren vorgestellt – nach GPT-2 im Jahr 2019. Diese Modellfamilie erscheint unter der freizügigen Apache-2.0-Lizenz. Das bedeutet im Wesentlichen, dass du das Modell breit einsetzen, anpassen und weitergeben darfst – auch kommerziell –, solange du die ursprünglichen Lizenz- und Copyright-Hinweise beibehältst und Änderungen nachvollziehbar kennzeichnest.
Modellvarianten und Hardware-Anforderungen
Das Modell gibt es in zwei Größen: 120B und 20B. Die 120B-Variante umfasst 117 Milliarden Gesamtparameter (davon 5,1 Milliarden aktiv pro Token) über 36 Layer. Die 20B-Variante bringt 21 Milliarden Gesamtparameter (3,6 Milliarden aktiv pro Token) und 24 Layer mit. Beide Modelle setzen auf eine native 4-Bit-(MXFP4)-Quantisierung für ihre Mixture-of-Experts-Gewichte. Dadurch passt das 120B-Modell auf eine einzelne 80-GB-GPU, während das 20B-Modell mit ungefähr 16 GB Speicher betrieben werden kann.
Wichtigste Punkte
- OpenAI veröffentlicht gpt-oss als erstes bedeutendes Open-Source-Modell seit GPT-2 (2019) unter der Apache-2.0-Lizenz
- Zwei Varianten: 120B und 20B – beide mit 4-Bit-(MXFP4)-Quantisierung für MoE-Gewichte; das 120B-Modell läuft auf einer einzelnen 80-GB-GPU
- Zentrale Architektur-Bausteine: MoE, Gated SwiGLU, GQA, SWA, RoPE, erweitertes Kontextfenster über YaRN, Attention Sinks
- Quantisierung: Native Microscaling FP4 (MXFP4) mit MoE-Gewichten bei 4,25 Bit pro Parameter
- Tokenizer: o200k_harmony (ein BPE-basierter Tokenizer), verfügbar über TikToken
- Schwerpunkt nach dem Training: Reasoning, Tool-Nutzung (Browsing, Python, Developer Functions) sowie Sicherheit über CoT-RL
- Nutzt das Harmony Chat Format, um Training und Deployment konsistent zu halten
Modellarchitektur
Wir starten mit einem Blick auf die Architektur des Modells. Damit die wichtigsten Spezifikationen und ihre Bedeutung leichter verständlich sind, haben wir sie in einer Tabelle zusammengefasst.
Spezifikationen und Bedeutung
| Spec | Relevance |
|---|---|
| Mixture of Experts | In gpt-oss nutzt die Mixture-of-Experts-(MoE)-Architektur spärliche Feedforward-Neural-Network-(FFN)-Layer, die als Experts fungieren, sowie einen Gating-Mechanismus (Router), der Tokens zu den Top-4-Experts weiterleitet. Dadurch wird pro Token nur ein Teil der Parameter aktiviert. Das ist besonders attraktiv, weil es eine rechen-effiziente Alternative zu vollständig dichten Modellen darstellt. |
| Gated SwiGLU activation function | Aktivierungsfunktionen bringen Nichtlinearität ins Modell und ermöglichen es, komplexe Muster zu lernen. Die MoE-Blöcke in gpt-oss verwenden eine gated SwiGLU-Aktivierungsfunktion – SwiGLU gilt aktuell als Standard in modernen LLMs. Laut gpt-oss-Model-Card ist die SwiGLU-Implementierung hier ungewöhnlich, weil sie Clamping und eine Residual-Verbindung enthält. Diese Anpassungen dürften eine stabilere Optimierung und schnellere Konvergenz unterstützen, besonders bei großen Transformer-Systemen. Residual- bzw. Skip-Connections schaffen dabei Abkürzungspfade, sodass der Input eines Layers direkt zum Output addiert werden kann, ohne alle Zwischenschritte vollständig durchlaufen zu müssen. |
| Grouped Query Attention (GQA) Sliding Window Attention (SWA) | Die Model-Card beschreibt dies als abwechselnde Attention-Blöcke mit vollständig dichter und bandförmiger Fensterstruktur. Praktisch bedeutet das: Die Attention-Layer wechseln zwischen Grouped Query Attention und Sliding Window Attention. Gpt-oss nutzt 8 Key-Value-Heads. Zusätzlich besitzt jeder Attention-Head einen lernbaren Bias im Nenner der Softmax, was an Off-by-one-Attention erinnert. |
| Rotary Position Embeddings | RoPE codiert Positionen, indem Query- und Key-Vektoren abhängig von der Token-Position rotiert werden. Diese Positionscodierung ist entscheidend, weil Attention-Mechanismen die Reihenfolge der Tokens nicht von sich aus verstehen. |
| Context Length of dense layers = 131 072 | Die dichten Layer unterstützen ein Kontextfenster von 131.072 Tokens durch YaRN. YaRN (Yet another RoPE-scaling method) ist eine rechen-effiziente Methode, um das Kontextfenster transformerbasierter Modelle zu erweitern. |
| Attention Sinks | Attention Sinks sind Tokens, die am Anfang einer Sequenz platziert werden, um die Attention zu stabilisieren – besonders hilfreich bei sehr langen Kontexten. |
Quantisierung
Der Ansatz zur Quantisierung ist hier besonders bemerkenswert. Die gpt-oss-Modelle werden nativ mit Microscaling FP4 (MXFP4) trainiert. Dabei werden die MoE-Gewichte (rund 90 % der gesamten Parameteranzahl) auf 4,25 Bit pro Parameter quantisiert. Um Microscaling tiefer zu verstehen, empfehlen wir die OCP Microscaling Formats (MX) Specification Version 1.0, insbesondere Abschnitt 5.
Tokenizer
Der o200k_harmony-Tokenizer wird über sämtliche Trainingsphasen hinweg eingesetzt. Es handelt sich um einen BPE-basierten Tokenizer mit einem Vokabular von 200.000 Tokens. Dieser Tokenizer ist Open Source, über TikToken verfügbar und basiert auf dem o200k-Tokenizer, der in anderen OpenAI-Modellen genutzt wird.
Schwerpunkt nach dem Training
Das Post-Training von gpt-oss konzentriert sich auf Reasoning, Tool-Nutzung (Browsing, Python und Developer Functions), Sicherheit über CoT-RL-Techniken sowie auf das Harmony Chat Format. Soweit wir wissen, wurden die Datensätze und RL-Umgebungen, die für dieses Modell verwendet wurden, nicht veröffentlicht.
OpenAI Harmony Chat Format
Chat-Templates sind aus mehreren Gründen entscheidend. Wenn das Chat-Format zwischen Training und Deployment gleich bleibt, lassen sich Performance-Verluste vermeiden. Ähnlich wie Tokenizer legen Chat-Templates fest, wie Daten verarbeitet werden. OpenAI nutzt beim Training von gpt-oss ein eigenes Chat-Format, das als Harmony Chat Format bezeichnet wird. Es enthält spezielle Tokens zur Markierung von Message-Grenzen sowie Rollen-Tags wie User, Assistant, System und Developer.
Konflikte werden im Modell über eine Rollen-Hierarchie aus System, Developer, User, Assistant und Tool aufgelöst. Zusätzlich werden Channels genutzt, um zu steuern, welche Inhalte für Analyse, Commentary und Final Output sichtbar sind.
Dieses Design unterstützt fortgeschrittene agentische Fähigkeiten, einschließlich ineinander verschachtelter Tool-Calls.
Zusätzliche Ressourcen
Konzeptionelle Übersichten
The Illustrated GPT-OSS – von Jay Alammar: Die Visualisierungen in diesem Beitrag eignen sich hervorragend, um ein intuitives Verständnis sowohl der gpt-oss-Architektur als auch des verwendeten Message-Formats zu entwickeln. Besonders gefällt uns, wie erklärt wird, dass unterschiedliche User-Rollen (zum Beispiel ChatGPT-Endnutzer, Builder von LLM-Apps wie cursor oder Personen im Post-Training) durch die Art unterstützt werden, wie das Format Inputs und Outputs formt (etwa Reasoning-Traces und Tool-Interaktionen) innerhalb des Modells.
From GPT-2 to gpt-oss: Analyzing the Architectural Advances – von Sebastian Raschka: Dieser Artikel ist herausragend, weil er verdeutlicht, wie weit die Entwicklung seit GPT-2 vorangeschritten ist. Er bietet sehr detaillierte und gründliche Erklärungen zu Konzepten wie RoPE, SwiGLU, Mixture of Experts, GQA, SWA und RMSNorm.
SwiGLU
What is SwiGLU? von jcarlosroldan: Dieser Beitrag liefert hilfreichen Kontext dazu, warum SwiGLU zur bevorzugten Aktivierungsfunktion in modernen LLMs geworden ist.
Chat-Format
Chat Templates: An End to the Silent Performance Killer : Chat-Templates sind Jinja-basierte Templates, die in Tokenizern eingebettet sind und Unterhaltungen automatisch in die Struktur formatieren, auf der ein Modell trainiert wurde. Der Artikel erklärt, dass die Performance still nachlassen kann, wenn Prompts nicht exakt im erwarteten Format vorliegen – nicht zwingend durch Fehler, aber durch schlechtere Ergebnisse.
Denke daran, dass gpt-oss das Harmony Chat Format nutzt.
Microscaling
OCP Microscaling Formats (MX) Specification Version 1.0 : Diese Ressource erweitert das Verständnis zu Microscaling-Formaten aus dem Open Compute Project (OCP). Abschnitt 2 beschreibt, wie MX-Formate zu den Kernprinzipien des OCP passen: offen und gemeinsam von großen Industrieakteuren entwickelt und auf früheren offenen Standards basierend; effizient, weil geringere Präzision und weniger Speicherbedarf zu niedrigeren Kosten und besserer Performance führen; wirkungsvoll, da breite Unterstützung sie wahrscheinlich zum Industriestandard macht; skalierbar, weil sie für einfache Adoption auf bestehender Hardware ausgelegt sind; und nachhaltig, weil sie Energieverbrauch und CO₂-Emissionen in AI-Workloads senken.
GitHub – microsoft/microxcaling: PyTorch emulation library for Microscaling (MX)-compatible data formats : Dieses GitHub-Projekt emuliert MX-kompatible Formate und bfloat-Quantisierung in PyTorch. Obwohl Berechnungen mit float32/bfloat16/fp16 ausgeführt werden, respektiert die Library die darstellbaren Wertebereiche von MX- oder bfloat-Formaten. Sie unterstützt Matrix-Multiplikation (torch.matmul, torch.linear, torch.bmm) für MX-Tensoren sowie elementweise Operationen wie GELU, softmax und layernorm, wobei grundlegende Operationen (darunter add, sub, sqrt, exp) mit bfloat-Präzision durchgeführt werden.
Microscaling Data Formats for Deep Learning: Das ist das Paper, das die Idee von Microscaling-Datenformaten ursprünglich eingeführt hat.
1.5x Faster MoE Training on Blackwell with MXFP8 Kernels Built from Scratch | Cursor – The AI Code Editor: Dieser Artikel erklärt, wie Cursor eine 1,5-fache Beschleunigung beim End-to-End-Training großer Sprachmodelle auf Blackwell-GPUs erreicht hat. Durch den Neuaufbau von Mixture-of-Experts-Layern mit eigenen MXFP8-Kernels konnten Trainingszeit und Kosten reduziert werden, was Fortschritt und SOTA-Deployment beschleunigt.
Beachte, dass gpt-oss für die linearen Projektionsgewichte im MoE-Layer MXFP4 verwendet und nicht MXFP8.
Implementierungen
Fine-tuning with gpt-oss and Hugging Face Transformers: „On a H100 GPU, this takes about 18 minutes to train, but may take longer depending on your hardware.“
Ollama (gpt-oss 20b, ~14GB of VRAM): „Ollama is supporting the MXFP4 format natively without additional quantizations or conversions. New kernels are developed for Ollama’s new engine to support the MXFP4 format. Ollama collaborated with OpenAI to benchmark against their reference implementations to ensure Ollama’s implementations have the same quality.”
Unsloth (gpt-oss 20b, ~14GB of VRAM): „We utilized OpenAI’s Triton Kernels library directly to allow MXFP4 inference. For finetuning / training however, the MXFP4 kernels do not yet support training, since the backwards pass is not yet implemented. We’re actively working on implementing it in Triton!”
Weitere Implementierungen sind im gpt-oss-Repository verlinkt.
Es gibt viele hervorragende Ressourcen da draußen – kommentiere also gern, falls etwas Wichtiges ergänzt werden sollte.
Abschließende Gedanken
Während der Recherche für diesen Artikel waren wir überrascht, wie viel Content rund um gpt-oss veröffentlicht wurde – von News-Berichten über YouTube-Videos und Blogposts bis hin zu community-entwickelten Base-Modellen und mehr. Es ist klar, dass die Community stark motiviert ist, weil OpenAI Open-Source-Modelle veröffentlicht, und wir freuen uns darauf zu sehen, wie diese Modelle genutzt werden, wie sie sich im Vergleich zu ähnlichen Alternativen schlagen und was Entwickler damit erschaffen.
