Seedance 2.5 API 速率限制与并发：提供商比较

如果您正在为 Seedance 2.5 规划吞吐量，首先需要知道一个令人不安的事实：任何平台上都没有公布可供规划的具体数字。本文将解释原因，以及应该采用何种工程策略来应对。

核心要点

• 市场上没有任何提供商为 Seedance 2.5 发布具体的 RPM、TPM 或并发数表格。这在 Atlas Cloud、Replicate、fal.ai、WaveSpeed、OpenRouter、Kie.ai 以及 ByteDance 的第一方渠道中都是一致的。任何向您展示具体并发数字的文章都是杜撰的。
• Atlas Cloud 在其常见问题解答中逐字记录了其立场：“速率限制因账户等级和模型类型而异。如果您遇到 429 Too Many Requests 错误，请联系支持以获取更高的限制。”
• Atlas Cloud 在其企业版套餐中提供定制的 TPM/RPM，以及按模型和按应用程序的 TPM/RPM 监控，这为需要承诺上限的团队提供了替代公开表格的机制。
• 视频并发不同于 LLM 的 RPM。单个 Seedance 2.5 任务会占用 GPU 数分钟，因此您的瓶颈约束是进行中的任务数量，而不是每秒请求数。
• 429 Too Many Requests 是您的发现信号。将其视为数据，采用带抖动的指数退避策略，并使用受控的斜坡测试来测量您的实际天花板，而不是猜测。
• Webhook 改变了吞吐量的计算方式，因为它们从您的请求预算中移除了轮询流量。Atlas Cloud 文档记录了至少一次送达、大约 10 秒、20 秒、40 秒的重试阶梯（上限约为 30 分钟，最多约 10 次尝试），以及一个对账安全网。

为什么这些数字不存在，以及为什么这不是在回避问题

生成式视频的速率限制是实时 GPU 容量、模型版本、账户等级和当前队列深度的函数。发布一个固定的数字，要么会低估大多数账户能获得的容量，要么会承诺在需求高峰期无法维持的容量。所有提供 Seedance 2.5 的服务商都做出了同样的选择。

ByteDance 也未发布 Seedance 2.5 的技术报告，也不存在正式的第三方基准测试。30 秒单次生成和最多 50 个参考资产的数字是 2026 年 6 月 23 日在北京举行的 Volcano Engine FORCE 发布会上供应商的声明。吞吐量从未成为该公告的一部分。

坦率地说：您的速率限制是您账户的属性，而不是模型的属性。有用的技能是发现它并围绕它进行工程设计。

视频并发与 LLM RPM 是不同的问题

对于文本模型，每分钟请求数是负载的合理代理指标，因为每个请求都简短且廉价。但对于视频，这完全不适用。

考虑一下单个 Seedance 2.5 请求会做什么。时长可配置为 4 到 30 秒（或 -1 让模型选择），分辨率为 480p 或 720p，任务在 GPU 上异步运行直到完成。Replicate 在其公共模型页面上发布了真实的运行指标，其中一个例子显示，一个没有视频输入的 5 秒 720p 片段的 predict_time 为 224.078 秒。这意味着五秒钟的输出占用了将近四分钟的资源。

这对容量规划的影响：

• 一个 HTTP 请求可以占用 GPU 数分钟，因此每秒请求数作为负载指标几乎没有意义。
• 真正的上限是您的账户被允许同时处理的任务数量。
• 提交是廉价的，完成是昂贵的。您可以淹没提交端点而不会产生任何吞吐量。
• 时长和分辨率会影响占用率。一个 30 秒的 720p 任务比一个 4 秒的 480p 任务的工作单元大得多。
• 一旦达到饱和状态，队列等待时间（而非请求延迟）将主导端到端的交付时间。

以进行中的任务和 GPU-秒为单位进行规划，绝不要用 RPM。

Token 计费如何与资源占用挂钩

在 Atlas Cloud 上，视频模型根据分辨率和时长按次生成定价，文档明确指出某些模型（如 Seedance 2.x）在任务完成时按输出的视频 token 计费。Atlas Cloud 提供三种可调用的 Seedance 2.5 变体：bytedance/seedance-2.5/text-to-video、bytedance/seedance-2.5/image-to-video 和 bytedance/seedance-2.5/reference-to-video，每种的基础价格为每秒 $0.134。

ByteDance 发布的第一方 token 计算公式明确了这种关系：token 约等于（输入视频时长 + 输出视频时长）乘以输出宽度、输出高度和输出帧率，再除以 1024。每个参数也都是 GPU 时间的驱动因素。

因此，控制您账单的旋钮也就是控制您并发消耗的旋钮。从 720p 降到 480p，或从 30 秒降到 8 秒，可以同时削减开支并释放容量。Atlas Cloud 也不对失败的生成任务收费：预留的金额会自动返还到您的余额中，因此探测性实验的成本很低。

