Laya auf Apple Silicon: Was der MLX-Port bringt – und was nicht

Laya ist ein Entscheidungsmodell, das niemals einen Satz schreibt. Convai Innovations veröffentlichte seine Gewichte am 18.09.2026 auf Hugging Face, und am nächsten Tag veröffentlichte ein Entwickler namens mizorewww Laya-MLX – einen unabhängigen Port, der alle drei Laya-Checkpoints nativ auf Apple Silicon über MLX ausführt, ohne PyTorch, ohne Transformers-Runtime und ohne Cloud-Aufruf. Dieser Port meldet einen Median von 13,42 ms für eine kurze englische Frage auf dem 421M-Checkpoint, 7,39 ms auf dem mehrsprachigen 322M-Checkpoint und null Ausgabe-Tokens auf einem M3 Max. Währenddessen Kev, die andere offene Familie, die dieselbe Idee typisierter Entscheidungen verfolgt, auf Qwen3.5-4B-Base aufbaut und ein komplettes zweites Backend benötigte, bevor sie auf einem Mac nutzbar war, weil PyTorch keine Kernel für seine DeltaNet-Schichten auf Apples GPU hat. Zwei Projekte, dieselbe Woche, dasselbe Ziel, und nur eines davon ließ sich sauber portieren. Dieser Unterschied ist die Geschichte, und es ist eher eine Runtime-Geschichte als eine Modell-Geschichte.

Der Grund, warum das heute einen Artikel wert ist, ist nicht, dass Laya neu ist. Er liegt darin, dass es bis zum 19. September 2026 keine Möglichkeit gab, ein typisiertes Entscheidungsmodell auf einem Mac auszuführen, ohne einen PyTorch-Stack mitzuschleppen, und dass die Frage, die eine Leserin oder ein Leser tatsächlich hat – kann ich das auf meinem Laptop ausführen, und worauf verzichte ich –, endlich eine messbare Antwort hat. In diesem Beitrag geht es also um den Serving-Pfad, die Zahlen dahinter und die Stellen, an denen die Zahlen nicht mehr das bedeuten, wonach sie aussehen.

Zuerst einmal, was Laya nicht ist

Laya ist kein LLM. Es ist nicht-autoregressiv: ein einziger bidirektionaler Forward-Pass über den Zustand plus Ihre Fragen, und heraus kommen typisierte Antworten. Es gibt keine Token-für-Token-Dekodierung, keine Gedankenkette, kein generiertes JSON zum Parsen und keine Ausgabe-Tokens, die abgerechnet werden. Die drei Antwort-Primitive sind choice (eine von N benannten Optionen auswählen), score (eine ordinale Rubrikstufe) und noul (eine kalibrierte Wahrscheinlichkeit dafür, dass etwas wahr ist).

Das ist entscheidend dafür, wie du jede Zahl in diesem Artikel liest. Wenn der Port 13,42 ms meldet, dann meldet er nicht 13,42 ms für die Erzeugung einiger hundert Tokens, wie es ein Generierungs-Benchmark tun würde. Er meldet den gesamten Vorgang. Die Latenz eines Entscheidungsmodells mit den Tokens pro Sekunde eines LLM zu vergleichen, heißt, zwei völlig unterschiedliche Aufgaben zu vergleichen, und jeder Artikel, der das tut – einschließlich des viralen Beitrags „50x faster than Jev“, der nach dem Launch die Runde machte –, erhebt einen Anspruch, den die zugrunde liegende Arbeit nicht stützt.

Was der Port tatsächlich gemessen hat

Diese Werte stammen vom Autor des Ports selbst, wurden auf einer angegebenen Maschine ermittelt und sollten zusammen mit der Maschine und der Methode gelesen werden, die dazugehören. Laya-MLX hat sie auf einem M3 Max mit 40 GPU-Kernen und 128 GiB Unified Memory bei FP16 gemessen, wobei das Laden des Modells nicht eingerechnet wurde.

• Eine kurze Frage, P50 — 13,42 ms auf dem englischen 421M-Checkpoint, 7,39 ms auf dem mehrsprachigen 322M-Checkpoint.

• Eine kurze Frage, P95 — 13,92 ms bzw. 7,79 ms.

• 50-Fragen-Durchsatz — 146,8 Fragen pro Sekunde und 395,0 Fragen pro Sekunde.

• Maximale MLX-Zuordnung — 943,6 MiB und 687,6 MiB.

