Skip to main content
更新日期：2026-06-17

​
Seedance 2.0 计费说明

本文只说明 Crazyrouter 当前代码里的真实结算逻辑，不是泛泛解释官方价格页。 适用模型：
  • doubao-seedance-2-0
  • doubao-seedance-2-0-fast
接入地址请统一使用 https://api.crazyrouter.com，基础设置参考 API Endpoint。

​
先说结论

  1. Seedance 2.0 和 Seedance 2.0 Fast 在本地代码里都按 per_output_token 结算，不是按秒结算。
  2. 提交任务时，这两类任务的预扣费默认是 0。
  3. 任务成功后，系统会根据上游返回的 TotalTokens 或 CompletionTokens 再做最终扣费。
  4. duration 会被记录为任务特征，但不会参与 Seedance 2.0 的最终扣费公式。
  5. 因此，代码里不存在一条固定的“多少 token = 多少秒”全局换算公式。
  6. 如果需要回答“约多少钱一秒”，只能在任务完成后用 实际输出 tokens / 实际秒数 做观测口径，不能把它当成固定计费规则。

​
本地代码里的计费规则

​
1. 命中哪条计费规则

Seedance 2.0 系列的计费规则由“是否包含视频输入”决定： 这里的 video0 / video1 不是秒数，而是：
  • video0: 请求里没有视频参考输入
  • video1: 请求里带了视频参考输入
对应代码：
  • model/video_billing_seedance.go
  • relay/video_billing_runtime.go

​
2. 提交任务时为什么通常不扣费

在运行时，Seedance 2.0 命中的平台计费模式是 per_output_token。这类任务在提交时：
  • BasePrice 会被记录
  • Ratio 会被置为 0
  • 所以提交阶段 quota = int(ratio * QuotaPerUnit) 结果就是 0
对应代码：
  • relay/video_billing_runtime.go
  • relay/relay_task.go
这就是为什么 Seedance 2.0 常见表现是：
  • 任务提交成功
  • 先不扣，或预扣为 0
  • 任务完成后再按真实 token 补扣

​
最终扣费公式

任务成功后，系统优先走 settlePerOutputTokenTaskBilling。 对 Seedance 系列，代码取 token 的优先级是：
  1. taskResult.TotalTokens
  2. 如果上面没有，再取 taskResult.CompletionTokens
对应代码：
  • controller/task_video.go
最终价格公式：
最终 quota 公式：
当前代码中的：
对应代码：
  • controller/task_video.go
  • common/constants.go

​
秒数在代码里扮演什么角色

​
1. duration 会被识别和记录

代码会从这些位置解析秒数：
  • req.Duration
  • req.Seconds
  • metadata.durationSeconds
  • metadata.duration_seconds
  • metadata.duration
  • metadata.seconds
对应代码：
  • relay/video_billing_runtime.go

​
2. 但 Seedance 2.0 不按秒结算

虽然 duration 会进入任务画像和日志，但 Seedance 2.0 / 2.0 Fast 命中的模式是 per_output_token，因此：
  • match.BilledSeconds 不会参与结算
  • 最终扣费只看上游回传的 token
这和 Veo、Wan 那类 per_second 视频模型不同。

​
token 和秒数怎么对照

​
结算口径

不能直接换。 也就是说，在当前代码里没有这样的规则：
原因很简单：
  • Seedance 2.0 的卖价配置不是 per_second
  • 代码也没有把 duration 映射成固定 token 档位
  • 最终只认任务完成后的真实 token 用量

​
观测口径

如果你只是想做“这次任务平均每秒消耗多少 token”的复盘，可以在任务完成后做一个观测值：
反过来：
但这只是事后分析，不是结算公式。

​
实测案例：4 秒 720p 简单视频

下面是一次实际调用 Seedance 2.0 的结果，用来说明怎样从真实 usage 反推“这次任务平均每秒多少钱”。
这个案例是 720p，不是 1080p。当前 Crazyrouter 文档对 Seedance 2.0 / 2.0 Fast 的公开能力边界仍是 480p、720p；1080p 不在当前公开支持范围内。

​
案例 1：最简单文生视频

请求特征：
  • 模型：doubao-seedance-2-0
  • 输入：只有文本，没有图片或视频参考
  • 分辨率：720p
  • 时长：4s
  • 任务 ID：cgt-20260617212928-5s755
  • 上游实际返回：completion_tokens = 87300，total_tokens = 87300
因为请求里没有视频参考输入，命中：
计算过程：
所以，这次非常简单的 4s 720p 文生视频，观测单价约为：

​
案例 2：基于上一个视频做参考视频生成

请求特征：
  • 模型：doubao-seedance-2-0
  • 输入：文本 + 上一个任务生成的视频作为 reference_video
  • 分辨率：720p
  • 时长：4s
  • 任务 ID：cgt-20260617214300-rsnsx
  • 上游实际返回：completion_tokens = 173700，total_tokens = 173700
因为请求里包含视频参考输入，命中：
计算过程：
所以，这次 4s 720p 参考视频生成，观测单价约为：

​
怎么向客户解释这个实测值

可以这样说明：
这也是为什么不能先假定“典型 1 秒就是 100,000 tokens”。如果要给客户一个可信估算，应优先使用真实任务的 usage.total_tokens 或 usage.completion_tokens 反推。

​
两个可直接套用的例子

​
示例 1：doubao-seedance-2-0-fast，带视频输入

假设：
  • 命中 doubao-seedance-2-0-fast:video1
  • 上游返回 TotalTokens = 1,200,000
  • quantityMultiplier = 1
  • groupRatio = 1
  • discount = 1
则：
如果这次请求的 duration = 12，你只能得到一个观测值：
这个 100,000 tokens/s 只对这次任务成立。

​
示例 2：doubao-seedance-2-0，不带视频输入

假设：
  • 命中 doubao-seedance-2-0:video0
  • 上游返回 CompletionTokens = 800,000
  • quantityMultiplier = 1
  • groupRatio = 1
  • discount = 1
则：
如果请求时填了 duration = 8，只能做观测：
仍然不能推出“8 秒任务永远就是 80 万 token”。

​
哪些字段值得看

如果你要排查一笔 Seedance 2.0 费用，优先看这些信息：
  • 请求是否含视频输入
  • 命中的 billing_key
  • 任务完成后上游返回的 TotalTokens / CompletionTokens
  • 该任务的 groupRatio
  • 该模型折扣 discount
  • 最终 task.Quota
代码里日志和快照也会记录：
  • billing_mode
  • billing_key
  • billing_total_price
  • billing_output_tokens
  • billing_billed_tokens
  • billing_token_kind
  • billing_settled
对应代码：
  • relay/relay_task.go
  • model/task.go
  • controller/task_video.go

​
一句话理解

对 Seedance 2.0 而言：
  • 秒数 是请求特征
  • token 是结算依据
  • quota 是 token 结算后再换算出来的站内额度
所以正确顺序是：
而不是：
如果后续平台专门给 Seedance 2.0 增加按秒售卖 SKU，那时才会出现稳定的“秒数到价格”映射。但截至 2026-06-06，本地代码还没有这样做。