Una evaluación de la API de Seedance debe responder a una pregunta de producto, no solo producir un clip demo 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 29 de julio de 2026, Flatkey enumera seedance-2.5 como una ruta de acceso anticipado de ByteDance para generación de texto a video e imagen a video con salida en 1080p. 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 consulta 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 líderes de ingeniería un conjunto de pruebas repetible, una tarjeta de puntuación ponderada, una métrica de costo 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 consistencia de referencia que requiere tu producto?
- Repetibilidad: ¿La misma familia de prompts produce resultados utilizables en múltiples ejecuciones?
- Ajuste al flujo de trabajo: ¿Puede tu aplicación manejar con limpieza tareas asincrónicas, sondeo, tiempos de espera, almacenamiento e পুনtries?
- Ajuste a la experiencia de usuario: ¿Puedes establecer expectativas honestas sobre espera, progreso, regeneración y fallos?
- Ajuste de seguridad: ¿Puede tu producto impedir entradas no permitidas y revisar salidas antes de su distribución?
- Ajuste a la economía por unidad: ¿Cuánto cuesta un clip aceptado una vez incluidos los trabajos fallidos y las salidas rechazadas?
No apruebes a un proveedor basándote en una sola generación seleccionada a conveniencia. Una evaluación de la API de Seedance útil usa un conjunto fijo de prompts, ejecuciones repetidas, puntuación a ciegas 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 describe una ruta de acceso anticipado con entrada de prompt, una imagen opcional y una URL MP4 como salida completada. 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 anochecer"
}
],
"resolution": "1080p",
"duration": 5
}'
Luego consulta 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 y los términos comerciales pueden cambiar durante el acceso anticipado.
Si tu equipo aún no ha verificado su clave y su URL base, completa primero el quickstart 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 los resultados. De lo contrario, las partes interesadas tienden a premiar el clip que parece más cinematográfico y a cambiar discretamente sus معیارios entre ejecuciones.
Anota estos campos:
| Field | Product-team decision |
|---|---|
| Target workflow | Social creative, product motion, storyboarding, game concept, ad variation, or another defined job |
| Input mode | Text-to-video, image-to-video, or both |
| Output requirement | Duration, resolution, aspect ratio, framing, and delivery format |
| Required motion | Camera movement, object movement, character movement, or mostly static composition |
| Reference requirement | None, loose style reference, or strict subject/product consistency |
| Acceptable wait | Maximum time before the user should see a result or a clear failure state |
| Safety boundary | Disallowed prompts, restricted subjects, review steps, and publication rules |
| Acceptance owner | The role that makes the final usable/not-usable decision |
| Budget unit | Cost per generated second, completed task, accepted clip, or published asset |
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 la forma del producto cambió. Una sola puntuación de calidad universal no puede representar todos los casos de uso.
Construye un conjunto de prueba de 24 prompts para la API de Seedance
Un conjunto de prueba práctico es lo bastante grande como para revelar patrones de fallo, pero lo bastante pequeño como para repetirlo cuando cambie una ruta, una plantilla de prompt o un modelo. Empieza con 24 prompts distribuidos en seis grupos.
| Prompt group | Prompts | What it tests |
|---|---|---|
| Simple subject motion | 4 | Basic motion, object integrity, and clean backgrounds |
| Camera and composition | 4 | Pan, tracking, close-up, wide shot, and framing adherence |
| Multi-element interaction | 4 | Spatial relationships, collisions, occlusion, and temporal consistency |
| Product or brand-like objects | 4 | Shape stability, material appearance, and reference sensitivity |
| Stylized creative scenes | 4 | Art direction, lighting, atmosphere, and prompt interpretation |
| Deliberate edge cases | 4 | Dense instructions, unusual motion, ambiguous prompts, and safety boundaries |
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 confiar en ese comportamiento.
Mantén los prompts independientes del proveedor. Evita la sintaxis de prompts que solo entiende un modelo, a menos que esa función en sí sea 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 de los revisores para cada ejecución.
La investigación pública de Seedance de ByteDance destaca dimensiones como el seguimiento de instrucciones, la calidad del movimiento, la consistencia temporal, la narrativa de múltiples planos 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 hoja de evaluación ponderada de la API de Seedance
La siguiente hoja de evaluació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, fondos e identidades visuales permanecen coherentes a lo largo del tiempo? |
| Composición y calidad visual | 10 | ¿El encuadre, la iluminación, el detalle y la presentación general son utilizables? |
| Consistencia con la referencia | 10 | Cuando se proporciona una imagen, ¿el resultado conserva el sujeto o las características del producto requeridas? |
| Tiempo hasta un resultado utilizable | 10 | ¿La espera total, incluidos los reintentos, se ajusta a la experiencia de usuario? |
| Fiabilidad 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 las solicitudes y salidas no seguras o inapropiadas antes de la publicación? |
| Coste por clip aceptado | 5 | ¿Es sostenible el coste real después de contar las salidas rechazadas? |
Califica cada dimensión de calidad de 1 a 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 justa de la API de Seedance, 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 coste por clip aceptado, no el coste por generación
La métrica de coste más útil para la generación de video es:
coste por clip aceptado = gasto total de generación / clips aceptados
Si 30 tareas cuestan $60 y solo 12 resultados pasan la revisión, el coste efectivo es de $5 por clip aceptado, no de $2 por generación.
También haz seguimiento de:
tasa de aceptación = clips aceptados / clips completados
tasa de finalización = clips completados / tareas enviadas
coste 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 cara 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 como acceso anticipado basado en uso. Utiliza el directorio de modelos y la página de precios en vivo para obtener información comercial actualizada, 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 solo adaptador
Tu producto no debería exponer estados de tareas específicos del proveedor en todo el 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 debe conservar el ID de la tarea del proveedor, el estado terminal sin procesar, los parámetros de la solicitud y los datos de uso para depuración. El resto del producto debe 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 independiente 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 síncrono 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 fiable.
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 retrocedió.
Revisión del resultado
Guarda el prompt y los parámetros junto al clip. Proporciona un estado de revisión interno antes de que un recurso generado pueda pasar a un flujo público o orientado al cliente.
Lenguaje de fallo
Traduce los fallos del proveedor en mensajes de producto accionables: entrada no compatible, rechazo por seguridad, capacidad temporal, recurso caducado o error de servicio recuperable. Conserva el código bruto 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 su latencia y su comportamiento ante fallos no pueden comunicarse con claridad.
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 de medio de entrada, el tamaño y el origen;
- 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 para el equipo de producto
Día 1: fija el contrato
Elige el flujo de trabajo, el responsable de aceptación, 24 prompts, los parámetros, los pesos de puntuación y el presupuesto máximo. Verifica el acceso actual en la página del modelo Seedance 2.5.
Día 2: implementa el adaptador
Crea tareas, conserva los IDs de tarea, consulta el estado 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, incluidas las fallas y las salidas que los revisores rechazan de inmediato.
Día 4: puntúa sin sesgos
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 coste por clip aceptado.
Día 5: decide y documenta
Aprobar uno de cuatro resultados:
- Pasar a beta limitada para el flujo de trabajo probado.
- Avanzar con restricciones en los tipos de prompts, la duración, las entradas de referencia o los 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 fin.
Ejemplos de umbrales de decisión de avanzar o no
Establece 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 |
| Fallos críticos de seguridad | Cero |
| Coste por clip aceptado | Dentro del presupuesto aprobado del flujo de trabajo |
| Fallos por ruptura de referencias | Por debajo del límite específico del caso de uso |
Estos son ejemplos, no referencias universales. Una herramienta de storyboard puede tolerar una fidelidad menor que un flujo automatizado de anuncios de producto. El valor proviene de precomprometerse con umbrales medibles.
¿Qué hace que esta evaluación sea reutilizable?
Versione juntos el conjunto de prompts, la tarjeta de puntuación, el adaptador y el conjunto de datos de resultados. Cuando cambie el acceso o esté disponible una nueva ruta de Seedance, vuelva a ejecutar el mismo paquete.
Conserve estos artefactos:
- versión del conjunto de prompts;
- versión del esquema de solicitud;
- modelo e ID de ruta;
- parámetros de generación;
- marcas de tiempo sin procesar del ciclo de vida de la tarea;
- IDs de los revisores y puntuaciones a 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 seguir/no seguir.
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 su producto compara modelos de video, imagen, audio y lenguaje detrás de una sola capa de acceso.
Recomendación final
Use la API de Seedance cuando cumpla el contrato de aceptación de su flujo de trabajo, no porque un clip generado se vea impresionante. Verifique la ruta actual, pruebe un conjunto fijo de prompts, puntúe las salidas a ciegas, incluya los fallos en la economía unitaria y mantenga el ciclo de vida asíncrono detrás de un adaptador.
Para los usuarios de Flatkey, la secuencia práctica es:
- verifique la clave y el enrutador con el inicio rápido de la API de Seedance;
- confirme el acceso actual a
seedance-2.5y los campos de solicitud en la página del modelo en vivo; - ejecute la tarjeta de puntuación de esta guía;
- complete la lista de verificación de producción antes de la implementación para clientes.
Una evaluación de la API de Seedance disciplinada ofrece a los equipos de producto, ingeniería, creatividad, seguridad y finanzas una sola respuesta compartida: si la ruta puede producir de forma fiable video aceptable para el flujo de trabajo que realmente planea 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 sondea 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ínela 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 distribuidos en seis grupos de comportamiento es un punto de partida práctico. Ejecute cada prompt varias veces cuando el presupuesto lo permita para que la evaluación mida la repetibilidad y no la posibilidad.
¿Los revisores deberían saber qué modelo produjo cada clip?
No, no cuando se comparan proveedores o versiones de modelos. La revisión a ciegas 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's actualmente enumera seedance-2.5 para texto a video e imagen a video con una entrada de imagen opcional. Confirme la ruta y los campos actuales antes de implementar, porque está marcado como acceso anticipado.
¿Debería un producto reintentar automáticamente una solicitud de video que agotó el tiempo de espera?
No creando una nueva tarea de inmediato. Primero verifique el ID de la tarea existente. Un tiempo de espera del cliente no demuestra que la tarea del proveedor haya fallado, y una reenvío automático puede crear trabajo duplicado y gasto.
¿Cuándo se completa una evaluación de la API de Seedance?
Se completa cuando el equipo ha medido la calidad, la repetibilidad, la fiabilidad de finalización, el tiempo hasta obtener una salida utilizable, el manejo de seguridad y el costo por clip aceptado frente a los umbrales acordados antes de las pruebas.



