RSI-Jev vs Laya: due modelli decisionali aperti, scommesse opposte

A partire da ottobre 2026 esistono due modelli a pesi aperti che vale la pena considerare se si vogliono decisioni tipizzate — un sì/no, una scelta di uno tra k, una valutazione secondo una rubrica — senza un endpoint ospitato nel percorso. Sono RSI-Jev v6.1-VL 4B, pubblicato il 2026-10-07 dal ciclo di ricerca indipendente Shanghua-Gao/RSI-Jev, e Laya, rilasciato il 2026-09-18 da Convai Innovations. Entrambi rispondono in un unico passaggio in avanti senza testo generato; entrambi restituiscono una probabilità calibrata per ogni opzione; entrambi sono distribuiti con pesi Apache-2.0 e un server che parla l'API delle decisioni di TypeSafe, così un client scritto per il modello commerciale funziona con l'uno o con l'altro cambiando un URL di base. Sono anche costruiti su scommesse opposte, e i due numeri che li separano sono da 3 a 4 token per etichetta e 421 milioni di parametri.

La prima scommessa riguarda la scala. Il checkpoint inglese di Laya è ModernBERT-large con 421 M di parametri e un contesto di 512 token, mentre il suo checkpoint multilingue è mmBERT-base con 322 M e una finestra di 1.024 token che raggiunge 8.192 con l'encoder impostato in modalità estesa. RSI-Jev v6.1-VL esegue un'intera torre Qwen3.5-4B-Base — 4,69 miliardi di parametri, 3,57 miliardi dei quali nei 32 strati del decoder, più una torre visiva e tre teste decisionali agli strati 16, 20 e 32. Laya è un modello di cui puoi precaricarne tre in pochi gigabyte; RSI-Jev è un checkpoint bf16 da 9,7 GB. La seconda scommessa deriva dalla prima: Laya spende quasi nulla per chiamata e si aspetta che tu gli insegni il tuo dominio, mentre RSI-Jev spende quattro miliardi e mezzo di parametri cercando di rispondere alla tua domanda senza alcun addestramento.

A cosa serve ciascuno in realtà

La model card di Laya stessa contiene la frase che inquadra questo confronto meglio di quanto potrebbe fare qualsiasi recensore: "Laya è una base veloce su cui specializzarsi, non un motore decisionale zero-shot." Sul benchmark typed-decisions — 2.000 decisioni su quattro workflow — il checkpoint base in inglese ottiene 0,362, contro 0,318 per la scelta casuale e 0,461 per scegliere sempre la classe maggioritaria. Sulle stesse decisioni, il checkpoint di Convai, addestrato con fine-tuning sullo split di addestramento proprio di quel benchmark, ottiene 0,766, superando il tetto di 0,735 dell'accordo con il teacher. Quel divario è il prodotto: Laya è un encoder da 421M su cui fai fine-tuning per una tassonomia ristretta, e Convai fornisce un notebook Kaggle che esegue l'intero ciclo — costruire il dataset, addestrare, adattare le temperature di calibrazione, valutare — su due T4 gratuite.

RSI-Jev è l'altra opzione. La sua release v6.1-VL ottiene 50,98 sul proprio Decision Index 0.3 pubblico, un'esecuzione di 140.178 richieste della configurazione predefinita, che sulla classifica del progetto datata 2026-10-06 eguaglia il miglior modello 4B presente e si colloca al 27º posto su 113 in totale. La sua suite di quindici benchmark vale 0,793 e il suo set held-out vale 0,729. Si tratta di cifre zero-shot — anche se il progetto tiene a precisare che dieci dei quindici benchmark forniscono dati di addestramento in qualche forma, quindi «zero-shot» si applica alla ricerca della release, non a ogni numero della pagina. Quello che le cifre ti garantiscono davvero è un modello che risponde a una domanda su un documento che non gli hai mai mostrato e che non ha bisogno di un addestramento preliminare.

• Dimensione — Laya 421M inglese / 322M multilingue vs RSI-Jev 4,69B, che esegue l'intera torre Qwen3.5-4B-Base.

• Accuratezza zero-shot — Laya 0.362 su typed-decisions, al di sotto della baseline di maggioranza di 0.461 rispetto a RSI-Jev 50.98 sul proprio Decision Index 0.3, eguagliando lì il miglior risultato 4B.

• Precisione dopo fine-tuning — Laya 0,766 con un checkpoint addestrato sullo split del benchmark stesso, rispetto ai valori di RSI-Jev che sono a livello di release e non per dominio.

• Lingue — Laya 45 lingue su 51 utilizzabili, oltre tre volte il routing casuale lato server rispetto al testo incentrato sull'inglese di RSI-Jev.

• Modalità — Solo testo Laya rispetto a testo RSI-Jev più fino a quattro immagini per richiesta.

• Contesto — Laya 512 token in inglese, 1.024 multilingue e fino a 8.192 per i documenti lunghi, contro i 32.768 token di RSI-Jev, rifiutati anziché troncati.

