Оптимизация локального инференса для Apple Silicon

Гибридные вычисления на Apple silicon координируют задачи между передовым интеллектом в облаке и локальной моделью на Mac. Облачные модели справляются с исследованиями и рассуждениями, в то время как локальная модель работает с личными файлами и приложениями на Mac.

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

Lily, наш легковесный локальный движок инференса, создан специально для Apple silicon и Qwen3.6-35B-A3B, с отдельными оптимизациями для предварительного заполнения (prefill) и декодирования. Автономная демоверсия находится в открытом доступе на GitHub.

Введение

Распространенным способом запуска языковых моделей на Mac является MLX — машинное обучение от Apple с открытым исходным кодом для архитектуры Apple silicon. Сопутствующая библиотека MLX-LM добавляет компоненты, необходимые для загрузки и генерации текста с помощью широкого спектра языковых моделей. Вместе MLX и MLX-LM образуют готовый универсальный стек для локального инференса LLM.

Qwen3.6-35B-A3B — это разреженная гибридная модель: в ней используется маршрутизация на основе смеси экспертов (MoE) и объединяются рекуррентные состояния фиксированного размера с полным вниманием. Такой выбор архитектуры снижает объем необходимых вычислений, но при этом создает неравномерную рабочую нагрузку. Токены направляются к различным весам экспертов, а рекуррентные состояния имеют последовательную природу.

MLX-LM уже выбирает оптимизированные ядра для фаз инференса и распространенных форм рабочей нагрузки, но его повторно используемые операции должны поддерживать множество архитектур моделей. Движок, предназначенный именно для Qwen, может специализироваться на уровне модели и времени выполнения, координируя ядра, перемещение данных и планирование с учетом фиксированной структуры модели.

Lily реализует эту специализацию сквозным образом в рамках одного процесса. Среда выполнения Rust загружает чекпоинт модели и управляет состоянием сеанса и циклом генерации, совместимый с OpenAI API чат-комплитов принимает запросы и передает токены потоком, а пользовательские ядра Metal выполняют специфичные для Qwen операции. Ни PyTorch, ни MLX не задействованы в пути выполнения.

Развернуть

Мы измеряем производительность префилла и декодирования по отдельности. Пропускная способность префилла отражает скорость обработки промпта движком; пропускная способность декодирования показывает, как быстро он генерирует выходные токены.

Мы сравниваем Qwen3.6-35B-A3B на одном MacBook Pro с процессором M5 Max, 40‑ядерным GPU и 128 ГБ унифицированной памяти. При десяти длинах промпта для prefill и десяти длинах контекста для decode — от 256 до 128K токенов (K = 1,024) — движок в среднем показывает throughput prefill в 1.22× выше, чем у MLX-LM, и throughput decode в 1.32× выше. При промпте на 4K токенов и контексте decode на 4K токенов custom engine достигает 5,749.9 токенов prefill в секунду и 186.6 токенов decode в секунду по сравнению с 4,737.5 и 140.9 у MLX-LM. В ходе многоходового сеанса эта экономия времени накапливается с каждым дополнительным вызовом модели.

Развернуть

Далее мы объясним, как архитектура Qwen создает возможности для оптимизации под конкретную модель на Apple silicon. Затем мы подробно рассмотрим изменения в префилле и декодировании. Мы также расскажем, в каких случаях дальнейшая оптимизация перестает приносить пользу, и в заключение приведем сквозное сравнение с MLX-LM.

Возможности оптимизации Qwen под Apple silicon

Qwen создает три различные формы рабочей нагрузки

Qwen3.6-35B-A3B содержит 35 миллиардов параметров, но для каждого токена активирует лишь около 3 миллиардов. Маршрутизатор оценивает 256 экспертных подсетей и выбирает восемь наряду с одним общим экспертом, который обрабатывает каждый токен. Такой разреженный дизайн MoE сокращает вычисления, но создает неравномерную работу: эксперты получают различное количество токенов, а каждый токен требует весов из другой комбинации экспертов.

Qwen также объединяет 10 слоев полного внимания с 30 слоями Gated DeltaNet. Эти два типа слоев сохраняют предшествующую информацию по-разному.

В слоях внимания используется внимание с группированными запросами (GQA). У модели Qwen 16 голов запросов и две головы ключ-значение (KV), причем восемь голов запросов разделяют каждую голову KV. Такое разделение делает кэш KV меньше и позволяет повторно использовать кэшированные данные между головами запросов. Кэш по-прежнему сохраняет новые ключи и значения для каждого токена, поэтому каждый шаг декодирования считывает больше данных по мере роста контекста.

