Wie GPT‑5.6 Frontier-Intelligenz mit Frontier-Effizienz vereint
Wir haben die GPT‑5.6‑Modellfamilie so entwickelt, dass sie Leistungsfähigkeit und Kosten über das gesamte Spektrum der Aufgaben hinweg ausbalanciert, für die Menschen unsere Modelle einsetzen. Unser Flagship-Modell GPT‑5.6 Sol übertrifft mit Reasoning auf Max Claude Fable ww5 im Artificial Analysis Coding Agent Index und kostet dabei weniger als die Hälfte. Terra erreicht in Intelligenz-Benchmarks die Leistung von GPT‑5.5 zum halben Preis. Luna ist unser schnellstes und günstigstes Modell und kostet 80 % weniger als Sol. Um diese Effizienz zu erreichen, haben unsere Forschungs- und Technikteams alle wichtigen Ebenen unseres Stacks umfassend optimiert. Diese Verbesserungen betreffen unsere Modelle, die Inferenz, also die Ausführung von Modellen zur Erzeugung von Ausgaben, und unseren agentischen Harness, den sowohl Codex als auch ChatGPT Work nutzen.
In den vergangenen vier Jahren haben wir unsere Modelle auf 1 Milliarde aktive Nutzende und mehr als 2 Millionen Unternehmen skaliert. Effizienz war dabei entscheidend, damit die Vorteile von Intelligenz allen zugutekommen. Unsere Mission ist es, dafür zu sorgen, dass künstliche allgemeine Intelligenz der gesamten Menschheit zugutekommt. In dieser Zeit haben wir unseren gesamten Stack kontinuierlich optimiert, um an jedem Punkt der Kosten-Intelligenz-Kurve die leistungsfähigsten Modelle anbieten zu können. Mit GPT‑5.6 haben wir unsere bisher höchste Intelligenz-pro-Token-Effizienz erreicht. Das Modell ist darauf trainiert, mehr Arbeit pro Token zu erledigen. Beim Training optimieren wir sowohl den Aufgabenerfolg als auch die Effizienz und bringen dem Modell bei, Aufgaben auf direkterem Weg zu lösen.
Dieser Artikel blickt über unsere Modelle hinaus und zeigt, wie Fortschritte in zwei weiteren wichtigen Bereichen des Stacks die Effizienz steigern: 1) bei der Inferenz, indem wir Prozesse wie Lastenausgleich, spekulatives Decoding, Caching und Kernel-Optimierung verbessern, um mit derselben Hardware mehr Ausgabe zu erzeugen, und 2) bei unserem agentischen Harness, unter anderem durch einen besseren Umgang mit übermäßigem Kontext, Tool-Nutzung und wiederholter Arbeit. Außerdem zeigen wir, wie GPT‑5.6 Sol mehrere dieser Verbesserungen autonom umgesetzt hat. Einzelne Verbesserungen mögen begrenzt erscheinen. Zusammengenommen ermöglichen sie uns jedoch Spitzenleistungen bei Intelligenz und Effizienz.
In einer Welt mit begrenzter Rechenleistung, in der die Nachfrage nach Modellen schneller wächst als die Kapazität, ist Effizienz für jedes Systemdesign entscheidend. Das gilt besonders für unseren Inferenz-Stack, der trainierte Modelle ausführt, um Antworten zu erzeugen. Unser wichtigstes Ziel ist, mit derselben Hardware mehr Token zu verarbeiten und dabei die erwartete Intelligenz, Latenz, Verfügbarkeit und Zuverlässigkeit zu wahren.
Dafür muss das gesamte System optimiert werden. Ein Modell kann für sich betrachtet sehr effizient sein und im Betrieb dennoch hohe Kosten verursachen, wenn Anfragen ungünstig verteilt werden, Hardware ungenutzt bleibt oder Datenbewegungen die Berechnung verlangsamen. Verbesserungen auf jeder Ebene verstärken sich gegenseitig. Gewinne entstehen durch optimiertes Routing (wohin Anfragen gesendet werden), Scheduling (wann Anfragen verarbeitet werden), Kernel (Software, die auf GPUs läuft), Caching (gespeicherte und wiederverwendete Arbeit) und die Modellimplementierung (Reihenfolge des GPU-Codes). GPT‑5.6 Sol in Codex spielte bei all diesen Optimierungen eine entscheidende Rolle.
Ein erstes wichtiges Beispiel ist der Lastenausgleich. Weltweit leiten wir Anfragen anhand von Faktoren wie Standort, verfügbarer Kapazität und Beschleunigertyp weiter, also der Art von GPU oder Spezialchip, auf der das Modell läuft. Innerhalb eines Clusters verteilen wir die Arbeit anhand von Auslastung, Kontextlänge, Cache-Verfügbarkeit und weiteren Anfrageeigenschaften auf Modellinstanzen. Innerhalb jeder Instanz muss die Arbeit anschließend effizient auf Beschleuniger, Teilnetze des Modells und Rechenkerne verteilt werden. GPT‑5.6 Sol in Codex hilft uns, Produktionsdatenverkehr zu analysieren, zuvor übersehene Ursachen von Ungleichgewichten zu erkennen, neue Routing-Strategien zu testen und diese Heuristiken laufend abzustimmen. Allein diese Verbesserungen beim Lastenausgleich haben die Betriebskosten unserer Modelle deutlich gesenkt.
Wir haben GPT‑5.6 Sol außerdem genutzt, um den Vorwärtsdurchlauf des Modells zu optimieren, also die Berechnung, die Eingaben in Vorhersagen für das nächste Token umwandelt. Selbst wenn einzelne Operationen schnell sind, können unnötige Speicherbewegungen, Synchronisierung und ineffiziente Datenlayouts dazu führen, dass GPUs ungenutzt bleiben. Um das zu vermeiden, identifizierte GPT‑5.6 Sol Arbeitsschritte, die sich vorab berechnen, vermeiden oder parallelisieren ließen. Mit Codex schrieb und optimierte GPT‑5.6 Sol unsere Produktions-Kernel autonom neu. Dieser Kerncode führt die mathematischen Operationen aus, aus denen das Modell besteht. Das gelang unter anderem, weil wir GPT‑5.6 darauf trainiert haben, Kernel in Triton(wird in einem neuen Fenster geöffnet) und Gluon(wird in einem neuen Fenster geöffnet) effektiv zu schreiben und zu verbessern. Beide sind von OpenAI betreute Open-Source-Programmiersprachen für GPUs. Zusammen mit weiteren Kernel-Verbesserungen durch GPT‑5.6 Sol senkten diese Maßnahmen die durchgängigen Betriebskosten um 20 %. Wir haben außerdem umfassend in Prüfwerkzeuge investiert, darunter das Open-Source-Tool FpSan(wird in einem neuen Fenster geöffnet) (Floating-Point Sanitizer). Damit lässt sich die Korrektheit der von GPT‑5.6 Sol geschriebenen Kernel validieren.
Spekulatives Decoding ist ein weiterer Ansatz, um Geschwindigkeit und Effizienz zu verbessern. Dabei läuft neben dem primären Modell ein kleineres Entwurfsmodell, auch „Speculator“ genannt. Es schlägt mehrere Token vor, die das primäre Modell parallel prüft. Werden diese Vorschläge akzeptiert, kann das System mit einem einzigen Durchlauf des primären Modells mehrere Ausgabe-Token erzeugen. Das reduziert die aufwendigen sequenziellen Berechnungen. GPT‑5.6 Sol verbesserte sein eigenes Entwurfsmodell, indem es Hunderte Experimente zu dessen Architektur entwickelte und ausführte sowie Änderungen an Größe, Struktur und Funktionen testete. Darüber hinaus startete und überwachte GPT‑5.6 Sol das Training des Speculators und griff bei Problemen wie Hardwareausfällen und instabilem Training autonom ein. Die daraus entstandenen Verbesserungen steigerten die Effizienz der Token-Erzeugung um mehr als 15 %.
Bei der Verarbeitung nicht zwischengespeicherter Eingabe-Token erstellt das Modell den Key-Value-Cache (KV-Cache) in einem rechenintensiven Durchlauf. Bei der Ausgabeerzeugung liest es wiederholt daraus und erweitert ihn. Die optimale Betriebskonfiguration, etwa für Batching, Sharding und KV-Verwaltung, hängt stark von der Arbeitslast ab: von Prompt- und Ausgabelänge, Batch-Größe, Cache-Trefferquote, Anfrageeigenschaften und weiteren Faktoren. Der Konfigurationsraum war bisher jedoch zu groß für eine systematische Abstimmung. Daher mussten sich technische Fachkräfte auf allgemeine Heuristiken verlassen. Mit GPT‑5.6 Sol in Codex konnten wir Produktionslasten analysieren, mögliche Konfigurationen erzeugen und bewerten sowie die Konfiguration von Engine und Modell für jedes Szenario gezielt optimieren. Damit wird eine neue Stufe der arbeitslastspezifischen Optimierung praktikabel, sodass dieselbe Hardware mehr nutzbare Inferenzleistung liefert.
Die Inferenzoptimierung ist ein kontinuierlicher Feedbackkreislauf. Wir messen das Verhalten in der Produktion, ermitteln die größten Lücken, setzen Änderungen um und prüfen, ob sie das gesamte System verbessern statt nur einen isolierten Benchmark. GPT‑5.6 Sol und Codex beschleunigen jeden Teil dieses Kreislaufs. So kann unser Team mehr Ideen untersuchen, schneller auf veränderte Arbeitslasten reagieren und einen Inferenz-Stack entwickeln, der Nutzenden geringere Latenzen, mehr Kapazität und niedrigere Kosten bietet.
ChatGPT Work und Codex erledigen komplexe Aufgaben durch eine Abfolge von Modellanfragen und Tool-Aufrufen. In einer einzigen Interaktion, von der Anfrage bis zur endgültigen Antwort, kann Codex Quellcode prüfen, den Bereitstellungsverlauf durchsuchen, Störungsberichte lesen, eine Datei bearbeiten und Tests ausführen. Jeder Schritt kann eine eigene Anfrage erfordern.
Kontext aufzubereiten, Daten zu übertragen, Inferenzen auszuführen, Tools aufzurufen und Prozesse zu starten, kostet Zeit und Rechenleistung. Wenn eine Aufgabe 30 Modellanfragen erfordert, summiert sich eine zusätzliche Sekunde pro Anfrage. Für eine bessere Gesamtleistung muss wiederholte Arbeit im gesamten System reduziert werden. Es reicht nicht, nur das Modell zu beschleunigen.
Eine einzelne Nutzereingabe kann viele Modell- und Tool-Iterationen umfassen. Kosten innerhalb des wiederholten Bereichs können daher mehrfach anfallen.
Diese Multiplikatoreffekte haben die Entwicklung unseres agentischen Harness geprägt, einer Orchestrierungsebene in Rust, die unsere Modelle und Tools mit der Umgebung der Nutzenden verbindet. Im Folgenden zeigen wir, wie sich jede Anfrage effizienter verarbeiten lässt, indem wir übermäßigen Kontext vermeiden, Tools bedarfsgerecht laden und Arbeit wiederverwenden.
Wenn Agenten Zugriff auf mehr Tools, Fähigkeiten, Plug-ins und Gesprächsverläufe erhalten, können Kontextfenster schnell wachsen. Das erhöht die Kosten, lenkt das Modell ab und führt zu unnötigem Reasoning. Der Harness kann diesen Aufwand durch verzögerte Erkennung reduzieren. Integrationen, benutzerdefinierte MCP-Tools, Fähigkeiten und Plug-ins werden dadurch erst bei Bedarf auffindbar. Der Harness verhindert außerdem, dass einzelne Tools und MCP-Integrationen unerwartet das Kontextfenster belegen. Die Tool-Ausgabe ist standardmäßig auf 10.000 Token begrenzt, sofern das Modell kein anderes Limit anfordert.
Wie bereits erwähnt, kann eine Agenten-Schleife innerhalb einer einzigen Interaktion dieselben Anweisungen, den Gesprächsverlauf, Tool-Definitionen und frühere Ergebnisse mehrfach an die GPUs senden. Die Verarbeitung dieser wiederholten Eingaben ist aufwendig. Deshalb verwendet Prompt-Caching die Berechnung eines zuvor verarbeiteten Prompt-Präfixes erneut. Damit dieses Präfix erhalten bleibt, behandelt der Harness den gesamten für das Modell sichtbaren Verlauf als unveränderlich: Neue Nachrichten, Tool-Ergebnisse und Aktualisierungen der Umgebung werden am Ende angefügt, statt in einen früheren Kontext eingefügt zu werden. Tools werden außerdem in einer deterministischen Reihenfolge bereitgestellt. Laufzeiteinstellungen wie Genehmigungsrichtlinien werden während der Ausführung angewendet, statt in Tool-Definitionen eingebettet zu sein. Diese Designentscheidung trägt zu den insgesamt hohen Trefferquoten des Prompt-Caches bei Codex und ChatGPT Work bei.
Inkrementelle Übertragung verändert, was über das Netzwerk gesendet wird. Prompt-Caching verändert, welche Berechnungen das Modell möglicherweise nicht wiederholen muss. Die Breiten sind schematisch; die zusätzliche Komprimierungsebene ist nicht dargestellt.
Die mit GPT‑5.6 erzielten Effizienzgewinne beruhen auf jahrelangen, aufeinander aufbauenden Verbesserungen im gesamten Stack, von Forschung und Inferenz bis zu unserem agentischen Harness. Die Rolle von GPT‑5.6 bei vielen dieser Verbesserungen stimmt uns zuversichtlich, dass sich Optimierungen künftig noch schneller umsetzen lassen. Wir werden Bereiche wie die Kernel-Optimierung weiter voranbringen und zugleich grundlegende Verbesserungen an unserem Stack vornehmen. Diese fortlaufenden Verbesserungen im Hintergrund sollen unseren Nutzenden und Kund:innen zugutekommen: durch besser verfügbare, kosteneffiziente Intelligenz.
Besonderer Dank gilt Matthew Ferrari, Philippe Tillet, Ahmed Ibrahim, Joe Gershenson und Steve Coffey, Members of Technical Staff, für ihre Beiträge zu diesem Artikel.


