Как я вылез из бардака с AI‑картинками и собрал себе стенд для тестов

В какой‑то момент я поймал себя на том, что решаю не задачи, а играю в перетаскивание между сервисами.

Запускаю один генератор — вроде картинка терпимая. Переезжаю в другой — там бодрее по скорости, зато качество начинает сыпаться. В третьем снова беда с пропорциями. Пара дней таких «проверок» — и всё рассыпается: скриншоты раскиданы по разным папкам, заметки живут кто где, в голове постоянный белый шум. На простой вопрос «какой инструмент действительно подходит под мою работу?» ответ уже не находится.

По факту это была чистая рулетка: я выбирал модели по настроению и обрывочным впечатлениям, а не по внятным метрикам.

В какой‑то момент меня это окончательно достало, и я собрал небольшой тестовый стенд на TypeScript. Без монструозной архитектуры: обычный проект, OpenRouter API и набор скриптов, которые гоняются через npm run test:*.

Схема до смешного прямолинейная: один и тот же набор задач улетает в разные модели, а результаты складываются по своим директориям и собираются в HTML‑отчёт. Открыл в браузере — и сразу видно, кто реально работает, а кто просто рисует симпатичную картинку ради картинки.

Что я проверяю на моделях

Вместо синтетических бенчмарков я взял живые сценарии — те, на которых сам чаще всего обжигаюсь.

Соотношения сторон — test:aspect-ratio

Длинные и тяжёлые промпты — 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, а не на маркетинговые обещания.

В какой‑то момент это перестало быть игрой «давай попробуем ещё один модный сервис — вдруг повезёт».

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