Qwen3.8-Flash-Next на MacBook із 64 ГБ: файли, кванти та прапорці llama.cpp

Файли Qwen3.8-Flash-Next разом важать 88 гігабайтів, і модель добре працює на зв’язці з трьох RTX 3090. Після кількох днів регулярного використання враження стале: вона думає менше, ніж Qwen3.8-27B, але дає раду майже будь-якому завданню. Менше балаканини, менше зациклень і більше справжніх відповідей. Для моделі з 6 мільярдами активних параметрів таке поєднання стислості й тямущості — рідкість.

Ігрові GPU в стійці — це одне, але архітектурна зміна в цій моделі підштовхує до іншого питання. Чи запуститься вона на MacBook? Тобто на одному ноутбуці з 64 ГБ єдиної пам’яті — машині, яку беруть у літак і якій зазвичай не довіряють модель на 180 мільярдів параметрів.

Два дні тестів на M4 Max і M1 Max, обидва з 64 ГБ, дали відповідь: так. Розраховуйте на 25–30 токенів за секунду під час декодування та близько 400 токенів за секунду на prefill, і жодного вивантаження на CPU.

Головне тут — «без вивантаження». Серверу з трьома 3090 доводиться ганяти експертів через системну RAM, а ноутбук просто завантажує модель і працює. M1 Max — чип шестирічної давнини з першого покоління Apple silicon, і все одно він видає приблизно дві третини швидкості M4 Max. Цим цілком можна користуватися.

Далі — як усе це налаштувати.

Який файл завантажувати: не найвідоміший

Тут є пастка. Найпопулярніша квантизація цієї моделі — GGUF від Unsloth. Для Linux-сервера це правильний файл, а для Mac — неправильний, і README самого Unsloth це визнає, вимагаючи на macOS 75–96 ГБ пам’яті.

Причина — особливість того, як графічний драйвер Apple поводиться з пам’яттю. У ній варто розібратися, бо вона пояснює все подальше.

llama.cpp завантажує моделі через відображення файлу в пам’ять (mmap). Операційна система видає вказівник, а сторінки читаються на вимогу. У Linux це працює повністю ліниво: сторінки, до яких звертаються, завантажуються, а решта може лишатися на диску або витіснятися, коли місце потрібне чомусь іншому.

Metal, графічний API Apple, усе ускладнює. Коли llama.cpp передає Metal відображений у пам’ять шард, цей шард повністю стає wired. Тобто він закріплюється в RAM, гарантовано присутній і не може бути витіснений. У шардах Unsloth ваги моделі перемішані з n-gram таблицею в тих самих файлах. Тому, коли Metal запитує один тензор ваг, він заразом закріплює гігабайти таблиці. На Mac із 64 ГБ результат — миттєва помилка браку пам’яті ще до першого токена.

Нагадаємо, що це за n-gram таблиця. Це «друга картотечна шафа» на 29 ГБ, яка взагалі нічого не обчислює, а лише слугує довідником — приблизно 2,7 кілобайта на згенерований токен. При 30 токенах за секунду це близько 3 МБ/с читання — навантаження, з яким упоралася б флешка 2012 року. Таблиці ніколи не потрібна була швидка пам’ять. Їй потрібно лише бути доступною.

Розкладка Unsloth випадково заганяє її у швидку пам’ять. У Linux розміщення можна перевизначити для кожного тензора, але в Metal такого контролю немає. Отже, рішення має бути структурним: покласти таблицю в шард без GPU-тензорів, щоб ніщо не змушувало її закріплювати.

Саме це й роблять збірки AtomicChat M64. Кожен їхній квант перепаковано так, що в шарді 2 лежить лише n-gram таблиця. Таблиця підтягується з SSD посторінково через кеш ОС, як і задумано архітектурою, а wired стають тільки справжні обчислювальні ваги.

Звідси й мітка «M64». Вона позначає сімейство розкладок, придумане під Mac із 64 ГБ, — перепаковку з розділеними шардами, — і нічого не обіцяє щодо розміру. Суфікс мають усі три їхні збірки, зокрема 110-гігабайтна для машин зі 128 ГБ. Чи поміститься збірка на ваш комп’ютер, вирішує кількість біт на вагу, а не суфікс.

