Как считать бюджет на генерацию изображений в продукте

Изображения оплачиваются иначе, чем текст: не по токенам, а фиксированной ценой за штуку, и цена зависит только от размера и качества. Отсюда две ловушки, на которых сгорают бюджеты. Первая — качество high стоит в пятнадцать раз дороже low у одной и той же модели, и разница между случайно выбранным режимом и осознанным измеряется не процентами, а разами. Вторая — один запрос делает ровно одно изображение: n_max в каталоге равен единице, поэтому четыре варианта на выбор пользователю это четыре списания, а не одно. Сколько картинок помещается в остаток баланса, считать руками не нужно — GET /v1/balance возвращает это число для каждой модели.

Ниже — как посчитать расход до запуска, где ставить лимиты и что логировать, чтобы потом разобраться в счёте. Сами ставки разобраны отдельно: сколько стоит картинка через API.

Почему картинки считаются не так, как текст

У текстовых моделей счёт зависит от того, сколько вы прислали и сколько модель ответила. Длинный промпт — дороже, короткий — дешевле. У изображений эта связь исчезает.

Цена фиксирована и определяется двумя параметрами: размером холста и качеством. Промпт на три слова и промпт на три абзаца стоят одинаково.

Практический вывод неочевидный: писать подробные промпты для картинок бесплатно. Экономить на описании сцены нет смысла, а вот на качестве и размере — есть.

Ещё одно следствие: расход становится предсказуемым. Для текста нужно измерять usage на реальных запросах, потому что заранее длина ответа неизвестна. Для изображений достаточно умножения.

Формула бюджета

Считается в три множителя:

расход = число изображений × цена(размер, качество) × число вариантов на пользователя

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

Разложим на типовом сценарии: карточки товаров в интернет-магазине, 500 позиций, по одной картинке на позицию, квадратный формат.

Разброс внутри строки — это разница между двумя моделями каталога. Между строками разница пятнадцатикратная, и она определяется одним параметром в запросе.

Теперь тот же расчёт, но с показом четырёх вариантов на выбор: умножьте на четыре. Пятьсот карточек в high с выбором из четырёх — это уже около шести тысяч рублей вместо полутора.

Где обычно сгорает бюджет

Четыре сценария, по убыванию частоты.

Качество по умолчанию. Разработчик пробует high, потому что «пусть будет хорошо», проверяет на десяти картинках, всё нравится — и параметр так и уезжает в прод. На десяти запросах разница незаметна, на десяти тысячах это разница в сто тысяч рублей.

Показ вариантов. Интерфейс с четырьмя карточками на выбор выглядит привычно, но каждый показ множит счёт. Часто достаточно одного изображения и кнопки «сгенерировать ещё» — платить будете только за тех, кому первый вариант не подошёл.

Ретраи без разбора. Обработчик, который при любой ошибке повторяет запрос трижды, на неуспешных генерациях денег не потратит — они не оплачиваются. А вот на успешных, но не понравившихся, потратит втрое.

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

Что спросить у API до того, как считать руками

Два поля закрывают большую часть арифметики.

GET /v1/balance возвращает не только точный рублёвый остаток, но и отдельно посчитанные эквиваленты: сколько изображений каждой доступной модели помещается в этот остаток с учётом ваших условий. Это ответ на вопрос «на сколько мне ещё хватит» без умножений в уме.

GET /v1/models отдаёт всю сетку цен по размерам и качеству, а также n_max и статус редактирования изображений. Строить интерфейс выбора качества стоит на этих данных, а не на константах в коде: сетка меняется, константа устаревает молча.

Полный контракт — в документации API и в openapi.yaml.

Что логировать, чтобы потом разобраться

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

keydealer_billing.charged_microrubles — сколько списано за конкретный запрос, в целых микрорублях, без округлений. operation_id — идентификатор, по которому этот же запрос находится в истории кабинета.

Минимальный набор, который стоит писать рядом: кто заказал, размер, качество, время и operation_id. Через месяц это отвечает на вопросы «почему в марте потратили втрое больше» и «кто именно генерирует по тысяче картинок в день» за одну выборку, а не за вечер раскопок.

Отдельно: неуспешная генерация не оплачивается. Если в логах есть списание, значит изображение было создано, даже если до пользователя оно не дошло из-за ошибки на вашей стороне.

Когда API — не тот инструмент

Честная граница, которую полезно обозначить до того, как вы начнёте писать код.

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

Если же задача другая — регулярно выпускать ролики, фото и карусели для соцсетей, с раскадровкой, удержанием одного персонажа между эпизодами и публикацией, — то писать под это интеграцию с нуля дорого и долго. Для такой работы у нас есть отдельный продукт: TrendMix, платформа ИИ-продакшена, где «Режиссёр» раскладывает идею по сценам и готовит промпты, а цена генерации видна до запуска, как и здесь.

Разница простая: KeyDealer даёт доступ к моделям тем, кто встраивает генерацию в свой продукт. TrendMix даёт готовый контент тем, кто снимает и публикует.

Порядок на первый запуск

Шесть шагов, которые снимают большую часть риска.

1. Определите нужное качество на реальных данных. Сделайте по одной картинке в low, medium и high на своём типовом промпте и посмотрите глазами. Часто medium неотличим от high в том размере, в котором изображение реально показывается.
2. Посчитайте по формуле число изображений на цену на варианты. Третий множитель не забывайте.
3. Поставьте месячный лимит на ключ. Отдельный ключ под генерацию изображений отделяет этот расход от текстового и ограничивает ущерб от ошибки в коде.
4. Введите потолок на пользователя. Хотя бы простой счётчик в сутки.
5. Логируйте operation_id и списание с первого же запроса, а не когда возникнут вопросы.
6. Сверьтесь через GET /v1/balance после первой сотни картинок: фактический расход против расчётного покажет, что вы не учли.

Про редактирование изображений

Отдельная строка, о которую спотыкаются при планировании. В каталоге у моделей изображений статус image_edits — unsupported. То есть дорисовать деталь на готовой картинке или заменить фрагмент через API нельзя, каждая правка — это новая генерация с новым списанием.

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

Что держать в голове

Изображения оплачиваются за штуку, поэтому бюджет считается умножением, а не измеряется на живых запросах. Два параметра решают всё: качество даёт пятнадцатикратный разброс, а число показанных вариантов множит счёт линейно.

Остальное закрывается тремя привычками: отдельный ключ с лимитом, потолок на пользователя и логирование operation_id с первого дня.

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

Ключ с отдельным лимитом под генерацию изображений заводится за минуту, и цена каждой комбинации размера и качества видна до первого запроса: keydealer.ru/login.