Una card del titolo generata che riporta "Laya spiegato" sopra il sottotitolo "Un modello decisionale che risponde senza scrivere un singolo token", con un piè di pagina che riporta "Tutti i dati secondo la scheda del modello Laya, salvo diversa indicazione."
Engineering & Research

Laya spiegato: un modello decisionale che risponde senza scrivere un singolo token

Autore

Rowan Sterling

Data di pubblicazione

Ultimi modelli · 20Vedi tutti i modelli
Benchmark: Artificial Analysis · aggiornato ogni giorno
Torna a tutti gli articoli

La cosa più interessante di Laya non è la sua velocità. È che ogni opzione che gli offri viene valutata sul proprio [MASK] token, e le probabilità vengono poi passate a softmax sulle opzioni di quella singola domanda. Convai Innovations ha pubblicato i pesi di Laya su Hugging Face il 18 settembre 2026, con licenza Apache 2.0 — tre checkpoint, un repository, 421M parametri per il modello inglese. Non ci sono token di output. Non c'è alcun ciclo di decodifica, nessun JSON da analizzare, nessuna parentesi graffa da dimenticare di chiudere. Gli passi uno stato e una serie di domande tipizzate e, dopo un solo forward pass, ottieni una scelta tra opzioni denominate, un punteggio ordinale con un livello atteso oppure una probabilità che un'affermazione sia vera. Quel design ha una conseguenza che molti trascurano: poiché lo spazio delle risposte viene assemblato per richiesta invece di essere incorporato in una testa di vocabolario, uno schema che inventi questo pomeriggio non ha bisogno di alcun riaddestramento. Ha anche un limite, e il progetto lo dichiara chiaramente sulla propria model card: i checkpoint base ottengono 0,362 sul benchmark typed-decisions, contro 0,318 per l'indovinare a caso e 0,461 per rispondere sempre con la classe maggioritaria. La frase stessa di Convai è quella da tenere a mente — "Laya è una base veloce da specializzare, non un motore decisionale zero-shot." L'ovvio termine di paragone è Jev di TypeSafe AI, un modello System One ospitato senza pesi pubblicati, senza numero di parametri pubblicato e senza modello base pubblicato. Laya è la risposta open-weights a esso. Se quella risposta ti sia utile dipende quasi interamente da quale metà della pipeline stai cercando di sostituire.

Cos'è realmente Laya e cosa non è

Inizia dal negativo, perché è lì che la maggior parte dei resoconti sbaglia. Laya non è un LLM. È non autoregressivo: un singolo passaggio in avanti produce la risposta e il modello non emette mai testo. Confrontare la sua latenza con i token al secondo di un modello di chat equivale a confrontare due operazioni diverse — una classifica, l'altra genera. Se ti serve un paragrafo, un riassunto, un piano o una catena di ragionamento, Laya non può dartelo e non ci sta nemmeno provando.

Cos'è: un encoder bidirezionale con una testa decisionale fissata sopra. Il checkpoint inglese è ModernBERT-large — 395M parametri, completamente fine-tuned — più una testa addestrata da zero composta da due layer transformer, un valutatore di marcatori di opzione e una testa act/escalate, per un totale di 421M. Il checkpoint multilingue sostituisce il backbone con mmBERT-base, 22 layer e un vocabolario da 256k, per un totale di 322M. Tre checkpoint sono forniti in un unico repository, e viene scaricato solo quello che richiedi:

convaiinnovations/laya — ModernBERT-large, 421 milioni di parametri, contesto di 512 token, inglese, circa 808 MB su disco.

