Saltar al contenido principal
Contenido actualizado: 2026-06-23

Explicación de tarifas de Seedance 2.0

Este documento solo explica la lógica real de liquidación en el código actual de Crazyrouter, no es una explicación genérica de la página de precios oficial. Modelos aplicables:
  • doubao-seedance-2-0
  • doubao-seedance-2-0-fast
La dirección de integración debe utilizar https://api.crazyrouter.com; para configuraciones básicas, consulta API Endpoint.

Primero, el resumen

  1. Seedance 2.0 y Seedance 2.0 Fast en el código local se liquidan según per_output_token, no según segundos.
  2. Al enviar una tarea, la pre-deducción de estas tareas es por defecto 0.
  3. Después de completar la tarea, el sistema efectuará la deducción final según la respuesta del upstream: TotalTokens o CompletionTokens.
  4. duration se registra como característica de la tarea, pero no participa en la fórmula de liquidación final de Seedance 2.0.
  5. Por lo tanto, en el código no existe una fórmula global fija de “tantos tokens = tantos segundos”.
  6. Si hace falta responder “aproximadamente cuánto cuesta un segundo”, solo se puede usar tokens de salida reales / segundos reales como referencia después de completar la tarea, no como regla fija de tarifas.

Reglas de tarifas en el código local

1. Qué regla de tarifas aplica

Las reglas de tarifas de la serie Seedance 2.0 dependen de “si hay entrada de video o no”: Aquí video0 / video1 no son segundos, sino:
  • video0: la solicitud no contiene entrada de referencia de video
  • video1: la solicitud contiene entrada de referencia de video
Código correspondiente:
  • model/video_billing_seedance.go
  • relay/video_billing_runtime.go

2. Por qué usualmente no se deduce al enviar tareas

En tiempo de ejecución, el modo de tarifas de plataforma que aplica en Seedance 2.0 es per_output_token. En este tipo de tareas al enviar:
  • BasePrice se registra
  • Ratio se establece como 0
  • Por eso en la etapa de envío, el resultado de quota = int(ratio * QuotaPerUnit) es 0
Código correspondiente:
  • relay/video_billing_runtime.go
  • relay/relay_task.go
Por eso Seedance 2.0 se comporta así comúnmente:
  • Envío de tarea exitoso
  • No se deduce al principio, o la pre-deducción es 0
  • Después de completar la tarea, se deduce según tokens reales

Fórmula de deducción final

Después de completar la tarea, el sistema sigue primero settlePerOutputTokenTaskBilling. Para la serie Seedance, la prioridad para obtener tokens en el código es:
  1. taskResult.TotalTokens
  2. Si no está disponible arriba, se obtiene taskResult.CompletionTokens
Código correspondiente:
  • controller/task_video.go
Fórmula de precio final:
Fórmula final de cuota:
En el código actual:
Código correspondiente:
  • controller/task_video.go
  • common/constants.go

Qué papel juegan los segundos en el código

1. duration se identifica y registra

El código analiza los segundos desde estas posiciones:
  • req.Duration
  • req.Seconds
  • metadata.durationSeconds
  • metadata.duration_seconds
  • metadata.duration
  • metadata.seconds
Código correspondiente:
  • relay/video_billing_runtime.go

2. Pero Seedance 2.0 no liquida por segundos

Aunque duration queda en el perfil de la tarea y en los logs, los modos relevantes de Seedance 2.0 / 2.0 Fast son per_output_token, por lo tanto:
  • match.BilledSeconds no participa en la liquidación
  • La deducción final solo considera los tokens reportados por el upstream
Esto es diferente de modelos de video como Veo, Wan, esa clase de per_second.

Cómo comparar tokens y segundos

Método de liquidación

No se pueden convertir directamente. Es decir, en el código actual no existe una regla de este tipo:
La razón es simple:
  • El precio de venta de Seedance 2.0 no está configurado como per_second
  • El código tampoco mapea duration a una franja fija de tokens
  • Solo considera el uso real de tokens después de completar la tarea

Método de observación

