Ninfer vs vLLM для Qwen 3.8 27B на RTX 5090: что выбрать и как настроить под агента

Для первого запуска Qwen 3.8 27B на RTX 5090 с 32 ГБ VRAM разумно начать с vLLM. Такой выбор подходит, когда нужны предсказуемый OpenAI-compatible API, понятная интеграция с Hermes Agent и стабильная базовая конфигурация. На ninfer имеет смысл переходить при конкретной задаче: изучить другой подход к prefilling, точнее управлять параметрами batch и ub, проверить режимы KV-cache или исследовать длинный контекст.

Прямого сопоставимого теста ninfer и vLLM для Qwen 3.8 27B именно на RTX 5090 в доступных материалах нет. Поэтому цифры из других конфигураций нельзя выдавать за готовый бенчмарк этой видеокарты. Выбор backend'а стоит делать по собственной агентной нагрузке, где видны скорость prefilling, время до первого токена, скорость генерации, расход памяти и стабильность последовательных запросов.

Практическая схема выглядит так: сначала зафиксировать модель, квантование, длину контекста и один слот, затем сравнить оба backend'а на одинаковых сценариях. После этого постепенно менять batch, ub и настройки KV-cache, записывая результаты в логи.

Короткий вывод: с чего начать на RTX 5090

vLLM стоит выбрать в качестве отправной точки в четырех случаях:

• Hermes Agent уже умеет работать с его API без дополнительного адаптера;
• приоритетом служат стабильность и повторяемость запуска;
• текущая скорость устраивает для рабочих задач;
• нет конкретной проблемы с памятью, контекстом или обработкой запросов.

nInfer оправдывает отдельную проверку, когда vLLM не закрывает конкретный сценарий. Например, длинный prompt слишком медленно обрабатывается, требуется проверить иной способ работы с KV-cache или нужно исследовать конфигурацию с большим n_ctx_slot. Само наличие заявленного преимущества не заменяет тест: выигрыш на синтетическом prefilling может исчезнуть при работе агента с историей, инструментами и повторными вызовами.

Для общего контекста по запуску Qwen 3.8 27B на одной RTX 5090 полезно сопоставить ограничения квантования, MTP, KV-cache и разных inference engine в статье о практическом запуске Qwen 3.8 27B на одной RTX 5090.

Qwen 3.8 27B на RTX 5090: что ограничивает запуск

32 ГБ VRAM дают RTX 5090 заметный запас для локального запуска крупной модели, но этот объём расходуется на несколько компонентов одновременно. Видеопамять нужна для весов модели, KV-cache, промежуточных буферов, служебных структур backend'а и параллельных запросов.

Размер весов задаёт нижнюю границу требований. Квантование уменьшает этот объём, однако оставшаяся память не превращается автоматически в доступный контекст. Чем длиннее prompt и история диалога, тем больше памяти занимает KV-cache. Несколько слотов или высокий параллелизм увеличивают расход ещё сильнее.

VRAM уходит не только на веса модели

Для одиночного короткого запроса система может выглядеть свободной по памяти. При этом длинная история Hermes Agent, результаты инструментов и документы из RAG быстро меняют картину. Сценарий с несколькими последовательными вызовами создаёт требования к памяти, которых не видно при проверке одного сообщения.

batch и ub влияют прежде всего на обработку входного текста. Большие значения могут ускорить prefilling, но требуют дополнительных буферов. При нехватке VRAM backend способен завершиться с OOM, снизить производительность или начать использовать оперативную память, что увеличит задержку.

Нужно учитывать и RAM. Даже при размещении весов на GPU системе могут понадобиться оперативная память и NVMe для загрузки модели, offload или временных операций. Конфигурация 16 ГБ VRAM, 32 ГБ RAM и NVMe из доступного примера достигала максимум 20 t/s на prefilling и 10 t/s на генерации, но работала нестабильно. Эти цифры нельзя переносить на RTX 5090, однако они хорошо показывают связь между скоростью, памятью и устойчивостью.

Почему вариант модели и квантование имеют значение

Название Qwen 3.8 27B не описывает всю конфигурацию. Нужно зафиксировать точный вариант модели, формат весов и квантование. Результаты для Qwen3.8-27B-IQ4_XS нельзя напрямую сравнивать с Qwen3.8-Flash-Next-IQ4_XS или другой сборкой с отличающимися весами и требованиями к памяти.