convaiinnovations/laya-multilingual — mmBERT-base, 322M parametri, contesto di 1.024 token (l'encoder supporta fino a 8.192 con RoPE), oltre 100 lingue, circa 2,2 volte più veloce, circa 647 MB.

convaiinnovations/laya-typed-decisions — ModernBERT-large, 421M parametri, contesto di 1.024 token, e l'unico dei tre che riporta la cifra 0,766 che vedrai citata ovunque.

Un Router si colloca davanti e seleziona il checkpoint per ogni richiesta rilevando script e lingua in meno di mezzo millisecondo, in puro Python, prima che avvenga qualsiasi forward pass. Non è una funzionalità di comodità. È una funzionalità di correttezza, e le prove fornite dal progetto stesso mostrano perché: il checkpoint inglese ottiene un'accuratezza di 0,000 in khmer pur riportando una confidenza di 0,952. Un modello che resta sicuro di sé mentre è completamente sbagliato è esattamente il caso in cui il gating basato sulla confidenza non può salvarti, quindi la decisione di routing deve essere presa prima che il modello veda l'input. Su una scansione di 51 lingue, il router ha reso utilizzabili 45 lingue su 51 — definite come il superamento di tre volte il caso — contro 23 su 51 per il solo checkpoint inglese.

A screenshot of the Laya model card on Hugging Face, showing the three checkpoints (convaiinnovations/laya, laya-multilingual and laya-typed-decisions) with their parameter counts and context windows, the choice, score and noul primitives, the Apache 2.0 licence, and the zero-shot and fine-tuned accuracy figures.

Il fatto di progettazione che vale la pena comprendere: un token [MASK] per opzione

Se c'è una sola cosa che devi trarre da questo articolo, è questa. In una normale testa di classificazione, l'insieme delle etichette è fisso al momento dell'addestramento: il livello finale ha un output per classe, e aggiungere una classe significa riaddestrare. Laya non fa così. Rende ogni opzione come testo con un marcatore, e lo scorer option-marker legge un punteggio dalla posizione [MASK] propria di quell'opzione. Poi applica la softmax tra le opzioni appartenenti a quella domanda.

Lo spazio delle risposte è quindi definito al momento della richiesta. Tu scrivi le opzioni, il modello le valuta. Un nuovo schema non richiede riaddestramento né fine-tuning, perché non c'è nulla nei pesi che codifichi "billing" o "technical" come una classe — solo il meccanismo per confrontare un'opzione renderizzata con un'altra nel contesto dello stato.

Due budget determinano quanto bene funziona, e sono condivisi. Ogni sequenza si suddivide in un budget per il prompt delle opzioni (head_max_len, 192 token sul checkpoint inglese e 256 sugli altri due) e in un budget per il documento (quanto rimane di max_len). Ogni domanda in una chiamata riceve risposta in quella stessa singola passata in avanti, quindi una chiamata con sei domande non equivale a sei invocazioni del modello. Ma le opzioni condividono il budget delle opzioni, ed è per questo che una domanda con 77 opzioni come Banking77 assegna all'incirca da tre a quattro token per etichetta e l'accuratezza crolla bruscamente — 0,425 rispetto allo 0,870 pubblicato da Jev. La correzione è documentata anziché nascosta: aumentare head_max_len e max_len, oppure suddividere un grande insieme di opzioni in una scelta a due passaggi, dal grossolano al fine.

Le tre primitive

Tutto ciò che Laya fa rientra in uno di tre tipi di domanda, e ciascuno restituisce una forma diversa:

scelta — una probabilità per ogni opzione denominata, più l'etichetta principale e un livello di confidenza. Questa è la primitiva di routing e classificazione dell'intento.

punteggio — una distribuzione su una rubrica ordinata più un livello atteso. Questa è la primitiva ordinale: urgenza, frustrazione, gravità.

noul — una probabilità calibrata che un'affermazione sia vera, da 0,0 a 1,0. Phishing, rischio di abbandono, prompt injection.

I tipi sono rigidi in un modo che conta a livello operativo. Una domanda a scelta non può restituire un'opzione che non hai fornito, perché le uniche opzioni che può valutare sono quelle che hai renderizzato. Questo elimina un'intera classe di errori in produzione — il valore enum inventato, il JSON troncato, il ciclo di retry attorno a un parser. Non elimina l'errore semantico. Un modello che restituisce billing: 0.94 per un ticket che sarebbe dovuto andare al supporto tecnico sbaglia, e sbaglia con sicurezza. L'output tipizzato garantisce la forma della risposta, mai la sua correttezza.

RLCD, o perché le probabilità dovrebbero significare qualcosa

La maggior parte dei classificatori è addestrata a essere nel giusto. Laya è addestrata a essere onesta su quanto sia nel giusto, e la ricetta di addestramento è all'origine di questo.

Il metodo si chiama RLCD — Reinforcement Learning for Calibrated Decisions. La policy emette una distribuzione anziché un argmax; l'esplorazione aggiunge rumore gaussiano a media zero ai logit; e la ricompensa è una regola di punteggio strettamente propria — log più sferica, con l'aggiunta di un ranked probability score per le domande ordinali. Quella parola, «propria», fa il lavoro. Una regola di punteggio strettamente propria è massimizzata in aspettativa solo riportando le proprie convinzioni reali, quindi l'hedging o il sovradichiarare fanno perdere ricompensa per costruzione anziché per istruzione. Gli aggiornamenti sono REINFORCE con una baseline di media di gruppo, in stile GRPO, e le conversazioni multi-turno usano TD(λ=1.0) su porzioni di prefisso.

La conseguenza pratica è che una soglia di confidenza è qualcosa su cui ha senso basare la logica dell'applicazione — un'affermazione che non si può fare riguardo a un softmax prodotto da un classificatore addestrato con entropia incrociata. È anche un'affermazione con un avvertimento che il progetto dichiara apertamente: i checkpoint rilasciati sono eccessivamente sicuri, e ci si aspetta che si riadatti una temperatura sui propri dati prima di fidarsi dei numeri. Riadattare una temperatura per tipo di domanda e numero di opzioni ha portato l'ECE medio da 0,466 a 0,081 sul checkpoint inglese e da 0,314 a 0,106 su quello multilingue. La soglia iniziale suggerita dal progetto per l'approvazione automatica rispetto alla revisione umana è intorno a 0,85.

Quanto costa

I dati di latenza sono quelli del progetto, misurati su una Tesla T4, con ogni checkpoint che risponde a domande identiche byte per byte nella stessa esecuzione:

• Una domanda — 39,5 ms su laya, 32,8 ms su laya-multilingual.

• Cinque domande — 84,5 ms e 40,1 ms.

• Dieci domande raggruppate — 158,6 ms (15,9 ms per domanda) e 72,3 ms (7,2 ms per domanda).

• Cinquanta domande — 771 ms e 337 ms, ovvero 6,8 ms per domanda sul checkpoint multilingue.

• Throughput in batch su una singola T4 — da 103 a 332 domande al secondo.

Se hai visto circolare un'affermazione secondo cui è "50 volte più veloce di Jev", non è il dato del progetto e il benchmark del progetto stesso non lo supporta. Il confronto pubblicato da Convai è di 7,8x sulla latenza p50 per una domanda: 32,8 ms contro 236–276 ms. È anche il confronto da leggere con attenzione, perché la scheda di Laya etichetta il lato Jev come cifre pubblicate da terzi che Convai non ha mai misurato — non ha accesso all'API TypeSafe — e perché mette a confronto un forward pass su GPU locale con una chiamata API ospitata che include round-trip di rete e accodamento. La parte architetturale di quel divario è reale. La parte infrastrutturale non è una proprietà del modello.

Per quanto riguarda la memoria, l'occupazione è di qualche centinaio di megabyte per checkpoint, e vale la pena conoscere la tabella di deployment prima di dimensionare un host. La modalità lazy predefinita mantiene due checkpoint residenti (inglese e multilingue, gli unici due tra cui il router sceglie automaticamente), quindi dopo il primo caricamento di ciascuna lingua un cambio costa solo il rilevamento. Router(max_loaded=1) su una macchina con memoria limitata ricarica a ogni cambio di lingua, con una mediana misurata di 7,4 secondi su CPU e 10,3 secondi su una T4. Router(preload=True) è la configurazione server: nulla viene ricaricato, e la latenza per richiesta è il valore di 32,8 ms su GPU o 193–464 ms su CPU.

La metà onesta

È qui che il pezzo dimostra il suo valore, perché la superficie attorno a Laya è chiassosa e i limiti sono specifici.

Innanzitutto, il numero di copertina è un numero messo a punto. L'accuratezza di 0,766 appartiene a laya-typed-decisions, il checkpoint messo a punto sullo split di training di quel benchmark stesso. I checkpoint di base ottengono 0,362 e 0,342 in zero-shot contro una baseline casuale di 0,318 e una baseline della classe maggioritaria di 0,461 — al di sotto della baseline banale, in altre parole. Il progetto lo dichiara nella propria lista di limitazioni anziché nasconderlo, e il checkpoint messo a punto supera il tetto di 0,735 dell'auto-accordo del teacher, che è un risultato davvero solido per un encoder da 421M su quattro workflow ristretti (elaborazione fatture 0,804, incidenti di sicurezza 0,766, servizio clienti 0,764, osservabilità degli agent-trace 0,730). Ma è un risultato sulla specializzazione, non sul modello di base, e chiunque citi 0,766 come capacità generale sta leggendo male la card.

Secondo, le primitive non sono ugualmente buone. In base all'accuratezza sul checkpoint fine-tuned: noul 0.857, choice 0.733, score 0.723. Il progetto definisce la score ordinale "la primitiva più debole" senza mezzi termini, con SST-5 a 0.372. Se la tua superficie decisionale è una valutazione di severità da 1 a 5, quella è la primitiva di cui hai meno motivo di fidarti fin da subito.

Terzo, due comportamenti sono documentati come bug nell'issue tracker del progetto stesso, ed entrambi ti metteranno nei guai in produzione se non li leggi. action.act_probability non porta ancora alcun segnale utilizzabile — problema #185 — perché l'output della testa decisionale non è normalizzato, a circa 300 volte la scala dell'encoder, il che satura la testa act facendole leggere 1,0 per quasi ogni input. I suoi logit grezzi remano contro la correttezza, con un AUROC di 0,30 su 396 decisioni etichettate. Usa come gate confidence invece, che raggiunge un AUROC di 0,77 sugli stessi elementi. Separatamente, noul può seguire le proprie etichette di opzione invece dello stato — problema #156 — perché render_options codifica in modo fisso le etichette di un noul a false: / true:, e quella coppia di etichette può dominare la risposta, restituendo un "no" sicuro per un input chiaramente positivo. La soluzione alternativa documentata è porre la stessa domanda come una scelta a due opzioni con chiavi neutre e la tua formulazione sì/no come descrizioni.

Quarto, un dettaglio di calibrazione facile da trascurare e che vale la pena esplicitare con precisione. Il checkpoint include una temperatura stimata di 0,1006 per il bucket choice:11+, e il loader forza ogni temperatura nell'intervallo [0.5, 5.0]. Quel limite ti sta facendo un favore. Una temperatura così netta potrebbe prendere una distribuzione genuinamente divisa e segnalarla come quasi-certezza; il limite significa che il caso peggiore è una risposta più morbida di quanto intended il fit, e il loader emette un avviso che nomina il bucket interessato e ti dice di considerare quella confidenza come non calibrata. Leggi gli avvisi al caricamento invece di sopprimerli.

Quinto, solo inglese nella root del repo, e la modalità di errore al di fuori dell'inglese non è affatto elegante — da qui il router, e da qui la raccomandazione di usare laya-multilingual per tutto ciò che non è prosa in inglese.

Il quadro indipendente, dove esiste, è più ristretto del quadro del fornitore e non lo contraddice. Un confronto diretto indipendente — sysone-bench, 751 stati in nove suite, datato 2026-09-21, eseguito su input identici byte per byte con hash delle domande verificati come identici prima del confronto — vede Jev in vantaggio su triage, guardrail, moderazione, banking77 e intento multilingue, e Laya in vantaggio su AG News (0.940 vs 0.910) e MNLI (0.983 vs 0.867). Il suo risultato di confidence-gating è quello su cui baserei davvero i piani: il gating a 0.85 di confidenza ha mantenuto il 58% del traffico di Laya a 0.878 di accuratezza, contro il 78% di quello di Jev a 0.917. Questa è la forma del compromesso — Laya automatizza meno traffico con un'accuratezza inferiore sulla porzione che mantiene, e la sua stessa esecuzione del router porta l'intento multilingue da 0.360 a 0.840.

La superficie intorno ad esso, che è insolitamente ampia

Per un progetto i cui pesi hanno solo pochi giorni, la superficie di integrazione è la parte che sorprende. Tutto questo si trova nel repository upstream su NandhaKishorM/laya, che al momento della stesura di questo testo contava 19.871 stelle su GitHub, ed è interamente sotto licenza Apache 2.0:

laya-serve — un server HTTP che espone il Router sulla stessa forma di richiesta e risposta POST /v1/systemone dell'API Jev ospitata di TypeSafe, così un client TypeSafe esistente si sposta cambiando il suo URL di base. Si noti onestamente l'impostazione predefinita di sicurezza: si associa a 0.0.0.0 senza autenticazione a meno che LAYA_API_KEY non sia impostata, nel qual caso richiede un bearer token. Esiste una variante irrobustita del modulo NixOS che gira sotto un'unità systemd DynamicUser e passa il token tramite LoadCredential invece di metterlo nello store.

• Un port completo in TypeScript, in laya-ts/ per Node e il browser, più un percorso per l'agente ONNX (laya.onnx_agent.ONNXAgent) per eseguire un modello esportato su ONNX Runtime senza PyTorch a runtime.

• Un server MCP dietro un extra opzionale, che espone laya_predict, laya_route, laya_preset e laya_status come strumenti.

• Integrazioni con LangChain e LangGraph — LayaRouter per l'instradamento condizionale basato su edge con soglia di confidenza e fallback, e LayaGuardrail.

• Un flake Nix con nix run .#laya-serve e un modulo services.laya-serve, quattro file compose, un percorso di immagine Docker con una guida rapida documentata, e un notebook Kaggle che esegue il ciclo completo di fine-tuning RLCD su GPU 2xT4 gratuite in quattro o cinque ore su circa 30.000 domande.

A screenshot of the Laya repository on GitHub, showing the repository description, the three-checkpoint table, the Route Mode quickstart, the 23-of-51 versus 45-of-51 language sweep, the Khmer 0.000 accuracy at 0.952 confidence, the self-hosting curl example with the note that the server binds 0.0.0.0 with no authentication unless LAYA_API_KEY is set, the architecture and RLCD training sections, the speed and Laya-versus-Jev benchmark tables, and the honest limits list.

Apache 2.0 è il dettaglio della licenza che decide se puoi distribuire questo all’interno di un prodotto: consente uso commerciale, modifica e ridistribuzione, e non richiede che tu pubblichi le tue modifiche o i tuoi pesi messi a punto. L’obbligo è quello consueto di attribuzione e conservazione degli avvisi, oltre all’esplicita assenza di una concessione di brevetti o marchi al di là di quanto stabilito dalla licenza. Per un livello decisionale che si trova davanti al traffico dei clienti, questa è una proposta sostanzialmente diversa da un endpoint ospitato ad accesso anticipato i cui pesi, architettura e ricetta di addestramento sono tutti non divulgati — che è ciò che Jev è oggi, a 0,042 $ per milione di token di input con output gratuito e una superficie di input solo testuale.

Dove questo si inserisce davvero: una testa decisionale davanti, un LLM instradato dietro

Il pattern che vale la pena interiorizzare non è "modello decisionale invece di LLM". È una pipeline a due stadi, ed entrambi gli stadi esistono perché l'altro è carente in qualcosa.

Metti Laya in prima linea per il giudizio ad alto volume, ristretto e consumabile dalle macchine: instrada il ticket, classifica l'intento, valuta l'urgenza, decidi se questo documento è pertinente alla query, verifica se questa bozza viola una policy. Queste chiamate hanno un insieme fisso di risposte, avvengono migliaia di volte all'ora, e un forward pass locale da 33 millisecondi con zero token di output è più adatto a loro di un round trip generativo. Poi metti un modello generativo dietro di esso per le chiamate che richiedono davvero prosa, sintesi o ragionamento su un contesto lungo: la stesura, la spiegazione, il riepilogo di escalation.

È qui che si colloca OrcaRouter, e vale la pena essere precisi sul confine. Non serviamo Laya; è un encoder da 421M che esegui tu stesso, e il suo scopo principale è che gira dove i tuoi dati già si trovano. Né serviamo Jev — è l'endpoint in accesso anticipato di TypeSafe. Ciò che copriamo è la metà generativa di quella stessa pipeline: oltre 200 modelli dietro un'unica chiave compatibile con OpenAI, al prezzo di listino del provider passato con 0% di markup, con failover automatico tra provider. La ragione pratica che conta qui è la giuntura tra le due metà. Nel momento in cui inizi a instradare decisioni verso un modello generativo per i casi che il decision head ha scartato, hai una seconda integrazione, una seconda fattura e un secondo modo di fallire. Una sola chiave per il lato generazione, con failover se un provider peggiora, significa che il percorso di escalation del livello decisionale è un cambio di configurazione anziché una seconda relazione con un fornitore. È un'affermazione modesta, ed è quella vera.

Chi dovrebbe adottarlo e chi dovrebbe aspettare

Adotta Laya ora se disponi di dati etichettati e di un ciclo di addestramento, e di una superficie decisionale sufficientemente stabile da valere la pena specializzare. Il notebook Kaggle esiste proprio affinché la fase di fine-tuning non sia un progetto di ricerca, i checkpoint di base si caricano in circa due secondi su CPU, e la licenza ti consente di distribuire il risultato commercialmente senza pubblicare i tuoi pesi. I carichi di lavoro più adatti sono quelli già valutati dal progetto: smistamento dei ticket, elaborazione delle fatture, classificazione degli incidenti di sicurezza, guardrail e moderazione, e osservabilità delle tracce degli agenti. Mantieni le domande a scelta sotto circa 20 opzioni, calibra una temperatura sui tuoi dati di validazione prima di mettere una soglia in produzione, e fai il gate su confidenza, mai su act_probability.

Aspetta se la tua decisione deve essere pronta all'uso senza dati etichettati. Un checkpoint di base che si colloca al di sotto della baseline della classe maggioritaria sul benchmark rispetto al quale è stato pubblicato non è un motore zero-shot, e la lettura onesta dei numeri del fornitore rispetto a quelli indipendenti è che un'API decisionale ospitata e ben gestita è attualmente la scelta zero-shot più forte. Aspetta anche se i tuoi insiemi di opzioni sono ampi e non sei disposto a mettere a punto il budget della testa, se il tuo punteggio ordinale deve essere affidabile immediatamente, o se hai bisogno di input di immagini, audio o documenti lunghi — Laya è solo testo e il suo budget di contesto è da 512 a 1.024 token per impostazione predefinita, il che è una selezione di evidenze piuttosto che un intero documento.

Ciò che deciderà questa categoria non sono i numeri di latenza, che sono già abbastanza buoni da smettere di essere l'argomento. È se un piccolo modello che riporta probabilità oneste su una superficie decisionale che hai definito, e che puoi riaddestrare sulle tue etichette, batte la chiamata a un grande modello generativo e l'analisi del suo output. Laya è un primo serio tentativo credibile della versione a pesi aperti di quella domanda — e ha al massimo pochi giorni di vita, che è il modo giusto di leggere tutto quanto sopra. La base è il punto di partenza, non il prodotto.

A generated single-column scoreboard titled "Laya - the scoreboard" with six labelled rows reading Architecture: non-autoregressive encoder plus decision head; Parameters: 421M total; Output tokens: zero, one forward pass; Zero-shot accuracy: 0.362 versus 0.461 majority class; Fine-tuned accuracy: 0.766 on typed-decisions; Licence: Apache 2.0, weights published; with a footer reading "All figures vendor-reported by Convai Innovations on its own harnesses."