Публичных бенчмарков, которые показали бы деградацию качества Basalt, Infernix и Strata-nvfp4, в доступных материалах нет. Вопрос, из которого выросла тема, сформулирован именно так: нужны замеры качества, а не очередное «движок выдаёт больше токенов» исходное обсуждение в r/LocalLLaMA. Отсюда практический вывод: решать, стоит ли менять strata-nvfp4 на более быстрый вариант и не платить ли за это неприемлемыми потерями, придётся на собственных замерах.
Что известно о Basalt из того же обсуждения: динамического масштабирования RoPE у него нет, yarn-скейлинг задан статически со значением 2 для контекста 524K и действует с самого старта; переключателя цензуры нет, хотя соответствующий механизм в системе уже есть и дописать его несложно там же. Про Infernix и Strata-nvfp4 известно ещё меньше: оба названы участниками сравнения, без конфигураций и цифр. Ниже - методика, которая даёт свои числа вместо ожидания чужих.
Есть ли бенчмарки деградации качества для Basalt, Infernix и Strata-nvfp4
Короткий ответ: нет. Ни одного замера вида «до квантизации столько, после столько» по этим трём вариантам в исходных материалах не приводится. Есть запрос на такие замеры и есть отдельные наблюдения по Basalt. Этого достаточно, чтобы обозначить проблему, но недостаточно для вывода «быстрый вариант теряет N% качества».
Разбираться всё равно нужно, потому что выбор между вариантами инференса делается каждую неделю: обновилась сборка движка, поменялся формат весов, включили новый режим префилла. Без собственного набора тестов решение принимается на ощущениях, а ощущения на длинных задачах обманывают чаще, чем хотелось бы.
Почему метрики скорости не отвечают на вопрос о качестве
tokens/s показывает, сколько токенов модель генерирует за секунду. TTFT (время до первого токена) отражает скорость обработки промпта. Throughput в батче говорит, сколько параллельных запросов переваривает сервер. Все три величины измеряют время и железо. Способности модели они не описывают никак: движок может выдавать в разы больше токенов и при этом терять точность на извлечении факта из документа.
Источники компромисса почти всегда одни и те же. Первый - формат весов. NVFP4 хранит веса в 4 битах, и такое сжатие требует отдельной проверки на ваших задачах. Второй - агрессивные режимы инференса: квантование KV-кэша, ускоренный префилл, упрощённые ядра внимания. Третий - настройки позиционного кодирования, о которых ниже.
Скоростные заявления при этом часто не измерены, а оценены на глаз. Показательный разбор такого случая есть в материале про ускоренный prefill через KV-кэш: там видно, как легко перепутать заявленное ускорение с подтверждённым и где перенос на 27B упирается в железо.
Что известно о Basalt, Infernix и Strata-nvfp4 на сегодня
Сводка фактов без домыслов выглядит скромно.
| Вариант | Что подтверждено | Чего нет |
|---|---|---|
| Basalt | Нет динамического масштабирования RoPE: yarn-скейлинг статический, значение 2 для контекста 524K. Нет переключателя цензуры, хотя механизм в системе реализован | Отчёта с бенчмарками качества, официальной документации по этим пунктам |
| Infernix | Упомянут в вопросе о сравнении деградации качества | Характеристик, конфигураций, любых цифр |
| Strata-nvfp4 | Упомянут как базовая точка, относительно которой обсуждают ускорение | Данных о потерях при переходе с него на другие варианты |
Сведения о Basalt - это пользовательское наблюдение из обсуждения, а не отчёт разработчика. Для практики такой статус значит простую вещь: проверять нужно самому, особенно на длинном контексте.
Какие метрики качества смотреть при сравнении быстрых вариантов инференса
Главное правило: сравнивать варианты на одном и том же наборе промптов, при одинаковых параметрах сэмплирования, на одном и том же железе. Любое изменение условий ломает сравнение быстрее, чем любая деградация модели. Набор метрик удобно держать перед глазами в виде таблицы.
| Метрика | Что показывает | Где обманывает |
|---|---|---|
| Perplexity на вашем корпусе | Насколько уверенно модель предсказывает токены в вашем домене | Слабо реагирует на потерю рассуждений и формата, сильно зависит от состава текста |
| Accuracy на задачах-ловушках | Точность извлечения факта, арифметики, следования инструкции | На маленькой выборке разброс шире самой деградации |
| Качество на длинном контексте | Работает ли модель на глубине контекста, а не только на первых абзацах | Один документ не описывает всё разнообразие ваших данных |
| Доля валидного JSON и стабильность схемы | Держит ли модель формат под нагрузкой | Валидный JSON ещё не значит правильный по смыслу |
| Прохождение тестов в коде | Функциональная корректность на краевых случаях | Зависит от качества самих тестов, а не только от модели |
Perplexity берут как грубый индикатор: она дёшева и считается быстро, но плохо различает варианты, которые одинаково гладко пишут текст и по-разному решают задачи. Если perplexity у быстрого варианта выросла незначительно, а accuracy на ваших ловушках просела на несколько пунктов, ориентироваться стоит на второе.
Задачи-ловушки: как поймать потерю качества на практике
Деградация проявляется не в свободном чате, а там, где нужен точный ответ. Рабочий набор собирается из четырёх типов задач.
- Извлечение факта из длинного документа: вопрос, ответ на который лежит в середине текста, а не в начале.
- Жёсткий формат: ответ строго по схеме, с фиксированными полями, без лишнего текста вокруг.
- Многошаговые вычисления: задача, где ошибка на втором шаге портит весь результат.
- Код с краевыми случаями: функция плюс тесты, включая пустой ввод, отрицательные значения, отсутствие поля.
Такие задачи чувствительнее к квантизации весов и к настройкам позиционного кодирования, потому что требуют точной работы с деталями, а не общей связности. Набор должен отражать ваши сценарии: тесты из чужой предметной области покажут чужую деградацию.
Как отделить деградацию от шума генерации
Единичный прогон почти ничего не значит. Один и тот же промпт при температуре выше нуля даёт разные ответы, и разница между двумя вариантами модели легко тонет в этой вариативности. Практическая схема такая.
- Зафиксируйте температуру и seed. Для воспроизводимости удобнее жадная генерация, для реалистичности - фиксированный seed при рабочей температуре.
- Прогоните каждый тест несколько раз, минимум пять, лучше десять.
- Смотрите на распределение: долю правильных ответов и разброс, а не на самый удачный ответ.
- Сравнивайте дельту между вариантами на одном наборе, а не абсолютные баллы с чужими отчётами.
Если разница укладывается в разброс между прогонами одного варианта, деградацией это называть рано. Про то, почему цифру с композитного набора нельзя напрямую сопоставлять с отчётами другого провайдера, подробно разобрано в материале про независимое сравнение квантованных моделей на композитном наборе.
Статический yarn-скейлинг RoPE в Basalt: что это и почему это важно
RoPE кодирует позицию токена через поворот векторов запроса и ключа. Чем дальше токен от начала, тем на больший угол поворачивается его представление, и внимание получает информацию о взаимном расположении слов. Модель обучается на определённой длине, и на этой длине углы распределены привычным образом.
Yarn-скейлинг растягивает позиционное кодирование, чтобы модель работала на контексте длиннее обученного. Грубая аналогия: линейку с привычными делениями перерисовывают так, чтобы на ней поместилось больше отметок, и модель учится читать эти новые отметки. В Basalt такой скейлинг задан статически со значением 2 для контекста 524K и действует с самого начала, без подстройки под фактическую длину входа.
Чем динамическое масштабирование RoPE отличается от статического
Динамический вариант подстраивает коэффициент растяжения под реальную длину промпта: короткий запрос обрабатывается почти без растяжения, длинный получает полный коэффициент. Статический вариант применяет одно и то же значение всегда.
Разница в том, что при статической настройке короткий промпт получает те же искажённые позиционные соотношения, что и промпт на сотни тысяч токенов. Растяжение, нужное для длинного документа, применяется там, где растягивать нечего. Насколько это критично для конкретной реализации, зависит от того, как именно масштабируются частоты и как модель обучалась, поэтому корректный ответ даёт только замер на ваших промптах.
Как статический скейлинг может проявляться на коротких, средних и длинных контекстах
Разделим сценарии, чтобы было что проверять.
Короткий чат. Промпт на пару тысяч токенов. Здесь статический коэффициент работает вхолостую, и разумно проверить базовые вещи: не путает ли модель порядок реплик, не теряет ли инструкцию из системного сообщения, стабилен ли формат ответа.
Средний контекст. Несколько страниц документа, кодовая база модуля, стенограмма встречи. Проверка: вопросы, ответы на которые разбросаны по тексту, и задачи на сопоставление фрагментов из разных частей.
Длинный контекст вблизи заявленных 524K. Здесь основной тест - поиск факта на разной глубине: в начале, в середине, ближе к концу вставки. Полезно добавить вопрос, ответ на который прямо противоречит утверждению из первых абзацев: модель должна опереться на более поздний фрагмент.
Влияние статического yarn-скейлинга на разных длинах контекста в исходных материалах не измерено. Всё, что выше, - гипотезы для проверки, а не подтверждённые результаты.
Практика длинного контекста без динамического RoPE: где возникают компромиссы
Сценарии, в которых это важно, легко узнать по описанию задачи. RAG с длинными вставками найденных фрагментов. Анализ договоров и техдокументации. Поиск по большому репозиторию. Суммаризация расшифровок и больших массивов переписки. Во всех случаях модель получает десятки тысяч токенов и должна вытащить из них конкретику.
Что стоит проверить отдельно, если вы работаете на Basalt с длинными промптами.
- Извлечение факта с разной глубины: одна и та же вставка ставится в начало, в середину и в конец промпта, вопрос не меняется.
- Следование инструкции, заданной в начале длинного промпта: формат ответа, запрет на лишние пояснения, обязательные поля.
- Поведение при сокращении вставки: если на 100K токенов качество проседает, а на 20K держится, вы нашли практическую границу для своей задачи.
- Стабильность на повторных прогонах: одинаковая ли доля правильных ответов при разном порядке фрагментов.
Заявленный контекст 524K - это техническая граница, до которой движок согласен принять промпт. Она не гарантирует, что модель одинаково хорошо использует весь диапазон. Полагаться на неё без собственных замеров рискованно: цена ошибки на длинном документе выше, чем экономия на пропущенных токенах. Общая логика соотношения размера контекстного окна, KV-кэша и доступной VRAM разобрана в статье о том, как контекст и стоимость инференса влияют на выбор модели.
Стоит ли менять strata-nvfp4 на более быстрый вариант: как принять решение
Вопрос «не плачу ли я неприемлемыми потерями за ускорение» решается только через порог, заданный заранее. Пока порог не сформулирован, любая разница будет казаться то шумом, то катастрофой.
Порядок действий выглядит так. Сначала определите тип задачи и допустимую цену ошибки. Свободный чат прощает потерю нескольких процентов точности, извлечение реквизитов из договора не прощает ничего. Затем зафиксируйте базу: прогоните набор на strata-nvfp4 и сохраните ответы. После этого прогоните тот же набор на быстром варианте и сравните дельту по каждой метрике отдельно.
Ускорение почти всегда оправдано на черновых и массовых операциях: разметка, переформулировка, первичная фильтрация. Оно редко оправдано там, где ответ проверяется дорого: юридические формулировки, генерация кода без тестов, извлечение чисел из таблиц. Разница в скорости при этом может быть значительной, а потеря качества - узкой и заметной только на одном типе задач. Именно поэтому решение принимают по задаче, а не «в целом по модели».
Отдельно стоит посмотреть, какие ускорения вообще дают прирост без изменения весов и какие регрессии при этом вылезают: в материале про ускорение MoE-инференса патчами llama.cpp собраны и приросты, и найденные побочные эффекты.
Отсутствие переключателя цензуры в Basalt: что это значит на практике
В Basalt нет переключателя цензуры, хотя соответствующий механизм в системе есть и дописать переключатель несложно. Формулировка важна: это ограничение конфигурации, а не приговор модели. Механизм отказов работает, управлять им снаружи нельзя.
Для одних сценариев это не имеет значения: корпоративная поддержка, работа с открытыми данными, учебные задачи. Для других критично. Если вы строите пайплайн, где поведение модели на чувствительных темах должно быть предсказуемым и настраиваемым, отсутствие переключателя придётся учитывать в архитектуре: ставить внешний фильтр, писать собственные инструкции, проверять ответы на выходе.
Связь с общей темой прямая. При выборе быстрого варианта смотрят не только на качество ответов, но и на управляемость поведения. Вариант, который на 10% точнее на ваших тестах, но не даёт настраивать отказы, может оказаться менее удобным в продукте. Обещать появление переключателя в Basalt никто не может: в исходных материалах сказано только, что дописать его несложно.
Чек-лист оценки деградации качества для своего сценария
Готовых бенчмарков по Basalt, Infernix и Strata-nvfp4 нет, поэтому чек-лист становится основным инструментом. Он же пригодится при следующем обновлении движка.
- Опишите сценарий и порог приемлемых потерь: что именно вы готовы потерять ради скорости.
- Соберите набор задач-ловушек из своих данных: извлечение факта, жёсткий формат, многошаговые вычисления, код с краевыми случаями.
- Зафиксируйте параметры сэмплирования и seed, запишите их вместе с результатами.
- Прогоните strata-nvfp4 как базу и сохраните ответы дословно.
- Прогоните быстрый вариант на том же наборе при тех же параметрах.
- Проверьте длинный контекст отдельно: факт на разной глубине, инструкция в начале промпта, поведение при сокращении вставки.
- Проверьте короткие и средние промпты: не появилось ли регрессий там, где раньше всё работало стабильно.
- Сравните дельту с учётом разброса между прогонами, а не по одному удачному ответу.
- Оцените управляемость: настройки поведения, отказы, стабильность формата.
- Примите решение по конкретной задаче и запишите его вместе с результатами замеров.
Практический ориентир по сбору такого набора есть в разборе сравнения компактных моделей по latency, tokens/s и качеству: там показано, как отделять скорость от полезности на собственном наборе задач. Начните с одного сценария и десяти ловушек, а не с большого бенчмарка: первые замеры нужны для решения, а не для отчёта.