Perplexity відкрила вихідний код Lily: рушія інференсу на Rust + Metal для Qwen3.6-35B-A3B на Apple Silicon

Perplexity відкрила вихідний код Lily, локального рушія інференсу, що лежить в основі Hybrid Compute у Perplexity Computer. Це середовище виконання в одному процесі: шар Rust завантажує чекпойнт і керує циклом генерації, API потокової передачі chat-completions, сумісний з OpenAI, передає токени, а написані вручну Metal-ядра виконують модель. Ні PyTorch, ні MLX не беруть участі у виконанні. Lily навмисно вузькоспеціалізована: одна модель, Qwen3.6-35B-A3B, на одному сімействі апаратного забезпечення, і саме ця вузька спеціалізація є аргументом на користь продуктивності.

Чи придатна вона до розгортання? Так. Автономна демонстраційна версія доступна публічно в репозиторії pplx-garden. Це сервер інференсу на Rust і Metal, який забезпечує жадібну генерацію тексту через мінімальний HTTP API, сумісний з OpenAI. 4-бітний чекпойнт займає 19,4 ГБ, тож Mac на Apple silicon із 32 ГБ або більше об’єднаної пам’яті є реалістичним мінімумом; у продуктивному продукті Perplexity Hybrid Compute зазначено macOS 15+, мінімум 24 ГБ і 32 ГБ для найкращих результатів.

Навіщо взагалі спеціалізація?

Стандартний стек для Mac — це MLX у поєднанні з MLX-LM, який уже містить реалізацію Qwen із груповою роботою експертів, об’єднаним рекурентним Metal-ядром і механізмом уваги, що враховує GQA. Але його операції мають залишатися придатними для повторного використання в різних архітектурах. Lily відмовляється від цього й об’єднує структуру моделі, плани виконання та вибір ядер в одному середовищі виконання.

Три форми робочого навантаження

Qwen3.6-35B-A3B зберігає 35 млрд параметрів і активує приблизно 3 млрд для кожного токена. Маршрутизатор оцінює 256 експертів і обирає вісім із них, а також одного спільного експерта, який обробляє кожен токен. Модель також поєднує 10 шарів повної уваги, що використовують увагу з групуванням запитів (16 голів запитів, дві KV-голови), із 30 шарами Gated DeltaNet. У результаті виникають три закономірності: нерівномірні групи експертів, увага до KV-кешу, що зростає, і рекурентність фіксованого розміру.

Prefill: зберігати ваги упакованими, маршрутизацію виконувати на GPU

У чекпойнті використовується групова афінна 4-бітна квантизація: кожна група з 64 ваг має спільні масштаб і зсув у форматі bfloat16, що стискає приблизно 70 ГБ ваг bfloat16 до 19,4 ГБ. Тензорні операції Metal 4 працюють із bfloat16, тому спочатку ваги потрібно відновити. Lily робить це по одному тайлу безпосередньо всередині групової GEMM-операції, зберігаючи результати в пам’яті групи потоків і накопичуючи їх у FP32, тож розгорнутий масив ніколи не потрапляє до об’єднаної пам’яті. В абляційному дослідженні Perplexity це об’єднання підвищило загальну продуктивність prefill на 77,4% для запиту довжиною 512 токенів.

Зберігання гістограми маршрутизації, префіксного сканування, scatter-операції та карти блоків в одному буфері команд GPU додало 89% для 512 токенів, усунувши синхронізацію з CPU всередині кожного MoE-шару. Перехід від тайлів із 16 рядків до тайлів із 32 рядків із чотирма simd-групами додав 13,2% для 2K; сканування Gated DeltaNet із розміщенням у регістрах додало 5,6%. На GEMM-операції експертів припадає приблизно 90% часу prefill. Довгі запити обробляються обмеженими за розміром фрагментами, щоб тимчасові активації не конкурували за пам’ять із вагами та кешем.

Decode: мінімізувати кількість байтів, переміщуваних для кожного токена

Під час decode із розміром пакета 1 повторне використання ваг майже відсутнє, тому пропускна здатність визначає верхню межу. Один записаний крок запускав 795 ядер, що формували 555 послідовних етапів; Lily фіксує фактичні залежності в паралельному проході Metal, щоб незалежні ядра могли виконуватися одночасно. Вибраний токен записується безпосередньо в GPU-слот вхідних даних для наступного кроку, що усуває круговий обмін із CPU для кожного токена, а чотири ланцюжки ядер об’єднано, щоб зберігати проміжні результати в регістрах.

Коалесцентне читання кешу підвищило пропускну здатність для ключів із 33,8 до 47,9 ГБ/с, а для значень — із 42,0 до 61,8 ГБ/с. Упакування GQA, за якого чотири голови запитів спільно використовують одну групу потоків, тож кожен рядок KV завантажується один раз, покращило decode на 23,8% при 32K. Розкладка уваги з фіксованими блоками при 32K і більше покращила decode на 7,7% при 32K, 27,4% при 64K і 40,2% при 128K.

Результати

На одному M5 Max із 40 ядрами та 128 ГБ пам’яті, з розміром пакета 1, під час завантаження ідентичних 4-бітних байтів чекпойнта та порівняння з найшвидшим шляхом прямої генерації MLX-LM для десяти довжин від 256 до 128K токенів Lily у середньому показала 4 156 токенів/с prefill проти 3 388 (1,23x) і 170,0 токенів/с decode проти 126,4 (1,35x). Для запиту на 4K і контексту 4K вона досягла 5 749,9 і 186,6 токенів/с проти 4 737,5 і 140,9, а також була швидшою в кожній зафіксованій точці: 1,12–1,42x для prefill і 1,31–1,37x для decode. Перевірка з примусом учителя на 192 позиціях показала, що перплексія Lily була на 0,04% вищою, а той самий токен із найвищим рейтингом обирався у 96,35% випадків.

Основні висновки

• Lily — рушій на Rust + Metal для Qwen3.6-35B-A3B на Apple silicon, без PyTorch або MLX у ланцюжку виконання.
• У середньому показує 1,23x продуктивності MLX-LM для prefill і 1,35x для decode на M5 Max із 40 ядрами та 128 ГБ пам’яті.
• Найбільші переваги для prefill: маршрутизація експертів, що виконується на GPU (+89%), і деквантизація, об’єднана з груповою GEMM-операцією (+77,4%).
• Найбільші переваги для decode: упакування GQA (+23,8% при 32K) і увага з фіксованими блоками (+40,2% при 128K).

---

Ознайомтеся з технічними деталями тут і репозиторієм GitHub тут. Також підписуйтеся на нас у Twitter і не забудьте приєднатися до нашого субреддіту про машинне навчання зі 150k+ учасників та підписатися на нашу розсилку. Стривайте! Ви є в Telegram? тепер ви також можете приєднатися до нас у Telegram.

Потрібно співпрацювати з нами для просування вашого репозиторію GitHub, сторінки Hugging Face, випуску продукту, вебінару тощо? Зв’яжіться з нами