RSI-Jev vs Jev 1.13: uno lo scarichi, l'altro lo chiami

Metti RSI-Jev v6.1-VL 4B e Jev 1.13 uno accanto all'altro e la prima cosa che un chiamante nota è che sono la stessa richiesta. Dai a uno dei due uno stato e una serie di domande tipizzate — un sì/no, una scelta di una tra k opzioni, una valutazione su una rubrica — ed entrambi restituiscono una probabilità calibrata per ogni opzione, in un'unica passata in avanti, senza testo generato da analizzare. Non è una coincidenza: RSI-Jev è costruito di proposito per parlare il formato wire di Jev, quindi un client scritto per l'API di TypeSafe funziona con esso cambiando un URL di base. Ciò che non è uguale è tutto il resto attorno alla chiamata. Jev 1.13 è il modello commerciale chiuso di TypeSafe, servito da un endpoint a consumo; RSI-Jev v6.1-VL è un checkpoint da 4,69 miliardi di parametri con pesi Apache-2.0 che scarichi e servi sul tuo hardware. Nessuno dei due è un rebranding dell'altro, nessuno dei due fornitori approva l'altro, e quasi ogni cifra in questo confronto proviene dalla parte che l'ha prodotta.

La data nell'oggetto conta, perché questo progetto rilascia una release più o meno ogni giorno. RSI-Jev v6.1-VL 4B è stato pubblicato il 2026-10-07 da Shanghua-Gao/RSI-Jev, un progetto di terze parti — un ciclo di ricerca auto-migliorante che addestra modelli decisionali in stile Jev e pubblica ogni braccio che ha fallito insieme a quelli che hanno vinto. È l'ottava release in tredici giorni su quella linea, ed è una media ponderata della release precedente con un secondo fine-tuning dello stesso Qwen3.5-4B-Base. Jev 1.13 è il modello di TypeSafe AI, lanciato il 2026-09-15 e presente nel nostro catalogo dal 2026-09-24. Entrambe le date contano qui sotto, perché un confronto con un progetto che si muove ogni giorno ha una durata di conservazione misurata in giorni.

Cosa sono davvero i due, in una riga ciascuno

Jev 1.13 è un modello decisionale ospitato dietro un endpoint dedicato — POST /v1/systemone, non in streaming, con un budget di input di circa 64.000 token ripartito tra lo stato e tutte le tue domande insieme, al prezzo di $0.042 per milione di token di input, con l'output fatturato a zero perché non ci sono token di output. La sua architettura, il numero di parametri e il compute di addestramento non sono divulgati; TypeSafe ha dichiarato che i dettagli vengono tenuti riservati e che potrebbe seguire un paper. Tu non lo esegui. Lo chiami, e ogni chiamata è una richiesta di rete misurata.

RSI-Jev v6.1-VL è l'altra configurazione completa. È una torre Qwen3.5-4B-Base fine-tuned end-to-end, con teste decisionali ai layer 16, 20 e 32, servita da un checkpoint autosufficiente e di 9,7 GB in bf16. Il numero di parametri è 4,69B e vale la pena sapere come sono distribuiti: 3,57B nei 32 layer decoder, 0,64B negli embedding dei token, 0,33B nella torre di visione, 0,05B nella testa decisionale principale e 0,10B nelle due teste di uscita anticipata. Non c'è alcun mixture of experts e nessun secondo modello. Lo installi con un comando pip dal repository, avvii il suo server e da quel momento la decisione non lascia mai la tua infrastruttura.

• Chi lo gestisce — un endpoint ospitato a consumo che non controlli, contro un checkpoint da 9,7 GB sulla tua GPU, su Apple Silicon o sulla CPU.

• Struttura del prezzo — $0.042 per milione di token di input, output gratuito, pagamento per chiamata rispetto a zero al margine più il costo della macchina e.

• Budget di input — circa 64.000 token per richiesta sul modello ospitato rispetto a 32.768 token di testo più un budget per le immagini sul checkpoint, con qualsiasi input più lungo rifiutato anziché troncato.

• Pesi e licenza — chiusi, dimensione non divulgata vs pesi Apache-2.0, codice MIT, 4,69 miliardi di parametri.

• Modalità — testo per il contratto di Jev rispetto a testo più fino a quattro immagini per richiesta nelle release vision di RSI-Jev.

• Proprietà — il modello commerciale di TypeSafe AI rispetto a un progetto di ricerca di terze parti che dichiara nella propria riga di licenza di "non essere affiliato a TypeSafe AI".

Il punteggio sul tabellone di RSI-Jev, e perché è solo metà di un confronto

