UserRepGen-4B vs Intern-Decision-4B : deux équipes ont affiné le même modèle de base 4B et ne sont tombées d'accord sur rien

Deux sorties discrètes, à cinq semaines d'intervalle, issues du même point de contrôle. microsoft/UserRepGen-4B a été mis en ligne sur Hugging Face le 14 octobre 2026 sous la forme d'un dépôt bfloat16 de 9,1 GB, sans la moindre annonce ; internlm/Intern-Decision-4B est apparu le 26 septembre 2026 à 05:36:37 UTC dans une fenêtre de quarante secondes qui a également produit un 0,8B et un 2B, tout aussi peu annoncés. Tous deux sont des fine-tunings LoRA de Qwen3.5-4B, tous deux sont purement textuels bien qu'ils portent une tour de vision qu'ils n'utilisent jamais, tous deux renvoient une structure rigide plutôt qu'une réponse — et ils ne pourraient pas être plus en désaccord sur la finalité du modèle. Intern-Decision-4B n'écrit jamais le moindre token. UserRepGen-4B n'écrit rien d'autre que des tokens. Tout le reste de cette comparaison découle de cette unique divergence.

L’un est un buteur, l’autre est un écrivain.

La fiche d'InternLM est d'une franchise inhabituelle sur son propre fonctionnement : « Cette API effectue une notation structurée des candidats. Elle n'appelle pas generate() et n'échantillonne pas de texte libre. » Vous lui fournissez un état, un schéma de questions nommées et un ensemble de réponses candidates. Il associe les options à des symboles d'un seul token, exécute une seule passe avant causale, lit les logits à la position immédiatement avant chaque placeholder, applique une température ajustée de 1,99241824 et renvoie une probabilité calibrée par option. Une seule passe. Pas d'échantillonnage, pas de boucle de décodage, pas de texte.

RepGen-4B l'inverse. On lui remet une conversation terminée. Il émet jusqu'à 1 024 tokens de prose répartis sur deux champs JSON — une description de tâche et une description user_behavior — et la fiche est tout aussi directe dans l'autre sens : le modèle « génère des représentations, pas des tours d'utilisateur simulés », il n'exécute pas la tâche de l'utilisateur, et il n'est pas le simulateur.

Mettez les deux côte à côte et les conséquences techniques apparaissent immédiatement.

• Ce que vaut la sortie — Intern-Decision-4B renvoie un nombre que vous pouvez comparer à un seuil, moyenner et auditer. UserRepGen-4B renvoie un paragraphe dont la qualité ne peut être notée que par un juge LLM, ce qui correspond exactement à la façon dont Microsoft l'a évalué.

• Coût par appel — une seule passe avant sur une invite fixe contre jusqu'à 1 024 jetons générés. C'est la différence entre environ 44 millisecondes et une exécution de décodage complète, et c'est pourquoi le modèle de décision peut se trouver dans une boucle où le modèle de représentation ne le peut pas.

• Où réside le sens — InternLM a décidé que la réponse devait déjà être énumérable dans le prompt, si bien que le modèle n'a plus qu'à classer. Microsoft a décidé que la réponse est latente dans une conversation, si bien que le modèle doit écrire cela. Le classement est borné et vérifiable. L'écriture est ouverte et exige un juge.

Les plafonds d'entrée, et ce qu'ils vous disent sur les paris

Les deux cartes publient une limite stricte, et les comparer est le moyen le plus rapide de voir à quel point les deux équipes ont défini différemment le périmètre du même modèle de base.

Intern-Decision-4B refuse de travailler au-delà de 8 192 jetons. C’est un refus, pas une troncature — un choix de conception qui signifie que le modèle est destiné aux décisions suffisamment compactes pour être énoncées complètement dans une invite.

UserRepGen-4B est entraîné sur une séquence de 9 216 tokens : jusqu'à 8 192 tokens de prompt couvrant la conversation, plus 1 024 tokens de complétion pour la représentation. La fiche ajoute que l'utilisation d'un contexte étendu au-delà de cette longueur « n'est pas prise en charge par cette version », et que les performances en contexte long n'ont jamais été évaluées séparément. Ainsi, le même plafond de 8 192 tokens apparaît des deux côtés, atteint indépendamment, par deux équipes qui n'avaient vraisemblablement aucune visibilité sur le travail de l'autre.

Cette convergence est le résultat utile. Un fine-tuning de 4B sur cette base, au milieu de 2026, est un composant dimensionné pour une seule invite bien formée — pas un moteur à long contexte. Les deux versions publiées sont honnêtes à ce sujet. Aucune ne le cache derrière une fenêtre annoncée plus grande.

Tous deux ont publié une histoire de calibration, et ce n’est pas la même histoire.

C’est là que le sourcing devient délicat, car les deux évaluations ne sont pas commensurables et aucune n’a été reproduite en dehors de son propre laboratoire.

Intern-Decision-4B publie un benchmark à sept suites, sur lequel il obtient une moyenne de 90,02 — la meilleure ligne de son propre tableau, devant Intern-Decision-2B à 84,68 et Intern-Decision-0.8B à 79,38, tous mesurés sur les harnais d’InternLM. Il publie aussi sa calibration : un score de Brier de 0,347 et une erreur de calibration attendue de 0,065. Un pilote distinct de 96 cas utilisant des distributions de référence exactes passe de 0,628 de Brier et 0,213 d’ECE à 0,550 et 0,089 après application de sa température ajustée. Chacun de ces chiffres provient du fournisseur lui-même, et personne en dehors d’InternLM ne les a vérifiés.

