В мире локального запуска больших языковых моделей (LLM) на устройствах Apple часто возникает компромисс между удобством использования и предельной производительностью. Стандартным решением долгое время оставалась связка фреймворка MLX и библиотеки MLX-LM, которые обеспечивают отличную совместимость и относительно простую настройку. Однако Perplexity, известная своими инновациями в области поисковых AI-ассистентов, решила пойти другим путем. Компания открыла исходный код своего внутреннего движка вывода под названием Lily, который лежит в основе функции Hybrid Compute в Perplexity Computer. Это не просто еще одна обертка над существующими инструментами, а глубоко специализированная система, построенная с нуля на Rust и Metal, предназначенная исключительно для одной модели — Qwen3.6-35B-A3B — и одного семейства процессоров. В этой статье мы подробно разберем, как устроен Lily, почему он показывает результаты, превосходящие стандартные решения, и что это значит для разработчиков, желающих запускать мощные модели локально на Mac.
01Философия узкой специализации: Почему отказ от универсальности?
Главный аргумент Perplexity в пользу создания Lily заключается в том, что универсальность часто является врагом производительности. Стандартный стек для Mac, состоящий из MLX и MLX-LM, спроектирован так, чтобы работать с множеством архитектур моделей. Это требует компромиссов: операции должны быть абстрактными и переиспользуемыми, что не позволяет оптимизировать каждый такт процессора под конкретную структуру нейросети. Lily же сознательно жертвует универсальностью ради скорости. Он заточен под одну модель (Qwen3.6-35B-A3B) и одно железо (Apple Silicon). В пути выполнения модели нет ни PyTorch, ни MLX. Вместо этого Rust-слой загружает чекпоинт и управляет циклом генерации, API, совместимый с OpenAI, потоково передает токены, а ручная реализация ядер Metal (Metal kernels) выполняет вычисления модели.
Такой подход позволяет разработчикам контролировать каждый аспект выполнения: от структуры модели и планов выполнения до выбора конкретных ядер. Это особенно важно для современных архитектур, таких как MoE (Mixture of Experts), где маршрутизация запросов к разным экспертам может стать узким местом. Lily интегрирует эти процессы непосредственно в GPU-командные буферы, устраняя задержки, связанные с синхронизацией между CPU и GPU. Для энтузиастов локального AI это означает, что при наличии соответствующего железа можно достичь производительности, близкой к теоретическому максимуму чипа, что ранее было доступно только крупным облачным провайдерам.
02Архитектура Qwen3.6-35B-A3B: Три формы рабочей нагрузки
Чтобы понять, как Lily достигает своих рекордных скоростей, необходимо разобраться в архитектуре модели Qwen3.6-35B-A3B. Эта модель является гибридной, сочетающей в себе несколько передовых техник. Она хранит 35 миллиардов параметров, но активирует примерно 3 миллиарда на каждый токен. Архитектура включает в себя маршрутизатор, который оценивает множество экспертов и выбирает лишь малую их часть, а также один общий эксперт, который обрабатывает каждый токен. Кроме того, модель смешивает слои с полным вниманием (full-attention), использующие группированное запросное внимание (Grouped-Query Attention, GQA), с большим количеством слоев Gated DeltaNet, которые представляют собой форму рекуррентной нейронной сети.
Такая сложная структура порождает три различных паттерна рабочей нагрузки, которые Lily должен эффективно обрабатывать:
- Неравномерные группы экспертов: Из-за выбора малого числа экспертов из большого пула распределение вычислительной нагрузки может быть неравномерным, что требует динамического планирования ресурсов.
- Внимание над растущим кэшем KV: Слои с полным вниманием требуют хранения и обработки ключей и значений (KV-cache), размер которых растет с каждым новым токеном.
- Рекурренция фиксированного размера: Слои Gated DeltaNet используют фиксированный размер состояния, что позволяет оптимизировать память иначе, чем при работе с растущим кэшем.
Лили должен управлять этими тремя паттернами одновременно, минимизируя перемещение данных между памятью и вычислительными ядрами. Именно здесь вступают в игру специализированные оптимизации, о которых пойдет речь ниже.
03Фаза Prefill: Удержание весов в GPU и слияние операций
Фаза prefill (предварительной обработки) отвечает за обработку входного промпта. В этот момент модель должна прочитать весь контекст и подготовить состояние для генерации. Основной вызов здесь заключается в том, что чекпоинт модели использует квантование 4-bit с групповой аффинной трансформацией. Каждая группа весов разделяет масштаб (scale) и смещение (bias) в формате bfloat16. Это сжимает весы с примерно 70 ГБ в формате bfloat16 до 19.4 ГБ. Однако операции Metal 4 требуют данных в формате bfloat16, поэтому веса необходимо реконструировать (декомпрессировать) перед использованием.
Стандартный подход мог бы загрузить веса в память, реконструировать их, а затем передать в вычислительное ядро. Lily делает иначе: он реконструирует веса по одному тайлу (блоку) непосредственно внутри сгруппированного умножения матриц (grouped GEMM). Результаты накапливаются в памяти threadgroup, а затем суммируются в формате FP32. Благодаря этому расширенный массив весов никогда не покидает пределы GPU и не загружает унифицированную память. В абляционных исследованиях Perplexity эта оптимизация повысила общую скорость prefill на 77,4% при промпте длиной 512 токенов.
Еще одна критическая оптимизация касается маршрутизации экспертов. Lily хра
Источник: MarkTechPost ↗