Нова технологія DeepSeek перенесена на чіпи Apple! Локальна велика модель на Mac прискорена на 60%

DSpark, який був відкритий лише тиждень тому, вже перенесено на комп'ютери Mac.

Порт називається mlx-dspark, він працює з моделями Gemma-4 12B та Qwen3-4B.

Після встановлення швидкість генерації цих двох моделей на Mac зросла в 1.6 та 1.4 рази відповідно.

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

Тобто, швидкість зросла, а якість не постраждала.

Людина, яка це зробила — Abdur Rahim, інженер, який у вільний час займається open-source проектами. Він самостійно створив першу нативну версію DSpark для Mac з моменту його відкриття.

Запуск великих моделей на Mac: прискорення на 60%

Для DSpark, відкритого DeepSeek 27 червня, офіційні цифри становлять прискорення на 60–85% у серверних сценаріях.

Однак на той час ця технологія була реалізована лише для дата-центрових GPU, без версії для Apple-чипів.

mlx-dspark — це перша нативна версія цієї технології для чипів Apple.

Ідея DSpark полягає в тому, щоб використовувати меншу модель для допомоги цільовій: мала модель генерує кілька кандидатів за раз, а цільова модель перевіряє їх усі одразу, приймаючи правильні та відхиляючи неправильні для повторної генерації.

Вартість цього кроку відрізняється між дата-центром і комп'ютером Mac.

На GPU в дата-центрі перевірка партії кандидатів схожа на оренду автобуса: ціна фіксована незалежно від кількості пасажирів. Декодування і так є вузьким місцем через пам'ять, тому додаткова перевірка декількох слів майже не потребує часу.

Чіпи Apple більше схожі на таксі з лічильником: чим більше кандидатів перевіряється, тим більше набігає.

Rahim виміряв, що для Gemma-4 12B кожен додатковий токен для перевірки коштує приблизно 14 мс. Він змоделював це в модель витрат і дійшов висновку, що верхня межа прискорення на чипах Apple становить близько 2.2 рази.

Загалом, Rahim переніс допоміжну малу модель з checkpoint на HuggingFace і налаштував її для використання з цільовими моделями Gemma-4 12B та Qwen3-4B.

Він також перебудував процес перевірки у фреймворку MLX, квантувавши ваги до 4-bit.

В результаті на M4 Pro, порівняно з офіційним інструментом MLX від Apple, швидкість генерації Gemma-4 12B зросла з 18.4 ток/с до приблизно 30 ток/с, тобто приблизно в 1.6 раза; Qwen3-4B — з 52.9 ток/с до приблизно 73 ток/с, тобто в 1.4 раза.

Крім того, у mlx-dspark Rahim зробив те, чого не робить більшість портів.

Порт також здатний на високоточне відтворення

Більшість версій, що переносять великі моделі локально, підтримують лише жадібне декодування, тобто на кожному кроці обирають слово з найвищою ймовірністю.

Rahim у mlx-dspark реалізував також метод семплювання температури, описаний у статті DSpark: модель-чернетка генерує кандидати, ймовірність прийняття min(1, p/q), а неприйнята частина повторно семплюється з залишку.

Він особисто перевірив, що вихідні дані цього процесу точно дорівнюють точному розподілу, який би дав цільова модель за тієї ж температури, а не апроксимовану версію.

Більшість спекулятивних декодерів реалізують лише жадібну версію, оскільки перевірити правильність жадібного режиму просто — потрібно лише порівняти послівно.

Додатковий крок Rahim полягав у тому, що він особисто перевірив розподіл вихідних даних у режимі семплювання, підтвердивши відсутність спотворень.

Яку точність призначити для цільової моделі-перевіряльника — підводний камінь, який він виявив самостійно.

Якщо мала модель використовується з базовою цільовою моделлю без інструктивного доналаштування (fine-tuning), лише 47% кандидатів проходять перевірку; якщо замінити на відповідну інструктивну версію, цей показник зростає до 82%.

Він також тестував заміну цільової моделі на точність bf16, але витрати на перевірку зросли більше, ніж рівень прийняття, що призвело до уповільнення, тому цільова модель за замовчуванням залишається в 8-bit, що є найвигіднішим.

Мала модель, яка генерує кандидати на передньому етапі, використовує іншу точність.

Сама модель-чернетка була стиснута: після квантування до 4-bit вона займає лише 1.8 ГБ, без проблем поміщається в пам'ять і працює без втрат.

У результаті DSpark не лише прискорив роботу, але й дійсно відтворив на пристрої підвищення коефіцієнта прийняття на 16–18%, згадане в статті.

DFlash також інтегровано, швидше для завдань з кодом

Після публікації твіту в коментарях з'явилося повідомлення від Jian Chen, одного з авторів статті DFlash, з проханням спробувати модель їхньої команди.

DFlash — це інший метод спекулятивного декодування, запропонований у дослідженні z-lab, опублікованому в травні цього року. Керівник авторського колективу — Zhijian Liu, доцент UCSD та науковий дослідник NVIDIA.

Підхід DFlash відрізняється від DSpark: він використовує паралельну «блокову дифузію» для денойзингу цілого блоку з 16 токенів, а не вгадує крок за кроком із залежностями, як DSpark.

Rahim швидко взявся до роботи.

Він використав скрипт портування, написаний самим Jian, підключив gemma4-12B-it-DFlash від z-lab до цільової моделі Gemma-4 у mlx-vlm, і на тому ж Mac провів пряме порівняння з DSpark, який він щойно протестував.

На завданнях з кодом і математикою DFlash досягає довжини прийняття блоку 5,95–6,20 зі швидкістю близько 36 ток/с, що становить приблизно 2,1-кратне прискорення, випереджаючи DSpark.

Однак DFlash генерує цілий блок із 16 токенів за раз, але цільова модель може не прийняти їх усі; на практиці проходить лише частина, що в індустрії називають «довжиною прийняття», і не завжди вдається заповнити всі 16.

Тому в сценаріях відкритих чатів, де вміст важко передбачити, довжина прийняття низька, блок не заповнюється, і перевага DFlash не реалізується.

Марковська голова DSpark існує саме для боротьби з цією ж проблемою: при паралельній генерації цілого блоку слів пізніші позиції обчислюються незалежно, що може призводити до неузгодженості; марковська голова додає залежності між цими позиціями, спеціально виправляючи цю проблему.

У результаті в чатовому сценарії DSpark виявляється швидшим за DFlash.

Пізніше оновлена версія mlx-dspark v0.0.3 офіційно інтегрувала оригінальний DFlash від z-lab у пакет, а також додала параметр для ручного скорочення ефективної довжини блоку DFlash: короткі блоки для чатів, а для завдань з кодом і математикою — повні блоки з 16.

Після цього на одному Mac в одному пакеті можна одночасно виконувати завдання чату, коду та математики, не потрібно перемикатися між проектами DSpark та DFlash.

Rahim у своєму твіті зазначив, що той самий метод має працювати і з більшими моделями-чернетками Qwen3-8B та 14B.

Джерело: Liangziwei

Попередження про ризики та застереження

        Ринок ризикований, інвестуйте обережно. Ця стаття не є індивідуальною інвестиційною порадою і не враховує особливі інвестиційні цілі, фінансовий стан або потреби окремих користувачів. Користувачі повинні самостійно оцінити, чи відповідають будь-які думки, погляди або висновки в цій статті їхнім конкретним обставинам. Інвестування на основі цієї статті здійснюється на власний ризик.