Обзор квантов ISTA-DASLab GSQ-RCO для Qwen3.8-27B и Flash-Next: что это за метод и чем отличается от Unsloth

Введение

В 2026 году вокруг GGUF-квантов открылась новая ветка, которая раньше была уделом академических работ. Лаборатория DASLab при IST Austria — та же группа, что стояла за GPTQ, AQLM и SqueezeLLM, — выпустила серию квантов GSQ-RCO для двух актуальных моделей Qwen: Qwen3.8-27B (dense VLM) и Qwen3.8-Flash-Next (MoE на 176–177B параметров). Главная заявка — «task-lossless» кванты, которые при размере в 4–5 раз меньше базового BF16 сохраняют почти все результаты по рассуждению и коду.

Что вы получите из этой статьи:

• как устроены методы GSQ и RCO и чем они принципиально отличаются от эвристического Unsloth Dynamic;

• полные таблицы размеров и бенчмарков для Qwen3.8-27B (IQ2_XS–IQ3_S) и Flash-Next (Q2_0, IQ2_XS, IQ3_XXS);

• сравнение с квантами Unsloth Dynamic на сопоставимых размерах;

• практические рекомендации: что скачать под ваш VRAM, как запускать в llama.cpp/Ollama/LM Studio и почему для Flash-Next критичен флаг -lm mmap --lazy-mode on.

💡 Если вы выбираете квант «на глаз» по размеру файла — GSQ-RCO даёт редкую вещь: опубликованные бенчи каждого конкретного размера против BF16. Это снимает главный вопрос локального LLM — «сколько качества я теряю, сжав модель в N раз».

Кто такие ISTA-DASLab и что такое GSQ/RCO

ISTA-DASLab (Distributed Algorithms and Systems Lab, IST Austria) — академическая группа, известная по GPTQ (один из самых распространённых PTQ-методов в индустрии), AQLM и SqueezeLLM. Их подход к квантованию — не эвристики «какой слой важнее», а оптимизация под целевую функцию (task loss) с жёстким бюджетом размера.

Метод состоит из двух независимых этапов:

1. GSQ (Gumbel-Softmax Quantization) — arXiv 2604.18556, код github.com/IST-DASLab/GSQ. Посттренировочное скалярное квантование, которое совместно обучает назначение координат на неравномерную сетку и масштабы групп через Gumbel-Softmax-релаксацию. Закрывает большую часть разрыва между скалярным и векторным квантованием на 2–3 бита, оставаясь в стандартных GGUF-форматах (IQ2_XS, IQ3_S и т.д.) — то есть работает без патчей в llama.cpp/Ollama/LM Studio.

2. RCO (Riemannian Constrained Optimization) — arXiv 2605.00649, код github.com/IST-DASLab/RCO. Назначает один из K типов кванта каждому из N тензоров под общий бюджет размера. Бюджет переформулируется как гладкое риманово многообразие в логит-пространстве, что позволяет оптимизировать градиентом напрямую по task loss с точным соблюдением бюджета — без «магических» гиперпараметров на саму constraint.

Порядок сборки: (1) для каждого тензора квантуются все кандидатские GGUF-типы через GSQ → база вариантов; (2) RCO-поиск выбирает один тип на тензор под целевой средний bpw; (3) выбранные варианты склеиваются в единый стандартный GGUF.

Ключевое отличие от Unsloth Dynamic:

⚠️ Важно: GSQ-RCO — это не «магия, которая лучше всех». Это другой компромисс: качество под конкретные бенчмарки рассуждения/кода в обмен на то, что метод оптимизирован именно под них. Для задач, не входящих в тренировочный набор (например, чистая генерация прозы), разрыв с UD может быть меньше или уходить в другую сторону — см. таблицу ниже: UD-IQ3_S по GPQA-Diamond на 0.51 пункта выше GSQ-RCO IQ3_S при том же размере.

Qwen3.8-27B: размеры и бенчмарки

Базовая модель: Qwen/Qwen3.8-27B, dense VLM, 27B параметров, BF16 = 53.8 GB. Архитектура в GGUF — qwen35. Лицензия apache-2.0 (наследуется от базовой).

Файлы квантов (имя: <model>-GSQ-RCO-<type>.gguf, bpw = фактический средний битрейт всего файла):

Каждый квант — один файл, без шардов, без n-gram таблицы. Для VLM-режима берётся один mmproj на все сборки.

Бенчмарки (против BF16 и Unsloth Dynamic):

Ключевые наблюдения:

• IQ3_S (11.8 GB) — task-lossless. Совпадает с BF16 по AIME25 (100.00) и LCB v6 (85.71), в пределах 0.51 по GPQA-Diamond. Task average = 91.70 против 91.87 у base — 99.8% при сжатии в 4.6 раза.

• IQ2_S (9.3 GB) — единственный вариант с recovery выше BF16 (101.8%). Это не ошибка: zero-shot на малых датасетах имеет большой стандартный разброс, и «выше base» здесь означает паритет в пределах шума.

• Против UD-IQ2_S при 8.4 GB: GSQ-RCO IQ2_XS выигрывает +10.00 AIME25, +8.59 GPQA-D, +4.57 LCB v6. Это самый большой разрыв в таблице — на нижнем конце битрейта метод оптимизации под task loss даёт ощутимый выигрыш над KLD-эвристикой.

• Против UD-IQ3_S при ~12 GB: GSQ-RCO IQ3_S выигрывает +3.33 AIME25, +1.71 LCB v6 и на 0.2 GB меньше по размеру; UD держит GPQA-Diamond на 0.51 пункта выше (89.90 против 89.39) и имеет чуть более высокий zero-shot average (75.49 против 74.47).

💡 Практический вывод: если у вас ≤16 GB VRAM и нужен VLM-квант Qwen3.8-27B — берите IQ3_S MTP (12.1 GB). Это «task-lossless» с запасом на KV-кэш и MTP-голову для спекулятивного декодирования. Если VRAM 12–14 GB — IQ3_XXS MTP (10.4 GB) уже совпадает с base по AIME25.

Qwen3.8-Flash-Next: MoE на 176B, два шарда и n-gram таблица

Базовая модель: Qwen/Qwen3.8-Flash-Next, MoE, 177B параметров, BF16 = 354 GB. Это уже не «домашний» размер — без квантования модель не помещается ни в один потребительский VRAM.

Файлы квантов (в отличие от 27B — два шарда):

Шард 2 — это per_layer_token_embd, таблица n-gram на 51.2B параметров, зафиксированная в IQ4_NL (4.5 bpw). Она одинакова во всех трёх квантах и не участвует в GSQ-RCO поиске — это lookup-таблица, а не matmul-веса. Именно поэтому её можно держать на диске через mmap.

Бенчмарки (против BF16 base 354 GB):

Наблюдения:

• IQ3_XXS (75.8 GB) — совпадает с BF16 по AIME25 (100.00) и держит 99.4% task average (92.57 против 93.12). Сжатие в 4.7 раза.

• Q2_0 жертвует ~3.5 пункта task average ради скорости: по данным лаба, prompt throughput на Q2_0 в 3.4 раза выше, а латентность на 1.9 раза ниже, чем у IQ2_XS — потому что lookup-форматы (IQ*) медленнее на GPU при генерации, а «плоские» Q2_0 идут через обычные matmul.

• Zero-shot recovery выше 100% во всех трёх квантах — это паритет в пределах стандартной ошибки малых датасетов, не «лучше base».

Критичный момент для запуска: без -lm mmap --lazy-mode on llama.cpp загрузит все 75.8 GB в VRAM — и модель просто не запустится на 2×RTX 5060 Ti (65 GB суммарно). С флагом резидентен только шард 1 (47 GB для IQ3_XXS), а n-gram таблица остаётся на NVMe.

⚠️ Для Flash-Next обязательно -lm mmap --lazy-mode on и быстрый NVMe SSD. Без этого флаг не даст нужного headroom — случайные обращения к 28.8 GB таблице по SATA/USB-диск превратят генерацию в ползучий процесс.

Сравнение с Unsloth Dynamic: что выбрать

Unsloth Dynamic (UD) — де-факто стандарт community-квантов: эвристика по KL-divergence логитов + «важности» слоёв, выбор типа GGUF на слой. GSQ-RCO — другой подход: градиентная оптимизация под task loss с точным бюджетом размера.

Что мы видим в данных лаба (27B):

Практические отличия:

1. MTP drafter. GSQ-RCO кладёт MTP-голову прямо в файл (-mtp сборка, +0.35 GB) — работает с любым квантом 27B. Unsloth кладёт shared-Q4_K_M drafter (~1.9 GB) только рядом с BF16/Q4_K_M/Q8. Для спекулятивного декодирования на нижних квантах GSQ-RCO выигрывает.

2. Один файл против одного файла. 27B: оба подхода — один GGUF, разница только в MTP. Flash-Next: у ISTA два шарда (веса + n-gram), у unsloth UD-Q2_K_XL — один большой файл ~79 GB (по данным сообщества) без отдельной lookup-таблицы.

3. Публикация бенчей. GSQ-RCO публикует полную таблицу per-quant против BF16 и UD. Unsloth не публикует per-quant бенчей вообще — качество оценивается сообществом по «≈ base» на конкретных задачах. Для выбора под конкретный сценарий это асимметрия в пользу ISTA.

4. Скорость генерации. Lookup-форматы (IQ*) медленнее на TG, чем «плоские» Q2_0/Q3_K. Если у вас MoE и важна скорость промпта — Q2_0 GSQ-RCO для Flash-Next даёт 3.4× PP против IQ2_XS при потерях ~3.5 пункта task average.

💡 Правило выбора: для dense моделей ≤30B (Qwen3.8-27B, Llama 3.x) — GSQ-RCO IQ3_S MTP, если VRAM позволяет; UD-Q4_K_M, если нужен максимальный TG и не важна экономия на AIME/LCB. для MoE ≥100B (Flash-Next) — GSQ-RCO IQ3_XXS + mmap, потому что unsloth UD-Q2_K_XL одним файлом 79 GB не оставляет headroom под KV-кэш на 65 GB VRAM.

Как запускать: llama.cpp, Ollama, LM Studio

Qwen3.8-27B (один файл)

# Скачивание (нужен huggingface_hub CLI)
hf download ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF \
  Qwen3.8-27B-GSQ-RCO-IQ3_S-mtp.gguf --local-dir .

# Текстовый режим
llama-cli -m Qwen3.8-27B-GSQ-RCO-IQ3_S-mtp.gguf \
  -p "Объясни mixed-precision квантование." -ngl 99

# VLM-режим (берётся общий mmproj)
llama-mtmd-cli -m Qwen3.8-27B-GSQ-RCO-IQ3_S-mtp.gguf \
  --mmproj mmproj-Qwen3.8-27B-BF16.gguf \
  --image photo.jpg -p "Опиши изображение."

Qwen3.8-Flash-Next (два шарда + mmap)

# Скачивание шарда 1 + mmproj (шард 2 подхватится через split)
hf download ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF \
  --include "IQ3_XXS/*" mmproj-Qwen3.8-Flash-Next-BF16.gguf --local-dir .

# КРИТИЧНО: -lm mmap --lazy-mode on держит n-gram шард на диске
llama-cli -m IQ3_XXS/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS-00001-of-00002.gguf \
  -lm mmap --lazy-mode on \
  -p "Объясни mixed-precision квантование." -ngl 99

Ollama и LM Studio

• Ollama: ollama run hf.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF — выберите файл под ваш VRAM. Для Flash-Next: ollama run hf.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF:IQ3_XXS (mmap/lazy-mode настраиваются внутри).

