Decision 3.0 è su Hugging Face: sei modelli decisionali multimodali open, annunciati solo su X

Decision 3.0 esiste in una forma che puoi scaricare subito, e quasi nessuno l'ha messo per iscritto. Sei checkpoint — d3, d3-flash, d3-mini, d3-nano, d3-lite e d3-edge — sono approdati nell'organizzazione vllm-sr su Hugging Face il 10 ottobre 2026, dal più recente al più vecchio a partire dalle 09:38 UTC e terminando con d3-edge alle 23:49 UTC. Sono sotto licenza Apache-2.0, sono costruiti su backbone Qwen3.5 e Qwen3.8, rispondono a domande a scelta, sì/no e con punteggio con una probabilità per opzione invece di generare un token, e cinque dei sei ora leggono immagini e video. Ogni model card si descrive come "the 27B multimodal foundation decision model of Decision 3.0, the decision models of vLLM Semantic Router", ovvero il layer decisionale aperto del progetto vLLM.

Quello che manca è l'annuncio. L'account X del progetto vLLM si è congratulato con il team vLLM-SR per il rilascio dell'11 ottobre, citando il thread introduttivo del maintainer stesso — questo è l'intero resoconto pubblico. L'indice del blog del progetto termina ancora il 10 ottobre con un post sui modelli decisionali di routing, non su questi. La pagina delle release su GitHub per vllm-project/semantic-router si ferma ancora alla v0.4.0 del 27 settembre. I pesi sono stati rilasciati; la nota di lancio no.

Questa distinzione è importante per come interpreti tutto ciò che segue. Ogni dato sulle prestazioni in questo articolo proviene dalle model card di vLLM-SR, misurate con il loro harness sul loro hardware. Nulla di quanto presentato qui è stato riprodotto da terzi, e la classifica su cui pubblicano è gestita da loro. Questa è una lettura precoce e onesta di un artefatto che è reale e di un'affermazione che non è ancora stata sottoposta ad audit.

Cosa c'è davvero su Hugging Face

I sei repository sono semplici, completi e coerenti tra loro. Ognuno contiene pesi safetensors, un template di chat, un decision_config.json che fissa la revisione del modello base, codice di modellazione personalizzato (modeling_d3.py, d3_engine.py, d3_server.py), una testa di lettura nel proprio readout.safetensors, e un MODEL_MANIFEST.json con un SHA-256 per file. Un settimo repository, la pagina della collezione, elenca tutti e sei.

La famiglia, nell'ordine in cui cadono le taglie:

• d3 — 26,09 miliardi di parametri, compreso un encoder visivo da 0,46 miliardi, basato su Qwen/Qwen3.8-27B. Caricato il 10 ottobre, 09:38 UTC.

• d3-flash — 8,39 miliardi, incluso un encoder visivo da 0,46 miliardi, basato su Qwen/Qwen3.5-9B.

• d-mini — 4,54B incluso un encoder visivo da 0,33B, basato su Qwen/Qwen3.5-4B.

• d3-nano — 2,21B inclusi 0,33B di encoder visivo, basato su Qwen/Qwen3.5-2B.

• d3-lite — 0,85B incluso un encoder visivo da 0,10B, basato su Qwen/Qwen3.5-0.8B.

• d3-edge 0,59B, incluso un encoder visivo da 0,10B, anch'esso basato su Qwen/Qwen3.5-0.8B Caricato per ultimo, 23:49 UTC.

Tutti e sei hanno lo stesso contratto di richiesta: uno stato (testo o JSON, opzionalmente con immagini e video) più un dizionario di domande denominate, e una risposta di distribuzioni di probabilità tipizzate. Esistono tre tipi di domande — Choice, Noul (sì/no), Score — e il modello risponde a tutte in una sola chiamata eseguendo un forward pass per domanda sullo stesso input, senza alcun ciclo di decodifica.

I numeri, e di chi sono

vLLM-SR pubblica una classifica che chiama Jev Decision Index 0.3.1 e vi mette d3 in cima. Le righe principali, tutte dichiarate dai fornitori:

