GGUF-кванты bartowski для Qwen3.8-27B и Flash-Next: чем отличаются от Unsloth Dynamic

Введение

В августе 2026 Qwen выпустил две модели, которые стали рабочими лошадками локального LLM: Qwen3.8-27B — dense VLM на 27B параметров (BF16 ≈ 54 GB), и Qwen3.8-Flash-Next — MoE на 125B суммарных параметров с ~6B активными, Gated DeltaNet и Qwen Sparse Attention, нативный контекст 262K токенов (BF16 ≈ 354 GB). Ни одна из них в полной точности не помещается в потребительское железо, поэтому выбор GGUF-кванта — первое реальное решение при развёртывании.

На Hugging Face кванты для этих моделей выпускают несколько лагерей: стандартные llama.cpp, Unsloth Dynamic 3.0 (UD-кванты) и bartowski. Мы уже разбирали обзор квантов ByteShape и ISTA-DASLab GSQ-RCO, а в этой статье — bartowski: что за метод, чем он характерен, где выигрывает у Unsloth, а где проигрывает, и что выбрать под 16–32 GB видеопамяти.

Что такое per-tensor layout maps

Главная особенность репозиториев bartowski — per-tensor layout maps: для каждого нового семейства моделей автор вычисляет собственную карту распределения битности по тензорам вместо «одного размера на всех» правил llama.cpp. Метод описан в блог-посте bartowski и состоит из четырёх шагов:

1. Degrade-one sweep. Для каждого тензора модели строится квант, где все остальные тензоры выдержаны в высоком качестве (q8_0), а один — «смят» до q2_k. Модель прогоняется через llama-perplexity --kl-divergence на wikitext-raw (контекст 512 токенов) и фиксируется KLD относительно BF16-референса. Чем выше прирост KLD, тем чувствительнее этот тип тензора к потере битности.

2. Агрегация. По каждому типу тензора (token_embd, attn_q/k/v, ffn_up/gate/down и другие) берётся медианный KLD — получается таблица «стоимости» деградации каждого типа, публикуемая в репо как prior.json.

3. Solver. На вход идут форма модели (размеры всех тензоров), таблица чувствительности, ограничения GGML по блокам и целевое имя кванта (например Q4_K_M). Оптимизатор подбирает тип кванта для каждого конкретного тензора — разрешая как «бамп» вверх, так и «краш» вниз — при жёстком соблюдении бит-бюджета.

4. Генерация layout-файла. Результат — JSON-карта tensor → quant_type, которую передают в llama-quantize. Файлы карт лежат в папке layouts/ каждого репо, так что процесс воспроизводим.

Масштаб экспериментов: более 1000 конфигураций, ~96 часов GPU/CPU времени на двух базовых моделях (Qwen3.5-0.8B и Qwen3.5-4B), каждая проверка — полный perplexity-прогон. Для каждого нового семейства моделей карта пересчитывается заново, а «canary»-тест сравнивает KLD-per-bit с эвристическим методом: если карта хуже на уровне шума — она не публикуется.

💡 Практический смысл: при том же целевом размере файла биты уходят туда, где модель их «чувствует». В результате Q4_K_M из репо bartowski может быть заметно меньше по размеру, чем номинальный Q4_K_M из стандартного llama.cpp, — и при этом не хуже по KLD.

Qwen3.8-27B: что в репозитории bartowski

bartowski/Qwen3.8-27B-GGUF содержит 25 файлов — от Q8_0 (29.1 GB) до IQ2_XXS (8.9 GB). Ключевые варианты:

Таблица KLD и perplexity на wiki.test.raw (100 чанков) опубликована прямо в README репо, включая поперцентильные лестницы KLD — это редкая степень прозрачности для квантовщика. Отметки «recommended» стоят у Q6_K_L/Q6_K/Q6_K_S, Q5_K_M/Q5_K_S, Q4_K_L/Q4_K_M/Q4_K_S и IQ4_XS.

Важные детали:

• Imatrix. Все кванты построены с иматрицей на собственном калибровочном наборе; файл Qwen3.8-27B-imatrix.gguf лежит в репо.

• MTP-слои хранятся при Q4_0 и активируются флагом --spec-type draft-mtp в llama.cpp — для ускорения генерации спекулятивным декодированием.

• KV-кэш. Для 27B с 16 full-attention слоями, 4 KV-головками и head-dim 256 K/V-кэш в BF16 ≈ 32K параметров на токен (≈ 64 KB/токен): при контексте 32K это ~2 GB, при 128K — ~8 GB. Бюджетировать память нужно с учётом этого, а не только размера файла модели.

Qwen3.8-Flash-Next: да, он есть у bartowski

bartowski/Qwen3.8-Flash-Next-GGUF — полный набор от BF16 (354 GB) до IQ1_S (~70 GB). Для железа с ≤ 84 GB суммарно доступны:

Для Flash-Next иматрица построена на калибровочном корпусе из 583 чанков (214 проза + 369 tool-calling) от 137 диалогов, с рендерингом через собственный chat-шаблон модели и --parse-special — то есть квантизация учитывает спец-токены и паттерны агентного использования. Корпус (calibration-v6.txt) и иматрица опубликованы в репо.

Два нюанса, отличающие Flash-Next от 27B:

1. Q*_K_L / Q3_K_XL держат embedding и output (logits) при Q8_0 — критичные матрицы не сжимаются ниже 8 бит, остальное тело модели квантуется по целевой битности. Это стандартный приём bartowski для «больших» семейств.

