Decision 3.0 est sur Hugging Face : six modèles décisionnels multimodaux ouverts, annoncés uniquement sur X

Decision 3.0 existe sous une forme que vous pouvez télécharger dès maintenant, et presque personne ne l'a couché par écrit. Six checkpoints — d3, d3-flash, d3-mini, d3-nano, d3-lite et d3-edge — sont arrivés dans l'organisation vllm-sr sur Hugging Face le 10 octobre 2026, du plus récent au plus ancien, à partir de 09:38 UTC et en terminant avec d3-edge à 23:49 UTC. Ils sont sous licence Apache-2.0, ils sont bâtis sur les backbones Qwen3.5 et Qwen3.8, ils répondent à des questions de choix, de oui/non et de score avec une probabilité par option au lieu de générer un token, et cinq des six lisent désormais les images et la vidéo. Chaque fiche de modèle se décrit comme « le modèle de décision fondationnel multimodal 27B de Decision 3.0, les modèles de décision de vLLM Semantic Router », qui est la couche de décision ouverte du projet vLLM.

Ce qui manque, c'est l'annonce. Le compte X du projet vLLM a félicité l'équipe vLLM-SR pour la publication du 11 octobre, en citant le fil de présentation du mainteneur lui-même — voilà tout ce qui est rendu public. L'index du blog du projet s'arrête toujours au 10 octobre avec un article sur les modèles de décision de routage, et non sur ceux-ci. La page des releases GitHub de vllm-project/semantic-router plafonne toujours à la v0.4.0 du 27 septembre. Les poids sont livrés ; la note de lancement, non.

Cette distinction est importante pour la façon dont vous lisez tout ce qui suit. Chaque chiffre de performance dans cet article provient des propres fiches de modèle de vLLM-SR, mesuré avec leur propre harnais d'évaluation sur leur propre matériel. Rien ici n'a été reproduit par un tiers extérieur, et le classement sur lequel ils publient est un classement qu'ils maintiennent eux-mêmes. Il s'agit d'une première lecture honnête d'un artefact qui est réel et d'une affirmation qui n'a pas encore été auditée.

Qu'y a-t-il réellement sur Hugging Face ?

Les six dépôts sont simples, complets et cohérents entre eux. Chacun contient des poids safetensors, un template de chat, un decision_config.json qui fige la révision du modèle de base, du code de modélisation personnalisé (modeling_d3.py, d3_engine.py, d3_server.py), une tête de lecture dans son propre readout.safetensors, et un MODEL_MANIFEST.json avec un SHA-256 par fichier. Un septième dépôt, la page de collection, répertorie les six.

La famille, dans l’ordre où les tailles s’échelonnent :

• d3 — 26,09 Md de paramètres, dont un encodeur visuel de 0,46 Md, basé sur Qwen/Qwen3.8-27B. Publié le 10 octobre à 09:38 UTC.

• d3-flash — 8,39 Md, dont un encodeur visuel de 0,46 Md, construit sur Qwen/Qwen3.5-9B.

• d3-mini — 4,54 Md, dont un encodeur visuel de 0,33 Md, construit sur Qwen/Qwen3.5-4B.

• d3-nano — 2,21 B, dont un encodeur visuel de 0,33 B, basé sur Qwen/Qwen3.5-2B.

• d3-lite — 0,85B, y compris un encodeur visuel de 0,10B, basé sur Qwen/Qwen3.5-0.8B.

• d3-edge — 0,59 B, dont un encodeur visuel de 0,10 B, également basé sur Qwen/Qwen3.5-0.8B. Téléversé en dernier, 23:49 UTC.

Les six partagent le même contrat de requête : un state (texte ou JSON, éventuellement avec des images et des vidéos) plus un dictionnaire de questions nommées, et une réponse composée de distributions de probabilité typées. Il existe trois types de questions — Choice, Noul (oui/non), Score — et le modèle répond à toutes en un seul appel en exécutant une passe avant par question sur la même entrée, sans aucune boucle de décodage.

Les chiffres, et à qui ils appartiennent

vLLM-SR publie un classement qu'il appelle le Jev Decision Index 0.3.1 et y place d3 en tête. Les lignes principales, toutes rapportées par les fournisseurs :

• d3 — Indice 64,7 ; suite publique 65,5 ; tests sur les mêmes compétences 62,8 ; tâches sur de nouveaux domaines 56,6.

