Perplexity публикува изходния код на Lily: инференс енджин на Rust + Metal за Qwen3.6-35B-A3B върху Apple Silicon

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

Може ли да бъде внедрен? Да. Самостоятелна демонстрация е публично достъпна в хранилището pplx-garden. Това е inference сървър на Rust и Metal, предлагащ алчно генериране на текст чрез минимален HTTP API, съвместим с OpenAI. Чекпойнтът в 4-битов формат е 19,4 GB, така че Mac с Apple silicon и поне 32 GB унифицирана памет е реалистичният минимум; предлаганият от Perplexity продукт Hybrid Compute посочва macOS 15+, минимум 24 GB и 32 GB за най-добри резултати.

Защо изобщо да се специализира?

Стандартният стек за Mac е MLX плюс MLX-LM, който вече включва реализация на Qwen с работа с групирани експерти, слято рекурентно Metal ядро и внимание, съобразено с GQA. Но неговите операции трябва да останат повторно използваеми между различни архитектури. Lily се отказва от това и поставя структурата на модела, плановете за изпълнение и избора на ядра в една среда за изпълнение.

Три типа натоварване

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

Предварително запълване: съхранявайте теглата пакетирани, поддържайте маршрутизацията на GPU

Чекпойнтът използва групова афинна 4-битова квантизация, при която всяка група от 64 тегла споделя bfloat16 мащабиращ коефициент и отместване; така около 70 GB bfloat16 тегла се компресират до 19,4 GB. Тензорните операции на Metal 4 използват bfloat16, така че теглата първо трябва да бъдат възстановени. Lily прави това плочка по плочка вътре в групираното GEMM, съхранява резултатите в паметта на нишковата група и акумулира във FP32, така че разширеният масив никога не достига до унифицираната памет. При аблационния тест на Perplexity това сливане повиши цялостната производителност при предварително запълване с 77,4% при промпт от 512 токена.

Поддържането на хистограмата на маршрутизацията, префиксното сканиране, разпръскването и картата на блоковете в един GPU команден буфер добави 89% при 512 токена, като премахна синхронизацията с CPU във всеки MoE слой. Преминаването от плочки с 16 реда към плочки с 32 реда и четири SIMD групи добави 13,2% при 2K; сканиране на Gated DeltaNet, разположено в регистрите, добави 5,6%. GEMM операциите на експертите заемат приблизително 90% от времето за предварително запълване. Дългите промптове се изпълняват на ограничени по размер части, така че временните активации да не се конкурират с теглата и кеша за памет.

Декодиране: минимизирайте прехвърляните байтове на токен

Декодирането с размер на пакета 1 почти не използва повторно теглата, така че пропускателната способност определя горната граница. При една записана стъпка са стартирани 795 ядра, формиращи 555 последователни етапа; Lily записва реалните зависимости в конкурентен Metal проход, така че независимите ядра да се припокриват. Избраният токен се записва директно в GPU слота за вход на следващата стъпка, който се намира в паметта на GPU, като така се премахва двупосочното пътуване през CPU за всеки токен, а четири вериги от ядра са слети, за да се запазят междинните резултати в регистрите.

Коалесцираните четения от кеша повишиха пропускателната способност за ключовете от 33,8 на 47,9 GB/s, а за стойностите — от 42,0 на 61,8 GB/s. Пакетирането на GQA, при което четири глави за заявки споделят една нишкова група, така че всеки KV ред да се зарежда веднъж, подобри декодирането с 23,8% при 32K. Оформлението на вниманието с фиксирани блокове при 32K и повече подобри декодирането със 7,7% при 32K, 27,4% при 64K и 40,2% при 128K.

Резултати

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

Основни изводи

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

---

Разгледайте техническите подробности тук и GitHub хранилището тук. Също така не се колебайте да ни последвате в Twitter и не забравяйте да се присъедините към нашия ML SubReddit с над 150 хил. членове и да се абонирате за нашия бюлетин. Почакайте! В Telegram ли сте? Вече можете да се присъедините към нас и в Telegram.

Имате нужда от партньор за популяризиране на вашето GitHub хранилище, страница в Hugging Face, продуктова премиера, уебинар и др.? Свържете се с нас