• Latenza — Laya 32,8 ms p50 su una T4, 7,2 ms per domanda con batch dieci rispetto a RSI-Jev 22,5 ms con impegno basso e circa 40 ms alla massima profondità, su una H200.

Il precipizio del numero di opzioni è la differenza più netta.

Entrambi i modelli definiscono lo spazio delle risposte al momento della richiesta, quindi un nuovo schema non richiede un nuovo addestramento — è il vantaggio strutturale condiviso di tutta questa famiglia. Ma allocano lo spazio delle risposte in modo diverso, e la differenza emerge proprio sui compiti che il routing aziendale tende a dover affrontare. Laya assegna un punteggio a ogni opzione sul proprio token mascherato, e le opzioni condividono un budget fisso per la testa: 192 token sul checkpoint inglese, 256 su quello multilingue. Su Banking77, con 77 intenti, ciò equivale a circa tre o quattro token per etichetta, e l'accuratezza scende a 0,425. La scheda di Convai stessa documenta il crollo e offre la soluzione — aumentare head_max_len a 512 e il contesto a 1.024 o più, in modo che ogni etichetta abbia spazio, oppure suddividere un ampio insieme di opzioni in una scelta in due passaggi dal grossolano al fine.

Il percorso di serving di RSI-Jev ammette fino a 5.120 opzioni per domanda. Non è un benchmark omogeneo rispetto al 0,425 di Laya: i due sono stati misurati su harness diversi, e il tetto delle opzioni è un limite di configurazione, non un punteggio. È un'affermazione su quale modello non crollerà quando la tua tassonomia ha cento voci. Se le tue domande a scelta sono «fatturazione / tecnico / vendite / altro», entrambi funzionano. Se sono un centinaio abbondante di etichette di intento, uno di questi due deve essere messo a punto prima di essere utilizzabile, e l'altro no.

Latenza, la questione linguistica e le immagini

L'affermazione di Laya sulla latenza è la sua più clamorosa, ed è reale: 32,8 ms p50 per una singola domanda su una Tesla T4, 72,3 ms per un batch di dieci e 337 ms per cinquanta — da 103 a 332 domande al secondo su una singola GPU modesta. I numeri di RSI-Jev stesso, misurati su una H200, sono 22,5 ms con effort low, 26,8 ms con medium, 39,9 ms per impostazione predefinita e 40,4 ms a piena profondità. Sono lo stesso ordine di grandezza, ed entrambi sono forward pass locali anziché chiamate di rete, che è il confronto che conta davvero una volta che un endpoint ospitato è fuori dai giochi. Nota cosa fanno i due con il tempo: RSI-Jev può fermarsi deliberatamente al layer 16 per guadagnare quei 22,5 ms ed eseguirne tutti e 32 quando la domanda è difficile, mentre Laya non ha una leva del genere — esegue sempre l'intero suo (piccolo) encoder.

La questione linguistica va nella direzione opposta ed è decisiva per chiunque sia al di fuori dell'inglese. Laya include un router che rileva la scrittura in ben meno di un millisecondo e indirizza al checkpoint multilingue, e la sua tabella pubblicata mostra che 45 delle 51 lingue sono utilizzabili al di sopra di tre volte il livello casuale, contro 23 per il solo checkpoint inglese. La sua scheda è anche onesta su perché questo conti: il checkpoint inglese crolla sulle scritture non latine — il khmer ottiene 0,000 di accuratezza con 0,952 di confidenza — quindi il filtraggio basato sulla confidenza non può salvare un instradamento sbagliato. RSI-Jev non ha una storia linguistica di questo tipo; è un modello testuale incentrato sull'inglese che, per caso, legge le immagini.

Per le immagini vale il discorso speculare. RSI-Jev ne accetta da una a quattro per richiesta come URL di dati base64 e ha ottenuto 0,834 sul suo set di immagini di hold-out in questa versione; i checkpoint rilasciati di Laya sono classificatori di testo, e sebbene port della community come laya-vision esistano sull'Hub, non sono il prodotto del fornitore. Se la tua decisione riguarda una foto, un grafico o uno screenshot, quella è la colonna di un modello e non dell'altro.

Nessuno dei due è stato sottoposto a benchmark rispetto all'altro.

Questa è la parte che un confronto specifica per specifica nasconde silenziosamente: non esiste un testa a testa tra questi due modelli. Ciò che esiste è un testa a testa tra ciascuno di essi e lo stesso modello chiuso — Jev 1.13 di TypeSafe — e nessuno dei due può essere messo accanto all'altro.

