Les modèles de décision remplacent discrètement le LLM dans la boucle de l'agent

Cloudflare a publié deux modèles dans les premiers jours d'octobre qui n'écrivent rien. Clef et Clef-flash lisent une entrée plus un ensemble de questions typées et renvoient une probabilité pour chaque réponse autorisée. Pas de prose, pas de chaîne de raisonnement, pas de tokens générés un par un. Juste un choix structuré.

Cela ressemble à une régression jusqu'à ce qu'on regarde les chiffres. Sur BANKING77, un benchmark standard de classification d'intention, Clef obtient un macro-F1 de 94,20 contre 79,74 pour Jev, le modèle qui a introduit la catégorie des modèles de décision. Clef-flash, la version plus petite de 9B, atteint 90,93. L'écart de latence est encore plus large. Clef-flash renvoie une réponse médiane en 38,8 millisecondes ; Jev met 524,1 millisecondes. Cloudflare affirme que Clef bat Jev sur sept des dix benchmarks de décision.

Les deux modèles sont publiés sous Apache 2.0 sur Hugging Face, et tous deux sont compatibles avec l'API de Jev, de sorte que les équipes déjà construites autour de Jev peuvent basculer sans réécrire leurs intégrations. Le fil Hacker News a atteint 602 points et plus de 200 commentaires en une journée.

Pourquoi un modèle plus petit peut gagner sur une tâche plus étroite

Les modèles de décision ont une forme différente de celle des chatbots vers lesquels la plupart des développeurs se tournent. Un grand modèle de langage génère du texte ouvert. Un modèle de décision lit un état et une liste de réponses autorisées, puis note chacune d'elles. La catégorie a été initiée par Typesafe AI avec Jev, qui a montré que les tâches de routage ou de classification des agents n'ont pas besoin d'un modèle généraliste de 400B. Elles ont besoin d'une sortie bornée, peu coûteuse et rapide.

Le Clef de Cloudflare est construit sur Qwen3.8-27B et utilise une architecture en prefill seul qui évalue les choix de schéma en parallèle au lieu de générer les tokens séquentiellement. C'est là que se joue la latence. Un modèle généraliste doit émettre une réponse token après token ; un modèle de décision n'a qu'à lire la question et trancher.

Il y a aussi une différence de contexte à noter. Clef accepte des entrées multimodales dans une fenêtre de 64k tokens, couvrant texte, JSON, images et vidéo. Jev ne gère que le texte, à 32k. Pour un agent qui route sur une capture d'écran ou un PDF, ce n'est pas un petit avantage.

La première objection de la communauté était la bonne

Le retour le plus utile dans la discussion Hacker News ne contestait pas les benchmarks. Il contestait l'étiquette. « Poids ouverts, pas open source », a écrit un commentateur. Les poids portent une licence permissive, mais les données d'entraînement et le pipeline n'ont pas été publiés, si bien que le modèle ne peut pas être reproduit de zéro.

Cette distinction importe pour quiconque décide où exécuter ce modèle. Clef a été entraîné à partir d'un point de départ Qwen propriétaire. Les poids sont libres de téléchargement et d'hébergement, ce qui représente une véritable économie, mais ils ne sont pas auditables comme l'est un logiciel open source. Les équipes dotées de politiques strictes de revue de la chaîne d'approvisionnement devraient lire la licence et la fiche du modèle avant de supposer que l'étiquette Apache 2.0 règle la question.

La même semaine, Amazon en a mis un dans votre ordinateur portable

Cloudflare n'était pas seul. Strands Labs d'AWS a publié Strands Decider 2B, un modèle de décision ouvert avec les poids et les scripts d'entraînement, conçu pour tourner en local et renvoyer des choix notés par un score de confiance en dizaines à quelques centaines de millisecondes. Cloudflare a également ajouté un service de fine-tuning par RL pour ses modèles de décision sur Workers AI.

Le schéma, c'est un petit modèle qui fait bien un seul travail et qui tourne au plus près des données. Si vous pouvez conditionner un appel d'outil, vérifier qu'une requête est fondée, ou décider s'il faut escalader, avec un modèle de 2B en 40 millisecondes, l'économie consistant à faire passer un agent par un modèle de pointe à chaque étape commence à paraître gaspilleuse.

Le paradigme introduit par Jev, et pourquoi il a fallu un an pour qu'il prenne

