速率限制

速率限制是我们的 API 对用户或客户端在指定时间段内访问我们服务的次数所施加的限制。

---

为何设置限制

我们在 API 上设置了速率限制，以帮助为每个人打造最佳体验。以下是它们重要的原因：

• 为了保障我们服务的安全稳定！可以把速率限制想象成友好的“把关人”——它们确保没有人能一下子用过多请求压垮我们的 API。这有助于保护我们的服务免受潜在滥用，让一切运行顺畅。

• 为了确保每个人都能公平地获得资源。就像在操场上分享玩具一样，我们希望所有用户都能平等地访问 API。通过温和地限制每位用户可以发出的请求数量，我们确保不会有人为了轮到自己而等待太久。

• 为了保持性能的快速和可靠。通过管理请求的整体流量，我们可以为所有用户维持快速的响应时间和稳定的服务。这就像确保高速公路不会太拥堵——当我们防止拥塞时，交通会更加顺畅！

---

限制如何生效

速率限制通过两种方式衡量：

• 每秒请求数：这是您每秒可以发出的网络请求数量。
• 队列任务数：这是您在任意给定时间内，队列中可以并发运行的生成任务数量。

队列任务包括 Text to 3D、Image to 3D、Text to Texture 和 Remesh 端点。其他端点，如 Upload 和 Balance，不计入此限制。

限制是按账户应用的。这意味着限制在您所有的 API key 之间是共享的。

除了速率限制之外，任务处理的优先顺序也会影响您任务的处理速度。

每个用户等级都有专门设计以匹配其需求的特定速率限制和优先级别。以下是当前各等级的限制：

如果您超过这些限制，您将收到来自我们 API 的 429 Too Many Requests 响应。有两种类型的触发情况会引发此响应，每种情况的响应内容不同：

• 请求触发：这发生在您每秒发出过多请求时。您将收到带有 Rate limit exceeded 消息的 429 Too Many Requests 响应。
• 队列触发：这发生在您有过多并发生成任务正在运行时。您将收到带有 NoMorePendingTasks 消息（或者，当您的 credits 用尽时，为 NoMoreConcurrentTasks）的 429 Too Many Requests 响应。此 429 不带 Retry-After：请等待其中一个任务完成后再创建新的任务。

---

速率限制响应头

API 响应会携带以下响应头，以便您控制请求节奏：

当出现 Retry-After 时，请等待相应的秒数后再发送下一次请求。