Laya su Apple Silicon: cosa ti offre il port MLX e cosa no

Laya è un modello decisionale che non scrive mai una frase. Convai Innovations ha pubblicato i suoi pesi su Hugging Face il 2026-09-18, e il giorno dopo uno sviluppatore di nome mizorewww ha pubblicato Laya-MLX — un port indipendente che esegue tutti e tre i checkpoint di Laya nativamente su Apple Silicon tramite MLX, senza PyTorch, senza runtime Transformers e senza chiamate al cloud. Quel port riporta 13,42 ms di mediana per una breve domanda in inglese sul checkpoint da 421M, 7,39 ms su quello multilingue da 322M, e zero token di output, su un M3 Max. Nel frattempo Kev, l'altra famiglia aperta che insegue la stessa idea di decisione tipizzata, è costruita su Qwen3.5-4B-Base e ha richiesto un intero secondo backend prima di poter essere usata su un Mac, perché PyTorch non ha kernel per i suoi layer DeltaNet sulla GPU di Apple. Due progetti, la stessa settimana, lo stesso obiettivo, e solo uno dei due è stato portato in modo pulito. Questa differenza è la storia, ed è una storia di runtime, non una storia di modello.

Il motivo per cui questo merita un articolo oggi non è che Laya sia una novità. È che fino al 2026-09-19 non c'era modo di eseguire un modello decisionale tipizzato su un Mac senza trascinarsi dietro uno stack PyTorch, e la domanda che un lettore ha davvero — posso eseguirlo sul mio laptop, e a cosa rinuncio — ha finalmente una risposta misurabile. Quindi questo pezzo riguarda il percorso di serving, i numeri che ci stanno dietro e i punti in cui i numeri smettono di significare ciò che sembrano.

Innanzitutto, cosa non è Laya

Laya non è un LLM. È non autoregressiva: un unico passaggio in avanti bidirezionale sullo stato più le tue domande, e in uscita si ottengono risposte tipizzate. Non c'è decodifica token per token, né catena di pensiero, né JSON generato da analizzare, né token di output da fatturare. Le tre primitive di risposta sono choice (scegli una tra N opzioni denominate), score (un livello ordinale di rubrica) e noul (una probabilità calibrata che qualcosa sia vero).

Questo è importante per come interpreti ogni numero in questo articolo. Quando il port riporta 13,42 ms, non sta riportando 13,42 ms per produrre qualche centinaio di token come farebbe un benchmark di generazione. Sta riportando l'intera operazione. Confrontare la latenza di un modello decisionale con i token al secondo di un LLM significa confrontare due lavori diversi, e qualsiasi articolo che lo faccia — incluso il post virale "50 volte più veloce di Jev" che è circolato dopo il lancio — avanza un'affermazione che il lavoro sottostante non supporta.

Cosa ha effettivamente misurato la porta

Queste cifre sono dell'autore del port stesso, ottenute su una macchina dichiarata, e vanno lette con la macchina e il metodo allegati. Laya-MLX le ha misurate su un M3 Max con 40 core GPU e 128 GiB di memoria unificata, in FP16, escludendo il caricamento del modello.

• Una breve domanda, P50 — 13,42 ms sul checkpoint inglese da 421M, 7,39 ms sul checkpoint multilingue da 322M.

• Una breve domanda, P95 — rispettivamente 13,92 ms e 7,79 ms.

• Throughput su 50 domande — 146,8 domande al secondo e 395,0 domande al secondo.

Allocazione MLX di picco — 943.6 MiB e 687.6 MiB.

Il confine temporale è la parte che vale la pena leggere due volte. Include la preparazione del prompt, la tokenizzazione, la costruzione dei tensori, l'inferenza sincronizzata, la calibrazione e la formattazione dei risultati. Esclude il caricamento del modello. La prova di throughput su 50 domande ha utilizzato batch_size=64, mentre l'API usa per impostazione predefinita 16, quindi quella coppia di numeri descrive un carico di lavoro deliberatamente raggruppato in batch e non ciò che costa una singola chiamata interattiva. Lunghezze di input diverse, numeri di domande diversi e condizioni di runtime diverse spostano tutti il risultato. Queste avvertenze sono la differenza tra un numero e un benchmark, e la porta le dichiara essa stessa.

Il limite minimo di memoria è il dato su cui la maggior parte dei lettori baserà le proprie decisioni, ed è il meno ambiguo dell'insieme: meno di un gigabyte di allocazione MLX di picco per una singola domanda breve, su entrambi i checkpoint. Non è un'affermazione sull'occupazione totale del tuo Mac — il sistema operativo, il terminale e il processo Python vi si affiancano — ma è un limite minimo reale, ed è circa tre ordini di grandezza inferiore a ciò che richiede l'esecuzione locale di un modello generativo di medie dimensioni.

