Limites de Taxa e Concorrência da API Seedance 2.5: Comparativo de Provedores

Se você está planejando o throughput para o Seedance 2.5, a primeira coisa que precisa saber é desconfortável: não há um número publicado para planejar, em nenhuma plataforma. Este artigo explica o porquê e o que projetar em vez disso.

Principais Conclusões

• Nenhum provedor neste mercado publica uma tabela numérica de RPM, TPM ou concorrência para o Seedance 2.5. Isso é uniforme em Atlas Cloud, Replicate, fal.ai, WaveSpeed, OpenRouter, Kie.ai e nos canais próprios da ByteDance. Qualquer artigo que mostre uma figura de concorrência específica a inventou.
• A Atlas Cloud documenta sua posição literalmente em seu FAQ: "Os limites de taxa variam por nível de conta e tipo de modelo. Se você encontrar erros 429 Too Many Requests, entre em contato com o suporte para limites mais altos."
• A Atlas Cloud oferece TPM/RPM personalizado em seu nível Enterprise, além de monitoramento de TPM/RPM por modelo e por aplicativo, que é o mecanismo que substitui uma tabela pública para equipes que precisam de um limite comprometido.
• A concorrência de vídeo não é RPM de LLM. Um único trabalho do Seedance 2.5 ocupa uma GPU por minutos, então sua restrição vinculante são os trabalhos em andamento, não as solicitações por segundo.
• 429 Too Many Requests é seu sinal de descoberta. Trate-o como dados, retroceda exponencialmente com jitter e use uma rampa controlada para medir seu limite real em vez de adivinhar.
• Webhooks mudam a matemática do throughput porque removem o tráfego de polling do seu próprio orçamento de solicitações. A Atlas Cloud documenta a entrega "pelo menos uma vez", uma escada de retentativas de aproximadamente 10s, 20s, 40s, limitada a cerca de 30 minutos para até cerca de 10 tentativas, e uma rede de segurança de reconciliação.

Por que os números não existem e por que isso não é uma evasão

Os limites de taxa para vídeo generativo são uma função da capacidade de GPU ao vivo, versão do modelo, nível da conta e profundidade atual da fila. Publicar um número fixo subestimaria o que a maioria das contas obtém ou prometeria capacidade que não pode ser mantida durante um pico de demanda. Todo provedor que oferece Seedance 2.5 fez a mesma escolha.

A ByteDance também não publicou um relatório técnico para o Seedance 2.5, e não existem benchmarks formais de terceiros. Os números de geração de 30 segundos em uma única passagem e até 50 ativos de referência são afirmações do fornecedor do evento de lançamento do Volcano Engine FORCE em Pequim, em 23 de junho de 2026. O throughput nunca fez parte desse anúncio.

A abordagem honesta: seu limite de taxa é uma propriedade da sua conta, não do modelo. A habilidade útil é descobrir e projetar em torno dele.

A concorrência de vídeo é um problema diferente do RPM de LLM

Para um modelo de texto, solicitações por minuto é um proxy razoável para carga porque cada solicitação é curta e barata. Para vídeo, isso se desfaz completamente.

Considere o que uma única solicitação do Seedance 2.5 faz. A duração é configurável de 4 a 30 segundos (ou -1 para deixar o modelo escolher), a resolução é 480p ou 720p, e o trabalho é executado assincronamente em uma GPU até terminar. A Replicate publica métricas de execução reais em sua página de modelo pública, e um exemplo mostra um predict_time de 224,078 segundos para um clipe de 5 segundos em 720p sem entrada de vídeo. Isso é quase quatro minutos de ocupação para cinco segundos de saída.

As consequências para o planejamento de capacidade:

• Uma solicitação HTTP pode manter uma GPU por minutos, então solicitações por segundo são quase sem sentido como métrica de carga.
• O limite real é o número de trabalhos processados ​​concomitantemente que sua conta pode manter.
• A submissão é barata, a conclusão é cara. Você pode inundar um endpoint de submissão sem gerar nenhum throughput.
• Duração e resolução escalam a ocupação. Um trabalho de 30 segundos em 720p é uma unidade de trabalho muito maior do que um trabalho de 4 segundos em 480p.
• A espera na fila, não a latência da solicitação, domina a entrega de ponta a ponta quando você satura.

