Laya на Apple Silicon: что даёт порт MLX и чего он не даёт

Laya — это модель принятия решений, которая никогда не пишет ни одного предложения. Convai Innovations выложила её веса на Hugging Face 18 сентября 2026 года, и уже на следующий день разработчик под ником mizorewww опубликовал Laya-MLX — независимый порт, который запускает все три контрольные точки Laya нативно на Apple Silicon через MLX, без PyTorch, без среды выполнения Transformers и без обращений к облаку. Этот порт сообщает медианное время 13,42 мс для одного короткого вопроса на английском на контрольной точке на 421M, 7,39 мс на многоязычной на 322M и ноль выходных токенов — на M3 Max. Тем временем Kev, другое открытое семейство, преследующее ту же идею типизированных решений, построено на Qwen3.5-4B-Base и требовало целого второго бэкенда, прежде чем стало пригодным для использования на Mac, потому что в PyTorch нет ядер для его слоёв DeltaNet на GPU от Apple. Два проекта, одна и та же неделя, одна и та же цель — и только один из них портировался чисто. Эта разница и есть суть истории, и это история о среде выполнения, а не о модели.

Причина, по которой это сегодня заслуживает статьи, не в том, что Laya — новинка. А в том, что до 2026-09-19 не существовало способа запустить модель типизированных решений на Mac, не притащив за собой стек PyTorch, и вопрос, который на самом деле есть у читателя — смогу ли я запустить это на своём ноутбуке и от чего мне придётся отказаться — наконец получил измеримый ответ. Так что этот материал о пути обслуживания, стоящих за ним числах и местах, где числа перестают означать то, чем кажутся.

Сначала о том, чем Laya не является.

Laya — не LLM. Она неавторегрессионна: один двунаправленный прямой проход по состоянию вместе с вашими вопросами — и на выходе типизированные ответы. Здесь нет посимвольного декодирования токен за токеном, нет цепочки рассуждений, нет сгенерированного JSON, который нужно разбирать, и нет выходных токенов, за которые надо платить. Три примитива ответа — choice (выбрать один из N именованных вариантов), score (уровень порядковой шкалы) и noul (калиброванная вероятность того, что нечто истинно).

Это важно для того, как вы читаете каждое число в этой статье. Когда порт сообщает 13,42 мс, он сообщает не о 13,42 мс, необходимых для создания нескольких сотен токенов, как это делал бы бенчмарк генерации. Он сообщает обо всей операции. Сравнивать задержку модели принятия решений с количеством токенов в секунду у LLM — это сравнение двух разных задач, и любая статья, которая это делает, — включая вирусный пост «в 50 раз быстрее Jev», распространявшийся после запуска, — делает утверждение, которое лежащая в основе работа не подтверждает.

Что порт на самом деле измерил

Эти цифры — собственные данные автора порта, полученные на указанной машине, и их следует воспринимать вместе с прилагаемой информацией о машине и методике. Laya-MLX измерила их на M3 Max с 40 ядрами GPU и 128 ГиБ унифицированной памяти, при FP16, без учёта загрузки модели.

• Один короткий вопрос, P50 — 13,42 мс на англоязычном чекпоинте 421M, 7,39 мс на многоязычном чекпоинте 322M.

• Один короткий вопрос, P95 — 13,92 мс и 7,79 мс соответственно.

• Пропускная способность при 50 вопросах — 146,8 вопроса в секунду и 395,0 вопросов в секунду.

• Пиковое выделение памяти MLX — 943,6 MiB и 687,6 MiB.

Граница измерения времени — это та часть, которую стоит перечитать дважды. Она включает подготовку промпта, токенизацию, построение тензоров, синхронизированный инференс, калибровку и форматирование результата. Она не включает загрузку модели. Прогон пропускной способности на 50 вопросов использовал batch_size=64, тогда как API по умолчанию использует 16, так что эта пара чисел описывает намеренно пакетную нагрузку, а не то, чего стоит один интерактивный вызов. Разная длина входных данных, разное количество вопросов и разные условия выполнения — всё это влияет на результат. Эти оговорки и есть разница между числом и бенчмарком, и порт сам их указывает.

Нижняя граница памяти — это цифра, на которую большинство читателей будут опираться, и она самая однозначная в этом наборе: менее гигабайта пикового выделения памяти MLX для одного короткого вопроса, на обоих чекпоинтах. Это не утверждение об общем объеме памяти вашего Mac — ОС, ваш терминал и процесс Python соседствуют с ним — но это настоящая нижняя граница, и она примерно на три порядка ниже того, что требуется для локального запуска генеративной модели среднего размера.

