Короткий ответ: что подтверждено, а что пока нельзя считать доказанным
Полный сценарий запуска Qwen 3.8 27B на одной RTX 5090 через nInfer предоставленные материалы не подтверждают. В доступном фрагменте обсуждаются варианты Qwen3.8-27b-IQ4_XS и Qwen3.8-Flash-Next-IQ4_XS, а в логах указаны n_ctx_slot = 131072 и kv_unified = true. Это полезные ориентиры для анализа, но они не доказывают заявленную конфигурацию с NVFP4, MTP, int8 KV cache и контекстом 180K.
Зафиксированные цифры выглядят так: prefilling достигал 78,31 tokens/s на 2048 токенах и 87,22 tokens/s на 4096 токенах. Генерация держалась примерно в диапазоне 7-10 tokens/s. Эти показатели относятся к конкретному неполному запуску и не должны автоматически приписываться Qwen 3.8 27B, RTX 5090 или nInfer.
Практический вывод простой: связку стоит проверять собственным воспроизводимым тестом. Потенциальный выигрыш может появиться за счёт компактного формата весов, MTP и сжатого KV cache, но итог зависит от версии модели, движка, длины контекста, размера batch и характера нагрузки.
Для общего контекста о том, почему prefill и decode нельзя оценивать одной цифрой, полезен разбор сравнения TensorSharp и llama.cpp.
Почему запуск 27B на одной видеокарте упирается не только в размер модели
При локальном запуске видеопамять расходуется сразу по нескольким направлениям. В ней находятся веса модели, KV cache, временные рабочие буферы и данные, связанные с обработкой входного пакета. Нагрузка меняется вместе с длиной промпта, ответом и числом параллельных запросов.
NVFP4 как способ уместить большую модель в ограниченный VRAM
NVFP4 уменьшает объём, который занимают веса, благодаря представлению с низкой разрядностью. Это может сделать крупную модель практичнее для одной мощной GPU, включая конфигурацию с RTX 5090. Точный запас VRAM зависит от конкретного файла весов, служебных структур и режима запуска.
Экономия памяти не равна гарантированному ускорению. Движок должен уметь эффективно выполнять операции с NVFP4, а видеокарта и CUDA-стек должны поддерживать нужный путь вычислений. Дополнительные преобразования форматов или недостаточно зрелые ядра способны съесть часть выигрыша.
При выборе формата нужно отдельно проверить три вещи: помещаются ли веса вместе с рабочими буферами, сохраняется ли качество на задачах пользователя и растёт ли реальная скорость генерации. Одного факта загрузки модели в VRAM для оценки конфигурации недостаточно.
Контекст, KV cache и реальная цена длинной сессии
KV cache хранит промежуточные ключи и значения внимания для уже обработанных токенов. Чем длиннее история диалога, тем больше памяти требуется под этот кэш. Поэтому модель, которая запускается с коротким запросом, может упереться в VRAM после добавления десятков тысяч токенов.
В доступных логах встречаются n_ctx_slot = 131072 и kv_unified = true. Это подтверждает конкретный режим с контекстом 131072 токена в том запуске. Полноценная проверка 180K для связки Qwen 3.8 27B, RTX 5090 и nInfer в материалах отсутствует.
int8 KV cache потенциально снижает расход памяти на историю. Освободившийся объём можно направить на контекст или рабочие буферы. Цена зависит от реализации: сжатие может повлиять на качество, скорость доступа и стабильность длинных сессий. Поэтому его нужно измерять на длинных промптах, а не оценивать по теоретическому размеру.
Что nInfer может изменить в локальном инференсе Qwen 3.8 27B
nInfer в этой статье выступает как заявленный объект проверки. Доступные материалы не дают оснований приписывать ему конкретные значения скорости или подтверждённую поддержку всех перечисленных режимов. Корректный вопрос звучит так: какой выигрыш даст этот движок в одинаковой конфигурации по сравнению с альтернативами?
MTP: где появляется ускорение генерации
MTP, или multi-token prediction, помогает декодеру предложить несколько следующих токенов за один цикл. Основная область применения этого механизма, авторегрессионная генерация ответа. Если базовая модель принимает предложенные токены, число эффективных токенов за шаг растёт.
Результат зависит от качества предложений, поддержки конкретной модели и режима декодирования. При низкой доле принятых токенов накладные расходы могут уменьшить пользу MTP. Механизм не ускоряет уже завершённое чтение промпта, поэтому его нельзя переносить на prefilling.
Численный эффект для рассматриваемой связки не подтверждён. Его нужно фиксировать отдельно для коротких и длинных ответов, с одинаковыми параметрами sampling и одинаковым состоянием KV cache.
int8 KV cache и контекст до 180K: выигрыш памяти против компромиссов
Сжатый KV cache меняет баланс памяти. При длинной истории это может оказаться полезнее небольшого прироста пиковой скорости: запрос продолжает помещаться в VRAM, а движок не начинает активно использовать оперативную память или не завершает сессию из-за нехватки буферов.
При этом контекст 180K остаётся заявленной целью, а не подтверждённым результатом доступного теста. Подтверждённый ориентир из логов, 131072 токена при kv_unified = true. Чтобы говорить о 180K, нужно показать успешное заполнение такого контекста, стабильное чтение информации из его начала и измерения latency.
nInfer vs vLLM и nInfer vs llama.cpp: как сравнивать движки без ложного рейтинга
Прямого проверяемого сравнения nInfer, vLLM и llama.cpp в предоставленных данных нет. Поэтому рейтинг по одной цифре tokens/s был бы недостоверным. Движки нужно сравнивать на одинаковом железе, с одинаковой моделью, квантизацией, длиной входа и выхода.
nInfer и vLLM: скорость против зрелости серверного сценария
Для пары nInfer и vLLM полезно разделить два сценария. При одном пользователе критичны скорость первого токена, decode и расход VRAM. При нескольких запросах значение получают планирование пакетов, continuous batching, p95 latency и поведение очереди.
Специализированный движок может дать выигрыш на конкретной модели и GPU, если его ядра хорошо соответствуют этому пути вычислений. vLLM может оказаться практичнее там, где важны привычный серверный API, параллельная обработка и предсказуемая интеграция. Эти утверждения задают критерии проверки, но не заменяют измерения.
Размеры batch и ub способны заметно изменить картину. В доступном обсуждении увеличение этих параметров связывается с кратным ускорением больших промптов, но с дополнительным расходом видеопамяти. Сравнение с разными значениями параметров не будет честным.
nInfer и llama.cpp: контроль локального запуска против оптимизаций конкретного стека
В сравнении с llama.cpp нужно проверить доступность нужного формата весов, параметры контекста, тип KV cache, MTP, offload и совместимость с локальными приложениями. Для домашнего запуска важны понятная команда, диагностика ошибок и возможность повторить конфигурацию через неделю.
llama.cpp часто выбирают за широкий набор форматов и большое количество интеграций. nInfer имеет смысл рассматривать, если его поддержка модели и аппаратных оптимизаций даёт измеримый выигрыш на конкретной задаче. Результаты IQ4_XS и Qwen3.8-Flash-Next из доступного фрагмента нельзя использовать как бенчмарк любого из этих движков.
Об агентных метриках и причинах расхождения между пиковыми tok/s и задержкой полезно прочитать разбор локального агентного бенчмарка Qwen3.8-Flash-Next.
Почему synthetic benchmark не равен agentic coding
Prefilling и generation измеряют разные узкие места
Prefilling показывает, как быстро движок обрабатывает входной текст и строит состояние для дальнейшей генерации. Generation показывает скорость выдачи новых токенов. Пользователь ощущает их по-разному: prefill влияет на ожидание начала ответа, decode, на время появления самого текста.
В доступном запуске 2048 токенов обрабатывались со скоростью 78,31 tokens/s, 4096 токенов, 87,22 tokens/s. Генерация при этом держалась примерно на 7-10 tokens/s. Складывать эти значения в один показатель нельзя: они описывают разные фазы.
Большие batch и ub могут ускорить обработку крупных промптов за счёт более плотной загрузки GPU. Доплата, дополнительная VRAM и возможное изменение latency. В интерактивном режиме максимальный prefill не всегда улучшает субъективную скорость ответа.
Как агент меняет профиль нагрузки
AI-агент для разработки редко генерирует один длинный ответ из одного фиксированного промпта. Он читает файлы, формирует план, вызывает инструмент, получает результат, уточняет задачу и повторяет цикл. Каждый раунд добавляет данные в контекст и меняет соотношение prefill и generation.
В таком сценарии важны latency первого токена, время отдельного шага, стабильность KV cache и скорость возврата результатов инструментов. Пиковые 10 или 20 tokens/s не описывают опыт работы, если агент часто ждёт обработки нового большого контекста.
Для оценки agentic coding нужно записывать число раундов, объём входа, длину ответа, вызовы инструментов, ошибки и итоговое время выполнения задачи. Подробно о значении p50 и p95 для локальных AI-систем рассказывает разбор практических тестов Qwen3.8-27B.
Как подготовить воспроизводимое сравнение на одной RTX 5090
Минимальный набор метрик
Зафиксируйте следующие значения для каждого движка:
- скорость prefilling в tokens/s;
- скорость generation в tokens/s;
- time to first token;
- полное время ответа;
- пиковое потребление VRAM;
- стабильность на контексте 32K, 64K, 128K и целевом длинном режиме;
- число успешных завершений и ошибок;
- для агента, время задачи, количество раундов и вызовов инструментов.
Среднее значение полезно для общего ориентира. Для эксплуатации добавьте p50 и p95 latency, особенно при повторных запросах и параллельной нагрузке.
Параметры, которые нельзя менять между движками
В тестовом протоколе зафиксируйте одну версию модели, формат весов NVFP4 или другой выбранный формат, длину входа и выхода, sampling settings, размер контекста, batch, ub, число запросов, тип KV cache и режим MTP.
Перед замером прогрейте каждый движок одинаково. Повторите каждый сценарий несколько раз, укажите состояние кэша и сохраните логи. Отдельно проверьте короткий синтетический прогон и задачу agentic coding с файлами и инструментами. Только такая пара позволяет увидеть разницу между теоретическим пиком и рабочей задержкой.
| Группа | Что фиксировать |
|---|---|
| Модель | Qwen 3.8 27B, версия и формат весов |
| Память | тип KV cache, контекст, пик VRAM |
| Инференс | batch, ub, MTP, sampling |
| Результат | prefill, decode, TTFT, p50, p95, ошибки |
Кому подходит такой локальный AI-стек, а кому лучше выбрать другой
Когда имеет смысл смотреть в сторону nInfer
nInfer стоит проверять владельцам одной мощной GPU, которым нужна крупная локальная модель, длинная история и работа с кодом без отправки данных в облако. Решение оправдано при одновременном выполнении нескольких условий: нужный формат поддерживается, MTP даёт измеримый прирост, int8 KV cache сохраняет приемлемое качество, а длинная сессия укладывается в VRAM.
Затраты на настройку тоже входят в расчёт. Если конфигурация требует ручной пересборки, нестабильных патчей или ограничивает совместимость с приложениями, небольшой прирост скорости может не окупить сложность.
Когда vLLM или llama.cpp практичнее
vLLM логичнее выбирать, когда приоритетом служат серверный API, параллельные запросы и управляемая очередь. llama.cpp удобнее для локального запуска, экспериментов с форматами и интеграции с инструментами, которые уже используют его интерфейс.
Пользователю с одним рабочим процессом важны простота, предсказуемость и latency. Домашнему серверу для нескольких клиентов потребуются другие метрики. Категоричное превосходство nInfer без парного теста заявлять нельзя.
Для оценки альтернативных квантов и компромисса между VRAM и качеством полезен материал о сравнении IQ1_S и UD-Q4.
Итоговый ориентир: начинайте с подтверждённых параметров, измеряйте prefilling и generation отдельно, а затем повторяйте тест в сценарии, где модель действительно будет работать. Для заявленной связки пока подтверждены лишь отдельные логи с контекстом 131072, prefill 78,31-87,22 tokens/s и генерацией около 7-10 tokens/s. Данные о запуске Qwen 3.8 27B на RTX 5090 через nInfer с NVFP4, MTP, int8 KV cache и 180K требуют отдельной проверки.