Даже одинаковое обозначение квантования не гарантирует одинаковое поведение. На итог влияют реализация kernel'ов, поддержка конкретной GPU-архитектуры, параметры KV-cache, длина входа и режим генерации. Поэтому сравнение ninfer и vLLM имеет смысл только при неизменной модели и одинаковых сценариях.

При выборе сборки полезно отдельно записать:

• точное имя модели;
• формат весов и тип квантования;
• размер контекста;
• режим хранения KV-cache;
• число параллельных слотов;
• наличие speculative decoding или MTP, если эта функция используется.

Ninfer vs vLLM: различия, важные для локального запуска

Сравнивать backend'ы стоит через практические свойства, а не через одно значение tokens per second. Для локального AI-стека важны API, управление памятью, поведение на длинных запросах, диагностика ошибок и работа под последовательной нагрузкой.

Критерий	vLLM	ninfer
Базовый выбор	Подходит как предсказуемая точка старта	Подходит для целевого эксперимента и тонкой проверки параметров
API	Удобен, если агент ожидает OpenAI-compatible интерфейс	Нужно отдельно проверить совместимость конкретной сборки и обвязки
Prefilling	Производительность зависит от batch, chunked prefill и конфигурации	Интересен для проверки другой схемы обработки длинных входов
KV-cache	Нужно подобрать формат и бюджет памяти под нагрузку	Нужно проверить поведение режимов, включая конфигурации с unified KV-cache
Диагностика	Проще начать, если стек уже знаком команде	Потребуется внимательнее читать логи и проверять совместимость
Агентные сценарии	Практичен при стабильной работе API и tool calling	Подходит после подтверждения корректности длинных цепочек вызовов

Когда vLLM остается рациональным выбором

vLLM логично оставить, если текущая конфигурация уже отвечает на запросы Hermes Agent и не создаёт ошибок. Переход на другой backend сам по себе не улучшит качество модели. Он может изменить скорость и расход памяти, но добавит новый слой совместимости и диагностики.

Для рабочей системы важна повторяемость. Одинаковый запрос должен проходить через тот же API, история должна передаваться без потерь, а ошибки переполнения контекста должны обрабатываться предсказуемо. При достаточной скорости генерации небольшой потенциальный прирост prefilling может не окупить усложнение конфигурации.

vLLM особенно удобен как базовая точка сравнения. Сначала фиксируется его профиль, затем ninfer проверяется на той же модели и тех же запросах. Без такого baseline трудно определить, что именно дало прирост или вызвало регрессию.

Когда имеет смысл попробовать ninfer

Эксперимент с ninfer оправдан при измеримой причине. К таким причинам относятся медленное prefilling на больших промптах, неудовлетворительное использование VRAM, потребность проверить другой режим KV-cache или интерес к работе с длинным контекстом.

Проверку следует ограничить одной переменной за раз. Сначала сравнивается одинаковый размер контекста и одинаковое число слотов. Затем меняется batch, после этого ub, а затем режим KV-cache. Иначе итоговый результат не покажет, какой параметр повлиял на скорость или стабильность.

nInfer не стоит выбирать по обещанию максимального контекста или пиковой скорости. Для агента важнее, сколько времени занимает полный цикл: запрос, ответ модели, вызов инструмента, возврат результата и следующий запрос. Backend, который быстро обрабатывает один prompt, может оказаться менее удобным при длинной цепочке итераций.

Скорость инференса: prefilling и генерация нельзя смешивать

Prefilling, или обработка входного текста, и generation, или генерация новых токенов, нагружают систему по-разному. На длинной истории агент может долго обрабатывать prompt, даже если последующая генерация идёт с приемлемой скоростью.

Показатель tokens per second без разделения этих этапов малоинформативен. Для Hermes Agent нужно смотреть как минимум на время до первого токена, скорость обработки входа и скорость генерации ответа.

Что дают batch и ub на больших промптах

Увеличение batch и ub способно дать кратный прирост prefilling на больших промптах. Цена такого ускорения, дополнительное потребление VRAM. Если памяти недостаточно, результатом станет OOM или нестабильность вместо ожидаемого выигрыша.

Подбирать параметры лучше ступенчато:

1. Запустить базовый профиль с умеренными значениями.
2. Зафиксировать длину входа и ответа.
3. Увеличить batch небольшим шагом.
4. Измерить prefilling, время до первого токена и пиковое потребление VRAM.
5. Повторить проверку с ub.
6. Остановиться при росте ошибок, скачках задержки или слишком малом практическом приросте.