Проверка достоверности — более интересный результат.

Быстрый порт, который отвечает иначе, чем модель, которую он портирует, бесполезен, и именно здесь проект проделал работу, которая имеет значение. Все три контрольные точки совпали с выбранным ответом исходной модели на 63 из 63 проверочных вопросов как в FP32, так и в FP16 — 378 из 378 сравнений. Каждая конфигурация также выполнила 100 повторных детерминированных вызовов без измеренного роста активной памяти, и все 36 опубликованных файлов весов прошли строгую удалённую проверку контрольных сумм.

Читайте описание охвата честно: оно измеряет верность на этих фикстурах, а не правильность ответов на любой возможный вопрос. Это говорит о том, что порт верен Laya. Это ничего не говорит о том, права ли Laya.

Независимый, поддерживаемый сообществом и всё ещё не в списке

Порт сообщает о себе это дважды: это независимый MLX-порт, а не официальный релиз Convai Innovations. Обучение и тонкая настройка RLCD остаются в апстриме. Авторство весов принадлежит Convai Innovations. Apache-2.0 с обеих сторон.

То, как к этому относится upstream, говорит больше, чем любой дисклеймер. В README Laya есть список Community Tools, и по состоянию на 2026-09-23 в нём четыре пункта: omp-laya-judge, laya-adk-toolkit, laya-Ascend для NPU Huawei Ascend и laya-apple — среда выполнения для Apple Silicon, использующая GPU MLX и Neural Engine. Этот четвёртый пункт появился через pull request #260, смёрженный 2026-09-23. Порт, о котором идёт речь в этой статье, в число этих четырёх не входит. Теперь список upstream указывает читателям на Apple Silicon совсем другой community-проект — не тот, что вышел первым и имеет бенчмарки.

Остальное расскажет собственный трекер задач Upstream. Задача №50 «Порты на Apple Silicon», открытая 21.09.2026, всё ещё открыта; в тот же день мейнтейнер ответил, что поддержка Apple Silicon отслеживается и что такие общественные порты, как Laya-MLX, изучают возможность нативного инференса на Metal, а затем 23.09.2026 ответил снова фразой, которую стоит процитировать дословно: «Порт MLX по-прежнему поддерживается сообществом». Исправление на стороне PyTorch — MPS autocast и коррекция RoPE в transformers 4.x — было принято как pull request #273, слитый 23.09.2026, причём рецензент в том обсуждении отметил, что его всё ещё нужно объединить с отдельным рефакторингом autocast в #109, который остаётся открытым. А задача №52, открытая 21.09.2026, сообщает о сайдкаре Laya-MLX, который вырос примерно до 21,7 ГБ памяти Metal за несколько часов работы, при этом vmmap относит около 21,4 ГБ к графической подсистеме, а не к куче Python; в ней предлагается ограничить кэш аллокатора и очищать его после каждого инференса, и она всё ещё открыта.

Соберите это вместе, и практический ответ таков: эта среда выполнения не одобрена апстримом, она поддерживается сообществом по собственному описанию мейнтейнера, и единственный вопрос о памяти, который имеет значение для долго работающего сайдкара, решается публично, а не исправляется в релизе.

Могу ли я запустить это на своём ноутбуке, и чем мне придётся пожертвовать?

Установка — это одна команда pip, а порт публикует предварительно сконвертированные веса FP16, так что вам не придётся ничего конвертировать самостоятельно:

pip install laya-mlx

Затем import laya_mlx as laya, agent = laya.load("aac6fef/laya-mlx"), и вызовите agent.predict(state, questions). Требования: Apple Silicon, Python 3.11+ и macOS 14+. Измеренная среда — macOS 27.2, Python 3.12.13 и MLX 0.32.2 — а в заметках о портировании указано, что использованный выпуск MLX поставлялся с wheel-пакетами для macOS 14, 15 и 26, тогда как установщик выбрал пакет для 26, и что более старые поддерживаемые версии macOS не тестировались на этой машине.

Что вы теряете — измерение за измерением:

• FP16 против FP32 — FP16 используется по умолчанию и является источником всех ключевых показателей выше. FP32 обеспечивает более близкое численное соответствие с upstream, и вероятности могут немного различаться при разных точностях, даже если выбранная метка совпадает. BF16 можно запросить, но он не входит в опубликованную матрицу валидации, поэтому считайте его непроверенным.