Gated DeltaNet, напротив, сжимает предшествующую информацию в рекуррентное состояние фиксированного размера. Обучаемый гейт контролирует объем сохраняемого существующего состояния, в то время как дельта-обновление включает информацию из текущего токена. Модель определяет эти обновления рекуррентно, поэтому каждый токен зависит от состояния, созданного предыдущим токеном. Однако на этапе префилла движок может вычислять те же операции двумя способами. Он может сканировать токены напрямую, продвигая состояние вперед, или реорганизовать обновления в блоки, которые задействуют больше матричных операций и параллелизма на уровне токенов. Какой подход окажется быстрее, зависит от размерностей модели, рабочей нагрузки и аппаратного обеспечения.

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

Apple silicon предоставляет разные пути для разных рабочих нагрузок

Префилл обрабатывает множество строк активации токенов промпта одновременно. Рассматриваемая здесь локальная рабочая нагрузка обычно декодирует по одному запросу за раз (батч 1) и обрабатывает по одной новой строке за шаг. Это различие меняет то, как используются одни и те же веса модели. Префилл может повторно использовать каждый блок весов для сотен или тысяч строк. Декодирование в значительной степени не имеет такой возможности, поскольку каждый новый токен требует еще одного прохода по весам.

Apple silicon размещает центральный и графический процессоры за объединенной памятью — единым пулом физической памяти, доступным обоим компонентам. Это позволяет модели оставаться в памяти без поддержки отдельной копии на GPU, однако не делает перемещение данных бесплатным. Чтение весов и промежуточных значений по-прежнему расходует пропускную способность памяти, в то время как регистры и другие хранилища на кристалле работают быстрее, но обладают гораздо меньшим объемом.

Графический процессор M5 также предоставляет разные вычислительные пути. Линейные слои префилла используют общее умножение матриц на матрицы (GEMM), применяя весовую матрицу ко многим строкам одновременно. Совместимые GEMM могут использовать нейронный ускоритель в каждом ядре GPU с помощью тензорных операций Metal 4. Декодирование батча 1 вместо этого использует общее умножение матриц на векторы (GEMV), применяя одни и те же веса к одной строке. При минимальном повторном использовании весов GEMV ограничено главным образом пропускной способностью памяти и лучше подходит для векторных арифметико-логических устройств (АЛУ) графического процессора, чем для нейронных ускорителей, разработанных для матричных операций с большим повторным использованием данных.

Эти пути выполнения не уникальны для Lily. MLX работает с той же объединенной памятью и выбирает оптимизированные матричные и векторные ядра в соответствии с формой рабочей нагрузки. Реализация Qwen в MLX-LM уже группирует экспертную работу, вычисляет Gated DeltaNet с помощью объединенного рекуррентного ядра Metal и использует внимание с учетом GQA. Эти возможности являются общей отправной точкой для эффективного инференса Qwen на Apple silicon.

Стратегия оптимизации

Более узкая направленность Lily позволяет координировать эти общие пути выполнения с учетом точной архитектуры и размерностей Qwen. Движок использует специализированные для каждой фазы пути графического процессора, сопоставляет рабочие нагрузки экспертов, рекуррентные и связанные с вниманием нагрузки Qwen так, чтобы минимизировать перемещение данных, а также выбирает ядра и макеты на основе измеренной формы рабочей нагрузки. Эта стратегия состоит из трех частей:

1. Согласование пути GPU с фазой инференса. Используйте матрично-ориентированное выполнение, когда префилл может повторно использовать веса по многим строкам, и векторно-ориентированное выполнение, когда декодирование с батчем 1 обрабатывает по одной строке за раз.
2. Отображение структуры Qwen на GPU с минимизацией перемещения данных. Храните веса сжатыми до их использования, организуйте экспертную работу с маршрутизацией без возврата к CPU, сохраняйте состояние Gated DeltaNet на кристалле во время его рекуррентного сканирования и повторно используйте данные KV, общие для внимания с группированными запросами.
3. Адаптация ядер под форму рабочей нагрузки. Внутри каждой фазы выбирайте размеры тайлов, макеты выполнения и пути внимания на основе доступного количества строк, распределения строк по экспертам, размерностей операции и текущей длины контекста.

