StartseiteArtikel

Offizielle Bekanntgabe: OpenAI stellt das schnellste Modell in seiner gesamten Geschichte außer Betrieb.

新智元2026-09-13 10:54
Geschwindigkeit ist nicht mehr ein „exklusives Modell“, sondern eine „kostenpflichtige Tarifstufe“

Das schnellste Modell in der Geschichte von OpenAI ist tot.

Tibo, Leiter von Codex, hat einen Beitrag veröffentlicht: GPT-5.3-Codex-Spark wird nächste Woche eingestellt.

Mit einer Geschwindigkeit von 1200 Token pro Sekunde, als erstes OpenAI-Modell, das nicht auf Nvidias Technologie-Stack läuft, und als erste Lieferung des großen 750-Megawatt-Auftrags von Cerebras, hat es von der Veröffentlichung bis zur Einstellung nur 7 Monate überlebt.

Der Grund, den Tibo angibt, ist einfach: Die Nutzung ist stetig gesunken, und es gibt bereits deutlich bessere Modelle. „Es ist Zeit, Platz für die Zukunft zu schaffen.“

Dann fügte er noch hinzu: „Ich kann kaum glauben, dass wir jemals ein Modell mit so einem langen Namen veröffentlicht haben!!“

Auf der Abschiedsfeier interessiert sich jeder nur für das „Reservekontingent“

Spark ist sehr leise gegangen, es wirkt sogar etwas peinlich.

Vaibhav Srivastav von Hugging Face versuchte, ein wenig Wärme in den Kommentarbereich zu bringen.

Danke für deinen Dienst, du warst besonders. Sei stolz darauf, dass du der erste „schnellste Junge“ warst. Bevor du nächste Woche eingestellt wirst, gib doch mal einen Prompt ein, um zu spüren, wie weit wir seitdem gekommen sind.

Der unmittelbar folgende beliebte Kommentar schlug sofort einen scharfen Ton an.

Also wofür ist es eigentlich gut? Vor ein paar Tagen habe ich noch mit Kollegen über diese Frage diskutiert.

OpenAI will Codex-Spark einstellen, dann werden die verbliebenen 67 starken Nutzer traurig sein.

Eine noch vernichtendere Bewertung stammt von dem Entwickler argofowl: „Spark war ein lustiges Modell, aber auch ein extrem schlechtes, völlig unbrauchbares Modell. Ich bin froh, dass es weg ist, ich habe es seit Monaten nicht mehr angefasst.“

Ein weiterer Entwickler gab an, dass er in mehreren Projekten von beträchtlicher Größe Spark kaum genutzt hat. Selbst grundlegende Aufgaben wie das Verstehen des Projektkontexts oder das Analysieren von Protokollen füllten das Kontextfenster sofort vollständig, sodass er gezwungen war, eine neue Unterhaltung zu öffnen.

Tatsächlich bedauern diejenigen, die den Ruhestand von Spark ein wenig bedauern, nicht das Modell selbst, sondern das damit verbundene unabhängige Kontingent.

Der bekannte Entwickler Chubby gab offen zu, dass er sich ein „GPT-6-Spark“ wünscht, da Spark über ein unabhängiges Paket verfügt, das das Hauptkontingent nicht verbraucht.

In der heutigen Zeit, in der das Astra-Kontingent extrem knapp ist, nutzen viele Entwickler Spark als „Reservetank“, um eine Weile auszukommen, nachdem das Hauptkontingent aufgebraucht ist.

Die „Zukunft“ vor 7 Monaten unterlag der „Leistungsreduzierung zur Geschwindigkeitssteigerung“

Gehen wir zurück zum 12. Februar dieses Jahres: Als Spark online ging, war die Veranstaltung sehr groß angelegt.

Es war das erste von OpenAI speziell für die Echtzeit-Programmierung entwickelte Modell mit einem Kontext von 128k und einer Generierungsgeschwindigkeit von über 1000 Token pro Sekunde.

Laut den offiziellen Angaben sank der Roundtrip-Overhead zwischen Client und Server um 80 %, der Verarbeitungsaufwand pro Token um 30 % und die Latenz des ersten Tokens wurde halbiert.

Der Code erschien nicht mehr Zeile für Zeile, sondern strömte in ganzen Blöcken auf den Bildschirm.

Die ersten Entwickler, die es ausprobiert haben, waren wirklich aufgeregt.

Der Entwickler Ryan Vogel hat es direkt in seinen offiziellen Arbeitsablauf integriert: GPT-5.4 ist für die Planung zuständig, GPT-5.3-Codex für die Erstellung, und Spark für die Erkundung des Code-Repositorys, das Nachschlagen von Dokumenten und das Geben einer zweiten Meinung.

Er sagte, dies sei das erste Mal, dass in seinem Arbeitsablauf kein einziges Claude-Modell enthalten sei: „Effizienter, weniger Kosten.“

Jason Liu, Autor von Instructor, startete direkt 20 Spark-Subagenten, um das Dateisystem zu durchsuchen, und erklärte „RAG ist tot“.

Dann trat er kurz darauf dem Codex-Team von OpenAI bei.

