Laya på Apple Silicon: Vad MLX-porten ger dig – och vad den inte ger

Laya är en beslutsmodell som aldrig skriver en mening. Convai Innovations lade ut sina vikter på Hugging Face den 18 september 2026, och dagen därpå publicerade en utvecklare vid namn mizorewww Laya-MLX – en oberoende port som kör alla tre Laya-checkpoints nativt på Apple Silicon via MLX, utan PyTorch, utan Transformers-runtime och utan molnanrop. Den porten rapporterar 13,42 ms i median för en kort engelsk fråga på 421M-checkpointen, 7,39 ms på den flerspråkiga 322M-modellen och noll utdatatokens, på en M3 Max. Samtidigt är Kev, den andra öppna familjen som jagar samma idé om typade beslut, byggd på Qwen3.5-4B-Base och behövde en helt annan backend innan den gick att använda på en Mac, eftersom PyTorch inte har några kärnor för dess DeltaNet-lager på Apples GPU. Två projekt, samma vecka, samma mål, och bara ett av dem porterades problemfritt. Den skillnaden är historien, och det är en runtime-historia snarare än en modellhistoria.

Anledningen till att detta är värt en artikel i dag är inte att Laya är ny. Det är att det fram till 2026-09-19 inte fanns något sätt att köra en typad beslutsmodell på en Mac utan att släpa med sig en PyTorch-stack, och frågan en läsare faktiskt har – kan jag köra detta på min laptop, och vad ger jag upp – har äntligen ett mätbart svar. Så den här artikeln handlar om serveringsvägen, siffrorna bakom den och de ställen där siffrorna inte längre betyder det de ser ut att betyda.

Först, vad Laya inte är

Laya är inte en LLM. Den är icke-autoregressiv: en bidirektionell framåtpassning över tillståndet plus dina frågor, och ut kommer typade svar. Det finns ingen token-för-token-avkodning, ingen tankekedja, ingen genererad JSON att parsa, och inga utdatatokens att debitera. De tre svarsprimitiverna är val (välj ett av N namngivna alternativ), poäng (en ordinal bedömningsnivå) och noul (en kalibrerad sannolikhet att något är sant).

Det spelar roll för hur du läser varje siffra i den här artikeln. När porten rapporterar 13,42 ms rapporterar den inte 13,42 ms för att producera några hundra tokens så som ett genereringsbenchmark skulle göra. Den rapporterar hela operationen. Att jämföra en beslutsmodells latens med en LLM:s tokens per sekund är att jämföra två olika uppgifter, och varje artikel som gör det – inklusive det virala inlägget "50x snabbare än Jev" som cirkulerade efter lanseringen – gör ett påstående som det underliggande arbetet inte stöder.

Vad porten faktiskt mätte

Dessa siffror är portförfattarens egna, tagna på en angiven maskin, och de bör läsas med angiven maskin och metod. Laya-MLX mätte dem på en M3 Max med 40 GPU-kärnor och 128 GiB enhetligt minne, vid FP16, med modellinläsning exkluderad.

• En kort fråga, P50 — 13,42 ms på den 421M engelska checkpointen, 7,39 ms på den 322M flerspråkiga checkpointen.

• En kort fråga, P95 — 13,92 ms respektive 7,79 ms.

• Genomströmning för 50 frågor — 146,8 frågor per sekund och 395,0 frågor per sekund.

• Högsta MLX-allokering — 943,6 MiB och 687,6 MiB.

Tidsgränsen är den del som är värd att läsa två gånger. Den inkluderar förberedelse av prompt, tokenisering, tensoruppbyggnad, synkroniserad inferens, kalibrering och formatering av resultat. Den utesluter modellinläsning. Genomflödeskörningen med 50 frågor använde batch_size=64, medan API:et som standard använder 16, så det paret siffror beskriver en avsiktligt batchad arbetsbelastning snarare än vad ett enskilt interaktivt anrop kostar. Olika indatalängder, olika antal frågor och olika körtidsförhållanden påverkar alla resultatet. Dessa förbehåll är skillnaden mellan en siffra och ett benchmark, och porten anger dem själv.

Minnesgolvet är den siffra som de flesta läsare kommer att agera på, och den är den minst tvetydiga i uppsättningen: ett toppvärde för MLX-allokeringen på under en gigabyte för en enda kort fråga, på båda checkpoints. Det är inte ett påstående om din Macs totala fotavtryck – operativsystemet, terminalen och Python-processen ligger alla vid sidan om – men det är ett verkligt golv, och det ligger ungefär tre storleksordningar under vad som krävs för att köra en medelstor generativ modell lokalt.

