Decision 3.0 vs Intern-Decision-4B : deux équipes ont affiné le même modèle et se sont opposées sur tout le reste

Placez d3-mini, le membre 4B de Decision 3.0, à côté de Intern-Decision-4B et la première chose que l’on remarque n’est pas une différence. Tous deux sont des versions affinées du même checkpoint de base, Qwen3.5-4B. Tous deux sont répertoriés à 4,54 milliards de paramètres. Tous deux prennent un état, un schéma de questions nommées et un ensemble de réponses candidates, et renvoient une probabilité calibrée par candidat sans générer de token. Tous deux sont Apache-2.0. Tous deux ont été publiés sans annonce — InternLM a téléversé trois checkpoints en quarante secondes le 26 septembre 2026, et la famille Decision 3.0 de vLLM-SR est arrivée sur Hugging Face le 10 octobre 2026, la nouvelle n’ayant été relayée que par le compte X du projet vLLM.

Tout ce qui suit est un désaccord. Ils ne sont pas d’accord sur la façon de lire une probabilité à partir du modèle, sur le point de savoir si la vidéo compte comme entrée, sur la durée maximale d’une requête et — surtout — sur la question de savoir si l’équipe est prête à publier le chiffre qui atteste que sa propre confiance est fiable. Cet article porte sur ces quatre désaccords et sur ce que chacun vous coûte, et non sur le modèle qui est « meilleur », car les deux ne sont pas mesurés à la même échelle et ne peuvent être classés l’un par rapport à l’autre sans faire un travail qu’aucun des deux fournisseurs n’a fait.

La coïncidence qu'il vaut la peine de comprendre en premier

Que deux laboratoires choisissent le même backbone 4B en l'espace de quinze jours n'est pas totalement surprenant — Qwen3.5-4B est une base raisonnable pour un modèle à sortie structurée, et les deux équipes se sont manifestement tournées vers lui parce qu'il est assez petit pour être exécuté à moindre coût et assez puissant pour lire des instructions. Ce qui est surprenant, c'est qu'ils soient parvenus au même nombre de paramètres à quatre chiffres significatifs près. Cela indique que le fine-tuning a préservé l'architecture, et qu'aucun des deux n'a ajouté une tour de vision séparée assez grande pour faire bouger le total. Tous deux intègrent leur capacité multimodale dans les mêmes poids.

La partie intéressante, c'est la lecture. Les deux modèles répondent aux questions de la même manière en principe — évaluer des réponses candidates plutôt que de les générer — et de manière complètement différente en mécanisme :

• Intern-Decision-4B — associe chaque option à un symbole de jeton unique (A–Z, puis a–z, puis 0–9), insère un squelette JSON dans le prompt avec un espace réservé par champ, et exécute une seule passe avant causale, en lisant les logits à la position immédiatement avant chaque espace réservé. Le mécanisme est documenté étape par étape sur sa fiche de modèle, y compris l'étape exacte de softmax et de température.

• d3-mini — embarque une architecture personnalisée dans modeling_d3.py avec une tête de lecture séparée dans son propre readout.safetensors, un decision_config.json déclarant noncausal_full_attention et un pooling du dernier token, et un mapping token-vers-code défini dans la config plutôt que décrit en prose.

Aucune des deux approches n'est manifestement meilleure. La voie InternLM présente l'avantage de fonctionner sur une classe de modèle Hugging Face standard avec une séquence numérique documentée — vous pouvez vérifier son travail. La voie vLLM-SR présente l'avantage que la lecture est une tête entraînée plutôt qu'une projection d'un embedding de token existant, ce qui est un ajustement plus libre, et le coût est que vous devez trust_remote_code=True et exécuter leur code pour faire quoi que ce soit.

Les limites que chacun publie

C'est ici qu'une véritable préférence commence à se former, car l'une des cartes est bien plus précise que l'autre quant à l'endroit où elle cesse de fonctionner.

• Plafond d'entrée — Intern-Decision-4B : 8 192 jetons par défaut, et les requêtes qui le dépassent sont rejetées d'emblée, jamais tronquées, le plafond étant fixé par un argument de constructeur. d3-mini : max_length vaut null dans la configuration livrée et aucun budget de jetons n'apparaît nulle part sur la fiche.

• Questions par requête — Intern-Decision-4B : de 1 à 16, avec un maximum indiqué de 62 options dans une même question. d3-mini : aucune limite indiquée ; la fiche indique seulement que les questions sont traitées ensemble, chacune à partir de sa propre passe avant.

• Images — Intern-Decision-4B : jusqu’à huit par requête, ordonnées selon une liste que vous fournissez, le processeur de checkpoint gérant le redimensionnement et l’expansion des jetons. d3-mini : plusieurs par requête sous forme de chemins, d’URL, d’images PIL ou d’URL de données base64, chacune lue jusqu’à 1,6 mégapixels, chaque question voyant chaque image.

• Vidéo — Intern-Decision-4B : aucun. d3-mini : plusieurs vidéos, lues à 2 images par seconde, avec un maximum de 32 images réparties sur le clip et de 0,2 mégapixel par image.

