Nace.AI ouvre les poids de Drex 1.5 : un modèle décisionnel de 8,95B note les options en une passe, 93,4% sur documents longs jusqu'à 128K
Selon un article de MarkTechPost du 9 octobre 2026, Nace.AI a publié les poids ouverts de Drex 1.5, un modèle décisionnel dense de 8,95B qui lit un état et une question typée puis renvoie une probabilité par option, sans générer de texte. Le rapport indique un score de 58,08 sur Decision Index 0.3.1 et un fonctionnement local possible en bf16 sur une carte unique ou via une version quantifiée d'environ 9,5 Go.
Ce qui change
Selon un article de MarkTechPost du 9 octobre 2026, Nace.AI a publié les poids ouverts de Drex 1.5, un modèle décisionnel dense de 8,95B destiné aux agents et aux flux backend. Le modèle ne génère pas de texte : l'utilisateur fournit un état (texte ou JSON) et une question nommée, et le modèle renvoie, en une seule passe avant, une probabilité pour chaque option ; il prend en charge trois types de questions, choice, noul (oui/non) et score ordinal. Comme aucun token n'est échantillonné, temperature et top_p ne s'appliquent pas. La source indique que le squelette est MiMo-V2.6-Distill-Qwen-9B, avec 32 couches et une attention hybride (chaque couche d'attention complète étant associée à trois couches d'attention linéaire), plus une tête de pointeur séparée head.pt qui note les états cachés. L'interface est POST /v1/systemone, au format de requête identique à celui du modèle propriétaire Jev de TypeSafe ; la source affirme qu'un client Jev existant peut migrer en modifiant quelques variables d'environnement. Le contexte par défaut est de 16384 tokens, avec un maximum de 131072 ; les poids sont publiés sur Hugging Face, une version hébergée est disponible sur OpenRouter et la puissance de calcul serait fournie par DeepInfra.
Conséquences pour les développeurs
Pour les développeurs, le changement le plus direct est que les tâches décisionnelles passent d'un « modèle de chat qui produit du texte structuré à analyser » à « une passe avant qui donne des probabilités par option », ce qui supprime la logique d'analyse et de nouvelle tentative et rend la latence de décision plus prévisible. D'après le rapport, les documents longs sont le point fort de Drex 1.5 : de 32K à 128K tokens, la précision atteint 93,4% pour une latence médiane de 2,0 secondes ; les mêmes requêtes tronquées à 8K tokens voient la précision tomber à 76,5% et 78%, ce qui montre un écart marqué entre décisions en contexte long et en contexte court et compte beaucoup pour les flux de type arbitrage après RAG ou tri de plusieurs candidats. À l'inverse, le rapport précise qu'il s'agit d'une couche décisionnelle, pas d'un modèle généraliste : il ne génère ni texte, ni code, ni explication ; les tâches à forte densité de connaissances sont son point faible, avec 45,4% sur GPQA Diamond contre 78,6% pour Jev, et 58,7% sur MMLU-Pro contre 82,7% pour Jev ; sur ACOS, l'analyse de sentiment sur un commentaire unique n'atteint qu'un F1 de 7,4%, contre 29,5% pour Jev. L'entraînement a utilisé le jeu d'entraînement officiel du benchmark d'index, ce qui lui donne un avantage sur les types de décision courants, mais la source avertit que les résultats peuvent différer sur de nouveaux domaines. Côté déploiement, la voie locale nécessite les forks llama.cpp et Ollama de Nace, et non les builds de la branche amont ; les poids sont sous licence Open RAIL-M et la source invite explicitement à vérifier les clauses avant un usage commercial : c'est là qu'il faut distinguer « poids ouverts » et « licence open source », la disponibilité des poids n'impliquant pas une licence permissive.
Intégration et évaluation
Les éléments suivants sont des recommandations et des analyses conditionnelles fondées sur le rapport, pas des faits vérifiés. Première décision : faut-il basculer les appels Jev existants vers Drex 1.5. Le rapport indique un format de requête identique et un coût de modification limité aux variables d'environnement ; donc, lorsque la charge de travail est surtout composée de notation d'options, de jugements oui/non et de tris ordinaux, et que l'équipe veut sortir le trafic décisionnel d'une API propriétaire, commencer par une comparaison en trafic fantôme est plus prudent. Critère d'acceptation mesurable : envoyer la même série de requêtes historiques sur les deux chemins et calculer le taux d'accord des options et la part d'échantillons dont la probabilité maximale est inférieure au seuil ; si le taux d'accord est élevé et que la part de faibles confiances n'augmente pas nettement, augmenter progressivement la charge. Si la charge de travail inclut la génération d'explications ou si les réponses doivent exposer un raisonnement, il ne faut pas basculer, car ce modèle ne génère pas de texte selon le rapport. Deuxième décision : en scénario document long, faut-il utiliser directement le palier 128K plutôt que de tronquer d'abord. Le rapport montre 93,4% de précision et 2,0 secondes de latence médiane sur 32K à 128K, contre 76,5% et 78% après troncature à 8K ; donc, si l'entrée est réellement un document long et que le budget de latence accepte un coût de l'ordre de la seconde, conserver le contexte long peut être plus rentable. Pour l'évaluation, mesurer la précision et la latence P95 par tranche de longueur (moins de 8K, 8K à 32K, 32K à 128K) ; si la latence du palier long dépasse le budget, envisager la troncature, mais en acceptant la baisse de précision. Troisième décision de déploiement : exécution locale ou hébergée. Le rapport indique qu'en bf16, environ 18 Go tiennent sur une seule A10G de 24 Go, qu'un GGUF Q8_0 d'environ 9,5 Go tourne sur puces Apple et CPU, et que les deux voies de quantification donnent les mêmes réponses ; donc, si les données ne peuvent pas sortir de l'intranet ou si une inférence hors ligne est nécessaire, le déploiement local est envisageable, à condition d'accepter les builds des forks Nace et les clauses d'Open RAIL-M. Critère d'évaluation : comparer la concordance des réponses locales et hébergées sur le même jeu d'évaluation, et vérifier si le débit sur une carte unique couvre le besoin de requêtes par seconde. Les prix changent : pour le coût hébergé, se référer aux pages tarifaires actuelles d'OpenRouter et de Nace Console.
Limites et points à confirmer
Il faut être clair : Drex 1.5 n'apparaît pas actuellement dans les modèles de KimiSeek, et la disponibilité API mentionnée dans le rapport renvoie au service hébergé du fournisseur, sans lien avec le catalogue de ce site. Les scores de benchmark cités (58,08 sur Decision Index 0.3.1, 86,2% sur JevBench, 122 victoires, 47 nuls et 87 défaites sur OpenSpiel, 93,4% sur documents longs, etc.) sont des résultats rapportés par Nace ou par les organisateurs de classements, le plus souvent produits par le fournisseur lui-même sur les suites d'évaluation officielles, et ce site ne les a pas reproduits indépendamment. Le rapport signale aussi que l'entraînement a utilisé le jeu d'entraînement officiel du benchmark d'index, donc les performances sur de nouveaux domaines décisionnels peuvent s'écarter des scores de classement ; les faiblesses en analyse de sentiment ACOS et dans les tests de connaissances sont déjà indiquées dans le rapport. En outre, les voies Ollama et llama.cpp dépendent des forks de Nace, que la branche amont ne prend pas forcément en charge ; les poids sont ouverts, mais la licence RAIL-M comporte des restrictions d'usage, et l'usage commercial exige de vérifier les clauses soi-même. Le bonus d'inscription de 25 dollars et les prix hébergés mentionnés dans le rapport datent du moment de la publication et peuvent avoir changé ; consulter les pages tarifaires actuelles.