Le Jev de Typesafe AI avançait une affirmation facile à balayer au lancement : l'essentiel de ce que les agents demandent à un modèle n'est pas de la génération, c'est de la classification. Router ce ticket, choisir cet outil, décider si cette action nécessite une approbation. Pour ces tâches, un modèle qui écrit des paragraphes fournit bien plus de travail que la tâche ne l'exige.

Jev a prouvé que l'approche étroite pouvait battre un modèle généraliste sur ses propres benchmarks. Ce qu'il ne pouvait pas faire, c'était rendre la catégorie urgente. Un seul fournisseur vendant un seul modèle de décision, c'est une curiosité. Cloudflare publiant une version Apache 2.0 compatible avec l'API de Jev, c'est une situation différente, car désormais n'importe qui peut l'héberger, inspecter la licence et l'intégrer sans réécriture. Amazon arrivant la même semaine avec son propre décideur ouvert transforme une curiosité en catégorie.

Le calendrier correspond à la façon dont les agents sont réellement construits. La première génération de frameworks d'agents faisait passer chaque étape par un seul grand modèle, parce que c'était le plus simple. À mesure que ces systèmes passent en production, les coûts de routage deviennent ce que les équipes remarquent. Découper la boucle en un modèle de langage pour les parties qui ont besoin de langage et un décideur pour celles qui n'en ont pas besoin est le correctif évident, et il a fallu la publication ouverte d'un bon décideur pour le rendre praticable.

L'angle du fine-tuning

Cloudflare a également ajouté un service de fine-tuning par RL pour ses modèles de décision sur Workers AI, ce qui indique où la catégorie se dirige ensuite. Un décideur générique est utile. Un décideur affiné sur votre propre historique de routage, vos propres règles d'escalade et votre propre notion de périmètre est plus utile, parce qu'il apprend la frontière qui compte pour votre activité.

C'est aussi la partie qui devrait inciter les équipes à la prudence. Un décideur affiné encode vos décisions passées, y compris les mauvaises. Si votre équipe approuvait autrefois des remboursements qu'elle aurait dû escalader, le modèle apprendra ce schéma et l'appliquera plus vite qu'un humain ne pourrait jamais le faire. La calibration joue dans les deux sens.

Où cela s'inscrit dans un pipeline d'agent

Imaginez un agent de support traitant un remboursement. Avant de pouvoir appeler l'outil de remboursement, quelque chose doit répondre à des questions comme : cette demande est-elle dans le périmètre, le compte du client l'autorise-t-il, cela nécessite-t-il un humain. Ce sont des questions de décision avec un ensemble fixe de réponses. Un modèle de décision peut renvoyer les probabilités, et l'agent agit selon un seuil.

Le profil de coût est tout l'intérêt. Router chacun de ces contrôles via un modèle de 400B coûte de l'argent à chaque appel et ajoute des centaines de millisecondes de latence. Les déléguer à un décideur local de 2B ou 9B réserve le modèle de pointe aux parties qui ont réellement besoin de langage : écrire la réponse, résumer un long fil, traiter un cas ambigu. Les budgets et les enveloppes de latence diminuent tous les deux.

Il y a un piège. Un modèle de décision renvoie une probabilité, et les probabilités peuvent se tromper avec assurance. Si vous automatisez une approbation de remboursement sur un score de 0,92, vous avez déplacé le risque de la formulation du modèle vers votre seuil. La calibration, et non la précision brute, devient le chiffre à surveiller. La latence et le coût sont faciles à mesurer ; un 0,9 bien calibré l'est moins.

Ce qu'il faut surveiller ensuite

Les outils suivent déjà les modèles. llama.cpp a ajouté la prise en charge des modèles de décision, et Perplexity comme Hugging Face parient tous deux dans la même direction. Si la catégorie tient, la question intéressante cesse d'être quel modèle de décision remporte un benchmark pour devenir quelles décisions vous êtes prêt à confier à une probabilité.

Pour les constructeurs d'agents, le geste pratique consiste à auditer la boucle et à repérer les étapes qui n'ont jamais eu besoin de texte fluide. La classification, le routage, la sélection d'outils et les contrôles préalables à une action sont les candidats habituels. Ce sont les étapes où une réponse en 40 millisecondes sur un ensemble fixe de choix peut remplacer une génération lente et coûteuse. Le reste de l'agent peut rester sur le modèle qu'il utilise déjà.