Seedance 2.5 视频延长怎么算钱：从黑屏省钱到同价上下文

先说结果：在我这次 Seedance 2.5 的测试条件下，固定输出 30 秒，输入 1～20 秒参考视频，接口返回的 token 数完全一样；官方计算器里，这一段区间的价格也都一样，记录下来是约 45 元，和不输入视频、直接生成 30 秒相当。把输入加到 30 秒，再生成 30 秒，价格约 54 元。

所以，“塞一秒黑屏就能便宜一大截”的想法不成立。但对连续视频制作来说，这仍然是个好消息：既然短参考和较长参考处在同一计费档，就可以在不增加这部分费用的情况下，多给模型一些有用的前情。

我的关注点也跟着变了。最初想弄清楚视频续写究竟贵不贵，后来差点以为找到了省钱办法，最后发现真正值得利用的是这段同价的视频上下文。

起点其实是想把视频接起来

这轮探索最早不是为了研究价格。我想知道，Seedance 2.5 能不能把上一段视频接着往下拍。

最开始连时长限制都需要确认：所谓 30 秒，是输入加输出总共 30 秒，还是输入可以 30 秒，输出也能有 30 秒？我实际试过之后，确认了后一种情况。先生成一段 30 秒视频，把它作为输入继续生成下一段，再拿第二段往后接，流程能走通。

在我的长镜头测试里，衔接比之前用 2.0 时舒服，没有那种接头稍微顿一下的感觉。后来我又把一集剧本拆开，用下一段剧本加上一段视频做延长，拼出了约三分钟的短剧。我的观看感受是，画面和声音都接得不错。

这当然不意味着连续性从此不用管了。每次只带最近一段，模型就看不到更早的内容；换场景、人物重新出现时，仍然需要补充信息。但它至少让我觉得，值得把视频输入认真用起来。

接下来才轮到钱的问题。

输入翻了一倍，为什么只贵了两成

我当时在官方计算器里比较的是 720P、输出 30 秒这一组设置，记下了两笔数：

请求	当时记录的计算器价格
不输入视频，生成 30 秒	约 45 元
输入 30 秒视频，再生成 30 秒	约 54 元

这里的 45 和 54 是当时讨论中记录的价格，不是精确到分的账单。后面我会用具体宽高重新算一遍，也能看到这个差别。

直觉上，模型既要看完旧视频，又要生成新视频，价格似乎应该接近翻倍。实际却只贵了约 20%。我一开始也想解释它：是不是有视频作为条件，计算会容易一些？是不是厂商希望大家多用视频参考？

这些猜测没有证据，先放下。计费表里倒有一个直接影响结果的区别：当时我们查到的 Seedance 2.5 单价，无视频输入是每百万 token 70 元，有视频输入是 42 元。后者正好是前者的 60%。

假设其他条件不变，先只考虑输入、输出时长相加，那么：

输入 30 秒、输出 30 秒，相对纯生成 30 秒的价格
= (30 + 30) / 30 × 42 / 70
= 1.2

这就解释了 45 元和 54 元的比例。输入变多了，但整次请求适用的 token 单价降低了。不能拿没有视频输入的单价，直接乘上两倍时长。

顺着算下去，我想到了“一秒黑屏”

算到这里，很容易顺手得出另一个结论：既然带视频输入就按六折单价算，那把输入剪短，不就更便宜了吗？

例如取上一段最后 5 秒，再生成 30 秒。如果仍按刚才那套简化算法：

(5 + 30) / 30 × 0.6 = 0.7

看起来只需原价的 70%。既给了模型连续性信息，又省了 30%，这事也太合适了。

我甚至往前多想了一步：如果只是为了触发有视频输入的价格，能不能每次都传一秒黑屏？同样算下去，比例是 31 / 30 × 0.6 = 0.62，似乎能省 38%。

当时和 AI 一起查资料、推公式，它也顺着这个思路算出了“可能省钱”。但我越想越觉得不对：这么直接、这么大的差价，为什么没看到大家都在这么做？

问题出在我们漏掉了最低计费量。上面这两个省钱比例，都是漏算之后的错误结论。

单价是六折，不代表账单就是六折