Il numero con cui il progetto si presenta è il suo punteggio Decision Index 0.3: 50,98 per v6.1-VL 4B, in aumento rispetto a 46,23 della release precedente. Si tratta di un'esecuzione completa della configurazione predefinita — 140.178 richieste, copertura 1,0 — e sulla classifica pubblica del progetto stesso, datata 2026-10-06, eguaglia il miglior modello 4B su quella classifica (50,98 contro il 50,82 di ezjev 4B s2, che il kit considera un pareggio a 0,25) e si colloca al 27º posto su 113 nel complesso. Sul più vecchio Decision Index 0.2.1 segna 50,74 contro il 46,24 di v6.0-VL. La sua suite di quindici benchmark, riportata senza il open_jev_ood task, che si è scoperto sovrapporsi a righe di addestramento, è 0,793, e il suo set hold-out è 0,729.

Ognuno di quei numeri è di RSI-Jev stesso, misurato sull'harness di RSI-Jev. Il Decision Index è una classifica di benchmark pubblica, ma non vi è alcuna lettura di Jev 1.13 su di essa, perché la suite del progetto è stata costruita per valutare checkpoint decisionali aperti e Jev è un endpoint chiuso. Quindi la tentazione di mettere 50,98 contro lo 0,727 di Jev sul benchmark delle decisioni tipizzate e dichiarare un vincitore è esattamente l'errore da evitare: quei due numeri provengono da harness diversi, dimensioni campionarie diverse e dati diversi, e nessuno ha eseguito un unico harness su entrambi i modelli.

L'unico testa a testa che esiste è quello di Laya, non quello di RSI-Jev

C'è un confronto che mette effettivamente un numero Jev accanto a un checkpoint, e non è stato eseguito da nessuna delle due parti qui. Convai, i creatori del modello Laya, ha tabulato le cifre pubblicate di TypeSafe Jev 1.13.0 contro le proprie e ha segnalato i numeri stessi: i numeri Jev sono pubblicati da terzi e non sono mai stati misurati da Convai, le dimensioni del campione e i prompt differiscono, e il fornitore non elenca i propri benchmark, poiché quella tabella vale la pena leggerla per calibrazione, non per un verdetto — e non include affatto RSI-Jev, perché RSI-Jev non esisteva quando è stata pubblicata.

Ciò che invece mostra è la forma della domanda hosted vs open che un lettore sta effettivamente soppesando. Il modello hosted è in vantaggio dove lo spazio delle opzioni è ampio e il modello deve mantenere stabile un ampio insieme di risposte; i modelli aperti vincono sulla latenza grezza per chiamata perché non c'è rete nel percorso. Niente in quel pattern ti dice quale di questi due modelli specifici sia migliore per il tuo compito, e la posizione onesta è che la risposta non esiste ancora pubblicamente.

Che cosa offre il checkpoint che l'endpoint non può offrire

L'argomento più forte a favore di RSI-Jev non è un punteggio. È che i pesi risiedono sul tuo disco. Per una decisione di routing presa su una cartella clinica, un documento legale o la cronologia di un conto cliente, "i dati non lasciano mai l'edificio" non è una preferenza da scambiare con un punto di benchmark — è un requisito tassativo, e nessun endpoint ospitato a qualsiasi prezzo vi risponde. La stessa proprietà elimina il rate limit: la documentazione del fornitore stesso per il modello ospitato osserva che i suoi limiti vengono adeguati dinamicamente e possono cambiare senza preavviso, e un checkpoint self-hosted non ha alcun tetto del genere oltre al tuo hardware.

La seconda cosa che il checkpoint offre è il controllo della profondità, ed è insolito. Poiché le teste decisionali si trovano a tre profondità, un'impostazione di effort determina quante layer può usare una richiesta: low si ferma al layer 16 con una mediana di circa 23 ms, medium a 20 con 27 ms, high a 32 con circa 40 ms, e auto risponde alla prima uscita sufficientemente sicura, con una media di 19,5 layer su 32 nella suite del progetto. Quelle latenze sono i numeri del progetto stesso, misurati su un H200 in bf16, e non dovrebbero essere mescolate con alcuna cifra hosted — un forward pass locale e una chiamata API a consumo non sono la stessa misurazione, e la documentazione di RSI-Jev è esplicita sul fatto che il suo precedente confronto con la latenza pubblicata di Jev contrapponeva il lavoro su GPU locale a un round-trip di rete.

La terza cosa sono le immagini. Il contratto di Jev è testo in ingresso, JSON strutturato in uscita. Le release vision di RSI-Jev accettano da una a quattro immagini per richiesta come data URL base64, con lo stato che fa riferimento a ciascuna tramite un marcatore, e v6.1-VL ottiene un punteggio di 0,834 sul set di immagini held-out del progetto. Se la tua decisione è "la foto mostra danni visibili", si tratta di una capacità che il contratto ospitato non offre affatto.

