La factura de la API de video de Seedance rara vez equivale a multiplicar el número de piezas por un precio fijo. Dos videos de cinco segundos pueden costar distinto según la resolución, el nivel del modelo, la presencia de una entrada de video, los reintentos por fallo y el almacenamiento del resultado. Si el presupuesto se calcula solo con la tarifa publicada, es habitual que la factura real llegue más alta: casi nunca porque el precio unitario haya subido, sino porque estas variables no se tuvieron en cuenta.

Este artículo desglosa la facturación en cuatro dimensiones —duración, resolución, reintentos y almacenamiento— y ofrece una fórmula de estimación, pasos de medición y métodos de control del presupuesto. Las tarifas y los criterios concretos cambian; toma como referencia la página de precios de modelos del sitio y la documentación oficial de facturación.

Nota: Seedance es un modelo de generación de video de ByteDance; Seedance, Doubao, Volcano Engine y BytePlus son marcas de sus titulares (ByteDance y sus sociedades vinculadas). Este artículo solo ofrece una explicación técnica y no guarda relación de dependencia ni representación con esos titulares. Los precios, las interfaces y las reglas de facturación se rigen por la documentación oficial y la página de precios del sitio.

1. Por qué la API de video no se puede presupuestar por piezas

La unidad de facturación de las API de texto es relativamente uniforme; la de las API de video no lo es. Detrás de una petición para generar un video hay al menos cuatro variables: duración, resolución, nivel del modelo y forma de entrada. Si cambia cualquiera de ellas, la factura puede ser distinta.

El problema se complica porque enviar una tarea no equivale a obtener una pieza utilizable. Los rechazos de moderación, los tiempos agotados y las imágenes inservibles obligan a reintentar; cuando el enlace del resultado caduca, hay que volver a generar o transferir el archivo. Presupuestar solo con el número de envíos multiplicado por la tarifa conduce a una subestimación sistemática.

2. Las cuatro dimensiones de la facturación

Dimensión Cómo afecta al costo Qué registrar al estimar Cómo controlarla
Duración Se acumula por segundo o por tokens equivalentes; a mayor duración, mayor consumo Duración enviada, duración final y si hubo segmentación Probar primero con la opción corta y unir después las piezas
Resolución El total de píxeles crece con la resolución y suele sumarse el efecto de los fotogramas por segundo Resolución de salida, tasa de fotogramas y proporción Borradores en baja resolución y versión final en alta
Modelo y entrada Cada generación, nivel y forma de entrada tiene una tarifa distinta Nombre del modelo y si hay fotograma inicial o video de referencia Derivar por dificultad, sin usar siempre el nivel superior
Fallos y reintentos Un envío repetido puede facturarse dos veces; las reglas de las tareas fallidas varían Estado de la tarea, código de error y número de reintentos Clasificar errores, aplicar idempotencia y limitar reintentos
Almacenamiento y tráfico La transferencia, conservación y distribución del resultado genera costos adicionales Tamaño del archivo, días de conservación y volumen de accesos Reglas de ciclo de vida y distribución bajo demanda

Las generaciones más recientes de la serie Seedance se miden por tokens en la documentación oficial, y el consumo depende de la resolución, la duración y el tipo de entrada; algunas pasarelas lo convierten a segundos o a piezas para mostrarlo. Antes de contratar, confirma la unidad que aparece en la factura.

3. Cómo la duración y la resolución amplifican el consumo

La duración es la variable más evidente. Las opciones habituales son cinco y diez segundos, pero diez segundos no siempre cuestan exactamente el doble que cinco: algunas plataformas fijan una unidad mínima de facturación y otras cobran por segundos redondeados. El presupuesto debe basarse en el cargo real de la factura, no en una reconstrucción a partir de la duración final.

