Что выпустили Nace и Kapitsa: GGUF-кванты Qwen и заявленные цифры
Nace.ai вместе с Kapitsa выпустила GGUF-кванты для четырёх моделей Qwen: 9B, 27B, 35B-A3B и Flash-Next. Файлы собраны методом Weight Space Programming (WSP): агентные LLM предлагали, где поменять точность тензоров, а каждая правка проверялась по KL-дивергенции и либо оставалась, либо откатывалась. Об этом команда рассказала в посте на r/LocalLLaMA. Рамка доверия сразу: все цифры ниже, это собственные замеры авторов. Независимой проверки нет, а статья с описанием метода ещё не опубликована.
Заявленные результаты по top-1 относительно полной модели:
| Модель | Квант | Размер файла | Top-1 |
|---|---|---|---|
| Qwen 9B | Q3_K_XL | 4.7 ГБ | 90.5% |
| Qwen 35B-A3B | Q3_K_S | 15.3 ГБ | 91.2% |
| Qwen 27B | Q4_K_XL | 17.3 ГБ | 97.7% |
| Qwen Flash-Next | в посте без имени кванта | 93 ГБ | 93.0% |
Top-1 accuracy показывает, как часто квант выбирает тот же следующий токен, что и полная модель. Замер шёл на контексте 128K, баллы по разным сабсетам объединены в один итоговый. Объединение удобно для красивого графика и неудобно для практика: по нему не видно, как квант ведёт себя отдельно на коде, отдельно на tool-calls, отдельно на обычном чате.
Автор заявляет, что на всех четырёх моделях его веса дают лучший результат в своём размере или меньше, и что сравнение шло с квантами Unsloth, ByteShape и EXL3 сопоставимого или меньшего размера, включая хвост p99. Читать это стоит как гипотезу: сравнение проводили сами авторы релиза, на своём наборе данных, до публикации методики.
Кто такие Nace.ai и Kapitsa
По описанию в посте Nace.ai - open source AI lab, которая стоит за моделью принятия решений, занявшей первое место в Artificial Analysis decision index v2.1. Kapitsa занимается быстрым инференсом для Apple Silicon. Оба титула, это самопозиционирование команд, сторонних подтверждений в материале нет. Для тех, кто запускает модели локально, связка выглядит логично: одна сторона отвечает за то, как веса ужимаются, вторая знает, как их потом гонять на потребительском железе.
Какие файлы и для каких моделей
GGUF читают llama.cpp, Ollama, LM Studio и большинство обвязок вокруг них, поэтому новые кванты встают в привычный стек без конвертации и кастомных ядер. Практический смысл размеров такой: 4.7 ГБ у 9B Q3_K_XL оставляют место под KV-кэш даже на картах с 8 ГБ, 17.3 ГБ у 27B Q4_K_XL рассчитаны на 24 ГБ VRAM, 15.3 ГБ у 35B-A3B Q3_K_S закрывают MoE-сценарий на той же 24-гиговой карте. Flash-Next на 93 ГБ, это история для серверов, а не для домашней сборки.
Суффиксы в названиях (Q3_K_XL, Q4_K_XL, Q3_K_S) означают разные схемы смешанной точности внутри одного файла: часть тензоров хранится точнее, часть грубее. Именно выбор этой смеси WSP и подбирает. Размер в таблице, это размер файла, а не пиковое потребление VRAM: на длинном контексте кэш растёт и легко съедает несколько гигабайт сверху.
Weight Space Programming: как LLM редактирует веса другой модели
Идею автор взял из статьи Sparks of Weight-Space Programming: дать LLM возможность нативно читать и править веса моделей меньшего размера. В квантовании это превратилось в цикл, где агентные модели Astra, Fable и Carbon конкурируют между собой и предлагают изменения точности конкретных тензоров. После каждой правки измеряется KL-дивергенция относительно полной модели, и правка сохраняется или откатывается.
Схема «предложил, измерил, оставил или откатил» превращает квантование в поиск по пространству вариантов с объективным критерием приёмки. Решение принимает не человек с эвристикой, а цикл, который сам себя проверяет на каждом шаге.
До WSP автор пробовал брутфорс-хиллклайм с агентным роем. Такой подход вышел на уровень SOTA, но упёрся в плато по KL относительно лучших квантов вроде Unsloth и EXL3. WSP это плато пробил: первые Q3-кванты Qwen 9B, по замеру автора, удержали фронтир среди 50+ квантов 9B по KL-дивергенции.
Чем это отличается от привычных GPTQ/AWQ/imatrix-подходов
Схемы вроде GPTQ и AWQ опираются на статистику весов и активаций плюс заранее заданные правила: что хранить точнее, что можно уронить. imatrix добавляет сигнал о том, где ошибка бьёт больнее, но итоговое решение всё равно считает формула. В WSP кандидата на изменение предлагает LLM-агент, а судьёй выступает измеренная KL.
Формат на выходе привычный: обычный GGUF, который читают стандартные раннеры. Сравнивать подход с другими методами корректно по качеству при сопоставимом размере файла, а не по скорости генерации, заявлений о скорости в посте нет вообще.
Почему KL-дивергенция - главная метрика
KL-дивергенция измеряет, насколько распределение вероятностей следующего токена у кванта расходится с распределением полной модели. Ноль означает идентичное поведение, рост означает, что квант всё чаще уходит в другие ветки.
Для автоматического цикла метрика удобна: правку можно принять или откатить без человека, нужен только порог. Автор отдельно акцентирует хвост p99, то есть 99-й процентиль ошибки. Средняя KL может выглядеть прилично, пока редкие случаи не улетают далеко от полной модели, и именно эти случаи ломают длинные ответы.
Цифры: top-1, KL и хвост p99 - что они реально значат
Три метрики из поста отвечают на разные вопросы. Top-1: как часто квант выдаёт тот же токен, что полная модель. KL: насколько расходятся распределения вероятностей. p99: как выглядят худшие 1% случаев.
90.5% у 9B Q3_K_XL при 4.7 ГБ означают, что примерно в девяти случаях из десяти следующий токен совпадёт с полной моделью. 97.7% у 27B Q4_K_XL при 17.3 ГБ, это уже почти паритет по этому показателю. Совпадение токена не гарантирует совпадения длинного рассуждения: небольшое расхождение на раннем шаге уводит весь ответ в сторону. Поэтому KL и хвост p99 смотрят туда, куда top-1 не достаёт.
Практическая оговорка: KL и top-1 не предсказывают, какая сборка лучше закроет вашу задачу. В сравнении GSQ-RCO и ByteShape на RTX 3060 12 ГБ квант с выигрышем по KL не дал автоматического выигрыша в работе и потратил вдвое больше токенов на ту же задачу. Разбор Basalt 0.2.0 с таблицей KLD и top-1 добавляет к этому цену выбора в скорости: у более точного кванта она заметно ниже.
Почему хвост p99 важнее среднего на длинном контексте
На длинном контексте ошибки кванта накапливаются. Редкие плохие случаи, то есть хвост распределения, портят ответ сильнее, чем небольшое ухудшение среднего: одна неверно выбранная ветка в середине рассуждения уводит весь вывод. Автор отдельно подчёркивает устойчивость к дрейфу на длинном контексте и замеры до 128K.
Граница применимости честно обозначена в обсуждении методики: на сотнях тысяч токенов деградирует само чтение длинного контекста даже на полных неквантованных весах, и это легко ошибочно списать на квант (разбор на linux.org.ru).
Что показывает MMLU и чего он не показывает
Проверка на MMLU: 13 943 вопроса, без chat template и без few-shot. В таких стерильных условиях разница между Q3-Q4 и более высокой точностью в основном в пределах шума, то есть квант не разваливает знания модели. Сигнал полезный, но узкий.
Чего MMLU не ловит: длинный контекст, tool-calls, код, многошаговые инструкции. А кванты чаще всего болят именно там. Отсутствие chat template означает ещё и то, что модель проверяли не в том виде, в котором её обычно запускают.
Ограничения, о которых говорит сам автор
Слабые места автор обозначает сам, и это добавляет посту веса.
Почему крупные модели - слабое место метода
Формулировка из поста: метод хуже масштабируется на крупные модели, отдельно упомянут QFN. Значит, для Flash-Next и сопоставимых по объёму весов ждать такого же отрыва, как у 9B, не стоит. Основной сценарий, это 9B, 27B и 35B-A3B. Переносить 90.5% с девятимиллиардной модели на 100B+ нельзя: у метода там другая отдача.
Чего в посте нет: скорость, независимая проверка, статья
- Нет заявлений о скорости инференса, только о качестве. WSP меняет то, как выбирается точность тензоров, и не обещает ускорения генерации.
- Нет независимого бенчмарка: сравнение с Unsloth, ByteShape и EXL3 проводили сами авторы квантов.
- Нет статьи с описанием метода: «paper coming soon». До публикации воспроизвести пайплайн снаружи невозможно.
- Тесты шли на арендованных GPU: H200 для BF16-референса, L40S для квантов.
- Работа над улучшениями для QFN и DeepSeek не закончена: автор упёрся в лимиты токенов и просит GPU в личку для поддержки.
Отдельно про выборку для замеров: английские статьи Википедии, чат- и tool-call-транскрипты, код с GitHub, опубликованные после октября 2026, длиной 512 токенов и до 128K. Это внутренний набор автора, а не публичный стандарт. Пока статья не вышла, повторить его снаружи нельзя, а значит и проверить заявление «лучше Unsloth в своём размере» нечем, кроме собственных прогонов.
Стоит ли переходить: практический разбор по сценариям
Универсального ответа нет, всё зависит от VRAM и от того, что именно болит в текущем кванте.
8-12 ГБ VRAM, Qwen 9B. Q3_K_XL на 4.7 ГБ с заявленными 90.5% top-1 выглядит разумной точкой входа, особенно если основная проблема в дрейфе на длинном контексте. Если сейчас стоит квант Unsloth и всё устраивает, повода бежать за новым файлом нет: выигрыш заявлен, но не подтверждён независимо.
24 ГБ VRAM, Qwen 27B. Q4_K_XL на 17.3 ГБ по заявлению автора почти не отличается от полной модели на своих тестах. Проверять придётся на своих задачах, и заодно сравнить с альтернативой в виде MoE: выбор между 27B и 35B-A3B Q4_K_M строится на битности, архитектуре и требованиях задачи, а не только на размере файла.
35B-A3B. Q3_K_S на 15.3 ГБ и 91.2% top-1. MoE-архитектура активна только частью параметров, поэтому по скорости на токен такая сборка обычно интереснее плотной модели того же размера. Но помните про оговорку автора насчёт масштабируемости метода.
Flash-Next. 93 ГБ и 93.0% top-1. Ниша для тех, у кого есть серверное железо, для домашнего ПК сценарий нерелевантен.
Если VRAM около 16 ГБ и хочется понять, как кванты Qwen ведут себя на реальных задачах, есть тест трёх квантов Qwen 3.8 на задачах AtCoder: он полезен как пример методики, а не как гарантия результата.
Как проверить квант самому и не обмануться
Методика простая и скучная: фиксированный набор задач, несколько прогонов, одинаковые настройки (температура, размер контекста, chat template, число few-shot), сравнение средних значений, а не единичных впечатлений (та же логика описана в обсуждении на linux.org.ru).
Дальше разделить проверки по типам нагрузки: отдельно длинный контекст (32K-128K, если хватает VRAM), отдельно tool-calls, отдельно код, если они важны в работе. Сравнивать кванты на разных настройках сэмплинга бессмысленно, разница в ответах будет про настройки, а не про квант.
И держать в голове поправку на длину: на сотнях тысяч токенов деградирует и полная модель, так что списывать всё на квант рано. Смотрите не только на средний балл, но и на худшие прогоны: именно хвост показывает, где сборка ломается.
Что дальше: статус проекта и куда смотреть
Статья с описанием метода ещё не вышла, автор обещает её скоро и просит писать в личку, если есть GPU для поддержки. Улучшения для QFN и DeepSeek в работе, есть «многообещающие результаты», но автор упёрся в лимиты токенов.
Практический вывод: следить за публикацией статьи. Именно она даст воспроизводимую методику и позволит сторонним людям проверить заявленные цифры. До этого относиться к результатам как к сильному, но непроверенному сигналу: скачать квант под свою модель, прогнать на своих задачах, сравнить с текущим вариантом по средним и по худшим прогонам.