Revue de Presse IA

AI Press Review : coûts, vitesse et conditions de comparaison

David Perron | Aequitas Consultus
Édition documentaire arrêtée au 13 septembre 2026. Version française, 13 min 25 s.

S’abonner à la chaîne YouTube · Suivre sur Apple Podcasts

Transcription

Bonjour. Cognition annonce un nouveau modèle de programmation et des coûts nettement inférieurs sur certains tests. AWS cherche de son côté à accélérer le démarrage des modèles et le traitement des requêtes. Mais que mesurent vraiment ces progrès ? Dans cette revue du samedi, je vous propose de regarder les résultats, leurs conditions de validité et les détails qui peuvent changer une décision d'achat. Nous passerons ensuite aux signaux faibles, puis aux informations moins visibles dans les documents techniques.

Cognition présente SWE-2 avec un score annoncé de 50,0 % sur FrontierCode 1.1 Main. Le modèle se situe à moins de 1 point de Fable 5.1, pour un coût annoncé inférieur de 64 %. Il s'agit des résultats publiés par le développeur. La comparaison associe des scores publics et des évaluations internes. Les modèles utilisent des environnements d'exécution différents, choisis pour chacun, avec leur meilleur réglage de raisonnement. Le calcul des coûts retient les tarifs affichés, remises publiques comprises. Pour moi, SWE-2 mérite donc un essai sur des tâches de programmation pertinentes. L'économie annoncée reste à vérifier avec vos propres outils, vos prix et vos critères d'acceptation.

AWS introduit une mise en cache des modèles pour Amazon SageMaker Inference sur HyperPod. Le mécanisme prépare les poids des modèles et les images de leurs conteneurs sur les nœuds du cluster, avant le démarrage des processus. AWS évoque des lectures locales d'environ 7 gigaoctets par seconde. Lorsque le cache est prêt, le service peut généralement démarrer en quelques secondes, plutôt qu'en plusieurs dizaines de minutes. Mais ce débit concerne l'accès aux fichiers. Il ne mesure pas la vitesse complète d'une réponse de l'IA. Si une montée en charge mobilise un nœud non préparé, les téléchargements distants restent nécessaires. Un test de capacité doit donc inclure cette situation, au-delà du seul démarrage idéal.

Autre changement chez AWS : le routage des requêtes selon leur préfixe commun dans Amazon SageMaker. Des demandes qui commencent de la même manière peuvent rejoindre la même instance. Celle-ci réutilise alors les calculs déjà réalisés sur ce contexte partagé. Sur un test avec Llama 3.1 70B, AWS annonce jusqu'à 77 % de réduction du délai médian avant le premier token, et jusqu'à 16 % de débit supplémentaire. Le gain dépend notamment de la longueur du préfixe commun. En cas de surcharge, la protection peut envoyer une requête ailleurs et perdre le bénéfice du cache. Pour évaluer ce mécanisme, il faut donc tester le contexte répété et la charge simultanée, ensemble.

NVIDIA décrit également le projet de d-Matrix : connecter des processeurs spécialisés dans l'inférence avec NVLink, et faire fonctionner leurs racks aux côtés de systèmes équipés de GPU NVIDIA. L'approche vise à répartir différentes parties du travail d'inférence entre ces équipements. L'intérêt commercial serait de combiner des processeurs spécialisés dans une infrastructure commune. Le document évoque toutefois plusieurs intégrations supplémentaires comme des projets, notamment pour les processeurs et les réseaux. Il donne donc matière à examiner une feuille de route. Il ne suffit pas à établir que l'ensemble de cette combinaison fonctionne déjà en production, ni à chiffrer une économie pour l'utilisateur.

Côté sécurité, Simon Willison publie une nouvelle analyse sur un possible lien entre des agents OpenAI et un incident plus ancien concernant RubyGems, survenu en mai. Son argument d'attribution s'appuie en particulier sur des ressemblances dans les fichiers consultés et les techniques employées. Il distingue cependant ce rapprochement du résultat de l'attaque : le succès des tentatives de vol de clés d'API reste incertain dans son analyse. Ce qui entre dans notre fenêtre de revue, c'est donc cette nouvelle analyse, pas une nouvelle attaque. Pour un professionnel, la distinction compte. Des indices sur la responsabilité possible ne prouvent pas, avec la même assurance, que l'objectif de l'attaque a été atteint.

Passons aux signaux faibles. Les documents retenus font ressortir les questions suivantes pour les évaluations d'IA : le coût d'une tâche agentique complète, et la configuration réelle derrière le nom d'un modèle. J'y vois des points d'attention documentés pour les achats et les tests, sans prétendre qu'ils décrivent déjà une évolution générale du marché.

