# Как часто нужно опрашивать асинхронный API генерации видео? > Часто проверяйте статус только в начале, затем применяйте backoff с jitter и верхним пределом. Учитывайте webhook, сигналы провайдера и четкие условия остановки. Цикл polling должен учитывать время завершения, стоимость запросов и неопределенность, а не фиксированный `sleep`. Пять секунд могут подойти для превью и быть расточительными для многоминутного рендера. ## Начните с ожидаемой длительности задания | Ожидаемое время | Первый интервал | Поздний интервал | Сценарий | |---|---:|---:|---| | Менее 30 секунд | 2–4 с | 5–8 с | Превью | | 30–120 секунд | 4–8 с | 10–20 с | Обычная генерация | | 2–10 минут | 10–20 с | 30–60 с | Долгий рендер | | Неизвестно | 5 с | Backoff до 60 с | Новая модель | Храните измеренные перцентили по модели и настройкам. Таблица — отправная точка, а не SLA. ## Используйте адаптивный backoff вместо фиксированного таймера ```text delay = min(max_delay, base_delay * 2^unchanged_rounds) scheduled_delay = delay * random(0.8, 1.2) ``` Сбрасывайте счетчик при прогрессе и держите предел ниже допустимой задержки уведомления. ## Считайте сигналы провайдера приоритетными | Сигнал | Безопасное действие | |---|---| | `Retry-After` | Ждать не меньше указанного времени | | Rate limit | Общий backoff для маршрута | | В очереди | Редкий polling | | Обработка | Учитывать оставшееся время | | Успех или ошибка | Остановить обычный polling | | Неизвестное задание | Сверить перед повторной отправкой | ## Совмещайте webhook и сверочный polling Проверяйте подписи, удаляйте дубликаты событий и быстро отвечайте. Редко опрашивайте только задания без webhook. ## Ограничьте параллельность всего аккаунта Задайте общий или провайдерский бюджет и разделите емкость запросов статуса и новых отправок. ## Останавливайте брошенные и конечные задания Остановитесь при успехе, ошибке, отмене или истечении срока и сохраните причину с удаленным ID. ## Измеряйте эффективность polling Отслеживайте запросы на завершение, задержку обнаружения, rate limit, возраст нерешенных заданий, webhook и backlog. [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-often-poll-asynchronous-video-generation-api) может унифицировать доступ к моделям текста, изображений и видео. Правила состояний остаются специфичными для маршрута. ## Итог Начните с указаний провайдера, затем добавьте backoff, jitter, ограничения и правила остановки. Webhook уведомляет, редкий polling сверяет. ## FAQ ### Какой первый интервал разумен? Следуйте документации; без указаний 3–5 секунд — осторожная отправная точка для короткого задания. ### Один интервал подходит всем заданиям? Нет. Учитывайте ожидаемую длительность, возраст, состояние и рекомендации модели. ### Нужно ли останавливаться после HTTP-ошибки? Временные ошибки повторяйте с backoff, а при явной ошибке аутентификации, валидации или конечном состоянии останавливайтесь. ### Достаточно ли webhook? Они могут задерживаться и дублироваться, поэтому оставьте редкий polling для сверки. ### Как избежать одновременной волны запросов? Добавьте jitter, ограничьте параллельность и планируйте каждое задание отдельно. ### Упрощает ли Atlas Cloud работу с несколькими моделями? Он унифицирует доступ, но приложение по-прежнему нормализует состояния и интервалы.