OpenAI Ultrafast: Die Unfalluntersuchung verlangsamt sich von Stunden zu Minuten

Was passiert

Am 26. Oktober gab OpenAI auf seiner offiziellen Blogseite Einblicke in die tatsächliche Anwendung von Codex Ultrafast im internen Sicherheitsteam. Bislang erforderte die Untersuchung eines Sicherheitsvorfalls normalerweise, dass Ingenieure Daten aus verschiedenen Quellen wie strukturierten Protokollen, unstrukturiertem Text und Slack-Chats extrahieren, diese dann bearbeiten, normalisieren und den Kontext ergänzen. Dieser Prozess dauerte 1 bis 2 Stunden. Mit Codex Ultrafast kann dieser Schritt auf 10 bis 15 Minuten verkürzt werden, in einigen Fällen sogar nahezu real time, und gleichzeitig können mehrere potenzielle Ursachen untersucht werden.

OpenAI beschreibt die Nutzung wie folgt: Die Reaktionszeit des Modells ist unter 30 Sekunden, was die Kontextwechsel- und -verluste der Ingenieure während der Untersuchung verringert. Die Datenquellen beschränken sich nicht nur auf traditionelle Protokolle, sondern umfassen auch Slack-Aussagen, historische ähnliche Symptome und andere internen Informationen. Derzeit ist Codex Ultrafast zur Standardwerkzeugung für OpenAI-Ingenieure bei Sicherheitsvorfällen geworden und wird auch für Code-Refactoring und den täglichen Arbeitsablauf verwendet.

Angesichts des Zeitpunkts der Veröffentlichung handelt es sich dabei um einen Blogartikel in einer Phase, in der die AI-Assisted-Operation und Wartung weit verbreitet diskutiert werden. OpenAI wählte das Beispiel der internen Effizienzsteigerung, um sowohl nach Anwendungsfällen für Codex Ultrafast zu suchen als auch ein Signal an die Öffentlichkeit zu senden: Schnelle Modelle eignen sich nicht nur zur Code-Aufrüstung, sondern können auch in Prozesse wie Sicherheitsuntersuchungen eingesetzt werden, bei denen eine hohe Synchronität erforderlich ist. Es ist bemerkenswert, dass OpenAI selbst sowohl Entwickler als auch starke Nutzer ist und die internen Vorteile nicht direkt auf normale Kunden übertragen werden können. Mit anderen Worten, der Blogartikel beschreibt die Effekte „OpenAI mit OpenAI“, und nicht die Effekte, die jede normale Firma unter normalen Bedingungen nachahmen könnte.

Hauptkritik/Audit

Der zentrale Ansatz von OpenAI ist die „Speed Revolution“, aber dieser Bericht enthält einige Punkte, die überprüft werden sollten.

Erstens: Hat der sechsfache Preis sechsfache Wert gebracht?

Laut den Notizen von Lilith AI beträgt die API-Kosten von Codex Ultrafast das Sechsfache der Standard-GPT-6.1 Sol. Wenn 1 bis 2 Stunden Ingenieurzeit eingespart werden können, ist der sechsfache Preis kommerziell rentabel, abhängig von drei impliziten Bedingungen: Ist die Häufigkeit von Vorfällen hoch genug, ist der Anteil an manueller Erfassung groß genug und ist die Tiefe der Untersuchung nicht deutlich eingeschränkt. Der offizielle Blogartikel gibt nur eine Zeitverkürzung an, ohne Angaben zur Kosteneinsparung oder zu einer quantitativen Vergleich der Genauigkeit zu machen. Es ähnelt eher einem internen Beispiel, bei dem die Arbeitskosten auf den Schlussverdacht übertragen werden. Für kleine und mittlere Unternehmen, deren Vorfälle nur wenige pro Monat sind, könnte die Verwendung von Codex Ultrafast lediglich dazu führen, dass die API-Rechnung besser aussieht, ohne die Sicherheit des Geschäfts zu erhöhen.

Zweitens: Die verschwommene Zone zwischen „real time“ und „near real time“.

Der Blogartikel erwähnt „manchmal nahezu real time“, gibt aber keine Angaben zu den Auslösern. Welche Arten von Anfragen in den Bereich near real time gelangen, welche auf Minutenbasis zurückfallen und wie bei Fehlern oder Falschalarmen reagiert werden soll, diese wichtigen Informationen sind nicht offengelegt. Ob 10 bis 15 Minuten der Durchschnitt, die Median oder das optimalste Ergebnis sind, lässt sich nicht beurteilen. Wenn diese Zahl aus den besten Szenarien stammt, könnte das Verhalten in der tatsächlichen Produktionsumgebung stark beeinträchtigt werden.

Drittens: Probleme mit Berechtigungen und Audits durch die Erweiterung der Datenquellen.

Ultrafast nutzt nicht nur Log-Dateien, sondern liest auch die in Slack erwähnten und ähnlichen Symptome. Das bedeutet, dass das Modell auf umfangreichere interne Kommunikation und historische Ereignisse zugreifen muss. Berechtigungsgrenzen, Zugriffsprotokolle, Datenschutzüberprüfungen sowie die Erklärbarkeit der Modellausgaben sind komplexer als bei bloßer Log-Abfrage. OpenAI hat nicht erklärt, wie das Modell bei Transsource-Abfragen scheinbar logische, aber falsche Zusammenhänge vermeiden kann, und auch nicht angegeben, wie wichtig die manuelle Überprüfung im gesamten Prozess ist.

