Comment GPT‑5.6 allie intelligence et efficacité de pointe

Nous avons conçu la famille de modèles GPT‑5.6 pour équilibrer capacités et coûts sur tout l’éventail des tâches pour lesquelles nos modèles sont utilisés. Notre modèle phare, GPT‑5.6 Sol, avec un raisonnement Max, surpasse Claude Fable 5 sur l’Artificial Analysis Coding Agent Index pour moins de la moitié du coût. Terra égale GPT‑5.5 sur les benchmarks d’intelligence pour moitié moins cher, tandis que Luna, notre modèle le plus rapide et le plus abordable, coûte 80 % de moins que Sol. Pour atteindre ces niveaux d’efficacité, nos équipes de recherche et d’ingénierie ont apporté des optimisations majeures à chaque couche principale de notre pile. Ces améliorations concernent nos modèles, l’inférence, c’est-à-dire la façon dont nous exécutons les modèles pour générer une sortie, et notre harnais agentique, utilisé par Codex comme par ChatGPT Work.

Alors que l’utilisation de nos modèles a atteint 1 milliard d’utilisateurs actifs et plus de 2 millions d’entreprises en quatre ans, l’efficacité a joué un rôle central pour rendre les bénéfices de l’intelligence accessibles à tous. Notre mission est de veiller à ce que l’intelligence artificielle générale profite à toute l’humanité. Au fil de ces années, nous avons continuellement cherché de nouvelles optimisations dans toute notre pile afin de proposer les modèles les plus performants à chaque niveau de la courbe coût-intelligence. Avec GPT‑5.6, entraîné pour accomplir davantage de travail par token, nous avons atteint notre meilleur niveau d’efficacité à ce jour en matière d’intelligence par token. Lors de l’entraînement, nous optimisons à la fois la réussite des tâches et l’efficacité, afin d’amener le modèle à suivre un chemin plus direct pour accomplir une tâche.

Cet article va au-delà de nos modèles et explique comment nous avons favorisé l’efficacité grâce aux progrès réalisés dans deux autres grandes composantes de la pile : 1) l’inférence, en optimisant l’équilibrage de charge, le décodage spéculatif, la mise en cache et les noyaux afin de tirer davantage de résultats du même matériel ; et 2) notre harnais agentique, notamment par une meilleure gestion de l’encombrement du contexte, de l’utilisation des outils et des tâches répétées. Nous expliquerons également comment GPT‑5.6 Sol a permis d’obtenir plusieurs de ces gains de manière autonome. Prise isolément, chaque amélioration peut sembler limitée, mais leur cumul nous permet d’atteindre la pointe en matière d’intelligence comme d’efficacité.

Dans un monde où les ressources de calcul sont limitées et où la demande de modèles croît plus vite que les capacités, l’efficacité est au cœur de la conception de chaque système. C’est particulièrement vrai pour notre pile d’inférence, qui exécute les modèles entraînés afin de générer des réponses. Notre principal objectif est de traiter davantage de tokens avec le même matériel, tout en préservant l’intelligence, la latence, la disponibilité et la fiabilité attendues par les utilisateurs.

Pour y parvenir, il faut optimiser l’ensemble du système. Un modèle peut être très efficace pris isolément, mais rester coûteux à servir si les requêtes sont mal réparties, si le matériel reste inactif ou si les transferts de données ralentissent les calculs. Les améliorations de chaque couche se cumulent : optimisation du routage (où les requêtes sont envoyées), de la planification (quand elles le sont), des noyaux (logiciels exécutés sur les GPU), de la mise en cache (travail enregistré et réutilisé) et de l’implémentation du modèle (ordre du code GPU). GPT‑5.6 Sol dans Codex a joué un rôle déterminant dans toutes ces optimisations.

