RSI-Jev vs Jev 1.13 : L'un que vous téléchargez, l'autre que vous appelez

Mettez RSI-Jev v6.1-VL 4B et Jev 1.13 côte à côte et la première chose qu'un appelant remarque, c'est qu'il s'agit de la même requête. Donnez à l'un ou à l'autre un état et un ensemble de questions typées — un oui/non, un choix parmi k, une note sur une grille — et les deux renvoient une probabilité calibrée pour chaque option, en une seule passe avant, sans texte généré à analyser. Ce n'est pas un hasard : RSI-Jev est conçu pour parler délibérément le format de transmission de Jev, de sorte qu'un client écrit pour l'API de TypeSafe fonctionne avec lui en changeant l'URL de base. Ce qui n'est pas identique, c'est tout ce qui entoure l'appel. Jev 1.13 est le modèle commercial fermé de TypeSafe, servi depuis un point de terminaison dont vous mesurez la consommation ; RSI-Jev v6.1-VL est un checkpoint de 4,69 milliards de paramètres dont les poids sont sous Apache-2.0, que vous téléchargez et hébergez sur votre propre matériel. Ni l'un ni l'autre n'est une version rebaptisée de l'autre, aucun des deux fournisseurs ne cautionne l'autre, et presque tous les chiffres de cette comparaison proviennent de la partie qui les a produits.

La date indiquée dans le sujet compte, car ce projet publie une version presque tous les jours. RSI-Jev v6.1-VL 4B a été publié le 2026-10-07 par le tiers Shanghua-Gao/RSI-Jev, un projet — une boucle de recherche auto-améliorante qui entraîne des modèles de décision de style Jev et publie chaque bras qui a échoué ainsi que ceux qui ont gagné. C'est la huitième version en treize jours sur cette ligne, et c'est une moyenne pondérée de la version précédente avec un second fine-tuning du même Qwen3.5-4B-Base. Jev 1.13 est le modèle de TypeSafe AI, lancé le 2026-09-15 et présent dans notre propre catalogue depuis le 2026-09-24. Les deux dates comptent ci-dessous, car une comparaison avec un projet qui évolue quotidiennement a une durée de validité mesurée en jours.

Ce que les deux sont réellement, en une ligne chacun

Jev 1.13 est un modèle de décision hébergé derrière un endpoint dédié — POST /v1/systemone, sans streaming, avec un budget d'entrée d'environ 64 000 tokens couvrant l'état et l'ensemble de vos questions, facturé à 0,042 $ par million de tokens d'entrée, la sortie étant facturée à zéro puisqu'il n'y a pas de tokens de sortie. Son architecture, son nombre de paramètres et son compute d'entraînement ne sont pas divulgués ; TypeSafe a déclaré que les détails restent confidentiels et qu'un article pourrait suivre. Vous ne l'exécutez pas. Vous l'appelez, et chaque appel est une requête réseau mesurée.

RSI-Jev v6.1-VL est l’autre configuration dans son intégralité. Il s’agit d’une tour Qwen3.5-4B-Base affinée de bout en bout, avec des têtes de décision aux couches 16, 20 et 32, servie à partir d’un checkpoint autonome de 9,7 Go en bf16. Le nombre de paramètres est de 4,69 milliards et il est utile de savoir où ils se répartissent : 3,57 milliards dans les 32 couches de décodeur, 0,64 milliard dans les embeddings de jetons, 0,33 milliard dans la tour de vision, 0,05 milliard dans la tête de décision principale et 0,10 milliard dans les deux têtes de sortie anticipée. Il n’y a ni mélange d’experts, ni second modèle. Vous l’installez avec une commande pip depuis le dépôt, lancez son serveur, et à partir de ce moment, la décision ne quitte jamais votre infrastructure.

• Qui l'exécute — un point de terminaison hébergé facturé à l'usage que vous ne contrôlez pas, par opposition à un checkpoint de 9,7 Go sur votre propre GPU, Apple Silicon ou CPU.

• Structure tarifaire — 0,042 $ par million de jetons d'entrée, sortie gratuite, paiement par appel contre zéro à la marge, plus le coût de la machine et de l'exploitation.

• Budget d'entrée — environ 64 000 jetons par requête sur le modèle hébergé, contre 32 768 jetons de texte plus un budget d'image sur le checkpoint, tout contenu plus long étant refusé plutôt que tronqué.

• Poids et licence — fermé, taille non divulguée contre des poids Apache-2.0, code MIT, 4,69 milliards de paramètres.

• Modalité — texte pour le contrat de Jev par rapport à du texte plus jusqu'à quatre images par requête sur les versions vision de RSI-Jev.

• Propriété — le modèle commercial de TypeSafe AI par rapport à un projet de recherche tiers qui indique dans sa propre ligne de licence qu'il « n'est pas affilié à TypeSafe AI ».

Le score sur le tableau de RSI-Jev, et pourquoi il ne s’agit que d’une demi-comparaison

Le chiffre que le projet met en avant est son score Decision Index 0.3 : 50,98 pour v6.1-VL 4B, contre 46,23 pour la version précédente. Il s'agit d'une exécution complète de la configuration par défaut — 140 178 requêtes, couverture 1,0 — et sur le tableau public du projet lui-même, daté du 2026-10-06, il égale le meilleur modèle 4B de ce tableau (50,98 contre 50,82 pour ezjev 4B s2, ce que le kit considère comme une égalité à 0,25) et occupe la 27e place sur 113 au total. Sur l'ancien Decision Index 0.2.1, il affiche 50,74 contre 46,24 pour v6.0-VL. Sa suite de quinze benchmarks, rapportée sans la tâche open_jev_ood dont il a été constaté qu'elle chevauchait des lignes d'entraînement, est de 0,793, et son ensemble mis de côté est de 0,729.

Chacun de ces chiffres est propre à RSI-Jev, mesuré sur le banc d’essai de RSI-Jev. Le Decision Index est un classement public de benchmarks, mais on n’y trouve aucun relevé de Jev 1.13, car la suite du projet a été conçue pour évaluer des points de contrôle de décision ouverts et Jev est un point de terminaison fermé. La tentation d’opposer 50,98 au 0,727 de Jev sur le benchmark des décisions typées et de déclarer un vainqueur est donc exactement l’erreur à éviter : ces deux nombres proviennent de bancs d’essai différents, de tailles d’échantillon différentes et de données différentes, et personne n’a fait tourner un même banc d’essai sur les deux modèles.

Le seul face-à-face qui existe est celui de Laya, et non celui de RSI-Jev.

Il existe une comparaison publiée qui place effectivement une valeur Jev à côté d’un checkpoint ouvert, et elle n’a été menée par aucune des deux parties en présence. Convai Innovations, les créateurs du modèle de décision Laya, ont compilé les valeurs Jev 1.13.0 publiées par TypeSafe en regard des leurs et ont eux-mêmes signalé les limites : les valeurs Jev sont publiées par des tiers et n’ont jamais été mesurées par Convai, les tailles d’échantillon et les prompts diffèrent, et le fournisseur ne répertorie pas ses propres benchmarks pour le modèle. Ce tableau mérite d’être lu pour la calibration, pas pour rendre un verdict — et il n’inclut pas RSI-Jev du tout, car RSI-Jev n’existait pas au moment de sa publication.

Ce que cela montre, c'est la forme de la question « hébergé contre ouvert » qu'un lecteur soupèse réellement. Le modèle hébergé l'emporte là où l'espace des options est vaste et que le modèle doit maintenir stable un large ensemble de réponses ; les modèles ouverts gagnent sur la latence brute par appel parce qu'il n'y a pas de réseau sur le chemin. Rien dans ce schéma ne vous dit lequel de ces deux modèles spécifiques est meilleur pour votre tâche, et la position honnête est que la réponse n'existe pas encore publiquement.

Ce que le checkpoint apporte que l'endpoint ne peut pas apporter

Le meilleur argument en faveur de RSI-Jev n'est pas un score. C'est que les poids résident sur votre disque. Pour une décision de routage prise à partir d'un dossier médical, d'un document juridique ou de l'historique de compte d'un client, « les données ne quittent jamais les murs » n'est pas une préférence que l'on arbitre contre un point de benchmark — c'est une exigence absolue, et aucun point de terminaison hébergé, à quelque prix que ce soit, n'y répond. Cette même propriété supprime la limite de débit : la documentation du fournisseur relative au modèle hébergé indique que ses limites sont ajustées dynamiquement et peuvent changer sans préavis, et un checkpoint auto-hébergé ne connaît pas d'autre plafond que celui de votre matériel.

La deuxième chose que le point de contrôle permet d'obtenir, c'est le contrôle de la profondeur, et c'est inhabituel. Parce que les têtes de décision se situent à trois profondeurs, un réglage effort détermine le nombre de couches qu'une requête peut utiliser : faible s'arrête à la couche 16 pour une médiane d'environ 23 ms, moyen à 20 pour 27 ms, élevé à 32 pour environ 40 ms, et auto répond dès la première sortie suffisamment sûre, avec une moyenne de 19,5 couches sur 32 sur la suite de tests du projet. Ces latences sont les chiffres propres au projet, mesurés sur un seul H200 en bf16, et ne doivent pas être mélangées à un quelconque chiffre provenant d'un service hébergé — une passe avant locale et un appel d'API facturé ne sont pas la même mesure, et la documentation de RSI-Jev précise elle-même explicitement que sa comparaison antérieure avec la latence publiée de Jev opposait un travail local sur GPU à un aller-retour réseau.

La troisième chose, ce sont les images. Le contrat de Jev, c’est du texte en entrée, du JSON structuré en sortie. Les versions vision de RSI-Jev acceptent une à quatre images par requête sous forme d’URL de données base64, l’état se référant à chacune au moyen d’un marqueur, et v6.1-VL obtient un score de 0,834 sur l’ensemble d’images tenu à l’écart du projet. Si votre décision est « la photo montre-t-elle des dommages visibles », c’est une capacité que le contrat hébergé n’offre pas du tout.

Ce à quoi vous renoncez est réel, lui aussi, et le projet le publie. La calibration s'est dégradée dans cette version, pas améliorée : l'erreur de calibration attendue finale est de 0,048 à la couche 32 et de 0,055 avec auto, contre 0,036 et 0,024 pour la version précédente. Le seuil unique par défaut de 0,95 est livré explicitement non confirmé — c'est la solution de repli d'une règle de sélection dont le choix propre, 0,85, a manqué le plafond de profondeur du projet sur la moitié de ses données de développement. Les sorties anticipées ne lisent que du texte, donc toute question comportant une image exécute les 32 couches, quel que soit l'effort. Et cinq des sources d'entraînement d'images sont non commerciales ou réservées à la recherche, le projet déclarant clairement que la question de savoir si des poids entraînés sur des données non commerciales héritent de ces conditions n'est pas tranchée.

Où appeler la version hébergée, et où ne pas le faire

C'est la partie de la comparaison qui nous concerne directement, aussi vaut-il la peine d'être précis. Nous servons le modèle commercial de TypeSafe sous la référence typesafe/jev-1.13 sur le point de terminaison dédié systemone — un POST vers /v1/systemone plutôt que la forme chat-completions d'OpenAI, sans streaming, dans la limite du contexte de 65 536 tokens que notre catalogue liste. C'est la même forme de requête et de réponse que RSI-Jev implémente, issue du modèle dont le projet copie le contrat. RSI-Jev lui-même, nous ne l'hébergeons pas ; il n'y a pas d'id rsi-jev ni d'id shgao dans notre catalogue, et un lecteur qui veut ce modèle le télécharge.

La raison pour laquelle cette distinction compte ici est étroite et concrète. Une couche de décision représente rarement l’intégralité d’un workflow — elle se trouve généralement à côté d’un modèle génératif qui rédige la réponse, le résumé ou le code. Cela a historiquement impliqué deux contrats. Ce n’est plus une obligation pour la partie hébergée : Jev 1.13 s’utilise avec la même clé que plus de 200 autres modèles au tarif catalogue du fournisseur répercuté avec 0 % de marge, donc si TypeSafe modifie un tarif, le changement est effectif de notre côté le jour même plutôt qu’au cycle de facturation suivant. La partie auto-hébergée n’a jamais connu ce problème, puisque c’est vous, le fournisseur. La façon la plus propre de trancher entre les deux est d’essayer d’abord le contrat commercial sur une poignée de vos propres cas étiquetés, de voir si le comportement par défaut est suffisamment bon pour être automatisé, et seulement ensuite d’évaluer si exécuter vous-même un checkpoint de 4,69 B en vaut l’exploitation.

Lequel vous devriez réellement choisir

Choisissez RSI-Jev v6.1-VL 4B si la décision doit rester à l'intérieur de votre périmètre, si vous avez besoin d'une décision sur une image ainsi que sur du texte, si vos ensembles d'options se comptent en centaines (le checkpoint admet jusqu'à 5 120 options par question), ou si vous souhaitez ajuster la profondeur et la latence par requête. Lancez-vous en sachant que vous adoptez un projet qui a changé huit fois en treize jours, que sa dernière version a troqué la calibration contre la précision, et que sa propre fiche nomme les parties de la politique de sortie qu'il n'a pas pu confirmer.

Choisissez Jev 1.13 si vous voulez que la décision fonctionne sans pile de service, si vous appréciez un endpoint que quelqu’un d’autre maintient en fonctionnement, et si le prix de 0,042 $ par million de tokens d’entrée — sans tokens de sortie à mesurer — est bon marché au regard de votre volume d’appels. Sachez, en vous engageant, que vous appelez un modèle fermé dont la taille n’est pas divulguée, dont les limites de débit peuvent changer sans préavis et dont les benchmarks publiés ne sont pas quelque chose que vous pouvez réexécuter.

Ce qu’ils ont en commun est plus utile que ce qui les sépare, et c’est la raison pour laquelle une comparaison comme celle-ci vaut la peine d’être écrite. Aucun des deux modèles ne génère de texte, donc aucun n’introduit le type de défaillance propre à un modèle qui oublie de fermer une accolade ou invente un champ. Les deux renvoient des probabilités, et dans les deux cas, la probabilité est la partie que vous devez valider sur vos propres données étiquetées avant d’automatiser en vous appuyant dessus — la latence est déjà banalisée, et la valeur de confiance est ce qui doit se gagner à chaque déploiement. Que vous vous situiez d’un côté ou de l’autre de la frontière entre téléchargement et appel, testez d’abord la calibration.