Qwen3.8 Flash Next сжали с 354 до 29,6 ГБ
Qwen3.8 Flash NextквантизацияMoE
Как модель ужали без обычной квантизации вслепую
Меня здесь цепляет не сам формат 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-модель можно приблизить к локальному инференсу не одной агрессивной квантизацией, а совместной оптимизацией структуры и представления весов. Это уменьшает память, сохраняя большую часть заявленного качества на задачах программирования.
Но именно удаление экспертов я бы проверял первым. Средний результат бенчмарка может скрыть просадку на редких языках, необычных репозиториях и задачах, где маршрутизация обращалась к специализированным экспертам. Отдельно интересны реальная скорость, потребление памяти во время длинных сессий и устойчивость качества за пределами двух указанных тестов.
Сам подход выглядит не трюком, а вполне серьёзной схемой compression под заданный бюджет. Главный нерешённый вопрос в том, сохраняется ли качество на редких маршрутах MoE так же хорошо, как на знакомом распределении кодовых бенчмарков.