Il controllo di fedeltà è il risultato più interessante

Un port veloce che risponde in modo diverso dal modello che porta è inutile, ed è qui che il progetto ha fatto il lavoro che conta. Tutti e tre i checkpoint hanno corrisposto alla risposta selezionata upstream su 63 domande di validazione su 63 sia in FP32 sia in FP16 — 378 confronti su 378. Ogni configurazione ha inoltre eseguito 100 chiamate ripetute e deterministiche senza alcuna crescita misurata della memoria attiva, e tutti i 36 file di pesi pubblicati hanno superato una rigorosa verifica remota dei checksum.

Leggi l'ambito con onestà: quello misura la fedeltà su quelle fixture, non l'accuratezza su ogni possibile domanda. Ti dice che il port è fedele a Laya. Non ti dice nulla sul fatto che Laya sia corretto.

Indipendente, mantenuto dalla comunità, e ancora non nell'elenco

Il port dice questo di sé, due volte: è un port MLX indipendente, non una release ufficiale di Convai Innovations. L'addestramento e il fine-tuning RLCD restano upstream. I pesi sono attribuiti a Convai Innovations. Apache-2.0 su entrambi i lati.

Il modo in cui upstream lo tratta è più rivelatore di qualsiasi disclaimer. Il README di Laya contiene un elenco Community Tools e, al 2026-09-23, include quattro voci: omp-laya-judge, laya-adk-toolkit, laya-Ascend per NPU Huawei Ascend, e laya-apple — un runtime per Apple Silicon che usa la GPU MLX e il Neural Engine. Quella quarta voce è arrivata tramite la pull request #260, unita il 2026-09-23. Il port di cui parla questo articolo non è tra i quattro. L'elenco di upstream ora indirizza i lettori di Apple Silicon verso un progetto della community diverso da quello che è stato rilasciato per primo e che ha i benchmark.

Il tracker delle issue di Upstream stesso dice il resto. La issue #50, «Apple silicon ports», aperta il 2026-09-21, è ancora aperta; il manutentore ha risposto lo stesso giorno che il supporto per Apple Silicon è monitorato e che port della community come Laya-MLX stanno esplorando l'inferenza Metal nativa, poi ha risposto di nuovo il 2026-09-23 con una frase che vale la pena citare esattamente: «The MLX port remains community-maintained». La correzione lato PyTorch — autocast MPS e una correzione RoPE di transformers 4.x — è arrivata come pull request #273, mergiata il 2026-09-23, con un revisore in quel thread che ha segnalato che deve ancora essere combinata con il refactoring separato dell'autocast nella #109, che resta aperta. E la issue #52, aperta il 2026-09-21, segnala un sidecar Laya-MLX che è cresciuto fino a circa 21,7 GB di memoria Metal nell'arco di diverse ore di funzionamento, con vmmap che attribuisce circa 21,4 GB al sottosistema grafico anziché all'heap Python; propone di limitare la cache dell'allocatore e di svuotarla dopo ogni inferenza, ed è ancora aperta.

Mettendo insieme questi elementi, la risposta pratica è: questo runtime non è approvato da upstream, è mantenuto dalla comunità, stando alla descrizione fornita dal manutentore stesso, e l'unica questione di memoria che conta per un sidecar di lunga durata viene affrontata pubblicamente anziché risolta in una release.

Posso eseguirlo sul mio portatile, e a cosa devo rinunciare?

L'installazione è un singolo comando pip, e il port pubblica pesi FP16 pre-convertiti, così non devi convertire nulla da solo:

pip install laya-mlx

Poi import laya_mlx as laya, agent = laya.load("aac6fef/laya-mlx"), e chiama agent.predict(state, questions). I requisiti sono Apple Silicon, Python 3.11+ e macOS 14+. L'ambiente misurato era macOS 27.2, Python 3.12.13 e MLX 0.32.2 — e il porting nota che la versione di MLX utilizzata includeva wheel per macOS 14, 15 e 26, mentre l'installer ha selezionato quella per il 26, e che le versioni precedenti di macOS supportate non sono state testate su quella macchina.

Ciò a cui rinunci, dimensione per dimensione:

• FP16 rispetto a FP32 — FP16 è l'impostazione predefinita e la fonte di ogni numero principale sopra riportato. FP32 offre una concordanza numerica più stretta con l'upstream, e le probabilità possono differire leggermente tra le precisioni anche quando l'etichetta selezionata concorda. BF16 può essere richiesto ma non fa parte della matrice di validazione pubblicata, quindi consideralo non testato.