• Нижняя граница памяти против запаса — пиковое выделение MLX менее 1 ГиБ для короткого вопроса комфортно на любом Mac серии M. Это не утверждение о длительной серверной нагрузке, и issue #52 — причина быть осторожным, если вы планируете запускать это как долгоживущий sidecar, а не как вызов библиотеки.

• Многоязычный против английского — многоязычный чекпоинт на 322M быстрее из двух и тот, который охватывает 100+ языков, но порт намеренно переносит предупреждение из апстрима: английские чекпоинты не заменяют многоязычный. Маршрутизация между ними — это задуманный шаблон, а не просто приятное дополнение.

• Одобрено апстримом или поддерживается сообществом — это второе. Ничто в примечаниях к выпуску апстрима не обещает, что этот порт продолжит работать при изменениях в апстриме.

• Скорость против калибровки — быстрый порт не исправляет бакет калибровки, который поставляется слишком самоуверенным. Upstream ограничивает подобранные температуры до [0.5, 5.0], а поставляемый choice:11+ бакет равен 0.1006, что обострило бы логиты примерно в десять раз и представило бы подбрасывание монеты как почти полную уверенность. Подобранные температуры калибровки существуют не просто так; подгоните их на своих собственных отложенных данных, прежде чем принимать решение на основе вероятности.

