NitroGen от NVIDIA: не «идеальный геймер», но любопытный кандидат в E2E QA
Если смотреть характеристики, то должна умещаться в 2 Gb VRAM на видеокартах начиная с RTX 3000-ой серии. Управлять может только через эмуляцию геймпада, так что клавомышные игры она не протестирует (можете попробовать агенты от OpenAI или Peplexity, но это будет медленно и дорого).
Ниже — что она реально умеет, как она запускается, где в этом правда про “open source”, и почему из неё потенциально получается “нормис‑бот” для smoke/E2E тестов.
TL;DR
- NitroGen принимает на вход картинку (кадр игры) и выдаёт на выход gamepad actions. Клавиатуры/мыши в выходе нет.
- В текущем релизе она не получает текстовых задач и не “проходит игру”. Это не агент с целями; это имитатор действий.
- Репозиторий — это “обвязка” для Windows: найти окно игры, сделать скрин, спросить модель, нажать кнопки через виртуальный геймпад, записать видео/логи.
- Модель ~0.5B параметров (4.93×10^8), файл чекпойнта ng.pt на HuggingFace ~1.97 GB. “2 GB VRAM” — это скорее про веса в fp32, в реальности будет больше (буферы/активации + сама игра).
- Лицензия — NVIDIA non‑commercial research only: формально это не “делаем коммерческий QA‑инструмент и продаём”.
Почему это не «идеальный геймер» и не «прошёл тысячи игр»
Если упростить, NitroGen — это правдоподобный автопилот, а не “проходильщик”.
- Нет цели/награды/планирования.
Модель не знает “я хочу открыть настройки” или “я хочу пройти уровень”. Она выдаёт действие, которое похоже на человеческое в похожей картинке. - Нет промпта.
В релизной обвязке язык/инструкции не подаются; вход — это кадры и (опционально) ID игры. - Меню и «Start» — не гарантированы.
Более того: в scripts/play.py по умолчанию меню‑кнопки отключены (если не передать --allow-menu, то START/GUIDE/BACK принудительно обнуляются). То есть “сам нажмёт Start и начнёт кампанию” — это даже не дефолтный сценарий. - Только gamepad.
Большая часть “тысяч игр” на ПК — это клавомышь. NitroGen из коробки туда не попадает. - Это imitation learning.
Имитатор может быть убедительным, но будет зацикливаться, тупить, умирать, делать странные штуки и не понимать “почему это важно”.
Как запускается
`scripts/serve.py` — грузит чекпойнт `ng.pt`, поднимает **ZMQ inference server** и отвечает на запросы `predict(image)`.
`scripts/play.py` — Windows‑клиент, который:
- ищет игру по имени процесса (`--process '<game>.exe'`),
- находит окно (через `pywinctl`),
- снимает кадры (`dxcam` по умолчанию),
- ресайзит до `256×256`,
- отправляет кадр на сервер,
- получает пачку действий и воспроизводит их через `vgamepad`,
- пишет артефакты: видео `*_DEBUG.mp4`, `*_CLEAN.mp4` и JSONL с действиями в `out/<ckpt_name>/`.
Отдельно стоит отметить: внутри nitrogen/game_env.py используется xspeedhack (DLL‑инжект), чтобы “пауза/анпауза” держала стабильный контроль по шагам. Для одиночных оффлайн‑игр — ок, для онлайна/античит‑зон — лучше даже не пробовать.
Можно ли давать задачи и follow‑up задачи?
В текущем виде — нет, это не чат‑агент и не instruction‑follower. Максимум “управляемости”, который есть без дообучения:
- Выбор игры (если в чекпойнте есть маппинг):
при старте сервера InferenceSession.from_ckpt(...) может предложить выбрать ID игры из списка, чтобы поведение лучше совпадало с конкретным тайтлом. - CFG / контекст:
в serve.py есть --cfg и --ctx, можно менять “насколько” модель следует условию/истории. - Маски/ограничения на действия (это уже ваша обвязка):
запрещать меню‑кнопки, запрещать “самоубийственные” вводы, ограничивать стики и т.д.
То есть вы не промптите NitroGen словами, но можете обложить его направляющими на уровне: “на этом экране нажимаем A, на этом — B, а в геймплее пусть ведёт себя сам”.
Реальное QA‑применение: что из этого может получиться
Если мыслить не “пройдёт ли он игру”, а “поймает ли он мне боль”, то открываются полезные сценарии:
Smoke/E2E: “игра вообще запускается и принимает ввод?”
- старт → интро/главное меню → начать новую игру → первые 5–10 минут геймплея;
- проверки фокуса окна, зависаний, чёрных экранов, странного поведения контроллера;
- артефакты в виде видео + лога действий (очень удобно для воспроизведения).
“Нормис‑бот” для раннего UX
Первые минуты особенно важны: игрок может не понять управление, не заметить подсказку, застрять в обучении, не найти “Start”. Имитатор “человеческого” ввода иногда полезнее, чем идеальный скрипт.
Регрессии на контроллере
Если у вас регулярно ломается раскладка геймпада/вибрация/ось стика — такой агент будет реально нажимать комбинации, а не только ваш ручной тест‑лист.
Негативные сценарии (по сути, fuzzing)
Много хаотичного ввода + запись видео → отличный способ ловить краши и софтлоки.
Важно понимать: покрытие будет непредсказуемое.
На своих проектах проверять не буду, т.к. у меня всё клавомышное, но если решите проверить на своих и запилите пост-ответ - будет интересно почитать.