В следующих разделах объясняются эти решения. Для оптимизаций, оцененных в сопоставимых абляционных тестах на чипе M5 Max, мы оцениваем их эффекты, сравнивая в остальном идентичные конфигурации движка, которые различаются только исследуемой оптимизацией. Поскольку в этих экспериментах сравниваются версии нашего движка друг с другом, они объясняют механизмы, а не декомпозируют итоговые результаты по сравнению с MLX-LM.

Префилл: повторное использование весов и сохранение маршрутизации на GPU

Префилл обнажает множество строк токенов одновременно, но Qwen распределяет эти строки по экспертам неравномерно и обновляет рекуррентное состояние по всей последовательности. Его оптимизации делятся на три группы: организация разреженной работы экспертов вокруг маршрутизируемых строк, удержание сканирования Gated DeltaNet на кристалле и разделение длинных промптов на ограниченные фрагменты.

Развернуть

Оптимизация разреженных вычислений экспертов

Деквантование весов во время умножения матриц

Чекпоинт Qwen3.6-35B-A3B использует групповую аффинную 4-битную квантовую дискретизацию. Каждый вес хранится как 4-битный целочисленный код, в то время как каждая группа из 64 весов совместно использует шкалу и смещение bfloat16, используемые для восстановления его значений. Это уменьшает модель с 35 миллиардами параметров с примерно 70 ГБ весов bfloat16 до чекпоинта размером 19,4 ГБ, что делает практичным хранение модели в памяти Mac.

Тензорная операция Metal 4, используемая для умножения матриц, потребляет операнды bfloat16, а не упакованное 4-битное представление. Перед умножением графический процессор должен восстановить веса в формате bfloat16. Оптимизированная сгруппированная GEMM в Lily выполняет это преобразование по одному небольшому весовому тайлу за раз и удерживает результат в памяти тредгруппы на кристалле ровно столько времени, сколько необходимо для умножения его на маршрутизированные строки активации. Для аккумуляции используется 32-разрядная плавающая точка, а вывод записывается в формате bfloat16. Полный развернутый массив весов никогда не создается в объединенной памяти.

В абляционном тесте деквантование выполняется как отдельная операция: оно расширяет 4-битные веса до массива bfloat16 в объединенной памяти, после чего матричное ядро считывает этот массив обратно. При промпте в 512 токенов перенос деквантования в сгруппированную GEMM увеличил сквозную пропускную способность префилла на 77,4% за счет устранения этой промежуточной записи и чтения.

Отказ от переноса маршрутизации экспертов на CPU

Сгруппированная GEMM требует, чтобы строки активации, назначенные каждому эксперту, хранились вместе. После выбора восьми экспертов на токен гистограмма подсчитывает, сколько назначений досталось каждому эксперту. Префиксное сканирование превращает эти подсчеты в начальные смещения, шаг разброса помещает строки в их экспертные группы, а блок-карпа выводит список матричных блоков фиксированного размера, которые должна обработать сгруппированная GEMM.

Оптимизированный путь сохраняет всю эту последовательность в одном буфере команд (упорядоченном пакете операций GPU) для каждого фрагмента промпта. В варианте с абляцией процесс приостанавливается, чтобы процессор мог проверить промежуточные результаты маршрутизации и отправить следующую операцию. Сохранение гистограммы и префиксного сканирования на GPU добавляет два ядра, но устраняет синхронизацию между CPU и GPU внутри каждого слоя MoE.

При промпте длиной в 512 токенов включение маршрутизации на GPU увеличило производительность сквозного префилла на 89%. Это также демонстрирует, почему один лишь подсчет ядер может вводить в заблуждение: более быстрый маршрут запускает больше ядер, но никогда не ждет процессор внутри слоя.

Согласование размера тайла с нагрузкой экспертов

При промпте длиной в 2K токенов направление каждого токена к восьми из 256 экспертов создает 16 384 назначения токен-эксперт, или в среднем 64 строки активации на эксперта. Фактическое распределение неравномерно: некоторые эксперты получают много строк, в то время как другие — лишь несколько.

Сгруппированная GEMM делит вывод каждого эксперта на тайлы — небольшие прямоугольные блоки результата умножения матриц. Каждый тайл назначается одной тредгруппе GPU. На графических процессорах Apple silicon тредгруппа содержит одну или несколько симдгрупп, каждая из которых состоит из 32 тредов, выполняющих инструкции синхронно.

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

