NInfer Windows fork (infernix): локальный инференс LLM на RTX 5090 — обзор форка и практические сценарии

Введение

Локальный инференс больших моделей перестал быть нишевым хобби: компании всё чаще ставят Qwen3.8-27B или аналоги на одну мощную видеокарту, чтобы не платить за облачные токены и не отправлять чувствительные данные наружу. Но «поставить модель» — это только верхушка: реальная производительность зависит от движка инференса, квантизации весов, KV-кэша, спекулятивного декодирования и того, насколько глубоко оптимизированы ядра под конкретный GPU.

Именно в этой нише появился NInfer — C++/CUDA-движок, написанный с нуля для узкой пары «Qwen + RTX 5090». Проект сознательно жертвует универсальностью ради максимальной скорости на одном конкретном железе: README формулирует позицию прямо — только отобранные чекпоинты и максимальная производительность инференса на одной GPU. Вокруг ядра быстро выросла экосистема форков, и один из самых заметных — нативный Windows-порт NInfer (в сообществах его часто называют infernix), который добавляет запуск под Windows 11, OpenAI/Anthropic-совместимые HTTP API и веб-интерфейс.

В этой статье разберём:

• что такое NInfer и почему он принципиально отличается от vLLM, SGLang и llama.cpp;

• что именно добавляют форки Windows (natpate/ninfer-windows и родственные репозитории);

• какие цифры производительности опубликованы для Qwen3.8-27B на RTX 5090 и как к ним относиться;

• когда такой движок реально экономит деньги, а когда лучше взять более универсальный стек;

• как безопасно интегрировать локальный инференс в корпоративный контур.

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

Что такое NInfer и почему он не похож на другие движки

Философия: узкий фокус вместо универсальности

Большинство открытых стеков инференса соревнуются в широте: vLLM, SGLang и llama.cpp стараются загружать произвольные чекпоинты на произвольном железе. NInfer делает ровно наоборот. Движок написан с нуля на C++/CUDA под одну конкретную видеокарту — NVIDIA GeForce RTX 5090 (архитектура Blackwell, sm_120a) — и поддерживает ограниченный набор моделей семейства Qwen.

Это не баг, а осознанная ставка: когда вы знаете заранее и модель, и GPU, можно писать кастомные CUDA-ядра под конкретный hardware target, без абстракций PyTorch и без универсальных диспетчеров. Цена — узкая совместимость; выгода — скорость, которую трудно повторить «универсальным» стеком на том же железе.

💡 Если ваша задача — «модель должна работать у любого пользователя на любой карте», NInfer не подходит. Если задача — «один сервер с RTX 5090 должен выдавать максимальные токены/с для Qwen3.8-27B», это ровно тот случай, ради которого проект и писали.

Формат моделей: нативный контейнер ninfer

NInfer не грузит модели из Transformers, Safetensors или GGUF. Каждая целевая модель распространяется как единый нативный контейнер формата ninfer с опубликованным SHA-256: веса, vision tower, MTP proposal head, токенизатор и чат-шаблон упакованы в один артефакт. По открытым данным это 16,29 GiB для Qwen3.6-27B и 21,22 GiB для Qwen3.6-35B-A3B — объём укладывается в 32 GB VRAM RTX 5090 вместе с рантайм-буферами и KV-кэшем.

Практическое следствие: перед запуском модель нужно скачать отдельным артефактом (например, через Hugging Face CLI) и проверить хеш. Это упрощает воспроизводимость — вы точно знаете, какие биты загружает движок, — но усложняет привычный сценарий «взял GGUF и поехал»: универсальных GGUF-файлов для NInfer не существует.

⚠️ Проверка SHA-256 обязательна. Артефакты формата ninfer публикуются в сторонних аккаунтах Hugging Face; при компрометации репозитория подмена весов пройдёт незаметно, если вы не сверяете хеш. Для продакшена добавьте шаг верификации в CI/скрипт развёртывания.

Что поддерживает ядро: мультимодальность и спекулятивное декодирование

По данным README форков, движок обрабатывает текстовые, одиночные и множественные изображения, видео и смешанные мультимодальные сообщения. Из ключевых механизмов производительности:

• Chunked prefill — предвычисление длинного промпта кусками, чтобы не раздувать пиковую память;

• Exact-batch CUDA Graph decode — запуск декодирования через CUDA Graphs с фиксированной партией;

• MTP speculative decoding — спекулятивное декодирование через multi-token prediction (окна draft от 1 до 5 токенов), а также вариант DFlash2 с окном до 7 токенов;

• Квантизации весов: BF16, INT8, FP8, NVFP4; для KV-кэша — в том числе K8V4 / E8 4-bit варианты;

• Prefix reuse — переиспользование точного префикса между запросами (состояние на устройстве и хосте), что снижает стоимость повторных обращений с одним системным промптом.

NVFP4 здесь ключевая технология: 4-битные веса с блочным масштабированием, нативно поддерживаемые Blackwell. Именно это позволяет RTX 5090 выдавать очень высокую скорость при приемлемом качестве вывода для Qwen3.8-27B.

