Laya sur Apple Silicon : ce que le portage MLX vous apporte, et ce qu’il n’apporte pas

Laya est un modèle de décision qui n'écrit jamais une phrase. Convai Innovations a publié ses poids sur Hugging Face le 18 septembre 2026, et le lendemain, un développeur du nom de mizorewww a publié Laya-MLX — un portage indépendant qui exécute les trois checkpoints Laya nativement sur Apple Silicon via MLX, sans PyTorch, sans runtime Transformers et sans appel au cloud. Ce portage annonce une médiane de 13,42 ms pour une courte question en anglais sur le checkpoint 421M, 7,39 ms sur celui de 322M multilingue, et zéro token de sortie, sur un M3 Max. Pendant ce temps, Kev, l'autre famille ouverte qui poursuit la même idée de décision typée, repose sur Qwen3.5-4B-Base et a nécessité tout un second backend avant d'être utilisable sur un Mac, car PyTorch ne possède aucun kernel pour ses couches DeltaNet sur le GPU d'Apple. Deux projets, la même semaine, le même objectif, et un seul d'entre eux a été porté proprement. Cette différence, c'est toute l'histoire, et c'est une histoire de runtime plutôt qu'une histoire de modèle.

La raison pour laquelle cela vaut un article aujourd’hui n’est pas que Laya soit nouveau. C’est que jusqu’au 2026-09-19, il n’existait aucun moyen d’exécuter un modèle de décision typé sur un Mac sans devoir traîner une pile PyTorch avec soi, et la question qu’un lecteur se pose réellement — puis-je exécuter ceci sur mon ordinateur portable, et à quoi dois-je renoncer — a enfin une réponse mesurable. Cet article porte donc sur le chemin de service, les chiffres qui le sous-tendent, et les endroits où les chiffres cessent de signifier ce qu’ils paraissent signifier.

D'abord, ce que Laya n'est pas

