Avertissement sur l’inférence agentique des LLM : les laboratoires divisent la latence par deux et réduisent les coûts de 83 %

OpenAI avertit que l’inférence agentique des LLM transforme une seule demande utilisateur en plusieurs appels au modèle, ce qui augmente les coûts et la latence, alors que les laboratoires réduisent la latence des modèles de près de moitié et les coûts de 83 %.
L’inférence agentique des LLM consiste à faire accomplir une tâche en plusieurs étapes à un modèle de langage à l’aide d’outils, de nouvelles tentatives et d’une mémoire, au lieu de lui demander une seule réponse. Une demande utilisateur se transforme ainsi en plusieurs appels au modèle. Des données publiées montrent désormais que les laboratoires réduisent la latence des modèles de près de moitié et les coûts de 83 % dans certaines offres d’API, et qu’ils repensent leurs systèmes de service pour rendre ces chaînes plus longues utilisables en production.
En bref
Les systèmes agentiques ne sont pas simplement des « clavardages, mais en plus grand ». Ils multiplient les jetons, les temps d’attente et les points de défaillance, car une tâche se transforme souvent en plan, en plusieurs appels d’outils, en une ou plusieurs vérifications, puis en au moins une réponse finale.
Le principal facteur de coût est généralement le décodage, l’étape où un modèle génère les jetons un à un. C’est pourquoi la bande passante mémoire, la politique de traitement par lots et la longueur des sorties comptent autant que la puissance de calcul brute.
La configuration de production fiable la moins coûteuse est souvent hybride : des modèles plus petits pour le routage, l’extraction et la vérification, des modèles plus grands réservés aux étapes difficiles, et une télémétrie rigoureuse permettant aux équipes de détecter les nouvelles tentatives, le temps d’attente dans les files et les erreurs d’outils avant que les factures ne s’envolent.
Pourquoi l’inférence des LLM agentiques est différente
Un appel classique à un chatbot est simple : une requête est envoyée et une réponse est reçue. L’inférence des LLM agentiques exige plutôt que le modèle planifie, choisisse un outil, appelle un système de recherche ou une base de données, lise les résultats, révise son plan, puis réponde à l’utilisateur, ce qui multiplie les appels au modèle et les interactions avec les outils.
Cette structure supplémentaire entraîne une hausse des coûts. L’appel direct au modèle ne représente qu’une partie de la facture. Le temps passé à attendre les outils, les jetons utilisés pour décrire au modèle les résultats des outils, les appels supplémentaires lorsque l’agent vérifie son propre travail et les nouvelles tentatives en cas d’échec d’une étape s’ajoutent aux coûts et à la latence de queue.
L’article sur le raisonnement dynamique a montré que les distributions de latence de bout en bout d’un système agentique de type ReAct différaient considérablement de celles d’un service classique non agentique. Autrement dit, la queue de distribution s’allonge. Un utilisateur peut obtenir rapidement un résultat médian, mais les requêtes les plus lentes le deviennent beaucoup plus.
La conséquence pratique est simple : l’unité de travail n’est plus une seule requête, mais un flux de travail. Selon l’analyse de Fathom, les équipes qui ne mesurent que le coût moyen par appel au modèle risquent de passer à côté de la véritable économie de l’inférence des LLM agentiques.
Le budget de latence se perd en cours de route
La plupart des gens associent la latence à la vitesse du modèle. En production, la latence se répartit entre plusieurs postes : le routage des requêtes, la mise en file d’attente, la préparation des requêtes, le préremplissage, le décodage, les appels d’outils, les vérifications de sécurité et le post-traitement. Les agents sont plus lents parce qu’ils ajoutent des étapes intermédiaires, et pas seulement parce que le modèle lui-même est plus lent.
Dans son guide sur la latence, OpenAI a indiqué que les principaux leviers étaient le choix du modèle et le nombre de jetons générés. Si un agent produit une longue chaîne de raisonnement, des schémas d’outils, du JSON, des résultats d’outils et une explication finale, la longueur de sortie devient un coût à la fois en temps et en argent.
Les équipes optimisent souvent la formulation des requêtes, mais négligent l’orchestration. Une requête bien réglée ne peut pas sauver un système qui attend 400 millisecondes pour le routage, 800 millisecondes pour un outil de recherche, 1 seconde pendant que le modèle lit le résultat de l’outil et une seconde de plus pour que le modèle vérificateur contrôle la réponse.
Dans de nombreux systèmes réels, le modèle n’explique pas à lui seul tout le délai. Il n’en est que la partie la plus visible, tandis que la surcharge d’orchestration se répercute directement sur les coûts de l’inférence des LLM agentiques.
Répartissez le temps d’attente de l’utilisateur entre deux objectifs de service. La latence avant le premier jeton correspond à la rapidité avec laquelle le système semble réagir. Le délai jusqu’à la réponse finale correspond à ce que les utilisateurs remarquent lorsqu’une tâche doit aboutir à un résultat complet. Pour le service à la clientèle ou l’aide au codage, la diffusion en continu peut masquer une partie du délai. Pour les agents de navigation ou les robots de flux de travail qui doivent agir avant de parler, elle est moins utile. Ces compromis sont essentiels à la conception de l’inférence des LLM agentiques.
Si une requête utilisateur déclenche quatre appels au modèle, une amélioration de 15 % du modèle ne se traduit pas par une amélioration de 15 % du système, à moins que ce modèle domine l’ensemble du processus. OpenAI a indiqué que GPT-4.1 égalait ou surpassait GPT-4o dans les évaluations d’intelligence, tout en réduisant la latence de près de moitié et les coûts de 83 %. Cet exemple montre comment des améliorations simultanées de la vitesse et du prix peuvent transformer les choix d’architecture pour l’inférence des LLM agentiques.
Le décodage est la partie coûteuse
Deux étapes dominent l’inférence des transformeurs : le préremplissage (lorsque le modèle lit la requête et construit son état interne) et le décodage (lorsqu’il génère la sortie jeton par jeton). Les agents sont souvent pénalisés au décodage, car chaque phrase de planification, argument d’outil et explication finale supplémentaire prolonge la phase la plus lente.
Le décodage est généralement limité par la mémoire. La puce passe souvent plus de temps à déplacer les poids du modèle et les données du cache clé-valeur qu’à effectuer des calculs bruts. C’est pourquoi une bande passante mémoire plus élevée est si utile pendant la génération et pourquoi les arguments marketing axés uniquement sur la puissance de calcul de pointe peuvent induire les acheteurs en erreur. AMD a écrit que la mémoire à large bande passante était importante pour la phase de décodage.
Les agents pâtissent d’une mauvaise maîtrise de la longueur des sorties. Une trace de raisonnement cachée, si elle est matérialisée dans la sortie ou sérialisée dans les requêtes ultérieures, entraîne deux fois des coûts : une première fois pour l’écrire, puis une deuxième fois lorsque les appels suivants la relisent. Cet effet augmente les coûts opérationnels de l’inférence des LLM agentiques.
Le même raisonnement explique pourquoi les petits modèles peuvent être plus rentables que les grands dans les flux de travail, même s’ils obtiennent de moins bons résultats dans les tests de référence les plus médiatisés. L’article sur les petits modèles de langage soutenait que ceux-ci convenaient bien à de nombreuses sous-tâches agentiques. Le routage, l’extraction, la synthèse, la réparation de schémas et les vérifications simples sont souvent des tâches ciblées pour lesquelles un modèle haut de gamme est surdimensionné.
Pour l’inférence des LLM agentiques, choisir le bon modèle pour chaque sous-tâche compte souvent davantage que de sélectionner le meilleur modèle unique pour tout faire. Une formule approximative peut aider. Le coût total d’une requête d’agent est égal à :
Coût total = somme des coûts des jetons de tous les appels aux modèles + gaspillage de calcul dû aux temps d’attente inactifs + coûts des appels d’outils + coûts des nouvelles tentatives + frais généraux liés à la sécurité et à la journalisation. La plupart des équipes ne voient que le premier terme, car c’est celui qui figure sur la facture de l’API.
Les exploitants qui hébergent eux-mêmes leurs modèles surveillent l’utilisation des GPU, mais peuvent ne pas remarquer qu’un outil lent laisse l’accélérateur sous-utilisé alors que l’utilisateur attend toujours. Une bonne économie des agents consiste à utiliser efficacement les jetons et à veiller à ce que le système reste actif au lieu de tourner au ralenti.
Les choix matériels fixent le plafond
Le matériel ne décide pas de tout, mais il fixe les limites supérieures des économies et de la vitesse qu’un service peut atteindre. Un mauvais choix de matériel peut enfermer une équipe dans un modèle économique défavorable bien avant que les requêtes ou l’orchestration ne soient optimisées, en particulier pour les charges de travail d’inférence de LLM agentiques, dominées par le décodage et sujettes à des pointes d’activité.
Nvidia a déclaré que le Transformer Engine du H100 pouvait augmenter jusqu’à 30 fois le débit d’inférence — autrement dit, la quantité de travail effectuée par seconde — pour les applications à faible latence. Ce chiffre spectaculaire dépend de la charge de travail, et les équipes ne devraient pas supposer qu’il s’applique directement à leur infrastructure. Il montre toutefois pourquoi les générations de matériel peuvent transformer l’économie d’un système par bonds soudains plutôt que de façon progressive.
Nvidia a également fait état de meilleurs résultats en inférence avec les H100, L4 et Orin dans MLPerf. La leçon à retenir pour la production est que différents usages nécessitent différents types de puces. Les composants de classe L4 peuvent convenir aux charges de travail légères ou sensibles aux coûts, tandis que ceux de classe H100 sont adaptés aux exigences strictes de latence, aux grands modèles ou à une forte simultanéité.
Le guide de service pour H100 et TensorRT-LLM a révélé un compromis essentiel : configurer les serveurs pour le débit (davantage de travail par seconde) ou pour la latence (des réponses individuelles plus rapides). Le traitement par lots intensif réduit le coût unitaire, mais augmente le temps d’attente. Les petits lots préservent la réactivité, mais réduisent l’utilisation du matériel. Ce compromis est encore plus marqué pour l’inférence des LLM agentiques, car les arrivées de requêtes sont irrégulières et de nombreux appels successifs sont brefs et imprévisibles.
Le matériel de remplacement compte surtout lorsque la charge de travail est spécialisée ou que l’alimentation électrique est limitée. Hugging Face a indiqué qu’AWS Inferentia2 mise sur le débit, la latence, les performances par watt et la capacité à passer à l’échelle. AMD a annoncé des options de partitionnement de GPU et affirmé que sa gamme de FPGA équipés de HBM offre une bande passante mémoire de 460 Gb/s. Ces options sont avantageuses pour des déploiements spécialisés, mais comptent généralement moins pour les services d’inférence de LLM agentiques à usage général.
L’enjeu économique est concret pour l’inférence des LLM agentiques. Lorsque le décodage domine, la bande passante mémoire et le comportement du cache ont une incidence directe sur le débit de génération et les coûts. Lorsque les charges de travail sont irrégulières et comportent plusieurs étapes, des fonctionnalités comme le partitionnement, le contrôle précis des files d’attente et l’ordonnancement optimisé pour la latence sont importantes.
Et à très grande échelle, les performances par watt deviennent un poste de dépense réel, car les coûts énergétiques s’accumulent avec l’inférence continue. Ce sont ces leviers de production qui influent davantage sur l’économie des agents que les tableaux comparatifs des fournisseurs.
La conception des modèles l’emporte désormais sur la puissance brute
Les récentes informations publiées par les fournisseurs suggèrent que les gains les plus importants proviennent d’une co-conception plus étroite du modèle et du système de service, et non de la seule mise à l’échelle d’un modèle. OpenAI a déclaré que servir GPT-5.5 avec la latence de GPT-5.4 nécessitait de repenser l’inférence comme un système intégré. L’entreprise a également écrit que GPT-5.6 associait des capacités de pointe à une pile à latence réduite, à une capacité accrue et à des coûts plus faibles pour les utilisateurs.
Ces déclarations montrent que les modèles sont désormais évalués en partie selon le coût de leur mise en service, un changement important pour l’inférence des LLM agentiques. Si un modèle conserve sa qualité tout en devenant beaucoup plus rapide, l’exploitant peut répercuter les économies sous forme de prix plus bas, les réinvestir dans une utilisation accrue des outils et des auto-vérifications, ou améliorer ses marges.
Pour les acheteurs du secteur, l’option intermédiaire — consacrer les économies à une deuxième étape de validation — peut améliorer la fiabilité davantage qu’elle ne réduit les coûts, en particulier dans les pipelines d’inférence de LLM agentiques. Les modèles à poids ouverts ajoutent une autre dimension. OpenAI a présenté gpt-oss-120b et gpt-oss-20b comme des options à poids ouverts moins coûteuses. Pour les exploitants dont le trafic est régulier, les charges de travail prévisibles et les équipes d’infrastructure solides, les poids ouverts peuvent améliorer l’économie en évitant les suppléments par jeton des API.
Mais ils transfèrent les risques à l’interne. L’équipe devient responsable de la disponibilité, des mises à niveau, des bogues du noyau, du réglage de la mémoire et de la sécurité, autant d’éléments qui influent sur la fiabilité et le coût de l’inférence des LLM agentiques.
Le seuil de rentabilité de l’auto-hébergement évolue. À mesure que l’efficacité des modèles s’améliore, la taille de la charge de travail nécessaire pour justifier la prise en charge de son propre chemin de service diminue. Les produits agentiques affectés à des tâches internes stables, comme l’extraction de données de factures ou les vérifications de code, peuvent atteindre ce seuil plus tôt que les applications de clavardage grand public dont la demande varie fortement.
Figure ou affirmation Pourquoi c’est important en production Source Jusqu’à 30 fois plus de débit d’inférence pour les applications à faible latence avec le Transformer Engine du H100 Montre à quel point les changements de matériel et de noyau peuvent influer sur l’économie du service Blog Nvidia sur le H100 GPT-4.1 a réduit la latence de près de moitié et les coûts de 83 % par rapport à GPT-4o Exemple d’amélioration simultanée du prix et de la vitesse qui transforme la conception d’un produit Article d’OpenAI sur GPT-4.1 GPT-5.5 servi avec la latence de GPT-5.4 Indique une refonte du service à l’échelle du système, et pas seulement un meilleur modèle de base Article d’OpenAI sur GPT-5.5 gpt-oss lancé en versions 120B et 20B Offre un éventail plus large pour orienter les petites tâches vers des modèles moins coûteux Article d’OpenAI sur gpt-oss La gamme de FPGA d’AMD annonce une bande passante HBM de 460 Gb/s Confirme que le déplacement de la mémoire est essentiel dans les charges de travail dominées par le décodage Page d’AMD sur les FPGA
À lire aussi : OpenAI verrouille l’entraînement de l’IA, alors que le vol de modèles coûte presque zéro
Les logiciels de service déterminent le taux d’utilisation
Une fois le matériel acheté et le modèle choisi, ce sont souvent les logiciels de service qui déterminent si l’exploitation est rentable pour l’inférence des LLM agentiques. Le traitement par lots, la réutilisation du cache clé-valeur, la pagination mémoire et l’ordonnancement des requêtes déterminent le taux d’utilisation. vLLM s’est présenté comme un moteur d’inférence et de service capable de traiter de nombreuses requêtes et d’utiliser efficacement la mémoire.
Son essor reflète une réalité du secteur : le modèle ne suffit pas à lui seul. Les exploitants ont besoin de logiciels qui regroupent de nombreuses requêtes sur le même matériel sans dépasser les objectifs de latence.
Pour l’inférence des LLM agentiques, cela signifie gérer de brèves pointes d’activité, des longueurs de sortie variables et de nombreuses sessions qui reprennent après des appels d’outils. Le décodage spéculatif est largement évoqué dans les piles de service. Un modèle brouillon plus petit prédit plusieurs jetons suivants, puis un modèle plus grand les vérifie afin de réduire le temps de génération.
En pratique, l’article sur le traitement par lots des agents a conclu que le décodage spéculatif pouvait nuire à l’inférence par lots pour les charges de travail agentiques et même être plus lent que le décodage autorégressif classique. Le trafic des agents est irrégulier et le modèle est souvent interrompu par des outils, ce qui influe sur les performances de l’inférence des LLM agentiques.
La politique de gestion des files d’attente a des conséquences économiques. Si une couche de service attend trop longtemps pour constituer des lots plus importants, les coûts diminuent, mais le délai pour l’utilisateur augmente. Si elle traite chaque requête immédiatement, le délai diminue, mais le matériel reste en partie inactif.
Pour l’inférence des LLM agentiques, un bon ordonnancement consiste souvent à classer les requêtes selon leur longueur et leur urgence prévues, afin que les minuscules étapes d’extraction n’attendent pas derrière de longues générations de code et que les appels de vérification bénéficient d’exigences de latence plus strictes. Le travail du processeur compte davantage que ne le pensent beaucoup d’équipes. L’article consacré aux processeurs a montré que l’inférence des agents comporte d’importants goulots d’étranglement côté processeur et a abordé le choix de la taille des lots pour des charges de travail comme LangChain, Haystack et SWE-Agent.
Les professionnels voient la génération de jetons sur les accélérateurs, tandis que la préparation des requêtes, l’orchestration des outils, la sérialisation et la journalisation sollicitent d’abord le processeur. Dans l’inférence des LLM agentiques, un système mal équilibré peut gaspiller des GPU coûteux, tandis qu’une couche de processeurs moins onéreuse devient le goulot d’étranglement.
La télémétrie fait désormais partie du produit
On ne peut pas maîtriser ce que l’on ne mesure pas, et les agents créent trop de chemins cachés pour qu’on puisse fonctionner à l’aveugle. Pour l’inférence des LLM agentiques, les traces détaillées de chaque étape, la latence du planificateur, le taux de réussite des appels d’outils, la taille des données transmises aux outils, le taux de désaccord des vérificateurs, le nombre de tentatives et le temps total écoulé entre le clic de l’utilisateur et l’achèvement de la tâche sont donc essentiels.
Une requête qui prend 6 secondes n’est pas exploitable si l’opérateur ne sait pas si 4 secondes ont été consacrées à une recherche sur le Web, 1 seconde à l’attente dans une file et 1 seconde à la génération du modèle. Si la même requête a utilisé trois modèles et un système de recherche d’information, l’équipe doit disposer d’une trace couvrant chacun d’eux.
La discussion sur la télémétrie dans vLLM portait sur son ajout par défaut pour les interfaces en ligne de commande et l’utilisation de Docker, avec des options permettant de la désactiver. Même au niveau des services open source, la tendance est claire. Les opérateurs veulent connaître les habitudes d’utilisation réelles, et pas seulement consulter des graphiques de référence, car ces informations comptent pour la fiabilité et les coûts. Si 15 % des tâches sont relancées à cause d’un schéma JSON défectueux, la facture augmente avant même que le client comprenne pourquoi.
Une bonne télémétrie influe aussi sur le choix du modèle. Les traces peuvent révéler que la plupart des coûts proviennent d’étapes de classification à faible valeur qui pourraient être confiées à un modèle plus petit, ou l’inverse. Un planificateur moins cher peut entraîner suffisamment de nouvelles tentatives en aval pour que l’ensemble du processus coûte davantage.
Les meilleurs produits agentiques considèrent désormais l’observabilité comme une composante de l’expérience utilisateur, afin que les équipes d’exploitation puissent déterminer si une tâche lente est imputable à la formulation de la requête, au routage, à un outil, à l’ordonnanceur ou au modèle.
Méthodologie
Cet article a examiné l’ingénierie et l’économie de l’inférence des LLM agentiques à partir de la documentation publique et d’articles de Nvidia, OpenAI, AMD, Hugging Face, du projet vLLM et d’arXiv portant sur la latence des agents et le comportement des services. Toutes ces sources provenaient du corpus fixe fourni pour le mardi 27 octobre 2026.
L’analyse s’est concentrée sur quatre couches : le matériel, l’efficacité côté modèle, les logiciels de service et la télémétrie. Elle a recherché des données concrètes sur la vitesse, les coûts, la taille des modèles, la bande passante mémoire et les compromis architecturaux.
Lorsqu’une source indiquait une mesure relative, comme « une latence presque divisée par deux » ou « une baisse des coûts de 83 % », cette mesure est rapportée telle quelle. Lorsqu’aucune source publique du corpus ne fournissait de valeurs précises en dollars par jeton ou en millisecondes pour une configuration de production donnée, l’article n’en a pas inventé.
Les données sont lacunaires sur trois points. Premièrement, la plupart des laboratoires ne publient pas le détail complet des coûts des charges de travail agentiques, notamment ceux liés aux nouvelles tentatives et aux échecs d’outils.
Deuxièmement, les résultats des tests de performance des fournisseurs ne correspondent pas directement au trafic mixte du monde réel. Troisièmement, la télémétrie open source reste fragmentée, ce qui complique les comparaisons entre systèmes. On obtient donc un aperçu de la production étayé par de solides indications générales et un nombre limité de données publiques précises, plutôt qu’une grille tarifaire universelle pour l’inférence des LLM agentiques.
Le contre-argument
Le meilleur argument contre la thèse selon laquelle « les agents sont intrinsèquement coûteux » est que nombre de ces coûts sont temporaires. L’efficacité des modèles s’améliore rapidement. Des modèles plus petits et mieux adaptés au routage peuvent prendre en charge une grande partie du flux de travail. Les logiciels de service deviennent plus efficaces pour le traitement par lots et la gestion du cache. Certaines tâches agentiques permettent aussi d’économiser suffisamment de main-d’œuvre pour que, même avec une facture d’inférence élevée, le compromis reste avantageux dans les déploiements d’inférence de LLM agentiques.
OpenAI a annoncé à plusieurs reprises des gains de vitesse et des réductions de coûts pour ses nouveaux modèles. Les options à poids ouverts s’améliorent. Les fournisseurs de matériel continuent d’élargir les limites des performances. Si un flux de travail remplace trente minutes de travail humain, le modèle peut être lent ou coûteux en valeur absolue tout en restant économiquement avantageux.
Il existe aussi un argument technique. Si les modèles continuent de s’améliorer, le nombre d’étapes pourrait diminuer, et un futur modèle pourrait moins expliciter son plan, appeler moins d’outils et nécessiter moins de vérifications. Dans ce scénario, le surcoût lié aux agents dans l’inférence des LLM agentiques diminue, car le flux de travail lui-même se raccourcit.
Cet argument mérite d’être pris au sérieux. Pourtant, les données publiées à ce jour suggèrent que ces gains ne supprimeront pas les compromis fondamentaux. Les modèles améliorés réduisent le coût par étape, mais de nombreuses équipes produit réagissent en ajoutant des étapes, des vérifications plus poussées et des outils plus riches. Les gains d’efficacité sont souvent dépensés plutôt qu’économisés. Il est donc probable que la cible continue de bouger et que la rigueur reste déterminante pour l’économie de l’inférence des LLM agentiques.
À quoi ressemble une bonne mise en production
Les meilleures configurations de production savent quelles tâches méritent quel modèle, combien de temps chaque étape devrait prendre et à quel moment cesser d’engager des dépenses. Pour l’inférence des LLM agentiques, le schéma durable est clair : utiliser un modèle petit ou de taille moyenne pour le routage, l’extraction, la création d’arguments d’outils et les vérifications simples. Réserver le modèle le plus performant à la synthèse ouverte, au raisonnement ambigu ou aux actions à haut risque.
Garder les sorties courtes, sauf si les utilisateurs ont réellement besoin de détails. Fixer des limites strictes aux nouvelles tentatives. Utiliser intensivement la mise en cache lorsque le même contexte se présente de nouveau. Consigner chaque étape afin de regrouper les échecs selon leur cause plutôt que dans de vagues catégories de « requêtes lentes ». Choisir le bon objectif de service. Certains produits doivent fournir rapidement la première action utile ; d’autres doivent garantir une exécution déterministe.
Les exploitants dont le modèle économique est le plus solide considéreront la conception des agents comme de l’ingénierie des systèmes, et non comme un simple travail de formulation de requêtes. Ils poseront tôt des questions opérationnelles. Quel pourcentage des requêtes appelle un outil ? Quel outil échoue le plus souvent ? Combien de jetons ne servent qu’aux vérifications internes ? Quel est le temps de bout en bout au 95e centile ? Combien de nouvelles tentatives ont lieu avant le transfert à un humain ? Les réponses influent sensiblement sur le coût et la fiabilité de l’inférence des LLM agentiques.
Conclusion
Deux éléments sont à surveiller : davantage de lancements publics de modèles qui améliorent à la fois la vitesse et les coûts, ainsi qu’une meilleure télémétrie ouverte pour les flux de travail à plusieurs étapes. Ces deux avancées sont essentielles pour faire de l’inférence des LLM agentiques un logiciel courant plutôt qu’une démonstration coûteuse. Les équipes gagnantes feront probablement moins appel aux grands modèles, et non davantage. Elles ne consacreront une inférence haut de gamme qu’aux étapes qui changent le résultat, et rendront toutes les autres plus petites, plus courtes et plus faciles à mesurer.
À lire ensuite : l’IA de DeepSeek pourrait coûter moins cher grâce à une réduction de 75 % de sa consommation mémoire par des chercheurs