Intern-Decision-2B a été publié discrètement sur Hugging Face. Le lien GitHub sur sa fiche vient tout juste de cesser de renvoyer une 404.

Plus tôt aujourd’hui, la fiche de modèle de internlm/Intern-Decision-2B renvoyait vers trois endroits pour plus d’informations, et deux d’entre eux étaient morts : le Space de démonstration répondait HTTP 401, et github.com/internlm/Intern-Decision renvoyait 404 à quiconque cliquait dessus. Depuis 08:58 UTC, le dépôt derrière ce deuxième lien existe — public, avec trois commits, contenant le code d’entraînement, deux backends d’inférence, un ensemble d’évaluation avec 10 751 lignes de test, un benchmark de calibration de 96 cas et le guide de reproduction. C’est la seule chose qui ait changé à propos de ce modèle depuis son apparition sur Hugging Face à 05:36 UTC le 26 septembre 2026, et cela suffit à faire passer Intern-Decision-2B de « un checkpoint avec un README inaccessible » à « un checkpoint que vous pouvez réellement inspecter, reproduire et contester. »

Les poids eux-mêmes sont inchangés et sans ambiguïté. Intern-Decision-2B est un modèle de décision structuré multimodal de 2 213 241 664 paramètres, affiné à partir de Qwen/Qwen3.5-2B — la base Alibaba du 28 février 2026 — publié sous Apache-2.0 avec la licence Qwen amont conservée à côté sous le nom de LICENSE-QWEN. C'est la taille intermédiaire des trois qu'InternLM a publiées en quarante secondes : Intern-Decision-0.8B à 05:35:57, celui-ci à 05:36:19, et Intern-Decision-4B à 05:36:37. Il n'y a toujours aucune annonce, d'aucune sorte, derrière aucun d'entre eux.

Ce qui rend la taille intermédiaire digne d’un article à part, c’est qu’elle marque l’endroit où la famille cesse de se comporter de manière prévisible. Selon les propres chiffres d’InternLM, c’est la plus rapide des trois et la plus mal calibrée des trois, et ces deux faits méritent d’être compris avant de télécharger quatre gigaoctets et demi de quoi que ce soit.

Qu'est-ce qui est confirmé, et qu'est-ce qui ne relève que du discours du fournisseur ?

Deux catégories, et il faut les garder séparées.