• Soglia minima di memoria rispetto al margine di riserva — meno di 1 GiB di allocazione MLX di picco per una domanda breve è confortevole su qualsiasi Mac della serie M. Non è un'affermazione sul carico server sostenuto, e il problema #52 è il motivo per cui bisogna essere cauti se prevedi di eseguirlo come sidecar di lunga durata anziché come chiamata di libreria.

• Multilingue rispetto all'inglese — il checkpoint multilingue da 322M è il più veloce dei due e quello che copre oltre 100 lingue, ma il port riporta deliberatamente l'avvertimento upstream: i checkpoint in inglese non sostituiscono quello multilingue. Il routing tra di essi è il modello previsto, non un vezzo.

• Approvato ufficialmente da upstream rispetto a mantenuto dalla community — è il secondo. Nulla nelle note di rilascio upstream garantisce che questo port continui a funzionare nonostante le modifiche upstream.

• Velocità contro calibrazione — un porting veloce non risolve un bucket di calibrazione che viene distribuito con eccessiva sicurezza. A monte, le temperature adattate vengono limitate a [0.5, 5.0], e il bucket distribuito choice:11+ è 0.1006, il che renderebbe i logit circa dieci volte più netti e presenterebbe un lancio di moneta come quasi-certezza. Le temperature di calibrazione adattate esistono per un motivo; adattale sui tuoi dati di hold-out prima di decidere in base a una probabilità.

