GPT-5.6 Sol : j'ai divisé la latence par 6 sans Ultrafast

OpenAI a prévisualisé Ultrafast le 13 août : GPT-5.6 Sol qui crache jusqu'à 750 tokens par seconde sur du silicium Cerebras, soit « jusqu'à 14× » la vitesse standard. Le hic, je l'ai lu dans le même paragraphe que tout le monde : c'est en liste d'attente, sans prix affiché, réservé à une poignée de comptes. Pendant ce temps, mon agent de support interne mettait toujours huit secondes à répondre. Alors au lieu d'attendre un e-mail d'OpenAI, j'ai passé un après-midi à traquer ces secondes. Résultat : 1,3 s, sans changer une virgule au modèle.

Ce tuto, c'est ce que j'ai fait, dans l'ordre, avec les chiffres réels et le levier qui n'a rien donné.

Ultrafast, 750 tokens/s, Cerebras : ce qui a été annoncé le 13 août

Reprenons les faits, parce qu'ils cadrent la suite. Ultrafast est un nouveau service tier qui fait tourner GPT-5.6 Sol jusqu'à 750 tokens de sortie par seconde, propulsé par l'infrastructure Cerebras issue du partenariat à 10 milliards de dollars signé plus tôt cette année. L'intelligence du modèle, sa fenêtre de contexte, la qualité de sortie : rien ne change. Seule la vitesse à laquelle les tokens arrivent bouge.

Entre les deux, il existe déjà un tier Fast : environ 2,5× la vitesse standard, facturé le double du tarif — 10 $ le million de tokens d'entrée et 60 $ en sortie, contre 5 $ et 30 $ pour Sol en standard. Ordre de grandeur : le standard tourne autour de 110-130 tokens/s, Fast vers 300, et Ultrafast vise 750. Utile à garder en tête pour calibrer ses attentes.

D'où vient la latence d'un agent GPT-5.6 (et ce qui coûte vraiment des secondes)

Avant de bricoler, il faut savoir où partent les secondes. Sur une réponse d'agent, la latence se décompose grosso modo en trois blocs :

• Le temps jusqu'au premier token (TTFT) : le modèle lit votre prompt (le prefill) avant d'écrire quoi que ce soit. Un system prompt de 3 000 tokens + un historique de conversation, ça se paie en attente sèche.
• La génération : le nombre de tokens de sortie divisé par le débit. 320 tokens à 120 tokens/s, c'est 2,7 s. Les mêmes 320 tokens à 300 tokens/s, 1,1 s.
• Les allers-retours d'outils : chaque appel de fonction relance un cycle réseau + prefill. Un agent qui enchaîne trois tool calls paie trois fois l'addition.

Mon erreur de départ, celle que je vois partout : je regardais le débit du modèle en pensant que c'était le problème. En vrai, sur mon agent, plus de la moitié du temps partait en prefill et en un passage de raisonnement dont je n'avais pas besoin. Le débit n'était qu'un tiers de l'histoire.

Comment réduire la latence de GPT-5.6 Sol sans attendre Ultrafast

Voici les leviers, du plus rentable au plus marginal. Faites-les dans cet ordre, mesurez après chacun.

1. Le streaming, la victoire la plus rapide

Le streaming ne change pas la latence réelle, il change la latence perçue — et c'est celle qui compte pour un humain en face. Au lieu d'attendre les 320 tokens, l'utilisateur voit le texte se former dès le premier. Sur une interface de support, ça transforme une attente de 8 s en une réponse « qui commence tout de suite ». Si vous n'avez qu'une chose à faire aujourd'hui, c'est ça.

from openai import OpenAI
client = OpenAI()

stream = client.responses.create(
    model='gpt-5.6-sol',
    service_tier='fast',          # standard | fast | (ultrafast: liste d'attente)
    reasoning={'effort': 'low'},  # le curseur de réflexion, au minimum pour du temps réel
    max_output_tokens=350,        # on plafonne : pas de roman inutile
    stream=True,
    input=messages,
)

for event in stream:
    if event.type == 'response.output_text.delta':
        print(event.delta, end='', flush=True)

2. service_tier : le levier que tout le monde oublie

Le paramètre service_tier='fast' vous fait passer sur le pool accéléré (~2,5×). Il double le prix, donc on ne l'active pas partout — mais sur le dernier tour de génération, celui que l'utilisateur attend, il vaut son coût. Ma règle : Fast sur la réponse visible, standard sur les étapes internes (classification, extraction, résumé de contexte) que personne ne regarde vivre.

3. Cache de prompt 30 min : le prefill quasi gratuit