Ещё два ограничения стоит учитывать, оба из собственного трекера upstream. action.act_probability сейчас не несёт полезного сигнала — он выдаёт 1,0 почти для любых входных данных, а его сырые логиты при проверке на правильность показали AUROC 0,30 на 396 размеченных решениях (issue #185). Вместо этого ориентируйтесь на confidence, который достигает 0,77 на тех же элементах. А noul вопросы могут следовать своим меткам вариантов, а не состоянию (issue #156) — собственная карточка upstream сообщает уверенное «нет» на явно положительном вводе, особенно сильно на английском чекпоинте. Предлагаемый обходной путь — не обращаться к другой модели, а изменить форму вопроса: задайте его как двухвариантный choice с нейтральными ключами (A/B), а вашу формулировку «да/нет» — как описания вариантов.

Почему одна модель принятия решений переносится без проблем, а другая — нет

Контраст здесь архитектурный, и это самое полезное в этой статье для тех, кто выбирает между двумя семействами.

Основа Laya — ModernBERT-large, двунаправленный энкодер, целиком построенный на внимании. Внимание — это то, в чём стек GPU Apple особенно силён, и именно на этом MLX сосредоточил свои усилия. Поэтому порт — это повторная реализация слоёв, для которых уже существовали быстрые пути: энкодер, слои Transformer в голове принятия решений, голова оценки и голова действий — всё работает в MLX, а токенизация по-прежнему проходит через Rust-токенизатор Hugging Face.

Основой Kev служат базы Qwen3.5, а Qwen3.5 сочетает слои внимания со слоями Gated DeltaNet. DeltaNet рекуррентна и игнорирует маски внимания. Из этого следуют два последствия. Во-первых, каждый вопрос приходится прогонять отдельной строкой, а не делить одну маскированную последовательность, и проект Kev решает это, вычисляя состояние один раз и переиспользуя его кэш для каждой строки. Во-вторых — и именно это особенно болезненно на Mac — для этих слоёв не было ядер PyTorch на GPU от Apple, поэтому PyTorch откатывался к эталонному коду. jaredpalmer/kev-4bВ карточке модели всё ещё прямо указано возникшее ограничение: запрос из пяти вопросов, который на сборке Kev-4B на базе Qwen3 занимает 0,17 с, занимает 0,78 с в bf16 на M5.

Проверьте текущую формулировку, прежде чем цитировать это, потому что она изменилась. README репозитория Kev теперь сообщает, что сервер вместо этого запускает модели Qwen3.5 через MLX на Apple Silicon, и публикует собственные показатели M5 для запроса из пяти вопросов с тремя вариантами ответа в каждом при состоянии объёмом примерно 270 токенов: Kev-4B — 721 мс при новом состоянии и 136 мс при повторном состоянии через кэш префиксов, против 3 302 мс и 847 мс на пути PyTorch bf16 MPS. Kev-0.8B показывает 149 мс и 28 мс. Модели Qwen3 предыдущего поколения по-прежнему работают на обычном PyTorch MPS, и проект называет их хорошим выбором на Mac.

Не превращайте это в результат гонки. Это не очные замеры. 13,42 мс в Laya-MLX — это один короткий вопрос на M3 Max; 721 мс у Kev — это пять вопросов с тремя вариантами ответа в каждом на состоянии размером ~270 токенов на M5. Разное количество вопросов, разное количество вариантов, разная длина состояния, разные машины, разные среды выполнения. Что можно проверить и что стоит сравнивать — это форма задачи, а не победитель: энкодер на чистом внимании портируется на Apple Silicon без боя, а гибридной модели с линейным вниманием понадобился целый второй бэкенд, прежде чем её можно было там использовать.

Для чего на самом деле нужна модель принятия решений

Отбросьте бенчмарки — и честный сценарий применения окажется узким, и проект сам это признаёт: Laya — это быстрая база для специализации, а не движок для принятия решений в режиме zero-shot. На собственном бенчмарке Convai typed-decisions два базовых чекпоинта набирают 0,362 и 0,342 в режиме zero-shot против базовой линии majority-class с 0,461 и случайной с 0,318. Они ниже уровня, который вы получили бы, всегда выбирая самую частую метку. Заявленный показатель 0,766 принадлежит laya-typed-decisions, чекпоинту, дообученному на собственном тренировочном разбиении этого бенчмарка, и его никогда не следует приводить как общую способность.

Опубликованное сравнение Convai с TypeSafe Jev 1.13.0 стоит прочитать именно по этой причине, и на их стороне оно аккуратно помечено: каждая цифра Laya — это то, что маршрутизатор фактически возвращает, а показатели Jev — это сторонние опубликованные числа, которые Convai никогда не измеряла, поскольку у неё нет доступа к API TypeSafe. В этом сравнении Laya с маршрутизацией набирает 0,766 против 0,727 у Jev на типизированных решениях, при ECE после температурной калибровки 0,081 против 0,246 и задержке p50 32,8 мс против 236–276 мс на Tesla T4 — разница в 7,8 раза по одному вопросу. Именно эту цифру и стоит приводить. Цифра «в 50 раз быстрее Jev», распространившаяся в социальных сетях, не встречается ни в документации проекта, ни в его бенчмарках, и опубликованное самим проектом сравнение её не подтверждает. Jev также лидирует там, где лидирует: на Banking77 Jev набирает 0,870 против 0,425 у Laya, потому что варианты Laya делят фиксированный бюджет токенов, а 77 меток оставляют примерно по три–четыре токена на каждую.

Итак, реальное развёртывание устроено так: решающая часть — дешёвая, локальная и узкая — маршрутизация заявки, оценка срочности, ответ на проверку да/нет — а за ней стоит что-то генеративное для той части, где нужно писать. Решающая модель принимает типизированный вызов за миллисекунды и эскалирует. Генеративная половина — это другая модель в другой среде выполнения, и именно здесь роутер оправдывает своё место: 200+ моделей за одним ключом по каталожной цене провайдера без наценки, так что изменение цены поставщиком вступает в силу в тот же день, и автоматическое переключение при сбое, если провайдер деградирует во время выполнения. OrcaRouter не обслуживает Laya и не обслуживает Kev или Jev — семейство Qwen3.5 есть в нашем списке моделей, а сами решающие модели — нет. Мы покрываем генеративную половину этого стека — ту половину, к которой вы обращаетесь при каждом запросе, который эскалирует решающая часть.

Есть ещё одна причина сохранять эти две половины раздельными, а не пытаться использовать одну модель для выполнения обеих задач. Локальная решающая головка, которая не расходует выходные токены и никогда не обращается к сети, — это зависимость иного рода, чем вызов API: она продолжает работать, когда сети нет, и её стоимость не растёт с объёмом читаемого текста. Именно за это свойство и стоит платить. Всё остальное в этой статье — о том, сколько вы за это платите точностью, памятью и поддержкой.

Кто должен запустить это, а кому стоит подождать?

Запускайте Laya-MLX, если вы работаете на Mac серии M, ваши решения ограничены — выбор из именованных вариантов, оценка по рубрике, порог «да/нет» — и у вас либо есть метки для дообучения, либо вы готовы сами подбирать температуры калибровки. Установка выполняется одной командой, минимальный объём памяти — меньше гигабайта, а работа по обеспечению точности уже выполнена и опубликована.

Подождите, если вам нужны гарантии поддержки со стороны апстрима, если вы запускаете долгоживущий сайдкар и хотите, чтобы вопрос о росте памяти был решён в релизе, а не в открытом issue, или если ваши вопросы открытого типа. Неавторегрессионный энкодер, отвечающий на вопрос «что мне делать дальше», — это не уменьшенная версия LLM, которая делает то же самое. Это другой инструмент, и он хорошо читается только тогда, когда вопрос уже сформулирован под него.