AWS Strands Labs dévoile un modèle de décision local et calibré

AWS Strands Labs publie Strands Decider 2B, un modèle open source qui ne génère pas de texte mais tranche entre options. Pensé pour le routage, la triage et les garde-fous, il vise les usages locaux et auto-hébergés.

AWS Strands Labs a publié Strands Decider 2B, un modèle de décision open source qui ne génère pas de texte mais renvoie un choix, une probabilité oui/non ou un score. Avec 1,9 milliard de paramètres, il peut tourner en local sur CPU, GPU grand public ou Mac Apple Silicon, ce qui le place à mi-chemin entre l’IA générative classique et les briques de tri utilisées dans les agents. Son intérêt est simple : décider vite, sans faire bavarder la machine.

Un modèle qui tranche, pas un modèle qui parle

Strands Decider appartient à la famille des decision models, ou modèles de décision, parfois appelés System One models dans la documentation citée. Là où un LLM peut produire n’importe quelle sortie, celui-ci se limite à des réponses cadrées par la requête : choice pour choisir une option parmi N, noul pour donner une probabilité oui/non entre 0 et 1, et score pour noter sur une échelle ordonnée.

Le modèle repose sur Qwen3.5-2B-Base, auquel AWS Strands Labs a retiré la tête de modélisation de langage. À la place, l’équipe a ajouté une petite tête de type pointeur d’environ 1 million de paramètres, chargée de comparer l’état caché avec les options proposées. Une seule passe suffit, sans boucle de décodage. Techniquement, c’est plus proche d’un arbitre que d’un conteur.

Cette architecture vise les tâches répétitives où il faut trier, valider ou router, pas rédiger des paragraphes. L’équipe dit d’ailleurs que le modèle reste inférieur aux modèles de raisonnement sur les problèmes complexes, et qu’il n’est pas fait pour le code, le chat ou la synthèse.

Pourquoi AWS le positionne dans les agents

Les cas d’usage mis en avant sont concrets : routage de modèle, sélection d’outil, vérification d’arguments, triage, garde-fous, évaluation et agents hybrides. Dans ce dernier cas, le LLM garde les décisions difficiles, tandis que le decider prend en charge les choix mécaniques. C’est moins spectaculaire qu’un assistant qui rédige un roman, mais souvent plus utile dans un pipeline de production.

Le dépôt fournit aussi un exemple de garde-fou autour d’un appel d’outil météo. Avant l’exécution, deux questions oui/non vérifient si les arguments collent vraiment à ce que l’utilisateur a dit et si l’appel n’est pas prématuré. Si le modèle a inventé une ville, le système interroge l’utilisateur à la place.

Depuis le terminal, le modèle peut aussi orienter une requête comme « Help! My payouts have been failing for 3 days! » vers une catégorie de support, avec un score de confiance. Le but n’est pas de faire joli, mais de réduire les mauvais acheminements et les faux positifs.

Des chiffres qui comptent surtout pour la calibration

Sur JevBench, le jeu de tests public utilisé pour ces modèles, la version v19 affiche une exactitude publique de 0,723, soit 167 tâches réussies sur 231. L’équipe annonce aussi un Brier score de 0,342 et un expected calibration error de 0,052. En pratique, cela compte autant que le taux brut : un score de confiance exploitable vaut mieux qu’une réponse brillante mais incertaine.

Sur des tâches courtes non vues, les réponses à 0,9 de confiance ou plus se sont révélées correctes dans environ 95 % des cas, selon le dépôt. En dessous, AWS Strands Labs recommande de confirmer ou d’escalader. Le seuil n’est pas magique, mais il donne une règle de conduite utile aux équipes produit et support.

Les latences publiées restent contenues : 115 ms de médiane sur une RTX 3090 et 153 ms de médiane à chaud sur un M3 Pro pour moins de 300 tokens. Les chiffres ne se comparent pas directement entre eux, car les matériels et bancs d’essai diffèrent, mais ils montrent un modèle pensé pour répondre vite, y compris hors centre de données.

Open source, auto-hébergement et prudence en production

Les poids sont disponibles sur Hugging Face sous licence Apache-2.0, et la commande pip install strands-decider fournit un CLI ainsi qu’un serveur HTTP. Attention toutefois : le serveur embarqué écoute sur 127.0.0.1 sans authentification. Pour un déploiement réel, il faut donc ajouter sa propre couche de sécurité. Le modèle n’est pas encore servi par un fournisseur d’inférence hébergée, selon la note publiée.

La publication inclut aussi la recette d’entraînement et la liste des données, ce qui facilite la vérification et les adaptations internes. Côté classement, la version v19 se place troisième sur 33 dans la catégorie 2B sur le board v1.4.2 du 25 septembre, et première si l’on retire trois modèles légèrement au-dessus de 2B. Un détail qui a son importance pour les équipes qui aiment les tableaux de bord plus que les slogans.

Une comparaison citée par la source rappelle toutefois qu’un concurrent plus récent, decider-2b de Mapika, obtient 175 tâches sur 231 sur le même harness Strands, avec huit tâches d’avance [à vérifier]. Autrement dit, Strands Decider 2B avance de bons arguments, mais la course des modèles de décision reste ouverte.

Points clés

  • Strands Decider 2B ne génère jamais de texte.
  • v19 atteint 0,723 sur JevBench public.
  • Confidence 0,9 : environ 95 % de bonnes réponses.
  • 25 septembre : 3e sur 33 en catégorie 2B.
  • AWS Strands Labs publie poids, code et recette.

En chiffres

  • 1,9 milliard — paramètres du modèle, selon AWS Strands Labs.
  • 167 sur 231 — tâches réussies sur JevBench public, version v19.
  • 0,052 — expected calibration error annoncé sur JevBench.
  • 115 ms — médiane de latence sur RTX 3090.
  • 153 ms — médiane à chaud sur Mac M3 Pro, moins de 300 tokens.

À lire