Laya op Apple Silicon: wat de MLX-port je oplevert, en wat niet

Laya is een beslissingsmodel dat nooit een zin schrijft. Convai Innovations zette zijn gewichten op Hugging Face op 2026-09-18, en de volgende dag publiceerde een ontwikkelaar genaamd mizorewww Laya-MLX — een onafhankelijke port die alle drie Laya-checkpoints native op Apple Silicon draait via MLX, zonder PyTorch, zonder Transformers-runtime en zonder cloudaanroep. Die port rapporteert een mediaan van 13,42 ms voor één korte Engelse vraag op het 421M-checkpoint, 7,39 ms op het 322M meertalige checkpoint, en nul uitvoertokens, op een M3 Max. Ondertussen Kev, de andere open familie die hetzelfde getypeerde beslissingsidee nastreeft, is gebouwd op Qwen3.5-4B-Base en had een volledige tweede backend nodig voordat het bruikbaar was op een Mac, omdat PyTorch geen kernels heeft voor zijn DeltaNet-lagen op de GPU van Apple. Twee projecten, dezelfde week, hetzelfde doel, en slechts één ervan werd vlekkeloos geport. Dat verschil is het verhaal, en het is een runtimeverhaal, geen modelverhaal.

De reden dat dit vandaag een artikel waard is, is niet dat Laya nieuw is. Het is dat er tot 2026-09-19 geen manier was om een getypeerd beslissingsmodel op een Mac te draaien zonder daar een PyTorch-stack bij te slepen, en de vraag die een lezer echt heeft — kan ik dit op mijn laptop draaien, en wat lever ik ervoor in — heeft eindelijk een meetbaar antwoord. Dit stuk gaat dus over het serveerpad, de cijfers erachter, en de plekken waar de cijfers ophouden te betekenen wat ze lijken.

Eerst, wat Laya niet is

Laya is geen LLM. Het is niet-autoregressief: één bidirectionele forward pass over de staat plus je vragen, en er komen getypeerde antwoorden uit. Er is geen token-voor-token-decodering, geen chain of thought, geen gegenereerde JSON om te parsen, en geen outputtokens om te factureren. De drie antwoordprimitieven zijn choice (kies een van N benoemde opties), score (een ordinaal rubriekniveau) en noul (een gekalibreerde waarschijnlijkheid dat iets waar is).

Dat is van belang voor hoe u elk getal in dit artikel leest. Wanneer de port 13,42 ms rapporteert, betekent dat niet dat hij 13,42 ms nodig heeft om een paar honderd tokens te produceren, zoals een generatiebenchmark zou doen. Hij rapporteert de hele bewerking. De latentie van een beslissingsmodel vergelijken met de tokens-per-seconde van een LLM is twee verschillende taken met elkaar vergelijken, en elk artikel dat dat doet — inclusief het virale bericht "50x sneller dan Jev" dat na de lancering circuleerde — doet een bewering die het onderliggende werk niet ondersteunt.

Wat de poort daadwerkelijk heeft gemeten

Deze cijfers zijn de eigen cijfers van de auteur van de port, verkregen op een genoemde machine, en ze moeten worden gelezen in samenhang met de bijbehorende machine en methode. Laya-MLX heeft ze gemeten op een M3 Max met 40 GPU-cores en 128 GiB aan unified memory, bij FP16, waarbij het laden van het model niet is meegerekend.

• Eén korte vraag, P50 — 13,42 ms op het Engelse checkpoint van 421M, 7,39 ms op het meertalige checkpoint van 322M.

• Eén korte vraag, P95 — respectievelijk 13,92 ms en 7,79 ms.

• Doorvoer voor 50 vragen — 146,8 vragen per seconde en 395,0 vragen per seconde.

• Piek MLX-toewijzing — 943,6 MiB en 687,6 MiB.

