Cloudflare lance un modèle de décision de 27 B qui bat Jev sur son propre terrain

Cloudflare a publié Clef dans les premiers jours d'octobre sous licence Apache 2.0. C'est un modèle de 27 milliards de paramètres construit sur Qwen3.8-27B, et il n'écrit pas de prose. Il note des choix.

La catégorie est petite et spécifique. Un modèle de décision prend une entrée et un ensemble de choix de schéma candidats, puis renvoie un classement plutôt qu'une phrase générée. Jev de Typesafe AI a établi l'approche et en est devenu le point de référence. Clef arrive comme le deuxième acteur sérieux, et d'après les chiffres publiés par Cloudflare, il bat le tenant du titre à la fois en exactitude et en latence.

En quoi l'architecture diffère

Clef utilise une conception à préremplissage seul. Il lit l'entrée et note les options de schéma en parallèle plutôt que d'émettre des jetons un par un. Ce seul choix explique l'essentiel de l'écart de performance, car la partie coûteuse d'un appel classique à un modèle de langage est la boucle de décodage.

Sur BANKING77, un benchmark standard de classification d'intentions, Clef obtient 94,20 de macro-F1 contre 79,74 pour Jev. Cloudflare indique aussi que Clef-flash, la configuration plus petite, a une latence médiane de 38,8 millisecondes, ce qu'il décrit comme environ 13 fois plus rapide que la référence de 524,1 millisecondes de Jev.

L'interface compte autant que le score. Clef est compatible avec l'API de Jev, donc une équipe déjà connectée à Jev peut changer le point de terminaison sans réécrire le code d'intégration. Clef accepte aussi des entrées multimodales dans une fenêtre de contexte de 64 000 jetons, tandis que Jev est texte uniquement et plafonné à 32 000.

Le cadrage de Cloudflare est sans détour : pour le routage, la classification et la sélection structurée, générer du texte est du travail inutile. Si la réponse dont vous avez besoin est l'une de douze catégories, un modèle qui écrit un paragraphe puis le post-traite fait quelque chose de plus difficile que la tâche ne l'exige.

Où cela se situe face aux embeddings

Il vaut la peine de distinguer les modèles de décision de l'approche plus ancienne du même problème. Des équipes routent et classent avec des embeddings depuis des années : on vectorise l'entrée, on la compare à des exemples étiquetés, on choisit le plus proche. Cela fonctionne, et c'est peu coûteux, mais cela nécessite un ensemble étiqueté auquel se comparer, et cela échoue lorsque la décision dépend d'instructions plutôt que de similarité.

Un modèle de décision prend un schéma et un ensemble d'options dans la requête. Il peut répondre à un éventail plus large de questions qu'une simple vérification de similarité : à quelle catégorie appartient un message, lequel de trois outils appeler, vers quel modèle router, et laquelle de plusieurs politiques s'applique. Les instructions résident dans la requête plutôt que dans un index d'exemples maintenu, ce qui facilite le changement de comportement sans réétiqueter quoi que ce soit.

La contrepartie est qu'un modèle de décision reste un modèle de langage qui effectue la notation, il hérite donc de ses modes de défaillance. Il peut se tromper avec une grande confiance, et ses scores de confiance ne sont pas calibrés en une probabilité à laquelle une politique de routage peut se fier sans test. La conception à préremplissage seul supprime le coût de décodage, mais elle ne supprime pas le problème de savoir quand le modèle devine.

Le calcul des coûts est ce qui rend la catégorie intéressante de toute façon. Router une requête via un modèle génératif coûte une génération complète sur le chemin critique, souvent plusieurs centaines de millisecondes et quelques centaines de jetons. Cloudflare annonce Clef à moins de 40 millisecondes en médiane pour la configuration flash. Pour un agent qui prend plusieurs décisions de routage par tour utilisateur, cette différence se cumule, et elle se cumule à l'étape que les utilisateurs ressentent réellement.

La catégorie se standardise vite

Ce qui fait que ce n'est pas qu'un lancement de plus d'un fournisseur, c'est la vitesse à laquelle l'outillage autour des modèles de décision s'est étoffé.

