Seedance 那个「带视频输入便宜 40%」的档位，一分都省不到

Seedance 有两档 token 单价。带输入视频的任务走低的那一档，比纯文生便宜约 40%。这写在价目表上，所有转售这个模型的渠道都是同一个结构，看上去像一个省钱的办法。

我们做了受控实测。**带输入视频的片子实际贵约 4.5%，不是便宜 40%。**而且把数字追到帧这一层会发现，那 40% 在模型接受的每一个时长上都兑现不了——最好的情况也只是打平。下面是实测数据，和那道算术。

实测

只有一个变量。其余全部逐字相同：同一条提示词、4 秒、480p、16:9、无音频、同一个通道、同一个账号。

B 按 7.04 秒计费。而 2 秒输入 + 4 秒输出 = 6 秒。多出来的那一秒不是取整误差。

那一秒是从哪来的

对输入含视频的任务，Seedance 有一个最低 token 用量，而这个最低值是按输出时长算的：

最低 token 用量 = ceil(输出秒 × 5 ÷ 3) × 24 × 宽 × 高 ÷ 1024

4 秒的片子：ceil(4 × 5 ÷ 3) = ceil(6.67) = 7 秒。这个地板接管了计费，于是你实际用了 6 秒、被按 7 秒收。

现在把两个机制并排放：

5/3 × (42/70) = 1.000000

最低计费公式里的那个倍率，和两档单价之间的折扣比例，精确抵消。不是近似——小数点后六位。便宜的那一档和更高的地板，是被设计成互相抵消的。

那就带出一个问题：既然精确抵消，B 为什么还是贵了 4.5%？因为 4 秒这一档地板要向上取整。4 × 5/3 = 6.67，而计费不接受三分之二秒，ceil 把它顶到 7。**这个取整就是全部的差额。**在 输出 × 5/3 恰好落在整数上的那些时长，没有东西可取整，两个机制是真的抵消掉的。下面会回到这一点。

两家互不相关的通道，同一个数字

发布之前我们确认过这不是某一家的实现问题。我们换了另一个完全无关的 API 通道、在另一天、用同一组参数又跑了一遍。

67,652 token，逐位相同。

两家没有关系的通道、同一组参数、同一个数字。这说明它不是谁家服务器上的计费实现细节，而是模型本身的计量方式。也就意味着这里没有套利空间：换通道躲不开这个地板，因为地板不是通道设的。

那这个折扣到底什么时候出现

几乎从不——但「从不」这个词是错的，而原因就藏在上面那两个数字里。

再看一眼帧数。4 秒的片子 97 帧，7 秒的 169 帧。不是 96 和 168。计费单位是帧，而 T 秒的片子是 24T + 1 帧——每一段都多一个首帧。

就是这一帧，让两个机制没能精确抵消。按秒算，5/3 × 42/70 正好等于 1；按帧算就不是了，而这个残差极轻微地偏向带输入视频那一侧。

把模型接受的每一个输出时长都算一遍（输入视频固定 2 秒）：

27 个合法输出时长里，有 9 个略微更便宜。这 9 个全是 3 秒的整数倍——正好是 输出 × 5/3 落在整数上、地板不再向上取整的那些值。其余全部贵 1.8% 到 7.6%。

所以诚实的版本是：

• 那 40% 永远不会以 40% 的形式到账。任何时长都不会。
• 大多数时长下，挂输入视频要多付 2% 到 7.6%。
• 输出是 3 秒整数倍、且输入较短时打平——严格说是领先约千分之一，而那是那个首帧，不是折扣。

我们也拿自己的面板对了一遍：30 秒输出挂 4 秒参考，相对纯文生的倍率是 0.9969。千分之三。这就是那个「便宜 40% 的档位」在实际中值多少。

便宜的那一档不是一个你能拿到的折扣，它是一个更长的计价表的价格。

我们为什么要较这个真

我们是平台。价目表说了一件事，而我们差一点就把这句话原样转述给用户。不做实测就转述上游的价目表，是平台最容易说出「字面正确、实际不成立」的那种话的方式。

那张价目表上的单价没有错。所有人从它推出来的那个结论错了。

如果你在按成本挑模型：别比价目表，比两条完全相同的任务回传的 token 数。那个数字里才有你的钱。