Pollinations AI API и лимиты бесплатной генерации под нагрузкой: измерить границу демо

<p>Бесплатный endpoint Pollinations ответил на первый запрос за пару секунд, и в переписке команды уже мелькает мысль: можно ставить в демо. Этот ответ доказывает ровно одно: маршрут был жив в конкретную секунду теста. Он ничего не говорит о том, выдержит ли endpoint пять карточек подряд, три параллельных показа на встрече или повторный вызов того же промпта для второго зрителя.</p> <p>Для демонстрации важна не удача одного вызова, а профиль частоты и параллельности, который можно честно обещать команде. Позиция этого текста простая: Pollinations AI API годится для небольшой демонстрации только в том диапазоне частоты и параллельности, который подтверждён серией контролируемых прогонов, а не единичным успешным ответом.</p> <p>Дальше — какие переменные фиксировать в каждом прогоне, как читать журнал наблюдений (load-profile), почему опубликованные официальные лимиты сами себе противоречат и что endpoint возвращает вместо честной ошибки под нагрузкой. Результатов собственных прогонов здесь нет: карточка их не содержит, и чужие документированные числа в этом тексте не выдаются за измерение. Ниже — протокол и разбор источников, по которым серию проводит сам читатель.</p> <h2> Почему один ответ не доказывает готовность к серии показов </h2> <p>Распространённый ход мысли звучит так: раз запрос уже ответил, endpoint годится для показа. Он ломается там, где начинается реальный сценарий: демонстрация — это серия вызовов, а не один. Первый ответ измеряет холодный старт, а не устойчивость под повторением.</p> <p>Разница особенно заметна на бесплатном маршруте, где лимиты завязаны на интервал между запросами. Документация Pollinations описывает доступ уровнями: анонимный доступ без регистрации — один запрос в 15 секунд на базовых моделях, уровень Seed после бесплатной регистрации — раз в 5 секунд, платный Flower — раз в 3 секунды, корпоративный Nectar заявлен как доступ «без лимитов» ко всем моделям (APIDOCS.md, доступ 2026-07-18). Если демо укладывается в один вызов раз в 15 секунд, это один режим работы; если в пять параллельных вызовов подряд, это уже другой вопрос, и опубликованные интервалы сами по себе на него не отвечают — параллельность в этой таблице вообще не указана.</p> <p>Если сценарий со временем перерастёт из разового показа в постоянную интеграцию, тот же протокол измерения можно прогнать и на другом маршруте: у <a href="https://provod.ai/?utm_source=vc.ru&amp;utm_medium=referral&amp;utm_campaign=api150-a147-pollinations-ai&amp;utm_content=hook&amp;utm_id=brief-a147" rel="noopener noreferrer">provod.ai</a> API совместим с протоколами OpenAI и Anthropic, и переключение сводится к замене base_url и ключа в уже написанном коде. Но это отдельный вопрос интеграции, а не повод переносить числа Pollinations на другой endpoint — к сравнению маршрутов вернёмся ниже, когда появится собственный журнал.</p> <h2> Что фиксировать в каждом контролируемом прогоне </h2> <p>Чтобы серия что-то доказывала, каждый прогон должен быть воспроизводим. На входе фиксируются четыре переменные: точный запрос (один и тот же prompt и параметры), частота (интервал между запросами), параллельность (число одновременно открытых соединений) и уровень доступа. На выходе журналируются три поля: HTTP-статус, время ожидания ответа и любое наблюдаемое ограничение.</p> <p>Уровень доступа определяет механику авторизации, и здесь легко ошибиться. Документация описывает два способа поднять тир: referrer-идентификацию для браузерных приложений (автоматический заголовок referrer, например <code>referrer=myapp.com</code>) и Bearer-токен из auth.pollinations.ai для серверного доступа. Документация прямо предупреждает: Bearer-токен нельзя размещать во frontend-коде (APIDOCS.md, доступ 2026-07-18). Для серии прогонов с бэкенда это рабочий вариант; для встроенного в страницу демо — только referrer.</p> <p>Минимальный каркас прогона на bash, без секретов в коде. Хост генерации для переменной BASE нужно брать из документации на момент теста: <code>ge