В абляционном тесте размер тайла фиксируется на уровне 16 строк. По сравнению с этим контрольным вариантом включение тайла на 32 строки с четырьмя симдгруппами улучшило сквозной префилл на 13,2% при длине 2K токенов.

Сохранение рекуррентного состояния на кристалле

Во время префилла каждый слой Gated DeltaNet сканирует промпт по порядку, продвигая вперед свое рекуррентное состояние. При отключенном размещении в регистрах в абляционном тесте используется блочное сканирование. При длине промпта в 2K токенов этот путь перемещает 256 МиБ (мебибайт) состояния на один слой и многократно останавливает сотрудничающие треды на барьерах — точках синхронизации, где все участвующие треды должны дожидаться друг друга.

Рекуррентное состояние представляет собой матрицу. Оптимизированное ядро назначает каждый столбец одной симдгруппе. Симдгруппа распределяет столбец между своими тредами, единожды загружает его в их регистры и проводит состояние через все сканирование. Треды обмениваются промежуточными результатами через операции симдгрупп, а не через память тредгруппы (память на кристалле, общую для всей тредгруппы). Завершенное состояние записывается обратно только после завершения сканирования.

Для состояния и его гейта используется 32-разрядный формат с плавающей точкой, поскольку небольшие погрешности округления накапливаются при последовательных обновлениях. Активации запросов и ключей остаются в формате bfloat16.

При длине промпта в 2K токенов включение сканирования в регистрах повысило производительность префилла в целом на 5,6%. На экспертные GEMM приходилось около 90% времени префилла. Последовательное сканирование не выделяет достаточно переиспользуемой матричной работы, чтобы извлечь выгоду из нейронных ускорителей.

Ограничение временной памяти с помощью разбиения промпта на фрагменты

Среда выполнения обрабатывает длинный промпт как последовательность ограниченных фрагментов, а не хранит в памяти временные данные для каждого токена промпта одновременно. Веса модели остаются в объединенной памяти, в то время как рекуррентное состояние и кэш KV переносят контекст от одного фрагмента к другому. Никакой предшествующий контекст не отбрасывается.

Без разбиения на фрагменты массивы временной активации растут вместе с полным промптом и конкурируют за объединенную память с весами модели, рекуррентным состоянием и кэшем KV. Разбиение сохраняет активными временные значения только одного сегмента за раз, после чего освобождает или повторно использует это хранилище перед обработкой следующего сегмента. Это ограничивает пиковый объем рабочей памяти и позволяет движку обрабатывать более длинные промпты без изменения вывода модели.

Префилл с разбиением на фрагменты популярен во многих движках и имеет решающее значение для обслуживания длинных многошаговых траекторий в этих условиях с ограниченной памятью. Общее время префилла для слоев внимания остается квадратичным по отношению к длине промпта с небольшими дополнительными накладными расходами из-за повторяющихся загрузок KV для более ранних фрагментов.

Декодирование: минимизация перемещаемых байтов на один токен

Декодирование с батчем 1 обрабатывает по одной новой строке за раз. При минимальном повторном использовании весов его производительность зависит главным образом от того, сколько байт движок перемещает для каждого токена. Изменения в декодировании делятся на четыре группы: оптимизация однострочного пути весов, удержание каждого шага на GPU, сокращение трафика промежуточных данных и состояний, а также эффективное чтение кэша внимания.

Развернуть

Оптимизация однострочного пути весов

MLX уже распределяет однострочные задачи по специализированным матрично-векторным ядрам. Поскольку Lily не использует MLX, специализированная среда выполнения должна обеспечивать ту же базовую стратегию. Наша строка-параллельная GEMV разработана для одной строки активации. Симдгруппа совместно работает над выходными данными, параллельно считывая различные части весовой матрицы.

Отказ от переноса шагов декодирования на CPU

Отказ от переноса передачи токенов на CPU

Каждый шаг декодирования завершается выбором следующего токена; следующий шаг начинается с этого токена в качестве ввода. Передача выбранного токена на центральный процессор и обратно на графический добавляет точку синхронизации к каждому токену. Вместо этого наша среда выполнения чередует два буфера команд и два слота токенов, размещенных в памяти GPU. Графический процессор выбирает токен с наивысшим баллом и записывает его ID напрямую во входной слот для следующего шага декодирования, в то время как процессор подготавливает последующую работу.

Параллельное выполнение независимых задач на GPU