Die Zeitmessgrenze ist der Teil, den man zweimal lesen sollte. Sie umfasst Prompt-Vorbereitung, Tokenisierung, Tensor-Konstruktion, synchronisierte Inferenz, Kalibrierung und Ergebnisformatierung. Sie schließt das Laden des Modells aus. Der Durchsatzlauf mit 50 Fragen verwendete batch_size=64, während die API standardmäßig 16 verwendet, sodass dieses Zahlenpaar eine bewusst gebatchte Arbeitslast beschreibt und nicht das, was ein einzelner interaktiver Aufruf kostet. Unterschiedliche Eingabelängen, unterschiedliche Fragenanzahlen und unterschiedliche Laufzeitbedingungen verändern das Ergebnis. Diese Einschränkungen sind der Unterschied zwischen einer Zahl und einem Benchmark, und der Port nennt sie selbst.

Die Speicheruntergrenze ist der Wert, nach dem sich die meisten Leser richten werden, und sie ist die am wenigsten mehrdeutige Zahl im Set: unter einem Gigabyte Spitzen-MLX-Allokation für eine einzelne kurze Frage, bei beiden Checkpoints. Das ist keine Aussage über den gesamten Footprint Ihres Macs – das Betriebssystem, Ihr Terminal und der Python-Prozess laufen daneben mit –, aber es ist eine echte Untergrenze, und sie liegt ungefähr drei Größenordnungen unter dem, was der lokale Betrieb eines mittelgroßen generativen Modells erfordert.

Der Fidelity-Check ist das interessantere Ergebnis

Eine schnelle Portierung, die anders antwortet als das Modell, das sie portiert, ist wertlos, und genau hier hat das Projekt die entscheidende Arbeit geleistet. Alle drei Checkpoints stimmten bei 63 von 63 Validierungsfragen sowohl in FP32 als auch in FP16 mit der vom Upstream ausgewählten Antwort überein – 378 von 378 Vergleichen. Jede Konfiguration führte außerdem 100 wiederholte, deterministische Aufrufe aus, ohne messbares Wachstum des aktiven Speichers, und alle 36 veröffentlichten Gewichtsdateien bestanden eine strenge Remote-Prüfsummenverifikation.

Lies den Geltungsbereich ehrlich: Das misst die Treue bei diesen Fixtures, nicht die Genauigkeit bei jeder möglichen Frage. Es sagt dir, dass der Port Laya treu ist. Es sagt dir nichts darüber, ob Laya recht hat.

Unabhängig, von der Community gepflegt – und immer noch nicht auf der Liste.

Der Port sagt dies über sich selbst, zweimal: Er ist ein unabhängiger MLX-Port, keine offizielle Veröffentlichung von Convai Innovations. RLCD-Training und Fine-Tuning bleiben upstream. Die Gewichte werden Convai Innovations zugeschrieben. Apache-2.0 auf beiden Seiten.

Wie Upstream damit umgeht, ist aufschlussreicher als jeder Haftungsausschluss. Das Laya-README enthält eine Liste der Community-Tools, und mit Stand 2026-09-23 umfasst sie vier Einträge: omp-laya-judge, laya-adk-toolkit, laya-Ascend für Huawei Ascend NPUs und laya-apple — eine Apple-Silicon-Runtime, die die MLX-GPU und die Neural Engine verwendet. Dieser vierte Eintrag kam über Pull Request #260, gemergt am 2026-09-23. Der Port, um den es in diesem Artikel geht, ist nicht unter den vier. Upstreams Liste verweist Apple-Silicon-Leser jetzt auf ein anderes Community-Projekt als auf dasjenige, das zuerst veröffentlicht wurde und die Benchmarks enthält.

Der Issue-Tracker von Upstream selbst verrät den Rest. Issue #50, „Apple-Silicon-Ports“, eröffnet am 21.09.2026, ist nach wie vor offen; der Maintainer antwortete noch am selben Tag, dass Apple-Silicon-Support nachverfolgt wird und dass Community-Ports wie Laya-MLX native Metal-Inferenz erkunden, und antwortete dann am 23.09.2026 erneut mit einem Satz, den man wörtlich zitieren sollte: „Der MLX-Port wird weiterhin von der Community gepflegt.“ Der Fix auf der PyTorch-Seite – MPS-Autocast und eine RoPE-Korrektur in transformers 4.x – landete als Pull Request #273 und wurde am 23.09.2026 gemergt, wobei ein Reviewer in jenem Thread anmerkte, dass er noch mit dem separaten Autocast-Refactoring in #109 kombiniert werden muss, das weiterhin offen ist. Und Issue #52, eröffnet am 21.09.2026, berichtet von einem Laya-MLX-Sidecar, der über mehrere Betriebsstunden hinweg auf rund 21,7 GB Metal-Speicher anwuchs, wobei vmmap etwa 21,4 GB dem Grafiksubsystem statt dem Python-Heap zuschreibt; darin wird vorgeschlagen, den Allocator-Cache zu begrenzen und ihn nach jeder Inferenz zu leeren, und es ist nach wie vor offen.

