Decision 3.0 vs Intern-Decision-4B: due team hanno messo a punto lo stesso modello e non erano d'accordo su tutto il resto

Metti d3-mini, il membro 4B di Decision 3.0, accanto a Intern-Decision-4B e la prima cosa che noti non è una differenza. Entrambi sono fine-tune dello stesso checkpoint di base, Qwen3.5-4B. Entrambi sono elencati a 4,54 miliardi di parametri. Entrambi prendono uno stato, uno schema di domande con nome e un insieme di risposte candidate, e restituiscono una probabilità calibrata per candidato senza generare un token. Entrambi sono-2.0. Entrambi sono stati rilasciati senza un annuncio — InternLM ha caricato tre checkpoint in quaranta secondi il 26 settembre 2026, e la famiglia Decision 3.0 di vLLM-SR è arrivata su Hugging Face il 10 ottobre 2026 con la notizia riportata solo dall'account X del progetto vLLM.

Tutto ciò che viene dopo è un disaccordo. Sono in disaccordo su come leggere una probabilità dal modello, se il video conti come input, su quanto può essere lunga una richiesta e — in modo particolarmente netto — se il team sia disposto a pubblicare il numero che dice che la propria fiducia è affidabile. Questo pezzo parla di quei quattro disaccordi e di quanto ciascuno ti costi, non di quale modello sia "migliore", perché i due non sono misurati sulla stessa scala e non possono essere classificati l'uno rispetto all'altro senza fare un lavoro che nessuno dei due fornitori ha fatto.

La coincidenza che vale la pena capire per prima

Che due laboratori scelgano lo stesso backbone da 4B nell'arco di due settimane non è del tutto sorprendente: Qwen3.5-4B è una base ragionevole per un modello a output strutturato, ed entrambi i team vi hanno chiaramente fatto ricorso perché è abbastanza piccolo da poter essere eseguito a basso costo e abbastanza forte da leggere le istruzioni. Ciò che sorprende è che siano arrivati allo stesso numero di parametri, con quattro cifre significative. Questo indica che il fine-tuning ha preservato l'architettura e che nessuno dei due ha aggiunto una torre di visione separata abbastanza grande da far cambiare il totale. Entrambi integrano la loro capacità multimodale negli stessi pesi.

La parte interessante è la lettura dei risultati. Entrambi i modelli rispondono alle domande allo stesso modo in linea di principio — assegnano un punteggio alle risposte candidate anziché generarle — e in modo completamente diverso nel meccanismo:

• Intern-Decision-4B — mappa ogni opzione su un singolo simbolo token (A–Z, poi a–z, poi 0–9), inserisce uno scheletro JSON nel prompt con un segnaposto per campo ed esegue un singolo forward pass causale, leggendo i logit nella posizione immediatamente precedente a ciascun segnaposto. Il meccanismo è documentato passo dopo passo sulla sua scheda del modello, compreso il passaggio esatto di softmax e temperatura.

• d3-mini — rilascia un'architettura personalizzata in modeling_d3.py con una testa di readout separata nel proprio readout.safetensors, un decision_config.json che dichiara noncausal_full_attention e il pooling dell'ultimo token, e una mappatura token-to-code definita nella config anziché descritta in prosa.

Nessuno dei due approcci è ovviamente migliore. La via InternLM ha il vantaggio di funzionare su una classe di modello standard di Hugging Face con una sequenza numerica documentata — puoi verificare il lavoro. La via vLLM-SR ha il vantaggio che il readout è una testa addestrata anziché una proiezione di un embedding di token esistente, il che è un adattamento più libero, e il costo è che devi trust_remote_code=True ed eseguire il loro codice per fare qualsiasi cosa.

I limiti che ciascuno pubblica

È qui che inizia a formarsi una vera preferenza, perché una carta è molto più specifica dell'altra su dove smette di funzionare.

• Limite di input — Intern-Decision-4B: 8.192 token per impostazione predefinita e le richieste che lo superano vengono respinte categoricamente, mai troncate, con il tetto fissato da un argomento del costruttore. d3-mini: max_length è null nella configurazione distribuita e nessun budget di token compare da nessuna parte sulla scheda.

• Domande per richiesta — Intern-Decision-4B: da 1 a 16, con un massimo dichiarato di 62 opzioni in una singola domanda. d3-mini: nessun limite dichiarato; la scheda dice solo che le domande ricevono risposta insieme, ciascuna dal proprio passaggio in avanti.

• Immagini — Intern-Decision-4B: fino a otto per richiesta, ordinati da un elenco che fornisci, con il processore di checkpoint che gestisce il ridimensionamento e l'espansione dei token. d3-mini: più per richiesta come percorsi, URL, immagini PIL o URL di dati base64, ciascuna letta fino a 1,6 megapixel, ogni domanda vede ogni immagine.