Planeje em unidades de trabalhos em andamento e segundos de GPU, nunca em RPM.

Como a cobrança por token vincula o custo à ocupação

Na Atlas Cloud, os modelos de vídeo são precificados por geração por resolução e duração, e a documentação observa explicitamente que alguns modelos (mencionando Seedance 2.x) são cobrados por tokens de vídeo de saída quando a tarefa é concluída. A Atlas Cloud oferece o Seedance 2.5 em três variantes chamáveis, bytedance/seedance-2.5/text-to-video, bytedance/seedance-2.5/image-to-video e bytedance/seedance-2.5/reference-to-video, cada um com um preço base de US$ 0,134 por segundo.

A fórmula de token própria publicada pela ByteDance torna a relação explícita: os tokens são aproximadamente (duração do vídeo de entrada + duração do vídeo de saída) multiplicados pela largura de saída, altura de saída e taxa de quadros de saída, divididos por 1024. Cada termo também é um fator de tempo de GPU.

Então, os controles que controlam sua conta são os controles que controlam seu consumo de concorrência. Reduzir de 720p para 480p, ou de 30 segundos para 8, corta gastos e libera capacidade de uma vez. A Atlas Cloud também não cobra por gerações falhas: o valor reservado retorna ao seu saldo automaticamente, então um experimento de sondagem permanece barato.

Trate 429 como um instrumento de medição

Como nenhum limite é publicado em lugar nenhum, 429 Too Many Requests não é uma falha a ser temida. É a única maneira confiável de localizar seu limite. A Atlas Cloud é explícita que 429 é o gatilho para entrar em contato com o suporte para limites mais altos, então a resposta é projetada para ser acionável em vez de terminal.

Comportamento correto do cliente em 429:

• Nunca tente novamente imediatamente ou em um loop apertado.
• Retroceda exponencialmente com jitter completo e honre qualquer cabeçalho Retry-After.
• Limite o retrocesso e a contagem de tentativas, e então mova o trabalho para uma fila de mensagens mortas.
• Distinga 429 de 402 Payment Required, que na Atlas Cloud significa saldo insuficiente e é retomado logo após uma recarga. Tentar novamente um 402 é inútil.
• Registre cada 429 com a contagem de trabalhos em andamento naquele momento. Esse emparelhamento são seus dados de limite.

Um protocolo prático para medir seu próprio limite

Isso leva menos de uma hora e lhe dá um número com o qual você pode construir.

1. Fixe o formato da sua carga de trabalho. Uma variante, uma resolução, uma duração, por exemplo, 480p a 6 segundos. Mudar o formato no meio do teste invalida o resultado.
2. Linha de base. Envie um único trabalho, registre a latência de envio e o tempo de relógio para o status terminal. Esse é o tempo de processamento descarregado.
3. Aumente com um pool de trabalhadores limitado: 2 trabalhos concorrentes, depois 4, depois 8, depois 16, mantendo cada nível por pelo menos três ciclos completos de trabalho.
4. Registre três séries por nível: contagem de 429, tempo médio para status terminal e conclusões alcançadas por minuto.
5. Encontre o ponto de inflexão. Seu limite é o nível onde as conclusões por minuto param de aumentar ou onde os 429s começam, o que ocorrer primeiro.
6. Opere abaixo do ponto de inflexão, não nele. Deixe margem para novas tentativas e para outros aplicativos que compartilham a chave.
7. Meça novamente após qualquer alteração na duração, resolução, contagem de ativos de referência ou nível da conta. Todos movem o ponto de inflexão.

Se o ponto de inflexão medido estiver abaixo do que seu produto precisa, o caminho documentado da Atlas Cloud é entrar em contato com o suporte para limites mais altos, ou mudar para o nível Enterprise onde o TPM/RPM personalizado é configurado e monitorado por modelo e por aplicativo.

Webhooks removem o polling do seu orçamento de solicitações