C'est la nouveauté fraîche du 13 août qu'on a peu commentée : la durée de vie du cache de prompt passe à au moins 30 minutes sur toute la famille. Concrètement, si votre system prompt et vos instructions d'outils dépassent ~1 024 tokens et restent en tête de requête, ils sont mis en cache. Les lectures en cache coûtent 90 % de moins (0,50 $ le million pour Sol au lieu de 5 $) et — surtout ici — le prefill devient quasi instantané. Le TTFT s'écroule.

4. Sortez les outils du chemin critique

Trois tool calls séquentiels, c'est trois prefills. Deux réflexes : paralléliser les appels indépendants, et déplacer l'orchestration hors du contexte quand c'est possible — l'approche que j'avais détaillée pour le Programmatic Tool Calling, qui sort les allers-retours du contexte du modèle. Chaque round-trip économisé, c'est 0,5 à 1,5 s de gagnée.

Mon bench maison : de 8,1 s à 1,3 s (et le levier qui n'a rien donné)

Test sur mon agent de support interne, question moyenne, 1 appel d'outil, réponse ~320 tokens. Cinq mesures, médiane retenue.

Soit un facteur ~6 sur la latence perçue, sans toucher au modèle ni attendre Ultrafast. Le plus gros gain n'est pas venu de la vitesse brute mais du couple streaming + effort low : couper un passage de réflexion superflu m'a rendu trois secondes d'un coup.

Le levier qui n'a rien donné : les predicted outputs. Sur un agent qui reformule du texte connu, ça peut aider, mais chez moi les réponses étaient trop variables et le speculative decoding se cassait à chaque appel d'outil — gain médian sous les 5 %, pour un code plus fragile. J'ai laissé tomber au bout d'une heure. À l'inverse, si votre besoin est du volume asynchrone et pas du temps réel, ne cherchez pas la latence : visez le batch, qui joue l'inverse — trier 10 000 tickets la nuit à prix cassé.

Agents vocaux et support live : là où la latence se paie cash

Ces optimisations sont du confort sur un chat écrit. Sur du vocal, elles sont vitales : au-delà de ~800 ms de silence, l'humain croit que la ligne a coupé. C'est tout l'enjeu des standards téléphoniques IA, où le moindre TTFT s'entend — j'en avais fait la démonstration pas à pas pour monter un standard téléphonique IA de bout en bout. Là, Fast n'est plus une option de luxe, c'est le minimum, et Ultrafast à 750 tokens/s est exactement le genre de tier qui rendrait un agent vocal indiscernable d'un humain. En attendant, streaming + phrases courtes générées + cache font le job.

Petit rappel de sobriété : sur GPT-5.6 Sol, les erreurs factuelles ont chuté de 68 % par rapport à 5.5-Instant. Vous n'avez donc pas à compenser la vitesse par un modèle plus bête — vous gardez la qualité, vous ne payez que le débit.

Faut-il payer le tier Fast, ou attendre Ultrafast ?

Faisons les comptes. Passer tout votre trafic en Fast double la facture : 10/60 $ le million au lieu de 5/30 $. Sur un agent qui brasse quelques millions de tokens par mois, ça se sent vite. Ma reco tient en une phrase : Fast uniquement sur le dernier appel, celui que l'utilisateur regarde ; standard partout ailleurs. Le surcoût reste marginal parce qu'il ne s'applique qu'à une fraction des tokens.

Ultrafast ? Inscrivez-vous à la liste d'attente si vous faites du vocal ou du live à fort volume — c'est là que 750 tokens/s change la nature du produit. Pour un chat écrit interne, le streaming vous a déjà donné 90 % du ressenti d'Ultrafast, gratuitement. N'attendez pas une bêta pour livrer. Et si votre vraie douleur n'est pas la vitesse mais le montant en bas de la facture, c'est un autre chantier : je l'ai décortiqué dans comment reprendre la main sur votre facture de tokens.

Si vous voulez juste tester ces réglages sans écrire de code, ils sont accessibles côté produit dans

Ce que je retiens

Ultrafast fera parler, à raison, le jour où il sortira de la liste d'attente. Mais l'annonce du 13 août a masqué la vraie bonne nouvelle pour ceux qui shippent aujourd'hui : le cache à 30 minutes, combiné au streaming et au bon service_tier, suffit à rendre un agent GPT-5.6 réactif. J'ai fait ×6 en un après-midi, sans budget supplémentaire notable. Commencez par le streaming, mesurez, plafonnez vos tokens, cachez votre préfixe — et gardez Fast pour l'endroit exact où quelqu'un attend. Le reste, c'est de la patience jusqu'à ce que Cerebras arrive dans votre région d'API.