Comment GPT‑5.6 allie intelligence et efficacité de pointe

Nous avons conçu la famille de modèles GPT‑5.6 pour équilibrer les capacités et les coûts dans tout l’éventail des tâches que les gens confient à nos modèles. Notre modèle phare, GPT‑5.6 Sol, surpasse Claude Fable 5 avec le raisonnement Max dans l’Artificial Analysis Coding Agent Index, et ce, à moins de la moitié du coût. Terra égale GPT‑5.5 dans les tests d’intelligence à la moitié du prix, tandis que Luna est notre modèle le plus rapide et le plus abordable, à un prix inférieur de 80 % à celui de Sol. Pour atteindre cette efficacité, nos équipes de recherche et nos équipes techniques ont apporté d’importantes optimisations à chaque couche majeure de notre infrastructure. Ces améliorations touchent nos modèles, l’inférence — la façon dont nous exécutons les modèles pour générer des sorties — et notre harnais agentique, qu’utilisent Codex et ChatGPT Work.

Alors que nos modèles ont atteint un milliard d’utilisateurs actifs et plus de deux millions d’entreprises au cours des quatre dernières années, l’efficacité a été essentielle pour rendre les avantages de l’intelligence accessibles à tous. Notre mission consiste à faire en sorte que l’intelligence artificielle générale profite à toute l’humanité. Au fil de ces années, nous avons cherché à optimiser continuellement toutes les couches de notre infrastructure afin d’offrir les modèles les plus performants à chaque point de la courbe coût-intelligence. Avec GPT‑5.6, nous avons atteint notre meilleure efficacité à ce jour en matière d’intelligence par token, grâce à un entraînement visant à accomplir plus de travail par token. Durant l’entraînement, nous optimisons à la fois la réussite des tâches et l’efficacité afin que le modèle suive un parcours plus direct pour accomplir une tâche.

Cet article va au-delà de nos modèles pour expliquer comment nous avons favorisé l’efficacité grâce à des avancées dans deux autres grandes composantes de notre infrastructure : 1) l’inférence, en optimisant des processus comme l’équilibrage de charge, le décodage spéculatif, la mise en cache et les noyaux afin de tirer plus de résultats du même matériel; et 2) notre harnais agentique, notamment par une meilleure gestion du gonflement du contexte, de l’utilisation des outils et du travail répétitif. Nous présenterons aussi le rôle joué par GPT‑5.6 Sol dans l’obtention autonome de plusieurs de ces gains. Chaque amélioration prise isolément peut sembler limitée, mais leur effet cumulatif nous permet d’être à la pointe de l’intelligence comme de l’efficacité.

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

Il faut pour cela optimiser l’ensemble du système. Un modèle peut être très efficace pris isolément, mais demeurer coûteux à exploiter si les requêtes sont mal réparties, si le matériel reste inactif ou si le déplacement des données ralentit les calculs. Les améliorations apportées à chaque couche se cumulent : les gains proviennent de l’optimisation du routage (où les requêtes sont envoyées), de l’ordonnancement (quand elles sont envoyées), des noyaux (les logiciels exécutés sur les processeurs graphiques), de la mise en cache (le travail sauvegardé et réutilisé) et de l’implémentation du modèle (l’ordre du code exécuté sur les processeurs graphiques). GPT‑5.6 Sol dans Codex a joué un rôle déterminant dans toutes ces optimisations.

Le premier exemple important est l’équilibrage de charge. À l’échelle mondiale, nous acheminons les requêtes selon des facteurs comme l’emplacement géographique, la capacité disponible et le type d’accélérateur, soit le processeur graphique ou la puce spécialisée qui exécute le modèle. Dans une grappe, 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 jusque-là 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 d’exploitation de nos modèles.

Nous avons aussi utilisé GPT‑5.6 Sol pour optimiser la passe avant du modèle, soit le calcul qui transforme les entrées en prédictions du prochain token. Même lorsque les opérations sont rapides individuellement, des déplacements excessifs en mémoire, la synchronisation et une disposition inefficace des données peuvent laisser les processeurs graphiques inactifs. Pour éviter cela, GPT‑5.6 Sol a repéré du travail pouvant être précalculé, évité ou parallélisé. Avec Codex, GPT‑5.6 Sol a réécrit et optimisé de façon autonome nos noyaux de production, le code central qui exécute les opérations mathématiques constituant le modèle. Cette réussite tient notamment au fait que nous avons entraîné GPT‑5.6 à écrire et à améliorer efficacement des noyaux en Triton⁠(s'ouvre dans une nouvelle fenêtre) et en Gluon⁠(s'ouvre dans une nouvelle fenêtre), deux langages de programmation libres pour processeurs graphiques maintenus par OpenAI. Ces efforts, conjugués aux avancées plus générales de GPT‑5.6 Sol en matière de noyaux, ont réduit de 20 % les coûts d’exploitation de bout en bout. Nous avons également beaucoup investi dans des outils de vérification, comme l’outil libre FpSan⁠(s'ouvre dans une nouvelle fenêtre) (assainisseur de nombres à 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’accroître 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 en parallèle. 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 en menant des centaines d’expériences sur son architecture, notamment sur sa taille, sa structure et ses fonctionnalités. De plus, GPT‑5.6 Sol a lancé et surveillé l’entraînement du spéculateur, intervenant de façon autonome en cas de problème, notamment lors de défaillances matérielles ou d’instabilité de l’entraînement. Les améliorations qui en ont découlé ont accru de plus de 15 % l’efficacité de la génération de tokens.

Lorsqu’il traite des tokens d’entrée non mis en cache, le modèle construit le cache clé-valeur (KV) en une seule passe exigeante en calcul; lorsqu’il génère la sortie, il lit ce cache et l’enrichit de façon répétée. La configuration optimale d’exploitation — notamment le traitement par lots, le partitionnement et la gestion KV — dépend fortement de la charge de travail : longueur de l’invite et de la sortie, taille des lots, taux de succès du cache, caractéristiques des requêtes et plus encore. Toutefois, l’espace de configuration était auparavant trop vaste pour être réglé systématiquement, ce qui obligeait 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 possibles, puis optimiser à l’extrême la configuration du moteur et du modèle pour chaque scénario. Cela rend possible un nouveau degré 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 est un processus continu de rétroaction. Nous mesurons le comportement en production, repérons les principales lacunes, apportons des changements et vérifions qu’ils améliorent l’ensemble du système plutôt qu’un test de performance isolé. GPT‑5.6 Sol et Codex accélèrent chaque étape de ce processus. Notre équipe peut ainsi explorer davantage d’idées, réagir plus vite à l’évolution des charges de travail et créer une infrastructure d’inférence offrant aux utilisateurs une latence et des coûts moindres, ainsi qu’une capacité accrue.

ChatGPT Work et Codex accomplissent des tâches complexes au moyen d’une série de requêtes aux modèles et d’appels d’outils. Au cours d’une seule intervention — de la demande de l’utilisateur à la réponse finale — Codex peut examiner du code source, consulter l’historique de déploiement, 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 exigent tous du temps et des ressources de calcul. Si une tâche nécessite 30 requêtes au modèle, chaque seconde supplémentaire par requête finit par peser lourd. Pour améliorer la performance globale, il faut réduire le travail répétitif dans tout le système, et non seulement 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 maintenant comment éviter le gonflement du contexte, charger les outils et réutiliser le travail afin de rendre chaque requête plus efficace.

À mesure que les agents accèdent à plus d’outils, de compétences, de modules d’extension et d’historique de conversation, les fenêtres contextuelles peuvent facilement s’élargir. Cela augmente les coûts, distrait le modèle et entraîne 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, les outils MCP personnalisés, les compétences et les modules d’extension qu’au besoin. Le harnais empêche aussi les outils et les intégrations MCP de consommer une part imprévue de la fenêtre contextuelle. 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 processeurs graphiques les mêmes instructions, l’historique de conversation, les définitions d’outils et les résultats antérieurs au cours d’une seule intervention. Le traitement de ces entrées répétées est coûteux. La mise en cache des invites réutilise donc les calculs associés au préfixe d’une invite déjà traitée. Pour préserver ce préfixe, le harnais traite tout l’historique visible par le modèle comme un journal en ajout seulement : les nouveaux messages, résultats d’outils et changements d’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 pendant 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 de la mise en cache des invites dans Codex et ChatGPT Work.

Les gains d’efficacité apportés par GPT‑5.6 résultent d’années d’améliorations cumulées dans l’ensemble de notre infrastructure, de la recherche à l’inférence en passant par notre harnais agentique. Le rôle de GPT‑5.6 dans bon 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 infrastructure. Nous avons hâte de faire profiter nos utilisateurs et nos clients de ces améliorations continues en coulisses, sous la forme d’une intelligence plus accessible et plus économique.

Un merci tout spécial à Matthew Ferrari, Philippe Tillet, Ahmed Ibrahim, Joe Gershenson et Steve Coffey, membres du personnel technique, pour leur contribution à cet article.