Результаты нужно сохранять после нескольких повторов. Одно удачное измерение не показывает поведение backend'а при заполненном кэше и длительной сессии.

Почему высокая скорость не равна хорошему backend'у

Пиковая скорость может появиться на коротком тесте, после прогрева или при размере prompt, который не похож на рабочую нагрузку. В другом примере после прогрева генерация держалась примерно на уровне 7-10 t/s. Это ориентир для понимания порядка измерений, а не оценка RTX 5090.

При сравнении фиксируйте:

• время до первого токена;
• среднюю и пиковую скорость prefilling;
• среднюю скорость generation;
• задержку на последующих запросах;
• пиковое потребление VRAM и RAM;
• число ошибок, перезапусков и зависаний;
• изменение скорости при росте истории агента.

Короткий ответ со скоростью 100 t/s может быть менее полезен, чем стабильная работа на меньшей скорости, если агент делает десятки последовательных вызовов. Полный цикл задачи измеряет ценность backend'а лучше отдельного пикового показателя.

Контекст и KV-cache: что означает n_ctx_slot = 131072

Параметр n_ctx_slot задаёт размер контекста слота, который backend выделяет для работы. В одном из логов встречается значение n_ctx_slot = 131072 вместе с kv_unified = true. Это подтверждает запуск с таким параметром, но не доказывает, что RTX 5090 будет поддерживать 131072 токенов с нужной скоростью и запасом VRAM.

Как длинный контекст меняет требования к памяти

KV-cache хранит промежуточные состояния внимания для уже обработанных токенов. При увеличении контекста растёт и объём этого кэша. В агентном сценарии в него попадают системные инструкции, история диалога, результаты tool calling, фрагменты кода и документы RAG.

Рабочий контекст обычно меньше заявленного максимума. Причина в том, что нужно оставить память для весов, временных буферов и генерации. При нескольких слотах бюджет делится между запросами, а при высоком batch возрастает нагрузка на обработку входных данных.

kv_unified = true описывает режим организации KV-cache в конкретном запуске. Само значение не сообщает, сколько VRAM останется под модель и промежуточные операции. Эти параметры нужно оценивать вместе с форматом KV-cache, квантованием и фактической длиной prompt.

Почему обещания большего контекста нужно проверять

Проверка длинного контекста должна включать четыре условия:

• модель принимает длинный запрос без ошибки;
• скорость не падает до непригодного уровня;
• последовательные запросы не приводят к утечке памяти или OOM;
• агент сохраняет корректную историю и формат вызова инструментов.

Успешный старт с большим n_ctx_slot показывает только возможность выделить заявленный слот в конкретной конфигурации. Он не гарантирует комфортную работу с реальными документами, длинными ответами и несколькими итерациями агента.

Практические ограничения длинного контекста для разных локальных стеков разобраны в материалах о настройке Qwen3.8 с GGUF, MTP и длинным контекстом и о связке vLLM с KV-cache и LMCache. Эти конфигурации не заменяют тест RTX 5090, но помогают составить список параметров для проверки.

Какой backend выбрать для Hermes Agent

Hermes Agent предъявляет к backend'у больше требований, чем обычный чат. Модель должна корректно получать историю, возвращать ожидаемый формат ответа и выдерживать несколько связанных вызовов.

Что проверить в агентной интеграции

Перед сравнением скорости прогоните одинаковый набор функциональных тестов:

1. Короткий запрос без инструментов.
2. Запрос с длинной историей.
3. Один вызов инструмента с возвратом результата модели.
4. Несколько итераций одного задания.
5. Повтор или отмена запроса.
6. Переполнение контекста.
7. Длительный прогон с повторными запросами.

Проверяйте OpenAI-compatible API, передачу ролей и сообщений, tool calling, stop-условия, обработку ошибок и сохранение состояния. Если один backend требует изменения формата запросов, это нужно учитывать как часть стоимости перехода.

Почему стабильность важнее пиковых t/s

Сбой в середине агентной цепочки может потерять состояние задачи, результат инструмента или часть истории. После перезапуска потребуется повторно загружать модель и восстанавливать контекст. Несколько секунд выигрыша на генерации не компенсируют регулярные ошибки памяти и непредсказуемую задержку.

Для первого запуска Hermes Agent лучше использовать backend с наиболее понятной интеграцией. Ninfer можно подключить после фиксации базовой конфигурации vLLM и сравнить параллельно на тех же сценариях.