Windows форки: что добавляют поверх ядра

natpate/ninfer-windows (порт infernix)

Самый известный Windows-форк — репозиторий natpate/ninfer-windows. Это нативный порт NInfer под Windows 11 x64, который трекает upstream master и добавляет:

• локальный CLI;

• OpenAI- и Anthropic-совместимые HTTP API;

• встроенный веб-интерфейс (webui);

• portable-релизы: исполняемые файлы, runtime DLL, лаунчеры по моделям, папку models/, README и SHA256SUMS.

Требования портации жёсткие: Windows 11 x64, RTX 5090 (sm_120a) и драйвер NVIDIA с поддержкой CUDA 13.1. Движок поддерживает зарегистрированные чекпоинты Qwen (в актуальных снапшотах — Qwen3.8-27B в NVFP4/QUASAR вариантах), контекст до 262 144 токенов и vision.

Родственные форки: тот же паттерн, разные акценты

Вокруг NInfer сформировалась целая ветка Windows-портов с похожей архитектурой, но разными упорствами оптимизации. По открытым описаниям репозиториев:

Эта картина важна для понимания: NInfer — не «один проект», а ядро плюс сообщество портировщиков. Если у вас нет RTX 5090, возможно, стоит смотреть на форки под 4090/3090; если нужен именно максимум на 5090 — базовый Windows-порт или headpiece747-вариант с QUASAR/DFlash2.

💡 Форки экспериментальные и могут меняться без предупреждения (один из них прямо назван «experimental repo, changes are subject to be wiped without notice»). Для продакшена фиксируйте конкретный commit/артефакт и SHA-256, а не «последний master».

Производительность: цифры и как их читать

Публикуемые бенчмарки

В открытых источниках по NInfer на RTX 5090 фигурируют следующие значения (разные снапшоты моделей и конфигураций):

По отдельным обзорам ядро NInfer на RTX 5090 достигало порядка 543–700 tok/s в пиковых конфигурациях для Qwen-классов моделей; другие независимые замеры того же Qwen3.8-27B на одной RTX 5090 (llama.cpp, NVFP4 + MTP) дают около 131–142 tok/s. Разброс объясняется конфигурацией: квант весов, KV dtype, окно draft, наличие vision и batch size сильно влияют на итог.

Как относиться к цифрам

Три правила чтения таких бенчмарков:

1. Сравнивайте одинаковые артефакты. 345 tok/s при NVFP4-full + DFlash2 не сопоставимо с 108 tok/s «из коробки» — это разные кванты и разные окна draft.

2. Decode-скорость ≠ стоимость задачи. Для агентных сценариев важнее токены/с на длинном контексте, время prefill и стабильность под нагрузкой, а не пиковый одиночный decode.

3. Пик vs sustained. CUDA Graph exact-batch даёт максимальный пик при фиксированной партии; реальный сервер с переменными запросами будет ниже.

⚠️ Не переносите цифры из одного снапшота на другой без повторного замера: после смены kernel organization upstream (например, замена attention-ядер) старые тюнинги форков могут стать неактуальными — один из 4090-форков прямо указывает, что его Ada-dispatch tuning нацелен на ядра, которые upstream уже заменил.

Практические сценарии: где NInfer экономит деньги

Сценарий 1: локальный ассистент по коду для команды

Типовая боль — облачный ассистент по коду дорогой при высоких объёмах и/или данные проекта не должны покидать периметр. Сервер с RTX 5090 + NInfer (Windows-порт) под OpenAI-совместимым API позволяет подключить существующие IDE-интеграции без изменения кода: клиент стучится в endpoint v1/chat/completions на локальном хосте, а движок отдаёт токены со скоростью, сопоставимой с облачными тарифами, но без поштучной оплаты.

Что важно проверить перед внедрением:

• контекст 262K хватает ли под ваши репозитории (chunked prefill + prefix reuse снижают стоимость повторных обращений);

• KV-кэш при --max-concurrency выше 1: сколько одновременных сессий укладываются в VRAM;

• стабильность MTP/DFlash2 на длинных ответах — спекулятивное декодирование ускоряет, но требует проверки качества на ваших промптах.

Сценарий 2: мультимодальная обработка документов

NInfer поддерживает изображения, видео и смешанные сообщения. Для внутренних задач — разбор сканов, фото дефектов, короткие видеоинструкции — локальный мультимодальный инференс закрывает потребность без отправки медиа в облако. Здесь критичен не только decode, но и prefill по vision-токенам: на длинных документах chunked prefill становится заметной частью времени ответа.

Сценарий 3: высоконагруженный внутренний API

Если нужен один сервер под несколько команд (поддержка + разработка + аналитика), NInfer с OpenAI/Anthropic-совместимым API и переиспользованием префикса хорошо ложится в паттерн «один системный промпт, разные пользователи». Переиспользование точного префикса между запросами напрямую снижает стоимость повторных обращений — это не маркетинг, а конкретный механизм сохранения состояния на устройстве и хосте.