Vale la pena tenere presenti altri due limiti, entrambi dal tracker di upstream stesso. action.act_probability attualmente non porta alcun segnale utilizzabile — restituisce 1.0 per quasi ogni input, e i suoi logit grezzi si sono rivelati contrari alla correttezza con un AUROC di 0,30 su 396 decisioni etichettate (issue #185). Fai il gate su confidence invece, che raggiunge 0,77 sugli stessi elementi. E le domande noul possono seguire le etichette delle loro opzioni anziché lo stato (issue #156) — la card di upstream stessa riporta un "no" sicuro su input chiaramente positivi, in modo più marcato sul checkpoint inglese. Il workaround che suggerisce non è ricorrere a un modello diverso, ma riformulare la domanda: porla come una choice a due opzioni con chiavi neutre (A/B) e la tua formulazione sì/no come descrizioni delle opzioni.

Perché un modello decisionale si trasferisce senza problemi e l'altro no

Il contrasto qui è architetturale, ed è la cosa più utile in questo articolo per chiunque debba scegliere tra le due famiglie.

Il backbone di Laya è ModernBERT-large, un encoder bidirezionale costruito interamente sull'attenzione. L'attenzione è ciò in cui lo stack GPU di Apple eccelle, ed è ciò su cui MLX ha concentrato i suoi sforzi. Quindi il port è una reimplementazione di layer che avevano già percorsi veloci: l'encoder, i layer Transformer della testa decisionale, la testa di scoring e la testa delle azioni girano tutti in MLX, e la tokenizzazione passa ancora attraverso il tokenizer Rust di Hugging Face.

I backbone di Kev sono basi Qwen3.5, e Qwen3.5 mescola layer di attenzione con layer Gated DeltaNet. DeltaNet è ricorrente e ignora le maschere di attenzione. Ciò ha due conseguenze. Primo, ogni domanda deve essere eseguita come riga a sé stante invece di condividere un'unica sequenza mascherata, cosa che il progetto Kev gestisce calcolando lo stato una volta e riutilizzando la sua cache per riga. Secondo — e questa è la parte che dà problemi su un Mac — non c'erano kernel PyTorch per quei layer sulla GPU di Apple, quindi PyTorch ha ripiegato sul codice di riferimento. La scheda del modello jaredpalmer/kev-4b riporta ancora il limite risultante in parole semplici: una richiesta di cinque domande che impiega 0,17 s sulla build Qwen3 di Kev-4B ne impiega 0,78 s in bf16 su un M5.

Controlla la formulazione attuale prima di citarlo, perché è cambiata. Il README del repository Kev ora dice invece che il server esegue i modelli Qwen3.5 tramite MLX su Apple Silicon e pubblica i propri dati M5 per una richiesta di cinque domande con tre opzioni ciascuna su uno stato di circa 270 token: Kev-4B a 721 ms su uno stato nuovo e 136 ms su uno stato ripetuto attraverso la cache dei prefissi, contro 3.302 ms e 847 ms sul percorso MPS bf16 di PyTorch. Kev-0.8B si attesta a 149 ms e 28 ms. I modelli Qwen3 della generazione precedente funzionano ancora su PyTorch MPS semplice e il progetto li considera un'ottima scelta su Mac.

Fai attenzione a non trasformarlo in un risultato di gara. Queste non sono misurazioni testa a testa. I 13,42 ms di Laya-MLX sono una sola domanda breve su un M3 Max; i 721 ms di Kev sono cinque domande con tre opzioni ciascuna, su uno stato di ~270 token su un M5. Diversi numeri di domande, diversi numeri di opzioni, diverse lunghezze dello stato, diverse macchine, diversi runtime. Ciò che è verificabile e vale la pena confrontare è la forma del problema, non un vincitore: un encoder a pura attenzione si trasferisce su Apple Silicon senza difficoltà, mentre un modello ibrido ad attenzione lineare ha avuto bisogno di un secondo backend completo prima di essere utilizzabile lì.

A cosa serve davvero un modello decisionale

Se si eliminano i benchmark, il caso d'uso onesto è ristretto, e il progetto stesso lo ammette: Laya è una base veloce da specializzare, non un motore decisionale zero-shot. Sul benchmark typed-decisions di Convai, i due checkpoint di base ottengono 0,362 e 0,342 zero-shot contro una baseline majority-class di 0,461 e una random di 0,318. Sono al di sotto della soglia che si otterrebbe rispondendo sempre con l'etichetta più comune. Il valore principale di 0,766 appartiene a laya-typed-decisions, il checkpoint fine-tuned sullo split di addestramento dello stesso benchmark, e non dovrebbe mai essere citato come capacità generale.

Il confronto pubblicato da Convai con TypeSafe Jev 1.13.0 vale la pena di leggerlo proprio per questo motivo, ed è etichettato con cura dalla loro parte: ogni valore di Laya è ciò che il router restituisce effettivamente, mentre i valori di Jev sono numeri pubblicati da terzi che Convai non ha mai misurato perché non ha accesso all'API TypeSafe. In quel confronto, il Laya instradato ottiene 0,766 contro 0,727 di Jev sulle decisioni tipizzate, con ECE post-temperatura di 0,081 contro 0,246, e una latenza p50 di 32,8 ms contro 236–276 ms su una Tesla T4 — una differenza di 7,8x su una domanda. È questo il numero da citare. Il dato "50x più veloce di Jev" che si è diffuso sui social media non compare nella documentazione del progetto né nei suoi benchmark, e il confronto pubblicato dal progetto stesso non lo supporta. Jev è anche in vantaggio dove lo è: su Banking77, Jev ottiene 0,870 contro 0,425 di Laya, perché le opzioni di Laya condividono un budget di token fisso e 77 etichette ne lasciano circa tre o quattro token ciascuna.

Quindi la forma di un deployment reale è una testa decisionale che è economica, locale e ristretta — instradare un ticket, valutare l'urgenza, rispondere a un cancello sì/no — con qualcosa di generativo dietro per la parte che deve scrivere. Il modello decisionale effettua la chiamata tipizzata in millisecondi ed escala. La metà generativa è un modello diverso su un runtime diverso, ed è qui che un router si guadagna il suo posto: Oltre 200 modelli dietro una singola chiave al prezzo di listino del provider senza ricarico, così un cambio di prezzo del fornitore è attivo lo stesso giorno, e failover automatico quando un provider si degrada a metà esecuzione. OrcaRouter non serve Laya, e non serve Kev o Jev — la famiglia Qwen3.5 è sulla nostra lista di modelli, e i modelli decisionali stessi non lo sono. Ciò che copriamo è la metà generativa di quello stack, che è la metà che chiami a ogni richiesta che la testa decisionale escala.

C'è un'ulteriore ragione per mantenere separate le due metà invece di ricorrere a un unico modello che faccia entrambe le cose. Una testa decisionale locale che non costa alcun token di output e non tocca mai una rete è un tipo diverso di dipendenza rispetto a una chiamata API: continua a funzionare quando la rete non funziona, e il suo costo non scala con la quantità di testo che legge. È questa la proprietà per cui vale la pena pagare. Tutto il resto in questo articolo riguarda quanto si paga per essa in termini di fedeltà, memoria e manutenzione.

Chi dovrebbe eseguirlo, e chi dovrebbe aspettare

Esegui Laya-MLX se usi un Mac della serie M, le tue decisioni sono vincolate — una scelta tra opzioni denominate, un punteggio di rubrica, un gate sì/no — e hai etichette su cui fare fine-tuning oppure sei pronto ad adattare da solo le temperature di calibrazione. L'installazione richiede un solo comando, il requisito minimo di memoria è inferiore a un gigabyte, e il lavoro sulla fedeltà è stato svolto e pubblicato.

Aspetta, se hai bisogno di garanzie di supporto upstream, se stai eseguendo un sidecar di lunga durata e vuoi che la questione della crescita di memoria venga risolta in una release anziché in una issue aperta, o se le tue domande sono aperte. Un encoder non autoregressivo che risponde a "cosa dovrei fare dopo" non è una versione più piccola di un LLM che fa la stessa cosa. È uno strumento diverso, e si legge bene solo quando la domanda è già modellata per esso.