De timinggrens is het deel dat het waard is om twee keer te lezen. Deze omvat promptvoorbereiding, tokenisatie, tensorconstructie, gesynchroniseerde inferentie, kalibratie en resultaatopmaak. Deze sluit het laden van modellen uit. De doorvoertest met 50 vragen gebruikte batch_size=64, terwijl de API standaard op 16 staat, dus dat paar getallen beschrijft een bewust gebatchte werklast in plaats van wat een enkele interactieve aanroep kost. Verschillende invoerlengtes, verschillende aantallen vragen en verschillende runtime-omstandigheden beïnvloeden allemaal het resultaat. Die kanttekeningen zijn het verschil tussen een getal en een benchmark, en de port vermeldt ze zelf.

De geheugenondergrens is het cijfer waarop de meeste lezers zullen afgaan, en het is het minst dubbelzinnige in de set: minder dan een gigabyte aan piek-MLX-allocatie voor één enkele korte vraag, op beide checkpoints. Dat is geen claim over de totale voetafdruk van je Mac — het besturingssysteem, je terminal en het Python-proces zitten er allemaal naast — maar het is een echte ondergrens, en die ligt ongeveer drie ordes van grootte onder wat het lokaal draaien van een middelgroot generatief model vereist.

De getrouwheidscontrole is het interessantere resultaat.

Een snelle port die anders antwoordt dan het model dat hij port, is waardeloos, en dit is waar het project het werk deed dat ertoe doet. Alle drie checkpoints kwamen overeen met het door upstream geselecteerde antwoord op 63 van de 63 validatievragen, zowel in FP32 als in FP16 — 378 van de 378 vergelijkingen. Elke configuratie voerde ook 100 herhaalde, deterministische aanroepen uit zonder gemeten groei van het actieve geheugen, en alle 36 gepubliceerde gewichtsbestanden slaagden voor strikte externe checksumverificatie.

Lees de reikwijdte eerlijk: dat meet de getrouwheid op die fixtures, niet de nauwkeurigheid op elke mogelijke vraag. Het vertelt je dat de port trouw is aan Laya. Het vertelt je niets over de vraag of Laya gelijk heeft.

Onafhankelijk, door de community onderhouden, en nog steeds niet op de lijst

De port zegt dit over zichzelf, tweemaal: het is een onafhankelijke MLX-port, geen officiële release van Convai Innovations. RLCD-training en fine-tuning blijven upstream. De weights worden toegeschreven aan Convai Innovations. Apache-2.0 aan beide zijden.

Hoe upstream ermee omgaat, is onthullender dan welke disclaimer dan ook. De Laya README bevat een Community Tools-lijst, en op 2026-09-23 bevat die vier vermeldingen: omp-laya-judge, laya-adk-toolkit, laya-Ascend voor Huawei Ascend NPU's, en laya-apple — een Apple Silicon-runtime die de MLX GPU en de Neural Engine gebruikt. Die vierde vermelding kwam binnen via pull request #260, die op 2026-09-23 werd samengevoegd. De port waar dit artikel over gaat, staat niet tussen de vier. De lijst van upstream verwijst Apple Silicon-lezers nu naar een ander communityproject dan het project dat als eerste werd uitgebracht en de benchmarks heeft.

De eigen issue tracker van upstream zegt de rest. Issue #50, "Apple silicon ports", geopend op 2026-09-21, staat nog steeds open; de maintainer antwoordde dezelfde dag dat Apple Silicon-ondersteuning wordt gevolgd en dat community-ports zoals Laya-MLX native Metal-inferentie verkennen, en antwoordde vervolgens opnieuw op 2026-09-23 met een regel die het verdient exact geciteerd te worden: "The MLX port remains community-maintained." De fix aan de PyTorch-kant — MPS-autocast en een correctie voor transformers 4.x RoPE — kwam binnen als pull request #273, samengevoegd op 2026-09-23, waarbij een reviewer in die thread opmerkte dat deze nog steeds gecombineerd moet worden met de afzonderlijke autocast-refactor in #109, die nog open staat. En issue #52, geopend op 2026-09-21, meldt een Laya-MLX-sidecar die gedurende enkele uren werking groeide naar ongeveer 21,7 GB Metal-geheugen, waarbij vmmap ongeveer 21,4 GB toeschrijft aan het grafische subsysteem in plaats van aan de Python-heap; het stelt voor om de allocator-cache te begrenzen en deze na elke inferentie te wissen, en het staat nog steeds open.

