Intern-Decision-0.8B est arrivé sans annonce : ce qu'InternLM a discrètement mis sur Hugging Face

Le lien GitHub sur la fiche du modèle renvoie une 404. L’Espace de démonstration renvoie une 401. Il n’existe aucune collection, aucun article de blog, aucun rapport technique et aucun résultat de recherche, où que ce soit, pour la chaîne « Intern-Decision » qui ne soit pas une offre d’emploi pour un stage — et pourtant Intern-Decision-0.8B est actuellement sur Hugging Face sous la forme d’un checkpoint Apache-2.0 complet et téléchargeable, affiné à partir de Qwen3.5-0.8B, mis en ligne au petit matin du 26 septembre 2026 avec deux frères plus grands apparus dans les mêmes trois minutes : Intern-Decision-2B et Intern-Decision-4B. InternLM a déjà procédé ainsi par le passé, et c’est pourquoi tout ce qui suit est assemblé à partir du dépôt lui-même plutôt que d’un billet de lancement. La distinction compte ici plus que d’ordinaire : un dépôt vous dit ce qui existe, et seul le fournisseur peut vous dire à quoi cela sert.

Ce que le dépôt dit, en détail, est suffisamment inhabituel pour valoir la lecture. Ce ne sont pas des modèles de chat ni des petits modèles de langue au sens habituel. Intern-Decision-0.8B prend un morceau d’état, un schéma de questions nommées que vous rédigez à l’avance, et éventuellement jusqu’à huit images, puis renvoie une distribution de réponses pour chaque question en une seule passe avant. Il n’appelle jamais generate(). Il n’échantillonne jamais. Il n’y a aucune sortie texte à analyser, aucun JSON à réparer, aucune boucle de nouvelle tentative autour d’une accolade qui ne s’est jamais fermée. Cette étroitesse constitue toute l’architecture, et elle place ce modèle dans la même petite catégorie que Jev 1.13 de TypeSafe et Laya de Convai — une catégorie sur laquelle InternLM a manifestement établi des benchmarks exprès, car Jevbench est le benchmark propre à TypeSafe et c’est la première colonne du tableau.

Voici ce qui peut être su à partir du checkpoint, ce qui n’est que revendiqué par le checkpoint, et ce que personne en dehors d’InternLM ne peut actuellement dire du tout.

Qu'y a-t-il réellement dans le dépôt ?

La fiche est brève et franche sur sa filiation. Intern-Decision-0.8B y est décrit comme « un modèle de décision structuré multimodal affiné à partir de Qwen3.5-0.8B » — la base Qwen publiée le 28 février 2026 — et le dépôt contient un second fichier de licence, LICENSE-QWEN, aux côtés des termes Apache-2.0, ce qu’un modèle dérivé est censé faire et qui constitue en soi un petit signal d’honnêteté. L’index de Hugging Face rapporte 852 985 920 paramètres répartis sur trois shards : un shard de langage de 1,50 Go, un shard de vision de 176 Mo et un projecteur de 25 Mo. Le stockage total du dépôt est d’environ 1,73 Go, fichiers de tokenizer inclus, ce qui place l’ensemble confortablement sur un seul GPU grand public ou sur un ordinateur portable bien équipé.

La configuration révèle une architecture que Qwen déploie sur toute la génération 3.5 plutôt qu'un réseau de décision sur mesure. Il s'agit d'un Qwen3_5ForConditionalGeneration avec 24 couches disposées selon un motif répétitif de trois couches d'attention linéaire pour une couche d'attention complète, une taille cachée de 1 024, 8 têtes d'attention contre 2 têtes clé-valeur, une dimension de tête de 256, et un embedding de position maximal de 262 144 jetons. Une seule couche de prédiction multi-jetons est conservée. Le chemin vision est bien réel : le texte de la fiche décrit le traitement des images, le processeur prend des images, et le checkpoint embarque une tour de vision et un projecteur pour le servir — donc l'étiquette multimodale sur le dépôt est soutenue par des poids, pas seulement par des étiquettes.

Le portrait de famille mérite d’être noté, car il conditionne la lecture de tout le reste. InternLM a mis en ligne trois tailles en 40 secondes : 0,8B, puis 2B, puis 4B. Les nombres de paramètres sont 852 985 920, 2 213 241 664 et 4 539 265 536. La fiche du modèle 4B comporte une section supplémentaire — un projet pilote de calibration à distribution connue portant sur 96 cas, avec des scores avant et après — que la fiche du 0,8B ne comporte pas. Cette asymétrie n’est pas la preuve d’un défaut du petit modèle ; elle montre que la documentation du petit modèle a été rédigée avec un budget plus serré, ce qui est le genre de chose à quoi ressemble une publication discrète.