• LM Studio: найдите репо по имени, выберите GSQ-RCO-* сборку; mmap для GGUF включён по умолчанию.

Поддерживаемые раннеры (из панели «Как использовать эту модель» на HuggingFace): vLLM (vllm serve "ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF", OpenAI-compatible API), Docker Model Runner, Lemonade, Hermes Agent, Pi, OpenClaw, Unsloth Desktop, Jan, Atomic Chat, Google Colab, Kaggle.

⚠️ Для vLLM и других серверных раннеров mmap/lazy-mode настраиваются по-своему — проверьте документацию конкретного раннера перед запуском Flash-Next. Без корректной настройки n-gram шарда модель не запустится на потребительском VRAM.

Рекомендации: что скачать под ваш сценарий

Общие правила:

1. Всегда берите -mtp сборку для 27B, если используете llama.cpp с спекулятивным декодированием — это +0.35 GB за заметный прирост TG на длинных ответах.

2. Для Flash-Next без mmap/lazy-mode не запускайте — модель не влезет в VRAM и упадёт на этапе загрузки.

3. NVMe SSD обязателен для Flash-Next. SATA/USB-диск убьёт скорость из-за случайных обращений к 28.8 GB n-gram таблице.

4. mmproj — один на все кванты модели. Не скачивайте его отдельно под каждый файл.

💡 Если вы разворачиваете локальный LLM для продакшн-сценария (агентные задачи, RAG, кодинг) — выбор кванта это только половина. Вторая половина: корректная настройка контекста, KV-кэша, спекулятивного декодирования и мониторинга деградации качества на ваших данных. Команды, которые доверяют критичные LLM-инфраструктурные решения опытным специалистам, экономят время на отладке «модель отвечает хуже, чем в бенче» — типичная проблема при неверном выборе кванта под конкретный workload.

Заключение

ISTA-DASLab GSQ-RCO — это академический подход к PTQ, который впервые приносит публикуемые per-quant бенчмарки против BF16 и Unsloth Dynamic в mainstream GGUF-экосистему. Для Qwen3.8-27B это «task-lossless» IQ3_S на 11.8 GB (99.8% task average base, сжатие в 4.6 раза) с MTP-сборками для спекулятивного декодирования. Для Flash-Next — IQ3_XXS на 75.8 GB с AIME25 = base и обязательным mmap/lazy-mode для работы на потребительском VRAM.

По сравнению с Unsloth Dynamic GSQ-RCO выигрывает на нижнем конце битрейта (IQ2_XS против UD-IQ2_S: +10 пунктов AIME25) и по MTP-доступности, но проигрывает UD-IQ3_S на 0.51 пункта GPQA-Diamond при сопоставимом размере. Выбор между ними — вопрос того, что важнее: качество под конкретные бенчмарки рассуждения/кода (GSQ-RCO) или максимальный TG и простота «один файл» (UD).

Что важно помнить:

• GSQ = Gumbel-Softmax PTQ на 2–3 бита, закрывает разрыв scalar↔vector.

• RCO = градиентное назначение типа кванта на тензор под точный бюджет размера.

• Для 27B берите IQ3_S MTP; для Flash-Next — IQ3_XXS + mmap/lazy-mode + NVMe.

• Публикуемые бенчи per-quant — главное конкурентное преимущество ISTA-DASLab над Unsloth, который не публикует таких данных.

Источники

• ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF

• ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF

• GSQ: Gumbel-Softmax Quantization (arXiv 2604.18556)

• RCO: Riemannian Constrained Optimization (arXiv 2605.00649)

• GSQ source code

• RCO source code

• Unsloth Dynamic v2.0 GGUFs

• Обзор квантов ByteShape для Qwen3.8-27B: ShapeLearn против Unsloth Dynamic

• Unsloth: Полный гид по ускоренному fine-tuning LLM