Si solo quieres analizar “cuántos tokens consume en promedio por segundo esta tarea”, puedes calcular un valor observado al finalizar la tarea:
Al revés:
Pero esto es solo análisis posterior, no la fórmula de liquidación.

Caso real: video simple 4 segundos en 720p

A continuación se muestra el resultado de una llamada real a Seedance 2.0, para demostrar cómo deducir “el precio promedio por segundo para esta tarea” según la usage real.
Este caso es 720p, no es 1080p. La documentación actual de Crazyrouter sobre Seedance 2.0 / 2.0 Fast limita la capacidad pública a 480p, 720p; 1080p no está en el rango de soporte actual.

Caso 1: Generación de video desde texto más simple

Características de la solicitud:
  • Modelo: doubao-seedance-2-0
  • Entrada: solo texto, sin imagen ni referencia de video
  • Resolución: 720p
  • Duración: 4s
  • ID de tarea: cgt-20260617212928-5s755
  • Respuesta real del upstream: completion_tokens = 87300, total_tokens = 87300
Como la solicitud no incluyó entrada de referencia de video, se aplica:
Proceso de cálculo:
Por eso, este sencillo 4s 720p video generado desde texto tiene un precio observado aproximado de:

Caso 2: Generación de video de referencia basado en un video anterior

Características de la solicitud:
  • Modelo: doubao-seedance-2-0
  • Entrada: texto + el video generado en la tarea anterior como reference_video
  • Resolución: 720p
  • Duración: 4s
  • ID de tarea: cgt-20260617214300-rsnsx
  • Respuesta real del upstream: completion_tokens = 173700, total_tokens = 173700
Como la solicitud incluyó entrada de referencia de video, se aplica:
Proceso de cálculo:
Por eso, este 4s 720p video generado por referencia tiene un precio observado aproximado de:

Cómo explicar este valor comprobado al cliente

Puede explicarse de esta manera:
Por eso no se puede suponer “típicamente 1 segundo son 100,000 tokens”. Para una estimación fiable al cliente, se debe usar preferentemente usage.total_tokens o usage.completion_tokens de tareas reales.

Dos ejemplos listos para aplicar

Ejemplo 1: doubao-seedance-2-0-fast, con entrada de video

Suponga:
  • Aplica doubao-seedance-2-0-fast:video1
  • El upstream retorna TotalTokens = 1,200,000
  • quantityMultiplier = 1
  • groupRatio = 1
  • discount = 1
Entonces:
Si la solicitud contiene duration = 12, solo puedes obtener un valor observado:
Este 100,000 tokens/s solo es válido para esta tarea.

Ejemplo 2: doubao-seedance-2-0, sin entrada de video

Suponga:
  • Aplica doubao-seedance-2-0:video0
  • El upstream retorna CompletionTokens = 800,000
  • quantityMultiplier = 1
  • groupRatio = 1
  • discount = 1
Entonces:
Si se llenó duration = 8 al solicitar, solo sirve para observación:
Todavía no se puede concluir “una tarea de 8 segundos siempre son 800,000 tokens”.

Qué campos son importantes revisar

Si necesitas analizar el costo de una tarea de Seedance 2.0, prioriza estos datos:
  • Si la solicitud contiene entrada de video
  • billing_key aplicado
  • El valor de TotalTokens / CompletionTokens retornado por el upstream al completar la tarea
  • groupRatio para dicha tarea
  • El descuento del modelo discount
  • El valor final task.Quota
Los logs y snapshots del código también registran:
  • billing_mode
  • billing_key
  • billing_total_price
  • billing_output_tokens
  • billing_billed_tokens
  • billing_token_kind
  • billing_settled
Código correspondiente:
  • relay/relay_task.go
  • model/task.go
  • controller/task_video.go

Resumen en una frase

Para Seedance 2.0:
  • Número de segundos es característica de solicitud
  • token es el criterio de liquidación
  • quota es la cuota interna calculada tras liquidar token
Por tanto, el orden correcto es:
No:
Si más adelante la plataforma añade SKU de venta por segundos para Seedance 2.0, entonces aparecerá el mapeo estable de “segundos a precio”. Pero hasta el 2026-06-06, el código local no lo implementa.

Páginas relacionadas