Als je dat samenvoegt, is het praktische antwoord: deze runtime is niet door upstream gezegend, hij wordt volgens de eigen beschrijving van de maintainer door de community onderhouden, en de ene geheugenvraag die ertoe doet voor een langdurig draaiende sidecar wordt in het openbaar aangepakt in plaats van opgelost in een release.

Kan ik het op mijn laptop draaien, en wat moet ik daarvoor opgeven?

Installeren is één pip-opdracht, en de port publiceert vooraf geconverteerde FP16-gewichten, zodat je zelf niets hoeft te converteren:

pip install laya-mlx

Dan import laya_mlx as laya, agent = laya.load("aac6fef/laya-mlx"), en roep agent.predict(state, questions) aan. Vereisten zijn Apple Silicon, Python 3.11+ en macOS 14+. De gemeten omgeving was macOS 27.2, Python 3.12.13 en MLX 0.32.2 — en de portnotities vermelden dat de MLX-release die werd gebruikt macOS 14-, 15- en 26-wheels meeleverde, terwijl de installer de 26-versie selecteerde, en dat oudere ondersteunde macOS-versies niet op die machine zijn getest.

Wat je opgeeft, dimensie voor dimensie:

• FP16 versus FP32 — FP16 is de standaard en de bron van elk kerncijfer hierboven. FP32 geeft nauwere numerieke overeenstemming met upstream, en kansen kunnen licht verschillen tussen precisies, zelfs wanneer het geselecteerde label overeenkomt. BF16 kan worden aangevraagd, maar maakt geen deel uit van de gepubliceerde validatiematrix, dus behandel het als ongetest.

• Geheugenondergrens versus marge — minder dan 1 GiB piek-MLX-toewijzing voor een korte vraag is comfortabel op elke Mac uit de M-serie. Het is geen uitspraak over aanhoudende serverbelasting, en issue #52 is de reden om voorzichtig te zijn als je dit als langdurig draaiende sidecar wilt gebruiken in plaats van als bibliotheekaanroep.

• Meertalig versus Engels — het 322M meertalige checkpoint is het snelste van de twee en het exemplaar dat 100+ talen dekt, maar de port neemt bewust de waarschuwing van upstream over: de Engelse checkpoints zijn geen vervanging voor het meertalige checkpoint. Routeren tussen beide is het beoogde patroon, niet een vrijblijvende extra.

• Door upstream gezegend versus door de community onderhouden — het is het tweede. Niets in de upstream-releaseopmerkingen belooft dat deze port blijft werken bij upstream-wijzigingen.

• Snelheid versus kalibratie — een snelle port verhelpt een kalibratiebucket die te zelfverzekerd wordt uitgeleverd niet. Upstream begrenst gefitte temperaturen tot [0.5, 5.0], en de uitgeleverde choice:11+bucket is 0.1006, wat de logits ruwweg tienvoudig zou verscherpen en een muntworp als bijna-zekerheid zou rapporteren. Gefitte kalibratietemperaturen bestaan niet voor niets; fit ze op je eigen hold-outdata voordat je op een waarschijnlijkheid vertakt.