El efecto de la resolución es más difícil de ver. Al pasar de 720p a 1080p, el total de píxeles se multiplica por aproximadamente 2,25; si además sube la tasa de fotogramas, el consumo sigue creciendo. Sin embargo, la factura final no tiene por qué cambiar en esa misma proporción, porque intervienen el nivel del modelo, los descuentos y el redondeo de la facturación. Lo correcto es fijar el prompt y la duración, cambiar solo la resolución y ejecutar una comparación para registrar la diferencia de cargo.

La proporción de la imagen también afecta al total de píxeles. En un mismo nivel de resolución, el formato vertical y el horizontal pueden dar un número distinto de píxeles; conviene crear presupuestos separados en lugar de compartir un promedio mensual.

4. Por qué los reintentos y el almacenamiento suelen quedar fuera del cálculo

Los reintentos por fallo son la parte del costo de video más fácil de descontrolar. Un error de parámetros no debe reintentarse; un rechazo de moderación repetido normalmente no cambia de resultado; solo la limitación de tasa y algunos errores del servidor admiten retroceso y reintento.

Se recomienda guardar el ID de tarea en la base de datos, comprobar la idempotencia antes de enviar y reutilizar el mismo registro de negocio en los reintentos. De lo contrario, un bucle de script puede enviar decenas de tareas idénticas en pocos minutos y producir una factura difícil de explicar.

El costo de almacenamiento se pasa por alto con frecuencia. El enlace del resultado suele tener vigencia; una vez caducado, hay que volver a generar. Al transferir a un almacenamiento de objetos aparecen además gastos de almacenamiento, peticiones y tráfico de salida. Conviene transferir en cuanto la tarea termina y definir reglas de limpieza: borradores durante siete días, piezas finales archivadas por proyecto y materiales descartados eliminados a tiempo.

5. Expresar el costo por pieza como una fórmula

Un indicador más fiable que la tarifa multiplicada por la duración es el costo por cada video utilizable:

Costo por video utilizable = (costo de tareas correctas + costo de tareas fallidas facturadas + almacenamiento y tráfico + revisión manual) ÷ número de videos aprobados y listos para usar

El denominador son las piezas utilizables, no el número de envíos. El siguiente código de Python hace el cálculo; los importes se leen de la factura y no se fijan en el código:

def costo_por_video_utilizable(costos_tarea, videos_utilizables, costo_almacenamiento=0.0, costo_revision=0.0):
    """costos_tarea: importe facturado por cada tarea; videos_utilizables: piezas aptas para uso"""
    if videos_utilizables == 0:
        raise ValueError("No hay videos utilizables; revisa primero los prompts, los materiales y los parámetros")
    total = sum(costos_tarea) + costo_almacenamiento + costo_revision
    return total / videos_utilizables

# Sustituye los valores de ejemplo por los importes exportados de la factura, con la misma unidad
costos_semanales = [0.0] * 40
print(costo_por_video_utilizable(costos_semanales, videos_utilizables=28))

Registra también los campos de uso que devuelve la respuesta: modelo, duración, resolución, estado y tiempo empleado. Solo con criterios consistentes se puede comparar semana a semana; no mezcles datos de canales distintos.

6. Pasos estándar para una medición con lote pequeño

  1. Fija un nivel de modelo, una duración y una resolución como línea base.
  2. Prepara entre veinte y treinta prompts reales del negocio y sus fotogramas iniciales; no uses solo ejemplos que salen bien.
  3. Anota por tarea el estado, el código de error, el tiempo y el cargo en la factura.
  4. Incluye las tareas fallidas en el costo total y calcula el costo por video utilizable.
  5. Observa durante siete días consecutivos, extrapola el costo mensual con la media diaria y añade almacenamiento, tráfico y horas de revisión.
  6. Cambia una sola variable cada vez, por ejemplo subir un nivel la resolución, para obtener la sensibilidad del costo.
  7. Con los resultados, define el nivel de prueba y el nivel de producción final, y déjalos escritos en la norma del equipo.

El valor de la medición no es solo obtener una cifra, sino saber a qué variable responde más el costo.