Comment fonctionne réellement le chemin d’inférence

Le fichier inference.py fourni est le fichier le plus instructif du dépôt, car il documente un contrat plutôt qu’un prompt. La séquence se déroule ainsi :

• Vous fournissez une requête avec un état (la chose qui est jugée), des questions (un schéma), et éventuellement des images.

• Les options de chaque question sont mappées à des symboles à un seul token — de A à Z, puis les minuscules, puis les chiffres, jusqu’à 62 options par question.

• L'invite système, l'état, le schéma et un squelette JSON complet d'assistant sont rendus avec un espace réservé <decision> par champ.

• Une passe avant causale est exécutée. Les logits sont lus à la position immédiatement avant chaque espace réservé.

• Un softmax est calculé uniquement sur les symboles candidats autorisés de ce champ, la calibration du checkpoint est appliquée, puis les symboles sont reconvertis vers vos valeurs d’option d’origine.

Le moteur expose trois types de questions. choice prend un objet ordonné associant les valeurs d’option à des descriptions. score prend une liste — qui devient les valeurs de chaîne « 0 », « 1 », « 2 », etc. — ou un objet ordonné avec des clés de chaîne numériques finies, ce qui permet au modèle de renvoyer une valeur attendue pondérée par les probabilités et pas seulement une catégorie. noul est une décision binaire où « non » précède « oui ». La réponse renvoie, par champ, la distribution de probabilités calibrée, une confiance égale à la probabilité candidate maximale, la décision argmax avec départage lexical, et, pour les questions score, la valeur numérique attendue et une légende. Les limites sont explicites : de une à seize questions par requête, jusqu’à 62 options chacune, un plafond d’entrée par défaut de 8 192 jetons qui est rejeté plutôt que tronqué, et un maximum de huit images dont les jetons sont comptabilisés dans ce plafond.

Deux détails dans cette liste méritent l’attention, car ils déterminent si vous pouvez faire confiance à la sortie. Le premier est qu’aucune réponse de référence n’est insérée dans le prompt — le modèle évalue des candidats pour lesquels la réponse ne lui a pas été montrée. Le second est que usage.output_tokens n’est pas un décompte de tokens de texte ; il compte les champs évalués. Quiconque intègre cela dans un calcul existant de budget de tokens sera surpris, et la fiche le précise plutôt que de laisser le découvrir.

Le tableau de benchmark, et dans quelle mesure y croire

Lecteur, méfiez-vous de cette section : chaque chiffre ci-dessous est déclaré par le fournisseur et non reproduit. InternLM a sélectionné les benchmarks, sélectionné les modèles de comparaison, exécuté les évaluations et publié le tableau. Il n’existe aucune exécution indépendante d’Intern-Decision-0.8B sur un classement public, et une recherche d’Artificial Analysis ne renvoie absolument rien pour le modèle. Cela ne rend pas le tableau faux. Cela le rend non audité, et cela signifie que les colonnes sont plus utiles pour lire la forme du résultat que son niveau.

• Jevbench, trois splits — Intern-Decision-0.8B affiche 97,92 sur Easy, 80,56 sur Original et 52,25 sur Hard. Le Jev de TypeSafe se situe à 100,00, 98,61 et 72,07 sur les mêmes splits.

• Typed Decision — le 0.8B obtient 77,35 contre 73,35 pour Jev. C’est la seule colonne où le plus petit modèle du domaine bat le modèle dont le benchmark tire son nom.

• ToolACE — 94,52 pour le 0,8B contre 91,29 pour Jev. ToolACE est un benchmark d’appel de fonctions, et une tête de décision qui surpasse Jev sur la sélection d’outils est l’affirmation la plus substantielle du tableau.

• AG News — 88,61 contre les 89,57 de Jev. Pratiquement à égalité avec la frontière de cette catégorie en classification thématique à quatre classes.

• WildJailBreak — 64,48 contre les 96,29 de Jev. C'est l'effondrement. Sans doute la colonne qui compte le plus pour un modèle que l'on exposerait à des entrées non fiables, et celle où le 0,8B est le plus éloigné de la référence.

