Karta tytułowa hero dla Laya na Apple Silicon z tekstem „Port MLX: 13,42 ms, zero tokenów wyjściowych”, ze stopką „Pomiary autora portu na podanym M3 Max; z wyłączeniem ładowania modelu.” oraz logo OrcaRouter w prawym dolnym narożniku.
Guides & Insights

Laya na Apple Silicon: co daje Ci port MLX, a czego nie

Autor

Alistair Wren

Data publikacji

Najnowsze modele · 20Zobacz wszystkie modele
Benchmarki: Artificial Analysis · aktualizowane codziennie
Powrót do wszystkich wpisów

Laya to model decyzyjny, który nigdy nie pisze zdania. Convai Innovations udostępniło swoje wagi na Hugging Face 18 września 2026 roku, a następnego dnia deweloper o pseudonimie mizorewww opublikował Laya-MLX — niezależny port, który uruchamia wszystkie trzy checkpointy Laya natywnie na Apple Silicon przez MLX, bez PyTorch, bez środowiska uruchomieniowego Transformers i bez wywołań w chmurze. Ten port raportuje medianę 13,42 ms dla jednego krótkiego pytania po angielsku na checkpoincie 421M, 7,39 ms na wielojęzycznym 322M oraz zero tokenów wyjściowych, na M3 Max. Tymczasem Kev, druga otwarta rodzina goniąca ten sam pomysł na typowane decyzje, jest zbudowana na Qwen3.5-4B-Base i potrzebowała całego drugiego backendu, zanim stała się użyteczna na Macu, ponieważ PyTorch nie ma jąder dla jej warstw DeltaNet na GPU Apple. Dwa projekty, ten sam tydzień, ten sam cel, a tylko jeden z nich dał się przenieść bez problemów. Ta różnica to cała historia — i jest to historia środowiska uruchomieniowego, a nie modelu.

Powód, dla którego warto dziś poświęcić temu artykuł, nie polega na tym, że Laya jest nowa. Chodzi o to, że do 2026-09-19 nie było sposobu, by uruchomić na Macu model decyzyjny z typowaniem, nie ciągnąc ze sobą stosu PyTorch, a pytanie, które czytelnik naprawdę ma — czy mogę uruchomić to na swoim laptopie i z czego rezygnuję — wreszcie ma mierzalną odpowiedź. Ten tekst jest więc o ścieżce serwowania, liczbach, które za nią stoją, oraz o miejscach, w których liczby przestają oznaczać to, na co wyglądają.

Najpierw, czym Laya nie jest

Laya nie jest LLM-em. Jest nieautoregresyjna: jeden dwukierunkowy przebieg w przód po stanie plus twoje pytania i na wyjściu pojawiają się typowane odpowiedzi. Nie ma dekodowania token po tokenie, nie ma łańcucha myśli, nie ma generowanego JSON-a do parsowania ani tokenów wyjściowych do rozliczania. Trzy prymitywy odpowiedzi to choice (wybór jednej z N nazwanych opcji), score (poziom rubryki porządkowej) oraz noul (skalibrowane prawdopodobieństwo, że coś jest prawdą).

To ma znaczenie dla tego, jak czytasz każdą liczbę w tym artykule. Gdy port zgłasza 13,42 ms, nie zgłasza 13,42 ms potrzebnych na wygenerowanie kilkuset tokenów tak, jak zrobiłby to benchmark generowania. Zgłasza całą operację. Porównywanie opóźnienia modelu decyzyjnego z liczbą tokenów na sekundę LLM-a to porównywanie dwóch różnych zadań, a każdy artykuł, który to robi — w tym viralowy wpis „50x szybszy niż Jev”, który krążył po premierze — wysuwa twierdzenie, którego nie uzasadnia praca leżąca u podstaw.

