RSI-Jev vs Laya : deux modèles de décision ouverts, des paris opposés

À compter d’octobre 2026, il existe deux modèles à poids ouverts qui méritent d’être envisagés si vous voulez des décisions typées — un oui/non, un choix parmi k, une note selon un barème — sans point de terminaison hébergé dans le chemin. Ce sont RSI-Jev v6.1-VL 4B, publié le 2026-10-07 par la boucle de recherche tierce Shanghua-Gao/RSI-Jev, et Laya, publié le 2026-09-18 par Convai Innovations. Les deux répondent en une seule passe avant, sans texte généré ; les deux renvoient une probabilité calibrée pour chaque option ; les deux sont distribués sous licence Apache-2.0 avec un serveur qui parle l’API de décision de TypeSafe, de sorte qu’un client écrit pour le modèle commercial fonctionne avec l’un ou l’autre en changeant une URL de base. Ils reposent aussi sur des paris opposés, et les deux nombres qui les séparent sont 3 à 4 tokens par étiquette et 421 millions de paramètres.

Le premier pari concerne l'échelle. Le checkpoint anglais de Laya est ModernBERT-large, avec 421 M de paramètres et un contexte de 512 jetons, et son checkpoint multilingue est mmBERT-base, avec 322 M de paramètres et une fenêtre de 1 024 jetons qui atteint 8 192 lorsque l'encodeur est configuré au maximum. RSI-Jev v6.1-VL fait tourner une tour Qwen3.5-4B-Base entière — 4,69 milliards de paramètres, dont 3,57 milliards dans les 32 couches du décodeur, plus une tour de vision et trois têtes de décision aux couches 16, 20 et 32. Laya est un modèle dont on peut précharger trois exemplaires en quelques gigaoctets ; RSI-Jev est un checkpoint bf16 de 9,7 Go. Le deuxième pari découle du premier : Laya ne dépense presque rien par appel et attend de vous que vous lui enseigniez votre domaine, tandis que RSI-Jev dépense quatre milliards et demi de paramètres pour tenter de répondre à votre question sans aucun entraînement.

À quoi chacun sert réellement

La fiche de modèle de Laya elle-même contient la phrase qui résume cette comparaison mieux que ne le ferait n'importe quel critique : « Laya est une base rapide à spécialiser, pas un moteur de décision zero-shot. » Sur le benchmark de décisions typées — 2 000 décisions réparties sur quatre workflows — le checkpoint de base en anglais obtient 0,362, contre 0,318 pour une réponse aléatoire et 0,461 pour le choix systématique de la classe majoritaire. Sur ces mêmes décisions, le checkpoint Convai affiné sur le split d'entraînement propre à ce benchmark atteint 0,766, dépassant le plafond de 0,735 fixé par l'accord avec l'enseignant. Cet écart, c'est le produit : Laya est un encodeur de 421 M que l'on affine sur une taxonomie étroite, et Convai fournit un notebook Kaggle qui exécute toute la boucle — construire le jeu de données, entraîner, ajuster les températures de calibration, évaluer — sur deux T4 gratuits.

RSI-Jev est l'autre piste. Sa version v6.1-VL obtient 0,3 sur son propre Decision Index public 0.3, une exécution de 140 178 requêtes de la configuration définie, ce qui, sur le classement du projet du 6 octobre 2026, égale le meilleur modèle 4B qui y figure et la classe 27e sur 101 au total. Sa suite de quinze benchmarks est de 0,793 et son ensemble tenu à l'écart est de 0,729. Ce sont des chiffres en zero-shot — bien que le projet s'empresse de préciser que dix des quinze benchmarks fournissent d'une manière ou d'une autre des données d'entraînement, de sorte que « zero-shot » s'applique à la recherche de la version, et non à chaque chiffre de la page. Ce que ces chiffres apportent, c'est un modèle qui répond à une question sur un document que vous ne lui avez jamais montré et qui n'a pas besoin d'un entraînement préalable.

• Taille — Laya 421 M anglais / 322 M multilingue vs RSI-Jev 4,69 Md, exécutant toute la tour Qwen3.5-4B-Base.

• Précision zéro-shot — Laya 0,362 sur les typed-decisions, en dessous de la baseline majoritaire de 0,461, contre RSI-Jev 50,98 sur son propre Decision Index 0,3, égalant la meilleure entrée 4B à cet égard.

• Précision après affinage — Laya 0.766 avec un checkpoint entraîné sur le split propre au benchmark, contre les chiffres de RSI-Jev qui sont au niveau de la release, et non par domaine.

• Langues — Laya : 45 langues sur 51 utilisables à plus de trois fois le routage aléatoire côté serveur, contre le texte centré sur l’anglais de RSI-Jev.

• Modalité — Laya texte uniquement vs RSI-Jev texte plus jusqu'à quatre images par requête.

• Contexte — Laya 512 tokens en anglais, 1 024 en multilingue et jusqu'à 8 192 pour les documents longs, contre 32 768 tokens pour RSI-Jev, qui refuse plutôt que de tronquer.