• Moyenne — 79,38 pour le 0.8B, 84,68 pour son propre homologue 2B, 90,02 pour le 4B. La famille grimpe fortement, ce à quoi on s’attendrait exactement, et c’est en soi un faible argument en faveur du fait que le tableau n’a pas été rétro-conçu pour flatter le modèle phare.

• Calibration — Brier 0,530 et erreur de calibration attendue 0,066 pour le 0.8B. Jev rapporte 0,358 et 0,095. À lire ces deux chiffres ensemble, une image plus claire se dégage que celle que donne chaque nombre isolément : le 0.8B est mieux calibré que Jev au sens de l’ECE — ses niveaux de confiance déclarés suivent de plus près sa précision — tout en étant sensiblement moins précis dans l’ensemble. C’est un profil plausible pour un petit modèle avec une température ajustée délibérément, et ce n’est pas une combinaison flatteuse à publier par accident.

L’ensemble de comparaison présente une propriété frappante : il est dominé par des modèles de décision. Jev, Laya, SemIf, Kev et JevK5 y figurent tous ; le benchmark du tableau lui-même est celui de TypeSafe. InternLM a choisi d’être mesuré sur le terrain d’un concurrent, à l’aide du harnais d’un concurrent, puis a publié les colonnes où son plus petit modèle perd. C’est le genre de décision qu’une équipe prend lorsqu’elle ne prévoit pas de campagne marketing autour de la sortie — ce qui est cohérent avec tout le reste de la manière dont cela a été livré.

La température d’étalonnage est le nombre le plus intéressant

Intern-Decision-0.8B calibre une température par défaut de 2.747760550703, par minimisation de la NLL sur 1 728 cas de calibration désignés avec 1 693 cas de validation distincts. La fiche indique explicitement que les étiquettes de la suite de tests n'ont pas été utilisées pour la sélectionner. La transformation appliquée est p = softmax(candidate_logits.float()) suivie de calibrated_p = softmax(log(p) / T).

Il s'agit d'une calibration de probabilité de candidat, et non d'une température d'échantillonnage, et la distinction n'est pas de la pédanterie. Comme la transformation est appliquée après le softmax et préserve l'ordre, elle ne peut en rien modifier la décision argmax. Elle modifie la confiance, la probabilité de oui noul et la valeur attendue d'un score — et laisse la décision principale identique. Si votre flux de travail lit l'étiquette, la température est sans effet. Si votre flux de travail lit la probabilité — s'il classe selon elle, ou l'injecte dans un calcul de valeur attendue en aval — la température fait la différence entre un nombre qui signifie quelque chose et un nombre qui ne signifie rien. Passer temperature=1 renvoie la distribution non calibrée, ce qui constitue une échappatoire valable pour quiconque souhaite appliquer sa propre calibration par-dessus.

La température est ajustée par checkpoint plutôt que partagée. Le modèle 4B utilise une valeur différente, 1.99241824, et la fiche vous indique d’utiliser le module d’inférence fourni avec la taille que vous avez téléchargée afin que sa calibration par défaut corresponde. Quiconque copie un wrapper d’inférence d’un modèle frère à un autre appliquera silencieusement la mauvaise température.

Trente-quatre millisecondes, et un résultat qui ne devrait pas être possible

InternLM a mesuré la latence de bout en bout par requête sur une seule RTX 4090 en utilisant le chemin local Hugging Face — une mesure réelle, mais aussi la configuration de service la plus lente possible, car un déploiement en production utiliserait un runtime compilé ou avec traitement par lots. Jev est indiqué à 109,70 ms en moyenne et 106,30 ms en médiane avec un p95 de 146,70 ms. Intern-Decision-0.8B affiche 33,98 / 33,44 / 37,50 ms.

Le nombre sur lequel il vaut la peine de s'arrêter est celui du frère 2 : 33,28 ms en moyenne, 33,15 ms en médiane. Le 2B est plus rapide que le 0.8B, d'une marge suffisamment faible pour relever du bruit, mais pas dans la direction que les nombres de paramètres laissent présager. Ce n'est pas une erreur dans le tableau et ce n'est pas vraiment une question de modèles. Un modèle de décision effectue exactement une passe avant sur un prompt dont la longueur est déterminée par l'état, le schéma et les descriptions d'options — et non par quoi que ce soit que le modèle écrit, car il n'écrit rien. Pour les prompts dans ce régime, le traitement du prompt domine et le nombre de paramètres est un coût de second ordre. La conséquence pratique est que la raison habituelle de se tourner vers le plus petit checkpoint — vous payez par token — ne s'applique pas ici. La vraie raison de choisir le 0.8B plutôt que le 2B est l'empreinte mémoire et le fait que l'ensemble de son dépôt tient dans 1,73 Go, et non le débit.