Screenshot of the Hugging Face model page for convaiinnovations/laya, showing the Apache 2.0 licence, the tags Text Classification, Transformers, Safetensors, system-one and calibrated-decisions, a model size of 0.4B params, the description of Laya as a multilingual, non-autoregressive System 1 decision model that never generates text, and the start of the checkpoint table listing convaiinnovations/laya on a ModernBERT-large backbone at 421M parameters with 512-token context.

Co port faktycznie zmierzył

Te wyniki są własnymi pomiarami autora portu, uzyskanymi na podanej maszynie, i należy je odczytywać wraz z dołączonymi informacjami o maszynie i metodzie. Laya-MLX zmierzył je na M3 Max z 40 rdzeniami GPU i 128 GiB zunifikowanej pamięci, przy FP16, z wyłączeniem ładowania modelu.

• Jedno krótkie pytanie, P50 — 13,42 ms na 421M angielskim punkcie kontrolnym, 7,39 ms na 322M wielojęzycznym punkcie kontrolnym.

• Jedno krótkie pytanie, P95 — odpowiednio 13,92 ms i 7,79 ms.

• Przepustowość dla 50 pytań — 146,8 pytań na sekundę i 395,0 pytań na sekundę.

• Szczytowa alokacja MLX — 943,6 MiB i 687,6 MiB.

Granica pomiaru czasu to fragment wart przeczytania dwa razy. Obejmuje przygotowanie promptu, tokenizację, konstrukcję tensorów, zsynchronizowaną inferencję, kalibrację i formatowanie wyników. Nie obejmuje wczytywania modelu. Test przepustowości na 50 pytań użył batch_size=64, podczas gdy API domyślnie przyjmuje 16, więc ta para liczb opisuje celowo wsadowe obciążenie, a nie koszt pojedynczego wywołania interaktywnego. Różne długości danych wejściowych, różne liczby pytań i różne warunki wykonania zmieniają wynik. Te zastrzeżenia stanowią różnicę między liczbą a benchmarkiem, a port sam je podaje.

Dolna granica pamięci to wartość, na której będzie opierać się większość czytelników, i jest to najmniej niejednoznaczna wartość w zestawie: poniżej gigabajta szczytowej alokacji MLX dla jednego krótkiego pytania, na obu punktach kontrolnych. To nie jest twierdzenie o całkowitym zapotrzebowaniu na pamięć twojego Maca — system operacyjny, twój terminal i proces Python również znajdują się obok niego — ale to prawdziwa dolna granica i jest ona o około trzy rzędy wielkości niższa od tego, czego wymaga lokalne uruchomienie średniej wielkości modelu generatywnego.

Test wierności jest tym ciekawszym wynikiem.

Szybki port, który odpowiada inaczej niż model, z którego powstał, jest bezwartościowy — i właśnie tutaj projekt wykonał pracę, która ma znaczenie. Wszystkie trzy punkty kontrolne zgadzały się z wybraną odpowiedzią upstream na 63 z 63 pytań walidacyjnych zarówno w FP32, jak i FP16 — 378 z 378 porównań. Każda konfiguracja wykonała również 100 powtórzonych, deterministycznych wywołań bez zmierzonego wzrostu pamięci aktywnej, a wszystkie 36 opublikowanych plików wag przeszło rygorystyczną zdalną weryfikację sum kontrolnych.

Odczytaj zakres uczciwie: to mierzy wierność na tych zestawach testowych, a nie dokładność w przypadku każdego możliwego pytania. Mówi ci to, że port jest wierny Layi. Nie mówi ci to nic o tym, czy Laya ma rację.

Niezależny, utrzymywany przez społeczność, a wciąż nie ma go na liście

Port mówi to o sobie dwukrotnie: jest niezależnym portem MLX, a nie oficjalnym wydaniem Convai Innovations. Trening RLCD i dostrajanie pozostają w upstreamie. Wagi są przypisane do Convai Innovations. Apache-2.0 po obu stronach.