Fasst man das zusammen, lautet die praktische Antwort: Diese Runtime ist nicht vom Upstream abgesegnet, sie wird – nach der eigenen Beschreibung des Maintainers – von der Community gepflegt, und die eine Speicherfrage, die für einen lang laufenden Sidecar zählt, wird öffentlich bearbeitet statt in einem Release behoben.

Kann ich es auf meinem Laptop laufen lassen, und worauf muss ich verzichten?

Install ist ein einziger pip-Befehl, und der Port veröffentlicht bereits konvertierte FP16-Gewichte, sodass du nichts selbst konvertieren musst:

pip install laya-mlx

Dann import laya_mlx as laya, agent = laya.load("aac6fef/laya-mlx"), und rufe agent.predict(state, questions) auf. Die Anforderungen sind Apple Silicon, Python 3.11+ und macOS 14+. Die gemessene Umgebung war macOS 27.2, Python 3.12.13 und MLX 0.32.2 — und die Portierung merkt an, dass die verwendete MLX-Version Wheels für macOS 14, 15 und 26 auslieferte, während das Installationsprogramm das 26er-Wheel auswählte, und dass ältere unterstützte macOS-Versionen auf diesem Rechner nicht getestet wurden.

Was Sie aufgeben, Dimension für Dimension:

• FP16 versus FP32 — FP16 ist der Standard und die Quelle jeder oben genannten Kernzahl. FP32 liefert eine engere numerische Übereinstimmung mit Upstream, und Wahrscheinlichkeiten können über verschiedene Präzisionen hinweg leicht abweichen, selbst wenn das ausgewählte Label übereinstimmt. BF16 kann angefordert werden, ist aber nicht Teil der veröffentlichten Validierungsmatrix, daher sollte es als ungetestet betrachtet werden.

• Speicher-Mindestbedarf versus Spielraum – unter 1 GiB Spitzen-MLX-Allokation für eine kurze Frage ist auf jedem Mac der M-Serie komfortabel. Das ist keine Aussage über anhaltende Serverlast, und Issue #52 ist der Grund, vorsichtig zu sein, wenn du dies als langlebigen Sidecar statt als Bibliotheksaufruf betreiben willst.

• Mehrsprachig versus Englisch — der 322M-Mehrsprachigkeits-Checkpoint ist der schnellere der beiden und derjenige, der über 100 Sprachen abdeckt, doch der Port gibt die Warnung von Upstream bewusst weiter: Die englischen Checkpoints sind kein Ersatz für den mehrsprachigen. Das Routing zwischen ihnen ist das vorgesehene Muster, keine bloße Annehmlichkeit.

• Von Upstream abgesegnet versus von der Community gepflegt – es ist Letzteres. Nichts in den Upstream-Release-Notes verspricht, dass dieser Port über Upstream-Änderungen hinweg weiter funktioniert.

• Geschwindigkeit versus Kalibrierung — ein schneller Port behebt keinen Kalibrierungs-Bucket, der mit übermäßiger Selbstsicherheit ausgeliefert wird. Upstream begrenzt angepasste Temperaturen auf [0.5, 5.0], und der ausgelieferte choice:11+-Bucket ist 0.1006, was die Logits grob um den Faktor zehn schärfen und einen Münzwurf als nahezu sicher ausgeben würde. Angepasste Kalibrierungstemperaturen gibt es aus gutem Grund; passe sie auf deinen eigenen Hold-out-Daten an, bevor du anhand einer Wahrscheinlichkeit verzweigst.

