Genius-bot · 12 минут чтения
Если задача — получить тысячу изображений по заранее подготовленным описаниям, api stable diffusion удобнее рассматривать не как отдельный вызов генерации, а как часть конвейера. У каждого изображения есть входные данные, идентификатор задания, статус, результат, критерии проверки и имя файла. В API сервиса запрос на генерацию отправляется через POST /generate, а состояние конкретной задачи можно проверять через GET /tasks/{id}.
Для массовой обработки важна не только сама генерация. Нужно ограничить скорость отправки, переживать временные ошибки, не создавать дубликаты при повторном запуске, отбраковывать неподходящие результаты и сохранять связь между исходным заданием и готовым файлом. Ключ для API создаётся после входа в раздел API и показывается один раз.
Ниже разберём конвейер на 1000 заданий: от CSV-файла с описаниями до каталога с результатами. Отдельно посчитаем стоимость, оценим время при разных уровнях параллельности и покажем, где в такой схеме находится api stable diffusion.
1) Задача: тысяча картинок под каталог или контент
Представим каталог из 1000 позиций. Для каждой позиции уже есть название, описание и набор требований к изображению: формат композиции, фон, наличие или отсутствие отдельных элементов. Ручной запуск каждой генерации превращает простую задачу в тысячу отдельных операций, поэтому входные данные лучше превратить в очередь заданий.
Минимальная запись может выглядеть так: id=000001, prompt="...", filename="000001.jpg". В отдельной колонке можно хранить статус: pending, running, done, rejected или error. Тогда после остановки программы не придётся начинать весь прогон сначала.
Для генерации картинки по описанию в справке API предусмотрена операция image стоимостью 9 ₽ за запуск. Цена здесь особенно важна для массовой задачи: тысяча отдельных запусков при неизменной цене операции дают понятную базовую сумму ещё до добавления собственной инфраструктуры, хранения и возможных повторных генераций.
| Операция | Цена за запуск | 1000 запусков |
|---|---|---|
| Картинка по описанию (image) | 9 ₽ | 9 000 ₽ |
| Изменить фото по описанию (image-edit) | 35 ₽ | 35 000 ₽ |
| Увеличить качество фото (upscale) | 50 ₽ | 50 000 ₽ |
| Оживить фото (photo-video) | 25 ₽ | 25 000 ₽ |
| Видео по описанию (video) | 119 ₽ | 119 000 ₽ |
Расчёт предполагает ровно один запуск на одну единицу результата. Если часть изображений придётся переделывать, каждый дополнительный запуск увеличивает фактическую стоимость. Поэтому автоматическая проверка качества — не второстепенная функция конвейера, а способ контролировать количество повторных операций.
2) Список заданий: откуда брать описания
На тысяче изображений основная ошибка обычно появляется ещё до первого HTTP-запроса: в очереди оказываются неполные или дублирующиеся задания. Удобнее заранее подготовить CSV, JSON или таблицу в базе данных, где каждая строка соответствует одной будущей картинке. Генератор затем читает строки последовательно и передаёт их в очередь.
Например, CSV может содержать такие поля: id, prompt, filename, category. Поле id должно быть стабильным и уникальным. Если программа аварийно завершится после обработки 437 строк, по этому идентификатору можно определить, какие задания уже имеют результат, а какие необходимо продолжить.
Для пакетной генерации изображений полезно разделить исходное описание и технические инструкции. Например, в prompt хранить описание товара, а общие правила композиции добавлять программно. Так можно изменить общий шаблон для всех 1000 заданий, не редактируя каждую строку.
Простейшая схема выглядит так:
catalog_id,prompt,filename
000001,"Белая керамическая кружка на светлом фоне","000001.jpg"
000002,"Чёрный рюкзак на нейтральном фоне","000002.jpg"
000003,"Деревянная настольная лампа в интерьере","000003.jpg"Если используется Python, перед отправкой стоит проверить хотя бы четыре вещи: уникальность идентификаторов, непустой prompt, корректное имя файла и отсутствие уже готового результата. Последняя проверка особенно важна при повторном запуске программы: она позволяет не платить второй раз за уже успешно выполненную операцию.
API также предоставляет GET /services, через который можно получить список доступных операций и цен. Остаток баланса проверяется через GET /balance. Перед запуском большой очереди полезно запросить баланс и сопоставить его с предполагаемым числом операций.
3) Параллельность и ограничение частоты запросов
Для ключа API установлено ограничение: не больше 60 запросов в минуту. Это примерно один запрос в секунду, если распределять обращения равномерно. Поэтому запускать тысячу HTTP-запросов одновременно нельзя: очередь должна иметь ограничитель скорости.
При этом ограничение частоты не означает, что весь конвейер обязательно должен быть последовательным. После отправки задания программа получает его идентификатор и может использовать этот идентификатор для последующей проверки через GET /tasks/{id}. Поэтому архитектура может разделить отправку заданий и ожидание результатов.
Например, диспетчер отправляет новые задания с интервалом около одной секунды, а отдельные рабочие процессы следят за уже запущенными задачами. Это позволяет не блокировать отправку всей очереди из-за одного медленного результата. Конкретную длительность выполнения генерации нельзя заранее вывести только из ограничения в 60 запросов в минуту: это разные параметры.
У сервиса есть и необязательный механизм callback_url. Его можно передать при запуске задачи, после чего при готовности результата сервис отправит POST на указанный адрес. Для тысячи заданий webhook удобен тем, что приложению не нужно постоянно опрашивать API по каждой задаче.
Пример запуска через curl:
curl -X POST "https://genius-bot.ru/wp-json/genius/v1/generate" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"service": "image",
"prompt": "Белая керамическая кружка на светлом нейтральном фоне",
"callback_url": "https://example.com/hooks/image-ready"
}'Конкретный набор параметров операции следует брать из ответа GET /services и актуальной документации API, а не жёстко зашивать в массовый скрипт без проверки. В примере выше показана схема запроса к маршруту /generate; имя операции image соответствует операции «Картинка по описанию» из предоставленной справки.
Если webhook не используется, схема может быть проще: отправили задание, сохранили его ID, затем периодически вызываем GET /tasks/{id}. При тысяче заданий лучше хранить состояние каждой задачи в локальной базе или хотя бы в JSON/CSV, чтобы перезапуск процесса не приводил к повторной отправке уже созданных заданий.
Пример простой отправки на Python с использованием requests:
import requests
BASE_URL = "https://genius-bot.ru/wp-json/genius/v1"
API_KEY = "YOUR_API_KEY"
headers = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
}
payload = {
"service": "image",
"prompt": "Белая керамическая кружка на светлом нейтральном фоне",
}
response = requests.post(
f"{BASE_URL}/generate",
headers=headers,
json=payload,
timeout=60,
)
response.raise_for_status()
task = response.json()
print(task)Для реальной очереди вокруг этого вызова нужен rate limiter. При предельных 60 запросах в минуту отправка тысячи обращений только на создание задач потребует теоретически не менее 16 минут 40 секунд, если каждое задание требует одного отдельного запроса. Это нижняя граница именно для отправки запросов, а не гарантированное время получения всех изображений.
4) Отбраковка: как отсеять неудачные автоматически
После генерации нельзя считать любой полученный файл готовым к публикации. Для каталога можно ввести формальные проверки, которые не требуют просмотра каждой картинки человеком. Например, программа проверяет наличие результата, допустимый размер файла, расширение, отсутствие повреждённого файла и соответствие ожидаемому идентификатору.
Следующий уровень — проверка содержимого. Здесь можно использовать собственные правила предметной области: если в задании требовался один объект на однотонном фоне, изображение отправляется на дополнительную проверку по этим критериям. Результат проверки лучше записывать отдельно от статуса API, например quality=pass или quality=reject.
Важно не смешивать техническую успешность и визуальную пригодность. Статус задачи означает, что операция завершена и есть результат, но решение о соответствии конкретному каталогу определяется вашей проверкой. Поэтому полезна двухступенчатая схема: сначала API сообщает о готовности, затем внутренний валидатор решает, отправлять файл в каталог или вернуть его в очередь на повторную генерацию.
Для автоматизации генерации можно задать лимит повторов. Например, исходное задание получает максимум две дополнительные попытки. Тогда при 1000 исходных заданий абсолютный верхний предел составит 3000 запусков, если каждое задание дважды признано неудачным и генерируется заново. При цене 9 ₽ за операцию image такой экстремальный сценарий стоил бы до 27 000 ₽.
В журнале стоит хранить причину отбраковки. Вместо записи reject=true лучше использовать значения вроде missing_result, invalid_file, content_check_failed или manual_review. Через несколько прогонов это позволяет понять, какие типы заданий чаще требуют повторной обработки.
Полезно также разделять автоматическую и ручную проверки. Если алгоритм уверен, что файл технически корректен, его можно принять без просмотра. Если проверка неоднозначна, изображение попадает в небольшой список ручного контроля, а не останавливает весь конвейер из 1000 заданий.
5) Именование и хранение: чтобы потом найти
Имена файлов должны быть производными от стабильного идентификатора, а не от текста prompt. Например, 000001.jpg проще искать, сортировать и связывать с записью в каталоге, чем файл с длинным описанием. Если у одной позиции может быть несколько вариантов, добавляется номер версии: 000001_v01.jpg, 000001_v02.jpg.
Удобная структура каталогов может выглядеть так:
images/
pending/
completed/
000001.jpg
000002.jpg
rejected/
000017.jpg
metadata/
tasks.json
results.json
logs/
run-2026-09-22.logВ tasks.json можно сохранить исходный prompt и идентификатор задачи API. В results.json — итоговый статус, ссылку или сведения о результате, время обработки и число попыток. Такой журнал нужен не только для поиска файлов: он позволяет отличить пропущенную строку от неудачного API-запроса и от результата, который был намеренно отбракован.
Если результат возвращается по ссылке, её лучше сохранить в метаданных вместе с идентификатором задачи. Сервис также предоставляет отдельный маршрут POST /uploads для загрузки файла и получения ссылки. Это пригодится в тех сценариях, где исходное изображение нужно передать в API перед операцией редактирования.
Для резервного хранения имеет смысл отделить оригинальный результат от обработанной копии. Например, 000001_raw.jpg можно не изменять, а после проверки создавать 000001_final.jpg. Тогда повторная обработка не уничтожит исходный результат, а отладка пайплайна не потребует повторной генерации.
Идентификатор задачи API также не стоит использовать как единственный идентификатор бизнес-объекта. У задачи есть технический жизненный цикл, а у товара или публикации — свой. Связка catalog_id → task_id → filename → quality_status сохраняет эту границу и значительно упрощает повторный запуск.
6) Сколько это стоит и сколько занимает по времени
Базовый расчёт для тысячи картинок по операции image простой: 1000 × 9 ₽ = 9000 ₽. Это стоимость тысячи запусков без учёта повторных генераций. Если 50 изображений пришлось переделать один раз, общее число запусков составит 1050, а стоимость — 9450 ₽.
Если повторно генерируется 10% результатов, то получится 1100 запусков и 9900 ₽. При 20% повторов — 1200 запусков и 10 800 ₽. Поэтому при планировании бюджета лучше считать не только количество исходных заданий, но и предполагаемый процент брака.
| Сценарий | Запусков | Стоимость image |
|---|---|---|
| 1000 исходных заданий, без повторов | 1000 | 9 000 ₽ |
| 5% повторных генераций | 1050 | 9 450 ₽ |
| 10% повторных генераций | 1100 | 9 900 ₽ |
| 20% повторных генераций | 1200 | 10 800 ₽ |
По времени нужно разделять минимум два этапа. Первый — передача заданий API. При ограничении 60 запросов в минуту тысяча отдельных запросов требуют не менее 16 минут 40 секунд при равномерной отправке и отсутствии дополнительных задержек. Второй этап — фактическое выполнение операций, для которого в предоставленной справке нет фиксированного времени обработки, поэтому точный общий срок из этих данных рассчитать нельзя.
Если программа отправляет задания небольшими группами, нужно учитывать не только частоту POST-запросов, но и частоту последующих обращений к API. При polling каждый запрос к /tasks/{id} тоже является запросом и должен учитываться в общей нагрузке ключа. Webhook позволяет убрать значительную часть таких проверок и получать уведомление о готовности задачи.
Для массового прогона разумно сначала выполнить небольшой тестовый пакет. Например, вместо немедленного запуска всех 1000 заданий можно обработать 20–50 строк, проверить формат результатов, схему именования и правила отбраковки. После этого основной конвейер запускается с уже проверенной логикой, а стоимость тестовой партии составляет соответственно 180–450 ₽ при операции за 9 ₽.
Оплата в сервисе идёт за запуск, без абонентской платы и без минимального платежа. При выпуске первого ключа на баланс начисляется 50 ₽ для пробы. Баланс перед большим запуском можно проверить через GET /balance, а список операций и их цены — через GET /services.
В результате конвейер на тысячу изображений можно представить как последовательность из семи состояний: загрузка заданий, валидация, постановка в очередь, отправка с ограничением скорости, ожидание результата, проверка качества и сохранение. Такой подход позволяет отдельно контролировать каждый этап и не превращать один сбой в необходимость повторять весь прогон.
Для задач, где нужен именно массовый запуск генераций по описаниям, API удобно использовать как транспорт между очередью заданий и вашим обработчиком результатов. Самое важное — заранее определить идентификаторы, правила повторов, лимит запросов, критерии отбраковки и структуру хранения. Тогда api stable diffusion становится не одиночным HTTP-вызовом, а частью воспроизводимого процесса, в котором можно точно посчитать количество запусков и стоимость.
Частые вопросы
Можно ли отправить тысячу изображений одним запросом?
В предоставленной справке описан маршрут POST /generate для запуска операции, а ограничение составляет не более 60 запросов в минуту на ключ. Поэтому для 1000 заданий следует проектировать очередь отдельных обращений, не предполагая наличие специального batch-метода, которого в справке нет.
Сколько стоит тысяча картинок?
Операция «Картинка по описанию (image)» стоит 9 ₽ за запуск. При 1000 запусках получается 9000 ₽; повторная генерация неудачных результатов добавляет новые оплачиваемые запуски.
Как узнать, готова ли конкретная картинка?
После запуска задачи нужно сохранить её идентификатор. Состояние и результат проверяются через GET /tasks/{id}. Альтернативно можно передать callback_url и получить POST-уведомление, когда задача готова.
Как не потерять прогресс после сбоя скрипта?
Сохраняйте собственный стабильный ID задания, ID задачи API и статус обработки до перехода к следующему элементу. При перезапуске программа сначала проверяет уже завершённые записи и не отправляет их повторно без необходимости.
Как контролировать ограничение в 60 запросов в минуту?
Добавьте rate limiter на очередь запросов. При равномерной отправке верхняя граница составляет 60 запросов за минуту, поэтому 1000 запросов только на запуск заданий потребуют не менее 16 минут 40 секунд. Polling статусов также следует учитывать как обращения к API.
Где взять ключ и посмотреть актуальные операции?
После входа ключ выдаётся в разделе API сервиса и показывается один раз. Список операций и цен доступен через GET /services, а остаток средств — через GET /balance.
