OpenAI a présenté le 13 août 2026 un nouveau niveau de service dans son API, appelé Ultrafast, qui exécute GPT-5.6 Sol jusqu'à 750 jetons de sortie par seconde, soit jusqu'à 14 fois plus vite que le traitement standard. Le multiplicateur n'est pas le plus intéressant, l'origine de la vitesse l'est davantage. Ultrafast tourne sur du matériel Cerebras à l'échelle du wafer, qui garde les poids du modèle dans 44 Go de mémoire SRAM sur la puce au lieu de les rapatrier depuis une mémoire externe à chaque jeton. C'est une histoire de bande passante mémoire, pas de modèle, et cela change la liste des produits réalisables. L'accès reste un aperçu limité.
The short answer
OpenAI a présenté Ultrafast le 13 août 2026, un niveau de service API qui exécute GPT-5.6 Sol jusqu'à 750 jetons de sortie par seconde. Le modèle ne change pas, le matériel si : Ultrafast tourne sur des processeurs Cerebras à l'échelle du wafer qui gardent les poids en SRAM sur la puce au lieu de les lire depuis une mémoire externe. Cerebras publie une accélération de bout en bout de 5,6 fois sur le test GDP-Val sans perte de qualité. L'accès est un aperçu limité, dans l'API d'abord, qui s'élargira selon la capacité disponible.
Dans tout système interactif, il existe un seuil au-delà duquel l'attente cesse d'être un coût pour devenir une contrainte de conception. En dessous, vous construisez un type de produit. Au-dessus, un autre.
Ce qui a été annoncé
Le 13 août 2026, OpenAI a présenté Ultrafast, un niveau de service de son API qui exécute GPT-5.6 Sol jusqu'à 750 jetons de sortie par seconde, décrit comme jusqu'à 14 fois plus rapide que le traitement standard. C'est un niveau de service, pas un modèle. Les poids sont ceux que vous appelez déjà, et l'annonce porte sur le lieu de leur exécution.
Cette exécution a lieu sur du matériel Cerebras, confirmé par les deux entreprises le même jour. La disponibilité prend la forme d'un aperçu limité à un groupe de clients sélectionnés, avec un formulaire d'inscription et un élargissement annoncé au rythme de la capacité. Parmi les testeurs cités dans la couverture du lancement figurent Jane Street, Podium, Basis et Rogo, sur des usages de programmation, de recherche financière, de commerce et de support client.
La raison de cette vitesse n'est pas celle qu'on imagine
Générer un jeton n'est pas un problème de calcul. C'est un problème de mémoire.
Pour chaque jeton produit, la machine doit lire les poids du modèle. Sur un GPU, ces poids résident dans une mémoire à haute bande passante attachée au boîtier : chaque jeton impose donc de déplacer l'ensemble de travail sur ce lien. Les unités de calcul terminent en avance et attendent. C'est pourquoi le débit d'inférence suit la bande passante mémoire bien plus que la puissance de calcul brute, et pourquoi la méthode habituelle pour accélérer consistait à réduire le modèle afin d'avoir moins à transférer.
Cerebras s'attaque au transfert plutôt qu'au modèle. Son processeur à l'échelle du wafer embarque 44 Go de SRAM sur la puce, donc les poids résident sur le même morceau de silicium que le calcul, et les couches sont mises en pipeline pour que les jetons circulent sans aller-retour externe dans la boucle interne. La citation de Rohan Varma, chez OpenAI, parle de suivre le rythme de la pensée, du code et de la collaboration, mais l'argument technique en dessous est plus étroit et plus intéressant : on peut garder le modèle tel quel et déplacer le goulet d'étranglement.
Cerebras publie aussi des résultats au niveau du harnais d'exécution. L'accélération de bout en bout de 5,6 fois sur GDP-Val sans perte de qualité est la plus structurante, car le bout en bout inclut les portions d'une exécution qu'aucun débit de jetons ne corrige. Le chiffre le plus parlant reste un passage complet de Humanity's Last Exam bouclé en 11 heures 11 contre 78 heures 27. Ce sont les chiffres du fournisseur de matériel, publiés pour vendre ce matériel : à lire comme une affirmation dotée d'un mécanisme plausible, pas comme une mesure indépendante.
Ce que cela change pour ceux qui construisent
Deux catégories bougent, et ce ne sont pas celles que l'on cite en premier.
Le vocal est l'évidence. Une conversation parlée dispose d'un budget strict, de l'ordre de quelques centaines de millisecondes, au-delà duquel un silence se lit comme une panne et non comme une réflexion. Jusqu'ici, tenir ce budget imposait de choisir un modèle plus petit ou spécialisé, donc d'accepter des réponses moins bonnes. Un niveau de service qui fait tenir le modèle complet dans ce budget supprime l'arbitrage, ce qui constitue une décision produit réellement différente.
Le cas moins évident concerne les boucles d'agents. Quand une tâche représente quarante appels successifs, chacun attendant le précédent, le temps total est leur somme, et la latence d'un seul appel se trouve multipliée par la profondeur de la chaîne. C'est la même pression qui se manifeste partout dans l'outillage cette année, depuis les nuages d'intégration continue qui se réorganisent autour des demandes de fusion générées par des agents jusqu'aux capitaux levés pour bâtir la puissance de calcul sous-jacente. Le goulet se déplace toujours vers ce qui est séquentiel.
La réaction d'un chercheur d'OpenAI, citée dans la note de Cerebras, donne la version honnête de l'effet ressenti : la tâche se termine avant même d'avoir le temps de changer de contexte. Ne plus changer de contexte vaut davantage que les secondes gagnées, car les secondes n'étaient pas la partie coûteuse.
Comment nous le traiterions cette semaine
Comme un signal, pas comme une dépendance.
C'est un aperçu sous conditions, dont la disponibilité est explicitement liée à la capacité. Tout ce que vous livrez dessus doit conserver un repli fonctionnel vers le niveau standard, et le conserver avant d'activer la fonctionnalité, pas après. Gardez le niveau de service en configuration. La même requête doit pouvoir passer par les deux chemins, et vos délais d'expiration doivent être réglés pour le chemin lent, car c'est celui que vous emprunterez quand la capacité manquera.
Mesurez ensuite la bonne chose. Les jetons par seconde sont une métrique de composant, et dans une requête réelle le modèle n'est qu'un segment d'une trace qui contient aussi la recherche documentaire, les appels d'outils, la sérialisation et votre propre réseau. Nous instrumenterions le segment complet avant et après, car un appel de modèle 14 fois plus rapide dans une requête qui passe 800 ms ailleurs représente un gain bien plus modeste que ne le suggère le titre. Connaître ce chiffre est précisément ce qui indique si ce niveau de service mérite qu'on conçoive autour.
Sources et pour aller plus loin
- Previewing Ultrafast mode: GPT-5.6 Sol at up to 14X the speed, OpenAI, 13 août 2026
- Accelerating GPT-5.6 Sol Ultrafast with OpenAI, Cerebras, 13 août 2026
- Cerebras Powers Ultrafast Mode for OpenAI's GPT-5.6 Sol, GlobeNewswire, 13 août 2026
- OpenAI introduces Ultrafast, a new mode that makes GPT-5.6 Sol work at 14x the speed, TechCrunch, 13 août 2026
- OpenAI introduces new Ultrafast mode for GPT-5.6 Sol delivering 14x faster tokens, Neowin, 13 août 2026
- Ultrafast mode preview in the API, forum développeurs OpenAI, 13 août 2026
Questions fréquentes
Qu'est-ce qu'Ultrafast exactement ?
Un nouveau niveau de service dans l'API OpenAI, présenté le 13 août 2026, et non un nouveau modèle. Le modèle reste le GPT-5.6 Sol que vous appelez déjà. Ce qui change, c'est le matériel qui l'exécute, donc la vitesse à laquelle les jetons reviennent : jusqu'à 750 jetons de sortie par seconde, ce qu'OpenAI décrit comme jusqu'à 14 fois plus rapide que le traitement standard. Le lancement se fait d'abord dans l'API, sous forme d'aperçu limité pour un groupe de clients sélectionnés, avec un formulaire d'inscription pour les autres. OpenAI indique que l'accès s'élargira à mesure que la capacité augmentera.
Pourquoi le matériel Cerebras va-t-il plus vite ?
La génération de jetons est limitée par la bande passante mémoire, pas par le calcul. Pour produire chaque jeton, la machine doit lire les poids du modèle. Sur un GPU, ces poids résident dans une mémoire à haute bande passante placée à côté de la puce, donc chaque jeton implique de déplacer des gigaoctets sur ce lien. Cerebras utilise un processeur de la taille d'un wafer doté de 44 Go de SRAM sur la puce elle-même : les poids se trouvent là où le calcul a lieu, et le flux de jetons n'est plus conditionné par un transfert externe. D'où un gain important sur la génération en particulier, sans passer par un modèle réduit ou distillé.
La vitesse se paie-t-elle en précision ?
Les deux entreprises répondent non, et la formulation exacte mérite attention. Cerebras publie une accélération de bout en bout de 5,6 fois sur le test GDP-Val sans perte de qualité, ce qui est un argument de type mêmes poids, mêmes sorties : le modèle n'est ni quantifié à la baisse ni remplacé par une version plus légère, il est simplement exécuté plus vite. Il s'agit d'un test publié par le fournisseur du matériel, donc à traiter comme une affirmation à vérifier sur votre propre jeu d'évaluation plutôt que comme un résultat indépendant. Le raisonnement structurel tient : garder les poids en SRAM ne change rien à ce qu'ils calculent.
Qu'est-ce que cela rend possible qui ne l'était pas ?
Tout ce où un humain ou un système attend la réponse pour continuer. OpenAI cite la recherche financière, la réponse à incident, le support client, les applications vocales, le commerce et l'expérimentation en direct, avec un point commun : la valeur de la réponse décroît avec le temps. Le cas vocal est le plus net, car une conversation dispose d'un budget de latence de quelques centaines de millisecondes avant de paraître cassée, et tenir ce budget imposait jusqu'ici de descendre vers un modèle plus petit. Le second cas concerne les boucles d'agents, où une tâche représente des dizaines d'appels successifs et où le temps total est leur somme.
Faut-il construire dessus maintenant ?
Pas comme une dépendance. C'est un aperçu à accès limité, et OpenAI précise que la disponibilité dépend de la capacité, donc tout ce que vous livrez dessus doit garder un chemin de repli fonctionnel vers le niveau standard. Deux remarques pratiques. Gardez le niveau de service dans la configuration plutôt qu'en hypothèse inscrite dans vos invites ou vos délais d'expiration, puisque le même code doit tourner sur les deux. Et mesurez la latence de bout en bout, pas les jetons par seconde : dans la plupart des applications réelles, le modèle n'est qu'un segment d'une trace qui contient aussi la recherche documentaire, les appels d'outils et vos propres sauts réseau.