Latence GPT-6 Sol : 102 secondes au premier jeton

Vous avez échangé gpt-6-astra contre gpt-6-sol car le prix des jetons est passé de 10 $ et 50 $ par million à 2 $ et 10 $. La facture est excellente. Puis votre temps de réponse p95 dépasse les deux minutes, votre équilibreur de charge commence à renvoyer des erreurs de délai d'attente de passerelle, et le support est submergé de personnes demandant pourquoi la page se bloque.

Rien n'est cassé. Vous avez changé la nature de la charge de travail, pas seulement son prix.

Artificial Analysis mesure GPT-6 Sol à 115,2 jetons de sortie par seconde avec un temps jusqu'au premier jeton de 102,15 secondes. GPT-6 Luna mesure 153,9 jetons de sortie par seconde avec 124,23 secondes jusqu'au premier jeton. Ces deux chiffres comportent d'importantes mises en garde, qui constituent la première moitié de cet article. La seconde moitié est consacrée à ce qu'il faut en faire : comment mesurer honnêtement la latence du premier jeton sur votre propre charge de travail, et les quatre modifications de conception qui empêchent un modèle de 100 secondes de faire tomber votre API avec lui.

Pour le contexte plus large de trois lancements frontaliers en deux jours, consultez la guerre des prix des modèles de septembre 2026.

Le chiffre, et tout ce qu'il y a de mal à le citer

Lisez la colonne des mises en garde avant la colonne des chiffres.

Trois choses que cette colonne vous dit.

Ce sont des chiffres d'Artificial Analysis, pas d'OpenAI. OpenAI a publié le prix, le contexte, la disponibilité et une série de scores de référence lors du lancement. Il n'a pas publié de chiffre de latence dans les documents que nous avons lus. Ainsi, les 102,15 secondes proviennent d'une partie tierce exécutant ses propres tests sur son propre réseau, et vous devriez les considérer comme une indication plutôt que comme une spécification. Notez-les dans votre propre documentation comme nous le faisons ici.

Ils décrivent la variante de raisonnement « max ». Des étiquettes d'effort apparaissent partout dans les tableaux de référence des deux fournisseurs au moment du lancement : faible, moyen, élevé, très élevé, max. Max est le sommet de cette échelle, et l'effort de raisonnement est le levier le plus important sur la latence du premier jeton. Une mesure de la configuration la plus lente n'est pas une mesure de la configuration que vous exécuterez en production.

Ce sont des mesures du point de terminaison d'un fournisseur à un instant donné. La capacité de service, le routage et la profondeur de la file d'attente varient. Un chiffre de semaine de lancement pris pendant un pic de trafic est un scénario du pire se faisant passer pour une constante.

Ce qui survit à ces trois mises en garde est la direction, et cette direction est le propos de cet article. Le modèle bon marché n'est pas le modèle rapide. Sol coûte un cinquième d'Astra par jeton et Luna coûte un vingtième de Sol, et aucune de ces réductions ne vous offre un premier octet plus rapide. Sur cette mesure, le modèle le moins cher de la famille a été le plus lent à démarrer.

Le temps jusqu'au premier jeton est un nom inapproprié pour ce que vous mesurez

Sur un modèle non-raisonneur, le temps jusqu'au premier jeton est environ le réseau plus la file d'attente plus le pré-remplissage. Il évolue avec la longueur de l'invite et se situe dans les centaines de millisecondes.

Sur un modèle raisonneur, c'est une quantité différente portant la même étiquette. Le modèle réfléchit avant d'émettre quoi que ce soit que vous ayez demandé, de sorte que l'intervalle avant le premier jeton visible contient toute la phase de raisonnement. Cette phase n'a aucun rapport avec la longueur de votre invite. Elle a un rapport avec la difficulté que le modèle attribue au problème.

Deux conséquences en découlent, et toutes deux se manifestent en production.

La première est qu'un débit de jetons rapide ne vous sauve pas. Sol émet à 115,2 jetons par seconde une fois qu'il a démarré, ce qui est rapide. Cela n'a pas beaucoup d'importance, car presque tout le temps réel est passé avant le premier jeton.

