CLM-8B, le décideur ouvert qui défie Jev
Dans le papier sur Jev, j'avais décrit un modèle qui renonce à la parole pour ne faire qu'une seule chose : décider. On lui soumet une situation et un ensemble de choix possibles, et il renvoie une décision assortie d'une probabilité, sans rédiger une seule ligne de texte. TypeSafe, qui l'a lancé le 15 septembre, a baptisé cette catégorie System One, en hommage à la pensée rapide de Kahneman. Huit jours plus tard est arrivée une proposition du camp opposé : CLM-8B, publié par des chercheurs de Stanford et NVIDIA sous licence Apache 2.0, donc téléchargeable et installable sur ses propres serveurs.
Il serait facile de le balayer d'un revers de main comme le « Jev libre », mais c'est un raccourci réducteur. L'idée d'une réponse directe à Jev relève d'une lecture journalistique et non d'une revendication de ses auteurs. CLM s'attaque au même problème — décider rapidement sans générer de texte mot à mot —, mais avec une architecture et une vocation différentes. Des données disponibles émergent un spécialiste, non un substitut généraliste.
Deux encodeurs, une cache
Pour comprendre la différence, une image est utile. En 1975, Brian Eno et Peter Schmidt ont publié les Oblique Strategies, un jeu de cartes contenant des aphorismes à tirer au sort lorsqu'un travail créatif stagne. Le jeu reste identique, seule varie la situation dans laquelle on le consulte. CLM fonctionne de manière analogue : les actions possibles forment un jeu fixe, et chaque nouvelle situation est comparée aux cartes pour découvrir celle qui correspond le mieux.
Techniquement, le modèle utilise deux lecteurs distincts, l'un pour la situation et l'autre pour les actions, qui traduisent toutes deux ces éléments dans les coordonnées d'un espace partagé ; l'action la plus proche de la situation l'emporte. C'est le principe des moteurs de recherche sémantique, entraînés avec une méthode appelée InfoNCE qui récompense les appariements corrects et pénalise les autres. L'avantage pratique réside dans le fait que les coordonnées des actions sont calculées une fois pour toutes et conservées en mémoire (la cache), tandis qu'à chaque requête, seule la situation est analysée.
Jacky Kwok, responsable du projet, a expliqué à VentureBeat que Jev et un modèle apparenté, Laya, ne mettent en cache que la situation, et que la séparation opérée par CLM rend l'avantage plus net lorsque les contextes et les actions sont longs ou réutilisés. Il s'agit de la description donnée par le concepteur du projet, non vérifiée par des tiers : l'architecture interne de Jev n'est pas publique, TypeSafe n'a divulgué ni les poids ni la taille de son modèle, et les reconstitutions externes, comme celle de l'analyste Archer Hume, restent ouvertement des conjectures.
La cache n'a rien de magique, comme l'admet le README lui-même. D'après les mesures des auteurs sur une GPU RTX 4090, le traitement d'une situation inédite demande environ 28 millisecondes avec ou sans cache, car elle doit être lue dans tous les cas ; lorsque les situations se répètent, la latence chute de 1,7 à 0,6 millisecondes environ. Le gain dépend de la fréquence à laquelle l'agent visite à nouveau les mêmes scénarios (déclaration de partie non répliquée par des tiers).
Des poids vraiment ouverts ?
C'est ici que réside le premier avantage concret par rapport à Jev, qui demeure un service fermé accessible via une API. Les poids et le code sont publiés sous licence Apache 2.0, sans contrat à signer et avec la possibilité d'exécuter l'ensemble en local. Pour les acteurs de l'intelligence artificielle locale et de la souveraineté des données, c'est le point clé. Mais la notion d'« ouverture » recouvre trois niveaux distincts.
Le premier niveau concerne les poids, et sur ce point CLM est en règle, avec toutefois une réserve. La partie entraînée par les auteurs est un fichier de 75 mégaoctets : le plus gros du travail est assuré par Qwen3-8B d'Alibaba, un modèle préexistant conservé gelé, auquel CLM greffe deux petites têtes de prédiction (l'une pour les situations, l'autre pour les actions). Selon la fiche de baobab-tech, l'exécution nécessite un serveur vLLM pour l'encodeur, environ 16 Go de mémoire et, comme requis par les auteurs, un GPU NVIDIA. Sur Mac, une solution de contournement développée par un tiers existe, tandis qu'Ollama n'est pas pris en charge. L'exécution locale est faisable, mais elle n'a rien de trivial.
Le deuxième niveau porte sur l'évaluation. Le dépôt inclut les scripts permettant de reproduire les tests sur le code et le jeu T-Rex, ce qui rend possible une vérification partielle, bien que la même fiche note qu'un jeu de données cité dans le README ne figure pas dans la liste de l'organisation. Le troisième niveau touche à l'écosystème, encore peu mûr : le guide d'entraînement complémentaire est, selon baobab, un document rédigé pour un agent autonome plutôt que pour un lecteur humain ; les données et les pipelines d'entraînement se trouvent dans un autre dépôt ; et les licences des données d'entraînement ne sont pas listées, y compris pour les 30 millions de réponses erronées mais plausibles générées via Gemini 2.5 Flash-Lite, dont les conditions d'utilisation sont signalées comme non vérifiées pour cet usage.
Ce que déclarent les auteurs
Toutes les figures citées dans cette section reposent sur les déclarations des concepteurs du modèle. Dans les tests sans entraînement spécifique à la tâche, le README soutient que CLM fait jeu égal avec Jev sur l'utilisation de l'ordinateur, les jeux et l'appel d'outils, avec des temps d'exécution jusqu'à 9 fois plus rapides. Le cas le plus favorable est le jeu du dinosaure de Chrome : 16,5 millisecondes contre 149,8, les deux modèles réussissant 5 tests sur 5, comme sur Super Mario. Sur le benchmark BFCL v4 dédié à l'appel d'outils, CLM obtient 95,2 % de réussite contre 99,2 % pour Jev, avec des temps de 76,8 contre 125,5 millisecondes. Sur WikiRacing, qui consiste à atteindre une page Wikipédia cible en suivant des hyperliens, CLM réussit 26 tests sur 30 et Jev la totalité des 30, avec des durées de 79,8 millisecondes contre 225.
Deux précisions s'imposent dans un souci de rigueur. La parité n'est pas uniforme : dès que la précision diverge, Jev conserve l'avantage, et le gain de vitesse varie de 1,6 à 9 fois selon la tâche. En outre, CLM est mesuré sur un GPU local tandis que Jev est un service hébergé dans le nuage ; les sources consultées ne précisent pas si la latence de Jev inclut les temps de transit réseau, un détail qui modifie sensiblement la comparaison.
Le résultat le plus spectaculaire concerne le code. Après un entraînement complémentaire léger, les auteurs revendiquent 81,6 % sur DeepSWE et 87,6 % sur Terminal-Bench 2.1, contre 71,1 % et 83,1 % pour Jev. Cependant, ces chiffres proviennent de têtes spécifiques entraînées pour l'occasion et non du modèle de base publié, sur des ensembles réduits de 38 et 30 tâches isolées. De plus, CLM ne résout pas les problèmes par lui-même : il sélectionne la meilleure option parmi des propositions générées par des modèles plus vastes (Opus 5 pour le premier test et Fable 5 pour le second). Cela reste un résultat intéressant, car il constitue le seul terrain où, selon les auteurs, CLM surpasse Jev. Aucun tiers n'a encore reproduit ces résultats de manière indépendante.
Retours d'expérience sur le terrain
C'est ici qu'interviennent les évaluations tierces, basées sur des méthodes et des périmètres très divers.
La première est local-jev-bench, un test réalisé sur un Mac M3 Max doté de 36 Go de RAM et synthétisé dans la fiche de baobab-tech. CLM obtient 39 % de réussite sur 105 décisions en anglais, 41 % en coréen et 20 % sur BANKING77, un jeu de données classique regroupant 20 catégories de requêtes bancaires (où le hasard donnerait environ 5 %). Deux autres modèles ouverts évalués dans le même test atteignent respectivement 89 %, 87 % et 89 % (Kev-4B) ainsi que 81 %, 84 % et 80 % (AnyJev L0). Attention : il ne s'agit pas d'un test comparatif direct contre Jev, mais face à d'autres modèles ouverts. Les évaluateurs n'ont par ailleurs pas réussi à reproduire l'exemple officiel du README concernant la détection d'urgence (0,852 contre 0,41). Limites : matériel non ciblé par les auteurs et protocole tiers.
La deuxième évaluation est un test mené par michabbb sur 140 paires réelles de liaisons entre entités d'une base de connaissances, posant la question binaire de savoir si deux éléments sont reliés. Sur 40 paires disposant d'une réponse de référence, la capacité de discrimination (AUC, où 1,0 représente la perfection et 0,5 le hasard) est de 0,77 pour CLM avec des textes tronqués à 2 048 tokens, 0,64 avec le texte intégral, et 0,998 pour Jev. CLM s'accorde avec Jev sur les tranches de décision dans environ 44 % des cas et n'attribue jamais une probabilité inférieure à 0,22. La latence est également moins bonne : 0,52 seconde contre 0,28 seconde, mais la comparaison est déséquilibrée : CLM tournait sur un DGX Spark avec les têtes de prédiction exécutées sur processeur, tandis que Jev était interrogé via API. L'auteur détaille lui-même les biais : tâche très éloignée des cas d'usage prévus pour le modèle, 129 entrées sur 140 dépassant la fenêtre de contexte, réponses de référence attribuées par un modèle linguistique et non par des évaluateurs humains, aucun entraînement spécifique et version v0.1.
La troisième catégorie rassemble les agrégateurs. BenchLM enregistre sur JevBench des scores de 8,57 contre 63,29 pour la version 1.4 et de 1,51 contre 72,13 pour la version 1.5, tout en refusant d'établir un classement par manque de données comparables. Benchmark Heaven classe CLM au 87e rang sur 92 modèles ouverts, bien qu'il s'agisse d'un projet personnel en version bêta. De plus, JevBench est un banc d'essai conçu spécifiquement autour de l'architecture des modèles de type Jev. Ce sont des indicateurs à suivre, non des jugements définitifs.
Pourquoi les chiffres divergent
Il serait erroné de conclure que l'une des parties ment. Dans Rashōmon de Kurosawa, le même événement donne lieu à quatre récits inconciliables sans qu'aucun témoin ne soit de mauvaise foi : ils observent simplement depuis des angles différents. Il en va de même ici avec les benchmarks.
Les tests officiels privilégient le choix entre un nombre restreint d'actions récurrentes, l'appel d'outils, les jeux vidéo et la sélection parmi des réponses candidates. Les tests indépendants s'appuient sur des classifications comportant de nombreuses catégories, des tickets de support réels et des évaluations sur des textes longs et structurés. Les variables clés évoluent : la longueur de l'entrée (que CLM tronque silencieusement au-delà de sa fenêtre par défaut de 2 048 tokens), la taille du vivier de candidats et la fréquence de réutilisation des mêmes actions, dont dépend l'efficacité de la cache. Le régime varie également : modèle de base publié versus têtes spécifiques entraînées sur mesure.
Kwok l'a lui-même reconnu avec franchise : il n'utiliserait pas CLM à la place d'un modèle de raisonnement généraliste pour des problèmes de mathématiques, des textes longs ou de la planification complexe. VentureBeat rappelle en outre une contrainte structurelle : les probabilités attribuées par CLM sont relatives uniquement au jeu de candidats qui lui est soumis ; si tous les choix sont mauvais, le modèle en sélectionnera néanmoins un. Ma conclusion est la suivante : CLM peut se révéler excellent dans le domaine pour lequel il a été conçu tout en étant faible en dehors. L'étendue réelle de ce domaine reste aujourd'hui à déterminer.
Compromis en production
Par souci d'impartialité, rappelons que Jev s'appuie lui aussi en grande partie sur des chiffres déclarés par TypeSafe : l'entreprise qualifie elle-même d'internes ses mesures de vitesse et de coût, et n'a publié aucune courbe de calibrage, comme je le notais dans l'article précédent. Sur le plan financier, il n'existe aucune comparaison homogène, ainsi que l'admet VentureBeat.
Jev représente aujourd'hui le choix le plus prévisible sur le plan de la précision globale ; CLM est l'option la plus séduisante pour le contrôle des données, le coût marginal nul et la faible latence, mais il exige une validation sur vos propres flux de travail. Qui y gagne ? Les organisations traitant des données sensibles avec des actions répétitives. Qui prend un risque ? Ceux qui l'adopteraient en se fiant uniquement aux annonces.
Ce qui manque pour trancher
J'expose les limites de cette analyse par souci de transparence. Je n'ai pas pu effectuer d'essai local sur du matériel AMD, non ciblé par l'infrastructure officielle. Les tests indépendants restent rares et portent sur des tâches hétérogènes. Il manque des bancs d'essai comparatifs réprodictibles sur une même tâche, avec les mêmes prompts et la même version de Jev (qui a atteint entre-temps la version 1.13.0). Les performances après un entraînement complémentaire pourraient être très différentes mais ne sont pas documentées par des tiers. Des mesures manquent sur la latence dans les cas défavorables, les coûts réels de déploiement, l'empreinte mémoire et la dégradation de qualité hors du domaine cible. Enfin, le modèle grand frère multimodal CLM-35B, annoncé par les auteurs pour début octobre, n'est toujours pas disponible sur Hugging Face au 11 octobre.
Une alternative ciblée, non un remplaçant
CLM-8B est une avancée importante car il apporte dans le domaine public une alternative ouverte aux modèles fermés System One, avec une approche architecturale originale et auditable. La latence réduite et la licence libre constituent des atouts réels, en particulier pour des agents à haute fréquence et des environnements sous contrôle strict. Néanmoins, dans les tests indépendants disponibles à ce jour, Jev reste nettement plus fiable pour la classification, les jugements binaires et le traitement de textes complexes.
La bonne question n'est donc pas « CLM ou Jev ? », mais de savoir si votre charge de travail comporte des actions réutilisables, des jeux de candidats restreints et un besoin d'hébergement sur vos propres serveurs. Si la réponse est oui, CLM mérite un essai évalué sur vos propres données. Si votre priorité absolue est la précision globale sans entraînement spécifique, Jev demeure le choix le plus prudent. Comme avec tout jeu de cartes, la valeur de la carte importe moins que la situation dans laquelle on la tire : mieux vaut mesurer avant de choisir.