Dans son étude sur les modèles OpenAI accessibles via Amazon Bedrock, AWS décrit un dispositif où le client conserve l'historique de la conversation. À chaque tour, il renvoie les instructions, les résultats des outils et le contexte accumulé. Dans cette configuration, si le contexte augmente à peu près régulièrement, le volume total d'entrée peut croître approximativement comme le carré du nombre de tours. Chaque échange ajoute aussi un aller-retour. Le prix d'une requête isolée ne suffit donc pas à expliquer la facture d'une tâche longue. Mais cette observation reste liée au dispositif étudié. Elle ne permet pas d'affirmer que toutes les architectures d'agents gèrent leur historique de cette manière.

Cognition apporte une observation distincte sur ce même sujet. Sur FrontierCode 1.1 Main, SWE-2 au niveau de raisonnement moyen dépasse SWE-1.7, avec 58 % de tours en moins et un coût moyen inférieur de 81 %. Le résultat concerne ce benchmark et ce réglage précis. Le nombre de tours devient ainsi une donnée utile pour comprendre l'efficacité de l'agent, au-delà du tarif par token. Attention toutefois au lien de causalité : le document ne démontre pas que la totalité de l'économie vient uniquement de la baisse du nombre de tours. Et ces pourcentages ne constituent pas une prévision d'économie pour des tâches différentes.

Ma lecture est la suivante : l'unité d'évaluation pertinente doit pouvoir être la tâche menée jusqu'au résultat accepté. Dans un essai, je garderais le nombre de tours, le volume d'entrée cumulé, l'acceptation du livrable et la facture finale. Cela permet de comparer le travail réellement accompli, sans confondre un appel peu coûteux avec une tâche économique. Les publications d'AWS et de Cognition justifient cette précaution. Elles ne mesurent ni un dépassement budgétaire généralisé dans les entreprises, ni un changement déjà établi de toutes leurs pratiques d'achat.

Le 2e signal concerne la configuration du service. AWS utilise le même client Responses API et la même logique d'évaluation pour comparer des modèles, mais les infrastructures des fournisseurs et les réglages de raisonnement diffèrent. Dans le dispositif étudié, le raisonnement est désactivé côté Bedrock, tandis que le service OpenAI conserve son comportement par défaut. AWS précise donc que la comparaison porte sur des configurations de déploiement pratiques. Elle ne constitue pas une mesure contrôlée des capacités intrinsèques des modèles. Avant de tirer une conclusion sur un nom de modèle, il faut connaître le service et les réglages qui ont effectivement produit le résultat.

Simon Willison aborde une question voisine dans sa discussion d'une analyse de Mohamed Moustafa sur OpenRouter. Plusieurs fournisseurs peuvent servir un modèle, avec des logiciels d'exécution, des optimisations ou des paramètres différents. Le traitement de la vision et du raisonnement peut aussi dépendre du service. Il existe des moyens de contrôle : limiter le routage à un fournisseur, et consulter la liste des fournisseurs disponibles pour un modèle. Cette variabilité n'est donc pas présentée comme inévitable. Cette publication apporte un autre éclairage sur la comparabilité. Elle ne donne pas un taux mesuré de défaillances chez les fournisseurs, et ne reproduit pas les tests d'AWS.

Pour mes propres tests d'acceptation, je conserverais donc le modèle, le fournisseur réellement utilisé et les réglages de raisonnement. Si le fournisseur change, je referais les vérifications pertinentes avant de reprendre les résultats antérieurs. C'est une recommandation de méthode. Elle ne revient pas à dire que tous les fournisseurs produisent nécessairement des écarts importants. Les documents montrent surtout qu'un nom de modèle, sans sa configuration d'exécution, peut laisser une comparaison incomplète.

Venons-en aux informations sous les radars. Ici, l'intérêt se trouve dans les précisions techniques qui changent la lecture d'un résultat annoncé. Leur faible visibilité publique n'a pas été mesurée. Je les retiens pour ce qu'elles apportent à l'évaluation, pas pour leur attribuer artificiellement un caractère confidentiel.

Premier détail : le plafond de sortie. Dans son évaluation GDPval, AWS limite les réponses à 8 192 tokens. Cette limite tronque 6 livrables du modèle luna et 9 du modèle terra. Ce sont les résultats observés avec le plafond du test. AWS indique qu'une limite plus élevée pourrait améliorer la qualité, mais aussi augmenter le coût. Un livrable incomplet doit donc se lire avec son budget de sortie. Pour choisir un réglage, il faut mesurer la complétude et la facture ensemble. On ne peut pas déduire de ce test le résultat qu'un autre plafond aurait produit.