Le plafond d'entrée est l'élément qui tranchera pour la plupart des gens. Un budget de 8 192 jetons partagé entre l'état, les instructions de la question et le candidat constitue une véritable contrainte pour le travail de notation de documents et de routage en contexte long pour lequel ces modèles sont vendus, et InternLM mérite d'être salué pour l'avoir dit franchement plutôt que de laisser cela à découvrir. Que vLLM-SR ne le précise pas est l'inverse : non pas une limite cachée, mais une limite inconnue, et aucune lecture du dépôt, aussi approfondie soit-elle, ne permet de trancher.

La calibration, c'est le vrai clivage.

Tout modèle de décision fait la même promesse : le nombre qu’il renvoie est une probabilité, et les seuils définis par rapport à lui ont un sens. Presque aucun d’entre eux ne le prouve. C’est là que les deux versions divergent le plus, et cette divergence va dans la direction opposée à celle que l’on devinerait d’après les dates de sortie.

Intern-Decision-4B publie, sur sa propre fiche, un score de Brier de 0,347 et une erreur de calibration attendue (ECE) de 0,065 sur sa moyenne de sept benchmarks, une température ajustée de 1,99241824 dérivée par minimisation de la NLL sur 1 728 cas de calibration désignés avec 1 693 cas de validation distincts, une déclaration explicite selon laquelle les étiquettes de la suite de tests n’ont pas été utilisées pour sélectionner cette température, et un diagnostic sur 96 cas montrant que sa calibration passe de 0,628 Brier / 0,213 ECE avant mise à l’échelle de température à 0,550 / 0,089. Il indique également la valeur par défaut et précise que la calibration est par checkpoint, donc l’utilisation d’une autre taille avec ce module ne correspondra pas.

Decision 3.0 publie un indice d'exactitude et une affirmation de couverture — chacune des 140 178 requêtes publiques a reçu une réponse, aucune non étayée — et aucun chiffre de calibration, absolument aucun. Pas de score de Brier, pas d'ECE, pas de température déclarée, sur aucun des six points de contrôle. température dans le decision_config.json livré avec d3 vaut 1.0, ce qui est l'identité et peut ou non être la valeur ajustée ; le fichier ne le dit pas.

Lisez les deux titres d’index côte à côte et l’asymétrie s’aggrave. La fiche de d3-mini rapporte un score de 54,90 au Jev Decision Index 0.3 public-suite, décrit comme mesuré avec le kit officiel sur les poids publiés, tandis que les lignes de comparaison du même classement sont décrites comme des données de classement en direct. Intern-Decision-4B rapporte une moyenne de 90,02 sur ses propres sept benchmarks. Ces deux nombres ne sont pas sur la même échelle, ils ne portent pas sur les mêmes tâches, et les mettre dans une même phrase comme comparaison serait malhonnête. Ce qui est comparable, c’est la divulgation : une fiche vous dit à quel point ses scores de confiance sont faux, et l’autre ne le sait pas ou ne veut pas le dire.

Latence, et pourquoi les deux ensembles de millisecondes ne sont pas non plus comparables

Les deux fiches publient la latence par requête, et les prendre au pied de la lettre serait une erreur, pour la même raison que les chiffres de précision ne sont pas comparables.

• Intern-Decision-4B — moyenne 44,16 ms, médiane 44,03 ms, p95 44,60 ms, mesuré sur une seule RTX 4090 via le chemin Hugging Face local, décrit comme dépendant de la charge de travail et du matériel.

• d3-mini — médiane de 17,5 ms pour du texte, 96,2 ms avec une image, 371,5 ms avec une vidéo de dix secondes, sur un AMD Instinct MI325X, une requête à la fois.

Deux choses les rendent incomparables. La première, ce sont le matériel et la voie logicielle : une 4090 face à une MI325X, une passe avant Hugging Face standard face à une implémentation d'attention personnalisée dotée de noyaux pour couches masquées disponibles via flash-linear-attention. La seconde, c'est la charge de travail : le chiffre d'InternLM est décrit comme mesuré de bout en bout par requête sur un mélange non précisé, et celui de vLLM-SR est ventilé par modalité d'entrée, si bien que la comparaison en texte seul est la seule ligne strictement comparable, et même celle-ci implique deux fabricants de GPU.

Le chiffre à retenir des deux cartes n’est pas le classement, c’est la forme. Un modèle de décision est appelé de façon répétée au sein d’un même flux de travail — un dossier de support peut nécessiter une destination, une vérification de remboursement, une décision d’escalade et un score de priorité, soit quatre questions, et un lot de 128 dossiers transforme cela en 512 décisions. À ce volume, 17 ms et 44 ms disparaissent tous les deux à côté de ce que coûte le modèle génératif en aval. Les chiffres dépendant de la modalité sont ceux à surveiller, car une requête d’image ou de vidéo coûte entre cinq et vingt fois plus cher qu’une requête texte d’après les propres chiffres de d3-mini, et si votre décision est prise sur une capture d’écran, vous avez importé un profil de coûts que la plupart des déploiements de modèles de décision n’ont pas.

