Вокруг Qwen 3.8 сложился набор артефактов, которые часто путают между собой: официальный репозиторий Qwen/Qwen3.8-27B, квантованный GSQ-RCO-GGUF (он относится к другой модели — Qwen3.8-Flash-Next), дообученный Coder390-EfficientThink и компактный Underdog-Saluki-27B. Ниже — что именно лежит в каждом из них, как устроены квантование и MTPMulti-Token Prediction — встроенная голова модели, предсказывающая сразу несколько следующих токенов и используемая для спекулятивного декодирования, какие движки что читают и на какие ограничения указывают авторы.
Что именно доступно
Официальный Qwen/Qwen3.8-27B содержит веса и конфигурационные файлы пост-обученной модели в формате Hugging Face Transformers. Артефакты совместимы с Transformers, vLLM, SGLang, TokenSpeed и другими движками.
Квантованный GSQ-RCO-GGUF относится не к 27B, а к Qwen3.8-Flash-Next: это неоднородные GGUF-квантования 512-экспертной MoEмодель, в которой на каждый токен активируется лишь часть экспертов-подсетей в четырёх размерах, вместе с визуальным проектором (mmproj) для мультимодального использования.
Дообученный вариант — репозиторий nerkyor/Qwen3.8-27B-Coder390-EfficientThink-Opus5.5-GPT6Astra-Grok4.7-DSV4Pro-K3-SFT-RLOO-MTP-DFlash2. Это модель, прошедшая несколько раундов SFT и RLOO поверх Qwen3.8-27B-EfficientThink-SFT-SimPO-DFlash2, которая сама является официальной Qwen3.8-27B, пост-обученной с SFT и SimPO.
Underdog-Saluki-27B — это ConwayResearch/Underdog-Saluki-27B-1.0, стандартный GGUF для stock llama.cpp на базе Qwen3.8-27B, умещающийся в 7.89 GB.
Режимы по умолчанию и MTP-голова
Qwen3.8 работает в режиме размышления по умолчанию: перед итоговым ответом генерируется блок, обозначенный <think>\n...</think>\n\n. Параметр preserve_thinking включён по умолчанию для всех нагрузок, а reasoning_effort по умолчанию равен xhigh — для сложных задач, требующих тщательного анализа. Доступны также medium (баланс точности и скорости) и low (экономный режим).
В архитектуре заявлена MTP-головадополнительный модуль модели, который предсказывает не один следующий токен, а сразу несколько шагов вперёд (Multi-Token Prediction), обученная сразу на несколько шагов предсказания. Для спекулятивного декодированияприём, при котором черновая модель предлагает несколько следующих токенов, а основная проверяет их за один проход MTP используется как встроенный механизм — когда не хочется загружать отдельный драфт DFlash2. Запускать MTP можно только на SGLang: DFlash2 валидирован лишь там, а в vLLM 0.28 режим MTP для FP8 временно недоступен.
Эффективность MTP измеряется через accept lengthсреднее число токенов, которые основная модель принимает за один проход проверки предложений черновой модели и accept rateдоля предложенных черновой моделью токенов, которые основная модель приняла. При C1 — accept length 2.858 и accept rate 0.619, что даёт ускорение 1.82× относительно работы без спекуляции. C1уровень параллелизма, то есть число одновременных запросов, которые обслуживает движок — самый быстрый одиночный запрос (91.1 tok/s); C4уровень параллелизма, то есть число одновременных запросов, которые обслуживает движок — интерактивная работа с несколькими пользователями (293.3 aggregate, 84.0 per request); C8уровень параллелизма, то есть число одновременных запросов, которые обслуживает движок — общее обслуживание (380.3 aggregate, 71.1 per request); C16уровень параллелизма, то есть число одновременных запросов, которые обслуживает движок — когда важна только суммарная пропускная способность (612.7 aggregate, 60.1 per request).
Как устроены квантованные варианты
GSQ (Gumbel-Softmax Quantization) — пост-тренировочная скалярная квантизация, которая совместно обучает назначения координат на сетке и масштабы по группам через Gumbel-Softmax релаксацию. Это позволяет приблизиться к векторной квантизации при 2–3 битах, оставаясь в стандартных скалярных форматах вроде GGUF. RCO (Riemannian Constrained Optimization) назначает один из K типов квантизации каждому из N тензоров при общем бюджете размера, переформулируя ограничение бюджета как гладкое риманово многообразие в пространстве логитов — так оптимизация идёт по лоссу задачи с точным соблюдением бюджета.
Вместе они дают неоднородный GGUF: каждый тензор получает свой тип квантизации. 95% искомых весов находятся в экспертах, и тип назначается по слою, а не по эксперту — GGUF не умеет выражать последнее.
LynnStyle Q2/Q3/Q4смешанная точность GGUF, где самый низкий тип достигает Q2/Q3/Q4 соответственно, со встроенным Q4 MTP (не Q8). Для Q3 LynnStyle указан BPWbits per weight — среднее число бит на один вес модели 5.07 при размере 17 303 770 432 байт, для Q4 LynnStyle — BPW 5.75 при 19 620 406 592 байт.
Схемы различаются тем, что именно квантуется — веса (W) и активации (A), а число после буквы означает разрядность:
- INT8 W8A16веса хранятся в 8-битном целочисленном формате, а активации остаются в BF16 — GPTQ симметричные per-channel INT8 веса с BF16 активациями;
- INT4 W4A16веса хранятся в 4-битном целочисленном формате, а активации остаются в BF16 — GPTQ INT4 веса (симметричные, group size 128) с BF16 активациями.
Запуск: обязательные флаги
Для vLLM запуск INT8 W8A8 требует двух переменных окружения, без которых сервер на RTX PRO 6000 Blackwell не стартует:
VLLM_DISABLED_KERNELS=CutlassInt8ScaledMMLinearKernel \
VLLM_USE_FLASHINFER_SAMPLER=0 \
vllm serve ./INT8/W8A8После отключения Cutlass INT8 vLLM переключается на собственное ядро INT8. Вторая переменная нужна, чтобы совпасть с протестированной конфигурацией.
Для llama.cpp используется llama-server -m ./GGUF/...gguf. Флаг --mmproj ./GGUF/mmproj-Qwen3.8-27B-Q8_0.gguf добавляет веса зрения и работает со всеми восемью GGUF-файлами; без него llama.cpp работает только с текстом.
В NInfer флаг --vision размещает визуальный энкодер на GPU, а при нехватке памяти используется --vision-cpu (на CPU, по умолчанию максимум 256 merged token на изображение, настраивается через --vision-max-merged). Без --vision движок работает только с текстом. Изображения передаются в формате OpenAI как части image_url в POST /v1/chat/completions.
Переключение thinking-режима
Чтобы получить прямой ответ без размышлений, нужно настроить параметры API. Для Qwen Cloud вместо обёртки chat_template_kwargs используется плоский параметр "enable_thinking": False. Аналогично preserved thinking (сохранение блоков размышлений из всех исторических сообщений) отключается в Qwen Cloud через "preserve_thinking": False напрямую, а не внутри chat_template_kwargs. В обычном API это делается через extra_body={"chat_template_kwargs": {"preserve_thinking": False}}.
На чём построен Coder390-EfficientThink
База — Qwen3.8-27B-EfficientThink-SFT-SimPO-DFlash2, то есть официальная Qwen3.8-27B, дообученная с SFT + SimPO. Поверх неё шли несколько раундов: K3 continuation SFT → week-2 SFT (week2dose, update-225) → первый раунд RLOO (182 группы) → ещё один раунд SFT (merge-sft-100), давший sft-base-rloo → второй раунд RLOO (172 группы) → Coder390.
Данные RLOO формируются так: на задачу сэмплируется 8 траекторий, оставляются только группы, где есть и правильные, и неправильные траектории. Группы с 0 или 1 правильной траекторией получают одну проверенную короткую учительскую траекторию, которая заменяет самую короткую неправильную в группе (27 групп). Итоговый набор — 172 группы, 1 376 траекторий: 859 правильных и 517 неправильных, включая 68 пустых ответов. Награда штрафует только неправильные траектории; длинные правильные рассуждения всё ещё получают положительную награду, чтобы не подавлять необходимые длинные рассуждения.
Зачем понадобился EfficientThink
Проблема, которую решает дообучение: после того как у модели уже есть локальный ответ, она продолжает повторять одну и ту же выкладку с Wait / Actually до заполнения контекста, и финальный ответ оказывается пустым. Авторы отмечают, что в большинстве таких случаев модель способна решить задачу — просто не останавливается. Цель обучения сформулирована как удаление непродуктивных хвостов рассуждения при сохранении необходимого длинного рассуждения.
Результат: при том же протоколе 94K-усечения падают с 4 до 1 на GPQA и с 13 до 3 на LCB по сравнению с исходной Qwen3.8 27B (FP8), и ни один из трёх баллов не опускается ниже исходного.
Зачем нужны низкобитные варианты
Низкобитные сборки резко уменьшают размер модели. IQ3_XXS при 3.00 bpw занимает 75.8 GB против 354 GB у BF16 — в 4.7 раза меньше, при этом достигает 99.4% от task average базовой модели. Q2_0 при 2.40 bpw занимает 66.4 GB (5.3-кратное сокращение), IQ2_XS при 2.50 bpw — 68.0 GB и сохраняет 95.7% task average. NVFP4Схема квантования, в которой MLP-слои языковой модели хранятся в формате NVFP4 W4A4, а проекции внимания — в FP8 W8A8.-варианты занимают около 22.1 GiB, GGUF Q3 LynnStyle — около 16.1 GiB.
Дополнительно флаг -lm mmap --lazy-mode on убирает 28.8 GB из резидентной памяти: n-gram-таблица остаётся отображённой на диск, а не загружается в память. Сторонний движок Strata Engine, по сообщениям пользователей, позволяет запускать эти GGUF на одной NVIDIA GPU от 8 GB VRAM.
Что читает какой движок
.ninfer — формат пакета, который читает только движок NInfer: SGLang, vLLM, llama.cpp и transformers его не загружают. .ninfer, сконвертированные из GGUF, требуют именно NInfer-all (iamwavecut/ninfer-all), а не официального ninfer-serve.
Обычные GGUF-файлы предназначены для llama.cpp, а также запускаются через Ollama (ollama run hf.co/<this-repo> с выбором каталога под бюджет памяти) и LM Studio (поиск по имени репозитория, затем выбор сборки GSQ-RCO-* из списка файлов).
HF-пакеты из каталогов NVFP4 по-прежнему запускаются в SGLang (с MTP или DFlash2) и не взаимозаменяемы с NInfer-пакетами.
Известные проблемы совместимости
В vLLM 0.28 MTP для FP8 временно недоступен — рекомендуется SGLang. На RTX PRO 6000 Blackwell ядро Cutlass INT8 в vLLM недоступно, и сервер не запустится, пока его не отключат через VLLM_DISABLED_KERNELS=CutlassInt8ScaledMMLinearKernel.
Ограничение KV-пула: нельзя использовать --max-context 131072 --kv-capacity 131072 — тогда пул вмещает лишь один полный контекст, и запросы в очереди получают HTTP 503. Также не следует добавлять --lm-head-q6 / --embedding-q4.
Метрики качества
Для Qwen3.8-Flash-Next-GSQ-RCO-GGUF приведены ZS avg, recovery, AIME25, GPQA-D, LCB v6 и Task avg. У BF16: ZS avg 76.94, recovery 100.0%, AIME25 100.00, GPQA-D 91.92, LCB v6 87.43, Task avg 93.12. У GSQ-RCO Q2_0 (2.40 bpw): ZS avg 78.00, recovery 101.4%, AIME25 96.67, GPQA-D 89.39, LCB v6 81.14, Task avg 89.07. У IQ2_XS (2.50 bpw): ZS avg 77.16, recovery 100.3%, AIME25 96.67, GPQA-D 87.37, LCB v6 83.43, Task avg 89.16. У IQ3_XXS (3.00 bpw): ZS avg 77.23, recovery 100.4%, AIME25 100.00, GPQA-D 91.41, LCB v6 86.29, Task avg 92.57. У IQ3_S (3.50 bpw): ZS avg и recovery — n/a, AIME25 100.00, GPQA-D 92.93, LCB v6 86.86, Task avg 93.26.
Для Coder390-EfficientThink GPQA и LCB идентичны во всех трёх точностях, а MMLU варьируется между 445 и 450 — это шум сэмплирования, а не эффект точности.
Замеры производительности
Замеры сделаны на одной RTX PRO 6000 Blackwell (96 GB) с vLLM 0.28, --max-model-len 102400, --max-num-seqs 8 и --gpu-memory-utilization 0.85. В таблицах NVFP4 W4A4 и W4A4-W8A8 приведены агрегатные tok/s и медианные per-request decode tok/s для C1/C4/C8/C16. Для W4A4 DFlash2: C16 1 143.2; для MTP: C8 355.5, C16 912.4; без спекуляции: C1 70.9. Для W4A4-W8A8 DFlash2: C16 1 146.4; MTP: C1 99.9, C8 417.2, C16 580.2; без спекуляции: C1 62.2. В таблицах также указаны TTFT (медиана), accept length и accept rate. Быстрые бенчмарки используют 512 или 1024 generation cap, thinking on, temperature 1.0, top_p 0.95, top_k 20.
Ограничения и открытые вопросы
Авторы прямо указывают, что таблицы TPS и конкурентности по одному протоколу ещё не готовы: smoke decode составил около 119 tok/s wall с MTP и зрением на коротком промпте. Для llama.cpp отмечено, что reasoning-токены не возвращаются отдельно: в usage нет reasoning_tokens, поэтому длину reasoning для MMLU считали по тексту, а для LCB результат вообще не сохранил reasoning-текст и читается как «—».
Калибровочные данные NVFP4 — это собственные корректные и непустые траектории модели из RLOO-обучения: 512 сэмплов, около 1.735M токенов, не более 4 096 токенов каждая; официальные задачи GPQA, MMLU или LCB не используются. Для GGUF Q6_K указана калибровка imatrixматрица важности, по которой при квантовании подбирают параметры так, чтобы сильнее всего сохранить наиболее значимые веса на 512 чанках со структурной защитой. Конкурентность выше C16 не тестировалась.