Convai ne ha pubblicato uno: su typed-decisions, Jev 1.13.0 a 0.727 contro il routed di Laya a 0.766; su Banking77, Jev 0.870 contro lo 0.425 di Laya; sulla calibrazione, Jev 0.246 contro lo 0.081 di Laya dopo la correzione della temperatura. Convai segnala i propri limiti nella stessa tabella — i dati di Jev sono pubblicati da terzi, non hanno mai avuto accesso API per misurarlo, e le dimensioni del campione e i prompt differiscono. Il confronto di RSI-Jev è il Decision Index, che è la classifica pubblica di RSI-Jev stesso e non contiene alcuna voce Jev. Quindi gli unici numeri esterni che toccano entrambi questi modelli provengono da harness costruiti dalle parti che li vendono, e la lettura sensata di qualsiasi singolo dato sopra è "questo è ciò che il produttore ha misurato, sul compito del produttore."

Ciò che entrambi i progetti fanno bene, e raramente, è pubblicare le proprie debolezze. RSI-Jev elenca le cinque fonti di immagini non commerciali alla base delle sue release di visione e dice chiaramente che non è stabilito se i pesi addestrati su di esse ereditino quei termini; segnala una regressione di calibrazione nella sua release più recente e definisce non confermata la sua soglia di uscita predefinita. Laya documenta che i suoi checkpoint di base si collocano al di sotto della baseline di maggioranza, che le sue domande sul punteggio ordinale sono la sua primitiva più debole, che il suo noul può seguire le proprie etichette delle opzioni anziché lo stato, e che uno dei suoi campi di risposta non porta alcun segnale utilizzabile. Quell'onestà è la cosa più utile da ereditare dall'uno o dall'altro progetto: controlla i valori di confidenza sui tuoi casi etichettati prima di automatizzare sulla loro base.

Dove si trova davvero il contratto che copiano

Entrambi questi modelli esistono perché valeva la pena copiare un formato di trasmissione. Jev di TypeSafe definisce la forma della richiesta — stato, domande, tre primitive tipizzate — e la forma della risposta, e sia Laya sia RSI-Jev lo implementano affinché un client esistente funzioni cambiando un URL di base. Quel modello di riferimento, typesafe/jev-1.13, è quello dei tre che serviamo: è nel nostro catalogo sull'endpoint dedicato systemone, un POST a /v1/systemone, non in streaming, con un contesto di 65.536 token, a 0,042 $ per milione di token di input con l'output fatturato a zero. Né Laya né RSI-Jev sono nel nostro catalogo — entrambi sono download, ed è proprio questo il punto.

La versione pratica di questo conta più del confronto. I livelli decisionali non sono quasi mai da soli in uno stack; stanno accanto a un modello generativo che scrive la risposta, il riepilogo o il codice. Avere il contratto di riferimento sulla stessa chiave di oltre 200 altri modelli, a prezzo di listino del provider passato con 0% di ricarico, significa che una variazione delle tariffe del fornitore ti arriva lo stesso giorno, e il failover automatico significa che la metà generativa di quella coppia non è un singolo punto di guasto mentre valuti se la metà decisionale economica è abbastanza buona. Se decidi che un encoder self-hosted da 421M o un checkpoint da 4,69B è la scelta giusta, vuoi comunque che il contratto con cui parla sia raggiungibile dallo stesso posto — e se preferisci non eseguirne nessuno dei due, il modello che entrambi copiano è a una richiesta di distanza.

Quale scaricare

Scegli Laya se disponi di dati etichettati, di una tassonomia che non cambia molto e di una miscela linguistica che non sia solo inglese. È abbastanza piccolo da poterne eseguire molti, abbastanza veloce da metterlo davanti a ogni richiesta ed è progettato fin dall'inizio per il fine-tuning: il punteggio di 0,766 con fine-tuning contro 0,362 zero-shot è l'intero argomento. Metti in budget l'esecuzione dell'addestramento, l'etichettatura e il refit della temperatura per domanda che porta il suo errore di calibrazione da 0,466 a 0,027, e mantieni gli insiemi di opzioni al di sotto di circa venti etichette oppure aumenta il budget per la testa prima di affrontare una classificazione su larga scala.

Scegli RSI-Jev v6.1-VL se vuoi che una decisione funzioni senza alcun addestramento preliminare, se le tue domande riguardano talvolta un'immagine, se i tuoi insiemi di opzioni sono grandi, o se vuoi scambiare latenza con profondità per richiesta. Aspettati di eseguire un checkpoint da 9,7 GB anziché uno da 400M, aspettati un progetto che ha pubblicato otto release in tredici giorni e che potrebbe pubblicarne un'altra mentre stai valutando questa, e aspettati di dover controllare tu stesso la sua calibrazione — la scheda di questa stessa release dice che è peggiorata, non migliorata.

Qualunque tu scelga, valgono le stesse due cose. Nessuno dei due modelli genera testo, quindi nessuno dei due può fallire emettendo un campo malformato; entrambi restituiscono probabilità, e la probabilità è la parte che deve essere validata per ogni deployment anziché presa da una scheda. Ed entrambi hanno spostato l'interessante questione di un livello decisionale da "di chi è l'API" a "di chi sono i pesi" — che è una domanda migliore da porsi, e una a cui questa coppia risponde in modo molto diverso.