Lequel choisir au final ?

Si la décision que vous devez prendre dépend d'une vidéo, il n'y a pas de match et aucune analyse n'est nécessaire : Decision 3.0 lit la vidéo et Intern-Decision-4B ne le fait pas. C'est toute la réponse pour tout ce qui implique des enregistrements d'écran, des clips caméra ou des séquences d'images, et c'est l'écart de capacité qui justifie à lui seul l'existence de la famille plus récente.

Si vos entrées sont du texte et des images occasionnelles, le choix repose sur deux choses, et aucune des deux n’est le classement.

Choisissez Intern-Decision-4B lorsque vous devez raisonner sur des seuils. C’est le seul des deux à vous dire si un 0,9 signifie neuf fois sur dix, il nomme sa température, il précise sur quels cas cette température a été ajustée, et il documente son inférence sous la forme d’une courte procédure numérotée que vous pouvez réimplémenter sur une classe de modèle standard. Pour un scoreur placé devant une action automatisée, c’est la propriété qui compte, et elle est plus rare que les points d’exactitude.

Choisissez Decision 3.0 lorsque vous avez besoin de la gamme ou des modalités. Six checkpoints de 0,59B à 26,09B signifient que le même format de requête peut être servi par un modèle edge de 6,7 ms et un modèle de 27B, et la famille partage une seule interface, de sorte que passer d'un palier à l'autre est un changement de configuration plutôt qu'une réécriture. Le hic, c'est que vous faites confiance à un budget d'entrée non déclaré et à une affirmation de calibration non auditée, et le plus grand modèle de la famille est celui dont le numéro d'index a été mesuré par le fournisseur sur son propre harnais d'évaluation.

Aucun des deux n’est un choix par défaut sûr aujourd’hui. Le checkpoint le plus téléchargé de d3 est présent sur Hugging Face depuis environ un jour ; Intern-Decision-4B est en ligne depuis deux semaines et a attiré environ 3 200 téléchargements et 83 mentions J’aime, ce qui représente de l’attention, mais pas du trafic de production. Les deux sont assez peu coûteux à tester et ni l’un ni l’autre ne s’appuie sur une évaluation tierce. Si vous placez un système de notation devant quelque chose qui dépense de l’argent, la bonne approche est de faire tourner les deux sur vos propres cas étiquetés et de comparer les courbes de calibration, pas les lignes d’index.

Où un routeur trouve sa place, honnêtement

OrcaRouter ne prend en charge aucun de ces deux modèles. Les checkpoints de Decision 3.0 constituent un chemin d'inférence Python local dans un dépôt Hugging Face, sans point de terminaison HTTP publié, et Intern-Decision-4B est livré sous la forme d'une classe DecisionEngine que vous instanciez vous-même. Aucun des deux ne fait partie de ce que nous pourrions router aujourd'hui, et aucune partie de cet article ne doit être interprétée comme une affirmation de disponibilité.

Ce que nous proposons, de notre côté, c'est le pendant hébergé de la même famille. typesafe/jev-1.13 figure dans notre catalogue, servi via POST /v1/systemone — le même contrat d'état et de questions nommées que mettent en œuvre les deux modèles ouverts ci-dessus — à 0,042 $ par million de jetons d'entrée, sans frais de complétion, puisqu'il n'en génère jamais. Il côtoie plus de 200 autres modèles, et c'est là le point pratique pour quiconque compare ces deux modèles : le scoreur est la partie bon marché de la boucle, et le modèle qui agit sur la décision est la partie coûteuse. Router les deux via une seule clé, avec basculement automatique en cas de défaillance d'un fournisseur et prix catalogue du fournisseur répercuté avec 0 % de marge, signifie qu'évaluer un modèle de décision ne nécessite pas de signer un second contrat ni de réécrire le site d'appel lorsque vous changez de backend. Si vous êtes en pleine évaluation — ce qui est le cas de ces deux modèles aujourd'hui —, c'est la partie qu'il vaut la peine de mettre en place avant de vous engager pour l'un ou l'autre.

La question ouverte

Les deux fiches ne s’accordent pas sur ce qu’un auteur de modèle doit au lecteur, et ce désaccord est plus intéressant que les modèles. InternLM a publié une température et les cas sur lesquels elle a été ajustée, puis a publié le diagnostic montrant l’ampleur de l’amélioration due à la calibration. vLLM-SR a publié des hachages de fichiers, des révisions de base épinglées, une cible matérielle déclarée, une affirmation de couverture — un véritable travail de provenance — et pas le moindre chiffre de calibration.

Le test pour savoir quelle version arrive à maturité n’est pas de savoir laquelle remporte un classement. C’est de savoir si le prochain Decision checkpoint est livré avec un score de Brier, et si la prochaine mise en ligne d’InternLM atteint la vidéo. Les deux sont visibles de l’extérieur, les deux sont faciles à vérifier, et ni l’un ni l’autre ne s’est encore produit.