• Video — Intern-Decision-4B: nessuno. d3-mini: più video, letti a 2 frame al secondo, con un limite di 32 frame distribuiti lungo la clip e 0,2 megapixel per frame.

Il tetto di input è la linea che deciderà la questione per la maggior parte delle persone. Un budget di 8.192 token condiviso tra stato, istruzioni della domanda e descrizioni dei candidati è un vincolo reale per il lavoro di valutazione dei documenti e di instradamento su contesti lunghi per cui questi modelli vengono venduti, e InternLM merita credito per averlo dichiarato apertamente invece di lasciare che venga scoperto. Il fatto che vLLM-SR non lo dichiari è l'opposto: non un limite nascosto, ma uno ignoto, e nessuna lettura del repository, per quanto approfondita, lo chiarisce.

La calibrazione è la vera divisione

Ogni modello decisionale fa la stessa promessa: il numero che restituisce è una probabilità, e le soglie impostate rispetto a esso significano qualcosa. Quasi nessuno di essi lo dimostra. È qui che le due release divergono maggiormente, e la divergenza va nella direzione opposta a quella che si supporrebbe dalle date di rilascio.

Intern-Decision-4B pubblica, sulla propria scheda, un Brier score di 0,347 e un errore di calibrazione atteso di 0,065 sulla media dei suoi sette benchmark, una temperatura fittata di 1,99241824 derivata dalla minimizzazione NLL su 1.728 casi di calibrazione designati con 1.693 casi di validazione separati, una dichiarazione esplicita che le etichette della suite di test non sono state utilizzate per selezionare quella temperatura, e una diagnostica su 96 casi che mostra la sua calibrazione passare da 0,628 Brier / 0,213 ECE prima del temperature scaling a 0,550 / 0,089 dopo. Afferma anche il default e dice che la calibrazione è per checkpoint, quindi usare un'altra dimensione con questo modulo non corrisponderà.

Decision 3.0 pubblica un indice di accuratezza e una dichiarazione di copertura — tutte e 140.178 le richieste pubbliche hanno ricevuto risposta, nessuna non supportata — e nessun dato di calibrazione. Nessun Brier score, nessun ECE, nessuna temperatura dichiarata, su nessuno dei sei checkpoint. temperatura nel file spedito da d3, decision_config.json è 1.0, che è l'identità e può o non può essere il valore stimato; il file non lo dice.

Leggi fianco a fianco i due titoli degli indici e l'asimmetria peggiora. La scheda di d3-mini riporta un punteggio di 54,90 nella public-suite del Jev Decision Index 0.3, descritto come misurato con il kit ufficiale sui pesi rilasciati, mentre le righe di confronto sulla stessa board sono descritte come dati live della board. Intern-Decision-4B riporta una media di 90,02 sui propri sette benchmark. Quei due numeri non sono sulla stessa scala, non usano gli stessi task e metterli in una sola frase come confronto sarebbe disonesto. Ciò che è comparabile è la disclosure: una scheda ti dice quanto sono sbagliate le sue confidenze, e l'altra non lo sa o non lo vuole dire.

Latenza, e perché nemmeno i due set di millisecondi sono confrontabili

Entrambe le schede pubblicano la latenza per richiesta, e prenderle alla lettera sarebbe un errore per lo stesso motivo per cui le cifre di accuratezza non sono comparabili.

• Intern-Decision-4B — media 44,16 ms, mediana 44,03 ms, p95 44,60 ms, misurati su una singola RTX 4090 tramite il percorso locale di Hugging Face, descritti come dipendenti dal carico di lavoro e dall'hardware.

• d3-mini — mediana di 17,5 ms per il testo, 96,2 ms con un'immagine, 371,5 ms con un video di dieci secondi, su un AMD Instinct MI325X, con una richiesta alla volta.

Due cose li rendono incomparabili. La prima è l'hardware e il percorso software: una 4090 contro una MI325X, un forward pass standard di Hugging Face contro un'implementazione di attenzione personalizzata con kernel di layer mascherati disponibili tramite flash-linear-attention. La seconda è il carico di lavoro: il numero di InternLM è descritto come end-to-end per query su un mix non specificato, e quello di vLLM-SR è suddiviso per modalità di input, quindi il confronto solo testo è l'unica linea like-for-like e anche quella coinvolge due fornitori di GPU.

Il dato da trarre da entrambe le card non è la posizione in classifica, è la forma. Un modello decisionale viene chiamato ripetutamente all'interno di un singolo workflow: un ticket di assistenza potrebbe richiedere una destinazione, una verifica del rimborso, una decisione di escalation e un punteggio di priorità — quattro domande — e un lotto di 128 record lo trasforma in 512 decisioni. A quel volume, 17 ms e 44 ms svaniscono entrambi di fronte a qualunque cosa costi il modello generativo a valle. I valori dipendenti dalla modalità sono quelli a cui prestare attenzione, perché una richiesta di immagine o di video costa tra cinque e venti volte una richiesta di testo, secondo i numeri di d3-mini stesso, e se la tua decisione viene presa su uno screenshot hai importato un profilo di costo che la maggior parte dei deployment di modelli decisionali non ha.