За один записанный шаг декодирования батча 1 генерация одного токена вызвала запуск 795 ядер GPU. Их зависимости образовали 555 последовательных этапов, позволяя некоторым ядрам выполняться параллельно. Тем не менее режим серийного выполнения Metal запускал каждое ядро по порядку.

Оптимизированный путь декодирования записывает фактические зависимости данных во время параллельного прохода Metal. Независимые запуски ядер могут выполняться одновременно, если это позволяют ресурсы GPU. Барьер вставляется только тогда, когда для последующей работы требуется более ранний результат.

Сокращение трафика промежуточных данных и состояний

Отдельные ядра часто создают промежуточные результаты: одно ядро записывает временный результат в память, а следующее считывает его обратно. Оптимизированный путь декодирования объединяет четыре цепочки: две проекции ввода экспертов с их активированными гейтами; проекцию вывода эксперта с его оценкой маршрутизации и результатом общего эксперта; подготовку запроса и ключа перед вниманием; а также рекуррентное обновление с его нормализацией. Каждое объединенное ядро сохраняет временные значения в регистрах, а не пересылает их через память.

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

Эффективное чтение кэша внимания

Коалесцирование чтений кэша внимания

Внимание считывает ключи и значения из кэша KV во время каждого шага декодирования. В абляционном тесте соседние треды GPU не всегда запрашивают соседние байты, вынуждая систему памяти обслуживать больше раздельных транзакций. Включение коалесцированных загрузок заставляет смежные треды запрашивать смежные байты, чтобы аппаратное обеспечение могло объединить их чтения.

В конфигурации bfloat16 коалесцирование увеличило пропускную способность ключей с 33,8 до 47,9 ГБ/с, значений — с 42,0 до 61,8 ГБ/с и улучшило сквозное декодирование на 2,1% при контексте в 3840 токенов.

Упаковка голов запросов для повторного использования строк KV

Внимание с группированными запросами позволяет восьми головам запросов совместно использовать одну голову KV. В ходе абляции каждая голова запроса выполняется в отдельной симдгруппе, поэтому все восемь независимо запрашивают одну и ту же кэшированную строку KV. Оптимизированное ядро объединяет четыре головы запросов в одну тредгруппу, которая загружает каждую строку KV один раз и многократно использует ее в четырех вычислениях внимания. Вторая тредгруппа обрабатывает оставшиеся четыре головы.

Эта техника, обычно называемая упаковкой GQA, выполняет ту же арифметику и выдает идентичные выходные байты, одновременно сокращая восемь независимых запросов KV до двух общих загрузок. По сравнению с распакованным вариантом абляции она увеличила сквозную пропускную способность декодирования на 23,8% при контексте в 32K токенов.

Смена макетов внимания при длинном контексте

Каждый шаг декодирования в слое с полным вниманием сканирует существующий кэш KV. Макет с фиксированными блоками разделяет этот кэш на равные части, которые графический процессор может обрабатывать параллельно. Дополнительное планирование не оправдывает себя, когда кэш мал, но макет с фиксированными блоками распределяет работу более равномерно по мере роста контекста.

Для этой модели среда выполнения сохраняет общий путь внимания для длин менее 32K токенов и использует путь с фиксированными блоками при длине 32K или более. Переключение происходит, когда каждая голова имеет 256 значений, а восемь голов запросов разделяют одну голову KV; другие формы остаются на общем пути. Абляционный тест отключает это переключение и всегда использует общий путь. Включение маршрута с фиксированными блоками улучшило сквозное декодирование на 7,7% при 32K, на 27,4% при 64K и на 40,2% при 128K.

Пределы дальнейшей оптимизации

Некоторые изменения улучшили изолированную операцию, но не улучшили сквозной инференс.

Спекулятивное декодирование, использующее меньшую модель для предложения токенов с целью их проверки полной моделью, замедлило декодирование батча 1 на 18%. Проверка обрабатывала группы из двух-пяти строк (неэффективная форма для этого оборудования), и строки часто выбирали разных экспертов, что увеличивало объем считываемых данных весов экспертов. Сокращение выходного словаря автора черновика улучшило его пропускную способность на 4,7–5,1%, но не ускорило цикл спекуляций в целом. Этот результат специфичен для рабочей нагрузки: наше пакетное развертывание Qwen на платформе Blackwell использует спекулятивное декодирование в других условиях.