Le temps de génération est la longueur de sortie divisée par 115,2 jetons par seconde, donc ce tableau est une arithmétique sur les deux chiffres mesurés plutôt qu'une nouvelle mesure. Raccourcir vos réponses ne change presque pas le total. Réduire une réponse verbeuse de 2 000 jetons à 500 fait gagner treize secondes sur un appel de deux minutes.

La deuxième conséquence est que le classement s'inverse en fonction de la longueur de la réponse. Luna a un débit de jetons plus rapide et un démarrage plus lent. Si l'on compare les deux, ils se croisent à environ 10 100 jetons de sortie : en dessous de ce seuil, Sol termine en premier malgré une génération plus lente, et au-dessus, le débit de Luna compense finalement son attente plus longue. Presque rien de ce que vous servez à un utilisateur n'est une réponse de 10 000 jetons, donc pour la plupart des charges de travail, le modèle qui démarre plus lentement est simplement le modèle le plus lent.

Ce qui cède en premier

L'échec est rarement l'appel au modèle lui-même. C'est tout ce qui l'entoure et qui était dimensionné pour une API rapide.

Délai d'inactivité. Les équilibreurs de charge, les proxys inverses, les passerelles d'API et les plateformes sans serveur limitent tous la durée pendant laquelle une connexion peut rester inactive sans flux d'octets. Beaucoup de ces valeurs par défaut sont bien inférieures à deux minutes. Ne faites pas confiance à un chiffre que vous lisez dans un article de blog, y compris celui-ci : allez lire votre propre configuration. La solution est généralement une seule directive, telle que proxy_read_timeout sur nginx, plus le réglage correspondant sur chaque saut en amont, y compris le délai d'attente du SDK client lui-même.

Nouvelles tentatives. Une politique de nouvelle tentative qui avait du sens à 300 millisecondes est dangereuse à 100 secondes. Trois tentatives avec un délai d'attente exponentiel sont désormais une requête de cinq minutes, et une rafale de nouvelles tentatives pendant une période lente ajoute davantage de travail concurrent sur le point d'accès exact qui était déjà en difficulté. Limitez les tentatives, maintenez un coupe-circuit, et rendez chaque appel idempotent afin qu'une nouvelle tentative ne puisse pas facturer ou écrire deux fois.

Concurrence, que les gens oublient. La loi de Little stipule que le nombre de requêtes en cours est égal au taux d'arrivée multiplié par le temps passé dans le système. À une requête par seconde et un appel de 120 secondes, vous avez besoin de 120 requêtes concurrentes en cours juste pour suivre. Ces connexions occupent des sockets, des threads ou des invocations de fonctions pendant deux minutes chacune, et rien de tout cela n'apparaît sur la facture des jetons. Un modèle bon marché par appel peut toujours être coûteux par seconde de capacité détenue.

L'interface utilisateur. Aucun indicateur de chargement ne survit 102 secondes. Si la phase de raisonnement se trouve sur votre chemin de requête synchrone, la solution est architecturale, pas cosmétique.

Comment le mesurer sur votre propre charge de travail

Les chiffres des fournisseurs et des tiers sont une hypothèse de départ. Votre invite, votre région, votre réglage d'effort et votre modèle de trafic décident du chiffre réel.

Commencez par la vue au niveau du transport, ce qui ne prend qu'une seule commande :

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}'

Lisez ensuite first_byte avec suspicion. Sur un point d'accès en streaming, les premiers octets sont généralement un événement d'ouverture de flux, pas un jeton de contenu, donc time_starttransfer mesure quand le serveur a commencé à parler plutôt que quand le modèle a commencé à répondre. Cet écart est précisément ce que vous essayez de dimensionner, c'est pourquoi un testeur naïf rapporte un chiffre flatteur.

Le chronométrage du premier delta de contenu est la mesure qui compte :

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")