• d3 — Indice 64,7, suite pubblica 65,5, test sulle stesse competenze 62,8, attività su nuovi domini 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 generazione precedente — 55.9, 57.0, 55.7, 47.9.

Una nota a piè di pagina sulla card di d3 afferma chiaramente che la riga di d3 stessa è una valutazione interna, mentre le righe di confronto sono dati live della board letti il 10 ottobre. È la giusta informazione da rendere nota e vale la pena leggerla due volte: i numeri dei concorrenti sono stati presi da una board, e il numero del soggetto è stato prodotto dal team che ha costruito il modello. La card sostiene anche che tutte le 140.178 richieste pubbliche hanno ricevuto risposta, nessuna senza supporto — un'affermazione di copertura, non di accuratezza, e insolita da pubblicare.

I checkpoint più piccoli dichiarano di procedere all'unisono. Ogni scheda fornisce un valore per la suite pubblica e un delta rispetto alla dimensione equivalente in Decision 2.0: d3-flash 57,79, in aumento di 11,0 rispetto al precedente 9B; d3-mini 54,90, in aumento di 10,7; d3-nano 42,22, in aumento di 12,2; d3-lite 36,93, in aumento di 16,4; d3-edge 28,82, in aumento di 12,1. I guadagni relativi sono maggiori in fondo all'intervallo, che è ciò che ci si aspetterebbe se la ricetta di pretraining multimodale stesse facendo più lavoro per i modelli piccoli che per quelli grandi — e anche ciò che si otterrebbe facendo il tuning più intenso sui modelli piccoli. Non c'è modo di capire quale delle due sia il caso dall'esterno.

La parte multimodale è il vero cambiamento

I modelli di Decision 2.0 leggono testo. Quelli di Decision 3.0 leggono testo, immagini e video, e questa è la differenza sostanziale tra le generazioni — non lo spostamento dell'indice. Ogni scheda elenca l'input immagine come PNG, JPEG o WebP, fornito come percorsi, URL, immagini PIL o URL di dati base64, con più input per richiesta fino a 1,6 megapixel ciascuno; e il video come MP4, WebM, MOV o MKV, oppure come array di fotogrammi, letto a 2 fotogrammi al secondo con al massimo 32 fotogrammi distribuiti sull'intera clip e ciascun fotogramma fino a 0,2 megapixel. Ogni domanda in una richiesta vede ogni immagine e ogni video a essa allegati.

L'evidenza a supporto per il video è un risultato del Perception Test su tutte le 19.140 domande di validazione: d3 a 77,4, d3-flash 73,3, d3-mini 70,3, d3-nano 63,5, d3-lite 59,3, d3-edge 46,6, rispetto a una soglia di casualità documentata di 33,3 sulle domande a tre opzioni. vLLM-SR lo etichetta come valutazione interna. d3 presenta anche una vision board che la colloca a 71,6 nel complesso, davanti a Perplexity Decider v1.1 a 70,6 e a JEV-27B-VL a 69,6, con le righe di confronto ancora tratte dai dati della board anziché eseguite dagli autori.

I dati di throughput sono riferiti a una singola richiesta, su una singola GPU, e sono dichiarati come tali: d3 risponde a una richiesta di testo in una mediana di 55 ms, a una richiesta che trasporta un'immagine in 273 ms e a una richiesta che trasporta un video di dieci secondi in 553 ms, su una AMD Instinct MI325X. d3-edge fa altrettanto in 6,7 ms, 41,9 ms e 308,3 ms. Queste sono mediane per domanda su un modello progettato per essere chiamato molte volte all'interno di un workflow, ed è il numero che conta per l'architettura per cui questi modelli sono costruiti: venti decisioni sequenziali con 100 ms extra ciascuna costano due secondi, come Microsoft ha fatto la stessa osservazione sul proprio modello decisionale questo mese.

Cosa non dicono i repository

Tre lacune meritano di essere menzionate prima che chiunque pianifichi in base a questo.