Sposób, w jaki traktuje to upstream, jest bardziej wymowny niż jakiekolwiek zastrzeżenie. README projektu Laya zawiera listę Community Tools, a na dzień 23 września 2026 r. znajdują się w niej cztery pozycje: omp-laya-judge, laya-adk-toolkit, laya-Ascend dla Huawei Ascend NPUs i laya-apple — środowisko uruchomieniowe Apple Silicon wykorzystujące GPU MLX i Neural Engine. Ten czwarty wpis pojawił się przez pull request #260, scalony 23 września 2026 r. Port, którego dotyczy ten artykuł, nie znajduje się wśród tych czterech. Lista upstreamu wskazuje teraz czytelnikom Apple Silicon inny projekt społecznościowy niż ten, który został wydany jako pierwszy i ma benchmarki.

Resztę mówi własny tracker zgłoszeń Upstreamu. Zgłoszenie #50, „Apple silicon ports”, otwarte 2026-09-21, wciąż jest otwarte; opiekun odpowiedział tego samego dnia, że wsparcie dla Apple Silicon jest śledzone, a społecznościowe porty, takie jak Laya-MLX, badają natywne wnioskowanie na Metal, po czym odpowiedział ponownie 2026-09-23 zdaniem wartym dokładnego zacytowania: „Port MLX pozostaje utrzymywany przez społeczność”. Poprawka po stronie PyTorch — autocast MPS i korekta RoPE w transformers 4.x — trafiła jako pull request #273, scalony 2026-09-23, przy czym recenzent w tym wątku zaznaczył, że wciąż trzeba ją połączyć z osobnym refaktorem autocastu w #109, który pozostaje otwarty. A zgłoszenie #52, otwarte 2026-09-21, opisuje sidecar Laya-MLX, który urósł do około 21,7 GB pamięci Metal w ciągu kilku godzin działania, przy czymvmmap przypisuje około 21,4 GB podsystemowi graficznemu, a nie stercie Pythona; proponuje się ograniczenie pamięci podręcznej alokatora i czyszczenie jej po każdym wnioskowaniu, a zgłoszenie wciąż jest otwarte.

Zestawiając to wszystko razem, praktyczna odpowiedź brzmi: to środowisko uruchomieniowe nie ma oficjalnego zatwierdzenia ze strony upstreamu, jest — według własnego opisu opiekuna — utrzymywane przez społeczność, a jedyna kwestia dotycząca pamięci, która ma znaczenie dla długo działającego sidecara, jest rozwiązywana publicznie, a nie poprawiona w wydaniu.

Screenshot of the GitHub repository page for mizorewww/laya-mlx, showing the description 'Native MLX runtime for Laya typed decision models — 7–14 ms short decisions on M3 Max. No text generation, PyTorch, or cloud API.', the Apache-2.0 licence label, 5.9k stars, 432 forks, 4 open issues and 6 open pull requests.

Czy mogę to uruchomić na swoim laptopie i z czego muszę zrezygnować?

Instalacja to jedna komenda pip, a port udostępnia wstępnie przekonwertowane wagi FP16, więc nie musisz niczego konwertować samodzielnie:

pip install laya-mlx

Następnie import laya_mlx as laya, agent = laya.load("aac6fef/laya-mlx"), i wywołaj agent.predict(state, questions). Wymagania to Apple Silicon, Python 3.11+ i macOS 14+. Zmierzone środowisko to macOS 27.2, Python 3.12.13 i MLX 0.32.2 — a port zauważa, że wydanie MLX, którego użyto, dostarczało wheels dla macOS 14, 15 i 26, podczas gdy instalator wybrał ten dla 26, oraz że starsze obsługiwane wersje macOS nie zostały przetestowane na tej maszynie.

Co poświęcasz, wymiar po wymiarze:

• FP16 w porównaniu z FP32 — FP16 jest domyślną precyzją i źródłem każdej kluczowej liczby powyżej. FP32 zapewnia bliższą zgodność numeryczną z upstreamem, a prawdopodobieństwa mogą się nieznacznie różnić między precyzjami, nawet gdy wybrana etykieta się zgadza. Można wybrać BF16, ale nie jest on częścią opublikowanej matrycy walidacyjnej, więc traktuj go jako nieprzetestowany.