Noch wichtiger ist, dass Spark den Ehrgeiz von OpenAI trug, die Abhängigkeit von einer einzigen Hardware aufzugeben.

Es war das erste Produktionsmodell von OpenAI, das außerhalb von Nvidias Technologie-Stack lief. Die zugrundeliegende Rechenleistung stammte vom wafergroßen Chip WSE-3 des Startups Cerebras.

Es markierte, dass OpenAI den ersten Erfolg für den großen 750-Megawatt-Vertrag mit einem Gesamtwert von über 20 Milliarden US-Dollar an Rechenleistung mit Cerebras vorgelegt hat.

Aber die Begeisterung ließ schneller nach, als sie gestiegen war.

Der tödliche Fehler von Spark liegt darin: Ein einzelner Wafer kann kein Flaggschiff-Modell aufnehmen. Im Wesentlichen ist es ein „destilliertes kleines Modell“, das für extreme Geschwindigkeit Kompromisse eingeht.

Im Terminal-Bench 2.0-Test erreichte Spark nur eine Genauigkeit von 58,4 %, weit unter den 77,3 % der vollständigen Version von GPT-5.3-Codex.

Die von OpenAI selbst veröffentlichte SWE-Bench Pro-Kurve zeigt auch: Obwohl Spark die Aufgabenlaufzeit auf 1 bis 2 Minuten drücken kann, bleibt die Genauigkeit zwischen 47 % und 51 %.

Im Vergleich dazu erreicht die vollständige Version von GPT-5.3-Codex bereits ab 3 Minuten 51 %, nach 9 Minuten 56 % und nach 16 Minuten 57 %.

Das heißt, die wenigen Minuten, die Spark einspart, führen zu einem Rückgang der Genauigkeit um fünf bis sechs Prozentpunkte.

Die angepriesene „15-fache Geschwindigkeitssteigerung“ wurde auch entlarvt.

Am zweiten Tag nach der Veröffentlichung veröffentlichte der Entwickler Nicholas Van Landschoot einen langen Artikel auf X, in dem er die Vergleichsbedingungen von OpenAI aufdeckte: Die sogenannte 15-fache Geschwindigkeit ergab sich, als man Spark mit GPT-5.3-Codex verglich, das mit höchster Inferenzintensität betrieben wurde.

Bei gleicher Genauigkeit war Spark tatsächlich nur 1,37-mal schneller.

In praktischen Codierungsszenarien wurden seine Mängel unbegrenzt verstärkt: Es erfindet willkürlich API-Endpunkte, das JSON-Format ist instabil, und mehrstufige Aufgaben laufen sehr leicht fehl.

Die Bildungseinrichtung Turing College fasste es pointiert zusammen: „Geschwindigkeit ohne Intelligenz bedeutet nur, schneller zu scheitern.“

Für Programmierer ist es immer lohnender, 17 Minuten auf einen lauffähigen Code zu warten, als 2 Minuten ein fehlerhaftes Stück Müll zu erhalten.

Daher war dieses auf Geschwindigkeit ausgelegte Modell dazu bestimmt, an den Rand gedrängt zu werden.

Das Flaggschiff-Modell selbst kommt auf die Bühne: Der Ultrafast-Modus beendet Spark

Was Spark tatsächlich zum Tode verurteilte, war der Ultrafast-Modus, der am 13. August von Cerebras veröffentlicht wurde.

Dieses Mal läuft auf dem Wafer nicht mehr die abgespeckte Version von Spark, sondern das Flaggschiff-Modell GPT-5.6 Sol selbst.

Indem das riesige Flaggschiff-Modell schichtweise aufgeteilt und auf mehreren CS-3-Knoten als Pipeline verteilt wird, erreicht der Ultrafast-Modus eine erschreckende Geschwindigkeit von 750 Token pro Sekunde, während er die „gleiche Intelligenz wie die Standardversion“ beibehält.

Laut dem Vergleich von Cerebras ist Ultrafast 14-mal schneller als die Standardstufe, und es gibt eine mittlere Stufe namens Priority, die nur 2,5-mal schneller ist.

Andrew Feldman, CEO von Cerebras, bewertete dies mit nachdrücklichen Worten: „Geschwindigkeit und Intelligenz schließen sich nicht mehr gegenseitig aus.“

Sie haben einen Zeitvergleich für 6 qualitätsausgerichtete Aufgaben in GDP-Val durchgeführt.

Die Standardstufe von Sol benötigt durchschnittlich 7,7 Minuten, davon entfallen 7,5 Minuten auf die Modellgenerierung. Mit Ultrafast dauern dieselben Aufgaben insgesamt 83 Sekunden, die Modellgenerierung 68 Sekunden, und die verbleibenden 15 Sekunden sind nicht-inferenzbezogene Overheads wie Tool-Aufrufe.

Das heißt, es ist Ende-zu-Ende ganze 5,6-mal schneller, und die Qualität der Antworten ist fast identisch.

Diese Erklärung verkündet nicht nur einen technischen Durchbruch, sondern raubt Spark auch direkt den gesamten Daseinszweck.

Der ursprüngliche Designzweck von Spark war „Intelligenz gegen Geschwindigkeit eintauschen