Es lohnt sich, zwei weitere Einschränkungen zu beachten, beide aus dem eigenen Tracker von Upstream. action.act_probability liefert derzeit kein nutzbares Signal — es zeigt bei fast jeder Eingabe 1,0, und seine Roh-Logits wurden an der Korrektheit gemessen und erreichten einen AUROC von 0,30 über 396 gelabelte Entscheidungen (Issue #185). Setzen Sie stattdessen auf confidence, was bei denselben Elementen 0,77 erreicht. Und noul-Fragen können eher ihren Optionslabels als dem Status folgen (Issue #156) — die eigene Model Card von Upstream meldet ein selbstsicheres „Nein“ bei klar positiven Eingaben, am stärksten beim englischen Checkpoint. Der vorgeschlagene Workaround besteht nicht darin, zu einem anderen Modell zu greifen, sondern die Frage umzuformen: Stellen Sie sie als Zwei-Optionen-choice mit neutralen Schlüsseln (A/B) und Ihre Ja/Nein-Formulierung als Optionsbeschreibungen.

Warum sich das eine Entscheidungsmodell sauber portieren lässt und das andere nicht

Der Gegensatz hier ist architektonischer Natur, und er ist das Nützlichste in diesem Artikel für alle, die zwischen den beiden Familien wählen.

Layas Backbone ist ModernBERT-large, ein bidirektionaler Encoder, der vollständig aus Attention aufgebaut ist. Attention ist das, worin Apples GPU-Stack am besten ist, und worauf MLX seine Anstrengungen konzentriert hat. Die Portierung ist also eine Neuimplementierung von Schichten, die bereits schnelle Pfade hatten: Der Encoder, die Transformer-Schichten des Decision-Heads, der Scoring-Head und der Action-Head laufen alle in MLX, und die Tokenisierung läuft weiterhin über den Rust-Tokenizer von Hugging Face.

Kevs Backbones sind Qwen3.5-Basismodelle, und Qwen3.5 mischt Attention-Schichten mit Gated-DeltaNet-Schichten. DeltaNet ist rekurrent und ignoriert Attention-Masken. Das hat zwei Konsequenzen. Erstens muss jede Frage als eigene Zeile ausgeführt werden, statt eine gemeinsame maskierte Sequenz zu teilen, was das Kev-Projekt dadurch löst, dass es den Zustand einmal berechnet und seinen Cache pro Zeile wiederverwendet. Zweitens – und das ist der Teil, der auf einem Mac schmerzt – gab es keine PyTorch-Kernel für diese Schichten auf Apples GPU, also griff PyTorch auf Referenzcode zurück. Die jaredpalmer/kev-4b Modellkarte nennt die daraus resultierende Einschränkung noch immer in klarer Sprache: Eine Anfrage mit fünf Fragen, die auf dem Qwen3-Build von Kev-4B 0,17 s benötigt, benötigt in bf16 auf einem M5 0,78 s.

Prüfe die aktuelle Formulierung, bevor du das zitierst, denn sie hat sich geändert. Die README des Kev-Repositorys besagt jetzt, dass der Server die Qwen3.5-Modelle stattdessen über MLX auf Apple Silicon ausführt und eigene M5-Messwerte für eine Anfrage mit fünf Fragen und jeweils drei Optionen bei einem Zustand von rund 270 Token veröffentlicht: Kev-4B bei 721 ms bei einem neuen Zustand und 136 ms bei einem wiederholten Zustand über den Präfix-Cache, gegenüber 3.302 ms und 847 ms auf dem PyTorch-bf16-MPS-Pfad. Kev-0.8B liegt bei 149 ms und 28 ms. Die Qwen3-Modelle der vorherigen Generation laufen weiterhin auf reinem PyTorch-MPS, und das Projekt bezeichnet sie als gute Wahl auf einem Mac.

Achte darauf, daraus kein Rennergebnis zu machen. Das sind keine direkten Vergleichsmessungen. Laya-MLXs 13,42 ms sind eine kurze Frage auf einem M3 Max; Kevs 721 ms sind fünf Fragen mit je drei Optionen bei einem Zustand von ca. 270 Token auf einem M5. Unterschiedliche Anzahlen an Fragen, unterschiedliche Anzahlen an Optionen, unterschiedliche Zustandslängen, unterschiedliche Rechner, unterschiedliche Laufzeitumgebungen. Was sich verifizieren lässt und einen Vergleich wert ist, ist die Form des Problems, nicht ein Sieger: Ein reiner Attention-Encoder lässt sich problemlos auf Apple Silicon portieren, und ein hybrides Linear-Attention-Modell brauchte ein komplettes zweites Backend, bevor es dort nutzbar war.

Wofür ein Entscheidungsmodell tatsächlich gedacht ist

Zieht man die Benchmarks ab, ist der ehrliche Anwendungsfall eng – und das Projekt sagt das selbst: Laya ist eine schnelle Basis zum Spezialisieren, keine Zero-Shot-Entscheidungsmaschine. Im eigenen Typed-Decisions-Benchmark von Convai erreichen die beiden Basis-Checkpoints 0,362 und 0,342 Zero-Shot gegenüber einer Majority-Class-Baseline von 0,461 und einem Zufallswert von 0,318. Sie liegen unter der Linie, die man erreichen würde, wenn man immer das häufigste Label antwortet. Der Schlagzeilenwert 0,766 gehört zu laya-typed-decisions, dem Checkpoint, der auf dem eigenen Trainingssplit dieses Benchmarks feinabgestimmt wurde, und er sollte niemals als allgemeine Fähigkeit zitiert werden.

Convais veröffentlichter Vergleich gegen TypeSafe Jev 1.13.0 ist genau aus diesem Grund lesenswert, und er ist auf ihrer Seite sorgfältig gekennzeichnet: Jede Laya-Zahl ist das, was der Router tatsächlich zurückgibt, und die Jev-Zahlen sind von Dritten veröffentlichte Werte, die Convai nie gemessen hat, weil es keinen Zugang zur TypeSafe-API hat. In diesem Vergleich erzielt das geroutete Laya 0,766 gegenüber Jevs 0,727 bei typisierten Entscheidungen, mit einer Post-Temperatur-ECE von 0,081 gegenüber 0,246 und einer p50-Latenz von 32,8 ms gegenüber 236–276 ms auf einer Tesla T4 – ein 7,8-facher Unterschied bei einer Frage. Das ist die Zahl, die man zitieren sollte. Die Zahl „50-mal schneller als Jev“, die sich in sozialen Medien verbreitete, taucht weder in der Dokumentation des Projekts noch in seinen Benchmarks auf, und der eigene veröffentlichte Vergleich des Projekts stützt sie nicht. Jev führt auch dort, wo es führt: Bei Banking77 erzielt Jev 0,870 gegenüber Layas 0,425, weil Layas Optionen sich ein festes Token-Budget teilen und 77 Labels jeweils etwa drei bis vier Token übrig lassen.

Die Form eines echten Deployments ist also ein Entscheidungskopf, der günstig, lokal und schmal ist – der ein Ticket weiterleitet, Dringlichkeit bewertet, ein Ja/Nein-Gate beantwortet –, mit etwas Generativem dahinter für den Teil, der schreiben muss. Das Entscheidungsmodell trifft den typisierten Aufruf in Millisekunden und eskaliert. Die generative Hälfte ist ein anderes Modell auf einer anderen Laufzeitumgebung, und genau hier verdient ein Router seinen Platz: 200+ Modelle hinter einem Schlüssel zum Anbieterlistenpreis ohne Aufschlag, sodass eine Anbieterpreisänderung noch am selben Tag live ist, und automatisches Failover, wenn ein Anbieter während des Laufs schlechter wird. OrcaRouter bietet weder Laya noch Kev noch Jev an – die Qwen3.5-Familie steht auf unserer Modellliste, die Entscheidungsmodelle selbst nicht. Was wir abdecken, ist die generative Hälfte dieses Stacks, also die Hälfte, die Sie bei jeder Anfrage aufrufen, die der Entscheidungskopf eskaliert.

Es gibt noch einen weiteren Grund, die beiden Hälften getrennt zu halten, statt zu einem einzigen Modell zu greifen, das beides übernimmt. Ein lokaler Entscheidungs-Head, der keine Ausgabe-Tokens kostet und nie auf ein Netzwerk zugreift, ist eine andere Art von Abhängigkeit als ein API-Aufruf: Er funktioniert weiter, wenn das Netzwerk ausfällt, und seine Kosten skalieren nicht mit der Menge an Text, die er liest. Das ist die Eigenschaft, für die es sich zu bezahlen lohnt. Alles andere in diesem Artikel dreht sich darum, wie viel Sie dafür an Genauigkeit, Speicher und Wartung zahlen.

Wer sollte es ausführen, und wer sollte warten?

Verwende Laya-MLX, wenn du einen Mac der M-Serie hast, deine Entscheidungen eingeschränkt sind – eine Auswahl aus benannten Optionen, eine Rubrikbewertung, ein Ja/Nein-Gate – und du entweder Labels zum Fine-Tuning hast oder bereit bist, Kalibrierungstemperaturen selbst anzupassen. Die Installation erfolgt mit einem einzigen Befehl, die Mindestspeicheranforderung liegt unter einem Gigabyte, und die Arbeit an der Wiedergabetreue wurde bereits erledigt und veröffentlicht.

Warten Sie, wenn Sie Upstream-Support-Garantien benötigen, wenn Sie ein langlebiges Sidecar betreiben und die Frage des Speicherwachstums lieber in einem Release als in einem offenen Issue geklärt sehen möchten, oder wenn Ihre Fragen offen sind. Ein nicht-autoregressiver Encoder, der auf „Was soll ich als Nächstes tun?“ antwortet, ist keine kleinere Version eines LLM, das dasselbe tut. Er ist ein anderes Instrument, und er liest sich nur dann gut, wenn die Frage bereits für ihn geformt ist.