Є й друга причина обрати їх — якість. Збирач починав з оригіналів у BF16, використав власну опубліковану матрицю важливості, а потім порівняв кожну збірку з реальними виходами еталонної моделі. Сирі логи KLD та еталонні логіти опубліковано — це більше прозорості, ніж дає більшість авторів квантів.

Який квант: 3.84 чи 4.27?

На Mac із 64 ГБ важливі дві збірки. Обидві використовувалися як основна модель цілими днями. Виміри на M4 Max із 64 ГБ:

| Build                     | Decode  | Prefill | Max context | Resident RAM |
|---------------------------|---------|---------|-------------|--------------|
| AD-3.84bpw-IQ4_XS-M64     | 28-32/s | ~400/s  | 220,000     | 45.8 GB      |
| AD-4.27bpw-Q4_K_M-M64     | ~25/s   | ~350/s  | 144,000     | 54.5 GB      |

Компроміс напрочуд чистий. 4.27 дає помітно кращу якість: розбіжність із моделлю повної точності в неї менша за половину розбіжності 3.84. Натомість вона коштує швидкості та 8,7 ГБ дорогоцінної резидентної пам’яті — тому її контекст обмежено 144K, а не 220K.

Для щоденної роботи краща 3.84, і причина одна — контекст. Вікно на 220 000 токенів при 30 токенах за секунду — приємніший супутник, ніж вікно на 144 000 при 25. Завантаження цілих кодових баз, повних колекцій нотаток і всієї історії проєкту — ось де розмір вікна відчувається цілий день, а різниця в якості проявляється лише в межових випадках раз на тиждень.

Обирайте за навантаженням. Якщо постійно згодовуєте довгі документи — беріть 3.84. Якщо робите точні міркування на коротших входах і різниця в якості вам заважає — беріть 4.27. Вона влазить у 64 ГБ, але Mac стає машиною однієї моделі, повністю.

Назви брешуть. Добре брешуть, але брешуть.

Ця частина наробила галасу на Reddit, тож скажемо прямо: ні «IQ4_XS», ні «Q4_K_M» у назвах цих файлів не описують, що всередині.

Збірки AtomicChat — змішані рецепти. Різні частини моделі отримують різні типи квантизації, а в назві файлу стоїть лише найближчий стандартний тип до середньої кількості біт на вагу — картка моделі каже про це прямо. Ось що насправді всередині кожної збірки.

AD-3.84bpw-IQ4_XS-M64

| AD-3.84bpw-IQ4_XS-M64  | Real type     | Share | Why                     |
|------------------------|---------------|-------|-------------------------|
| n-gram table           | ~6-bit        | 46%   | memorized hints, cheap  |
| MoE expert body        | IQ1_M (1.75b) | ~40%  | 512 experts, 2% active  |
| dense layers, heads    | Q6_K/Q8_0     | ~14%  | the parts that think    |

AD-4.27bpw-Q4_K_M-M64

| AD-4.27bpw-Q4_K_M-M64  | Real type      | Share | bpw contribution |
|------------------------|----------------|-------|------------------|
| n-gram table           | Q5_1           | 41%   | 1.74             |
| ffn_gate/up experts    | IQ2_S (IQ3_S*) | 29%   | 1.24             |
| ffn_down experts       | IQ4_NL         | 24%   | 1.03             |
| everything else        | Q8_0           | 5%    | 0.23             |

До того ж шари з 0 по 3 і з 40 по 47 отримують точніший IQ3_S. Статистика матриці важливості показала, що енергія активацій накопичується в останніх шарах, і рівномірний розподіл біт змарнував би їх на шари з 4 по 39.

Чи вважається це шахрайством? Коментатори на Reddit сказали, що так. Цифри свідчать про протилежне: вони показують, що відкалібрований рецепт робить саме те, для чого задуманий. Порівняно з повною моделлю в BF16 збірка 4.27 обирає той самий топовий токен у 89,5% випадків, а її перплексія вища лише на 2,6% (відношення 1,026). Біти не викинули, а перерозподілили. Експерта, до якого токен звертається приблизно у 2% випадків, можна сильно стиснути, а щільні шари, крізь які проходить кожен токен, лишаються великими. Сама архітектура робить ту саму ставку — тут її просто застосовано рівнем нижче, до квантизації.

Команда

Спершу оновіть і перезберіть llama.cpp. Підтримка архітектури qwen4exp потрапила в mainline 27 серпня, і все швидко змінюється:

cd ~/github_repos/llama.cpp
git pull
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j

Потім підніміть стелю пам’яті для GPU. На машині з 64 ГБ macOS обмежує її приблизно 48 ГБ, а налаштування скидається після кожного перезавантаження:

sudo sysctl iogpu.wired_limit_mb=57344

Далі запустіть сервер:

llama-server \
  -m /Users/andrewzhu/ai_models/Qwen3.8-Flash-Next-AD-3.84bpw-IQ4_XS-M64/Qwen3.8-Flash-Next-AD-3.84bpw-IQ4_XS-M64-00001-of-00028.gguf \
  --alias Qwen3.8-Flash-Next \
  --jinja \
  -ngl 99 \
  -c 168000 \
  -fit off \
  --host 0.0.0.0 --port 8083 \
  --metrics \
  --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 \
  --reasoning-format none \
  --parallel 1

Чотири деталі цієї команди важливіші, ніж здається.

-fit off обов’язковий. Автоматичний підбирач пам’яті в llama.cpp неправильно оцінює цю архітектуру й не може виділити пам’ять. Без прапорця сервер падає під час запуску на машині із запасом пам’яті, а помилка виглядає точнісінько як «бракує RAM» — і люди починають виснажливі пошуки. На Linux-збірках прапорець не був потрібен, а на Mac потрібен.

Перевизначення -ot немає. На Linux-сервері n-gram таблицю треба закріпити за CPU — це робиться регулярним виразом -ot '^per_layer_token_embd\.weight$=CPU'. Mac може це пропустити. За розкладки з розділеними шардами таблиця сама йде на хост, бо в її шарді немає нічого, що змусило б Metal її закріпити. Будова шардів уже розв’язує ту проблему, яку розв’язував регулярний вираз.

Прапорця --load-mode теж немає, тож лишається mmap за замовчуванням. На Linux-машині зі 128 ГБ можна вимкнути mmap і прочитати все один раз. На Mac mmap — це і є потрібна функція. Він дає ОС змогу підвантажувати й вивантажувати 39-гігабайтну таблицю з SSD у міру того, як її споживають токени. Якщо його вимкнути, система спробує зробити резидентними всі 85 ГБ, а в ноутбука лише 64.

Нарешті, немає -ncmoe. Конфігурації з однією 3090 потрібно близько 43 ГБ експертів, припаркованих у системній RAM. На Mac уся резидентна частина, 45,8 ГБ, вміщується під ліміт wired-пам’яті в 56 ГБ, тож вивантажувати нічого не треба. Єдина пам’ять просто вміщує все. Це перша машина, де відповідь на питання «що куди?» звучить так: «усе, що важливо, туди, де важливо, одразу».

Старий ноутбук теж дає раду

Те саме налаштування працює й на M1 Max із 64 ГБ. Це перший серйозний ривок Apple silicon, що вийшов шість років тому, коли 64 ГБ у ноутбуці були хизуванням у специфікаціях, а не вимогою для інференсу.

Він видає приблизно дві третини швидкості M4 Max із тією самою моделлю, тим самим файлом і тими самими прапорцями. Один із робочих варіантів — перенести повсякденну роботу на M1 Max, а M4 Max залишити з одним завданням: ця модель, завжди завантажена, відповідає зі швидкістю 30 токенів за секунду на сусідньому столі.

Є два застереження, і про них варто сказати без прикрас.

Машина зайнята. Поки модель завантажена, тиск на пам’ять лишається високим, тож закрийте вкладки браузера й чати: цей Mac тепер робить одну справу. Саме тому варто мати два.

SSD працює. Таблиця підтягується постійно. Пропускна здатність скромна, але за місяці це дає реальне зношування, а на довгих сесіях розкручуються вентилятори. Покласти файли моделі в зовнішній корпус USB4 NVMe — жест доброї волі щодо внутрішнього накопичувача.

Але погляньте ширше. Ноутбук, куплений для коду й монтажу відео, тепер запускає модель, яка на рівних б’ється з передовими ШІ. Модель має 180 мільярдів параметрів і живе на залізі, охолодження якого ніколи не налаштовували під тензорні навантаження. Ні дата-центру, ні кластера, ні рахунку за API. Архітектура прийшла до заліза, а не навпаки.

Ось у чому справжня історія Qwen3.8-Flash-Next. Великі моделі не стали меншими. Розумним моделям стали раді.