Viertens: Man sollte „Standardwerkzeug“ und „Alltagsassistent“ nicht verwechseln.

Der offizielle Blog beschreibt Ultrafast gleichzeitig als Standardwerkzeug für Notfallreaktionen und als allgemeiner Assistent für Rekonstruktionen und tägliche Arbeitsabläufe. Diese beiden Szenarien haben unterschiedliche Toleranzen gegenüber Latenzzeiten, Kosten und Genauigkeit. Wenn dasselbe Produkt gleichzeitig als zwei verschiedene Funktionen präsentiert wird, kann es dazu führen, dass die Leser denken, dass der Hochgeschwindigkeitsmodus in allen Szenarien sinnvoll ist.

Fünftens: Risiko der Marketingisierung interner Beispiele.

Wenn Unternehmen interne Beispiele veröffentlichen, geben sie normalerweise nur die vorteilhaftesten Daten preis. OpenAI hat diesmal keinen Kontrollgruppen-Test angegeben, keine Misserfolge bekanntgegeben und auch nicht erklärt, welche Aspekte weiterhin manuell überwacht werden müssen. Diese selektive Offenbarung könnte es externen Lesern ermöglichen, die Reifegrad von Ultrafast zu überschätzen.

Die offizielle Darstellung stimmt nicht

Der Blog beschreibt Ultrafast gleichzeitig als zwei Funktionen: Als „Standardwerkzeug“ für Notfallreaktionen bei OpenAI-Ingenieuren und als allgemeiner Assistent für Rekonstruktionen und tägliche Arbeitsabläufe. Die Ressourcenverbrauchsmodelle beider sind nicht identisch. Wenn „Standard“ bedeutet, dass große Mengen an Anfragen abgegeben werden, ist fraglich, ob ein sechsfacher Kostenaufwand durchgehend möglich ist; wenn es nur für kleine, spezielle Notfälle geht, dann hat der Begriff „Standard“ einen deutlichen Marketingcharakter.

Ein noch wichtigeres Problem ist, dass die offizielle Seite sowohl betont, dass eine 30-Sekunden-Reaktionszeit Kontextwechsel reduziert, als auch Ultrafast für Aufgaben wie Rekonstruktionen, die keine hohen Zeitanforderungen haben, propagiert. Der Hochgeschwindigkeits-, Hohe-Kosten- und Spezialisierte-Analyse-Modus wird als alltägliches Werkzeug verpackt, wodurch die Grenzen zwischen Leistung, Kosten und Anwendungsbereichen verschwimmen. Leser können leicht durch die Wörter „Standard“ und „Alltag“ täuscht werden und denken, dass es sich um ein universell nutzbares Beschleunigungsprogramm handelt, ohne das hohe Kostenaufwand zu berücksichtigen.

Was normale Nutzer tun können

Für normale Entwickler und kleine Unternehmen, die keine internen Berechtigungen bei OpenAI haben, ist es nicht möglich, Ultrafast direkt nachzubilden. Doch man kann ihre Ideen übernehmen:

1. Integrieren Sie Protokolle, Warnungen, Schlüsselwörter aus Instant Messaging und vergleichbare Vorfälle in denselben Suchprozess, um die Kosten für den manuellen Wechsel zwischen verschiedenen Systemen zu reduzieren.
2. Teilen Sie die Unfalluntersuchung in drei Schritte auf: „Datenaufbereitung – Zusammenfassung und Analyse – Ausgabe von Schlussfolgerungen“. Verwenden Sie dazu bestehende Modelle, um diese Schritte schrittweise abzuleisten, anstatt alle Kontexte in ein einzelnes Großmodell zu packen.
3. Setzen Sie Ihre eigenen Kostennormen fest und bewerten Sie regelmäßig, ob eine „bessere Reaktionsgeschwindigkeit“ den aktuellen API-Ausgaben wert ist, um von Geschwindigkeitspropaganda abzulenken.
4. Wenn Sie LLMs zur Unterstützung der Betriebsführung verwenden, behalten Sie eine vollständige manuelle Überprüfung und Protokollierungsmechanismus bei, um zu verhindern, dass Modelleffekte fälschlicherweise als Ursache angesehen werden.

Schlussfolgerung

Das Unfallbeispiel von Ultrafast innerhalb von OpenAI zeigt das Potenzial von schnellen Modellen für Betriebssicherheit. Es zeigt jedoch auch die Preisprobleme hinter der Effizienzpropaganda. Da OpenAI sowohl Entwickler als auch tiefe Nutzer ist, können seine internen Vorteile nicht unbedingt auf normale Kunden übertragen werden. Vor einem Sechsfachen der Kosten hängt es letztendlich davon ab, was „besser“ ist – nämlich die konkreten Rechnungen und Unfallschäden. Für die meisten normalen Teams ist vielleicht nicht die sechsfache Rechengeschwindigkeit wichtig, sondern klarere Protokollierungsstandards, ein verbessertes Warnsystem und strengere manuelle Überprüfungsprozesse. Zumindest für jetzt scheint dies eher eine interne Präsentation eines teuren neuen Produkts zu sein, als die endgültige Lösung für alle Fälle.

Referenzquellen

• OpenAI Official Blog, 2026-10-26
• Lilith AI Note: Die Kosten des Ultrafast API sind sechs Mal höher als die des Standard-GPT-6.1 Sol