Fidelitetskontrollen är det mer intressanta resultatet.

En snabb port som svarar annorlunda än modellen den porterar är värdelös, och det är här projektet gjorde arbetet som spelar roll. Alla tre checkpoints matchade det uppströms valda svaret på 63 av 63 valideringsfrågor i både FP32 och FP16 — 378 av 378 jämförelser. Varje konfiguration körde också 100 upprepade, deterministiska anrop utan uppmätt ökning av aktivt minne, och alla 36 publicerade viktfiler klarade strikt fjärrverifiering av kontrollsumma.

Läs omfattningen ärligt: det mäter trohet mot de där fixturerna, inte träffsäkerhet för varje tänkbar fråga. Det säger dig att portningen är trogen Laya. Det säger dig ingenting om huruvida Laya har rätt.

Oberoende, community-underhållet och fortfarande inte på listan

Porten säger detta om sig själv, två gånger: den är en oberoende MLX-port, inte en officiell utgåva från Convai Innovations. RLCD-träning och finjustering stannar uppströms. Vikterna tillskrivs Convai Innovations. Apache-2.0 på båda sidor.

Hur uppströms hanterar det är mer avslöjande än någon ansvarsfriskrivning. Laya-README:n innehåller en Community Tools-lista, och per den 2026-09-23 innehåller den fyra poster: omp-laya-judge, laya-adk-toolkit, laya-Ascend för Huawei Ascend NPU:er samt laya-apple – en Apple Silicon-runtime som använder MLX-GPU:n och Neural Engine. Den fjärde posten kom in via pull request #260, som slogs samman den 2026-09-23. Porten som den här artikeln handlar om finns inte bland de fyra. Uppströms lista pekar nu Apple Silicon-läsare mot ett annat communityprojekt än det som släpptes först och har benchmarkresultaten.

Upstreams egen ärendespårare säger resten. Ärende #50, "Apple silicon ports", öppnat 2026-09-21, är fortfarande öppet; underhållaren svarade samma dag att stöd för Apple Silicon spåras och att communityportar som Laya-MLX utforskar nativ Metal-inferens, och svarade sedan igen 2026-09-23 med en rad som är värd att citera ordagrant: "The MLX port remains community-maintained." Fixen på PyTorch-sidan – MPS-autocast och en RoPE-korrigering för transformers 4.x – landade som pull request #273, mergad 2026-09-23, med en granskare i den tråden som påpekade att den fortfarande behöver kombineras med den separata autocast-refaktoreringen i #109, som fortfarande är öppen. Och ärende #52, öppnat 2026-09-21, rapporterar en Laya-MLX-sidecar som växte till ungefär 21,7 GB Metal-minne under flera timmars drift, där vmmap tillskriver omkring 21,4 GB till grafikundersystemet snarare än Python-heapen; den föreslår att begränsa allokatorcachen och rensa den efter varje inferens, och den är fortfarande öppen.

Lägger man ihop det är det praktiska svaret: den här runtimemiljön är inte godkänd av upstream, den underhålls av communityn enligt underhållarens egen beskrivning, och den enda minnesfrågan som spelar roll för en långkörande sidecar bearbetas öppet i stället för att åtgärdas i en release.

Kan jag köra det på min laptop, och vad får jag ge upp?

Installationen är ett enda pip-kommando, och porten publicerar förkonverterade FP16-vikter så att du inte behöver konvertera något själv:

pip install laya-mlx

Sedan import laya_mlx as laya, agent = laya.load("aac6fef/laya-mlx"), och anropa agent.predict(state, questions). Kraven är Apple Silicon, Python 3.11+ och macOS 14+. Den uppmätta miljön var macOS 27.2, Python 3.12.13 och MLX 0.32.2 – och portningen noterar att MLX-utgåvan som användes levererade wheels för macOS 14, 15 och 26 medan installationsprogrammet valde 26:an, och att äldre macOS-versioner som stöds inte testades på den datorn.

Vad du ger upp, dimension för dimension:

• FP16 kontra FP32 — FP16 är standard och källan till varje nyckeltal ovan. FP32 ger närmare numerisk överensstämmelse med uppströms, och sannolikheter kan skilja sig något mellan olika precisioner även när den valda etiketten stämmer. BF16 kan begäras men ingår inte i den publicerade valideringsmatrisen, så behandla det som otestat.

