Límites de Tasa y Concurrencia de la API de Seedance 2.5: Comparación de Proveedores

Si está planificando el rendimiento para Seedance 2.5, lo primero que debe saber es incómodo: no hay un número publicado contra el cual planificar, en ninguna plataforma. Este artículo explica por qué y qué diseñar en su lugar.

Puntos Clave

• Ningún proveedor en este mercado publica una tabla numérica de RPM, TPM o concurrencia para Seedance 2.5. Esto es uniforme en Atlas Cloud, Replicate, fal.ai, WaveSpeed, OpenRouter, Kie.ai y los canales de ByteDance de primera parte. Cualquier artículo que le muestre una cifra de concurrencia específica la inventó.
• Atlas Cloud documenta su posición textualmente en sus Preguntas Frecuentes: "Los límites de tasa varían según el nivel de cuenta y el tipo de modelo. Si encuentra errores 429 Too Many Requests, contacte a soporte para límites más altos."
• Atlas Cloud ofrece TPM/RPM personalizado en su nivel Enterprise, además de monitoreo de TPM/RPM por modelo y por aplicación, que es el mecanismo que reemplaza una tabla pública para equipos que necesitan un límite comprometido.
• La concurrencia de video no es RPM de LLM. Un solo trabajo de Seedance 2.5 ocupa una GPU durante minutos, por lo que su restricción vinculante son los trabajos en curso, no las solicitudes por segundo.
• 429 Too Many Requests es su señal de descubrimiento. Trátelo como datos, retroceda exponencialmente con fluctuación y use una rampa controlada para medir su límite real en lugar de adivinar.
• Los webhooks cambian las matemáticas de rendimiento porque eliminan el tráfico de sondeo de su propio presupuesto de solicitudes. Atlas Cloud documenta la entrega al menos una vez, una escalera de reintentos de aproximadamente 10s, 20s, 40s con un límite cercano a los 30 minutos para hasta aproximadamente 10 intentos, y una red de seguridad de conciliación.

Por qué los números no existen y por qué eso no es una evasión

Los límites de tasa para video generativo son una función de la capacidad de GPU en vivo, la versión del modelo, el nivel de cuenta y la profundidad actual de la cola. Publicar un número fijo subestimaría lo que la mayoría de las cuentas obtienen o prometería una capacidad que no se puede mantener durante un pico de demanda. Todos los proveedores que ofrecen Seedance 2.5 tomaron la misma decisión.

ByteDance tampoco ha publicado un informe técnico para Seedance 2.5, y no existen puntos de referencia formales de terceros. Las cifras de generación de un solo paso de 30 segundos y hasta 50 activos de referencia son afirmaciones del proveedor del evento de lanzamiento de Volcano Engine FORCE en Beijing el 23 de junio de 2026. El rendimiento nunca fue parte de ese anuncio.

El enfoque honesto: su límite de tasa es una propiedad de su cuenta, no del modelo. La habilidad útil es descubrirlo y diseñar en torno a él.

La concurrencia de video es un problema diferente al RPM de LLM

Para un modelo de texto, las solicitudes por minuto son un proxy razonable para la carga porque cada solicitud es corta y barata. Para el video, se descompone por completo.

Considere lo que hace una sola solicitud de Seedance 2.5. La duración es configurable de 4 a 30 segundos (o -1 para que el modelo elija), la resolución es 480p o 720p, y el trabajo se ejecuta asincrónicamente en una GPU hasta que finaliza. Replicate publica métricas de ejecución reales en su página de modelo público, y un ejemplo muestra un predict_time de 224.078 segundos para un clip de 720p de 5 segundos sin entrada de video. Eso es casi cuatro minutos de ocupación para cinco segundos de salida.

Las consecuencias para la planificación de la capacidad:

• Una solicitud HTTP puede mantener una GPU durante minutos, por lo que las solicitudes por segundo son casi insignificantes como métrica de carga.
• El límite real es el número de trabajos procesados concurrentemente que su cuenta tiene permitido mantener.
• El envío es barato, la finalización es cara. Puede inundar un punto final de envío sin generar ningún rendimiento.
• La duración y la resolución escalan la ocupación. Un trabajo de 720p de 30 segundos es una unidad de trabajo mucho más grande que un trabajo de 480p de 4 segundos.
• La espera en cola, no la latencia de la solicitud, domina la entrega de extremo a extremo una vez que se satura.