Le premier exemple important concerne l’équilibrage de charge. À l’échelle mondiale, nous acheminons les requêtes selon des facteurs tels que la zone géographique, la capacité disponible et le type d’accélérateur, c’est-à-dire le GPU ou la puce spécialisée qui exécute le modèle. Au sein d’un cluster, nous répartissons le travail entre les instances du modèle selon la charge, la longueur du contexte, la disponibilité du cache et d’autres propriétés des requêtes. Dans chaque instance, le travail doit ensuite être réparti efficacement entre les accélérateurs, les sous-réseaux du modèle et les cœurs de calcul. GPT‑5.6 Sol dans Codex nous aide à analyser le trafic de production, à repérer des sources de déséquilibre auparavant négligées, à tester de nouvelles stratégies de routage et à ajuster continuellement ces heuristiques. À elles seules, ces améliorations de l’équilibrage de charge ont considérablement réduit le coût de service de nos modèles.

Nous avons également utilisé GPT‑5.6 Sol pour optimiser la passe avant du modèle, c’est-à-dire le calcul qui transforme les entrées en prédictions du token suivant. Même lorsque les opérations individuelles sont rapides, des transferts de mémoire excessifs, la synchronisation et une organisation inefficace des données peuvent laisser les GPU inactifs. Pour éviter cela, GPT‑5.6 Sol a identifié les calculs pouvant être préexécutés, évités ou parallélisés. Avec Codex, GPT‑5.6 Sol a réécrit et optimisé de manière autonome nos noyaux de production, le code central qui exécute les opérations mathématiques constituant le modèle. Cela a notamment été possible parce que nous avons entraîné GPT‑5.6 à écrire et améliorer efficacement des noyaux en Triton⁠(ouverture dans une nouvelle fenêtre) et en Gluon⁠(ouverture dans une nouvelle fenêtre), deux langages de programmation GPU open source maintenus par OpenAI. Ces efforts, associés aux avancées plus générales de GPT‑5.6 Sol sur les noyaux, ont réduit de 20 % les coûts de service de bout en bout. Nous avons également beaucoup investi dans des outils de vérification, comme l’outil open source FpSan⁠(ouverture dans une nouvelle fenêtre) (assainisseur de virgule flottante), afin de valider l’exactitude des noyaux écrits par GPT‑5.6 Sol.

Le décodage spéculatif constitue un autre moyen d’améliorer la vitesse et l’efficacité. Cette technique consiste à exécuter un modèle d’ébauche plus petit, ou « spéculateur », parallèlement au modèle principal afin de proposer plusieurs tokens que ce dernier vérifie simultanément. Lorsque ces propositions sont acceptées, le système peut produire plusieurs tokens de sortie en une seule passe du modèle principal, réduisant ainsi les coûteux calculs séquentiels. GPT‑5.6 Sol a amélioré son propre modèle d’ébauche en concevant et menant des centaines d’expériences sur son architecture, afin de tester différentes tailles, structures et fonctionnalités. GPT‑5.6 Sol a également lancé et surveillé l’entraînement du spéculateur, en intervenant de manière autonome en cas de problème, notamment lors de pannes matérielles ou d’une instabilité de l’entraînement. Les améliorations obtenues ont accru de plus de 15 % l’efficacité de la génération de tokens.

Lors du traitement de tokens d’entrée non mis en cache, le modèle construit le cache clé-valeur (KV) en une passe exigeante en calcul ; lors de la génération de la sortie, il consulte et étend ce cache de façon répétée. La configuration de service optimale, notamment le regroupement par lots, le partitionnement et la gestion du cache KV, dépend fortement de la charge de travail : longueur du prompt et de la sortie, taille des lots, taux de succès du cache, caractéristiques des requêtes, etc. Auparavant, l’espace des configurations était toutefois trop vaste pour permettre un réglage systématique, obligeant les ingénieurs à s’appuyer sur des heuristiques générales. Grâce à GPT‑5.6 Sol dans Codex, nous avons pu analyser les charges de production, générer et évaluer des configurations candidates, puis optimiser au maximum la configuration du moteur et du modèle pour chaque scénario. Ce procédé rend possible un nouveau niveau d’optimisation propre à chaque charge de travail et permet de tirer davantage d’inférences utiles du même matériel.