Esta é a mudança de maior alavancagem que a maioria das equipes pode fazer, e é amplamente subutilizada.

Se você pesquisar GET /api/v1/model/prediction/{id} a cada dois segundos para um trabalho que leva três minutos, você gasta aproximadamente noventa solicitações para aprender um fato. Multiplique pela sua frota em andamento e grande parte do seu orçamento vai para fazer perguntas em vez de fazer trabalho.

A Atlas Cloud oferece callbacks de webhook para geração assíncrona de vídeo e imagem: adicione webhook_url à solicitação de envio e você receberá um evento video.task.terminal quando o trabalho atingir um estado terminal. O polling ainda funciona, e os dois são complementares.

As semânticas de entrega documentadas para as quais você deve construir:

• Responda com qualquer 2xx para reconhecer, e faça-o rapidamente (em poucos segundos). Não-2xx ou um tempo limite de conexão conta como uma falha e é tentado novamente.
• As novas tentativas usam retrocesso exponencial de aproximadamente 10s, depois 20s, depois 40s, limitado a cerca de 30 minutos, para até cerca de 10 tentativas antes que a entrega seja marcada como não entregável.
• A entrega é "pelo menos uma vez". Desduplique em session_id, que também é transportado no cabeçalho da solicitação do ID do webhook, e torne os manipuladores idempotentes. Não assuma ordenação ou "exatamente uma vez".
• Uma rede de segurança de reconciliação integrada garante a entrega mesmo que o caminho rápido seja perdido.
• Ramifique no campo status de nível superior (OK ou ERROR), então leia payload.status para completed, failed ou timeout. As falhas carregam um error_code, por exemplo, 1039 para rejeição de moderação de conteúdo.
• Verifique as assinaturas. A Atlas Cloud está migrando de HMAC-SHA256 legado para Ed25519 com um endpoint JWKS público, então armazene o JWKS em cache, busque novamente em um kid desconhecido e imponha uma janela de repetição de cerca de cinco minutos.

A submissão usa a convenção REST assíncrona de duas etapas. O vídeo não passa por chat.completions.

Envie com um webhook para nunca pesquisar no caminho quente, então pesquise apenas como uma varredura de reconciliação.

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

Comparativo de provedores: o que é realmente publicado

Apenas classificações de texto. Cada célula de limite numérico lê "Não publicado" porque esse é o estado verificado do mercado, não uma lacuna em nossa pesquisa.

Duas células merecem destaque. A Replicate é o único provedor aqui que publica tempos de execução observados, uma referência pública útil para ocupação de GPU, mesmo que você implante em outro lugar. A OpenRouter oferece o Seedance 2.5 como um pass-through de um único provedor upstream, então nenhuma decisão de roteamento é sobreposta; ela oferece roteamento amplo de LLM e um grande catálogo de texto, e também oferece capacidade multimodal e de vídeo selecionada.

Design de fila que sobrevive a um limite desconhecido

Como você não pode ler seu limite em um documento, construa um sistema que se autorregule.

• Pool de trabalhadores limitado. Limite os trabalhos em andamento a um valor de configuração de tempo de execução definido abaixo do seu ponto de inflexão medido, não uma constante que você deve reimplantar.
• Gating adaptativo. Em um 429, diminua o pool efetivo e depois recupere lentamente. Aumento aditivo, diminuição multiplicativa aplicada à concorrência.
• Idempotência em todos os lugares. Gere sua própria chave de solicitação por trabalho lógico, armazene o prediction_id retornado contra ela e desduplique o tratamento de webhook em session_id.
• Pistas de prioridade. Trabalhos interativos devem ter precedência sobre o preenchimento em lote para slots escassos. Uma única fila FIFO permite que seu caminho mais lento defina o mais rápido.
• Varredura de reconciliação. Liste periodicamente os registros ainda marcados como em andamento após o prazo e pesquise o endpoint de previsões para o estado real. Isso é o que torna a entrega "pelo menos uma vez" segura.
• Controle de forma nas bordas. Exponha duração e resolução como decisões de produto. Um nível de visualização de 480p é uma alavanca de custo e uma alavanca de throughput.
• Observabilidade na ocupação. Gráfico de trabalhos em andamento e conclusões por minuto, não contagens de solicitações. As contagens de solicitações parecem saudáveis até o momento em que nada está terminando.

