Итог сравнения движков для Qwen 3.8 FN на одной RTX 5090
На одной RTX 5090 с лимитом мощности 400 Вт и 128 ГБ RAM быстрее всех Qwen 3.8 FN обслуживают Basalt и Infernix. Декодирование на прозе: 180 ток/с против 163. На диалоге: 188 против 170. Это примерно по 10% в пользу Basalt. На структурном выводе (JSON, таблицы, размеченные ответы) движки почти равны: 354 против 349 ток/с, то есть разрыв меньше погрешности.
Читать эти цифры стоит с поправкой на один факт: сравнение опубликовал разработчик Basalt, то есть автор замера одновременно заинтересован в победе одного из участников. Это не отменяет измерения, но требует осторожности в выводах и проверки на собственных задачах.
Дальше разбираем методику, три сценария декодирования, поведение движков на глубине контекста 25K, 50K, 100K и 200K токенов, ограничения теста и практический выбор движка под конкретную нагрузку.
Что именно сравнивали: семь движков, одна видеокарта, одна модель
В сравнении участвовали семь движков: Basalt, Infernix, capy-flash, Strata, ninfer-ext, ninfer и llama.cpp. Железо одно: RTX 5090 с ограничением мощности 400 Вт, 128 ГБ RAM, Linux. Модель Qwen 3.8 FN в NVFP4-весах NVIDIA, при этом каждый движок конвертировал исходные веса своим инструментом. Полной идентичности конфигураций это не гарантирует, хотя исходный формат у всех был одинаковый.
Условия замеров автор описал так: семь одинаковых запросов с жадным сэмплированием (temperature 0), холодный старт на каждый запрос, отключённый thinking, int8 KV cache у всех движков, кроме llama.cpp, где стоял f16 KV. Ссылка на публикацию с таблицами и текстом выводов: отчёт в r/LocalLLaMA.
Метрики две. Декодирование в ток/с на трёх типах задач: проза, диалог, структурный вывод. И время до первого токена на глубине 25K, 50K, 100K и 200K токенов, где префикс собирался из wikitext, а запросом служила одна и та же фраза «Write an essay on the Odyssey.» с выводом 512 токенов.
Почему отключённый MTP в llama.cpp ломает сравнение
MTP (multi-token prediction) это вариант спекулятивного декодирования: модель за один шаг предлагает несколько токенов, а проверка подтверждает или отбрасывает их пачкой. На коротких и средних ответах такая схема заметно поднимает ток/с, потому что уменьшает число последовательных проходов через модель.
В этом бенчмарке llama.cpp работал с выключенным MTP, а остальные движки использовали эту технику. Автор прямо называет llama.cpp точкой отсчёта и говорит, что его декодирование несопоставимо с остальными участниками. Поэтому 39 ток/с у llama.cpp на прозе и структурном выводе не приговор движку: это другой режим работы. Как MTP, NVFP4 и int8 KV cache влияют на реальную скорость, подробно разобрано в материале про запуск Qwen 3.8 27B на одной RTX 5090.
Скорость декодирования: где Basalt и Infernix действительно расходятся
Три сценария дают разную картину, и это важнее, чем итоговое место в таблице.
| Задача | Basalt, ток/с | Infernix, ток/с | capy-flash, ток/с | llama.cpp (MTP off), ток/с |
|---|---|---|---|---|
| Проза | 180 | 163 | н/д | 39 |
| Диалог | 188 | 170 | н/д | н/д |
| Структурный вывод | 354 | 349 | 292 | 39 |
Проза и диалог: около +10% у Basalt. Для интерактивной работы с текстом это ощутимая, но не революционная разница. Ответ на 500 токенов при 180 ток/с занимает примерно 2,8 с, при 163 ток/с примерно 3,1 с. Разница в треть секунды на глаз почти не читается.
Структурный вывод: 354 против 349 ток/с. Автор отдельно оговаривает правило интерпретации, декодирование варьируется между запусками, поэтому разрывы меньше 5% он считает ничьей. Пять ток/с здесь укладываются в этот порог. Практический смысл простой: если вы генерируете JSON для агентного пайплайна, выбирать между Basalt и Infernix по скорости бессмысленно, смотрите на стабильность, удобство API и поведение на ваших промптах.
Отдельно стоит отметить высокие абсолютные значения на структурном выводе, 349-354 ток/с против 180-188 на прозе. Это типичная картина для предсказуемой разметки: короткие частые токены фигурных скобок, ключей и отступов предсказывать проще, спекулятивное декодирование на них срабатывает чаще.
capy-flash показал 292 ток/с на структурном выводе, лучший результат среди движков вне пары лидеров. Но этот движок рассчитан в основном на две GPU, так что запуск на одной карте для него не оптимальный режим.
Глубина контекста: как меняется время до первого токена
Здесь измеряли префилл, то есть обработку входного контекста перед генерацией. Именно префилл определяет, как быстро вы увидите первый токен ответа при работе с длинным документом, в RAG-сценарии или при анализе большого файла. Декодирование в этот момент ещё не началось, поэтому «медленный старт» ощущается как зависший интерфейс.
| Глубина контекста | Basalt, с до первого токена | Infernix, с до первого токена | llama.cpp, с до первого токена |
|---|---|---|---|
| 25K токенов | 3,94 | 3,94 | н/д |
| 50K токенов | 6,65 | 7,79 | н/д |
| 100K токенов | 11,81 | 15,43 | н/д |
| 200K токенов | 23,79 | 31,81 | 162,86 |
До 25K токенов движки идут вровень, одинаковые 3,94 с у обоих. С 50K Basalt отрывается: 6,65 против 7,79, то есть примерно на 15% быстрее. На 100K разрыв растёт до 11,81 против 15,43, около 23%. На 200K это уже 23,79 против 31,81, преимущество около 25% и почти восемь секунд абсолютной разницы в момент, когда пользователь ждёт реакции на большой документ.
Отрыв нарастает с глубиной, а не появляется сразу. Для практики это значит, что на промптах до 25K токенов выбор между лидерами по скорости префилла не даёт ничего, а на 100K и выше разница уже заметна в работе. Числа по глубине подтверждены в том же отчёте автора бенчмарка.
llama.cpp на 200K потратил на префилл 162,86 с. Это больше двух с половиной минут ожидания до первого токена, причём с f16 KV cache, который сам по себе тяжелее int8 и требует больше памяти.
Остальные движки: почему они оказались позади
Полных таблиц по Strata, ninfer-ext и ninfer в публикации нет в разобранном виде, поэтому конкретные значения по ним здесь не приводятся: без цифр любые оценки были бы догадками. Общий вывод автора однозначный, эта группа уступает Basalt и Infernix.
По capy-flash данных больше. Движок занял третье место по декодированию и показал 292 ток/с на структурном выводе, но проектировался под конфигурацию из двух GPU. Замер на одной RTX 5090 показывает нижнюю границу его возможностей, а не реальный потолок. Если в вашей машине две карты, ориентироваться на этот результат не стоит.
Картина с кастомными движками под одну конкретную модель уже не первый случай: похожие узкоспециализированные решения появлялись и на другом железе, включая пример с CPU-движком для модели на 0,8B. Логика одинаковая: оптимизация под одну архитектуру и один формат весов даёт прирост, но привязывает пользователя к конкретной связке.
Насколько можно доверять этому бенчмарку
Ограничения лучше держать в голове до того, как принимать решение по таблицам.
- Конфликт интересов. Автор сравнения разрабатывает Basalt, то есть движок, который победил. Сам он заявляет о стремлении к честному замеру, но независимой проверки этих цифр нет.
- Разные инструменты конвертации. Каждый движок переводил NVFP4-веса своим конвертером, поэтому идентичность конфигураций весов не гарантирована.
- Разный KV cache. У llama.cpp стоял f16 KV против int8 у остальных, что влияет и на память, и на скорость обработки длинного контекста.
- Разброс между запусками. Автор прямо говорит, что декодирование варьируется от запуска к запуску, и разрывы меньше 5% считает ничьей.
- capy-flash вне оптимального режима. Одна GPU не его сценарий, результат занижен по построению.
- Узкая выборка. Одна модель, одна видеокарта, один набор из семи запросов и один запрос для глубинных тестов. Экстраполировать это на другие модели, другие кванты и другие типы нагрузки нельзя.
Общий принцип чтения чужих замеров хорошо виден на другом примере: в разборе тестов DeepSeek V4.1 Flash на восьми A40 половина ценности материала приходится именно на границы применимости цифр, а не на сами tok/s.
Практические выводы: какой движок выбрать под свою задачу
Длинный контекст, RAG, разбор больших документов на 50K токенов и выше. По этому бенчмарку Basalt предпочтительнее: преимущество в префилле растёт с глубиной и достигает примерно 25% на 200K. Разница в восемь секунд до первого токена на большом документе заметна, особенно если запросов много.
Генерация прозы и диалогов. Отрыв около 10% в пользу Basalt. Приятно, но редко служит единственным аргументом: если ваш пайплайн уже построен вокруг Infernix, переезд ради 17 ток/с на прозе вряд ли окупится.
Структурный вывод, JSON, агентные пайплайны. Basalt и Infernix равноценны по скорости, 354 против 349 ток/с при пороге ничьей в 5%. Выбирайте по удобству API, стабильности, поддержке нужного формата весов и качеству обработки ошибок.
Две видеокарты. Смотрите в сторону capy-flash, но с отдельными замерами на своей конфигурации: результат на одной RTX 5090 про его потенциал ничего не говорит.
Вы уже работаете на llama.cpp. Сравнивать свои ток/с с цифрами этого бенчмарка нельзя: у llama.cpp был выключен MTP. Чтобы понять разницу, нужен отдельный замер с включённым MTP на вашей конфигурации.
Общее правило остаётся неизменным. Это один замер от заинтересованного автора на одной карте и одной модели. Перед выбором движка прогоните собственные запросы, свой тип нагрузки и свою глубину контекста.
Что нужно, чтобы воспроизвести тест у себя
Минимальный набор условий из методики выглядит так:
- RTX 5090 с лимитом мощности 400 Вт и 128 ГБ RAM, операционная система Linux;
- веса Qwen 3.8 FN в формате NVIDIA NVFP4;
- инструмент конвертации под каждый проверяемый движок;
- жадное сэмплирование (temperature 0), отключённый thinking, int8 KV cache;
- холодный старт на каждый запрос, чтобы исключить влияние прогретого кэша;
- для глубинных тестов префикс wikitext на 25K, 50K, 100K и 200K токенов и запрос с выводом 512 токенов.
Стоит трезво оценить масштаб: 128 ГБ RAM и контекст 200K токенов это условие конкретного эксперимента, а не домашний минимум. На меньшем объёме памяти часть конфигураций может не запуститься или уйдёт в своп, и тогда любые ток/с потеряют смысл.
Совпадения цифр ждать не нужно. Даже у автора декодирование колеблется между запусками настолько, что разрывы меньше 5% он не считает значимыми. Ваш результат будет отличаться, и сравнивать имеет смысл только замеры, сделанные на одной машине в одинаковых условиях.