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.

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).

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.

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.

Event-getriebene Architektur klingt zunächst nach einem radikalen Paradigmenwechsel – und das ist sie auch. Doch gerade weil sie auf einer anderen Denkweise beruht, ist der Einstieg oft einfacher, als viele glauben. Entscheidend ist, dass man nicht mit der Technik beginnt, sondern mit dem gemeinsamen Verständnis.

Dieser letzte Teil der Serie zeigt, wie man ein solches System in der Praxis aufbaut, welche typischen Stolperfallen man dabei vermeiden sollte und wie man Event-getriebene Architektur schrittweise einführen kann.

Reden ist wichtiger als Code

Am Anfang steht kein Code, kein Framework, keine Datenbank – sondern ein Gespräch. Wer Event-getriebene Systeme bauen will, muss zuerst verstehen, was in der Domäne passiert. Und das gelingt am besten im Dialog mit den Menschen, die diese Domäne kennen: den Fachexpertinnen und -experten.

Ein erster Schritt kann sein, gemeinsam Ereignisse zu sammeln: Was passiert in eurem Tagesgeschäft? Welche Abläufe gibt es? Welche Entscheidungen werden getroffen? Was ist wichtig, was ist selten, was ist kritisch?

Dabei hilft es, ganz bewusst in der Sprache der Fachlichkeit zu bleiben – ohne technische Begriffe, ohne JSON-Formate, ohne Implementierungsdetails.

Event Storming und ähnliche Methoden

Bewährt haben sich dabei Formate wie Event Storming: Man klebt Events als Post-Its an eine Wand, ordnet sie zeitlich und diskutiert darüber. So entstehen Schritt für Schritt die zentralen Abläufe der Domäne – verständlich, diskutierbar und überprüfbar.

In dieser Phase ist es wichtig, die Sprache ernst zu nehmen: Ein Event wie „Bestellung wurde storniert“ muss nicht nur technisch korrekt sein, sondern es muss auch inhaltlich passen. Und vor allem: Es muss für alle Beteiligten dasselbe bedeuten.

Nicht das ganze System umstellen

Ein häufiger Fehler ist, Event-getriebene Architektur gleich auf das gesamte System anwenden zu wollen. Das führt oft zu Überforderung – fachlich, organisatorisch und technisch.

Besser ist es, sich ein isoliertes Teilproblem zu suchen – einen Prozess, der in sich geschlossen ist, aber bereits von klassischen Architekturen überfordert wirkt.

Typisch sind:

• Benachrichtigungsprozesse
• Abrechnungs- oder Mahnwesen
• Genehmigungsworkflows
• Integration mit Drittsystemen

Hier lässt sich Event-getriebene Architektur gut einführen, zunächst als ergänzender Ansatz, nicht als Ersatz für das bestehende System.

Nicht die Technik überfrachten

Viele Einsteiger verlieren sich schnell in technischen Entscheidungen: Welches Event-Format soll man wählen? Welche Queue verwenden? Wie Event-Versionierung lösen?

Diese Fragen sind wichtig, aber nicht am Anfang. Wer Events als fachliche Beschreibung ernst nimmt, kann diese zunächst einfach als strukturierte Objekte behandeln – selbst ohne Event-Store oder Queue. Die technische Infrastruktur lässt sich nach und nach ergänzen.

Erst wenn klar ist, welche Events entstehen, wann sie entstehen und was sie bedeuten, lohnt es sich, über Serialisierung, Partitionierung und Replikation nachzudenken.

Was sich langfristig verändert

Wer einmal damit beginnt, in Events zu denken, verändert die eigene Sicht auf Systeme dauerhaft. Man beginnt, Abläufe nicht mehr als Abfolge von Methodenaufrufen zu sehen, sondern als Geschichte von Ereignissen. Und das hat viele positive Effekte:

• Die Kommunikation mit dem Fachbereich wird klarer.
• Die Modelle werden stabiler.
• Die Systeme werden flexibler und nachvollziehbarer.
• Neue Anforderungen lassen sich oft mit vorhandenen Events umsetzen.

Fazit und Ausblick

Event-getriebene Architektur ist kein Selbstzweck – und keine technische Mode. Sie ist eine Antwort auf Systeme, die zu unübersichtlich, zu gekoppelt und zu schwer veränderbar geworden sind. Wer Systeme baut, die sich natürlich weiterentwickeln lassen sollen, findet in Events ein kraftvolles Werkzeug.

Diese Serie hat den Bogen gespannt – von den Grenzen klassischer Architektur über die Bausteine, Denkweisen und Fallstricke bis hin zum konkreten Einstieg. Wer den nächsten Schritt gehen möchte, findet auf cqrs.com weitere Ressourcen, konkrete Beispiele und vertiefende Konzepte.

(mai)

Microsoft hat das Juli-Update seines freien Sourcecode-Editors Visual Studio Code 1.103 veröffentlicht. In dieser Version kann er bereits in Form einer öffentlichen Preview die Features von OpenAIs frisch erschienenem Sprachmodell GPT-5 nutzen. Zudem können Entwicklerinnen und Entwickler nun im Chat Checkpoints setzen, um zu einem früheren Zustand zurückzukehren.

GPT-5 jetzt als Preview in GitHub Copilot

Als fortschrittlichstes Sprachmodell von OpenAI soll GPT-5 Updates für mehrere Bereiche bringen, die für Developer relevant sind: GPT-5 soll sowohl das Reasoning als auch das Coding und den Chat verbessern.

Der GPT-5-Support läuft derzeit als Public Preview für GitHub Copilot und wird allen zahlenden Copilot-Kundinnen und -Kunden zur Verfügung gestellt – nicht nur in Visual Studio Code, sondern auch auf github.com im GitHub Copilot Chat und in der mobilen Version GitHub Mobile. Um darauf in VS Code zuzugreifen, wählen Entwicklerinnen und Entwickler GPT-5 innerhalb der Chat View im Model Picker aus.

Admins von Copilot Enterprise und Business müssen den GPT-5-Support zunächst in den Copilot-Einstellungen erlauben. Dann können User innerhalb der Organisation in VS Code das neue Sprachmodell auswählen.

Als eine weitere Neuerung im Chat lassen sich nun Checkpoints nutzen, um zu einem früheren Chat-Status zurückzukehren und Änderungen rückgängig zu machen. Wie Microsoft ausführt, soll das insbesondere beim Bearbeiten mehrerer Dateien innerhalb einer Chat-Session hilfreich sein. Auch das Wiederherstellen zu einem Checkpoint lässt sich dabei rückgängig machen.

Checkpoints sind standardmäßig aktiviert und lassen sich mit der Einstellung chat.checkpoints.enabled steuern.

Weitere Updates in diesem VS-Code-Release umfassen eine verbesserte Barrierefreiheit, das Konfigurieren des Autostart-Verhaltens für MCP-Server und die Überarbeitung des Tool Picker. Alle Details zu den Neuerungen finden sich im Ankündigungsbeitrag von Microsoft.

(mai)