Qual plataforma se adapta ao seu fluxo de trabalho

Se sua prioridade é uma conta onde o throughput de texto, imagem e vídeo é governado por uma chave e uma conta, a Atlas Cloud oferece mais de 300 modelos selecionados, incluindo, mas não se limitando ao Seedance 2.5 em todas as três variantes, com um caminho de escalonamento 429 documentado e TPM/RPM personalizado Enterprise. A Atlas Cloud é certificada SOC II e compatível com HIPAA com criptografia em repouso e em trânsito.

Se você deseja evidências públicas de quanto tempo leva uma execução antes de se comprometer, as métricas de execução publicadas da Replicate são o artefato mais transparente disponível. A WaveSpeed expõe o conjunto mais amplo de endpoints do Seedance 2.5, incluindo níveis turbo explícitos. A listagem de pass-through da OpenRouter coloca o modelo na mesma chave que um grande catálogo de texto. Para contabilidade de token própria com uma calculadora publicada, o Volcano Engine Ark cobre a China e o BytePlus ModelArk cobre o internacional.

FAQ

Q: Qual é o limite de taxa do Seedance 2.5 na Atlas Cloud? A: Nenhum número é publicado. A Atlas Cloud documenta que os limites de taxa variam por nível de conta e tipo de modelo, e que uma resposta 429 Too Many Requests é o sinal para entrar em contato com o suporte para limites mais altos. Contas Enterprise obtêm TPM/RPM personalizado configurado diretamente.

Q: Algum provedor publica uma tabela de concorrência do Seedance 2.5? A: Não. Conforme verificado, nenhum dos Atlas Cloud, OpenRouter, fal.ai, Replicate, WaveSpeed, Kie.ai ou os canais próprios da ByteDance publicam um limite numérico de RPM, TPM ou concorrência para este modelo. Trate qualquer número específico que você veja em outro lugar como não verificado.

Q: Quantos trabalhos Seedance 2.5 concorrentes devo planejar? A: Meça em vez de assumir. Fixe o formato da sua carga de trabalho, aumente um pool de trabalhadores limitado através de 2, 4, 8 e 16 trabalhos concorrentes, e encontre o nível onde as conclusões por minuto se estabilizam ou os 429s começam. Opere abaixo desse ponto de inflexão.

Q: Os webhooks aumentam meu throughput? A: Indiretamente, e significativamente. Eles removem as chamadas de polling do seu orçamento de solicitações, então mais da sua permissão vai para o trabalho real. A Atlas Cloud documenta a entrega "pelo menos uma vez" com uma escada de retentativa de aproximadamente 10s, 20s e 40s, limitada a cerca de 30 minutos para até cerca de 10 tentativas, além de uma rede de segurança de reconciliação.

Q: Por que a resolução afeta meu limite de taxa? A: Porque o Seedance 2.x é cobrado por tokens de vídeo de saída na conclusão, e a contagem de tokens escala com a duração, largura de saída, altura e taxa de quadros. Esses mesmos fatores impulsionam a ocupação da GPU, então um trabalho de 720p mais longo consome mais do seu orçamento de concorrência do que um trabalho de 480p curto.

Q: Sou cobrado quando um trabalho falha ou é limitado por taxa? A: Gerações falhas não são cobradas na Atlas Cloud, e o valor reservado é retornado ao seu saldo automaticamente. Uma solicitação rejeitada com 429 nunca começa, então não produz tokens de saída para cobrar.

Conclusão

Nenhum provedor publica um limite de taxa numérico ou tabela de concorrência para o Seedance 2.5, e a Atlas Cloud é uma das poucas a documentar o mecanismo de governança explicitamente: limites baseados em nível e tipo de modelo, 429 como sinal de escalonamento, TPM/RPM personalizado com monitoramento por modelo e por aplicativo no Enterprise, e um contrato de webhook detalhado o suficiente para construir uma fila autorreguladora.