Практическая схема настройки backend'а

Универсальных значений для RTX 5090 здесь нет. Итог зависит от варианта Qwen 3.8 27B, квантования, длины контекста, RAM, версии CUDA, backend'а и характера запросов.

Базовый профиль для первого запуска

Начните с одной модели и одного слота. Установите минимально необходимый рабочий контекст, умеренные значения параллелизма и понятный формат KV-cache. Сначала нужно получить стабильные ответы, затем измерить расход памяти и скорость.

В журнале запуска сохраните точное имя модели, квантование, версию backend'а, параметры GPU, n_ctx_slot, kv_unified, значения batch и ub. Без этих данных повторить результат будет трудно.

Как подбирать batch и ub

Если узкое место находится в prefilling, увеличивайте batch и ub небольшими шагами. После каждого изменения повторяйте короткий и длинный тест. Отдельно проверяйте первый токен, среднюю скорость и потребление памяти.

Высокие значения полезны только до момента, когда прирост перестаёт компенсировать расход VRAM. Для агента приоритетом служит профиль, который выдерживает длинную историю и серию вызовов, а не максимальная цифра на одном prompt.

Что записывать в логи сравнения

Параметр	Что фиксировать
Модель	Точный вариант Qwen 3.8 27B и формат весов
Квантование	Тип квантования весов и KV-cache
Контекст	n_ctx_slot и фактическая длина входа
Память	Пиковые значения VRAM, RAM и использование NVMe
Prefilling	Средняя скорость обработки prompt в t/s
Generation	Средняя скорость генерации в t/s
Задержка	Время до первого токена и полное время ответа
Стабильность	OOM, ошибки API, зависания, перезапуски и деградация после серии запросов

Чек-лист перед переходом с vLLM на ninfer

Минимальный набор тестов

Сначала определите проблему текущего backend'а. Если это скорость, измеряйте prefilling и generation отдельно. Если это память, фиксируйте KV-cache, контекст и число слотов. Если это Hermes Agent, начинайте с функциональной совместимости.

Минимальный нагрузочный тест должен включать короткий запрос, длинный prompt, длинную историю, вызов инструмента, несколько последовательных шагов и длительный прогон с повторными обращениями. Для каждого сценария используйте одинаковую модель, одинаковые параметры генерации и одинаковую длину ожидаемого ответа.

Результаты удобно свести в таблицу:

• название backend'а и версия;
• параметры batch, ub и n_ctx_slot;
• режим kv_unified и формат KV-cache;
• время до первого токена;
• prefilling и generation в t/s;
• пиковое потребление VRAM и RAM;
• ошибки OOM, API и контекста;
• результат выполнения агентной задачи.

Критерии решения

Оставайтесь на vLLM, если скорость устраивает, Hermes Agent работает стабильно, а текущий контекст покрывает рабочие задачи. В этом случае переход добавит переменные, но не решит конкретную проблему.

Рассматривайте ninfer, если тесты подтверждают преимущество на нужной нагрузке. Прирост должен сохраняться при реальных размерах prompt, последовательных вызовах и длительной истории. Одновременно не должно появляться критических проблем с VRAM, API, корректностью tool calling или устойчивостью.

Если выигрыш виден только в синтетическом тесте prefilling, а в Hermes Agent исчезает, переход не оправдан. Такой результат стоит зафиксировать как особенность профиля нагрузки, а не как универсальный вердикт в пользу одного backend'а.

Итог: лучший backend для локальной LLM зависит от нагрузки

Для Qwen 3.8 27B на RTX 5090 с 32 ГБ VRAM начните с vLLM. Он даёт понятную базовую точку для интеграции с Hermes Agent и позволяет сначала проверить модель, память, контекст и API без лишних переменных.

nInfer стоит проверять при конкретной цели: ускорить prefilling, подобрать другие значения batch и ub, исследовать kv_unified или проверить работу с большим контекстом. Значение n_ctx_slot = 131072 в логе подтверждает пример запуска, но не гарантирует такую же скорость и стабильность на любой конфигурации.

Числа для системы с 16 ГБ VRAM, 32 ГБ RAM и NVMe, включая 20 t/s на prefilling и 10 t/s на генерации, используйте только как ориентир. Финальное решение принимайте по одинаковому нагрузочному тесту: с короткими и длинными запросами, tool calling, повторными агентными шагами, измерением задержки и фиксацией ошибок.

Подписаться на канал