Laya n'est pas un LLM. Il est non autorégressif : une seule passe avant bidirectionnelle sur l'état et vos questions, et il en ressort des réponses typées. Il n'y a pas de décodage jeton par jeton, pas de chaîne de raisonnement, pas de JSON généré à analyser, et pas de jetons de sortie à facturer. Les trois primitives de réponse sont choice (choisir l'une de N options nommées), score (un niveau de barème ordinal) et noul (une probabilité calibrée qu'une chose soit vraie).

Cela a son importance pour la manière dont vous lisez chaque chiffre de cet article. Lorsque le port indique 13,42 ms, il n'indique pas 13,42 ms pour produire quelques centaines de tokens comme le ferait un benchmark de génération. Il rend compte de l'opération entière. Comparer la latence d'un modèle de décision aux tokens par seconde d'un LLM revient à comparer deux tâches différentes, et tout article qui le fait — y compris le post viral « 50x plus rapide que Jev » qui a circulé après le lancement — avance une affirmation que le travail sous-jacent ne soutient pas.

Ce que le port a réellement mesuré

Ces chiffres sont ceux de l’auteur du port, relevés sur une machine précisée, et ils doivent être lus en tenant compte de la machine et de la méthode associées. Laya-MLX les a mesurés sur un M3 Max avec 40 cœurs GPU et 128 GiB de mémoire unifiée, en FP16, chargement du modèle exclu.

• Une courte question, P50 — 13,42 ms sur le checkpoint anglais 421M, 7,39 ms sur le checkpoint multilingue 322M.

• Une brève question, P95 — 13,92 ms et 7,79 ms respectivement.

• Débit de 50 questions — 146,8 questions par seconde et 395,0 questions par seconde.

• Allocation MLX maximale — 943,6 MiB et 687,6 MiB.

La frontière temporelle est la partie qui mérite d'être lue deux fois. Elle comprend la préparation du prompt, la tokenisation, la construction des tenseurs, l'inférence synchronisée, la calibration et la mise en forme des résultats. Elle exclut le chargement du modèle. L'exécution de débit sur 50 questions utilisait batch_size=64, alors que l'API utilise par défaut 16, donc cette paire de nombres décrit une charge de travail délibérément traitée par lots plutôt que ce que coûte un appel interactif unique. Des longueurs d'entrée différentes, des nombres de questions différents et des conditions d'exécution différentes modifient tous le résultat. Ces mises en garde font la différence entre un nombre et un benchmark, et le port les énonce lui-même.

Le plancher mémoire est le chiffre sur lequel la plupart des lecteurs s'appuieront, et c'est le moins ambigu de l'ensemble : moins d'un gigaoctet d'allocation MLX maximale pour une seule question courte, sur les deux checkpoints. Il ne s'agit pas d'une affirmation sur l'empreinte totale de votre Mac — le système d'exploitation, votre terminal et le processus Python coexistent avec elle — mais c'est un véritable plancher, et il est environ trois ordres de grandeur en dessous de ce qu'exige l'exécution locale d'un modèle génératif de taille moyenne.

Le contrôle de fidélité est le résultat le plus intéressant.

Un portage rapide qui répond différemment du modèle qu'il porte ne vaut rien, et c'est là que le projet a fait le travail qui compte. Les trois points de contrôle correspondaient à la réponse sélectionnée en amont sur 63 des 63 questions de validation, en FP32 comme en FP16 — 378 comparaisons sur 378. Chaque configuration a également exécuté 100 appels répétés et déterministes sans croissance mesurée de la mémoire active, et les 36 fichiers de poids publiés ont tous passé une vérification stricte de somme de contrôle à distance.

Lisez la portée honnêtement : cela mesure la fidélité sur ces fixtures, pas l’exactitude sur toutes les questions possibles. Cela vous dit que le portage est fidèle à Laya. Cela ne vous dit rien sur le fait que Laya ait raison.

Indépendant, maintenu par la communauté, et toujours pas sur la liste

Le port se décrit lui-même, et ce deux fois : c'est un port MLX indépendant, et non une version officielle de Convai Innovations. L'entraînement et le fine-tuning RLCD restent en amont. Les poids sont crédités à Convai Innovations. Apache-2.0 des deux côtés.

La façon dont l’amont le traite est plus révélatrice que n’importe quel avertissement. Le README de Laya comporte une liste Community Tools et, au 23 septembre 2026, elle compte quatre entrées : omp-laya-judge, laya-adk-toolkit, laya-Ascend pour les NPU Huawei Ascend, et laya-apple — un runtime Apple Silicon utilisant le GPU MLX et le Neural Engine. Cette quatrième entrée est arrivée via la pull request #260, fusionnée le 23 septembre 2026. Le portage dont traite cet article ne figure pas parmi les quatre. La liste de l’amont oriente désormais les lecteurs Apple Silicon vers un projet communautaire différent de celui qui a été livré en premier et qui dispose des benchmarks.

Le propre gestionnaire de tickets d'Upstream en dit le reste. Le ticket #50, « Portages vers Apple silicon », ouvert le 2026-09-21, est toujours ouvert ; le mainteneur a répondu le jour même que la prise en charge d'Apple Silicon faisait l'objet d'un suivi et que des ports communautaires comme Laya-MLX exploraient l'inférence Metal native, puis a de nouveau répondu le 2026-09-23 par une phrase qui mérite d'être citée mot pour mot : « Le port MLX reste maintenu par la communauté. » Le correctif côté PyTorch — autocast MPS et une correction RoPE de transformers 4.x — a été intégré via la pull request #273, fusionnée le 2026-09-23, un relecteur de ce fil signalant qu'il doit encore être combiné avec la refactorisation distincte de l'autocast dans #109, qui reste ouverte. Et le ticket #52, ouvert le 2026-09-21, rapporte un sidecar Laya-MLX qui a atteint environ 21,7 Go de mémoire Metal après plusieurs heures de fonctionnement, avec vmmap attribuant environ 21,4 Go au sous-système graphique plutôt qu'au tas Python ; il propose de limiter le cache de l'allocateur et de le vider après chaque inférence, et il est toujours ouvert.

Rassemblez tout cela et la réponse pratique est la suivante : ce runtime n’a pas la bénédiction de l’amont, il est maintenu par la communauté selon la propre description de son mainteneur, et la seule question de mémoire qui compte pour un sidecar de longue durée est traitée en public plutôt que corrigée dans une version publiée.

Puis-je l'exécuter sur mon ordinateur portable, et à quoi dois-je renoncer ?

L’installation se fait avec une seule commande pip, et le port publie des poids FP16 préconvertis, donc vous n’avez rien à convertir vous-même :

pip install laya-mlx

Ensuite import laya_mlx as laya, agent = laya.load("aac6fef/laya-mlx"), puis appelez agent.predict(state, questions). Les prérequis sont Apple Silicon, Python 3.11+ et macOS 14+. L'environnement mesuré était macOS 27.2, Python 3.12.13 et MLX 0.32.2 — et le portage note que la version MLX qu'il utilisait fournissait des wheels pour macOS 14, 15 et 26, tandis que l'installeur a sélectionné celle pour la 26, et que les versions macOS prises en charge plus anciennes n'ont pas été testées sur cette machine.

Ce que vous abandonnez, dimension par dimension :

• FP16 par rapport à FP32 — FP16 est la valeur par défaut et la source de tous les chiffres phares ci-dessus. FP32 offre un accord numérique plus proche avec l’amont, et les probabilités peuvent différer légèrement selon les précisions, même lorsque l’étiquette sélectionnée concorde. BF16 peut être demandé, mais ne fait pas partie de la matrice de validation publiée ; considérez-le donc comme non testé.

• Plancher de mémoire ou marge de manœuvre — moins de 1 GiB d’allocation MLX maximale pour une question courte est confortable sur n’importe quel Mac de la gamme M. Ce n’est pas une affirmation sur une charge serveur soutenue, et le problème #52 est la raison d’être prudent si vous prévoyez de l’exécuter comme sidecar de longue durée plutôt que comme appel de bibliothèque.

• Multilingue versus anglais — le checkpoint multilingue de 322 M est le plus rapide des deux et celui qui couvre plus de 100 langues, mais le port reprend délibérément l'avertissement de la source amont : les checkpoints anglais ne remplacent pas celui multilingue. Le routage entre les deux est le schéma prévu, pas un simple agrément.

• Approuvé en amont versus maintenu par la communauté — c’est la seconde. Rien dans les notes de version en amont ne promet que ce port continuera de fonctionner au fil des changements en amont.

• Vitesse contre calibration — un portage rapide ne corrige pas un compartiment de calibration livré avec une confiance excessive. En amont, les températures ajustées sont bornées à [0,5 ; 5,0], et le compartiment choice:11+ livré est à 0,1006, ce qui rendrait les logits environ dix fois plus tranchés et ferait passer un pile ou face pour une quasi-certitude. Les températures de calibration ajustées existent pour une raison ; ajustez-les sur vos propres données mises de côté avant de prendre une décision sur la base d'une probabilité.

Deux autres limites méritent d'être retenues, toutes deux issues du propre système de suivi de tickets de l'amont. action.act_probability ne porte actuellement aucun signal exploitable — il renvoie 1.0 pour presque toutes les entrées, et ses logits bruts, confrontés à l'exactitude, donnaient un AUROC de 0,30 sur 396 décisions étiquetées (ticket #185). Filtrez plutôt sur confidence, qui atteint 0,77 sur les mêmes éléments. Et les questions noul peuvent suivre leurs libellés d'options plutôt que l'état (ticket #156) — la fiche de l'amont elle-même rapporte un « non » confiant sur une entrée clairement positive, et plus fortement encore sur le point de contrôle anglais. La solution de contournement qu'elle suggère n'est pas d'aller chercher un autre modèle, mais de reformuler la question : posez-la comme un choix à deux options choice avec des clés neutres (A/B) et votre formulation oui/non comme descriptions des options.

Pourquoi un modèle de décision se transpose proprement et l’autre non

Le contraste est ici d'ordre architectural, et c'est l'élément le plus utile de cet article pour quiconque doit choisir entre les deux familles.

Le backbone de Laya est ModernBERT-large, un encodeur bidirectionnel construit entièrement à partir d'attention. L'attention est ce pour quoi la stack GPU d'Apple est la meilleure, et c'est ce sur quoi MLX a concentré ses efforts. Le portage est donc une réimplémentation de couches qui disposaient déjà de chemins rapides : l'encodeur, les couches Transformer de la tête de décision, la tête de scoring et la tête d'action tournent tous dans MLX, et la tokenisation passe toujours par le tokenizer Rust de Hugging Face.

Les backbones de Kev sont des bases Qwen3.5, et Qwen3.5 mélange des couches d'attention avec des couches Gated DeltaNet. DeltaNet est récurrent et ignore les masques d'attention. Cela a deux conséquences. Premièrement, chaque question doit être traitée comme sa propre ligne plutôt que de partager une séquence masquée unique, ce que le projet Kev gère en calculant l'état une seule fois et en réutilisant son cache pour chaque ligne. Deuxièmement — et c'est la partie qui coince sur un Mac — il n'existait pas de kernels PyTorch pour ces couches sur le GPU d'Apple, si bien que PyTorch retombait sur du code de référence. jaredpalmer/kev-4bLa fiche modèle porte encore la limite qui en résulte, en termes simples : une requête de cinq questions qui prend 0,17 s sur la version Qwen3 de Kev-4B prend 0,78 s en bf16 sur un M5.

Vérifiez la formulation actuelle avant de citer cela, car elle a changé. Le README du dépôt Kev indique désormais que le serveur exécute les modèles Qwen3.5 via MLX sur Apple Silicon à la place, et publie ses propres chiffres M5 pour une requête à cinq questions avec trois options chacune sur un état d'environ 270 jetons : Kev-4B à 721 ms sur un nouvel état et 136 ms sur un état répété via le cache de préfixe, contre 3 302 ms et 847 ms sur le chemin PyTorch bf16 MPS. Kev-0.8B arrive à 149 ms et 28 ms. Les modèles Qwen3 de génération précédente fonctionnent toujours sur PyTorch MPS standard et le projet les considère comme un excellent choix sur un Mac.

Faites attention à ne pas transformer cela en résultat de course. Ce ne sont pas des mesures en tête-à-tête. Les 13,42 ms de Laya-MLX correspondent à une seule question courte sur un M3 Max ; les 721 ms de Kev correspondent à cinq questions avec trois options chacune sur un état d'environ 270 tokens sur un M5. Nombres de questions différents, nombres d'options différents, longueurs d'état différentes, machines différentes, runtimes différents. Ce qui est vérifiable et mérite d'être comparé, c'est la forme du problème, pas un gagnant : un encodeur à attention pure se transpose vers Apple Silicon sans difficulté, tandis qu'un modèle hybride à attention linéaire a eu besoin de tout un second backend avant d'y être utilisable.

À quoi sert vraiment un modèle de décision

Si l’on met de côté les benchmarks, le cas d’usage honnête est limité, et le projet le dit lui-même : Laya est une base rapide à spécialiser, pas un moteur de décision zero-shot. Sur le benchmark typed-decisions propre à Convai, les deux checkpoints de base obtiennent 0,362 et 0,342 en zero-shot, contre une baseline de classe majoritaire à 0,461 et une baseline aléatoire à 0,318. Ils se situent en dessous de la barre que l’on obtiendrait en répondant toujours par l’étiquette la plus fréquente. Le score phare de 0,766 revient à laya-typed-decisions, le checkpoint fine-tuné sur le split d’entraînement propre à ce benchmark, et il ne devrait jamais être cité comme capacité générale.

La comparaison publiée par Convai face à TypeSafe Jev 1.13.0 vaut la peine d’être lue pour exactement cette raison, et elle est soigneusement étiquetée de son côté : chaque chiffre de Laya correspond à ce que le routeur renvoie réellement, et les chiffres de Jev sont des nombres publiés par des tiers que Convai n’a jamais mesurés, car Convai n’a pas d’accès à l’API TypeSafe. Dans cette comparaison, le Laya routé obtient 0,766 contre 0,727 pour Jev sur les décisions typées, avec un ECE post-température de 0,081 contre 0,246, et une latence p50 de 32,8 ms contre 236–276 ms sur un Tesla T4 — une différence de 7,8x sur une seule question. C’est le chiffre à citer. Le chiffre « 50x plus rapide que Jev » qui a circulé sur les réseaux sociaux n’apparaît ni dans la documentation du projet ni dans ses benchmarks, et la comparaison publiée par le projet lui-même ne le corrobore pas. Jev mène aussi là où il mène : sur Banking77, Jev obtient 0,870 contre 0,425 pour Laya, parce que les options de Laya partagent un budget de tokens fixe et que 77 labels ne laissent qu’environ trois à quatre tokens chacun.

Donc la forme d'un déploiement réel, c'est une tête de décision peu coûteuse, locale et étroite — acheminer un ticket, évaluer l'urgence, répondre à un test oui/non — avec quelque chose de génératif derrière pour la partie qui doit rédiger. Le modèle de décision rend la décision typée en millisecondes et escalade. La moitié générative est un autre modèle sur un autre runtime, et c'est là qu'un routeur gagne sa place : plus de 200 modèles derrière une seule clé, au prix catalogue du fournisseur et sans majoration, si bien qu'un changement de prix d'un fournisseur est répercuté le jour même, et un basculement automatique lorsqu'un fournisseur se dégrade en cours d'exécution. OrcaRouter ne sert pas Laya, et il ne sert pas Kev ni Jev — la famille Qwen3.5 figure sur notre liste de modèles, et les modèles de décision eux-mêmes n'y figurent pas. Ce que nous couvrons, c'est la moitié générative de cette pile, celle que vous appelez à chaque requête que la tête de décision escalade.

Il y a une raison de plus de garder les deux moitiés séparées plutôt que de recourir à un seul modèle pour faire les deux. Une tête de décision locale qui ne coûte aucun jeton de sortie et ne touche jamais à un réseau constitue un type de dépendance différent de celui d'un appel d'API : elle continue de fonctionner lorsque le réseau est indisponible, et son coût n'augmente pas avec la quantité de texte qu'elle lit. C'est la propriété qui vaut qu'on paie pour elle. Tout le reste de cet article porte sur ce que cela vous coûte en fidélité, mémoire et maintenance.

Qui devrait s'en charger, et qui devrait attendre

Lancez Laya-MLX si vous êtes sur un Mac de la série M, que vos décisions sont contraintes — un choix parmi des options nommées, un score de grille d’évaluation, un critère oui/non — et que vous disposez soit d’étiquettes sur lesquelles effectuer un fine-tuning, soit êtes prêt à ajuster vous-même les températures de calibration. L’installation se fait en une seule commande, l’empreinte mémoire minimale est inférieure à un gigaoctet, et le travail de fidélité a été réalisé et publié.

Attendez : si vous avez besoin de garanties de support en amont, si vous exécutez un sidecar de longue durée et voulez que la question de la croissance mémoire soit tranchée dans une version plutôt que dans une issue ouverte, ou si vos questions sont ouvertes. Un encodeur non autorégressif qui répond à « que dois-je faire ensuite » n’est pas une version réduite d’un LLM qui fait la même chose. C’est un instrument différent, et il ne lit bien que lorsque la question est déjà façonnée pour lui.