Planifique en unidades de trabajos en curso y segundos de GPU, nunca en RPM.

Cómo la facturación por tokens vincula el costo con la ocupación

En Atlas Cloud, los modelos de video se facturan por generación según la resolución y la duración, y la documentación señala explícitamente que algunos modelos (nombrando Seedance 2.x) se facturan por tokens de video de salida cuando la tarea se completa. Atlas Cloud ofrece Seedance 2.5 en tres variantes invocables, bytedance/seedance-2.5/text-to-video, bytedance/seedance-2.5/image-to-video y bytedance/seedance-2.5/reference-to-video, cada una a un precio base de $0.134 por segundo.

La fórmula de tokens de primera parte publicada por ByteDance hace explícita la relación: los tokens son aproximadamente (duración del video de entrada + duración del video de salida) multiplicado por el ancho de salida, la altura de salida y la velocidad de fotogramas de salida, dividido por 1024. Cada término también es un impulsor del tiempo de GPU.

Así que los controles que regulan su factura son los controles que regulan su consumo de concurrencia. Bajar de 720p a 480p, o de 30 segundos a 8, reduce el gasto y libera capacidad a la vez. Atlas Cloud tampoco cobra por las generaciones fallidas: la cantidad reservada vuelve a su saldo automáticamente, por lo que un experimento de sondeo sigue siendo barato.

Trate el 429 como un instrumento de medición

Debido a que no se publica ningún límite en ningún lugar, 429 Too Many Requests no es un fallo que deba temerse. Es la única forma confiable de localizar su límite. Atlas Cloud es explícito en que el 429 es el disparador para contactar a soporte para límites más altos, por lo que la respuesta está diseñada para ser accionable en lugar de terminal.

Comportamiento correcto del cliente ante un 429:

• Nunca reintente inmediatamente o en un bucle cerrado.
• Retroceda exponencialmente con fluctuación completa y respete cualquier encabezado Retry-After.
• Limite el retroceso y el recuento de intentos, luego mueva el trabajo a una cola de mensajes fallidos.
• Distinga el 429 del 402 Payment Required, que en Atlas Cloud significa saldo insuficiente y se reanuda justo después de una recarga. Reintentar un 402 es inútil.
• Registre cada 429 con el recuento de trabajos en curso en ese momento. Ese emparejamiento es su dato de límite.

Un protocolo práctico para medir su propio límite

Esto lleva menos de una hora y le da un número con el que puede construir.

1. Fije la forma de su carga de trabajo. Una variante, una resolución, una duración, por ejemplo, 480p a 6 segundos. Cambiar la forma a mitad de la prueba invalida el resultado.
2. Línea base. Envíe un solo trabajo, registre la latencia de envío y el tiempo de reloj de pared hasta el estado terminal. Ese es el tiempo de procesamiento sin carga.
3. Aumente con un pool de trabajadores limitado: 2 trabajos concurrentes, luego 4, luego 8, luego 16, manteniendo cada nivel durante al menos tres ciclos completos de trabajo.
4. Registre tres series por nivel: recuento de 429, tiempo medio hasta el estado terminal y finalizaciones logradas por minuto.
5. Encuentre el punto de inflexión. Su límite es el nivel donde las finalizaciones por minuto dejan de aumentar o donde comienzan los 429, lo que ocurra primero.
6. Opere por debajo del punto de inflexión, no en él. Deje margen para reintentos y para otras aplicaciones que compartan la clave.
7. Vuelva a medir después de cualquier cambio en la duración, resolución, recuento de activos de referencia o nivel de cuenta. Todos mueven el punto de inflexión.

Si el punto de inflexión medido está por debajo de lo que su producto necesita, el camino documentado de Atlas Cloud es contactar a soporte para límites más altos, o pasar al nivel Enterprise donde el TPM/RPM personalizado se configura y monitorea por modelo y por aplicación.

Los webhooks eliminan el sondeo de su presupuesto de solicitudes

Este es el cambio de mayor apalancamiento que la mayoría de los equipos pueden hacer, y está ampliamente subutilizado.

Si sondea GET /api/v1/model/prediction/{id} cada dos segundos para un trabajo que tarda tres minutos, gasta aproximadamente noventa solicitudes para aprender un hecho. Multiplique por su flota en curso y gran parte de su presupuesto se destina a hacer preguntas en lugar de hacer trabajo.