将 429 视为一种测量工具

由于没有任何地方公布上限，429 Too Many Requests 并不是一个需要担心的失败。它是定位您边界的唯一可靠方法。Atlas Cloud 明确表示，429 是联系支持以获取更高限制的触发器，因此该响应被设计为可操作的，而不是终结性的。

收到 429 时的正确客户端行为：

• 切勿立即重试或在紧密循环中重试。
• 采用带完全抖动的指数退避，并遵守任何 Retry-After 响应头。
• 为退避和尝试次数设置上限，然后将任务移至死信队列。
• 区分 429 和 402 Payment Required，后者在 Atlas Cloud 上意味着余额不足，充值后即可恢复。重试 402 是没有意义的。
• 记录每一个 429 错误以及当时进行中的任务数量。这对数据就是您的上限数据。

测量您自己上限的实用协议

这不到一个小时，就能给您一个可以作为构建基础的数字。

1. 固定您的工作负载形态。例如，使用一种变体、一种分辨率、一种时长，比如 480p 6 秒。在测试中途改变形态会使结果无效。
2. 基线测试。提交单个任务，记录提交延迟和到达最终状态的墙上时钟时间。这就是无负载处理时间。
3. 使用有界工作池进行斜坡测试：2 个并发任务，然后 4 个，然后 8 个，然后 16 个，每个级别至少维持三个完整的任务周期。
4. 每个级别记录三个系列数据：429 错误计数、到达最终状态的中位时间，以及每分钟完成的任务数。
5. 找到拐点。您的上限是每分钟完成数停止增长或开始出现 429 错误的水平，以先到者为准。
6. 在拐点以下运行，而不是在拐点上。为重试和共享密钥的其他应用程序留出余地。
7. 在对时长、分辨率、参考资产数量或账户等级进行任何更改后重新测量。所有这些都会移动拐点。

如果测得的拐点低于您产品的需求，Atlas Cloud 文档中记录的路径是联系支持以获取更高的限制，或升级到企业版套餐，在该套餐中可以为每个模型和每个应用程序配置和监控定制的 TPM/RPM。

Webhook 从您的请求预算中移除轮询

这是大多数团队可以做出的最高杠杆的改变，但却被广泛地低估了。

如果您为一个需要三分钟的任务每两秒轮询一次 GET /api/v1/model/prediction/{id}，您将花费大约九十个请求来了解一个事实。乘以您进行中的任务数量，您的大部分预算都花在了提问而不是做功上。

Atlas Cloud 为异步视频和图像生成提供 webhook 回调：在提交请求中添加 webhook_url，当任务达到最终状态时，您将收到一个 video.task.terminal 事件。轮询仍然有效，两者是互补的。

您必须为其构建的已记录的交付语义：

• 以任何 2xx 响应来确认，并且要快（在几秒钟内）。非 2xx 响应或连接超时算作失败，并将被重试。
• 重试使用指数退避，大约为 10 秒，然后 20 秒，然后 40 秒，上限约为 30 分钟，最多约 10 次尝试，之后交付将被标记为无法送达。
• 交付是至少一次。根据 session_id 进行去重（该 ID 也包含在 webhook ID 请求头中），并使处理程序具有幂等性。不要假设有序或精确一次交付。
• 内置的对账安全网保证即使错过了快速路径也能交付。
• 根据顶层的 status 字段（OK 或 ERROR）进行分支，然后读取 payload.status 以获取 completed、failed 或 timeout。失败会携带一个 error_code，例如 1039 表示内容审核拒绝。
• 验证签名。Atlas Cloud 正在从旧的 HMAC-SHA256 迁移到 Ed25519，并提供一个公共 JWKS 端点，因此请缓存 JWKS，在遇到未知的 kid 时重新获取，并强制执行约五分钟的重放窗口。

提交使用两步异步 REST 约定。视频不通过 chat.completions。

使用 webhook 提交，这样您就永远不会在热路径中轮询，然后仅作为对账扫描时进行轮询。

bashCopy
1curl -X POST https://api.atlascloud.ai/api/v1/model/generateVideo \
2  -H "Authorization: Bearer $ATLAS_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "model": "bytedance/seedance-2.5/text-to-video",
6    "prompt": "a courier cycling through neon-lit rain, camera tracking alongside",
7    "duration": 8,
8    "resolution": "480p",
9    "ratio": "16:9",
10    "webhook_url": "https://example.com/hooks/atlas"
11  }'
12#Returns {"code":200,"data":{"id":"...","status":"processing"}}
13
14curl -H "Authorization: Bearer $ATLAS_API_KEY" \
15  https://api.atlascloud.ai/api/v1/model/prediction/PREDICTION_ID

提供商比较：实际公布了什么

仅为文本评级。每个数字限制单元格都显示“未公布”，因为这是经过验证的市场现状，而不是我们研究中的空白。

