Если вы ищете api нейросети бесплатно, важно сразу разделить два понятия: бесплатный доступ и отсутствие технических ограничений. Даже когда на старте есть деньги на балансе для тестов, приложение может упереться не в стоимость операции, а в частоту запросов, размер входных данных, время выполнения или количество одновременно запущенных задач.
В этой статье разберём именно техническую сторону. На примере API сервиса Genius Bot покажу, как проверить ограничения до подключения продакшена, почему один запрос не равен одной секунде ожидания и как организовать очередь, повторные попытки и экспоненциальную паузу. Для доступа к API ключ выпускается после входа в раздел API; ключ показывается один раз.
Главная цифра, известная заранее для этого API, — не более 60 запросов в минуту на один ключ. Остальные ограничения нельзя корректно заменить выдуманными числами: если документация их не задаёт, их нужно измерять на конкретной операции небольшими тестами и закладывать в код запас.
Пять ограничений, о которых узнают уже в бою
У API нейросети есть несколько разных потолков, и деньги покрывают только один из них. Приложение может иметь достаточный баланс, но всё равно не справляться с потоком задач, потому что запросы приходят слишком часто или результат генерируется дольше, чем готов ждать HTTP-клиент.
Первый потолок — частота запросов. Для Genius Bot указано ограничение не более 60 запросов в минуту на ключ. Это среднее арифметическое 1 запрос в секунду, но воспринимать его как безопасный рабочий режим нельзя: если приложение отправляет пачку из 60 запросов почти одновременно, оно создаёт совершенно другую нагрузку, чем равномерный поток одного запроса каждую секунду.
Второй потолок — размер входных данных. Для разных операций это может означать размер загружаемого файла или объём текста. В доступной справке сервиса конкретные максимальные значения размера файла и длины текста не указаны, поэтому не стоит записывать в клиент условное «10 МБ» или «10000 символов» как факт. Такие границы нужно проверять на нужном маршруте и обрабатывать ошибку как штатный сценарий.
Третий потолок — время выполнения. Операция генерации изображения, видео, музыки или расшифровки не обязана завершиться за время обычного HTTP-запроса. В API для этого предусмотрена модель задач: сначала выполняется POST /generate, затем состояние можно получить через GET /tasks/{id}. Это принципиально отличается от схемы «отправил запрос — получил готовый файл».
Четвёртый потолок — параллельность. Даже если частота запросов не превышена, сотни одновременно запущенных задач создают очередь работы на стороне вашего приложения и увеличивают число открытых соединений, таймеров и элементов состояния. Публичное число одновременно выполняемых задач в справке не задано, поэтому собственный лимит параллельности лучше сделать настраиваемым.
Пятый потолок — поведение клиента при временной ошибке. Например, если приложение немедленно повторяет запрос после ограничения частоты, оно может превратить одну ошибку в серию новых ошибок. Повтор должен иметь задержку, ограниченное число попыток и, для операций с побочными эффектами, понятную стратегию защиты от повторного запуска.
Поэтому «лимиты api нейросети» лучше хранить не одной переменной вроде MAX_REQUESTS, а несколькими настройками: requests_per_minute, max_concurrency, timeout, max_retries и backoff. Это позволяет менять стратегию без переписывания кода, когда реальные измерения покажут другую картину.
Запросы в минуту: как измерить свой потолок и не словить 429
Для API Genius Bot верхняя граница частоты задана явно: максимум 60 запросов в минуту на ключ. Если отправлять запросы равномерно, теоретический интервал составляет 60 / 60 = 1 секунду. Для рабочего приложения разумнее оставить запас и, например, настроить локальный ограничитель на 50–55 запросов в минуту, а не пытаться постоянно попадать точно в верхнюю границу.
Важно считать именно запросы к API, а не только успешно завершённые генерации. Если приложение сначала загружает файл через POST /uploads, затем запускает POST /generate и после этого делает GET /tasks/{id}, эти HTTP-вызовы относятся к разным запросам. При проектировании клиента полезно заранее посчитать, сколько обращений приходится на одну пользовательскую операцию.
Например, схема с файлом может выглядеть как «upload → generate → несколько проверок task». Если на одну пользовательскую операцию приходится 1 загрузка, 1 запуск и 5 проверок статуса, это уже 7 HTTP-запросов. При лимите 60 запросов в минуту нельзя автоматически считать, что 60 таких пользовательских операций помещаются в минуту.
Для простого теста удобно начать с последовательных запросов и записывать время каждого ответа. Затем увеличить частоту и посмотреть, где появляется ограничение. При этом тестировать лучше на отдельном ключе и небольшом количестве операций, а не пытаться сразу создать нагрузку из сотен запросов.
curl -X GET "https://genius-bot.ru/wp-json/genius/v1/services" \
-H "Authorization: Bearer YOUR_API_KEY"Этот запрос получает список операций и цен. Базовый адрес API — https://genius-bot.ru/wp-json/genius/v1, а авторизация передаётся через заголовок Authorization с Bearer-ключом. Для автоматического клиента ключ следует хранить в переменной окружения или секрет-хранилище, а не в исходном коде.
Если сервер отвечает ошибкой ограничения частоты, клиенту не стоит сразу делать ещё десять повторов. В этом месте работает очередь: задача помещается в очередь, воркер ждёт разрешённый момент отправки, а временная ошибка обрабатывается отдельно от ошибки в самом запросе.
Размер файла и длина текста: где проходит граница
Размер входного файла особенно важен для операций, которым нужен исходный медиафайл. В API есть отдельный маршрут POST /uploads: приложение загружает файл и получает ссылку, которую затем может использовать при запуске операции. Такой подход позволяет отделить передачу большого входного объекта от самого запуска задачи.
Конкретный максимальный размер файла в справке сервиса не указан. Поэтому корректный способ определить рабочую границу — взять типичный файл, измерить его размер, затем провести серию небольших тестов с увеличением размера. Результат нужно считать эмпирическим ограничением конкретной операции, а не универсальным лимитом всего API.
То же относится к длине текста. Нельзя переносить ограничение одной операции на другую без проверки. Озвучка текста, например, тарифицируется за 1000 знаков, а для остальных операций правила обработки текстового входа могут отличаться; если максимальная длина явно не приведена в документации, её следует определять тестом.
На уровне приложения полезно сделать предварительную валидацию. Сначала проверьте размер файла или длину строки локально, затем отправляйте данные. Если вход слишком большой, его можно отклонить с понятным сообщением или разбить на части, когда это логически допустимо для конкретной задачи.
Для текста разбиение должно учитывать смысл. Механически резать строку каждые N символов можно только там, где потеря границ фраз не влияет на результат. Для расшифровки записи или других медиаопераций аналогичная стратегия должна учитывать, можно ли безопасно обрабатывать части независимо.
Есть ещё одна практическая граница — размер ответа. Даже если входной запрос небольшой, результат может быть объёмным или потребовать заметного времени. Поэтому HTTP-клиенту нужны тайм-ауты, рассчитанные на характер операции, а не одно значение timeout=5 для всех маршрутов.
Время выполнения: почему ответ не приходит сразу и что с этим делать
Для генеративных операций полезно разделять два времени: время принятия задания сервером и время получения готового результата. API предоставляет для этого POST /generate и GET /tasks/{id}. После запуска задача получает идентификатор, по которому приложение может проверять состояние и получить результат.
Это означает, что клиент не обязан держать одно HTTP-соединение открытым до конца генерации. Можно принять задачу, сохранить её ID в базе или очереди и продолжить обрабатывать другие события. Когда состояние изменится, приложение заберёт результат через GET /tasks/{id}.
Есть и необязательный callback_url. Если передать его при запуске, после готовности задачи на указанный адрес приходит POST. Такой вариант удобен, когда постоянный polling не нужен: приложение запускает задачу и ждёт входящего уведомления.
При polling нельзя проверять состояние слишком часто. Если запрос к /tasks/{id} выполняется каждые 100 миллисекунд для сотен задач, значительная часть запросов уходит не на полезные операции, а на проверку состояния. Кроме того, эти обращения учитываются в общем ограничении частоты API.
Практичнее использовать возрастающий интервал проверки: например, первая проверка через несколько секунд, затем через больший интервал. Конкретные значения должны зависеть от операции и измеренного времени выполнения. В справке сервиса нет единого гарантированного времени готовности для всех операций, поэтому фиксированное обещание вроде «результат всегда будет через 30 секунд» делать нельзя.
Webhook тоже требует защиты. Обработчик callback_url должен быстро принять уведомление, проверить идентификатор задачи и передать дальнейшую работу внутренней очереди. Не стоит выполнять тяжёлую обработку непосредственно внутри HTTP-обработчика webhook, иначе повторная доставка или несколько одновременных уведомлений могут создать дополнительную нагрузку.
Повторы с растущей паузой: короткий код, который спасает продакшен
Одна из частых ошибок клиента — одинаковая пауза между всеми повторными попытками. Если сервер временно ограничил частоту, пять повторов через одну секунду дают пять новых обращений почти подряд. Экспоненциальная пауза решает эту проблему: после каждой неудачной попытки интервал увеличивается.
Минимальная схема может выглядеть так: 1 секунда, 2 секунды, 4 секунды, 8 секунд. При этом количество попыток должно быть ограничено, например пятью. Для продакшена к задержке часто добавляют небольшой случайный разброс, чтобы несколько воркеров не просыпались одновременно.
import time
import random
import requests
URL = "https://genius-bot.ru/wp-json/genius/v1/services"
API_KEY = "YOUR_API_KEY"
for attempt in range(5):
try:
response = requests.get(
URL,
headers={"Authorization": f"Bearer {API_KEY}"},
timeout=20,
)
if response.status_code == 200:
data = response.json()
print(data)
break
if response.status_code == 429:
delay = min(30, 2 ** attempt) + random.uniform(0, 0.5)
time.sleep(delay)
continue
response.raise_for_status()
except requests.RequestException:
if attempt == 4:
raise
delay = min(30, 2 ** attempt) + random.uniform(0, 0.5)
time.sleep(delay)
else:
raise RuntimeError("Не удалось получить ответ после повторных попыток")Здесь важно различать временную проблему и постоянную ошибку. Если запрос некорректен, бесконечные повторы не помогут. Если проблема связана с ограничением частоты или кратковременным сетевым сбоем, повтор с увеличивающейся задержкой может быть уместен.
Для POST-запросов нужна дополнительная осторожность. Повтор POST /generate потенциально может снова запустить операцию, поэтому клиент должен понимать, является ли повтор безопасным. Нельзя автоматически применять одну retry-стратегию ко всем POST без проверки поведения конкретного маршрута.
В более крупном приложении повторы лучше вынести из HTTP-клиента в очередь задач. Один компонент создаёт задания, несколько воркеров забирают их с контролем concurrency, а отдельный ограничитель следит за частотой запросов. Тогда ошибка одного запроса не блокирует весь поток обработки.
Удобно также собирать метрики: количество запросов в минуту, число ответов 429, среднее и максимальное время ответа, количество повторов, время от POST /generate до готового результата и долю неуспешных задач. Именно эти данные позволяют понять, какое из ограничений стало узким местом.
Когда бесплатных лимитов действительно хватает
Если задача небольшая, ограничение 60 запросов в минуту обычно нужно учитывать прежде всего на уровне архитектуры, а не воспринимать как отдельную проблему. Например, приложение с несколькими последовательными пользовательскими действиями может спокойно работать через очередь, если оно не отправляет запросы пачками и не создаёт лишние проверки состояния.
При этом термин «api нейросети бесплатно» не означает, что все операции постоянно выполняются без оплаты. В данном API при выпуске первого ключа на баланс начисляется 50 ₽ для пробы, а дальше операции оплачиваются за запуск без абонентской платы и минимального платежа.
| Операция | Цена за запуск | Единица тарификации |
|---|---|---|
| Картинка по описанию | 9 ₽ | запуск |
| Изменить фото по описанию | 35 ₽ | запуск |
| Оживить фото | 25 ₽ | запуск |
| Увеличить качество фото | 50 ₽ | запуск |
| Расшифровка записи | 10 ₽ | запуск |
| Озвучка текста | 18 ₽ | 1000 знаков |
| Создать музыку | 59 ₽ | запуск |
| Видео по описанию | 119 ₽ | запуск |
| Говорящий аватар | 120 ₽ | запуск |
Эти цены полезны для оценки стоимости теста, но технические ограничения нужно считать отдельно. Например, уменьшение цены одной операции не увеличивает допустимое число запросов: ограничение частоты задаётся для ключа и составляет не более 60 запросов в минуту.
Для чата действует совместимый с OpenAI формат: доступны POST /chat/completions и GET /models, а в клиентской библиотеке достаточно заменить base_url и ключ. Тариф чата указан отдельно: 40 ₽ за миллион токенов запроса и 400 ₽ за миллион токенов ответа. Это снова показывает разницу между финансовым лимитом и техническим: цена измеряется токенами, а частота обращений — запросами в минуту.
Если вы строите небольшой внутренний инструмент, начать можно с одного ключа, очереди и простого ограничения скорости. Для более интенсивного приложения стоит заранее отделить создание задач от их выполнения и хранить состояние каждой операции: queued, running, completed или failed — в соответствии с тем, какие состояния фактически возвращает API.
Главный принцип такой: неизвестный лимит не надо угадывать. Его измеряют, фиксируют в конфигурации и обрабатывают как изменяемый параметр. Известный лимит, например 60 запросов в минуту, также не стоит использовать на 100% — запас снижает вероятность того, что небольшой всплеск нагрузки превратится в серию 429.
Частые вопросы
Сколько запросов в минуту api разрешает отправлять?
Для Genius Bot указано не более 60 запросов в минуту на один ключ. Это ограничение нужно учитывать для всех HTTP-вызовов клиента, включая загрузку, запуск и проверки состояния, а не только для успешно завершённых генераций.
Есть ли фиксированный максимальный размер файла?
В предоставленной справке конкретный максимальный размер файла не указан. Для нужной операции его следует определить тестированием, а в коде предусмотреть обработку отказа при слишком большом входном файле.
Почему после POST /generate нельзя просто ждать готовый ответ?
API поддерживает модель задач: после POST /generate можно получить идентификатор задачи и проверять её состояние через GET /tasks/{id}. Дополнительно предусмотрен необязательный callback_url, на который приходит POST после готовности задачи.
Что делать при 429?
Не нужно немедленно повторять запрос несколько раз подряд. Лучше использовать очередь и экспоненциальную задержку, ограничить число повторов и снизить локальную скорость отправки.
Что означают ограничения бесплатного api на практике?
Бесплатное тестовое начисление и технические ограничения — разные вещи. Первый ключ получает 50 ₽ на пробу, но для ключа всё равно действует ограничение не более 60 запросов в минуту; остальные неуказанные в справке границы следует проверять для конкретной операции.
Где получить ключ и посмотреть API?
Ключ выдаётся после входа в панели API и показывается один раз. Там же находится точка входа к настройкам доступа; базовый адрес API — https://genius-bot.ru/wp-json/genius/v1.
