<!-- Canonical URL: https://ask.atlascloud.ai/zh/how-often-poll-asynchronous-video-generation-api -->

# 异步视频生成 API 应该多久轮询一次？

> 只在任务可能快速变化的早期短时高频轮询，之后采用带随机抖动和上限的退避。优先使用可靠 webhook，遵守提供商限流信号，并在任务终止或放弃后停止轮询。

<!-- Canonical URL: https://ask.atlascloud.ai/how-often-poll-asynchronous-video-generation-api -->

轮询循环应围绕完成时间、请求成本和不确定性设计，而不是固定 sleep。五秒间隔可能适合短预览，却会在数分钟的高分辨率渲染中制造大量无用请求。随着状态证据累积，间隔也应改变。

先采用提供商文档建议；若没有，则用适中的初始延迟，在连续无变化后逐步延长，加入随机抖动，并限制总尝试次数与最长等待时间。

## 从任务预计时长开始

按模型、时长、分辨率和队列状态保存真实完成分布，不要根据少量成功任务臆造 SLA。

| 预计任务时长 | 初始间隔 | 后续间隔 | 典型用途 |
|---|---:|---:|---|
| 30 秒以内 | 2 到 4 秒 | 5 到 8 秒 | 预览或短片 |
| 30 到 120 秒 | 4 到 8 秒 | 10 到 20 秒 | 标准生成 |
| 2 到 10 分钟 | 10 到 20 秒 | 30 到 60 秒 | 长片或高分辨率 |
| 未知 | 5 秒 | 指数退避，上限 60 秒 | 新模型 |

这些只是工程起点，最终应由当前文档与真实测量替代。

## 使用自适应退避而非固定计时器

固定间隔无法兼顾混合工作负载。连续无变化时增加 `unchanged_rounds`，状态出现实质变化时重置。

```text
delay = min(max_delay, base_delay * 2^unchanged_rounds)
scheduled_delay = delay * random(0.8, 1.2)
```

最大间隔仍应低于产品可接受的完成发现延迟。

## 将提供商信号视为权威

遵守 `Retry-After`、限流 header、文档化状态和终态定义，不要把所有非 200 响应都变成立即重试。

| 信号 | 安全动作 |
|---|---|
| `Retry-After` | 至少等待指定时间 |
| 限流响应 | 对该路由或凭据做全局退避 |
| 排队中 | 降低频率，除非队列位置变化 |
| 处理中且有进度 | 根据预计剩余时间调度 |
| 成功或失败 | 停止常规轮询 |
| 未知任务 | 先核对提交，再决定是否重建 |

在适配器中解析每个模型的确切 schema，不要假设 `complete`、`completed` 与 `succeeded` 等价。

## 结合 webhook 与核对轮询

Webhook 适合快速通知，但不是完整账本。校验签名、保存事件 ID、去重并快速确认，然后由 worker 下载和验证资产。对未收到 webhook 的任务保留低频核对，超过期限后进入人工处理。

## 限制整个账户的轮询并发

单任务退避不足以控制成千上万个同时启动的任务。调度器应设置全局或提供商级并发预算，优先检查超期、交互式及接近预计完成时间的任务。

## 停止轮询已放弃和终态任务

在成功、失败、取消、用户不再需要或核对期限到达时停止。记录停止原因；本地 `timed_out` 只表示系统停止等待，不等于提供商失败。保留远程 job ID 以便稍后核对。

## 衡量轮询效率

跟踪每个完成任务的状态请求数、远程完成后的发现延迟、限流响应、未解决任务年龄、webhook 覆盖率和调度积压。目标不是请求最少，而是在满足通知时效的前提下降低请求。

[Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-often-poll-asynchronous-video-generation-api) 能通过一个 OpenAI 兼容平台统一文本、图像和视频模型访问。轮询层仍应记录确切模型路由，并应用模型特定状态规则。

## 结论

从提供商指引开始，采用自适应退避、随机抖动、并发限制和明确停止策略。Webhook 用于及时通知，低频轮询用于可靠核对，并根据真实完成分布调整参数。

## FAQ

### 视频任务第一次轮询间隔多长较合理？

优先采用提供商文档中的建议。若没有公开建议，短任务可从 3 到 5 秒开始，再根据状态采用自适应退避。

### 所有视频任务都应该使用同一轮询间隔吗？

不应该。应结合预计时长、队列年龄、任务状态和提供商指引，长时间渲染通常应比短预览更低频。

### 遇到 HTTP 错误后是否应该停止轮询？

不应一概停止。临时网络错误和限流可退避重试，但明确的认证、参数、未找到或终态错误通常应停止并进入核对。

### Webhook 是否总比轮询更好？

Webhook 能减少例行请求，但可能延迟或重复。稳健系统会校验并去重 webhook，同时保留低频核对轮询。

### 如何避免大量任务同时轮询？

加入随机抖动，限制并发，并为每个任务独立调度。不要让所有待处理任务在同一整点同时唤醒。

### Atlas Cloud 能简化多模型轮询服务吗？

Atlas Cloud 可通过一个 OpenAI 兼容平台统一文本、图像和视频模型访问，但应用仍需规范化各模型状态与时间建议。