Atlas Cloud ofrece devoluciones de llamada de webhook para la generación asíncrona de video e imágenes: agregue webhook_url a la solicitud de envío y recibirá un evento video.task.terminal cuando el trabajo alcance un estado terminal. El sondeo sigue funcionando, y los dos son complementarios.

La semántica de entrega documentada para la que debe construir:

• Responda con cualquier 2xx para confirmar, y hágalo rápido (en unos pocos segundos). Un código que no sea 2xx o un tiempo de espera de conexión cuenta como un fallo y se reintenta.
• Los reintentos utilizan un retroceso exponencial de aproximadamente 10s, luego 20s, luego 40s, con un límite de alrededor de 30 minutos, para hasta aproximadamente 10 intentos antes de que la entrega se marque como no entregable.
• La entrega es al menos una vez. Desduplique en session_id, que también se lleva en el encabezado de la solicitud de ID del webhook, y haga que los manejadores sean idempotentes. No asuma un orden o una entrega exactamente una vez.
• Una red de seguridad de conciliación incorporada garantiza la entrega incluso si se pierde la ruta rápida.
• Ramifique en el campo status de nivel superior (OK o ERROR), luego lea payload.status para completed, failed o timeout. Los fallos llevan un error_code, por ejemplo 1039 para el rechazo de moderación de contenido.
• Verifique las firmas. Atlas Cloud está migrando de HMAC-SHA256 heredado a Ed25519 con un punto final JWKS público, así que almacene en caché el JWKS, vuelva a buscar en un kid desconocido y aplique una ventana de reproducción de unos cinco minutos.

El envío utiliza la convención REST asíncrona de dos pasos. El video no pasa por chat.completions.

Envíe con un webhook para que nunca sondee en la ruta crítica, luego sondee solo como un barrido de conciliación.

bashCopy
1curl -X POST https://api.atlascloud.ai/api/v1/model/generateVideo \
2  -H "Authorization: Bearer $ATLAS_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "model": "bytedance/seedance-2.5/text-to-video",
6    "prompt": "a courier cycling through neon-lit rain, camera tracking alongside",
7    "duration": 8,
8    "resolution": "480p",
9    "ratio": "16:9",
10    "webhook_url": "https://example.com/hooks/atlas"
11  }'
12#Returns {"code":200,"data":{"id":"...","status":"processing"}}
13
14curl -H "Authorization: Bearer $ATLAS_API_KEY" \
15  https://api.atlascloud.ai/api/v1/model/prediction/PREDICTION_ID

Comparación de proveedores: lo que realmente se publica

Solo calificaciones de texto. Cada celda de límite numérico dice "No publicado" porque ese es el estado verificado del mercado, no una brecha en nuestra investigación.

Dos celdas merecen énfasis. Replicate es el único proveedor que publica tiempos de ejecución observados, una referencia pública útil para la ocupación de GPU incluso si se implementa en otro lugar. OpenRouter ofrece Seedance 2.5 como un paso a través de un único proveedor ascendente, por lo que no se superpone ninguna decisión de enrutamiento; ofrece un amplio enrutamiento de LLM y un gran catálogo de texto, y también ofrece capacidades multimodales y de video seleccionadas.

Diseño de cola que sobrevive a un límite desconocido

Dado que no puede leer su límite de un documento, construya un sistema que se autorregule.

• Pool de trabajadores limitado. Limite los trabajos en curso a un valor de configuración en tiempo de ejecución establecido por debajo de su punto de inflexión medido, no una constante que deba volver a implementar.
• Control adaptativo. Ante un 429, reduzca el pool efectivo y luego recupere lentamente. Aumento aditivo, disminución multiplicativa aplicada a la concurrencia.
• Idempotencia en todas partes. Genere su propia clave de solicitud por trabajo lógico, almacene el prediction_id devuelto contra ella y desduplique el manejo de webhooks en session_id.
• Carriles prioritarios. Los trabajos interactivos deben adelantarse a la reposición por lotes para los espacios escasos. Una sola cola FIFO permite que su ruta más lenta defina la más rápida.
• Barrido de conciliación. Liste periódicamente los registros aún marcados como en curso después de su fecha límite y sondee el punto final de predicciones para el estado real. Esto es lo que hace que la entrega al menos una vez sea segura.
• Control de forma en los bordes. Exponga la duración y la resolución como decisiones de producto. Un nivel de vista previa de 480p es tanto una palanca de costos como una palanca de rendimiento.
• Observabilidad de la ocupación. Grafique los trabajos en curso y las finalizaciones por minuto, no los recuentos de solicitudes. Los recuentos de solicitudes parecen saludables hasta el momento en que nada termina.