• Minnesgolv kontra marginal — under 1 GiB i högsta MLX-allokering för en kort fråga är bekvämt på vilken Mac med M-serie som helst. Det är inte ett uttalande om varaktig serverbelastning, och issue #52 är anledningen till att vara försiktig om du planerar att köra detta som en långvarig sidecar snarare än ett biblioteksanrop.

• Flerspråkig kontra engelsk — den flerspråkiga 322M-checkpointen är den snabbare av de två och den som täcker 100+ språk, men porten förmedlar avsiktligt vidare upstreams varning: de engelska checkpointarna är inte ersättare för den flerspråkiga. Routning mellan dem är det avsedda mönstret, inte en finess.

• Upstream-godkänd kontra community-underhållen — det är det senare. Ingenting i upstreams versionsanteckningar lovar att denna port fortsätter att fungera över upstream-ändringar.

• Hastighet kontra kalibrering — en snabb portering åtgärdar inte en kalibreringsbucket som levereras överkonfident. Uppströms begränsar anpassade temperaturer till [0.5, 5.0], och den levererade choice:11+ bucket är 0.1006, vilket skulle skärpa logits ungefär tiofalt och rapportera en slantsingling som nästan säkerhet. Anpassade kalibreringstemperaturer finns av en anledning; anpassa dem på dina egna undanhållna data innan du förgrenar dig på en sannolikhet.

