Qwen3.8 Flash Next стиснули з 354 до 29,6 ГБ

Як модель стиснули без сліпого квантування

Тут привертає увагу не сам формат GGUF, а поєднання двох важелів: зменшення кількості MoE-експертів і неоднорідне квантування ваг, що залишилися. У картці моделі ISTA-DASLab на Hugging Face Qwen3.8 Flash Next описана як MoE-модель із 512 експертами, стиснута зв'язкою GSQ і RCO для запуску в середовищах, сумісних із llama.cpp.

Для опублікованої збірки заявлено вилучення половини експертів і зниження точності ваг до 3,5 bpw. Початкова база BF16 займала 354 ГБ, тоді як робочий набір після обробки становить 29,6 ГБ. Це вже не косметичне зменшення файлу, а перехід до іншого класу доступного обладнання.

GSQ виконує посттренувальне скалярне квантування. Метод навчає призначення координат сіткам і масштаби для груп ваг, використовуючи релаксацію Gumbel-Softmax. Ідея полягає в тому, щоб не заганяти всі тензори в одну грубу схему, коли чутливість різних частин моделі помітно відрізняється.

RCO розв'язує наступний рівень задачі: для кожного тензора обирає один із K типів квантування за точного обмеження на підсумковий розмір. Підбирати окремий штрафний коефіцієнт для бюджету не потрібно. З інженерного погляду це сильніше за звичайний перебір пресетів GGUF, адже розмір стає умовою оптимізації, а не випадковим результатом налаштувань.

Заявлене збереження якості виглядає переконливо: 91,3% початкового результату на SWE-bench Verified і 98,7% на LiveCodeBench v6. Водночас матеріали офіційної картки докладно підтверджують GSQ, RCO та архітектуру з 512 експертами, але не дають змоги незалежно перевірити всі цифри стискання й тестів. Тому це варто сприймати як результати релізу, а не як відтворене вимірювання.

Що це змінює для локальних кодових моделей

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

Проте саме вилучення експертів я б перевіряв насамперед. Середній результат бенчмарку може приховувати просідання на рідкісних мовах, незвичних репозиторіях і задачах, де маршрутизація зверталася до спеціалізованих експертів. Окремо важливі реальна швидкість, споживання пам'яті під час довгих сесій і стабільність якості поза межами двох наведених тестів.

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

Ми також розглядали Pony Alpha як модель для безризикового пілотування та перевірки AI-архітектури в умовах обмежених ресурсів. Квантизація Qwen3.8 Flash Next робить такі експерименти значно доступнішими для локального й економного запуску.