2. mmproj-файлы: mmproj-Qwen3.8-Flash-Next-f16.gguf и -bf16.gguf лежат в репо; при запуске через llama-server -hf bartowski/Qwen3.8-Flash-Next-GGUF:Q4_K_M проектор скачивается автоматически, вручную — --mmproj <путь>.

Сравнение с Unsloth Dynamic 3.0

unsloth/Qwen3.8-27B-GGUF и unsloth/Qwen3.8-Flash-Next-GGUF используют Unsloth Dynamic 3.0 — блок-поковую оптимизацию с минимизацией KLD и динамическим пересчётом масштабных коэффициентов; Unsloth заявляет «более чем на 10% лучше top-1 accuracy при равном размере» против других провайдеров.

Размерная картина для Qwen3.8-27B при сопоставимой битности: Unsloth компактнее на нижнем конце (UD-IQ1_S 6.19 GB против IQ2_XXS 8.88 GB — разница в два раза), а в 4–5-битной зоне разрыв небольшой (UD-Q4_K_M 16.5 GB против Q4_K_M 17.4 GB). Для Flash-Next: UD-IQ3_XXS 82 GB против IQ3_XXS 88 GB — Unsloth влезает в 84 GB, bartowski — уже нет.

⚠️ Типичная ошибка: выбирать квант только по bpw или размеру. При одинаковых ~15–17 GB методология решает: KLD-метрики bartowski показывают 95% same-top-p для Q4_K_M, но это близость распределений токенов, а не качество на ваших задачах. Для продакшн-решений прогоните оба кванта на своём домене — особенно если критичны безопасность или точность (OWASP Top 10, инъекции в prompt).

Скорость и практические сценарии

Для Qwen3.8-27B на локальном железе (2× RTX 5060 Ti, суммарно ~32 GB VRAM) рабочая зона — IQ4_XS/Q4_K_M: модель целиком в памяти, контекст 16–32K без вырезания KV-кэша. MTP (--spec-type draft-mtp) даёт прибавку к скорости генерации при почти нулевой деградации качества — это аргумент в пользу bartowski для тех, кто запускает через llama.cpp напрямую.

Для Flash-Next картина другая: 125B MoE не «влезает» в потребительскую VRAM целиком даже в 2-битной квантизации (75 GB). Варианты — offload на RAM с частичным GPU-размещением (на сервере с 64–96 GB RAM и 16–24 GB VRAM это даёт ~10–15 t/s генерации в 2-bit) или удалённый инференс. Если задача — агентный ассистент с длинным контекстом на домашнем сервере, bartowski IQ2_XXS/IQ3_XXS — разумная точка входа; если нужен запас по качеству и есть 96 GB RAM+VRAM — смотреть UD-IQ3_XXS (82 GB) или GSQ-RCO (75.8 GB).

💡 Выбор кванта под конкретный сценарий: - 16 GB VRAM, чат/код: Qwen3.8-27B IQ4_XS (bartowski, 15.5 GB) или UD-IQ4_XS (unsloth, 14.3 GB). - 24 GB VRAM, агентные задачи: Qwen3.8-27B Q4_K_L/Q5_K_S + MTP — запас на KV-кэш длинного контекста. - Сервер 64–96 GB RAM: Flash-Next IQ2_XXS/IQ3_XXS с offload; для максимальной плотности квантования — GSQ-RCO. - Файл «без сюрпризов» (тонкая настройка, дистилляция): Q8_0 или UD-Q6_K_XL — минимальный KLD у обоих провайдеров.

Рекомендации

Обе методологии в 4–6-битной зоне дают практически одинаковый уровень качества (KLD < 0.015, same-top-p > 95% для 27B), поэтому выбор часто сводится к размеру файла и экосистеме запуска, а не к «чистоте» модели.

⚠️ Важно понимать: выбор кванта — лишь половина задачи. Вторая половина — корректная настройка инференса (контекст, KV-кэш, offload, спекулятивное декодирование) и проверка поведения на реальных задачах. Поверхностный подбор «по размеру файла» в продакшн приводит к ошибкам качества, которые обнаруживаются только под нагрузкой; для критичных систем стоит привлечь специалистов с опытом развёртывания LLM — это инвестиция, которая окупается снижением рисков.

Заключение

bartowski — это не просто ещё один квантовщик: пер-тензорные layout maps, вычисленные на тысячах degrade-one экспериментов, плюс иматрица с учётом спец-токенов и опубликованные KLD-метрики делают его репозитории наиболее прозрачными в экосистеме GGUF. Для Qwen3.8-27B это даёт полную серию от 8.9 до 29 GB с MTP-поддержкой; для Flash-Next — единственный «съедобный» набор в ≤ ~88 GB (IQ2_XXS–IQ3_XXS) с vision-проекторами.

Unsloth Dynamic 3.0 остаётся сильнее на нижнем конце размерного диапазона (1-битные кванты, компактность UD-IQ4_XS) и предлагает встроенный vision для Flash-Next без отдельного mmproj. В средней битности оба лагеря дают сопоставимое качество — финальный выбор стоит делать по своему железу, запусковому стеку и результатам прогона на доменных данных.

Источники

• bartowski/Qwen3.8-27B-GGUF

• bartowski/Qwen3.8-Flash-Next-GGUF

• Per-tensor layout maps for GGUF quantization — блог bartowski

• unsloth/Qwen3.8-27B-GGUF

• unsloth/Qwen3.8-Flash-Next-GGUF

• Qwen/Qwen3.8-Flash-Next — официальная модельная карточка

• Обзор квантов ByteShape для Qwen3.8-27B (ast-softpro.ru)

• ISTA-DASLab GSQ-RCO: обзор (ast-softpro.ru)