Quale scegliere davvero

Se la decisione che devi prendere dipende da un video, non c'è partita né analisi necessaria: Decision 3.0 legge i video e Intern-Decision-4B no. Questa è la risposta completa per tutto ciò che riguarda registrazioni dello schermo, filmati della fotocamera o sequenze di fotogrammi, ed è il divario di capacità che da solo giustifica l'esistenza della famiglia più recente.

Se i tuoi input sono testo e immagini occasionali, la scelta dipende da due cose e nessuna delle due è la classifica.

Prendi Intern-Decision-4B quando hai bisogno di ragionare sulle soglie. È l'unico dei due che ti dice se un 0,9 significa nove volte su dieci, dichiara la sua temperatura, indica su quali casi è stata calibrata quella temperatura e documenta la sua inferenza come una breve procedura numerata che puoi reimplementare rispetto a una classe di modello standard. Per uno scorer posto davanti a un'azione automatizzata, questa è la proprietà che conta, ed è più rara dei punti di accuratezza.

Scegli Decision 3.0 quando ti servono la gamma o le modalità. Sei checkpoint da 0,59B a 26,09B significano che lo stesso formato di richiesta può essere servito da un modello edge da 6,7 ms e da uno da 27B, e la famiglia condivide un'unica interfaccia, quindi passare da un livello all'altro è un cambio di configurazione anziché una riscrittura. L'insidia è che ti stai fidando di un budget di input non dichiarato e di un'affermazione di calibrazione non verificata, e il modello più grande della famiglia è quello il cui numero di indice il fornitore ha misurato sul proprio harness.

Nessuno dei due è oggi un default sicuro. Il checkpoint più scaricato di d3 è su Hugging Face da circa un giorno; Intern-Decision-4B è online da due settimane e ha totalizzato circa 3.200 download e 83 like, il che è attenzione, ma non traffico di produzione. Entrambi sono abbastanza economici da testare e nessuno dei due ha alle spalle una valutazione di terze parti. Se stai mettendo uno scorer davanti a qualcosa che spende denaro, la mossa giusta è eseguire entrambi sui tuoi casi etichettati e confrontare le curve di calibrazione, non le righe dell'indice.

Dove un router si inserisce, onestamente

OrcaRouter non supporta nessuno di questi due modelli. I checkpoint di Decision 3 sono un percorso di inferenza locale in un Hugging Face privo di endpoint HTTP, e Intern-Decision-4 viene distribuito come unaDecisionclasse che si istanzia da soli. Nessuno dei due è qualcosa che potremmo instradare oggi, e nessuna parte di questo articolo dovrebbe essere interpretata come un'affermazione di disponibilità.

Quello che invece offriamo è la parte hosted della stessa famiglia. typesafe/jev-1.13 è nel nostro catalogo, servito tramite POST /v1/systemone — lo stesso contratto di stato e domande denominate che entrambi i modelli aperti qui sopra implementano — a 0,042 $ per milione di token di input senza alcun costo per le completion, dato che non ne genera mai nessuna. Si affianca ad altri oltre 200 modelli, e questo è il punto pratico per chiunque confronti questi due: lo scorer è la parte economica del ciclo, mentre il modello che agisce sulla decisione è la parte costosa. Instradare entrambi attraverso un'unica chiave, con failover automatico quando un provider vacilla e il prezzo di listino del provider passato senza alcun ricarico (0% di markup), significa che valutare un modello decisionale non richiede di firmare un secondo contratto né di riscrivere il call site quando si cambia backend. Se siete nel mezzo di una valutazione — ed è la situazione in cui si trovano entrambi questi modelli, oggi — questa è la parte che vale la pena configurare prima di impegnarvi con l'uno o con l'altro.

La questione aperta

Le due schede non concordano su ciò che un autore di modelli deve a un lettore, e questo disaccordo è più interessante dei modelli stessi. InternLM ha pubblicato una temperatura e i casi utilizzati per il fit, poi ha pubblicato la diagnostica che mostra quanto è migliorata la calibrazione. vLLM-SR ha pubblicato hash dei file, revisioni di base fissate, un obiettivo hardware dichiarato, una dichiarazione di copertura — vero lavoro di provenienza — e nessun numero di calibrazione.

Il test per stabilire quale release matura non è quale vince una classifica. È se il prossimo checkpoint Decision viene rilasciato con un Brier score associato, e se il prossimo upload di InternLM arriva al video. Entrambi sono visibili dall'esterno, entrambi sono economici da verificare, e nessuno dei due è ancora accaduto.