Anche ciò a cui rinunci è reale, e il progetto lo pubblica. La calibrazione è peggiorata in questa versione, non migliorata: l'errore di calibrazione atteso finale è 0,048 al livello 32 e 0,055 con auto, contro 0,036 e 0,024 della versione precedente. La singola soglia predefinita di 0,95 viene rilasciata esplicitamente come non confermata — è il fallback di una regola di selezione la cui scelta, 0,85, non ha raggiunto il tetto di profondità del progetto su metà dei suoi dati di sviluppo. Le uscite anticipate leggono solo testo, quindi qualsiasi domanda con un'immagine esegue tutti i 32 livelli indipendentemente dall'impegno. E cinque delle fonti di addestramento per immagini sono non commerciali o solo per ricerca, con il progetto che dichiara chiaramente che non è stabilito se i pesi addestrati su dati non commerciali ereditino quei termini.

Dove chiamare quello ospitato, e dove no

Questa è la parte del confronto che ci riguarda direttamente, quindi vale la pena essere precisi. Serviamo il modello commerciale di TypeSafe come typesafe/jev-1.13 sull'endpoint dedicato systemone — una POST a /v1/systemone anziché il formato chat-completions di OpenAI, non in streaming, rispetto al contesto di 65.536 token elencato nel nostro catalogo. È la stessa richiesta e lo stesso formato che RSI-Jev implementa, dal contratto del modello che il progetto copia. RSI-Jev in sé non lo ospitiamo; non esiste alcun id rsi-jev né alcun id shgao nel nostro catalogo, e chi desidera quel modello se lo scarica.

La ragione per cui questa distinzione conta qui è circoscritta e concreta. Uno strato decisionale raramente costituisce l'intero flusso di lavoro — di solito si affianca a un modello generativo che scrive la risposta, il riepilogo o il codice. Storicamente questo ha significato due contratti. Per la parte ospitata non deve più essere così: Jev 1.13 si trova sulla stessa chiave di oltre 200 altri modelli al prezzo di listino del provider passato con markup dello 0%, quindi se TypeSafe modifica una tariffa, la modifica è attiva dalla nostra parte lo stesso giorno anziché al ciclo di fatturazione successivo. La parte self-hosted non ha mai avuto questo problema, perché il provider sei tu. Il modo pulito per decidere tra i due è provare prima il contratto commerciale su una manciata di tuoi casi etichettati, vedere se il comportamento out-of-the-box è abbastanza buono da poterci automatizzare, e solo allora valutare se eseguire da soli un checkpoint da 4,69B valga l'impegno operativo.

Quale dovresti scegliere davvero

Scegli RSI-Jev v6.1-VL 4B se la decisione deve rimanere all'interno del tuo perimetro, se ti serve una decisione sia su un'immagine sia su testo, se i tuoi insiemi di opzioni arrivano a centinaia (il checkpoint ammette fino a 5.120 opzioni per domanda), o se vuoi regolare profondità e latenza per richiesta. Entra sapendo che stai adottando un progetto che si è mosso otto volte in tredici giorni, che la sua ultima release ha scambiato la calibrazione con l'accuratezza, e che la sua stessa scheda nomina le parti della politica di uscita che non ha potuto confermare.

Scegli Jev 1.13 se vuoi che la decisione funzioni senza uno stack di serving, se apprezzi un endpoint che qualcun altro mantiene attivo e se il prezzo di $0,042 per milione di input — senza token di output da misurare — è conveniente rispetto al tuo volume di chiamate. Procedi sapendo che stai chiamando un modello chiuso la cui dimensione non è divulgata, i cui limiti di frequenza possono cambiare senza preavviso e i cui benchmark pubblicati non sono qualcosa che puoi rieseguire.

Ciò che entrambi condividono è più utile di ciò che li separa, ed è il motivo per cui un confronto come questo merita di essere scritto. Nessuno dei due modelli genera testo, quindi nessuno dei due introduce la classe di guasti che deriva da un modello che dimentica di chiudere una parentesi graffa o inventa un campo. Entrambi restituiscono probabilità, e in entrambi i casi la probabilità è la parte che devi validare sui tuoi dati etichettati prima di automatizzare su di essa — la latenza è già commoditizzata, e il valore di confidenza è ciò che deve essere guadagnato per ogni implementazione. Qualunque sia il lato della linea tra download e chiamata su cui ti trovi, testa prima la calibrazione.