Ce qui ne peut pas encore être établi

C’est la partie à laquelle un article de lancement aurait répondu et à laquelle un dépôt ne peut pas répondre.

Il n’y a pas de date de sortie annoncée, pas d’annonce, et rien sur les canaux publics d’InternLM ne décrit la famille. L’URL GitHub imprimée sur la fiche du modèle ne se résout pas. Le Space de démonstration mentionné dans la fiche n’est pas accessible publiquement. Il n’existe aucune collection regroupant les trois checkpoints, ce qui signifie que le seul moyen de trouver le 2B ou le 4B est de consulter la liste des modèles de l’organisation. Il n’y a pas d’article, donc les données d’entraînement, la recette de réglage, le nombre d’étapes d’entraînement et ce que le « decision tuning » a modifié dans les poids ne sont pas indiqués. Il n’y a pas d’évaluation indépendante, pas de réplication de la latence par un tiers, et aucune preuve pour l’instant que quelqu’un en dehors d’InternLM ait exécuté le checkpoint.

La fiche soulève également deux questions sans y répondre. La première est ce que l’écart WildJailBreak signifie en pratique : un déficit de robustesse de refus de cette ampleur est une propriété du fine-tuning, et savoir s’il reflète le modèle de base, l’objectif de réglage décisionnel ou le faible nombre de paramètres n’est pas indiqué par le dépôt. La seconde est ce qui se passe au plafond d’entrée. Les requêtes au-delà de 8 192 tokens sont rejetées plutôt que tronquées, ce qui est le comportement approprié pour un modèle de scoring, mais cela signifie que la fenêtre de contexte pratique n’est pas les 262 144 annoncés par la configuration — c’est ce qui tient dans 8 192 tokens d’état, de schéma, d’options et de patchs d’image. Pour les documents longs avec des schémas riches, ce plafond arrive plus tôt que ne le suggère le diagramme d’architecture.

Où cela se situe, et comment l’essayer sans parier dessus

La présentation honnête consiste à dire qu'Intern-Decision-0.8B est un checkpoint publié, assorti d'affirmations non auditées et sans documentation à l'appui. Cette combinaison n'est pas une raison de l'ignorer — une publication de poids sous Apache-2.0 que vous pouvez télécharger et évaluer en un après-midi est une meilleure situation qu'une API à liste d'attente — mais elle signifie bel et bien que la charge de la validation vous incombe. Le moteur se charge depuis un répertoire local, tourne sur un GPU de classe 4090 ou inférieur, et la fiche fournit une requête d'exemple fonctionnelle que vous pouvez coller. Une journée d'évaluation sur vos propres cas annotés vous en apprendra plus sur la colonne WildJailBreak que ne le peut le tableau du fournisseur.

Si la couche de décision est la partie que vous évaluez, la cible de comparaison utile est une cible hébergée. Le Jev 1.13 de TypeSafe est le modèle sur lequel InternLM a fait son benchmark, et il est appelable dès aujourd'hui via un unique point de terminaison compatible OpenAI à 0,042 $ par million de jetons d'entrée, la sortie étant facturée à zéro — le même prix que publie le fournisseur, car OrcaRouter répercute le prix catalogue du fournisseur sans aucune marge plutôt que d'ajouter une marge par-dessus. Mettre une tête de décision auto-hébergée de 0,8 Md et une API de décision hébergée sur la même clé, le même après-midi, est une expérience nettement moins coûteuse que de monter deux contrats distincts pour répondre à la même question.

Ce qui changerait la donne, ce n'est pas un benchmark. C'est l'apparition du dépôt GitHub, ou la publication par InternLM de la recette de réglage, ou la première exécution indépendante du checkpoint arrivant sur un classement. Tant que rien de tout cela ne se produit, la description exacte d'Intern-Decision-0.8B est étroite, peu flatteuse et entièrement à son avantage : les poids sont bien réels, le contrat d'inférence est documenté mieux que ne le font la plupart des modèles lancés, et le marketing n'a pas commencé.