OpenAI hat seiner API eine neue Geschwindigkeitsstufe gegeben. Der Ultrafast mode ist laut Dokumentation der schnellste Service-Tier der API, gedacht für latenzkritische Arbeit und ausdrücklich für Fälle, in denen die Geschwindigkeit den höheren Preis rechtfertigt. In der Dokumentation steht er unter den Production best practices im Abschnitt Performance and quality, direkt neben Fast mode, Latency optimization und Predicted Outputs.
Die Seite selbst ist knapp: Sie erklärt, wie man den Modus einschaltet, für welche Modelle er gilt und welche Grenzen gelten. Wie viel schneller er ist, beziffert sie nicht. Dieser Text fasst zusammen, was dort steht, und zeigt, wie du selbst prüfst, ob sich der Aufpreis für deine Anwendung lohnt.
Modelle, Konfiguration und WebSockets
Allgemein verfügbar ist Ultrafast für GPT-6 Astra und GPT-6.1 Sol, für GPT-5.6 Sol gibt es Vorabzugang. Für dieses Modell hatte OpenAI eine Ultrafast-Variante schon im August zusammen mit Cerebras vorgestellt. Eingeschaltet wird der Modus pro Anfrage: model auf gpt-6-astra oder gpt-6.1-sol setzen und service_tier auf ultrafast. Das funktioniert über die normale HTTP-Schnittstelle der Responses API ebenso wie über eine WebSocket-Verbindung.
OpenAI empfiehlt WebSockets ausdrücklich, vor allem für agentische Anwendungen, die in schneller Folge viele Werkzeugaufrufe machen. Ohne dauerhafte Verbindung kann der Netzwerk-Overhead einen Teil des Latenzgewinns wieder auffressen. Das Beispiel in der Dokumentation streamt zwei Antworten über dieselbe Verbindung; die zweite Anfrage schickt nur den neuen Prompt und verweist mit previous_response_id auf die erste. Dieselbe Verbindung soll auch für spätere Runden und Werkzeugergebnisse weiterverwendet werden.
Bezeichnend ist, wo das Thema steht: nicht unter den Modellfähigkeiten, sondern unter den Produktionspraktiken. Es geht nicht darum, was das Modell kann, sondern wie schnell es antwortet. Das ist der Teil, den der Nutzer am Ende spürt, ob im Sprachdialog, in einer Chat-Oberfläche oder in einem Editor.
Rate Limits, Datenresidenz und was die Seite nicht sagt
Ultrafast hat eigene Rate Limits, getrennt von Standard und Fast mode. Für GPT-6.1 Sol liegen die Voreinstellungen je nach Nutzungsstufe bei 1 Million Token pro Minute (Build), 4 Millionen (Launch) und 40 Millionen (Grow). Für GPT-6 Astra sind es 500.000, 1 Million und 5 Millionen Token pro Minute. Vor dem Hochfahren des Verkehrs empfiehlt die Dokumentation, die Limits der eigenen Organisation zu prüfen; wer mehr braucht, soll sich an sein Account-Team bei OpenAI wenden.
Unterschiede gibt es bei der Datenresidenz: Ultrafast mit GPT-6.1 Sol unterstützt Datenresidenz in den USA und der EU sowie globale Verarbeitung, Ultrafast mit GPT-6 Astra nur US-Datenresidenz und globale Verarbeitung. Wer Daten in der EU halten muss, ist damit auf Sol festgelegt. Die Preise für Eingabe, gecachte Eingabe, Cache-Schreibvorgänge und Ausgabe stehen in einer eigenen Ultrafast-Preistabelle.
Was der Modus intern anders macht, erklärt die Seite nicht. Für die eigene Planung hilft trotzdem die Unterscheidung zwischen zwei Größen: der Zeit bis zum ersten Token, im Englischen time to first token, kurz TTFT, und der Geschwindigkeit danach, gemessen in Token pro Sekunde. Wer nur die Gesamtdauer eines Requests betrachtet, mittelt beide zu einer Zahl, die wenig aussagt. Welche der beiden Größen für deine Anwendung zählt, entscheidet mit darüber, ob sich der Aufpreis lohnt.
Für welche Anwendungen sich der ultraschnelle Modus rechnet
Die Dokumentation nennt als Einsatzgebiet latenzkritische Arbeit und hebt agentische Anwendungen mit vielen Werkzeugaufrufen hervor. Gemeint sind Anwendungen, in denen eine Verzögerung von einer Sekunde wie ein Fehler wirkt.
Bei einem Sprachdialog addieren sich mehrere Latenzen: Spracherkennung, Modellaufruf, Sprachausgabe. Wenn der Modellaufruf davon den größten Posten frisst, bringt der ultraschnelle Modus am meisten. Weitere Kandidaten sind Autovervollständigung im Editor, Agenten, die Werkzeuge aufrufen und deren Ergebnis sofort weiterverarbeiten, sowie Oberflächen, die Text während der Generierung einblenden.
Für Batch-Verarbeitung, Tiefenrecherche oder Aufgaben mit langem Reasoning ist der Modus das falsche Werkzeug. Dort ist nicht die Reaktionszeit das Problem, sondern die Qualität des Ergebnisses, und die entsteht durch mehr Rechenzeit, nicht durch weniger. Der Batch-Endpunkt und der Flex-Modus passen für solche Fälle besser.
Fast mode, Predicted Outputs, Prompt Caching: wer was beschleunigt
Die Dokumentation nennt unter Performance and quality mehrere Optimierungen, die unterschiedliche Probleme lösen. Wer sie verwechselt, optimiert an der falschen Stelle und wundert sich über ausbleibende Effekte.
Prompt Caching reduziert den Aufwand für den Eingabetext. Wenn du denselben Systemprompt oder dasselbe Dokument wiederholt mitschickst, muss der vordere Teil nicht neu verarbeitet werden. Predicted Outputs zielt auf den Ausgabeteil und lohnt sich, wenn ein großer Teil der Antwort bereits bekannt ist, etwa beim Umschreiben einer Datei, in der nur wenige Zeilen wechseln. Latency optimization ist der Sammelbegriff für Architekturentscheidungen: kürzere Prompts, weniger Werkzeugschleifen, Streaming statt Warten auf die Gesamtantwort.
Fast mode und Ultrafast mode dagegen sind Service-Tiers, keine Sparmaßnahmen: Sie ändern nicht, wie viel Arbeit ein Request macht, sondern wie schnell er bedient wird, gegen Aufpreis. In der Praxis kombinierst du sie: Caching für den Kontext, den alle Requests teilen, und die schnellere Betriebsart nur für die Pfade, in denen ein Mensch tatsächlich wartet.
Messen statt raten: TTFT, Perzentile und die Kostenfrage
Ein Durchschnittswert über alle Requests verdeckt genau das, was Nutzer stört. Miss deshalb den Median und die oberen Perzentile, also p95 und p99, getrennt für jeden Endpunkt und jeden Modus. Ein p95 von zwei Sekunden bei einem Median von 300 Millisekunden bedeutet, dass sich jeder zwanzigste Aufruf träge anfühlt.
Vergleiche mit identischen Prompts, identischer Ausgabelänge und identischer Last. Sonst misst du den Unterschied zwischen zwei Eingaben, nicht den zwischen zwei Betriebsarten. Streaming verändert die Wahrnehmung: Wenn Text sofort erscheint, wirkt derselbe Request kürzer, auch wenn die Gesamtdauer gleich bleibt.
Prüfe außerdem die Randbedingungen. Ultrafast hat eigene Rate Limits, und die schnellste Betriebsart hilft nichts, wenn der Request vorher an einem Limit abprallt. Die Dokumentation lässt sich übrigens skripten: Für den vollständigen Index gibt es llms.txt, und jede Seite existiert als Markdown-Version, wenn du .md an die URL hängst. Damit baust du die Referenz in deinen Entwickler-Workflow ein, statt sie im Browser zu suchen.
Was das für deine Architektur bedeutet
Der ultraschnelle Modus ist keine Wunderwaffe, sondern ein teurerer Service-Tier. Er hebt keine grundlegenden Grenzen auf. Wenn dein Prompt 40.000 Token Kontext mitschleppt oder dein Agent fünf Werkzeugschleifen dreht, bleibt die Wartezeit hoch, egal welche Betriebsart du wählst.
Sinnvoll ist eine Aufteilung: schnelle Pfade für alles, was im Dialog oder direkt in der Eingabe passiert, und großzügigere Zeitbudgets für alles, was im Hintergrund läuft. Wer diese Trennung einmal eingezogen hat, kann beide Seiten unabhängig optimieren, statt an einer einzigen globalen Einstellung zu drehen und dabei entweder Geld zu verbrennen oder Reaktionszeit zu verschenken.
Fang mit der Messung an, nicht mit der Konfiguration. Erhebe TTFT und Durchsatz deiner wichtigsten Endpunkte, schalte dann den Modus für einen einzelnen Pfad zu und vergleiche dieselben Werte erneut. Was sich nicht messbar verbessert, gehört nicht in die Produktion – egal wie überzeugend der Name klingt.
Quelle: developers.openai.com