继续查下去，才发现含视频输入的请求还存在最低 token 用量限制。按时长、像素和帧率算出来的用量如果低于这个下限，并不会按那个更小的数收费。BytePlus 的官方计费文档也解释了这种机制，并说明最低值与分辨率、宽高比、输出时长有关；实际用量要看接口返回的 usage.completion_tokens。

当时找到的一篇开发者实算记录给了我一个很有用的线索：用大约 输出时长 × 5/3 的最低计费窗口，可以解释一批公开价格。作者也说明，这个系数是反推得到的，不能直接当成所有时长都已验证的官方公式。

把这个假设放到 30 秒输出上，下限就是相当于 50 秒的计费量。这样一来，输入 1 秒还是 20 秒，输入与输出相加都不超过 50 秒，价格自然会被抹平。

而 50 × 42 恰好等于 30 × 70。这也解释了为什么加短视频后单价下降，最终价格却能和纯生成持平。

为了看清数字，我按 1280×720、24 fps 演算了一遍。下面是对这个假设的计算，不是从历史调用里重新取出的原始 token 日志：

每秒对应的估算 token = 1280 × 720 × 24 / 1024 = 21,600

无视频输入，输出 30 秒：
30 × 21,600 = 648,000 token
648,000 / 1,000,000 × 70 = 45.36 元

有短视频输入，按相当于 50 秒的下限计算：
50 × 21,600 = 1,080,000 token
1,080,000 / 1,000,000 × 42 = 45.36 元

输入 30 秒，输出 30 秒：
60 × 21,600 = 1,296,000 token
1,296,000 / 1,000,000 × 42 = 54.432 元

它与我记下的约 45 元、54 元对得上。也能看出来，“720P、30 秒”还不足以独立描述一张精确账单，具体宽高、返回用量和适用单价都不能省略。国内价格可以从火山方舟模型价格页重新核对，不要把这次实验的金额当成所有渠道的固定报价。

最后用实际调用确认，而不是停在公式上

到这里，解释已经合理了，但仍然只是一个需要验证的假设。我还怀疑过：如果接入层只是拿“输入时长加输出时长”自己算钱，会不会漏掉最低计费量，把短输入的价格报低了？

于是我去实际调用，同时把官方计算器也按了一遍。

结果很干脆：固定输出 30 秒，输入在 1～20 秒范围内变化，返回的 token 数是一模一样的；计算器对应的价格也全部相同，都是我当时记下的 45 元。

这才把前面的猜测落了地。我们确实看到了一个同价区间，不是界面上的一句“有视频输入更便宜”，也不是只靠单价除出来的结果。

我没有因此把所有输出时长都宣布成同一个规律。30 秒输出是这次直接确认的场景；更短输出的取整方式、其他分辨率和渠道，都需要各自核对。尤其是不能把第三方平台的一句折扣说明，直接套进火山官方接口的结算。

至于一秒黑屏，我并没有得到“靠它成功省钱”的结果。最低计费量已经解释了为什么那笔账算不通，也没必要为了凑输入，额外给模型塞一段没有创作价值的内容。

最后留下的，是一个更实用的续写习惯

这轮算账改变了我挑参考片段的方式。

如果下一段准备生成 30 秒，上一段最后 20 秒又恰好包含有用的动作和场景状态，那么在这次验证过的条件下，不必仅仅为了省钱把它剪成 5 秒。5 秒和 20 秒可能付的是同一笔费用。

但我也不会强制每次塞满 20 秒。上一段里如果已经换过场景，或者较早部分对下一段没有帮助，剪掉反而更清楚。输入更长不等于效果必然更好；价格相同，只是让我可以主要根据内容来选，而不用纠结这几秒会不会又多花钱。

我的默认思路会是：先选上一段里真正有用的尾部片段，在已验证的同价范围内保留足够上下文，再根据下一段的剧情决定是否需要更长的参考。需要 30 秒就用 30 秒，只要知道多花的钱买到了什么。

回头看，这次最有意思的地方，是结论真的变过。起初我以为视频延长比想象中便宜，接着以为短输入还能明显省钱，最后亲自确认，短输入之间的价格被最低计费量抹平了。

省下 38% 的设想没了，不过我更清楚下一次该怎么选参考视频。