• Latence — Laya 32,8 ms p50 sur un T4, 7,2 ms par question avec un lot de dix, contre RSI-Jev 22,5 ms à un effort faible et environ 40 ms à pleine profondeur, sur un H200.

La falaise du nombre d’options est la différence la plus marquée.

Les deux modèles définissent l'espace de réponses au moment de la requête, si bien qu'un nouveau schéma n'exige aucun réentraînement — c'est là l'avantage structurel partagé par toute cette famille. Mais ils allouent l'espace de réponses différemment, et cette différence se manifeste précisément sur les tâches qui caractérisent le routage en entreprise. Laya note chaque option à son propre token masqué, et les options partagent un budget de tête fixe : 192 tokens sur le checkpoint anglais, 256 sur le multilingue. Sur Banking77, avec 77 intentions, cela équivaut à environ trois ou quatre tokens par étiquette, et la précision tombe à 0,425. La fiche officielle de Convai documente cette falaise et propose la solution — augmenter head_max_len jusqu'à 512 et le contexte jusqu'à 1 024 ou plus pour que chaque étiquette ait de la place, ou découper un grand ensemble d'options en un choix en deux étapes, du plus général au plus fin.

Le chemin de service de RSI-Jev admet jusqu’à 5 120 options par question. Ce n’est pas un comparatif à armes égales avec le 0,425 de Laya — les deux ont été mesurés sur des bancs d’essai différents, et le plafond d’options est une limite de configuration, pas un score. C’est une indication sur le modèle qui ne s’effondrera pas lorsque votre taxonomie comporte cent entrées. Si vos questions à choix sont « facturation / technique / ventes / autre », l’un ou l’autre convient. S’il s’agit d’une bonne centaine de libellés d’intention, l’un de ces deux modèles doit être ajusté avant d’être utilisable, et l’autre non.

Latence, la question de la langue, et les images

L'argument de latence de Laya est le plus retentissant, et il est bien réel : 32,8 ms p50 pour une question unique sur une Tesla T4, 72,3 ms pour un lot de dix, et 337 ms pour cinquante — de 103 à 332 questions par seconde sur un seul GPU modeste. Les chiffres de RSI-Jev lui-même, mesurés sur un H200, sont de 22,5 ms à effort faible, 26,8 ms à effort moyen, 39,9 ms par défaut et 40,4 ms à pleine profondeur. Ces chiffres sont du même ordre de grandeur, et les deux sont des passes avant locales plutôt que des appels réseau, ce qui est la comparaison qui compte vraiment une fois qu'un point de terminaison hébergé est hors de l'équation. Notez ce que les deux font du temps : RSI-Jev peut s'arrêter délibérément à la couche 16 pour obtenir ces 22,5 ms et exécuter les 32 au complet lorsque la question est difficile, et Laya n'a pas de tel réglage — son (petit) encodeur est toujours exécuté au complet.

L’argument linguistique va dans l’autre sens et il est décisif pour quiconque n’est pas anglophone. Laya livre un routeur qui détecte le système d’écriture en bien moins d’une milliseconde et l’achemine vers le checkpoint multilingue, et son tableau publié montre que 45 langues sur 51 sont utilisables au-dessus de trois fois le hasard, contre 23 pour le checkpoint anglais seul. Sa fiche est aussi honnête sur les raisons pour lesquelles c’est important : le checkpoint anglais s’effondre sur les écritures non latines — le khmer obtient une exactitude de 0,000 avec une confiance de 0,952 —, si bien qu’un filtrage par confiance ne peut pas rattraper un routage erroné. RSI-Jev n’a pas d’argument linguistique de ce type ; c’est un modèle de texte centré sur l’anglais qui se trouve lire des images.

Pour les images, c'est l'inverse. RSI-Jev en accepte une à quatre par requête sous forme d'URL de données base64 et a obtenu 0,834 sur son jeu d'images de validation dans cette version ; les checkpoints livrés de Laya sont des classificateurs de texte, et bien que des ports communautaires comme laya-vision existent sur le Hub, ils ne sont pas le produit de l'éditeur. Si votre décision porte sur une photo, un graphique ou une capture d'écran, c'est la colonne d'un modèle et non celle de l'autre.

Aucun des deux n'a été évalué par rapport à l'autre.

Voici ce qu'une comparaison spécification par spécification dissimule discrètement : il n'y a pas de face-à-face entre ces deux modèles. Ce qui existe, c'est un face-à-face entre chacun d'eux et le même modèle fermé — le Jev 1.13 de TypeSafe — et aucun des deux ne peut être placé à côté de l'autre.

Convai en a publié un : sur typed-decisions, Jev 1.13.0 à 0,727 contre 0,766 pour Laya en mode routé ; sur Banking77, Jev 0,870 contre 0,425 pour Laya ; sur la calibration, Jev 0,246 contre 0,081 pour Laya après correction de température. Convai signale ses propres limites dans le même tableau : les chiffres de Jev sont publiés par des tiers, ils n'ont jamais eu d'accès API pour le mesurer, et les tailles d'échantillon comme les prompts diffèrent. La comparaison de RSI-Jev est le Decision Index, qui est le tableau public de RSI-Jev lui-même et ne comporte aucune entrée Jev. Ainsi, les seuls chiffres externes qui concernent ces deux modèles proviennent de bancs d'essai construits par les parties qui les vendent, et la lecture raisonnable de n'importe quel chiffre ci-dessus est « voici ce que le fabricant a mesuré, sur la tâche du fabricant. »