Le 30 septembre, SGLang a ajouté des routes natives /v1/decisions et /v1/systemone, permettant aux modèles de langage et de vision d'agir comme classificateurs et noteurs sans génération jeton par jeton. Le framework a démontré cette capacité en exécutant Qwen3.8-27B comme modèle de décision multimodal et a rapporté avoir battu Pokemon FireRed en une tentative avec une latence inférieure à 100 millisecondes.

Quelques jours plus tard, llama.cpp a ajouté la prise en charge des modèles de décision via un nouveau point de terminaison /v1/systemone, couvrant des modèles ouverts dont Kev-4B et OpenJev, avec une sortie prévue dans la version 0.6.0. Les petits modèles tournent sur CPU, et certains prennent en charge des entrées d'images pour la classification.

Respan a lancé sa propre offre, Span-01, un classificateur de raisonnement hyper-parallèle pour détecter l'injection de prompt, l'hallucination et le mauvais usage d'outils dans les traces d'agents. Il est entraîné avec RLAIF et évalue plusieurs définitions de comportement non vues en une seule passe avant. Respan le propose à 0,02 $ par million de jetons d'entrée, avec une version Lite gratuite.

Cela fait quatre projets distincts à traiter les modèles de décision comme une interface digne d'être implémentée nativement, en l'espace de deux semaines. Quand un motif apparaît dans un framework d'inférence, un runtime local et la gamme de produits d'une startup en même temps, ce n'est plus une curiosité.

Pourquoi c'est important pour le routage des agents

Les premiers à en profiter sont ceux qui construisent des agents qui appellent d'autres modèles. Un agent doit décider quel outil utiliser, vers quel modèle router, si une requête est une tentative d'injection et si une réponse est fondée. Aujourd'hui, beaucoup d'équipes implémentent ces étapes en demandant à un grand modèle de répondre en JSON et en espérant que le format tienne.

Un classificateur qui renvoie un score en quelques dizaines de millisecondes change le coût de cette décision. Router une requête via un modèle de langage coûte une génération complète, et la coûte sur le chemin critique. La router via un noteur à préremplissage seul coûte une fraction de cela et se termine plus tôt. Si l'exactitude tient, l'effet pratique est qu'une plus grande partie du flux de contrôle d'un agent peut s'exécuter à la vitesse machine plutôt qu'à la vitesse des jetons.

L'argument de Cloudflare porte sur l'économie de l'infrastructure. L'entreprise affirme que les modèles à poids ouverts coûtent désormais de 15 à 90 % moins cher que les équivalents fermés pour la plupart des charges de production, et que l'époque où les poids ouverts couraient après les autres est révolue. Clef est présenté comme preuve : un modèle téléchargeable, sous licence Apache 2.0, qui surpasse un concurrent propriétaire dans sa propre catégorie de benchmark et peut être auto-hébergé.

Ce qu'il faut vérifier avant de croire au titre

Trois réserves méritent d'être gardées à l'esprit.

Premièrement, les benchmarks sont choisis par le fournisseur. BANKING77 est un jeu de données d'intentions réel et largement utilisé, mais un seul chiffre de macro-F1 ne décrit pas le comportement d'un modèle sur une distribution de production avec des classes rares, des entrées ambiguës et des formulations adverses. Une évaluation indépendante trancherait davantage qu'un article de lancement ne peut le faire.

Deuxièmement, la compatibilité avec l'API de Jev est une affirmation sur la forme de la requête, pas sur le comportement. Un point de terminaison substituable qui renvoie une calibration de confiance différente peut quand même casser une politique de routage réglée autour de l'original.

Troisièmement, la comparaison est mesurée par rapport à Jev tel que publié. Typesafe AI a ses propres versions en préparation, et l'écart entre un challenger et un tenant du titre reste rarement figé longtemps.

Rien de tout cela n'efface le point plus durable. Les modèles de décision existent parce que le routage, le contrôle d'accès et la classification représentent une grande part de ce que fait réellement l'infrastructure d'agents, et les confier à un générateur de texte a toujours été une mauvaise adéquation. Clef, Span-01 et les nouveaux points de terminaison dans SGLang et llama.cpp convergent vers la même idée : certains appels de modèle devraient renvoyer un nombre plutôt qu'une phrase. La question est désormais de savoir laquelle de ces implémentations finira sous la boucle d'agent de tous les autres, et combien de temps la catégorie restera disputée.