Nog twee beperkingen zijn de moeite waard om mee te nemen, beide uit de eigen tracker van upstream. action.act_probability bevat momenteel geen bruikbaar signaal — het geeft 1,0 voor bijna elke invoer, en de ruwe logits ervan scoorden tegen correctheid met een AUROC van 0,30 over 396 gelabelde beslissingen (issue #185). Gebruik confidence in plaats daarvan, die 0,77 haalt op dezelfde items. En noul-vragen kunnen hun optielabels volgen in plaats van de toestand (issue #156) — de eigen modelkaart van upstream meldt een zelfverzekerde "nee" bij duidelijk positieve invoer, het sterkst op het Engelse checkpoint. De workaround die het voorstelt is niet om naar een ander model te grijpen, maar om de vraag te hervormen: stel hem als een choice met twee opties en neutrale sleutels (A/B) en je ja/nee-bewoording als de optiebeschrijvingen.

Waarom het ene beslissingsmodel probleemloos overzet en het andere niet

Het contrast hier is architectonisch, en het is het nuttigste in dit artikel voor iedereen die tussen de twee families moet kiezen.

Laya's backbone is ModernBERT-large, een bidirectionele encoder die volledig uit attention is opgebouwd. Attention is waar de GPU-stack van Apple het beste in is, en het is waar MLX zijn inspanningen op heeft gericht. Dus de port is een herimplementatie van lagen die al fast paths hadden: de encoder, de Transformer-lagen van de decision head, de scoring head en de action head draaien allemaal in MLX, en tokenisatie gaat nog steeds via de Rust-tokenizer van Hugging Face.

Kevs backbones zijn Qwen3.5-bases, en Qwen3.5 mengt attentionlagen met Gated DeltaNet-lagen. DeltaNet is recurrent en negeert attentionmasks. Dat heeft twee gevolgen. Ten eerste moet elke vraag als een eigen rij worden uitgevoerd in plaats van één gemaskeerde sequentie te delen, wat het Kev-project oplost door de state één keer te berekenen en de cache per rij te hergebruiken. Ten tweede — en dit is het deel dat op een Mac pijn doet — waren er geen PyTorch-kernels voor die lagen op Apples GPU, dus viel PyTorch terug op referentiecode. jaredpalmer/kev-4bDe modelkaart vermeldt de resulterende beperking nog steeds in duidelijke taal: een verzoek met vijf vragen dat 0,17 s kost op de Qwen3-build van Kev-4B, kost 0,78 s in bf16 op een M5.

Controleer de huidige formulering voordat je dat citeert, want die is gewijzigd. De README van de Kev-repository zegt nu dat de server de Qwen3.5-modellen in plaats daarvan via MLX op Apple Silicon draait, en publiceert zijn eigen M5-cijfers voor een aanvraag met vijf vragen met elk drie opties op een staat van ongeveer 270 tokens: Kev-4B op 721 ms bij een nieuwe staat en 136 ms bij een herhaalde staat via de prefixcache, tegenover 3.302 ms en 847 ms op het PyTorch bf16 MPS-pad. Kev-0.8B komt uit op 149 ms en 28 ms. De Qwen3-modellen van de vorige generatie draaien nog steeds op gewone PyTorch MPS en het project noemt ze een prima keuze op een Mac.

Pas op dat je daar geen wedstrijduitslag van maakt. Dit zijn geen directe onderlinge metingen. De 13,42 ms van Laya-MLX is één korte vraag op een M3 Max; de 721 ms van Kev zijn vijf vragen met elk drie opties op een toestand van ~270 tokens op een M5. Verschillende aantallen vragen, verschillende aantallen opties, verschillende toestandslengtes, verschillende machines, verschillende runtimes. Wat verifieerbaar is en het vergelijken waard is, is de vorm van het probleem, niet wie er wint: een pure-attention encoder laat zich zonder slag of stoot naar Apple Silicon porteren, en een hybride linear-attentionmodel had een heel tweede backend nodig voordat het daar bruikbaar was.

Waar een beslismodel eigenlijk voor dient

Zonder de benchmarks is de eerlijke use case beperkt, en het project zegt dat zelf: Laya is een snelle basis om op te specialiseren, geen zero-shot beslissingsengine. Op Convai's eigen typed-decisions-benchmark scoren de twee basis-checkpoints 0,362 en 0,342 zero-shot, tegenover een majority-class-baseline van 0,461 en een random baseline van 0,318. Ze liggen onder de grens die je zou halen door altijd het meest voorkomende label te antwoorden. Het topcijfer 0,766 hoort bij laya-typed-decisions, de checkpoint die is fine-tuned op de eigen trainingssplit van die benchmark, en mag nooit als algemene capaciteit worden aangehaald.

De gepubliceerde vergelijking van Convai met TypeSafe Jev 1.13.0 is om precies deze reden het lezen waard, en aan hun kant is die zorgvuldig gelabeld: elk Laya-cijfer is wat de router daadwerkelijk retourneert, en de Jev-cijfers zijn door derden gepubliceerde cijfers die Convai nooit heeft gemeten omdat het geen TypeSafe API-toegang heeft. In die vergelijking scoort de gerouteerde Laya 0,766 tegen Jevs 0,727 op typed-decisions, met post-temperature ECE van 0,081 tegen 0,246, en p50-latentie van 32,8 ms tegen 236–276 ms op een Tesla T4 — een verschil van 7,8x op één vraag. Dat is het cijfer dat je moet aanhalen. Het cijfer "50x sneller dan Jev" dat zich op sociale media verspreidde, komt niet voor in de documentatie van het project of in de benchmarks ervan, en de eigen gepubliceerde vergelijking van het project ondersteunt het niet. Jev leidt ook waar het leidt: op Banking77 scoort Jev 0,870 tegen Laya's 0,425, omdat Laya's opties een vast tokenbudget delen en 77 labels ongeveer drie tot vier tokens per stuk overlaten.

De vorm van een echte deployment is dus een beslissingshoofd dat goedkoop, lokaal en smal is — een ticket routeren, urgentie scoren, een ja/nee-poort beantwoorden — met iets generatiefs erachter voor het deel dat moet schrijven. Het beslissingsmodel doet de getypeerde aanroep in milliseconden en escaleert. De generatieve helft is een ander model op een andere runtime, en dat is waar een router zijn plaats verdient: 200+ modellen achter één sleutel tegen de listprijs van de provider zonder markup, zodat een prijswijziging van een leverancier dezelfde dag live is, en automatische failover wanneer een provider tijdens een run degradeert. OrcaRouter serveert Laya niet, en het serveert Kev of Jev niet — de Qwen3.5-familie staat op onze modellenlijst, en de beslissingsmodellen zelf niet. Wat wij dekken is de generatieve helft van die stack, de helft die je aanroept bij elk verzoek dat het beslissingshoofd escaleert.

Er is nog een reden om de twee helften gescheiden te houden in plaats van naar één model te grijpen dat beide doet. Een lokaal beslissingshoofd dat nul outputtokens kost en nooit een netwerk aanraakt, is een ander soort afhankelijkheid dan een API-aanroep: het blijft werken wanneer het netwerk dat niet doet, en de kosten schalen niet mee met hoeveel tekst het leest. Dat is de eigenschap die het waard is om voor te betalen. Al het overige in dit artikel gaat over hoeveel je ervoor betaalt in getrouwheid, geheugen en onderhoud.

Wie moet het uitvoeren, en wie moet wachten

Draai Laya-MLX als je op een Mac uit de M-serie werkt, je beslissingen beperkt zijn — een keuze uit benoemde opties, een rubriekscore, een ja/nee-poort — en je ofwel labels hebt om op te fine-tunen of zelf bereid bent om kalibratietemperaturen te fitten. De installatie is één commando, de geheugenondergrens ligt onder een gigabyte, en het fidelity-werk is gedaan en gepubliceerd.

Wacht: als je garanties voor upstream-ondersteuning nodig hebt, als je een langlevende sidecar draait en de kwestie van geheugengroei in een release beslecht wilt zien in plaats van in een open issue, of als je vragen open van aard zijn. Een niet-autoregressieve encoder die antwoordt op "wat moet ik nu doen", is geen kleinere versie van een LLM die hetzelfde doet. Het is een ander instrument, en het leest alleen goed wanneer de vraag al op het instrument is toegesneden.