Ce que les deux projets font bien, et rarement, c’est publier leurs propres faiblesses. RSI-Jev nomme les cinq sources d’images non commerciales derrière ses versions de vision et dit clairement que la question de savoir si les pondérations entraînées sur celles-ci héritent de ces conditions n’est pas tranchée ; il signale une régression de calibration dans sa plus récente version et qualifie son seuil de sortie par défaut de non confirmé. Laya documente que ses checkpoints de base se situent sous la ligne de base majoritaire, que ses questions de score ordinal sont sa primitive la plus faible, que son noul peut suivre ses propres étiquettes d’option plutôt que l’état, et que l’un de ses champs de réponse ne porte aucun signal utilisable. Cette honnêteté est la chose la plus utile à hériter de l’un ou l’autre projet : vérifiez les valeurs de confiance sur vos propres cas étiquetés avant d’automatiser à partir de celles-ci.

Où se trouve réellement le contrat qu’ils copient

Ces deux modèles existent parce qu'un format d'échange valait la peine d'être copié. Le Jev de TypeSafe définit la forme de la requête — état, questions, trois primitives typées — et la forme de la réponse, et Laya et RSI-Jev l'implémentent tous deux, de sorte qu'un client existant fonctionne en changeant d'URL de base. Ce modèle de référence, typesafe/jev-1.13, est celui des trois que nous servons : il figure dans notre catalogue sur le point de terminaison systemone dédié, un POST vers /v1/systemone, sans streaming, avec un contexte de 65 536 jetons, à 0,042 $ par million de jetons d'entrée, la sortie étant facturée à zéro. Ni Laya ni RSI-Jev ne figurent dans notre catalogue — tous deux sont des téléchargements, et c'est là tout leur intérêt.

L'aspect pratique de tout cela importe davantage que la comparaison. Les couches de décision ne sont presque jamais seules dans une pile ; elles siègent à côté d'un modèle génératif qui rédige la réponse, le résumé ou le code. Disposer du contrat de référence sur la même clé que plus de 200 autres modèles, au prix catalogue du fournisseur répercuté avec 0 % de marge, signifie qu'un changement de tarif du fournisseur vous parvient le jour même, et le basculement automatique signifie que la moitié générative de cette paire n'est pas un point de défaillance unique pendant que vous déterminez si la moitié décisionnelle bon marché est suffisamment bonne. Si vous décidez qu'un encodeur auto-hébergé 421M ou qu'un checkpoint 4,69B est le bon choix, vous voulez toujours que le contrat auquel il s'adresse soit joignable depuis le même endroit — et si vous préférez n'exécuter ni l'un ni l'autre, le modèle que tous deux copient se trouve à une requête d'ici.

Lequel télécharger ?

Choisissez Laya si vous disposez de données étiquetées, d’une taxonomie qui évolue peu et d’un mélange de langues qui n’est pas uniquement anglais. Il est suffisamment petit pour en exécuter un grand nombre, suffisamment rapide pour être placé devant chaque requête, et conçu dès le départ pour être affiné — le score affiné de 0,766 contre 0,362 en zero-shot constitue tout l’argument. Prévoyez un budget pour l’exécution de l’entraînement, l’étiquetage et le réajustement de la température par type de question, qui fait passer son erreur de calibration de 0,466 à 0,081, et gardez les ensembles d’options en dessous d’une vingtaine d’étiquettes, ou augmentez le budget de la tête avant de faire confiance à une classification à grande échelle.

Choisissez RSI-Jev v6.1-VL si vous voulez qu’une décision fonctionne sans aucun entraînement préalable, si vos questions portent parfois sur une image, si vos ensembles d’options sont vastes, ou si vous voulez échanger de la latence contre de la profondeur par requête. Attendez-vous à exécuter un checkpoint de 9,7 Go plutôt qu’un de 400 M, attendez-vous à un projet qui a publié huit versions en treize jours et qui pourrait en publier une autre pendant que vous évaluez celle-ci, et attendez-vous à vérifier vous-même sa calibration — la fiche de cette version dit elle-même qu’elle s’est dégradée, et non améliorée.

Quel que soit votre choix, les deux mêmes choses sont vraies. Aucun des deux modèles ne génère de texte, donc aucun ne peut échouer en émettant un champ malformé ; les deux renvoient des probabilités, et la probabilité est la partie qui doit être validée par déploiement plutôt que reprise d’une fiche. Et tous deux ont déplacé l’intéressante question d’une couche de décision de « à qui appartient l’API » à « à qui appartiennent les poids » — ce qui est une meilleure question à poser, et à laquelle ce duo répond très différemment.