• Perplexity Decider v1.1 (27B) — 62,8, 62,3, 61,1, 55,6.

• Fastino GLiDE no-thinking (28B) — 60,2, 59,1, 59,5, 52,9.

• Jev — 60.1, 58.0, 58.0, 55.0.

• Torchcast Decision 27B — 59.9, 65.1, 58.1, 50.8.

• Decision 2.0 (27B), la génération précédente — 55,9, 57,0, 55,7, 47,9.

Une note de bas de page sur la fiche de d3 indique clairement que la ligne de d3 est une évaluation interne, tandis que les lignes de comparaison sont des données de tableau en direct lues le 10 octobre. C'est la bonne divulgation à faire, et cela vaut la peine de la lire deux fois : les chiffres des concurrents ont été extraits d'un tableau, et le chiffre du sujet a été produit par l'équipe qui a construit le modèle. La fiche affirme également que les 140 178 requêtes publiques ont toutes reçu une réponse, aucune n'étant non étayée — une affirmation de couverture, non d'exactitude, et une affirmation inhabituelle à publier.

Les checkpoints plus petits déclarent avancer du même pas. Chaque fiche donne un chiffre sur la suite publique et un écart par rapport à la taille équivalente dans Decision 2.0 : d3-flash 57,79, en hausse de 11,0 par rapport au précédent 9B ; d3-mini 54,90, en hausse de 10,7 ; d3-nano 42,22, en hausse de 12,2 ; d3-lite 36,93, en hausse de 16,4 ; d3-edge 28,82, en hausse de 12,1. Les gains relatifs sont les plus importants dans le bas de la gamme, ce à quoi on s'attendrait si la recette de préentraînement multimodale faisait davantage de travail pour les petits modèles que pour les grands — et aussi ce que l'on produirait en optimisant le plus intensivement les petits modèles. Il est impossible de savoir lequel des deux depuis l'extérieur.

La partie multimodale est le vrai changement

Les modèles de Decision 2.0 lisent du texte. Ceux de Decision 3.0 lisent le texte, les images et la vidéo, et c'est là la différence fondamentale entre les générations — et non le mouvement de l'indice. Chaque fiche répertorie l'entrée image au format PNG, JPEG ou WebP, fournie sous forme de chemins, d'URL, d'images PIL ou d'URL de données base64, avec plusieurs par requête à jusqu'à 1,6 mégapixel chacune ; et la vidéo au format MP4, WebM, MOV ou MKV, ou sous forme de tableaux de trames, lue à 2 images par seconde avec au maximum 32 images réparties sur l'ensemble du clip et chaque image à jusqu'à 0,2 mégapixel. Chaque question d'une requête voit toutes les images et toutes les vidéos qui y sont jointes.

Les éléments de preuve à l'appui pour la vidéo consistent en un résultat au Perception Test portant sur l'ensemble des 19 140 questions de validation : d3 à 77,4, d3-flash à 73,3, d3-mini à 70,3, d3-nano à 63,5, d3-lite à 59,3, d3-edge à 46,6, face à un seuil de hasard documenté de 33,3 sur les questions à trois options. vLLM-SR qualifie cela d'évaluation interne. d3 dispose également d'un tableau de bord vision qui le situe à 71,6 au global, devant Perplexity Decider v1.1 à 70,6 et JEV-27B-VL à 69,6, les lignes de comparaison étant là encore tirées des données du tableau de bord plutôt que produites par les auteurs.

Les chiffres de débit sont ceux d’une requête unique, sur un seul GPU, et sont annoncés comme tels : d3 répond à une requête texte en une médiane de 55 ms, à une requête contenant une image en 273 ms, et à une requête contenant une vidéo de dix secondes en 553 ms, sur un AMD Instinct MI325X. d3-edge fait de même en 6,7 ms, 41,9 ms et 308,3 ms. Ce sont des médianes par question sur un modèle conçu pour être appelé de nombreuses fois au sein d’un même workflow, ce qui est le chiffre qui compte pour l’architecture à laquelle ces modèles sont destinés — vingt décisions séquentielles à 100 ms supplémentaires chacune coûtent deux secondes, comme Microsoft l’a fait valoir ce mois-ci à propos de son propre modèle de décision.

Ce que les dépôts ne disent pas