• Dolna granica pamięci a zapas — poniżej 1 GiB szczytowej alokacji MLX dla krótkiego pytania jest komfortowe na każdym Macu z serii M. To nie jest stwierdzenie o długotrwałym obciążeniu serwera, a issue #52 to powód do ostrożności, jeśli planujesz uruchamiać to jako długotrwale działający sidecar, a nie jako wywołanie biblioteczne.

• Wielojęzyczny kontra angielski — wielojęzyczny checkpoint 322M jest szybszy z tych dwóch i to on obsługuje ponad 100 języków, ale port celowo powtarza ostrzeżenie z projektu źródłowego: angielskie checkpointy nie zastępują wielojęzycznego. Przełączanie między nimi to zamierzony wzorzec, a nie opcjonalny dodatek.

• Zatwierdzone przez upstream kontra utrzymywane przez społeczność — to drugie. Nic w informacjach o wydaniu upstream nie obiecuje, że ten port będzie działał mimo zmian w upstream.

• Szybkość kontra kalibracja — szybki port nie naprawia przedziału kalibracyjnego, który jest dostarczany z nadmierną pewnością. Komponent nadrzędny ogranicza dopasowane temperatury do [0.5, 5.0], a dostarczany choice:11+ przedział ma wartość 0.1006, co wyostrzyłoby logity mniej więcej dziesięciokrotnie i przedstawiłoby rzut monetą jako niemal pewność. Dopasowane temperatury kalibracji istnieją nie bez powodu; dopasuj je na własnym odłożonym zbiorze danych, zanim rozgałęzisz na podstawie prawdopodobieństwa.