Il primo è il budget di input. decision_config.json per i set di modelli più grandi max_length a null, e nessuna scheda indica un limite di token per stato più domande più descrizioni delle opzioni. Le schede di Decision 1.0 pubblicavano budget espliciti — 1.024 token per il ramo encoder, 16.384 per il ramo decoder — e quei numeri sono un vero vincolo di pianificazione. La loro assenza qui è evidente, ed è la cosa più utile in assoluto che un commit successivo potrebbe aggiungere.

Il secondo è la calibrazione. Il numero più importante di un modello decisionale non è l'accuratezza: è se un 0,9 restituito significhi nove volte su dieci. Gli indici di visione e testo non dicono nulla al riguardo. Non c'è alcun punteggio di Brier, nessun valore di errore di calibrazione atteso e nessuna temperatura in nessuna delle sei schede. InternLM ha pubblicato entrambe le cose sul proprio modello decisionale a settembre; vLLM-SR non l'ha fatto, per nessun membro di questa famiglia.

La terza è l'indipendenza. I modelli di Decision 2.0 hanno avuto due settimane di utilizzo esterno; quelli di Decision 3.0 hanno ore. I conteggi dei download dell'11 ottobre — 130 per d3, 83 per d3-lite, 82 per d3-nano — sono l'impronta di un caricamento, non di un'adozione. Considera ogni cifra di indice sopra come un'ipotesi con un repository allegato.

Dove si colloca questo in uno stack che puoi chiamare oggi

La questione pratica riguardo a un modello decisionale è se si inserisca in una pipeline già esistente, e qui l'ecosistema è più avanti di quanto lo siano i modelli. Il formato di richiesta System One che questi modelli usano non è proprietario di vLLM-SR: è lo stesso contratto di stato e domande denominate con cui vengono chiamati i modelli Jev ospitati, ecco perché "Jev" compare sia come nome dell'indice nella model card di d3 sia come riga nella sua classifica.

OrcaRouter copre quel lato della famiglia. typesafe/jev-1.13 è nel nostro catalogo ed è servito tramite POST /v1/systemone — lo stesso contratto, a 0,042 $ per milione di token di input senza costi di completamento perché non c'è alcun completamento, fino a circa 64K token di input, testo in ingresso e JSON strutturato in uscita, non in streaming. È il tipo di modello che un livello decisionale chiama oggi. Due cose che non affermiamo: d3 e il resto di Decision 3.0 non sono nel nostro catalogo, e il percorso di inferenza locale di Decision 3.0 è una classe Python in un repository Hugging Face, non un endpoint che potremmo instradare anche se volessimo. Quello che un router ti offre davvero qui è sull'altro lato del ciclo — il modello generativo che agisce su una decisione, instradato attraverso un'unica chiave su oltre 200 modelli con failover automatico quando un provider vacilla, così che aggiungere uno step di scoring davanti a un workflow non significhi anche aggiungere una seconda relazione con un fornitore.

Cosa cambierebbe questo quadro?

Quattro cose, all'incirca in ordine di quanto vi direbbero. Un post sul blog del progetto che dichiari il budget di input e la forma di deployment prevista, il che confermerebbe che si tratta di un rilascio e non di un push. Un punteggio di Brier o un valore ECE su un qualsiasi checkpoint. Una terza parte che esegua la suite pubblica sui pesi rilasciati invece di leggere l'indice. E un runtime: il repository semantic-router ha registrato due commit l'11 ottobre che collegano d3 e d3-edge al suo runtime dei modelli, incluso l'input video, il che suggerisce che la storia del serving si stia costruendo adesso e sarà ciò che renderà questi modelli economici da provare.

Finché almeno il primo di questi non arriva, il riassunto onesto è questo: esiste una famiglia completa di modelli decisionali, Apache-2.0, autenticamente multimodale, disponibile su Hugging Face da 0,6B a 27B, pubblicata con una provenienza insolitamente buona — hash dei file, revisioni di base fissate, un target hardware dichiarato — e con una quantità insolitamente scarsa della documentazione di contorno che ti permetterebbe di decidere se usarla. Scaricarla non costa nulla. Credere all'indice dovrebbe aspettare.