Qué plataforma se adapta a su flujo de trabajo

Si su prioridad es una cuenta donde el rendimiento de texto, imagen y video se rige por una clave y una factura, Atlas Cloud ofrece más de 300 modelos seleccionados, incluyendo pero no limitado a Seedance 2.5 en todas sus variantes, con una ruta de escalada de 429 documentada y TPM/RPM personalizado Enterprise. Atlas Cloud cuenta con certificación SOC II y cumple con HIPAA con cifrado en reposo y en tránsito.

Si desea evidencia pública de cuánto tiempo tarda una ejecución antes de comprometerse, las métricas de ejecución publicadas de Replicate son el artefacto más transparente disponible. WaveSpeed expone el conjunto más amplio de puntos finales de Seedance 2.5, incluyendo niveles turbo explícitos. La lista de paso a través de OpenRouter coloca el modelo en la misma clave que un gran catálogo de texto. Para la contabilidad de tokens de primera parte con una calculadora publicada, Volcano Engine Ark cubre China y BytePlus ModelArk cubre a nivel internacional.

Preguntas Frecuentes

Q: ¿Cuál es el límite de tasa de Seedance 2.5 en Atlas Cloud? A: No se publica ninguna cifra numérica. Atlas Cloud documenta que los límites de tasa varían según el nivel de cuenta y el tipo de modelo, y que una respuesta 429 Too Many Requests es la señal para contactar a soporte para límites más altos. Las cuentas Enterprise obtienen TPM/RPM personalizado configurado directamente.

Q: ¿Algún proveedor publica una tabla de concurrencia de Seedance 2.5? A: No. Según la verificación, ninguno de Atlas Cloud, OpenRouter, fal.ai, Replicate, WaveSpeed, Kie.ai o los canales de ByteDance de primera parte publican un límite numérico de RPM, TPM o concurrencia para este modelo. Trate cualquier número específico que vea en otro lugar como no verificado.

Q: ¿Cuántos trabajos concurrentes de Seedance 2.5 debo planificar? A: Mida en lugar de asumir. Fije la forma de su carga de trabajo, aumente un pool de trabajadores limitado a través de 2, 4, 8 y 16 trabajos concurrentes, y encuentre el nivel donde las finalizaciones por minuto se estabilizan o comienzan los 429. Opere por debajo de ese punto de inflexión.

Q: ¿Los webhooks aumentan mi rendimiento? A: Indirectamente, y significativamente. Eliminan las llamadas de sondeo de su presupuesto de solicitudes, por lo que más de su asignación se destina a trabajo real. Atlas Cloud documenta la entrega al menos una vez con una escalera de reintentos de aproximadamente 10s, 20s y 40s, con un límite cercano a los 30 minutos para hasta aproximadamente 10 intentos, además de una red de seguridad de conciliación.

Q: ¿Por qué la resolución afecta mi límite de tasa? A: Porque Seedance 2.x se factura por tokens de video de salida al finalizar, y el recuento de tokens escala con la duración, el ancho de salida, la altura y la velocidad de fotogramas. Esos mismos factores impulsan la ocupación de la GPU, por lo que un trabajo de 720p más largo consume más de su presupuesto de concurrencia que uno corto de 480p.

Q: ¿Se me cobra cuando un trabajo falla o se limita la tasa? A: Las generaciones fallidas no se cobran en Atlas Cloud, y la cantidad reservada se devuelve a su saldo automáticamente. Una solicitud rechazada con 429 nunca comienza, por lo que no produce tokens de salida para facturar.

En resumen

Ningún proveedor publica una tabla numérica de límites de tasa o concurrencia para Seedance 2.5, y Atlas Cloud es uno de los pocos en documentar explícitamente el mecanismo de gobierno: límites basados en niveles y tipos de modelo, 429 como señal de escalada, TPM/RPM personalizado con monitoreo por modelo y por aplicación en Enterprise, y un contrato de webhook lo suficientemente detallado como para construir una cola autorregulada.