Una evaluación de la API de Seedance debe responder a una pregunta de producto, no solo generar un clip de demostración impresionante. La decisión real es si tu equipo puede convertir prompts y medios de referencia en activos de video aceptables con una calidad, latencia, seguridad y costo predecibles.
A fecha de 11 de septiembre de 2026, la página del modelo en vivo seedance-2.5 de Flatkey describe una ruta de video de ByteDance para generación de texto a video e imagen a video, con metadatos públicos que muestran precios por segundo basados en el uso. El patrón de solicitud actual es asincrónico: crea una tarea de video con POST /v1/video/generations, conserva el ID de tarea devuelto y haz sondeo de GET /v1/videos/{task_id} hasta que el trabajo alcance un estado terminal.
Ese contrato de API es sencillo. Diseñar una evaluación de la API de Seedance útil es más difícil. Esta guía ofrece a los gerentes de producto y a los responsables de ingeniería un conjunto de pruebas repetible, una tarjeta de puntuación ponderada, una métrica de coste por clip aceptado y un plan de despliegue de cinco días.
Respuesta rápida: ¿qué debería medir una evaluación de la API de Seedance?
Evalúa la API en seis filtros:
- Ajuste de capacidades: ¿Puede producir las escenas, el movimiento, el encuadre y la coherencia con referencias que tu producto requiere?
- Repetibilidad: ¿La misma familia de prompts produce resultados utilizables en varias ejecuciones?
- Ajuste al flujo de trabajo: ¿Puede tu aplicación gestionar con limpieza tareas asincrónicas, sondeo, tiempos de espera, almacenamiento y reintentos?
- Ajuste a la experiencia de usuario: ¿Puedes establecer expectativas honestas sobre la espera, el progreso, la regeneración y los fallos?
- Ajuste a la seguridad: ¿Puede tu producto impedir entradas no permitidas y revisar los resultados antes de su distribución?
- Ajuste a la economía unitaria: ¿Cuánto cuesta un clip aceptado después de incluir los trabajos fallidos y los resultados rechazados?
No apruebes a un proveedor basándote en una sola generación seleccionada. Una evaluación de la API de Seedance útil usa un conjunto fijo de prompts, ejecuciones repetidas, puntuación ciega y las mismas reglas de aceptación para cada modelo candidato.
Empieza con el contrato actual de la API de Seedance
La página actual del modelo seedance-2.5 de Flatkey presenta la ruta como un modelo de texto/imagen a video y documenta el patrón de tarea de video que los equipos de producto necesitan evaluar. El ejemplo de la página crea una tarea de cinco segundos en 1080p:
curl -X POST https://router.flatkey.ai/v1/video/generations \
-H "Authorization: Bearer $FLATKEY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "seedance-2.5",
"content": [
{
"type": "text",
"text": "Un avión de papel volando sobre una ciudad neón al atardecer"
}
],
"resolution": "1080p",
"duration": 5
}'
Luego haz sondeo de la tarea usando el ID devuelto:
curl https://router.flatkey.ai/v1/videos/TASK_ID \
-H "Authorization: Bearer $FLATKEY_API_KEY"
Consulta la página del modelo Seedance 2.5 en vivo antes de implementar, porque la disponibilidad, los campos de solicitud, las señales de estado y las condiciones comerciales pueden cambiar.
Si tu equipo aún no ha verificado su clave y su URL base, completa primero el inicio rápido de la API de Seedance existente. Usa este artículo después de que la conectividad funcione y el equipo de producto esté listo para juzgar si la ruta se ajusta a un caso de uso real.
Define un contrato de evaluación antes de generar clips
El paso de mayor impacto en una evaluación de la API de Seedance es acordar el contrato de aceptación antes de que alguien vea resultados. De lo contrario, las partes interesadas tienden a premiar el clip que se ve más cinematográfico y a cambiar discretamente sus estándares entre ejecuciones.
Anota estos campos:
| Campo | Decisión del equipo de producto |
|---|---|
| Flujo de trabajo objetivo | Creatividad para redes sociales, movimiento de producto, storyboard, concepto de juego, variante de anuncio u otro trabajo definido |
| Modo de entrada | Texto a video, imagen a video o ambos |
| Requisito de salida | Duración, resolución, relación de aspecto, encuadre y formato de entrega |
| Movimiento requerido | Movimiento de cámara, movimiento de objetos, movimiento de personajes o composición mayormente estática |
| Requisito de referencia | Ninguno, referencia de estilo flexible o consistencia estricta del sujeto/producto |
| Tiempo de espera aceptable | Tiempo máximo antes de que el usuario deba ver un resultado o un estado de fallo claro |
| Límite de seguridad | Prompts no permitidos, temas restringidos, pasos de revisión y reglas de publicación |
| Responsable de aceptación | El rol que toma la decisión final de utilizable/no utilizable |
| Unidad de presupuesto | Costo por segundo generado, tarea completada, clip aceptado o recurso publicado |
El responsable de aceptación debe estar cerca del flujo de trabajo final. Un líder creativo de growth puede aceptar un clip que un equipo de renderizado de producto rechaza porque cambió la forma del producto. Una sola puntuación universal de calidad no puede representar todos los casos de uso.
Construye un conjunto de pruebas de 24 prompts para la API de Seedance
Un conjunto de pruebas práctico es lo bastante grande para exponer patrones de fallo, pero lo bastante pequeño para repetirlo cuando cambie una ruta, una plantilla de prompt o un modelo. Empieza con 24 prompts repartidos en seis grupos.
| Grupo de prompts | Prompts | Qué prueba |
|---|---|---|
| Movimiento simple de un sujeto | 4 | Movimiento básico, integridad del objeto y fondos limpios |
| Cámara y composición | 4 | Paneo, seguimiento, primer plano, plano general y cumplimiento del encuadre |
| Interacción de múltiples elementos | 4 | Relaciones espaciales, colisiones, oclusión y consistencia temporal |
| Objetos de producto o de apariencia de marca | 4 | Estabilidad de la forma, apariencia del material y sensibilidad a la referencia |
| Escenas creativas estilizadas | 4 | Dirección artística, iluminación, atmósfera e interpretación del prompt |
| Casos límite deliberados | 4 | Instrucciones densas, movimiento inusual, prompts ambiguos y límites de seguridad |
Ejecuta cada prompt al menos tres veces cuando el presupuesto lo permita. Una ejecución prueba la posibilidad; las ejecuciones repetidas prueban si tu producto puede depender de ese comportamiento.
Mantén los prompts neutrales respecto al proveedor. Evita la sintaxis de prompt que solo un modelo entiende, a menos que la propia función forme parte de la evaluación. Guarda el prompt, los parámetros de la solicitud, el ID de la tarea, las marcas de tiempo, el estado terminal, la URL de salida y las puntuaciones del revisor para cada ejecución.
La investigación pública de Seedance de ByteDance enfatiza dimensiones como el seguimiento de instrucciones, la calidad del movimiento, la consistencia temporal, la narrativa de varias tomas y la calidad visual. Esas son categorías de evaluación útiles, pero tu equipo debería traducirlas en requisitos de producto observables en lugar de copiar directamente un benchmark de investigación.
Usa una tarjeta de puntuación ponderada de evaluación de la API de Seedance
La siguiente tarjeta de puntuación funciona como punto de partida para productos generales de texto a video. Cambia los pesos antes de probar si tu caso de uso tiene prioridades diferentes.
| Dimensión | Peso | Pregunta del revisor |
|---|---|---|
| Adherencia al prompt y a las instrucciones | 20 | ¿El clip siguió el sujeto, la acción, el entorno y la dirección de cámara solicitados? |
| Calidad del movimiento | 20 | ¿El movimiento es lo suficientemente natural para el flujo de trabajo previsto del producto? |
| Consistencia temporal | 15 | ¿Los objetos, los fondos y las identidades visuales permanecen coherentes con el tiempo? |
| Composición y calidad visual | 10 | ¿El encuadre, la iluminación, el nivel de detalle y la presentación general son utilizables? |
| Consistencia de referencia | 10 | Cuando se proporciona una imagen, ¿el resultado preserva el sujeto o los rasgos del producto requeridos? |
| Tiempo hasta un resultado utilizable | 10 | ¿La espera total, incluidos los reintentos, se ajusta a la experiencia de usuario? |
| Confiabilidad de finalización | 5 | ¿Con qué frecuencia las tareas se completan sin fallos de transporte, del proveedor o de salida? |
| Seguridad y capacidad de revisión | 5 | ¿Se pueden detectar antes de la publicación las solicitudes y salidas inseguras o inadecuadas? |
| Costo por clip aceptado | 5 | ¿Es sostenible el costo real después de contar las salidas rechazadas? |
Califica cada dimensión de calidad del 1 al 5, multiplícala por su peso y normaliza el resultado a 100. Mantén las métricas operativas, como la latencia y la tasa de finalización, medidas directamente en lugar de puntuadas de memoria.
Para una evaluación de la API de Seedance justa, los revisores no deberían saber qué proveedor produjo cada clip cuando compares varios modelos. Aleatoriza los nombres de archivo, elimina los metadatos del proveedor de la hoja de revisión y revela el modelo solo después de completar la puntuación.
Mide el costo por clip aceptado, no el costo por generación
La métrica de costo más útil para la generación de video es:
costo por clip aceptado = gasto total de generación / clips aceptados
Si 30 tareas cuestan $60 y solo 12 salidas pasan la revisión, el costo efectivo es de $5 por clip aceptado, no de $2 por generación.
Además, controla:
tasa de aceptación = clips aceptados / clips completados
tasa de finalización = clips completados / tareas enviadas
costo por activo publicado = gasto total de generación / activos realmente publicados
Esto evita que una ruta barata pero inconsistente parezca mejor que una ruta más costosa que produce resultados utilizables con mayor frecuencia. También conecta la evaluación del modelo con el rendimiento creativo o de producto real del equipo.
Flatkey presenta actualmente seedance-2.5 con precios basados en el uso, por segundo. Utiliza el directorio de modelos en vivo, la página del modelo Seedance 2.5 y la página de precios para obtener la información comercial actual en lugar de copiar una cifra estática en una hoja de cálculo de planificación.
Normaliza el flujo de trabajo asíncrono detrás de un único adaptador
Tu producto no debería exponer estados de tareas específicos del proveedor en toda la base de código. Coloca la API de Seedance detrás de un pequeño adaptador de generación de video y normaliza el ciclo de vida.
type VideoJobState =
| "queued"
| "processing"
| "succeeded"
| "failed"
| "expired";
type VideoJob = {
id: string;
state: VideoJobState;
outputUrl?: string;
errorCode?: string;
submittedAt: string;
completedAt?: string;
};
interface VideoGenerationAdapter {
create(input: {
prompt: string;
imageUrl?: string;
duration: number;
resolution: string;
}): Promise<VideoJob>;
get(jobId: string): Promise<VideoJob>;
}
El adaptador debería conservar el ID de la tarea del proveedor, el estado terminal bruto, los parámetros de la solicitud y los datos de uso para depuración. El resto del producto debería depender de estados normalizados.
Este límite hace que la evaluación de la API de Seedance sea más honesta. Puedes comparar la calidad y las operaciones de Seedance con otra ruta de video sin reescribir el flujo de tu producto. También te ofrece un lugar controlado para implementar intervalos de sondeo, presupuestos de tiempo de espera, reglas de reintento, verificación de webhooks y lógica de migración.
Para un patrón de implementación más profundo, consulta la guía sobre una URL base estable compatible con OpenAI para equipos de la API de Seedance. Antes del lanzamiento, ejecuta la lista de verificación de producción de la API de Seedance aparte para durabilidad de la cola, idempotencia, almacenamiento y controles de incidentes.
Mapea el comportamiento de la API a la experiencia del producto
Una ruta de video asíncrona crea decisiones de experiencia de usuario que un endpoint de texto sincrónico no crea.
Estado de espera
Muestra que la solicitud fue aceptada y proporciona una referencia de trabajo duradera. No des a entender que un video está casi terminado a menos que la API exponga un progreso confiable.
Estado de tiempo de espera
Separa una tarea lenta de una tarea fallida. Un tiempo de espera del cliente no debería crear automáticamente una segunda generación facturable. Sigue comprobando la tarea original antes de permitir un reintento.
Regeneración
Permite que los usuarios cambien una variable a la vez—prompt, imagen de referencia, duración o resolución—para que los equipos puedan aprender por qué un resultado mejoró o empeoró.
Revisión del resultado
Almacena el prompt y los parámetros junto al clip. Proporciona un estado de revisión interna antes de que un activo generado pueda pasar a un flujo de trabajo público o orientado al cliente.
Lenguaje de error
Convierte las fallas del proveedor en mensajes de producto accionables: entrada no compatible, rechazo por seguridad, capacidad temporal insuficiente, activo caducado o error de servicio recuperable. Conserva el código sin procesar para soporte e ingeniería.
Incluye estos estados de UX en la evaluación de la API de Seedance. Un modelo puede producir clips excelentes y aun así ser una mala opción para el producto si no se pueden comunicar con claridad su latencia y su comportamiento ante fallos.
Añade seguridad y revisión de contenido a la evaluación
Las entradas y salidas de texto a video deben pasar por controles específicos del producto. Como mínimo:
- validar el tipo, tamaño y origen del medio de entrada;
- rechazar solicitudes obviamente no permitidas o no compatibles antes de crear una tarea de pago;
- registrar quién envió la solicitud y qué versión de la política se aplicó;
- analizar o revisar las salidas completadas antes de su distribución pública;
- definir reglas de retención y eliminación para prompts, referencias y archivos generados;
- evitar que una URL temporal firmada se convierta en el registro permanente del activo del producto.
No asumas que la capa de seguridad de un proveedor equivale a la política de tu producto. Tu aplicación sigue siendo responsable de decidir qué pueden solicitar los usuarios y qué contenido generado puede almacenarse, mostrarse o publicarse.
Ejecuta una evaluación de cinco días con el equipo de producto
Día 1: bloquea el contrato
Elige el flujo de trabajo, el responsable de aceptación, 24 prompts, parámetros, ponderaciones de puntuación y presupuesto máximo. Verifica el acceso actual, el estado de salud, los campos de solicitud y el precio por segundo en la página del modelo Seedance 2.5.
Día 2: implementa el adaptador
Crea tareas, persiste los IDs de tarea, sondea de forma segura, normaliza los estados y almacena las salidas. Confirma que una sesión de cliente interrumpida no haga perder el trabajo.
Día 3: genera el conjunto fijo de pruebas
Ejecuta el mismo conjunto de prompts con parámetros controlados. Registra cada solicitud, incluidos los fallos y las salidas que los revisores rechazan de inmediato.
Día 4: puntúa a ciegas
Pide al menos a dos revisores que puntúen los clips de forma independiente. Calcula la tasa de aceptación, la tasa de finalización, p50 y p95 del tiempo hasta el estado terminal, la puntuación de calidad ponderada y el costo por clip aceptado.
Día 5: decide y documenta
Aprobar uno de cuatro resultados:
- Avanzar a beta limitada para el flujo de trabajo probado.
- Avanzar con restricciones sobre tipos de prompts, duración, entradas de referencia o grupos de usuarios.
- Continuar la evaluación con prompts revisados o una muestra mayor.
- No avanzar porque la calidad, las operaciones, la seguridad o la economía unitaria no alcanzan el umbral acordado.
Esta estructura de cinco días evita que una evaluación de la API de Seedance se convierta en un experimento creativo sin límites.
Ejemplos de umbrales de ir/no ir
Establece los umbrales antes de probar. Un equipo de producto hipotético podría requerir:
| Métrica | Umbral de ejemplo |
|---|---|
| Puntuación de calidad ponderada | Al menos 78/100 |
| Tasa de aceptación | Al menos 60% |
| Tasa de finalización | Al menos 97% |
| p95 del tiempo hasta el estado terminal | Dentro de la ventana de espera declarada del producto |
| Fallas críticas de seguridad | Cero |
| Costo por clip aceptado | Dentro del presupuesto aprobado del flujo de trabajo |
| Fallas que rompen la referencia | Por debajo del límite específico del caso de uso |
Estos son ejemplos, no puntos de referencia universales. Una herramienta de storyboard puede tolerar una fidelidad más baja que un flujo de trabajo automatizado de anuncios de producto. El valor proviene de comprometer de antemano umbrales medibles.
¿Qué hace que esta evaluación sea reutilizable?
Versiona juntos el conjunto de prompts, la tarjeta de puntuación, el adaptador y el conjunto de datos de resultados. Cuando cambien los accesos o esté disponible una nueva ruta de Seedance, vuelve a ejecutar el mismo paquete.
Conserva estos artefactos:
- versión del conjunto de prompts;
- versión del esquema de solicitud;
- ID del modelo y de la ruta;
- parámetros de generación;
- marcas de tiempo sin procesar del ciclo de vida de la tarea;
- IDs de los revisores y puntuaciones ciegas;
- decisión de aceptación y motivo del rechazo;
- registro de costos y uso;
- versión de la política;
- decisión final de ir/no ir.
Eso convierte la evaluación de la API de Seedance en un activo duradero de operaciones de modelos en lugar de un documento de lanzamiento de una sola vez. La misma estructura también admite un enrutamiento de modelos multimodales más amplio cuando tu producto compara modelos de video, imagen, audio y lenguaje detrás de una sola capa de acceso.
Recomendación final
Usa la API de Seedance cuando pase el contrato de aceptación de tu flujo de trabajo, no porque un clip generado se vea impresionante. Verifica la ruta actual, prueba un conjunto fijo de prompts, califica las salidas de forma ciega, incluye los fallos en la economía unitaria y mantén el ciclo de vida asíncrono detrás de un adaptador.
Para los usuarios de Flatkey, la secuencia práctica es:
- verificar la clave y el router con el inicio rápido de la API de Seedance;
- confirmar el acceso actual a
seedance-2.5, los campos de solicitud, el estado de salud y los precios en la página del modelo en vivo; - ejecutar la tarjeta de puntuación de esta guía;
- completar la lista de verificación de producción antes del despliegue a clientes.
Una evaluación disciplinada de la API de Seedance ofrece a los equipos de producto, ingeniería, creatividad, seguridad y finanzas una respuesta compartida: si la ruta puede producir de forma fiable video aceptable para el flujo de trabajo que realmente planeas lanzar.
Preguntas frecuentes
¿La API de Seedance es síncrona o asíncrona?
El ejemplo actual de seedance-2.5 de Flatkey usa un flujo de trabajo asíncrono. La aplicación crea una tarea de video, almacena el ID de tarea devuelto y consulta el endpoint de la tarea de video hasta su finalización.
¿Cuál es la métrica más importante de evaluación de la API de Seedance?
Para la mayoría de los equipos de producto, es el costo por clip aceptado, porque esa métrica incluye tanto el gasto de generación como la usabilidad del resultado. Combínala con la tasa de aceptación, la tasa de finalización, la latencia y una puntuación de calidad ponderada.
¿Cuántos prompts debería probar un equipo de producto?
Veinticuatro prompts en seis grupos de comportamiento es un punto de partida práctico. Ejecute cada prompt varias veces cuando el presupuesto lo permita, de modo que la evaluación mida la repetibilidad en lugar de la posibilidad.
¿Deben los revisores saber qué modelo produjo cada clip?
No, no cuando se comparan proveedores o versiones de modelo. La revisión ciega reduce la preferencia por la marca y el sesgo de confirmación.
¿Seedance 2.5 admite imagen a video?
La página del modelo en vivo de Flatkey actualmente enumera seedance-2.5 como una ruta de ByteDance de texto/imagen a video. Confirme la ruta, los campos y los precios actuales antes de implementar.
¿Debería un producto reintentar automáticamente una solicitud de video agotada por tiempo?
No creando inmediatamente una nueva tarea. Primero verifique el ID de la tarea existente. Un tiempo de espera del cliente no demuestra que la tarea del proveedor haya fallado, y un reenvío automático puede crear trabajo y gasto duplicados.
¿Cuándo está completa una evaluación de la API de Seedance?
Está completa cuando el equipo ha medido la calidad, la repetibilidad, la fiabilidad de finalización, el tiempo hasta obtener un resultado utilizable, el manejo de seguridad y el costo por clip aceptado frente a umbrales acordados antes de la prueba.