UserRepGen-4B publie un tableau de fidélité sur une échelle de jugement de 1 à 10 — 4,95 en best-of-1 et 6,02 en best-of-3, contre 3,90 et 4,90 pour GPT-5.5 utilisé tel quel et 3,41 et 4,42 pour la base non ajustée. Chacun de ces chiffres est celui de Microsoft, produit avec GPT-5.4 mini agissant simultanément comme simulateur, assistant et juge, et personne en dehors de Microsoft ne les a vérifiés.

L’asymétrie qui compte n’est pas celle des scores — ils mesurent des choses différentes sur des échelles différentes. Elle tient au fait qu’Intern-Decision-4B publie une règle de score propre par rapport à des distributions de référence connues, falsifiable par construction, tandis que UserRepGen-4B publie un score de juge LLM, qui n’est falsifiable qu’en exécutant un autre juge. InternLM a construit un modèle qui peut être audité avec de l’arithmétique. Microsoft en a construit un qui doit être audité avec un autre modèle. Étant donné que les deux affirment avoir battu les références de base, cette différence d’auditabilité fait réellement partie du choix qui s’offre à vous.

Le constat de confidentialité que seul l'un d'entre eux imprime

La fiche d'Intern-Decision-4B ne contient aucune section sur la confidentialité d'importance. Celle d'UserRepGen-4B contient un chiffre qui devrait faire réfléchir n'importe quelle équipe : sur plus de 147 utilisateurs, un sélecteur chargé de déterminer laquelle de quatre conversations provenait de la même personne atteint 51,02 % en utilisant les descriptions du comportement du modèle, contre 44,22 % avec les conversations brutes complètes et 25 % au hasard. La représentation compressée identifie la personne mieux que le matériel dont elle est issue.

Microsoft le qualifie de risque de liaison et déclare sans détour que les représentations ne sont pas des données anonymisées. C'est la bonne façon de procéder, et c'est une mise en garde qui s'applique à toute la classe de modèles — y compris le modèle de décision, dont les entrées sont elles-mêmes des conversations sur la situation des personnes. La seule différence est que l'une des fiches le dit et pas l'autre, ce qui n'est pas la même chose qu'un modèle sûr.

Aucun des deux n’est une API, mais la base qu’ils partagent est

Ces deux éléments sont des téléchargements, pas des endpoints. Intern-Decision-4B est livré sous la forme d’une classe Python DecisionEngine chargée une fois puis réutilisée, son Space de démonstration renvoie 401 et son lien GitHub renvoie 404 ; UserRepGen-4B est livré avec un unique fichier safetensors non quantifié et un example.py. OrcaRouter ne propose ni l’un ni l’autre. Si vous dites que l’un ou l’autre est disponible via une API hébergée aujourd’hui, vous décrivez un projet plutôt qu’un fait.

Ce qui est réellement appelable, c'est le checkpoint à partir duquel les deux ont bifurqué. La famille de Qwen3.5-4B figure dans notre catalogue — Qwen3.5-Flashavec un contexte de plus d'un million de tokens, à 0,10 $ par million de tokens d'entrée et 0,40 $ par million de tokens de sortie, Qwen3.5-35B-A3Bà 0,057 $ et 0,459 $, Qwen3.5-27Bà 0,086 $ et 0,688 $ — tous sur la même clé, tous au prix catalogue du fournisseur, sans rien de plus. C'est utile pour la partie du pipeline qui n'est pas constituée de ces deux modèles : le côté assistant d'une simulation, ou l'étape de raisonnement autour d'un appel de décision, peut passer par un seul point de terminaison pendant que vous évaluez le modèle affiné localement.

Comment choisir

Si votre problème est une question bornée avec des réponses énumérables et que vous avez besoin d'un nombre calibré dix mille fois par seconde, Intern-Decision-4B est le seul modèle ici qui le fait, et le fait qu'il n'échantillonne jamais est une fonctionnalité plutôt qu'une limite. Si votre problème est que vous voulez un simulateur qui se comporte comme un véritable utilisateur, UserRepGen-4B est le seul modèle ici entraîné pour cela, et l'ampleur du gain qu'il rapporte face à GPT-5.5 est la raison de s'y intéresser. Personne ne devrait choisir l'un ou l'autre sur la base des chiffres de l'autre, car ils n'ont jamais mesuré la même chose. Ce qui trancherait la comparaison serait un seul examen externe portant sur l'une ou l'autre des fiches — et pour deux versions publiées dans un silence total, à quelques semaines d'intervalle, ni l'une ni l'autre n'en a fait l'objet.

Deux sorties discrètes rappellent aussi à quel point une grande partie de cette classe de modèles est livrée sans documentation, et les défaillances qui s'ensuivent sont recensées dans l'OrcaRouter AI Incident Archive, où chaque entrée comporte ses propres sources, son niveau de gravité, sa note de confiance et son indicateur de contestation.