Как я навёл порядок в AIгенерации и собрал свой тестовый стенд
AI картинки
В какой‑то момент я поймал себя на мысли, что всё это уже не похоже на работу, а на хаотичный квест.
Открываю один генератор — кажется, вроде нормально. Перехожу в другой — да, шустрее, но картинка «едет». В третьем снова что‑то не так с пропорциями. Через пару дней всё смешивается: скрины раскиданы по папкам, заметки в разных местах, а ответ на простой вопрос «какой сервис реально лучше под мои задачи?» отсутствует.
По сути, я просто играл в лотерею — выбирал модели по настроению, а не по данным.
В какой‑то момент меня это окончательно достало, и я собрал себе небольшой тестовый стенд на TypeScript. Без тяжёлых фреймворков и магии: проект, OpenRouter API и набор скриптов, которые запускаются через npm run test:*.
Логика до обидного проста: один и тот же набор заданий уходит в разные модели, а результаты складываются по своим папкам и собираются в аккуратный HTML‑отчёт. Открыл в браузере — и сразу видно, кто действительно тащит, а кто просто создаёт иллюзию активности.
Что именно я тестирую в моделях
Вместо абстрактных синтетических бенчмарков я взял ситуации, в которых сам чаще всего ловлю боль.
Соотношения сторон — test:aspect-ratio
Модель должна вернуть тот формат, который я попросил: 3:4, 1:1, 16:9. На бумаге это тривиальная задача, но в реальности часть движков упорно лепит квадрат, даже если в промпте честно прописана вертикаль.
Длинные и тяжёлые промпты — test:long-prompt
Это те самые ТЗ на полэкрана: куча вводных, уточнений, исключений и «и ещё вот здесь поправь». На таких текстах мгновенно видно, кто умеет держать контекст, а кто к середине начинает придумывать своё.
Нишевые запросы — test:niche: ресторан, ремонт, медицина, дом
Попросить «уютный интерьер» — не проблема практически ни для кого. Но как только формулировка становится конкретнее — например, «ванная в процессе ремонта» — модели начинают чудить: у кого‑то получается склад, у кого‑то полуоперационная, а у кого‑то вообще непонятное помещение.
Стоимость и время — test:cost-and-time
Здесь я замеряю не только цену, но и фактическое время генерации. Забавная штука: «дешёвая» модель легко оказывается дороже, если она тупо дольше всех считает один и тот же запрос.
Плюс в наборе есть композиционные тесты: коллажи 2×2, 3×3, вариативные промпты — это уже история про тонкую настройку и аккуратность композиций.
Как устроен пайплайн
Каждый запуск тестов складывается в outputs/<test_name>/results/, а в корне лежит outputs/<test_name>/index.html.
Мне больше не нужно перебирать папки и выискивать отличия в скриншотах. Я просто открываю HTML‑отчёт и сразу вижу:
какие тесты модель прошла, а какие завалила (PASS/FAIL);
какие размеры она выдала на самом деле;
выдержала ли длинные инструкции или развалилась по пути;
кто реально быстрый, а кто просто сжигает бюджет.
Отдельно я позаботился о гибкости. В models.conf хранится список моделей, и я управляю ими как тумблерами: захотел — включил, надоела — закомментировал. Структура тестов при этом не меняется. Сейчас в активном списке у меня, например, flux.2-klein-4b, riverflow-v2-fast, seedream-4.5, а остальные тихо лежат в конфиге и ждут следующей волны экспериментов.
Что это дало в реальной работе
Главное изменение — я перестал выбирать сервисы по лайкам, эмоциям и красивым лендингам.
Теперь всё выглядит гораздо спокойнее:
нужно быстро накидать десяток черновых концептов — беру модель, которая по отчётам действительно быстрее других, даже если иногда даёт мелкие артефакты;
критична чистая композиция и аккуратные детали — включаю более «вылизанную» модель, мирюсь с тем, что она не чемпион по скорости;
предстоит длинный, сложный промпт — смотрю результаты test:long-prompt, а не верю рекламным обещаниям.
В какой‑то момент всё это перестало быть игрой «а давай попробуем ещё вот этот модный сервис, вдруг повезёт».
Получился нормальный рабочий процесс: формулирую задачи, прогоняю тесты, смотрю метрики, открываю HTML‑отчёт и принимаю решение — эту модель ставим в строй, а эта идёт отдыхать до следующих апдейтов.