Deuxième détail, dans la même étude : le budget des nouvelles tentatives. AWS prend un taux de réussite de 37 % pour illustrer un calcul. Si chaque tentative était indépendante, avec une probabilité de réussite constante, il faudrait environ 2,7 tentatives par succès. Mais le document précise que les tentatives réelles sont corrélées. Une erreur peut se répéter lorsque l'agent repart avec la même stratégie ou les mêmes informations. Le chiffre de 2,7 reste donc une illustration conditionnelle, et non un taux de relance observé en production. Pour votre processus, la donnée utile est le comportement de la stratégie de relance réellement testée, y compris ses échecs répétés.

Troisième détail : le périmètre des scores de détection de données personnelles. AWS évalue 49 365 enregistrements, contenant 222 114 segments de référence pour les catégories communes. Le corpus associe des profils synthétiques multilingues et des documents professionnels en anglais. Le socle commun comprend 12 types d'entités. Des catégories supplémentaires dépendent des jeux de données, par exemple les professions ou les adresses de portefeuilles de cryptomonnaies. Chaque détecteur reçoit un score uniquement sur les catégories qu'il déclare et que le jeu de données contient. Un score doit donc toujours se lire avec cette couverture. Les limites concernant les frontières et les formats des dates restent également à prendre en compte.

La même étude compare des détecteurs sur Amazon Bedrock et Amazon EC2, mais précise la nature de ses chiffres de latence. Les chercheurs traitent les enregistrements avec des travailleurs parallèles, puis ramènent le temps total à un enregistrement. Ce sont des estimations indicatives du dispositif de traitement, pas des chronométrages directs de chaque requête isolée. Cette différence devient importante pour une application interactive. Avant de retenir un engagement de temps de réponse, il faut mesurer une demande seule dans les conditions d'utilisation prévues. Un bon débit de traitement par lots ne permet pas, à lui seul, de promettre une réponse individuelle aussi rapide.

Quatrième détail : Cognition regroupe des demandes proches pour leur traitement initial pendant l'entraînement de SWE-2. L'équipe rapporte un gain de 10 % à 20 % sur les tokens par minute et par GPU, ainsi que sur les tokens par seconde et par requête. En contrepartie, l'attente avant le premier token augmente. Cognition juge ce compromis acceptable dans son contexte d'entraînement. Cela sépare clairement l'efficacité de traitement et le début de la réponse. Le gain annoncé sur le débit ne veut donc pas dire qu'un utilisateur interactif voit nécessairement sa réponse commencer plus tôt.

Cinquième détail : la manière de vérifier les progrès pendant l'entraînement. Cognition explique que les capacités de Kimi K3 ont accru le besoin de renforcer les mécanismes qui attribuent les récompenses. L'équipe inspecte les exécutions pour repérer les faux positifs et les faux négatifs, puis affine ses données avec des versions intermédiaires de SWE-2. Ce document décrit un travail de correction itératif. Il invite à examiner aussi le mécanisme de notation quand les capacités progressent. Il ne certifie pas que toutes les faiblesses des vérificateurs ont disparu. Une meilleure performance impose donc de continuer à contrôler ce que le score récompense réellement.

Sixième détail : la version réellement servie par le cache HyperPod. AWS indique que remplacer les fichiers d'un modèle au même emplacement Amazon S3 ne suffit pas à rafraîchir automatiquement les poids en cache, si la configuration du déploiement reste inchangée. L'opérateur peut continuer à servir l'ancienne version. Il faut donc faire évoluer le chemin de version ou la spécification du déploiement, puis vérifier le modèle effectivement chargé. Cette restriction concerne le processus de mise à jour. Elle est distincte du gain de démarrage présenté au début. La présence de nouveaux fichiers à la source ne prouve pas que les utilisateurs reçoivent déjà le nouveau modèle.

Dernier détail : la portabilité du routage par préfixe dans Amazon SageMaker. L'API native Invoke compte les octets bruts de la requête. L'API compatible OpenAI compte les caractères du texte extrait des messages. Ces unités ne sont pas interchangeables. Avec l'interface native, les espaces, l'ordre des clés et la mise en forme du JSON peuvent modifier le routage, même si le sens du message reste identique. Lors d'un changement d'interface, il faut donc revoir le paramètre de préfixe et garder une sérialisation cohérente. C'est un point de configuration concret qui peut empêcher de retrouver le bénéfice attendu du contexte partagé.

Pour les prochains essais, je retiens une exigence simple : chaque bénéfice annoncé doit correspondre à une condition d'acceptation, avec un résultat de test conservé. C'est sur cette base que je choisirais les améliorations qui méritent une adoption. Merci de votre écoute. Vous pouvez retrouver mon travail sur www.aequitus.net, et vous abonner à la chaîne pour suivre les prochaines revues.

Sources et liens

www.aequitus.net