Ytterligare två begränsningar är värda att ta med, båda från upstreams egen tracker. action.act_probability bär för närvarande ingen användbar signal — den visar 1.0 för nästan varje indata, och dess råa logits gick emot korrekthet vid en AUROC på 0.30 över 396 märkta beslut (issue #185). Grinda i stället på confidence, som når 0.77 på samma poster. Och noul-frågor kan följa sina alternativetiketter i stället för tillståndet (issue #156) — upstreams eget kort rapporterar ett självsäkert "no" på tydligt positiv indata, starkast på den engelska checkpointen. Den lösning det föreslår är inte att ta till en annan modell utan att forma om frågan: ställ den som två alternativ, alltså ett val med neutrala nycklar (A/B) och din ja/nej-formulering som alternativbeskrivning.

Varför en beslutsmodell kan porteras smidigt och den andra inte

Kontrasten här är arkitektonisk, och den är det mest användbara i den här artikeln för den som ska välja mellan de två familjerna.

Layas stomme är ModernBERT-large, en dubbelriktad encoder byggd helt och hållet av attention. Attention är det Apples GPU-stack är bäst på, och det är vad MLX har lagt sin kraft på. Portningen är därför en återimplementering av lager som redan hade snabba vägar: encodern, beslutshuvudets Transformer-lager, poängsättningshuvudet och handlingshuvudet körs alla i MLX, och tokeniseringen går fortfarande via Hugging Faces Rust-tokeniserare.

Kevs backbones är Qwen3.5-baser, och Qwen3.5 blandar uppmärksamhetslager med Gated DeltaNet-lager. DeltaNet är rekurrent och ignorerar uppmärksamhetsmasker. Det får två konsekvenser. För det första måste varje fråga köras som en egen rad i stället för att dela en maskad sekvens, vilket Kev-projektet hanterar genom att beräkna tillståndet en gång och återanvända cachen per rad. För det andra – och det är här det skaver på en Mac – fanns det inga PyTorch-kärnor för dessa lager på Apples GPU, så PyTorch föll tillbaka på referenskod. Modellkortet för jaredpalmer/kev-4b anger fortfarande den resulterande begränsningen i klarspråk: en förfrågan med fem frågor som tar 0,17 s på Qwen3-bygget av Kev-4B tar 0,78 s i bf16 på en M5.

Kontrollera den aktuella ordalydelsen innan du citerar det, eftersom den har ändrats. README-filen i Kev-repositoriet säger nu att servern i stället kör Qwen3.5-modellerna via MLX på Apple Silicon, och publicerar sina egna M5-siffror för en begäran med fem frågor och tre alternativ vardera på ett tillstånd på ungefär 270 tokens: Kev-4B ligger på 721 ms på ett nytt tillstånd och 136 ms på ett upprepat tillstånd via prefixcachen, mot 3 302 ms och 847 ms på PyTorch bf16 MPS-vägen. Kev-0.8B landar på 149 ms och 28 ms. Den tidigare generationens Qwen3-modeller körs fortfarande på vanlig PyTorch MPS, och projektet kallar dem ett utmärkt val på en Mac.

Var försiktig så att du inte gör det till ett tävlingsresultat. Det här är inte direkta jämförande mätningar. Laya-MLX:s 13,42 ms är en kort fråga på en M3 Max; Kevs 721 ms är fem frågor med tre alternativ vardera på ett tillstånd på ~270 token på en M5. Olika antal frågor, olika antal alternativ, olika tillståndslängder, olika maskiner, olika körtider. Det som är verifierbart och värt att jämföra är problemets form, inte en vinnare: en renodlad attention-encoder portas till Apple Silicon utan problem, och en hybridmodell med linjär attention behövde en helt egen andra backend innan den var användbar där.

Vad en beslutsmodell egentligen är till för

Rensar man bort benchmarkarna är den ärliga användningen smal, och projektet säger det själv: Laya är en snabb bas för specialisering, inte en zero-shot-beslutsmotor. I Convais egen typed-decisions-benchmark får de två bascheckpointarna 0,362 och 0,342 zero-shot mot en majoritetsklassbaslinje på 0,461 och en slumpmässig på 0,318. De ligger under den linje man skulle få genom att alltid svara med den vanligaste etiketten. Rubrikvärdet 0,766 tillhör laya-typed-decisions, checkpointen som finjusterats på benchmarksens egen träningsdel, och den bör aldrig citeras som allmän förmåga.

Convais publicerade jämförelse mot TypeSafe Jev 1.13.0 är värd att läsa av just denna anledning, och den är noggrant märkt från deras sida: varje Laya-siffra är vad routern faktiskt returnerar, och Jev-siffrorna är tredjepartspublicerade siffror som Convai aldrig mätte eftersom det inte har någon TypeSafe API-åtkomst. I den jämförelsen får den routade Laya 0,766 mot Jevs 0,727 på typed-decisions, med post-temperature-ECE på 0,081 mot 0,246, och p50-latens på 32,8 ms mot 236–276 ms på en Tesla T4 — en skillnad på 7,8x på en fråga. Det är den siffran man bör citera. Siffran ”50x snabbare än Jev” som spreds i sociala medier finns inte i projektets dokumentation eller dess benchmarks, och projektets egen publicerade jämförelse stöder den inte. Jev leder också där Jev leder: på Banking77 får Jev 0,870 mot Layas 0,425, eftersom Layas alternativ delar en fast tokenbudget och 77 etiketter lämnar ungefär tre till fyra tokens var.

Så formen på en verklig driftsättning är ett beslutshuvud som är billigt, lokalt och smalt — dirigerar ett ärende, poängsätter brådska, svarar på en ja/nej-grind — med något generativt bakom för den del som behöver skriva. Beslutsmodellen fattar det typade anropet på millisekunder och eskalerar. Den generativa halvan är en annan modell på en annan runtime, och det är där en router förtjänar sin plats: 200+ modeller bakom en enda nyckel till leverantörens listpris utan påslag, så en leverantörsprisändring är live samma dag, och automatisk failover när en leverantör försämras mitt i körningen. OrcaRouter betjänar inte Laya, och det betjänar inte Kev eller Jev — Qwen3.5-familjen finns på vår modellista, och beslutsmodellerna själva gör det inte. Det vi täcker är den generativa halvan av den stacken, vilket är den halva du anropar vid varje förfrågan som beslutshuvudet eskalerar.

Det finns ytterligare en anledning att hålla de två halvorna åtskilda i stället för att ta till en enda modell som gör båda. Ett lokalt beslutshuvud som kostar noll utdatatokens och aldrig rör ett nätverk är ett annat slags beroende än ett API-anrop: det fortsätter fungera när nätverket inte gör det, och dess kostnad skalar inte med hur mycket text det läser. Det är egenskapen som är värd att betala för. Allt annat i den här artikeln handlar om hur mycket du betalar för det i trohet, minne och underhåll.

Vem bör köra det, och vem bör vänta

Kör Laya-MLX om du använder en Mac i M-serien: dina beslut är begränsade – ett val bland namngivna alternativ, en poäng enligt en bedömningsmatris, en ja/nej-grind – och du har antingen etiketter att finjustera på eller är beredd att själv anpassa kalibreringstemperaturer. Installationen är ett enda kommando, minneskravet är under en gigabyte, och fidelitetsarbetet har utförts och publicerats.

Vänta om du behöver garantier för upstream-support, om du kör en långlivad sidecar och vill få minnestillväxtfrågan avgjord i en release i stället för i ett öppet issue, eller om dina frågor är öppna. En icke-autoregressiv encoder som svarar på ”vad ska jag göra härnäst” är inte en mindre version av en LLM som gör samma sak. Det är ett annat instrument, och den läser av bra bara när frågan redan är formad för den.