GPT-6 Sol Latenz: 102 Sekunden bis zum ersten Token

Sie haben gpt-6-astra gegen gpt-6-sol getauscht, weil der Token-Preis von 10 $ und 50 $ pro Million auf 2 $ und 10 $ gesunken ist. Die Rechnung sieht super aus. Dann überschreitet Ihre p95-Antwortzeit zwei Minuten, Ihr Load Balancer liefert Gateway-Timeouts zurück und der Support wird mit Anfragen überschwemmt, warum die Seite hängt.

Nichts ist kaputt. Sie haben die Form der Arbeitslast geändert, nicht nur ihren Preis.

Artificial Analysis misst GPT-6 Sol mit 115,2 Ausgabe-Tokens pro Sekunde und einer Zeit bis zum ersten Token von 102,15 Sekunden. GPT-6 Luna misst 153,9 Ausgabe-Tokens pro Sekunde mit 124,23 Sekunden bis zum ersten Token. Diese beiden Zahlen sind mit erheblichen Vorbehalten verbunden, was die erste Hälfte dieses Artikels ausmacht. Die zweite Hälfte befasst sich damit, was man dagegen tun kann: wie man die Latenz bis zum ersten Token auf der eigenen Arbeitslast ehrlich misst und welche vier Designänderungen verhindern, dass ein 100-Sekunden-Modell Ihre API mit in den Abgrund zieht.

Für den breiteren Kontext von drei bahnbrechenden Starts innerhalb von zwei Tagen, siehe den Modell-Preiskrieg vom September 2026.

Die Zahl und alles, was beim Zitieren falsch gemacht wird

Lesen Sie die Spalte "Vorbehalt" vor der Spalte "Zahlen".

Drei Dinge, die Ihnen diese Spalte sagt.

Dies sind Zahlen von Artificial Analysis, nicht von OpenAI. OpenAI veröffentlichte bei der Einführung Preis, Kontext, Verfügbarkeit und eine Reihe von Benchmark-Ergebnissen. Es wurde keine Latenzzahl in dem von uns gelesenen Material veröffentlicht. Die 102,15 Sekunden stammen also von einem Drittanbieter, der sein eigenes Testsystem in seinem eigenen Netzwerk betreibt, und Sie sollten sie eher als richtungsweisend denn als Spezifikation behandeln. Vermerken Sie es in Ihren eigenen Unterlagen so, wie wir es hier vermerken.

Sie beschreiben die „max“ Reasoning-Variante. Auf den Benchmark-Tabellen beider Anbieter erscheinen zur Einführung Leistungsstufen-Bezeichnungen: low, medium, high, xhigh, max. Max ist die höchste Stufe dieser Skala, und der Reasoning-Aufwand ist der größte Hebel für die Latenz des ersten Tokens. Eine Messung der langsamsten Konfiguration ist keine Messung der Konfiguration, die Sie in der Produktion einsetzen werden.

Es handelt sich um Messungen eines Endpunkts eines Anbieters zu einem bestimmten Zeitpunkt. Bereitstellungskapazität, Routing und Warteschlangentiefe ändern sich. Eine Startwoche-Zahl, die während eines Verkehrsspitzen aufgenommen wurde, ist ein Worst Case, der sich als Konstante tarnt.

Was alle drei Vorbehalte überdauert, ist die Richtung, und diese Richtung ist der Kernpunkt dieses Artikels. Das günstige Modell ist nicht das schnelle Modell. Sol kostet ein Fünftel von Astra pro Token und Luna ein Zwanzigstel von Sol, und keiner dieser Rabatte verschafft Ihnen ein schnelleres erstes Byte. Bei dieser Messung war das günstigste Modell der Familie am langsamsten beim Start.

„Zeit bis zum ersten Token“ ist die falsche Bezeichnung für das, was Sie messen

Bei einem nicht-Reasoning-Modell ist die Zeit bis zum ersten Token grob Netzwerk plus Warteschlange plus Vorbefüllung. Sie skaliert mit der Promptlänge und liegt im Bereich von Hunderten von Millisekunden.

Bei einem Reasoning-Modell ist es eine andere Größe, die dieselbe Bezeichnung trägt. Das Modell denkt nach, bevor es etwas ausgibt, das Sie angefordert haben, so dass die Lücke vor dem ersten sichtbaren Token die gesamte Reasoning-Phase enthält. Diese Phase hat keine Beziehung zu Ihrer Promptlänge. Sie hat eine Beziehung dazu, wie schwierig das Modell das Problem einschätzt.

Daraus ergeben sich zwei Konsequenzen, und beide machen sich in der Produktion bemerkbar.

Die erste ist, dass eine schnelle Token-Rate Sie nicht rettet. Sol gibt 115,2 Tokens pro Sekunde aus, sobald es startet, was schnell ist. Das spielt jedoch kaum eine Rolle, da fast die gesamte Echtzeit vor dem ersten Token verbracht wird.