7. Medidas concretas de control del presupuesto

  • Una clave por proyecto, con pruebas y producción separadas, para no mezclar gastos.
  • Fijar un límite de cuota por clave en la consola y configurar alertas de consumo diario o semanal.
  • Estimar antes de enviar con los parámetros actuales y derivar a revisión manual si se supera el umbral por pieza.
  • Limitar la concurrencia y el número máximo de reintentos, sobre todo en scripts por lotes.
  • Usar siempre baja resolución para borradores y generar la versión de alta solo para los planos aprobados.
  • Transferir los resultados a tiempo y definir ciclos de vida; conciliar cada semana por proyecto, modelo y resolución.

La pasarela suele ofrecer cuota por clave, lista de modelos permitidos y exportación de consumo; los detalles dependen de la consola. Las alertas deben llegar a una persona: enviarlas a un chat que nadie revisa equivale a no tenerlas.

8. Orden de reducción de costos y tres errores frecuentes

La reducción debe avanzar de mayor a menor impacto: primero mejorar la tasa de éxito, después eliminar reintentos inútiles, luego separar por resolución y recortar duración, a continuación ordenar el almacenamiento y, por último, considerar un cambio de canal. Si se invierte el orden, el resultado típico es una tarifa más baja con una tasa de fallos y un costo total más altos.

Tres errores frecuentes:

  1. Mirar solo la tarifa y no la tasa de éxito ni los reintentos. Un canal de bajo precio que falla a menudo puede tener un costo por pieza utilizable más alto.
  2. Medir con la duración más corta y producir con la más larga y alta resolución, con lo que el presupuesto no cuadra.
  3. Ignorar la vigencia del enlace del resultado y volver a generar tras caducar, pagando dos veces.

Preguntas frecuentes

¿La API de Seedance se factura por pieza, por segundo o por tokens?

Las generaciones más recientes de la serie Seedance suelen medirse por tokens en la documentación oficial, y el consumo depende de la resolución, la duración y la forma de entrada; algunas pasarelas lo convierten a segundos o a piezas. Antes de integrar, confirma la unidad de la factura y guíate por la página de precios de modelos.

Si subo la resolución de 720p a 1080p, ¿se duplica el costo?

El total de píxeles pasa a ser aproximadamente 2,25 veces mayor, pero el cargo real también depende del nivel del modelo, la unidad mínima de facturación y los descuentos, así que no basta con multiplicar por dos. Es más fiable hacer una prueba comparativa con el mismo prompt.

¿Se cobran las tareas fallidas o rechazadas por moderación?

Las reglas varían según la plataforma y el motivo del fallo. Algunos errores del sistema no se cobran y otros servicios facturan desde la creación de la tarea. Confírmalo con un pedido de prueba antes de integrar e incluye el costo de los fallos en el costo por pieza.

¿Por qué la prueba sale barata y la factura sube al pasar a producción?

Las causas habituales son probar con cinco segundos y baja resolución frente a producir con diez segundos en alta definición; el aumento de reintentos; los costos de transferencia y distribución; y el uso compartido de una clave que impide imputar gastos. Separa las claves por proyecto y registra la factura a nivel de tarea.

¿Cómo se fija un límite de presupuesto para la generación de video?

Con al menos tres niveles: cuota por clave, presupuesto por proyecto y estimación antes del envío a nivel de tarea. Al alcanzar un umbral, pausa las tareas no críticas y avisa al responsable; no dependas solo de la factura de fin de mes.

Siguiente paso

Crea primero una clave de prueba en ZSQH AI Gateway, ejecuta entre veinte y treinta tareas con la configuración mínima, registra la tasa de éxito, el tiempo y el cargo, y convierte el resultado en presupuesto mensual según la página de precios de modelos. Si necesitas entender antes el flujo de tareas asíncronas, continúa con la guía de integración del sitio.

Lecturas relacionadas: