L’essentiel
- OpenAI a appliqué son modèle GPT-5.6 Sol, une fois déployé, aux kernels GPU de sa propre infrastructure de production.
- L’entreprise annonce 20 % de coûts de service en moins, et mentionne un second gain chiffré à 15 % ou plus.
- Le même travail a été mené dans Codex, sur l’inférence et la boucle d’agent : plus de travail utile à matériel constant.
GPT-5.6 Sol venait d’être déployé en production. OpenAI l’a aussitôt braqué sur une cible inhabituelle : les kernels GPU qui le font tourner, ces programmes de bas niveau qui exécutent les calculs sur les cartes graphiques. Mercredi soir, l’entreprise a publié dans un fil sur X le résultat obtenu sur son parc de production : 20 % de coût de service en moins.
L’auto-amélioration a changé de terrain
Depuis des années, on imagine l’auto-amélioration du côté de l’intelligence : un modèle qui concevrait une meilleure architecture, trouverait de meilleures données, entraînerait son successeur. Ici, rien de tel. GPT-5.6 Sol n’a pas redessiné son successeur, il a réécrit du code d’exécution : les kernels de production, l’inférence, la boucle d’agent, ce cycle où le modèle enchaîne seul ses actions. L’entreprise précise avoir mené ce travail dans Codex, son environnement de programmation agentique, et en résume l’effet d’une formule : produire davantage de travail utile avec le même matériel.
OpenAI n’est pas seul sur ce créneau. Google DeepMind exploite depuis 2025 AlphaEvolve, un agent piloté par Gemini qui a accéléré de 23 % un kernel de multiplication matricielle utilisé pour entraîner Gemini, soit 1 % de temps d’entraînement en moins. La différence tient au poste visé : Google a d’abord allégé sa facture d’entraînement, quand OpenAI s’attaque à celle du service, c’est-à-dire à ce que coûte chaque requête envoyée par un utilisateur.
La compétence n’a rien à voir avec l’invention scientifique. Optimiser un kernel, c’est un problème fermé et mesurable, au verdict immédiat : le calcul est plus rapide, ou il ne l’est pas. Exactement le type de tâche où un agent excelle et où l’ingénieur humain coûte cher, parce qu’il faut essayer des milliers de variantes pour en garder trois.
Le modèle s’attaque à sa propre facture
Voilà pourquoi l’annonce compte davantage que la performance affichée. Jusqu’ici, la baisse du coût d’un token, l’unité de facturation de ces modèles, dépendait d’un événement extérieur : une nouvelle génération de modèle, une nouvelle génération de cartes, une nouvelle grille tarifaire. Une marche d’escalier, calée sur le calendrier des lancements.
Si un modèle déjà en service peut réduire son propre coût d’exploitation, la mécanique change de nature. Chaque génération devient un outil d’optimisation appliqué à elle-même, et les gains s’empilent entre deux lancements au lieu d’attendre le suivant. OpenAI le dit sans détour : ces optimisations s’additionnent à tous les étages de son infrastructure, de quoi servir le meilleur modèle possible à chaque niveau de prix. Le même fil annonce un second gain, supérieur à 15 % sur la génération de tokens. Il vient d’un décodage spéculatif amélioré : un modèle plus petit propose plusieurs tokens d’avance, que le grand valide d’un bloc au lieu de les produire un par un.
Les deux leviers visent la même dépense, ce que coûte une requête servie. À supposer qu’ils se cumulent, la facture retomberait autour des deux tiers de son niveau initial, sans avoir touché au modèle.
Des baisses de tarif hors lancement, dès 2027
D’ici fin 2027, les baisses les plus significatives sur les tarifs des API, ces accès aux modèles facturés à l’usage, ne tomberont plus le jour d’un lancement : elles arriveront entre deux lancements, sur des modèles déjà au catalogue. On imagine mal OpenAI financer ce travail sans le convertir en argument commercial, tarif à l’appui.
Deux conditions à ce scénario. D’abord que les gains se répètent : un tour d’optimisation à 20 % est un joli coup, trois tours consécutifs à 15 % constituent un régime industriel. Ensuite qu’ils redescendent jusqu’au client, ce qui n’a rien d’automatique : un coût de service n’est pas un prix, et la marge peut très bien absorber la différence pendant deux ans.
Pour une équipe dont la facture dépend de ces API, trois réflexes changent :
- ne calez plus vos projections de coût sur la sortie du prochain modèle, mais sur un réexamen semestriel des modèles déjà en place ;
- surveillez les changements de tarif ou de latence sans annonce de version : c’est là que ce type d’optimisation se manifeste ;
- rejouez vos arbitrages entre modèle auto-hébergé et API à chaque mouvement de grille, l’écart de coût devient mobile en cours d’année.
La boucle s’essouffle à chaque tour
Ces chiffres sont maison, sans vérification indépendante, et le périmètre reste flou : on ne sait ni quelle part du parc est concernée, ni sur quelles charges le gain a été mesuré. Le mécanisme, lui, a une limite intrinsèque plus intéressante : les grosses inefficacités partent en premier. Un code déjà passé au crible offre moins de prise au tour suivant.
S’ajoute une dépendance matérielle rarement soulignée. Un kernel taillé pour une génération de GPU perd une partie de sa valeur au changement de génération, et le travail se rejoue à chaque migration, au bénéfice du fabricant de puces dominant. L’efficacité gagnée reste locataire du matériel.
Vient enfin l’asymétrie, sans doute l’effet le plus durable : la manœuvre n’est jouable que par un acteur qui possède à la fois un modèle de premier plan et son infrastructure. Une jeune entreprise qui loue son inférence n’a pas ce levier : sa structure de coûts dépend des optimisations de son fournisseur, et de sa décision de les partager ou non.
La grille tarifaire tranchera. Une baisse en dehors de tout lancement dans les prochains mois, et la boucle est bien réelle, déjà industrialisée ; ces 20 % restés une annonce sans suite, et la démonstration technique n’aura rien changé au régime économique. Une inconnue plus discrète mérite autant d’attention : ces kernels optimisés resteront-ils un actif interne, ou remonteront-ils dans les briques logicielles ouvertes que tout le monde utilise, Triton et PyTorch en tête ? Dans le premier cas, OpenAI creuse un fossé ; dans le second, l’écosystème entier gagne quelques points d’efficacité au passage.
Mon avis
Ces 20 % ont une date de péremption, et c’est précisément ce qui m’intéresse. Un parc de kernels mal réglés, ça se récolte une fois : le tour suivant rapportera moins, et le suivant encore moins, jusqu’à ce qu’une nouvelle génération de cartes remette du gras à retirer. Mon pronostic pour 2027 : l’avantage concurrentiel se jouera sur la vitesse à laquelle un propriétaire de modèle sait le retourner contre sa propre infrastructure, bien plus que sur son score aux benchmarks. Et ce jour-là, les entreprises qui louent leur inférence constateront qu’elles ne rattrapent pas un écart de coût qu’elles n’ont aucun moyen de produire elles-mêmes.