Die Generierungszeit ist die Ausgabelänge geteilt durch 115,2 Tokens pro Sekunde, so dass diese Tabelle eine arithmetische Berechnung der beiden gemessenen Werte und keine neue Messung ist. Eine Verkürzung Ihrer Antworten ändert kaum die Gesamtzeit. Das Kürzen einer ausführlichen Antwort von 2.000 auf 500 Tokens spart dreizehn Sekunden bei einem Zwei-Minuten-Aufruf.

Die zweite Konsequenz ist, dass sich die Rangfolge je nach Antwortlänge umkehrt. Luna hat die schnellere Token-Rate und den langsameren Start. Vergleicht man die beiden Linien miteinander, kreuzen sie sich bei etwa 10.100 Ausgabe-Tokens: Darunter beendet Sol zuerst, obwohl es langsamer generiert, und darüber macht sich Lunas Rate schließlich für ihre längere Wartezeit bezahlt. Fast nichts, was Sie einem Benutzer bereitstellen, ist eine 10.000-Token-Antwort, so dass für die meisten Arbeitslasten das langsamer startende Modell einfach das langsamere Modell ist.

Was zuerst kaputtgeht

Der Fehler liegt selten im Modellaufruf selbst. Es ist alles, was ihn umgibt und für eine schnelle API dimensioniert wurde.

Idle-Timeouts. Load Balancer, Reverse Proxys, API-Gateways und Serverless-Plattformen begrenzen alle, wie lange eine Verbindung ohne Datenfluss bestehen darf. Viele dieser Standardwerte liegen weit unter zwei Minuten. Vertrauen Sie keiner Zahl, die Sie in einem Blogbeitrag lesen, auch nicht dieser: Lesen Sie Ihre eigene Konfiguration. Die Lösung ist normalerweise eine einzige Anweisung, wie proxy_read_timeout bei nginx, plus die passende Einstellung bei jedem Hop davor, einschließlich des Timeouts des Client-SDK selbst.

Wiederholungsversuche. Eine Wiederholungsstrategie, die bei 300 Millisekunden sinnvoll war, ist bei 100 Sekunden gefährlich. Drei Versuche mit Backoff sind jetzt eine Fünf-Minuten-Anfrage, und eine Flut von Wiederholungsversuchen während einer langsamen Phase erzeugt mehr gleichzeitige Arbeit auf genau dem Endpunkt, der bereits zu kämpfen hatte. Begrenzen Sie die Versuche, verwenden Sie einen Circuit Breaker und machen Sie jeden Aufruf idempotent, damit ein Wiederholungsversuch nicht doppelt belastet oder doppelt schreibt.

Parallelität, die oft übersehen wird. Littles Gesetz besagt, dass die Anzahl der laufenden Anfragen der Ankunftsrate multipliziert mit der Verweildauer im System entspricht. Bei einer Anfrage pro Sekunde und einem 120-Sekunden-Aufruf benötigen Sie 120 gleichzeitig laufende Anfragen, nur um Schritt zu halten. Diese Verbindungen belegen Sockets, Threads oder Funktionsaufrufe jeweils zwei Minuten lang, und nichts davon erscheint auf der Token-Rechnung. Ein Modell, das pro Aufruf günstig ist, kann pro Sekunde belegter Kapazität immer noch teuer sein.

Die Benutzeroberfläche. Kein Lade-Spinner überlebt 102 Sekunden. Wenn die Reasoning-Phase auf Ihrem synchronen Anforderungspfad liegt, ist die Lösung architektonischer Natur, nicht kosmetischer.

So messen Sie es bei Ihrer eigenen Arbeitslast

Anbieter- und Drittanbieterzahlen sind eine Ausgangshypothese. Ihr Prompt, Ihre Region, Ihre Einstellung des Aufwands und Ihr Verkehrsmuster entscheiden über die tatsächliche Zahl.

curl -N -s -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6-sol","input":"Summarise this OpenAPI operation.","stream":true}'

Lesen Sie dann first_byte mit Misstrauen. Bei einem Streaming-Endpunkt sind die ersten Bytes normalerweise ein Stream-Open-Ereignis, kein Inhalts-Token, daher misst time_starttransfer, wann der Server zu sprechen begann, und nicht, wann das Modell zu antworten begann. Diese Lücke ist genau das, was Sie zu dimensionieren versuchen, weshalb ein naiver Testlauf eine schmeichelhafte Zahl meldet.

import time
from openai import OpenAI

client = OpenAI(timeout=600)

t0 = time.perf_counter()
first_content = None

with client.responses.stream(
    model="gpt-6-sol",
    input=PROMPT,
    reasoning={"effort": "low"},
) as stream:
    for event in stream:
        if event.type == "response.output_text.delta" and first_content is None:
            first_content = time.perf_counter() - t0
    total = time.perf_counter() - t0