Warto zapamiętać jeszcze dwa ograniczenia, oba z własnego trackera upstreamu. action.act_probability obecnie nie niesie żadnego użytecznego sygnału — zwraca 1.0 dla niemal każdego wejścia, a jego surowe logity wypadły względem poprawności przy AUROC 0,30 na 396 oznaczonych decyzjach (issue #185). Zamiast tego opieraj się na confidence, które osiąga 0,77 na tych samych pozycjach. A noul pytania mogą podążać za etykietami swoich opcji, a nie za stanem (issue #156) — własna karta upstreamu zgłasza pewne „nie” na wyraźnie pozytywnym wejściu, najsilniej na angielskim checkpoincie. Sugerowane obejście to nie sięganie po inny model, lecz przekształcenie pytania: zadaj je jako dwuopcyjne choice z neutralnymi kluczami (A/B) i swoim sformułowaniem tak/nie jako opisami opcji.

Dlaczego jeden model decyzyjny przenosi się bezproblemowo, a drugi nie

Kontrast ten ma charakter architektoniczny i jest naj użyteczniejszą rzeczą w tym artykule dla każdego, kto wybiera między tymi dwiema rodzinami.

Trzonem Layi jest ModernBERT-large, dwukierunkowy enkoder zbudowany w całości na mechanizmie uwagi. Uwaga to coś, w czym stos GPU Apple'a radzi sobie najlepiej i na czym MLX skupił swoje wysiłki. Przeniesienie jest więc reimplementacją warstw, które już miały szybkie ścieżki: enkoder, warstwy Transformera głowy decyzyjnej, głowa oceniająca i głowa akcji działają w MLX, a tokenizacja nadal przechodzi przez tokenizator Rust Hugging Face.

Szkielety Kev opierają się na bazach Qwen3.5, a Qwen3.5 miesza warstwy uwagi z warstwami Gated DeltaNet. DeltaNet jest rekurencyjny i ignoruje maski uwagi. Ma to dwie konsekwencje. Po pierwsze, każde pytanie musi być uruchamiane jako własny wiersz, zamiast współdzielić jedną zamaskowaną sekwencję, co projekt Kev obsługuje, obliczając stan raz i ponownie wykorzystując jego cache dla każdego wiersza. Po drugie — i to jest część, która doskwiera na Macu — nie było jąder PyTorch dla tych warstw na GPU Apple, więc PyTorch przeszedł na kod referencyjny. Karta modelu jaredpalmer/kev-4b wciąż podaje wynikowy limit wprost: żądanie z pięcioma pytaniami, które zajmuje 0,17 s w kompilacji Kev-4B na Qwen3, zajmuje 0,78 s w bf16 na M5.

Sprawdź aktualne brzmienie, zanim to zacytujesz, bo się zmieniło. README repozytorium Kev mówi teraz, że serwer uruchamia modele Qwen3.5 przez MLX na Apple Silicon, i podaje własne wyniki dla M5 dla żądania z pięcioma pytaniami, każde z trzema opcjami, na stanie o rozmiarze około 270 tokenów: Kev-4B przy 721 ms na nowym stanie i 136 ms na powtórzonym stanie przez pamięć podręczną prefiksów, w porównaniu z 3,302 ms i 847 ms na ścieżce PyTorch bf16 MPS. Kev-0.8B osiąga 149 ms i 28 ms. Modele Qwen3 poprzedniej generacji nadal działają na zwykłym PyTorch MPS, a projekt nazywa je dobrym wyborem na Macu.

Uważaj, żeby nie zamienić tego w wynik wyścigu. To nie są pomiary bezpośrednie. 13,42 ms Laya-MLX to jedno krótkie pytanie na M3 Max; 721 ms Kev’a to pięć pytań z trzema opcjami każde, na stanie o długości ~270 tokenów na M5. Inna liczba pytań, inna liczba opcji, inne długości stanu, inne maszyny, inne środowiska uruchomieniowe. To, co da się zweryfikować i co warto porównywać, to kształt problemu, a nie zwycięzca: czysty enkoder oparty na uwadze portuje się na Apple Silicon bez walki, a hybrydowy model z liniową uwagą potrzebował całego drugiego backendu, zanim był tam użyteczny.

Do czego tak naprawdę służy model decyzyjny

Gdy pominąć benchmarki, uczciwy przypadek użycia jest wąski, a sam projekt to przyznaje: Laya to szybka baza do specjalizacji, a nie silnik decyzyjny działający zero-shot. We własnym benchmarku Convai typed-decisions dwa bazowe checkpointy uzyskują w trybie zero-shot wyniki 0,362 i 0,342 w porównaniu z 0,461 dla baseline'u klasy większościowej i 0,318 dla losowego. Są poniżej poziomu, jaki osiągnąłbyś, zawsze odpowiadając najczęstszą etykietą. Główny wynik 0,766 należy do laya-typed-decisions, checkpointu dostrojonego na własnym podziale treningowym tego benchmarku, i nigdy nie należy go przytaczać jako ogólnej zdolności.

Opublikowane przez Convai porównanie z TypeSafe Jev 1.13.0 warto przeczytać właśnie z tego powodu i po ich stronie zostało ono starannie oznaczone: każda wartość dotycząca Laya to to, co router faktycznie zwraca, a wartości dotyczące Jev to opublikowane przez strony trzecie liczby, których Convai nigdy nie zmierzyło, ponieważ nie ma dostępu do API TypeSafe. W tym porównaniu Laya z routingiem uzyskuje 0,766 wobec 0,727 Jev w typed-decisions, z ECE po skalowaniu temperatury 0,081 wobec 0,246 oraz opóźnieniem p50 32,8 ms wobec 236–276 ms na Tesla T4 — różnica 7,8x w przypadku jednego pytania. To jest liczba, którą należy cytować. Liczba „50x szybszy niż Jev”, która rozprzestrzeniła się w mediach społecznościowych, nie pojawia się w dokumentacji projektu ani w jego benchmarkach, a własne opublikowane porównanie projektu jej nie potwierdza. Jev prowadzi także tam, gdzie prowadzi: w Banking77 Jev uzyskuje 0,870 wobec 0,425 Laya, ponieważ opcje Laya mają wspólny stały budżet tokenów, a 77 etykiet pozostawia każdej z nich około trzech do czterech tokenów.

Zatem kształt prawdziwego wdrożenia to moduł decyzyjny, który jest tani, lokalny i wąski — kierowanie zgłoszeniem, ocenianie pilności, odpowiadanie na bramkę tak/nie — z czymś generatywnym za nim dla części, która wymaga pisania. Model decyzyjny wykonuje typowane wywołanie w milisekundach i eskaluje. Połowa generatywna to inny model na innym środowisku uruchomieniowym, i to tam router zasługuje na swoje miejsce: ponad 200 modeli za jednym kluczem w cenie katalogowej dostawcy bez marży, więc zmiana ceny dostawcy obowiązuje tego samego dnia, i automatyczne przełączenie awaryjne, gdy dostawca ulegnie degradacji w trakcie działania. OrcaRouter nie obsługuje Laya i nie obsługuje Kev ani Jev — rodzina Qwen3.5 znajduje się na naszej liście modeli, a same modele decyzyjne nie. To, co obejmujemy, to generatywna połowa tego stosu, czyli ta połowa, którą wywołujesz przy każdym żądaniu, które moduł decyzyjny eskaluje.

Jest jeszcze jeden powód, by utrzymywać obie połowy osobno, zamiast sięgać po jeden model, który robiłby jedno i drugie. Lokalna głowica decyzyjna, która nie zużywa żadnych tokenów wyjściowych i nigdy nie łączy się z siecią, to zależność innego rodzaju niż wywołanie API: działa dalej, gdy sieć nie działa, a jej koszt nie rośnie wraz z ilością czytanego tekstu. To właśnie ta właściwość jest warta zapłaty. Wszystko inne w tym artykule mówi o tym, ile płacisz za nią pod względem wierności, pamięci i utrzymania.

Kto powinien to uruchomić, a kto powinien poczekać

Uruchom Laya-MLX, jeśli masz Maca z serii M, Twoje decyzje są ograniczone — wybór spośród nazwanych opcji, wynik według rubryki, bramka tak/nie — a Ty albo masz etykiety do dostrojenia, albo jesteś gotów samodzielnie dopasować temperatury kalibracji. Instalacja to jedno polecenie, minimalny wymóg pamięci to mniej niż gigabajt, a praca nad wiernością została wykonana i opublikowana.

Czekaj, jeśli potrzebujesz gwarancji wsparcia od upstreamu, jeśli uruchamiasz długo działający sidecar i chcesz, aby kwestia wzrostu pamięci została rozstrzygnięta w wydaniu, a nie w otwartym zgłoszeniu, albo jeśli twoje pytania są otwarte. Enkoder nieautoregresyjny odpowiadający na pytanie „co powinienem zrobić dalej” nie jest mniejszą wersją LLM robiącego to samo. To inne narzędzie i sprawdza się tylko wtedy, gdy pytanie jest już ukształtowane pod nie.

A generated two-column scoreboard for Laya-MLX on Apple Silicon. Left column 'Laya 421M English': One short question P50 13.42 ms, P95 13.92 ms, 50-question throughput 146.8 q/s, Peak MLX allocation 943.6 MiB, Output tokens zero, Precision FP16. Right column 'Laya 322M multilingual': P50 7.39 ms, P95 7.79 ms, 395.0 q/s, 687.6 MiB, zero output tokens, FP16. Footer 'Port author measurements on a stated M3 Max (40-core GPU, 128 GiB); model loading excluded.', with the OrcaRouter logo in the bottom-right corner.

Porównane w tym artykule1

Wykryto na podstawie tego artykułu · Benchmarki: Artificial Analysis · aktualizowane codziennie