Confirmé, car il s'agit d'un listing de fichiers ou d'une réponse HTTP : le nombre de paramètres (2 592 F32 plus 2 213 239 072 poids BF16) ; la carte des shards (un shard de langage de 3,76 Go, une tour de vision de 612,5 Mo, un projecteur de 50,3 Mo, environ 4,43 Go de tenseurs et à peu près 4,46 Go de dépôt) ; la paire de licences ; le modèle de base ; l'architecture sous-jacente (un Qwen3_5ForConditionalGeneration avec 24 couches, taille cachée 2 048, 8 têtes de requête contre 2 têtes clé-valeur, dimension de tête 256, un motif répétitif de trois couches d'attention linéaire pour une couche d'attention complète, une couche de prédiction multi-jetons conservée, et un plafond d'embedding de 262 144 positions) ; l'existence du dépôt ; et le fait que la collection de modèles sur huggingface.co/collections/internlm/intern-decision se résout désormais et liste les trois checkpoints.

Signalé par le fournisseur et non reproduit : chaque chiffre de précision, chaque chiffre de latence et la température d’étalonnage. Il n’y a pas d’article, pas d’entrée arXiv, pas de billet de lancement, pas de journal des modifications et pas d’évaluation indépendante — une recherche de la chaîne « Intern-Decision » ne renvoie rien qui concerne ce modèle. Le Space de démo répond toujours 401, ce qui signifie qu’il n’est pas public, et non qu’il est cassé. Le checkpoint 2B a un like et zéro téléchargement. Personne en dehors d’InternLM ne l’a exécuté.

Le contrat d'inférence, dans l'ordre où cela se produit

Le fichier le plus informatif du dépôt n'est pas la carte. C'est src/inference/engine.py et le fichier inference.py fourni sur le Hub, car à eux deux, ils documentent un contrat plutôt qu'un prompt.

• Vous fournissez l'état — le matériau à juger — un questions schéma, et éventuellement jusqu'à huit images. D'une à seize questions, jusqu'à 62 options chacune.

• Les options de chaque question sont associées à des symboles à token unique : A–Z, puis a–z, puis 0–9. Le plafond de 62 options n'est pas une préférence de conception, c'est exactement le nombre de symboles à token unique que le contrat peut adresser.

• Le prompt système, l'état, le schéma et un squelette JSON complet d'assistant sont rendus avec un <decision> espace réservé par champ. Le template de chat du checkpoint et le bloc de réflexion vide sont conservés tels quels.

• Une seule passe avant causale est exécutée. Les logits sont lus à la position immédiatement avant chaque espace réservé — pas après, ni sur un jeton généré.

• Une softmax est calculée uniquement sur les symboles candidats autorisés de ce champ, la calibration du checkpoint est appliquée, et les symboles sont reconvertis en vos valeurs d'option d'origine.

La fiche est sans détour sur ce dont il s'agit : « Cette API effectue une notation structurée des candidats. Elle n'appelle pas generate() et n'échantillonne pas de texte libre. » Un DecisionEngine(max_length=8192) refuse les entrées surdimensionnées plutôt que de les tronquer, si bien qu'une requête qui ne tient pas échoue bruyamment au lieu de perdre discrètement son dernier paragraphe. La liste des backends est honnête elle aussi — backend="hf" est celui par défaut et le seul implémenté dans le dépôt Hugging Face, ce qu'il vaut la peine de savoir car la version GitHub livre également un backend XTuner, et les deux ne sont pas numériquement identiques. Le guide d'évaluation d'InternLM le dit lui-même : « Des différences de noyau et de BF16 peuvent modifier les probabilités et parfois les étiquettes. »

L'anomalie au milieu

Placez les trois points de contrôle côte à côte dans le propre tableau d'InternLM, et la forme est assez étrange pour faire toute l'histoire.

• Moyenne sur sept suites — Intern-Decision-0.8B 79,38, Intern-Decision-2B 84,68, Intern-Decision-4B 90,02. Ordonné, comme on peut s’y attendre en augmentant les poids.

• Latence sur un RTX 4090 — 33,98 ms en moyenne pour le 0,8B, 33,28 ms pour le 2B, 44,16 ms pour le 4B. La taille intermédiaire est la plus rapide des trois, avec une marge suffisamment faible pour être du bruit sur un seul GPU, mais cohérente entre la moyenne, la médiane (33,15 ms) et le P95 (33,55 ms).

• Score de Brier, plus bas est mieux — 0,530, 0,437, 0,347. Monotone avec la taille, comme l’est généralement une règle de notation propre.

• Erreur de calibration attendue, plus faible est mieux — 0,066 pour le 0,8B, 0,100 pour ce 2B, 0,065 pour le 4B. La taille intermédiaire est la pire, et elle est pire que le modèle qui fait la moitié de sa taille.

Cette dernière ligne est la plus intéressante, et les températures ajustées la corroborent plutôt que de l'expliquer. Chaque point de contrôle porte sa propre température ajustée par NLL : 2,747760550703 pour le 0.8B, 2,100509348278 pour le 2B, 1,992418 pour le 4B. Chacune a été ajustée sur 1 728 cas de calibration désignés, avec 1 693 mis de côté, en minimisant la log-vraisemblance négative au cours d'une recherche de température inverse dans l'intervalle [0,01 ; 100], les étiquettes de la suite de tests étant délibérément tenues à l'écart de l'ajustement. La température du 2B se situe entre celles de ses deux homologues, ce à quoi on s'attendrait si l'anomalie était un artefact d'ajustement. Ce n'est pas le cas : la valeur ajustée varie de façon monotone avec la taille, alors que l'erreur après calibration ne l'est pas. D'après la propre mesure d'InternLM, le point de contrôle de 2,2 milliards de paramètres est le moins fiable des trois lorsqu'il vous indique à quel point il est confiant.

Deux réserves avant d'en faire une conclusion. L'ECE avec dix intervalles de largeur égale et une confiance de probabilité maximale est une statistique bruitée sur la petite suite qu'utilise ce tableau — Jevbench-Hard, 111 éléments, donc toute la colonne ECE repose sur une centaine de questions et un choix de découpage en intervalles. Et internlm/Intern-Decision-2B est la seule des trois cartes à ne pas comporter la section de calibration supplémentaire que possède la carte 4B, il y a donc ici moins de documentation, pas plus. Interprétez le 0,100 comme une raison d'ajuster votre propre température plutôt que comme un verdict sur les poids.

Ce que le dépôt apporte, et ce qu'il dissimule encore

La version publiée sur GitHub est plus complète que la fiche du modèle, qui est elle-même instructive — un laboratoire qui visait un artefact d'article ne livre généralement pas un générateur d'étalonnage déterministe et un ensemble d'évaluation à vérification par hachage en plus du lanceur d'entraînement.

Ce qui est désormais public : le code d'entraînement et l'objectif de jeton suivant masqué (les symboles de réponse de référence n'apparaissent que dans les étiquettes, jamais dans l'entrée ; la réponse de chaque champ est prédite par le logit immédiatement avant son marqueur, et tous les champs partagent une seule passe avant) ; les sept suites de précision avec hachages vérifiés par SHA-256 et nombres de lignes ; le code de notation ; les scripts d'ajustement de température et de rejeu, où il est affirmé que le rejeu ne change aucune décision ; le benchmark de calibration de distribution à 96 cas avec son générateur et son évaluateur hors ligne ; et une démo navigateur servie sur loopback avec POST /v1/decisions (alias /v1/jev).

Ce qui est explicitement exclu, selon les termes mêmes du dépôt : « Les données d'entraînement, les enregistrements privés de calibration/validation, les images, les pipelines de préparation et les poids du modèle ne sont pas inclus. » Le dépôt ne comporte aucun fichier de licence, de sorte que les conditions du code ne sont pas précisées, alors même que les poids sont sous Apache-2.0. Et la composition de la répartition de calibration — quels 1 728 cas, d'où — reste non divulguée, ce qui est la seule omission qui limite la mesure dans laquelle les chiffres ECE peuvent être vérifiés.

Les tailles que nous routons effectivement, et celle que nous ne routons pas.

Intern-Decision-2B n'est pas sur OrcaRouter. Notre page de modèle le concernant renvoie une 404, nous n'avons trouvé nulle part de point de terminaison hébergé pour celui-ci, et rien ici ne doit être interprété comme une affirmation de disponibilité. La seule façon de l'appeler aujourd'hui est de télécharger le checkpoint et d'exécuter inference.py à côté des poids.

Cela compte pour la décision dont traite réellement cet article, car un scorer que personne ne sert est un scorer que vous devez exploiter. Si la décision en ensemble fermé que vous essayez de prendre est proche en forme de ce que fait cette famille — un état, des questions typées, des probabilités calibrées — la comparaison hébergée est TypeSafe's Jev 1.13, qui est le modèle contre lequel InternLM a délibérément fait un benchmark et qui est sur OrcaRouter à 0,042 $ par million de tokens d'entrée avec un contexte de 65K et un temps jusqu'au premier token (P50) de 178 ms.

Exécuter localement un checkpoint de 2,2 milliards de paramètres et appeler un classifieur hébergé ne sont pas le même achat, mais c’est le même problème, et le fait de disposer des deux sur une seule clé avec prix catalogue du fournisseur répercuté à 0 % de marge est la raison de garder la comparaison ouverte plutôt que de parier l’architecture sur l’un des deux.

Qu’est-ce qui changerait cette image ?

Trois choses, dans l'ordre.

Quelqu'un d'extérieur à InternLM doit pouvoir reproduire la moyenne de 84,68 et l'ECE de 0,100, et le dépôt est désormais ce qui rend cela possible — voilà la véritable nouvelle ici. L'examen est public et vérifié par hachage ; seule la feuille de réponses manque, et la feuille de réponses est le checkpoint que n'importe qui peut désormais télécharger.

Le fournisseur doit dire à quoi cela sert. Un modèle avec une pile d'entraînement fonctionnelle, un bundle d'évaluation publié et aucune annonce, aucune licence sur son code et aucun point de terminaison hébergé apparaît comme une version de recherche qui n'a pas encore été transformée en produit. Les poids Apache-2.0 plaident dans un sens ; la licence de code manquante et le 401 Space plaident dans l'autre.

Et la taille intermédiaire doit avoir une raison d’exister. Si l’avantage de vitesse du 2B sur le 0,8B est réel mais marginal, et que sa calibration est la plus faible des trois pour chaque mesure publiée par InternLM, alors la recommandation honnête pour la plupart des lecteurs est de payer le facteur 2,6× en espace disque pour le 4B, ou d’accepter la précision plus faible du plus petit modèle. L’argument en faveur du 2B est qu’il se trouve être le plus rapide des modèles rapides — et c’est un argument plus ténu que ne le suggère le cadrage d’inspiration marketing de la famille.