print(f"ttft={first_content:.2f}s total={total:.2f}s")

Feld- und Ereignisnamen in diesen Snippets stammen von den aktuellen OpenAI API-Strukturen und nicht von der GPT-6-Startankündigung, überprüfen Sie diese also vor der Auslieferung mit der Referenz. Die Messdisziplin ist das, was übernommen wird: Erfassen Sie die Zeit bis zum ersten Inhalts-Token und die Gesamtzeit als separate Metriken, halten Sie sie pro Modell und pro Aufwandsstufe und melden Sie den p95-Wert statt eines Durchschnitts. Die Latenz des ersten Tokens bei einem Reasoning-Modell hat einen langen Schwanz, und ein Durchschnitt verbirgt genau die Anfragen, die ein Timeout erhalten.

Führen Sie dies als geplante Überprüfung und nicht als einmaligen Vorgang aus. Speichern Sie die Streaming-Anfrage in Apidog, prüfen Sie die Antwortzeit und führen Sie das Szenario regelmäßig in CI aus, damit eine regression auf Anbieterseite oder eine Änderung des Aufwandsgrads als fehlerhafter Test statt als Support-Ticket angezeigt wird. Dasselbe Projekt bietet der Frontend-Arbeit eine Möglichkeit, die Wartezeit zu umgehen: Verweisen Sie den Client auf ein Apidog-Mock Ihres eigenen Endpunkts, damit niemand zwei Minuten pro Iteration blockiert ist, während die echte Integration noch gebaut wird. Wenn Sie die Grundlagen hinter den Metriken verstehen möchten, deckt unser Leitfaden zur API-Latenz das Vokabular ab.

Vier Änderungen, die tatsächlich helfen

Holen Sie den Reasoning-Aufruf vom synchronen Pfad. Akzeptieren Sie die Anfrage, geben Sie sofort 202 Accepted mit einer Job-ID zurück und liefern Sie das Ergebnis per Polling oder Webhook. Dies ist die einzige Änderung, die jedes andere Problem kleiner macht, da die 102 Sekunden nicht mehr in einer HTTP-Anfrage stecken, auf die etwas vorgelagertes wartet.

Routen Sie nach Aufwand, nicht nach Modell. Die gemessenen Zahlen beschreiben die maximale Reasoning-Stufe. Die meisten Anfragen benötigen diese nicht. Klassifizieren Sie zuerst die Aufgabe, senden Sie die routinemäßige Mehrheit mit geringem Aufwand und reservieren Sie die teure Einstellung für die Fälle, die es rechtfertigen. OpenAIs eigene Launch-Benchmarks werden aus genau diesem Grund pro Aufwandsstufe ausgewiesen, sodass die Einstellung eine erstklassige Designentscheidung und kein Tuning-Detail ist.

Streamen Sie und zeigen Sie die Wartezeit ehrlich an. Wenn ein Mensch zusieht, streamen Sie die Antwort und sagen Sie, was passiert. Ein Fortschrittsstatus, der die Realität widerspiegelt, ist besser als ein Lade-Spinner, der suggeriert, dass etwas nicht stimmt.

Budgetieren Sie die Realzeit getrennt von den Tokens. Kosten pro Aufgabe und Latenz pro Aufgabe sind unabhängige Achsen, und die September-Einführungen haben eine davon stark beeinflusst. Halten Sie ein Latenzbudget pro Endpunkt neben dem Kostenbudget und behandeln Sie eine Regression bei einem von beiden als Release-Blocker.

Eine Sache, die man nicht annehmen sollte: Die Einführung des Prompt-Caching von GPT-6 senkt den Preis für zwischengespeicherte Eingabe-Lesevorgänge um 90 % und erhöht die Trefferquoten, und das ist eine echte Einsparung. Keiner der Anbieter veröffentlichte eine Latenzangabe dafür, also behandeln Sie jede Verbesserung der ersten Token durch Caching als etwas, das gemessen werden muss, anstatt darum herum zu planen.

Das günstige Modell ist nicht das schnelle Modell

GPT-6 Sol zu 2 $ und 10 $ pro Million Tokens ist eine echte Preisbewegung, und die Benchmark-Ergebnisse dahinter sind stark. Nichts davon macht es schnell im Start. Bei der einzigen öffentlich verfügbaren Latenzmessung benötigt das Modell, das Ihnen 80 % des Token-Preises von Astra spart, mehr als anderthalb Minuten, bevor es ein Wort sagt, und sein billigeres Geschwistermodell benötigt sogar noch länger.

Der Preis steht auf der Rechnung. Die Latenz ist in Ihrer Architektur. Messen Sie Letzteres selbst, mit einem Testsystem, das den ersten Inhalts-Token statt des ersten Bytes misst, bevor Sie ein günstigeres Modell in einen Anforderungspfad integrieren, der für ein schnelleres Modell gebaut wurde.