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 數。那個數字裡才有你的錢。