Pollinations AI API и лимиты бесплатной генерации под нагрузкой: измерить границу демо
Бесплатный endpoint Pollinations ответил на первый запрос за пару секунд, и в переписке команды уже мелькает мысль: можно ставить в демо. Этот ответ доказывает ровно одно: маршрут был жив в конкретную секунду теста. Он ничего не говорит о том, выдержит ли endpoint пять карточек подряд, три параллельных показа на встрече или повторный вызов того же промпта для второго зрителя.
Для демонстрации важна не удача одного вызова, а профиль частоты и параллельности, который можно честно обещать команде. Позиция этого текста простая: Pollinations AI API годится для небольшой демонстрации только в том диапазоне частоты и параллельности, который подтверждён серией контролируемых прогонов, а не единичным успешным ответом.
Дальше — какие переменные фиксировать в каждом прогоне, как читать журнал наблюдений (load-profile), почему опубликованные официальные лимиты сами себе противоречат и что endpoint возвращает вместо честной ошибки под нагрузкой. Результатов собственных прогонов здесь нет: карточка их не содержит, и чужие документированные числа в этом тексте не выдаются за измерение. Ниже — протокол и разбор источников, по которым серию проводит сам читатель.
Почему один ответ не доказывает готовность к серии показов
Распространённый ход мысли звучит так: раз запрос уже ответил, endpoint годится для показа. Он ломается там, где начинается реальный сценарий: демонстрация — это серия вызовов, а не один. Первый ответ измеряет холодный старт, а не устойчивость под повторением.
Разница особенно заметна на бесплатном маршруте, где лимиты завязаны на интервал между запросами. Документация Pollinations описывает доступ уровнями: анонимный доступ без регистрации — один запрос в 15 секунд на базовых моделях, уровень Seed после бесплатной регистрации — раз в 5 секунд, платный Flower — раз в 3 секунды, корпоративный Nectar заявлен как доступ «без лимитов» ко всем моделям (APIDOCS.md, доступ 2026-07-18). Если демо укладывается в один вызов раз в 15 секунд, это один режим работы; если в пять параллельных вызовов подряд, это уже другой вопрос, и опубликованные интервалы сами по себе на него не отвечают — параллельность в этой таблице вообще не указана.
Если сценарий со временем перерастёт из разового показа в постоянную интеграцию, тот же протокол измерения можно прогнать и на другом маршруте: у provod.ai API совместим с протоколами OpenAI и Anthropic, и переключение сводится к замене base_url и ключа в уже написанном коде. Но это отдельный вопрос интеграции, а не повод переносить числа Pollinations на другой endpoint — к сравнению маршрутов вернёмся ниже, когда появится собственный журнал.
Что фиксировать в каждом контролируемом прогоне
Чтобы серия что-то доказывала, каждый прогон должен быть воспроизводим. На входе фиксируются четыре переменные: точный запрос (один и тот же prompt и параметры), частота (интервал между запросами), параллельность (число одновременно открытых соединений) и уровень доступа. На выходе журналируются три поля: HTTP-статус, время ожидания ответа и любое наблюдаемое ограничение.
Уровень доступа определяет механику авторизации, и здесь легко ошибиться. Документация описывает два способа поднять тир: referrer-идентификацию для браузерных приложений (автоматический заголовок referrer, например referrer=myapp.com) и Bearer-токен из auth.pollinations.ai для серверного доступа. Документация прямо предупреждает: Bearer-токен нельзя размещать во frontend-коде (APIDOCS.md, доступ 2026-07-18). Для серии прогонов с бэкенда это рабочий вариант; для встроенного в страницу демо — только referrer.
Минимальный каркас прогона на bash, без секретов в коде. Хост генерации для переменной BASE нужно брать из документации на момент теста: gen.pollinations.ai в APIDOCS.md значится только как точка входа в docs, а не как сам генератор, и подставлять его в BASE нельзя.
Здесь & и wait задают параллельность, sleep задаёт частоту, а флаг -w пишет в журнал статус, время до первого байта и размер тела. Размер тела нужен не для полноты: ниже станет ясно, зачем он ловит скрытое ограничение, которое статус не покажет.
Тот же принцип касается точки входа документации: официальная документация сейчас доступна по gen.pollinations.ai/docs, куда ведёт 301-редирект с enter.pollinations.ai/api/docs. Страница рендерится на клиенте через JavaScript, и её текущую таблицу лимитов автоматический fetch на 2026-07-18 снять не смог (точка входа документации, доступ 2026-07-18). Практический вывод: и хост генерации, и конкретное число лимита на момент теста проверяйте по документации интерактивно, а не берите зафиксированными из этой статьи.
Почему официальные цифры лимитов расходятся
Здесь причина, по которой единичный успех бесполезен как основание для обещания: официальные первоисточники сами дают разные числа для одних и тех же уровней. Файл документации описывает лимиты по интервалу — анонимный доступ раз в 15 секунд, без упоминания параллельности. Более свежий инженерный тикет в том же репозитории от 2025-10-27 (issue #4817) документирует другую схему, реально реализованную в коде: анонимные запросы — интервал 6 секунд с одним одновременным запросом на ограниченном наборе моделей, запросы с прямым API-токеном — интервал 7 секунд с параллельностью по тиру, аутентифицированные через enter.pollinations.ai — интервал 1 секунда и до 20 одновременных запросов на всех моделях.
Это не разночтение в пересказе, а численное расхождение между двумя first-party источниками одного проекта. Тикет отмечен статусом «Done»: логика лимитов живёт в shared/ipQueue.js и shared/auth-utils.js, а обход тира завязан на заголовок x-enter-token в text.pollinations.ai/server.js (issue #4817, доступ 2026-07-18). Статус «Done» здесь означает заявленную сопровождающими текущую реализацию в коде, а не независимое подтверждение, что поведение совпадает с числами из файла документации, — это две разные вещи, и смешивать их источники нельзя.
Практический вывод один: раз опубликованные значения не образуют единой стабильной цифры, узнать действующий режим на момент теста можно только из собственного журнала. Расхождение источников — не помеха методу, а обоснование, зачем он вообще нужен.
Что endpoint отдаёт вместо ошибки 429
Есть отдельная ловушка, из-за которой журнал по одному только HTTP-статусу соврёт. Баг-репорт от 2026-01-13 на официальном репозитории документирует: при срабатывании лимита endpoint генерации изображений не возвращает ошибку 429. Вместо неё приходит HTTP 200 с картинкой-заглушкой размером около 1,3 МБ и устойчивым MD5-хэшем 2090a5dc21c32952cbf8496339752bd1, тогда как обычные сгенерированные изображения весят примерно 40–80 КБ и у каждого запроса свой уникальный хэш (issue #7207, доступ 2026-07-18). Автор репорта просил перейти на стандартные ответы 429; на дату выборки в треде не зафиксировано изменения этого поведения.
Именно поэтому в каркасе прогона выше журналируется размер тела, а не только код ответа. Серия из десяти «200 OK» выглядит как чистый успех, но часть картинок в ней может быть одной и той же заглушкой. Добавьте в журнал строку с хэшем:
Две оговорки, чтобы не растянуть этот факт дальше, чем он доказан. Поведение с заглушкой датировано 2026-01-13 и описывает генерацию изображений; переносить его на текстовые endpoint без отдельного подтверждения в собственном логе нельзя. С 31 марта 2025 года анонимные бесплатные изображения ещё и могут содержать водяной знак, а регистрация на auth.pollinations.ai документирована как способ убрать его и получить более высокий тир (APIDOCS.md, доступ 2026-07-18) — валидный ответ на демо-прогоне может выглядеть иначе, чем на первом тесте.
К деньгам это добавляет ещё один слой. По документации системы Pollen бесплатные модели (например, изображения Flux) всегда стоят 0 Pollen независимо от тира, а платные модели расходуют Pollen; зарегистрированным разработчикам дополнительно начисляется дневной грант Pollen, который сгорает в тот же день и тратится раньше купленного баланса (POLLEN_FAQ.md, доступ 2026-07-18). «Бесплатно» здесь относится к конкретным моделям, а не ко всему маршруту, и это тоже стоит зафиксировать до демо.
Как читать журнал и назначать допустимый режим демо
Итоговый артефакт серии— load-profile: журнал со строками по схеме «частота — параллельность — статус — время ожидания — наблюдаемое ограничение — допустимый режим». Серия прогоняется на нескольких уровнях частоты и параллельности, строки заполняются реальными наблюдениями, и только после этого читается последний столбец.
Правило чтения журнала одно. Если на заданном профиле серия показывает повторяемый режим без наблюдаемого ограничения (стабильный статус, ровное время ожидания, уникальные хэши без заглушек), этот профиль становится допустимым режимом демо. Если появляется ограничение — заглушка, рост времени ожидания, срыв на определённом уровне параллельности, — сценарий сужается до последнего чистого профиля или исключается вовсе. Команде обещается ровно та частота и параллельность, что вошли в журнал, и ни вызовом больше.
- Что показал журнал на профиле: Повторяемый режим, статусы стабильны, хэши уникальны • Наблюдаемое ограничение: нет • Что обещать команде: демо в этом профиле частоты и параллельности
- Что показал журнал на профиле: Часть ответов — заглушка ~1,3 МБ, MD5 совпадает • Наблюдаемое ограничение: лимит через 200-заглушку • Что обещать команде: сузить до профиля без заглушек
- Что показал журнал на профиле: Время ожидания растёт с числом параллельных вызовов • Наблюдаемое ограничение: деградация под параллельностью • Что обещать команде: снизить параллельность до последнего чистого уровня
- Что показал журнал на профиле: Прогон невоспроизводим, параметры не зафиксированы • Наблюдаемое ограничение: метод сломан • Что обещать команде: не обещать демо, перезапустить измерение
Цена метода честная: контролируемая серия занимает больше времени, чем вывод по одному запросу. Взамен появляется число одновременных показов, которое можно назвать заказчику без гадания — это и есть спорный размен: потратить час на прогоны против риска зависшего показа на сцене.
Если сценарий требует оплаты из России без VPN, у provod.ai рублёвый баланс, оплата картой РФ, через СБП или по счёту, а модели доступны по официальным ценам провайдеров без наценки provod.ai. Это отдельная, но релевантная причина держать provod.ai в поле зрения как запасной маршрут, когда бесплатный профиль Pollinations и его непрозрачная система Pollen перестают устраивать команду по деньгам или предсказуемости. Но именно поэтому его собственную нагрузочную границу нужно измерить своей серией: правило метода прямо запрещает переносить документированные или отчётные числа Pollinations на другой маршрут вместо самостоятельного замера.
Что это измерение не закрывает
Метод отвечает на один вопрос— какой профиль нагрузки безопасно обещать — и не претендует на большее. Он не подтверждает доступность endpoint за пределами окна собственного лога. В официальном репозитории и документации Pollinations описан мультипровайдерный роутинг: Cloudflare Workers для маршрутизации и кэша, региональный failover на Azure для моделей GPT Image, дополнительные бэкенды Scaleway, Deepseek и Cloudflare AI, с коммитами по 2026-07-16. Но ни отдельной страницы статуса, ни опубликованного процента аптайма или SLA в этих источниках нет (репозиторий и APIDOCS.md, доступ 2026-07-18). Значит, любое утверждение о «надёжности» шире измеренного окна источником не подкреплено.
Журнал одного маршрута не доказывает режим другого: результаты Pollinations нельзя переносить на provod.ai, на self-hosted модель или на любой иной endpoint — это отдельные замеры по одному и тому же протоколу. Измерение также не заменяет проверку условий использования: карточка не содержит результатов нагрузки и не подтверждает права на результаты генерации до того, как условия сверены на дату теста.
Две дополнительные границы стоит держать в уме. В поисковой выдаче регулярно всплывает похожий домен pollinations-ai.com со страницами API и FAQ, зеркалящими или пересказывающими официальные документы; это не то же самое, что официальные pollinations.ai и *.pollinations.ai, и его числа не авторитетны. И вторая граница — актуальность: условия и поведение endpoint требуют повторной проверки, здесь она зафиксирована на 2026-07-18, и после этой даты цифры стоит перепроверить заново, а не полагаться на статью.
FAQ
Хватит ли одного успешного запроса, чтобы показать демо на пять карточек? Нет. Один ответ измеряет холодный старт, а не серию. Пять карточек — это профиль частоты и параллельности, который нужно прогнать и залогировать отдельно.
Как в журнале отличить лимит от нормального ответа, если оба возвращают 200? По телу ответа, а не по статусу. Заглушка при лимите весит около 1,3 МБ с постоянным MD5 2090a5dc21c32952cbf8496339752bd1, нормальная картинка — примерно 40–80 КБ с уникальным хэшем на запрос (issue #7207, 2026-01-13).
Каким цифрам лимитов верить: из документации или из тикета? Ни одним молча. APIDOCS.md называет 15 секунд для анонимного доступа, issue #4817 со статусом «Done» — интервал 6 секунд и 1 параллельный запрос. Это разные first-party источники; действующий режим на момент теста показывает только собственный лог.
Сколько параллельных показов можно обещать команде на одном и том же профиле? Ровно столько, сколько подтвердил журнал на этом уровне частоты и параллельности без наблюдаемого ограничения. Как только в логе появляется заглушка или рост времени ожидания, профиль сужается до последнего чистого уровня, и обещать команде больше показов до новой ревизии журнала нельзя.
Если после измерения вы решите держать provod.ai как проверенный резервный маршрут, подключите его и прогоните по нему ту же серию: оплата всё так же остаётся в рублях, без VPN и без наценки сверх цены провайдера. Готового результата это не даёт: границу нагрузки этого маршрута всё равно нужно измерить тем же протоколом, а сам сервис не заменяет ни работы по внедрению, ни автоматизацию поверх API — он остаётся источником доступа к моделям, а не готовым решением.
Источники
- Pollinations, APIDOCS.md (GitHub, raw), доступ 2026-07-18 — уровни и интервалы лимитов, водяной знак с 31.03.2025:
- Pollinations, APIDOCS.md (канонический вид файла), доступ 2026-07-18 — механизмы аутентификации, описание мультипровайдерного роутинга:
- Pollinations, POLLEN_FAQ.md, доступ 2026-07-18 — правила Pollen и бесплатных моделей:
- Pollinations, Issue #4817, дата 2025-10-27, доступ 2026-07-18 — лимиты по параллельности и пути enforcement:
- Pollinations, Issue #7207, дата 2026-01-13, доступ 2026-07-18 — поведение HTTP 200 с заглушкой вместо 429:
- Pollinations, корень репозитория, доступ 2026-07-18 — роутинг и отсутствие опубликованного SLA:
- Pollinations, точка входа документации, доступ 2026-07-18 — редирект на текущие docs, клиентский рендер таблицы лимитов:
- provod.ai — проверенные факты о продукте (2026-07-15), сравнение как отдельный измеряемый маршрут: факты продукта подтверждены владельцем
provod.ai — управляемый AI-контур для корпоративных данных
Для внутренних документов важны доступы, роли и контроль расходов: provod.ai даёт рабочие пространства, отдельные аккаунты сотрудников и централизованное управление AI. Платформа проектируется с учётом требований РФ к обработке и защите персональных данных; применимость зависит от конкретного сценария и настроек клиента.
В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.
Корпоративный контроль не превращается в ценовой коэффициент: стоимость моделей сохраняется 1:1 с официальными тарифами, без собственной наценки provod.ai.
Изучите корпоративный контур provod.ai: форма регистрации · цены на модели · защита данных по 152-ФЗ · политика обработки данных