L’optimisation de l’inférence repose sur une boucle de rétroaction continue. Nous mesurons le comportement en production, repérons les principaux écarts, mettons en œuvre des changements et vérifions qu’ils améliorent l’ensemble du système plutôt qu’un benchmark isolé. GPT‑5.6 Sol et Codex accélèrent chaque étape de cette boucle. Notre équipe peut ainsi explorer davantage d’idées, réagir plus vite à l’évolution des charges de travail et créer une pile d’inférence offrant aux utilisateurs une latence et des coûts réduits, ainsi qu’une capacité accrue.

ChatGPT Work et Codex accomplissent des tâches complexes au moyen d’une série de requêtes au modèle et d’appels d’outils. Au cours d’un même tour, de la demande de l’utilisateur à la réponse finale, Codex peut examiner du code source, rechercher l’historique des déploiements, lire des rapports d’incident, modifier un fichier et exécuter des tests. Chaque étape peut nécessiter une requête.

La préparation du contexte, la transmission des données, l’exécution de l’inférence, l’appel d’outils et le lancement de processus consomment tous du temps et des ressources de calcul. Si une tâche nécessite 30 requêtes au modèle, une seconde supplémentaire par requête finit par peser lourd. Améliorer les performances globales suppose de réduire les tâches répétées dans tout le système, et pas seulement d’accélérer le modèle.

Ces effets multiplicateurs ont guidé la conception de notre harnais agentique, une couche d’orchestration en Rust qui relie nos modèles, nos outils et l’environnement de l’utilisateur. Nous verrons ensuite comment limiter l’encombrement du contexte, charger les outils et réutiliser le travail déjà effectué pour rendre chaque requête plus efficace.

À mesure que les agents accèdent à davantage d’outils, de compétences, de plugins et d’historique de conversation, les fenêtres de contexte peuvent facilement s’étendre. Cela augmente les coûts, détourne l’attention du modèle et provoque un raisonnement inutile. Le harnais peut réduire ce surcoût grâce à la découverte différée, qui ne rend accessibles les intégrations, outils MCP personnalisés, compétences et plugins qu’en cas de besoin. Le harnais empêche également les outils et intégrations MCP de consommer de façon imprévue la fenêtre de contexte. La sortie des outils est limitée par défaut à 10 000 tokens, sauf si le modèle demande une autre limite.

Comme indiqué précédemment, une boucle d’agent peut envoyer plusieurs fois aux GPU, au cours d’un même tour, les mêmes instructions, l’historique de la conversation, les définitions des outils et les résultats antérieurs. Le traitement de ces entrées répétées est coûteux. La mise en cache des prompts réutilise donc les calculs associés au préfixe d’un prompt déjà traité. Pour préserver ce préfixe, le harnais traite tout l’historique visible par le modèle comme un journal en ajout seul : les nouveaux messages, résultats d’outils et mises à jour de l’environnement sont ajoutés à la fin plutôt qu’insérés dans le contexte antérieur. Les outils sont également présentés dans un ordre déterministe, tandis que les paramètres d’exécution, comme les politiques d’approbation, sont appliqués lors de l’exécution plutôt qu’intégrés aux définitions des outils. Ce choix de conception contribue aux taux globaux élevés de succès du cache de prompts de Codex et de ChatGPT Work.

Les gains d’efficacité obtenus avec GPT‑5.6 résultent d’années d’améliorations cumulées dans toute la pile, de la recherche à l’inférence en passant par notre harnais agentique. Le rôle de GPT‑5.6 dans nombre de ces améliorations nous rend optimistes quant à l’accélération du rythme des optimisations. Nous poursuivrons des optimisations plus poussées dans des domaines comme les noyaux, parallèlement à des améliorations fondamentales de notre pile. Nous avons hâte de faire bénéficier nos utilisateurs et clients de ces améliorations continues et invisibles, sous la forme d’une intelligence plus largement accessible et plus rentable.

Nous remercions tout particulièrement Matthew Ferrari, Philippe Tillet, Ahmed Ibrahim, Joe Gershenson et Steve Coffey, membres du personnel technique, pour leur contribution à cet article.