Les noms de champs et d'événements dans ces extraits proviennent des formats d'API OpenAI actuels plutôt que de l'annonce de lancement de GPT-6, alors vérifiez-les par rapport à la référence avant de déployer. Ce qui est important, c'est la discipline de mesure : enregistrez le temps jusqu'au premier jeton de contenu et le temps total comme des métriques distinctes, conservez-les par modèle et par niveau d'effort, et rapportez le p95 plutôt qu'une moyenne. La latence du premier jeton sur un modèle de raisonnement a une longue traîne, et une moyenne masque précisément les requêtes qui expirent.

Exécutez cela comme une vérification planifiée plutôt qu'une vérification ponctuelle. Enregistrez la requête de streaming dans Apidog, vérifiez le temps de réponse et exécutez le scénario selon un calendrier en CI afin qu'une régression côté fournisseur ou un changement de niveau d'effort apparaisse comme un test échoué au lieu d'un ticket de support. Le même projet offre au travail frontal une solution pour contourner l'attente : pointez le client vers un mock Apidog de votre propre point d'accès afin que personne ne soit bloqué pendant deux minutes par itération pendant que la véritable intégration est encore en cours de construction. Si vous voulez les principes fondamentaux derrière les métriques, notre guide sur la latence des API couvre le vocabulaire.

Quatre changements qui aident réellement

Retirez l'appel de raisonnement du chemin synchrone. Acceptez la requête, renvoyez immédiatement un code 202 Accepted avec un ID de tâche, et délivrez le résultat par interrogation (polling) ou webhook. C'est le seul changement qui réduit tous les autres problèmes, car les 102 secondes ne vivent plus à l'intérieur d'une requête HTTP qu'un élément en amont attend.

Routez par effort, et non par modèle. Les chiffres mesurés décrivent le raisonnement maximal. La plupart du trafic n'en a pas besoin. Classifiez d'abord la tâche, envoyez la majorité de routine avec un faible effort, et réservez le réglage coûteux aux cas qui le méritent. Les propres benchmarks de lancement d'OpenAI sont rapportés par niveau d'effort précisément pour cette raison, de sorte que le réglage est une décision de conception de premier ordre plutôt qu'un détail d'ajustement.

Diffusez en streaming et affichez l'attente honnêtement. Si un humain regarde, diffusez la réponse en streaming et dites ce qui se passe. Un état de progression qui reflète la réalité est préférable à un indicateur de chargement qui suggère que quelque chose ne va pas.

Budgétisez le temps réel séparément des jetons. Le coût par tâche et la latence par tâche sont des axes indépendants, et les lancements de septembre ont fortement modifié l'un d'entre eux. Maintenez un budget de latence par point d'accès à côté du budget de coût, et traitez toute régression de l'un ou de l'autre comme un bloqueur de publication.

Une chose à ne pas supposer : la version de mise en cache des invites de GPT-6 réduit le prix des lectures d'entrée mises en cache de 90 % et augmente les taux de réussite, et c'est une véritable économie. Aucun des fournisseurs n'a publié de déclaration de latence à ce sujet, alors considérez toute amélioration du premier jeton grâce à la mise en cache comme quelque chose à mesurer plutôt que comme quelque chose sur quoi baser une planification.

Le modèle bon marché n'est pas le modèle rapide

GPT-6 Sol à 2 $ et 10 $ par million de jetons est une véritable évolution de prix, et les résultats de référence qui le sous-tendent sont solides. Rien de tout cela ne le rend rapide à démarrer. Sur la seule mesure de latence publique disponible, le modèle qui vous fait économiser 80 % sur le prix des jetons d'Astra demande plus d'une minute et demie avant de dire un mot, et son équivalent moins cher demande encore plus de temps.

Le prix est sur la facture. La latence est dans votre architecture. Mesurez vous-même la seconde, avec un outil qui chronomètre le premier jeton de contenu plutôt que le premier octet, avant de promouvoir un modèle moins cher dans un chemin de requête qui a été conçu pour un modèle plus rapide.