Сторонний NVFP4 против официального FP8 на Qwen3.8-27B: 1.35× быстрее

Прогнал на арендованной RTX PRO 6000 (96 ГБ, Blackwell) полный кросс-движковый прогон на Qwen3.8-27B: vLLM, NVFP4-чекпойнт от unsloth (community-квант, не официальный релиз) против официального Qwen/Qwen3.8-27B-FP8, MTP включён и выключен, и отдельно SGLang с DSpark сверху. По throughput число чистое и backend-controlled: мой NVFP4-чекпойнт быстрее официального FP8 в 1.35 раза (643 против 476 ток/с — это агрегатная пропускная способность при concurrency 16, 1024 входных / 256 выходных токенов, не скорость одного запроса), MTP добавляет ещё 16–19% на любом кванте. Дальше начались проблемы — не с картой, а с моей собственной интерпретацией результата.

Ошибки в сборке замера, обнаруженные до принятия результатов

Прежде чем принять результаты хоть одного прогона, харнесс для замера качества (lii-code-bench-ru, 50 реальных архитекторских задач) споткнулся четыре раза подряд:

→ Скачивание второго чекпойнта (RadixArk) затёрло уже загруженный (unsloth) — оба резолвились в одну и ту же папку по совпадающему basename, config и tokenizer оказались перезаписаны чужими. Поймал за две минуты, пока arm 1 уже гонял против рассинхронизированного чекпойнта. → Ни в одном из моих запусков за два дня не было флагов для tool-calling. Задача на вызов инструмента падала с 400. → Мой конфиг по умолчанию выключал reasoning — притом что в собственном CHANGELOG репозитория уже был зафиксирован прецедент: прогон с выключенным reasoning признан невалидным. → И главное: на этих 50 задачах бюджета в 4096 токенов на ответ регулярно не хватало — 13–15 задач из 50 в каждом прогоне обрывались пустым ответом, весь бюджет уходил в размышление.

Первые три поправил до того, как что-либо засчиталось. Четвёртую — нет: бюджет намеренно оставил как есть, для сравнимости с существующей доской, так что обрывы остаются в каждом посчитанном прогоне. Ни одна из этих проблем не в модели. Все — в моей собственной сборке замера.

Качество: диапазон есть, приговора нет

Среди задач, на которые модель вообще ответила — за вычетом 13–15 из 50, у которых бюджет в 4096 токенов кончался на размышлении раньше, чем начинался ответ, — все четыре конфигурации легли в диапазон 0.743–0.792 (простое среднее, без весов задач). Большого провала, которого я боялся после AWQ, в этом срезе не видно. Но это не паритет NVFP4/FP8: диапазон посчитан только по отвеченным задачам и без весов, при одном прогоне на конфигурацию — а сырые баллы по доске (0.605 / 0.580 / 0.549 / 0.628, взвешенные по методике харнесса) пересекаются нелогично: NVFP4-чекпойнт обгоняет FP8 без MTP и проигрывает с MTP. Часть разницы между двумя наборами чисел — от смены взвешенного среднего на простое, не только от исключения обрывов. При n=1 это либо шум, либо реальное взаимодействие кванта со спекулятивным декодингом — не различить.

Судья один (Gemini), не ансамбль — на моей исторической доске сравнимых прогонов с тем же судьёй на этой модели нет. Честно: вопрос не закрыт. Нужен повтор минимум в три прогона на конфигурацию — то же самое, что уже сделал для throughput-матрицы.

SGLang и DSpark — тоже без сенсаций

Community заявляла 200+ ток/с single-stream на этой же паре чекпойнт+карта через SGLang с DSpark. Не воспроизвелось — наблюдал 68→126 ток/с (×1.85), по одному замеру на конфигурацию, повтор не делал. На batch-16 throughput SGLang не отстаёт драматично от vLLM (603 против 643), но это разные чекпойнты (RadixArk/NVIDIA ModelOpt для SGLang, unsloth для vLLM) на разных стеках — не сравнение движков при равном кванте, и SGLang не закреплён по backend так же жёстко, как число vLLM.

Меня поправляли дважды — и по делу

Первый черновик этого текста называл ninfer (сторонний движок под RTX 5090) «подтверждённо несовместимым». Неправда — cmake реально упал из-за нехватки CUDA 13.1 (у меня 13.0.3, это факт), но заявление README про специфичность под конкретную карту я так и не проверил сборкой — до неё просто не дошло. Ушло в репозиторий как «подтверждённая несовместимость», поймали на ревью, поправил коммитом позже.

Второй случай хуже. Сравнивал Qwen3.8 с моделью, подписанной в старой доске как «qwen36» — предположил по аналогии с меткой, что это Qwen3.6-27B того же класса. Манифест не проверил. Оказалось — Qwen3.6-35B-A3B, другая архитектура, другой размер, да ещё и reasoning на том прогоне был выключен. Сравнение целиком оказалось нерабочим. Успел до публикации: ушло в чат, не в git.

Что дальше

→ Повтор оценки качества в три прогона — закрыть вопрос про пересечение NVFP4/FP8×MTP → Параллельно идёт прогон Qwen3.8 через OpenRouter — тот же харнесс, тот же набор задач, три судьи вместо моего одного, сравнимо с исторической доской. Отдельный прогон обновит доску, когда завершится. → ninfer остаётся на паузе — второй стек CUDA ради непроверенного README не стоит потраченного времени без реальной причины форсировать сборку.