Trois lacunes méritent d’être nommées avant que quiconque ne planifie en fonction de cela.

Le premier est le budget d'entrée. decision_config.jsonpour les plus grands ensembles de modèles met max_lengthà null, et aucune fiche n'indique de plafond de tokens pour l'état, les questions et les descriptions d'options. Les fiches de Decision 1.0 publiaient des budgets explicites — 1 024 tokens pour la branche encodeur, 16 384 pour la branche décodeur — et ces chiffres constituent une véritable contrainte de planification. Leur absence ici est frappante, et c'est la chose la plus utile qu'un commit de suivi pourrait ajouter.

Le deuxième point est la calibration. Le nombre le plus important d'un modèle de décision n'est pas la précision, mais de savoir si une valeur 0.9 renvoyée signifie neuf fois sur dix. Les indices de vision et de texte ne disent rien à ce sujet. Aucune des six fiches ne contient de score de Brier, de valeur d'erreur de calibration attendue, ni de température. InternLM a publié les deux sur son propre modèle de décision en septembre ; vLLM-SR ne l'a fait pour aucun membre de cette famille.

Le troisième est l'indépendance. Les modèles de Decision 2.0 ont derrière eux deux semaines d'utilisation externe ; ceux de Decision 3.0, quelques heures. Les compteurs de téléchargements du 11 octobre — 130 pour d3, 83 pour d3-lite, 82 pour d3-nano — sont l'empreinte d'un téléversement, non d'une adoption. Traitez chaque chiffre de l'indice ci-dessus comme une hypothèse à laquelle est attaché un dépôt.

Où cela se situe dans une pile que vous pouvez appeler dès aujourd’hui

La question pratique à propos d’un modèle de décision est de savoir s’il s’intègre dans un pipeline qui existe déjà, et ici, l’écosystème est plus avancé que ne le sont les modèles. Le format de requête System One que ces modèles utilisent n’est pas exclusif à vLLM-SR : c’est le même contrat d’état et de questions nommées que celui avec lequel les modèles Jev hébergés sont appelés, ce qui explique pourquoi « Jev » apparaît à la fois comme nom de l’index dans la fiche de modèle de d3 et comme ligne dans son classement.

OrcaRouter couvre ce pan de la famille. typesafe/jev-1.13 figure dans notre catalogue et est servi via /v1 les mêmes jetons en entrée, pas de streaming, du JSON structuré en sortie, en mode non-streaming. Deux choses ne sont pas revendiquées : d3 ne figure pas dans notre catalogue, et l'inférence locale de d3.0 n'est pas quelque chose que nous pourrions router, même si nous le voulions. Ce qu'un routeur vous apporte ici se joue de l'autre côté de la boucle — le modèle génératif qui agit sur une décision, routé via une seule clé sur plus de 200 modèles, avec bascule automatique en cas de défaillance d'un fournisseur, de sorte que l'ajout d'une étape de scoring en amont d'un workflow n'implique pas non plus l'ajout d'une seconde relation fournisseur.

Qu’est-ce qui changerait cette image ?

Quatre choses, dans un ordre approximatif de ce qu'elles vous apprendraient. Un billet de blog du projet énonçant le budget d'entrée et la forme de déploiement envisagée, ce qui confirmerait qu'il s'agit d'une release plutôt que d'un push. Un score de Brier ou une valeur ECE sur un seul checkpoint. Un tiers exécutant la suite publique sur les poids publiés plutôt que de lire l'index. Et un runtime — le dépôt semantic-router a enregistré deux commits le 11 octobre qui intègrent d3 et d3-edge dans son runtime de modèle, y compris l'entrée vidéo, ce qui suggère que le volet serving se construit maintenant et sera ce qui rend ces modèles peu coûteux à essayer.

Tant qu'au moins le premier de ces éléments n'est pas arrivé, le résumé honnête est le suivant : il existe une famille complète de modèles décisionnels, sous Apache-2.0, véritablement multimodale, hébergée sur Hugging Face, de 0.6B à 27B, publiée avec une provenance inhabituellement bonne — hachages de fichiers, révisions de base épinglées, une cible matérielle déclarée — et avec une quantité inhabituellement faible de documentation d'accompagnement qui vous permettrait de décider si vous devez l'utiliser. Le téléchargement ne coûte rien. Croire à l'index devrait attendre.