AWS publie un modèle qui ne sait pas écrire, et c'est tout l'intérêt

Le 1er octobre, le projet Strands Agents d'AWS a publié Strands Decider 2B, un modèle d'environ deux milliards de paramètres, et le plus intéressant, c'est ce qu'on lui a retiré. Selon la fiche Hugging Face et le dépôt GitHub, il part de Qwen3.5-2B-Base d'Alibaba, dont on a ôté la tête qui prédit le mot suivant pour la remplacer par une pointer head qui note les options reçues : à peine plus d'un million de nouveaux paramètres, avec une adaptation par LoRA de rang 16. « Decision models are designed to pick between sets of options... and assign simple numerical scores », écrit le blog officiel signé Marc Brooker, Mike Chambers et Fabio Nonato de Paula. Ce n'est pas un chatbot amputé, c'est un composant conçu pour une catégorie de tâches omniprésente chez les agents : quel outil appeler, vers quel modèle orienter une requête, si une action reste dans les limites. Des choix entre des alternatives déjà rédigées, où faire générer du texte à un LLM revient à travailler pour rien.

Les chiffres annoncés : 72,3 % sur le jeu public de JevBench, soit 167 tâches sur 231 ; 87,2 % sur ContractNLI, 88,4 % sur MuSiQue, 71,7 % sur HotpotQA. Une latence médiane d'environ 115 ms sur une RTX 3090 et de 153 ms sur un MacBook M3, qui croît à peu près linéairement avec la taille de la tâche. Le blog classe le modèle troisième sur 33 dans la catégorie 2B, premier sur 30 si l'on exclut les modèles juste au-dessus du seuil. Il faut le dire : les sources ne concordent pas. VentureBeat rapporte 106 ms de médiane et une deuxième place, mais en mesurant la v18 aller-retour HTTP compris et en écartant 7,7 secondes de préchauffage du serveur, alors que le blog et le dépôt parlent de la v19. L'écart de latence peut tenir à la version et à la méthode de mesure. Celui du classement reste inexpliqué : c'est une incertitude à garder ouverte.

La liste des limites, c'est AWS elle-même qui la signe, et elle mérite d'être lue : pas de code, pas de chatbot, pas de résumés ; moins performant que les modèles de raisonnement sur les problèmes complexes ; faible sur les documents longs à plusieurs étapes ; calibration réglée uniquement sur de courtes tâches de classification ; bruit d'étiquetage hérité des jeux de données publics. Surtout, le jugement du modèle ne doit pas être traité comme une frontière de sécurité face à des entrées malveillantes — c'est précisément la tentation, puisque les garde-fous figurent parmi les usages suggérés. La comparaison qui s'impose est avec Jev de TypeSafe, modèle de décision propriétaire proposé en service hébergé, dont nous avons déjà parlé. D'après VentureBeat, les documents d'AWS ne contiennent aucune comparaison directe de précision avec Jev. Rien ne démontre non plus que l'exécuter soi-même coûte moins cher que le service hébergé. Les bibliothèques d'intégration dédiées sont, pour l'instant, encore en développement.

Ce qui distingue cette publication, ce ne sont pas les poids en eux-mêmes, mais les poids accompagnés de la recette : code, procédure d'entraînement, inventaire des données, évaluations, licence Apache 2.0. Les performances restent autodéclarées et aucune vérification indépendante n'existe encore, mais avec la recette en clair, n'importe qui peut tenter de les confirmer ou de les démentir — ce qui n'a rien à voir avec le fait de croire un chiffre sur une page produit. Ce qui me frappe, c'est que la contribution la plus solide ici soit une soustraction : retirer à un modèle la capacité de parler pour voir à quel point il réussit la seule chose qu'on lui demandait.

— Olya