Другие эксперименты включали сокращение числа запусков GPU, совмещение целых фаз, использование более крупных тайлов префилла, применение более широкого слияния, ускорение маршрутизатора и объединение выходной проекции с выбором токена. Ни одно из этих изменений не улучшило цикл инференса в целом.

Измерения аппаратных лимитов также показали небольшой остающийся запас производительности в основных операциях префилла и декодирования. Модели MoE GEMM и GEMV достигли 97,9% и 90,3% от максимально возможных устойчивых скоростей чтения весов для своих паттернов доступа. Удаление арифметических операций из разреженной GEMV изменило пропускную способность всего на 0,2%, подтвердив, что узким местом являются чтения весов, а не вычисления. Умножение матриц на этапе префилла аналогично достигло 93% от теоретического предела матрицы в изоляции и 80–86% внутри протестированных моделей.

Сквозная производительность

В сквозном сравнении загружаются идентичные 4-битные контрольные чекпоинты в обоих движках и выполняется по одному запросу за раз на одном 40-ядерном чипе M5 Max с 128 ГБ памяти. Внутри каждого раунда два движка работают в чередующемся порядке, чтобы снизить погрешность из-за фоновой нагрузки и изменений температуры чипа. Мы сравниваем результаты с самым быстрым путем прямой генерации MLX-LM, а не с его сервером, поэтому измерение сосредоточено на выполнении модели, а не на накладных расходах на обслуживании.

Анализ охватывает десять вариантов длины промпта для префилла и десять вариантов длины контекста для декодирования, от 256 до 128K токенов. Пропускная способность префилла сначала растет по мере того, как движок распределяет фиксированные затраты на настройку между большим количеством токенов. Префилл достигает пика примерно при промпте в 4K токенов, а затем падает, поскольку десять слоев полного внимания выполняют больше работы по мере роста промпта. Декодирование остается практически неизменным на коротких контекстах и снижается, когда чтение растущего кэша KV становится существенным. Пользовательский движок работает быстрее при любой зарегистрированной длине.

Поскольку специализированное выполнение может изменять порядок операций с плавающей точкой, мы также проверили числовую согласованность с MLX-LM. При сравнении с принудительным учителем оба движка предсказывали следующий токен из одного и того же префикса-образца в каждой из 192 позиций, предотвращая влияние ранних различий на последующие входные данные. Перплексия Lily оказалась всего на 0,04% выше, и движок выбрал тот же токен с наивысшим рангом в 96,35% протестированных позиций.

Развернуть

Создано для локальной платформы

Apple silicon — это не уменьшенный датацентровый GPU. Это полноценная локальная платформа инференса с собственными аппаратными и программными характеристиками. Объединенная память дает одному узлу очень высокий предел емкости для хранения модели и состояния. Нейронные ускорители M5 берут на себя плотные матричные вычисления на этапе префилла. Векторные АЛУ обрабатывают оставшуюся часть в процессе декодирования, которая ограничена пропускной способностью памяти и характеризуется низкой степенью повторного использования данных.

Qwen открывает дополнительные возможности для специализации: сохранение маршрутизации экспертов и рекуррентного состояния на GPU, устранение ненужных промежуточных данных, параллельное выполнение независимых задач, повторное использование общих данных KV и адаптация ядер под форму рабочей нагрузки.

Благодаря оптимизации под конкретную модель и платформу один Mac может эффективно запускать крупную разреженную модель. В будущем планируется расширить поддержку на другие модели, чипы и сценарии обслуживания, а также превратить опробованные здесь механизмы для одной конфигурации в более общую политику времени выполнения.

Более общий принцип заключается в том, чтобы согласовать движок как с архитектурой модели, так и с конкретными путями вычислений и памяти оборудования. По мере эволюции передовых открытых моделей и аппаратного обеспечения высокопроизводительный локальный инференс будет все больше зависеть от движков, адаптированных к обоим компонентам, а не абстрагирующихся от их различий.

Цитата

@online{perplexity2026OptimizingOnDeviceInferenceForAppleSilicon,
  author = {{Perplexity} and Yibo Wu and Lequn Chen and Kevin Hu and Phi Hoang and Claire Beamer and Jeremy Yang and Denis Yarats},
  title = {{Optimizing on-device inference for Apple Silicon}},
  date = {2026-09-01},
  url = {https://www.perplexity.ai/hub/blog/optimizing-on-device-inference-for-apple-silicon}
}