💡 Для продакшена-сервиса фиксируйте артефакт модели (SHA-256), commit форка и параметры запуска (--kv-dtype, --spec, --draft-tokens, --max-context). Без этого «обновил DLL» превращается в неконтролируемый регресс производительности.

Ограничения: почему NInfer не универсален

Узкая совместимость — главная цена скорости

• Одна GPU: ядро рассчитано на RTX 5090 (sm_120a). Порты под 4090/3090 существуют, но это отдельные ветки с собственными настройками производительности.

• Ограниченный набор моделей: поддерживаются только зарегистрированные чекпоинты Qwen в нативном формате ninfer. Llama, Mistral, DeepSeek и произвольные GGUF — не варианты.

• Нет целевой установки: пакета в pip/npm нет; запуск идёт из дерева сборки исходников или portable-архива. Python-инструменты работают независимо от CMake, автономный HBM-probe собирается отдельной командой.

Риск экспериментальности форков

Windows-порты — community-проекты: они трекают upstream, но не являются официальными релизами Neroued/ninfer. Это означает:

• отсутствие гарантий API-стабильности между снапшотами;

• возможность «вытирания» экспериментальных репозиториев без уведомления;

• необходимость собственной верификации артефактов и воспроизводимости сборки.

⚠️ Для критичных контуров не ставьте бизнес на «последний master форка». Корректный подход: зафиксированный commit + SHA-256 артефакта + собственный smoke-тест (запрос с известным ожидаемым ответом) в CI.

Безопасность и продакшен-практики

Локальный инференс снижает риск утечки данных наружу, но не отменяет базовую гигиену:

1. Верификация артефактов. SHA-256 каждого файла формата ninfer сверяется с опубликованным значением; скрипт развёртывания падает при несовпадении.

2. Сетевая изоляция API. OpenAI-совместимый HTTP API по умолчанию слушает на localhost; при открытии для сети — TLS, аутентификация и rate-limiting (иначе один «зациклившийся» агент съест весь KV-кэш).

3. Ресурсы под нагрузкой. --max-concurrency, --kv-capacity и --host-kv-mib задают, сколько одновременных сессий реально укладывается в VRAM; превышение приводит к деградации или сбоям.

4. Мониторинг. Измеряйте не только токены/с, но и время prefill на длинном контексте, долю отклонённых draft-токенов (для MTP/DFlash2) и пиковую VRAM.

5. Откат. Храните предыдущий рабочий артефакт + commit форка; при регрессии после обновления возвращаетесь к известному состоянию за минуты, а не пересобираете.

💡 Выбор движка — лишь половина задачи. Вторая половина — корректная интеграция: аутентификация API, лимиты по сессиям, мониторинг и откат. Команды, которые доверяют критичные контуры опытным разработчикам, экономят время на исправлении архитектурных просчётов, которые обнаруживаются только под нагрузкой.

Сравнение NInfer-подхода с альтернативами

Вывод простой: если ваша задача укладывается в «Qwen + одна RTX 5090 + максимальная скорость» — NInfer и его Windows-форки дают реальное преимущество. Если нужна широта моделей или разнородное железо — универсальные стеки остаются безопаснее.

Итог

NInfer — пример осознанного отказа от универсальности ради производительности: C++/CUDA-движок с нуля, нативный формат ninfer, NVFP4 + MTP/DFlash2 и кастомные ядра под RTX 5090. Windows-форки (natpate/ninfer-windows и родственные репозитории) добавляют то, чего не хватает «голому» ядру для реальной эксплуатации: нативный запуск под Windows 11, OpenAI/Anthropic-совместимые API, веб-интерфейс и portable-релизы с файлом SHA256SUMS.

Для бизнеса такой стек экономит деньги там, где облачные токены дорожают при высоких объёмах, а данные не должны покидать периметр: локальный ассистент по коду, мультимодальная обработка документов, высоконагруженный внутренний API с переиспользованием префикса. Цена — узкая совместимость (Qwen + одна карта), экспериментальность форков и необходимость собственной дисциплины верификации артефактов и мониторинга под нагрузкой.

Перед внедрением зафиксируйте конкретный commit форка, SHA-256 модели и параметры запуска; добавьте smoke-тест в CI и план отката. Тогда локальный инференс превращается из «эксперимента на одной карте» в предсказуемый инфраструктурный компонент.

Источники

• Neroued/ninfer — High-performance single-GPU inference (upstream)

• natpate/ninfer-windows — Windows 11 port of NInfer

• headpiece747/ninfer-5090-windows — Qwen3.8-27B QUASAR/NVFP4, MTP/DFlash2, 262K context

• sergiuszm/ninfer-4090 — RTX 4090 port with E8 4-bit KV and 262K context

• Don-Chad/ninfer-3090 — RTX 3090 port: ReplaySSM, MTP3, C1–C8 batching