有两个单元格值得强调。Replicate 是这里唯一发布观察到的运行时间的提供商，即使您在其他地方部署，这也是一个有用的 GPU 占用率公共参考。OpenRouter 将 Seedance 2.5 作为来自单一上游提供商的直通服务，因此没有在其上叠加路由决策；它提供广泛的 LLM 路由和大型文本目录，并且还具备多模态和部分视频功能。

能在未知上限下幸存的队列设计

既然您无法从文档中读取限制，那就构建一个能够自我调节的系统。

• 有界工作池。将在进行中的任务数量上限设置为低于您测得的拐点的运行时配置值，而不是一个需要重新部署的常量。
• 自适应门控。遇到 429 时，缩小有效池，然后缓慢恢复。对并发应用加性增、乘性减策略。
• 处处幂等。为每个逻辑任务生成您自己的请求密钥，存储返回的 prediction_id，并在处理 webhook 时根据 session_id 去重。
• 优先通道。交互式任务应抢占批量回填任务以获取稀缺的槽位。单一的 FIFO 队列会让您最慢的路径定义您最快的路径。
• 对账扫描。定期列出超过截止日期仍标记为进行中的记录，并轮询预测端点以获取真实状态。这是使至少一次交付安全的原因。
• 在边缘进行形态控制。将时长和分辨率作为产品决策暴露出来。一个 480p 的预览等级既是成本杠杆，也是吞吐量杠杆。
• 占用率的可观察性。图表化进行中的任务和每分钟完成数，而不是请求计数。请求计数直到没有任何任务完成的那一刻看起来都是健康的。

哪个平台适合您的工作流

如果您的首要任务是使用一个账户、一个密钥和一张账单来管理文本、图像和视频的吞吐量，Atlas Cloud 提供了 300 多个精选模型，包括但不限于所有三种变体的 Seedance 2.5，并有文档化的 429 升级路径和企业版定制 TPM/RPM。Atlas Cloud 已通过 SOC II 认证并符合 HIPAA 要求，数据在静止和传输中都经过加密。

如果您想在投入前看到运行时间的公开证据，Replicate 发布的运行指标是可用的最透明的工件。WaveSpeed 暴露了最广泛的 Seedance 2.5 端点集，包括明确的加速等级。OpenRouter 的直通列表将该模型与大型文本目录置于同一密钥下。对于需要使用已发布计算器的第一方 token 计费，Volcano Engine Ark 覆盖中国，而 BytePlus ModelArk 覆盖国际市场。

常见问题解答

Q: Atlas Cloud 上 Seedance 2.5 的速率限制是多少？ A: 没有公布具体数字。Atlas Cloud 的文档指出，速率限制因账户等级和模型类型而异，收到 429 Too Many Requests 响应是联系支持以获取更高限制的信号。企业账户可以直接配置定制的 TPM/RPM。

Q: 有没有提供商公布 Seedance 2.5 的并发数表格？ A: 没有。经核实，Atlas Cloud、OpenRouter、fal.ai、Replicate、WaveSpeed、Kie.ai 或 ByteDance 的第一方渠道均未公布此模型的具体 RPM、TPM 或并发限制。将在别处看到的任何具体数字都视为未经证实。

Q: 我应该为多少个并发的 Seedance 2.5 任务做计划？ A: 测量而不是假设。固定您的工作负载形态，通过 2、4、8 和 16 个并发任务来逐步增加有界工作池的负载，找到每分钟完成数趋于平稳或开始出现 429 错误的水平。在该拐点以下运行。

Q: Webhook 会增加我的吞吐量吗？ A: 间接但显著地增加。它们从您的请求预算中移除了轮询调用，因此您的更多配额可以用于实际工作。Atlas Cloud 文档记录了至少一次送达，重试阶梯大约为 10 秒、20 秒和 40 秒，上限约为 30 分钟，最多约 10 次尝试，外加一个对账安全网。

Q: 为什么分辨率会影响我的速率限制？ A: 因为 Seedance 2.x 在完成时按输出的视频 token 计费，而 token 数量与时长、输出宽度、高度和帧率成正比。这些相同的因素也驱动 GPU 占用率，因此一个较长的 720p 任务比一个较短的 480p 任务消耗更多的并发预算。

Q: 当任务失败或被速率限制时，我会被收费吗？ A: 在 Atlas Cloud 上，失败的生成任务不收费，预留的金额会自动返还到您的余额中。被 429 拒绝的请求从未开始，因此不会产生可计费的输出 token。

总结

没有提供商为 Seedance 2.5 发布具体的速率限制或并发数表格，而 Atlas Cloud 是少数明确记录其管理机制的提供商之一：基于等级和模型类型的限制，以 429 作为升级信号，在企业版上提供定制的 TPM/RPM 以及按模型和应用的监控，还有一个足够详细的 webhook 合约，可以据此构建自调节队列。