Basalt 0.2.0 - релиз движка инференса, который работает только на GPU архитектуры Blackwell и рассчитан на одну модель: Qwen 3.8 Flash Next. Версию 0.2.0 автор построил вокруг качества, а не вокруг токенов в секунду: впервые опубликованы замеры KLD и совпадения top-1 для нескольких форматов квантования относительно полнопрецизионной модели в BF16.
Что изменилось по сути: появился квант NVFP4-DQ8 с KLD 0.0561 против 0.0624 у NVFP4-DQ6_K и ценой примерно 7% скорости на прозе, формат файлов .basalt обновлён до версии 2 с теми же весами и более быстрым запуском, для старых файлов заявлен инструмент миграции. Lossy-опции, которые снижают точность, по умолчанию выключены и при включении показывают предупреждение.
Рамки стоит обозначить сразу. Basalt поддерживает только Blackwell (потребительские RTX 50-серии и серверные карты этого поколения) и только Qwen 3.8 Flash Next. На Ada, Ampere или с другой моделью движок не запустится, и тогда материал полезен как разбор методики замеров качества, а не как инструкция по установке. Второе ограничение автор релиза называет сам: каждый движок в сравнении измерялся своим инструментом, поэтому строгим бенчмарком результат не является.
Ключевые изменения в 0.2.0 коротко
- Новый формат квантования NVFP4-DQ8: KLD 0.0561 и совпадение top-1 92.25% против 0.0624 и 91.65% у NVFP4-DQ6_K.
- Замеры качества относительно полнопрецизионной модели BF16: KLD и top-1 для пяти форматов вместо субъективных впечатлений.
- Формат .basalt версии 2: веса и качество не меняются, запуск немного быстрее.
- Инструмент миграции для старых файлов .basalt.
- Lossy-«хаки» движка выключены по умолчанию, включаются вручную и сопровождаются предупреждением.
Кому адресован движок: только Blackwell и только Qwen 3.8 Flash Next
Проверка совместимости занимает один вопрос: есть ли у вас Blackwell. Речь про потребительские карты RTX 50-серии и серверное железо того же поколения. На более старых архитектурах движок не работает, и это заявленное ограничение, а не временная недоработка.
Второй фильтр - модель. Basalt оптимизирован под Qwen 3.8 Flash Next, а не под произвольные LLM: затачивать ядро под одну архитектуру проще, чем поддерживать десятки моделей, но и выбора у пользователя не остаётся. Тестовая конфигурация автора показывает то же самое: две карты разного класса (RTX 5090 на 400 Вт и RTX 5060 Ti 16 ГБ на 180 Вт) плюс 128 ГБ DDR5. Это сетап человека, который сознательно собирает систему под одну модель.
Почему в 0.2.0 акцент на качестве, а не на скорости
Автор релиза пишет прямо: скорость остаётся заголовком, но начинать он хочет с качества. Логика простая. Пока квант свежий, разница между NVFP4 и BF16 на коротком ответе почти не видна. Она проявляется позже: в длинных текстах, где ошибки накапливаются, в структурном выводе с жёстким форматом и в вызовах инструментов, где один неверный токен ломает весь JSON.
Замеры KLD и top-1 дают числовую опору вместо «на глаз стало хуже». Это не заменяет проверку на своих задачах, но позволяет сравнивать форматы между собой и понимать цену экономии памяти.
Что такое KLD и top-1 простыми словами
KLD (KL-дивергенция) показывает, насколько распределение вероятностей квантованной модели отличается от распределения полнопрецизионного референса на одном и том же тексте. Чем меньше значение, тем ближе поведение: 0.02 и 0.15 расходятся в разы, и на практике это обычно заметно.
Совпадение top-1 - доля позиций, где квантованная модель выбрала тот же следующий токен, что и референс. Метрика грубее: она смотрит только на первый вариант в распределении и не видит, насколько уверенно модель ошибается. Поэтому в релизе приводят обе цифры: KLD чувствительнее, top-1 понятнее без подготовки.
Ни одна из метрик не отвечает на вопрос «стало ли хуже на моей задаче». Они дают воспроизводимую базу для сравнения форматов, и в этом их ценность.
Замеры качества: как читать таблицу KLD и top-1
Методика в релизе описана явно. Все новые замеры считаются относительно полнопрецизионной модели BF16, которую обслуживает llama.cpp, с reference PPL 3.2749. Использован Unsloth BF16 GGUF, оценка шла через basalt-bench --quality. Прошлая база сравнения была другой, llama.cpp Q8, и, по словам автора, её собственная ошибка делала результаты хуже, чем они есть. Исходные таблицы и условия замера собраны в посте автора.
| Формат | KLD | Совпадение top-1 |
|---|---|---|
| llama.cpp Q8 | 0.0325 | 93.98% |
| Basalt Q8 | 0.0200 | 95.34% |
| NVFP4-DQ8 (новый) | 0.0561 | 92.25% |
| NVFP4-DQ6_K | 0.0624 | 91.65% |
| GSQ-RCO IQ3_S | 0.1497 | 87.56% |
Отдельная цифра, важная для доверия к движку: все прочие округления, которые делает Basalt, стоят около 0.001 KLD или меньше относительно полной модели. Основной вклад в расхождение даёт сам формат квантования, а не внутренние оптимизации.
NVFP4-DQ8 против NVFP4-DQ6_K: что показывают цифры
По KLD разница ощутимая: 0.0561 против 0.0624, то есть примерно на 10% ниже у DQ8. По top-1 куда скромнее: 92.25% против 91.65%, около 0.6 процентного пункта. Цена - примерно 7% скорости на прозе. Файл Qwen3.8-FN-NVFP4-DQ8 лежит на Hugging Face рядом с дефолтным DQ6_K, так что оба варианта доступны без пересборки модели.
Практический критерий такой. DQ8 разумен там, где важнее формулировки и структура: длинные тексты, генерация кода, ответы по жёсткому шаблону, вызовы инструментов. DQ6_K остаётся дефолтом для массовой генерации, чатов и всего, где вы упираетесь в скорость, а не в точность. Прибавка 0.6 п.п. по top-1 сама по себе редко оправдывает 7% просадки throughput, а вот в связке со снижением KLD выбор перестаёт быть вкусовым.
Оговорка по цифрам: 7% измерены на прозе. Для структурного вывода и разговорных задач отдельных замеров скорости DQ8 в релизе нет, поэтому переносить эту оценку на все сценарии не стоит.
И ещё одно: качество на бумаге и качество в рабочем пайплайне расходятся. Разбор 500+ заданий по кодингу, pandas, анализу данных и локальному RAG на AI-Manual показывает, как по-разному ведут себя модели с близкими заявленными возможностями на одном и том же железе (тест Qwen3.8 27B и других моделей).
Почему GSQ-RCO IQ3_S не стоит выбирать ради качества
В той же таблице GSQ-RCO IQ3_S даёт KLD 0.1497 и top-1 87.56%. Это худшие показатели среди приведённых форматов: почти втрое дальше от референса, чем NVFP4-DQ8. Формат живёт в другой нише, когда памяти катастрофически мало и лучше получить ответ с потерями, чем не получить его вовсе.
В релизе с акцентом на качество такая строка нужна как точка отсчёта: она показывает, насколько глубоко может просесть модель при агрессивном сжатии. На Blackwell экономить память ценой KLD 0.15 почти не имеет смысла, если только вы не упираетесь в потолок VRAM. Как KL-дивергенция соотносится с реальной работой на задачах, видно в разборе GSQ против ByteShape на RTX 3060 12 ГБ: один низкобитный квант закрыл 3D-задачу меньше чем за 55K токенов, второй не справился и за 98K.
Скорость на практике: RTX 5090 + RTX 5060 Ti 16 ГБ, 262K контекст
Скоростные прогоны сделаны на конкретной сборке: RTX 5090 (400 Вт) плюс RTX 5060 Ti 16 ГБ (180 Вт), 128 ГБ DDR5, контекст 262K, 4 параллельных слота, vision on (dynamic), без lossy-флагов, квант NVFP4-DQ6_K на актуальной main-ветке. На каждый сценарий по два прогона, результаты сведены в таблицу релиза.
| Сценарий | Прогон 1, tok/s | Прогон 2, tok/s |
|---|---|---|
| Проза | 295.0 | 299.9 |
| Разговорные задачи | 363.8 | 321.9 |
| Структурные задачи | 603.7 | 594.2 |
| Prefill 16K | 7432 | 8159 |
| Prefill 64K | 10221 | 10229 |
Две колонки здесь важнее среднего: разброс между прогонами доходит до 12% (363.8 против 321.9 tok/s на разговорных задачах), и для замера в один прогон это нормальный шум. Prefill на 64K держится ровно (10221 и 10229 tok/s), на 16K заметно ниже и менее стабилен (7432 и 8159 tok/s). Структурный вывод почти вдвое быстрее прозы, что логично при спекулятивном декодировании на предсказуемых шаблонах.
Почему за неделю стало быстрее
По словам автора, проза выросла с 277 до примерно 300 tok/s, структурные задачи с 558 до примерно 600 tok/s. Причины названы конкретные: более быстрый draft-шаг, более быстрая выходная голова и лучшее размещение экспертов при запуске. Экстраполировать этот темп не стоит: речь про неделю оптимизаций одного человека, а не про гарантированный тренд.
Как перенести эти цифры на свой сетап
Конфигурация специфична: две карты разного класса, 128 ГБ системной памяти, контекст 262K и четыре параллельных слота. На одной видеокарте, с меньшим объёмом RAM или другим контекстом цифры будут другими, причём в обе стороны. Ориентируйтесь на порядок величин и на соотношение сценариев: проза около 300 tok/s, структурный вывод около 600 tok/s, prefill в диапазоне 7-10 тысяч tok/s в зависимости от длины промпта.
Если Blackwell в системе нет, полезны другие точки отсчёта. Например, тест кастомного CPU-движка для Qwen3.5 0.8B на Ryzen 9 9955HX3D в Linux даёт до 2,9x по prefill против llama.cpp (разбор H128/Q4-G32-DOT4).
Формат .basalt v2 и миграция старых файлов
Формат .basalt обновлён до версии 2. Веса и качество те же, что и раньше, меняется скорость запуска: файл читается и поднимается немного быстрее. Для тех, у кого уже лежат файлы первой версии, в релизе предусмотрен инструмент миграции. Точный синтаксис и флаги в описании релиза не приводятся, поэтому команды стоит смотреть в репозитории движка, а не подставлять по памяти.
Практический смысл скромнее, чем у нового кванта, но для регулярной работы заметен. Миграция переводит старый файл в актуальный формат, качество модели при этом не меняется, поэтому перепроверять выводы после обновления не нужно. Если вы поднимаете движок несколько раз в день или гоняете его в контейнере, разница по времени холодного старта накапливается.
Насколько честно сравнение с llama.cpp
Сравнение движков велось разными инструментами, и это главная оговорка всего материала. BF16-референс обслуживает llama.cpp, а оценка идёт через basalt-bench --quality: методики у Basalt и llama.cpp не идентичны. Поэтому пара строк «Basalt Q8 против llama.cpp Q8» (0.0200 против 0.0325 по KLD, 95.34% против 93.98% по top-1) показывает разницу в конкретном замере, а не превосходство движка во всех сценариях.
История с прошлой базой добавляет скепсиса. Раньше сравнение шло против llama.cpp Q8, и, по словам автора, ошибка самой базы делала результаты хуже. Переход на BF16 через llama.cpp методику улучшил, но не убрал разницу в инструментах и не превратил замер в независимый аудит.
Что из этого следует практически. Цифры релиза внутренне согласованы: один референс, один инструмент оценки, одинаковые условия. Их корректно использовать для выбора между квантами и для отслеживания прогресса версий. Вывод «Basalt точнее llama.cpp вообще» из них не вытекает. Тот же подход стоит держать в голове при чтении бенчмарка семи движков на одной RTX 5090, где Basalt обошёл Infernix примерно на 10% в прозе и сравнялся на структурном выводе.
Стоит ли переходить на Basalt 0.2.0: практический вывод
Решение зависит от двух условий: архитектура GPU и модель. Если у вас Blackwell и вы гоняете Qwen 3.8 Flash Next, релиз даёт реальный выбор. NVFP4-DQ8 берите под задачи, где важна точность формулировок и структура: KLD 0.0561, top-1 92.25%, минус примерно 7% скорости на прозе. NVFP4-DQ6_K остаётся дефолтом для throughput: KLD 0.0624, top-1 91.65%. Сверху идёт ускоренный запуск за счёт .basalt v2 и миграция старых файлов.
Если у вас другая архитектура или другая модель, Basalt не подойдёт, и это не недостаток версии, а её рамки: движок сознательно заточен под один класс железа и одну модель. Тогда материал остаётся полезен как пример того, как вендор показывает качество квантования числами, а не обещаниями.
Тем, кто гонится за скоростью, стоит помнить: lossy-опции в Basalt выключены по умолчанию и включаются с предупреждением. Штатные округления движка стоят около 0.001 KLD или меньше, а вот агрессивные «хаки» в эту статистику не входят, и их влияние на качество в релизе не измерено.
Что сделать дальше: сверить KLD нужного формата в таблице, прогнать basalt-bench --quality на своих типовых промптах и только потом менять дефолтный квант. Для чата и массовой генерации чаще достаточно DQ6_K, для длинных текстов и структурного вывода разница в пользу DQ8 стоит своих 7% скорости.