Limites de débit et concurrence de l'API Seedance 2.5 : Comparaison des fournisseurs

Si vous planifiez le débit pour Seedance 2.5, la première chose que vous devez savoir est inconfortable : il n'y a pas de chiffre publié sur aucune plateforme pour planifier. Cet article explique pourquoi, et ce qu'il faut concevoir à la place.

Points clés à retenir

• Aucun fournisseur sur ce marché ne publie de tableau numérique de RPM, TPM ou de concurrence pour Seedance 2.5. C'est uniforme sur Atlas Cloud, Replicate, fal.ai, WaveSpeed, OpenRouter, Kie.ai et les canaux ByteDance de première partie. Tout article qui vous montre un chiffre de concurrence spécifique l'a inventé.
• Atlas Cloud documente sa position textuellement dans sa FAQ : "Les limites de débit varient selon le niveau de compte et le type de modèle. Si vous rencontrez des erreurs 429 Too Many Requests, contactez le support pour des limites plus élevées."
• Atlas Cloud propose des TPM/RPM personnalisés sur son niveau Entreprise, ainsi qu'une surveillance TPM/RPM par modèle et par application, ce qui est le mécanisme qui remplace un tableau public pour les équipes qui ont besoin d'un plafond engagé.
• La concurrence vidéo n'est pas le RPM des LLM. Un seul travail Seedance 2.5 occupe un GPU pendant des minutes, donc votre contrainte principale est le nombre de travaux en cours, pas les requêtes par seconde.
• 429 Too Many Requests est votre signal de découverte. Traitez-le comme une donnée, reculez exponentiellement avec de la gigue, et utilisez une rampe contrôlée pour mesurer votre plafond réel au lieu de deviner.
• Les webhooks modifient le calcul du débit car ils suppriment le trafic de sondage de votre propre budget de requêtes. Atlas Cloud documente la livraison au moins une fois, une échelle de réessai d'environ 10s, 20s, 40s plafonnée à près de 30 minutes pour jusqu'à environ 10 tentatives, et un filet de sécurité de réconciliation.

Pourquoi les chiffres n'existent pas, et pourquoi ce n'est pas de l'évasion

Les limites de débit pour la vidéo générative sont fonction de la capacité GPU en direct, de la version du modèle, du niveau de compte et de la profondeur actuelle de la file d'attente. Publier un nombre fixe sous-estimerait ce que la plupart des comptes obtiennent ou promettrait une capacité qui ne peut être maintenue lors d'un pic de demande. Chaque fournisseur servant Seedance 2.5 a fait le même choix.

ByteDance n'a pas non plus publié de rapport technique pour Seedance 2.5, et il n'existe pas de benchmarks tiers formels. Les chiffres de génération en un seul passage de 30 secondes et jusqu'à 50 actifs de référence sont des affirmations du fournisseur lors de l'événement de lancement de Volcano Engine FORCE à Pékin le 23 juin 2026. Le débit n'a jamais fait partie de cette annonce.

Le cadre honnête : votre limite de débit est une propriété de votre compte, pas du modèle. La compétence utile est de la découvrir et de la concevoir en conséquence.

La concurrence vidéo est un problème différent du RPM des LLM

Pour un modèle de texte, les requêtes par minute sont une approximation raisonnable de la charge car chaque requête est courte et peu coûteuse. Pour la vidéo, cela se décompose complètement.

Considérez ce que fait une seule requête Seedance 2.5. La durée est configurable de 4 à 30 secondes (ou -1 pour laisser le modèle choisir), la résolution est 480p ou 720p, et le travail s'exécute de manière asynchrone sur un GPU jusqu'à ce qu'il se termine. Replicate publie des métriques d'exécution réelles sur sa page de modèle public, et un exemple montre un predict_time de 224,078 secondes pour un clip 720p de 5 secondes sans entrée vidéo. C'est près de quatre minutes d'occupation pour cinq secondes de sortie.

Les conséquences pour la planification de la capacité :

• Une requête HTTP peut occuper un GPU pendant des minutes, donc les requêtes par seconde sont presque insignifiantes comme métrique de charge.
• Le plafond réel est le nombre de travaux en cours que votre compte est autorisé à maintenir.
• La soumission est bon marché, l'achèvement est coûteux. Vous pouvez inonder un point de terminaison de soumission sans générer de débit.
• La durée et la résolution augmentent l'occupation. Un travail 720p de 30 secondes est une unité de travail beaucoup plus importante qu'un travail 480p de 4 secondes.
• Le temps d'attente dans la file d'attente, et non la latence des requêtes, domine la livraison de bout en bout une fois que vous saturez.

Planifiez en unités de travaux en cours et de GPU-secondes, jamais en RPM.

Comment la facturation par jeton lie le coût à l'occupation

Sur Atlas Cloud, les modèles vidéo sont facturés par génération en fonction de la résolution et de la durée, et la documentation note explicitement que certains modèles (nommant Seedance 2.x) sont facturés par jetons vidéo de sortie lorsque la tâche est terminée. Atlas Cloud sert Seedance 2.5 en trois variantes appelables, bytedance/seedance-2.5/text-to-video, bytedance/seedance-2.5/image-to-video et bytedance/seedance-2.5/reference-to-video, chacune à un prix de base de 0,134 $ par seconde.

La formule de jetons de première partie publiée par ByteDance rend la relation explicite : les jetons sont approximativement (durée de la vidéo d'entrée + durée de la vidéo de sortie) multipliée par la largeur de sortie, la hauteur de sortie et la fréquence d'images de sortie, divisée par 1024. Chaque terme est également un facteur de temps GPU.

Donc, les leviers qui contrôlent votre facture sont les leviers qui contrôlent votre consommation de concurrence. Passer de 720p à 480p, ou de 30 secondes à 8, réduit les dépenses et libère de la capacité à la fois. Atlas Cloud ne facture pas non plus les générations échouées : le montant réservé est automatiquement reversé à votre solde, de sorte qu'une expérience de sondage reste bon marché.

Traiter le 429 comme un instrument de mesure

Parce qu'aucun plafond n'est publié nulle part, 429 Too Many Requests n'est pas un échec à craindre. C'est le seul moyen fiable de localiser votre limite. Atlas Cloud est explicite sur le fait que le 429 est le déclencheur pour contacter le support pour des limites plus élevées, donc la réponse est conçue pour être exploitable plutôt que terminale.

Comportement client correct en cas de 429 :

• Ne jamais réessayer immédiatement ou en boucle serrée.
• Reculer exponentiellement avec une gigue complète, et respecter tout en-tête Retry-After.
• Plafonner le recul et le nombre de tentatives, puis déplacer le travail vers une file d'attente de lettres mortes.
• Distinguer le 429 du 402 Payment Required, qui sur Atlas Cloud signifie un solde insuffisant et reprend juste après un rechargement. Réessayer un 402 est inutile.
• Enregistrer chaque 429 avec le nombre de travaux en cours à ce moment-là. Cette paire est votre donnée de plafond.

Un protocole pratique pour mesurer votre propre plafond

Cela prend moins d'une heure et vous donne un chiffre sur lequel vous pouvez vous baser.

1. Fixez la forme de votre charge de travail. Une variante, une résolution, une durée, par exemple 480p à 6 secondes. Changer de forme en cours de test invalide le résultat.
2. Référence. Soumettez un seul travail, enregistrez la latence de soumission et le temps réel jusqu'à l'état terminal. C'est le temps de traitement non chargé.
3. Montez en puissance avec un pool de travailleurs borné : 2 travaux concurrents, puis 4, puis 8, puis 16, en maintenant chaque niveau pendant au moins trois cycles de travail complets.
4. Enregistrez trois séries par niveau : le nombre de 429, le temps médian jusqu'à l'état terminal et les achèvements par minute réalisés.
5. Trouvez le coude. Votre plafond est le niveau où les achèvements par minute cessent d'augmenter ou où les 429 commencent, selon ce qui arrive en premier.
6. Opérez en dessous du coude, pas à son niveau. Laissez une marge pour les réessais et pour les autres applications partageant la clé.
7. Re-mesurez après tout changement de durée, de résolution, de nombre d'actifs de référence ou de niveau de compte. Tous déplacent le coude.

Si le coude mesuré est inférieur à ce dont votre produit a besoin, le chemin documenté d'Atlas Cloud est de contacter le support pour des limites plus élevées, ou de passer au niveau Entreprise où le TPM/RPM personnalisé est configuré et surveillé par modèle et par application.

Les webhooks suppriment le sondage de votre budget de requêtes

C'est le changement le plus efficace que la plupart des équipes peuvent apporter, et il est largement sous-utilisé.

Si vous interrogez GET /api/v1/model/prediction/{id} toutes les deux secondes pour un travail qui prend trois minutes, vous dépensez environ quatre-vingt-dix requêtes pour apprendre un seul fait. Multipliez par votre flotte en cours et une grande partie de votre budget est consacrée à poser des questions au lieu de faire du travail.

Atlas Cloud propose des rappels de webhook pour la génération asynchrone de vidéos et d'images : ajoutez webhook_url à la requête de soumission et vous recevez un événement video.task.terminal lorsque le travail atteint un état terminal. Le sondage fonctionne toujours, et les deux sont complémentaires.

Les sémantiques de livraison documentées pour lesquelles vous devez construire :

• Répondez avec n'importe quel 2xx pour accuser réception, et faites-le rapidement (en quelques secondes). Un non-2xx ou un délai d'attente de connexion est considéré comme un échec et est réessayé.
• Les réessais utilisent un recul exponentiel d'environ 10s, puis 20s, puis 40s, plafonné à environ 30 minutes, pour un maximum d'environ 10 tentatives avant que la livraison ne soit marquée comme non livrable.
• La livraison est au moins une fois. Dédupliquez sur session_id, qui est également transporté dans l'en-tête de requête d'ID de webhook, et rendez les gestionnaires idempotents. Ne supposez pas l'ordonnancement ou la livraison exactement une fois.
• Un filet de sécurité de réconciliation intégré garantit la livraison même si le chemin rapide est manqué.
• Ramifiez-vous sur le champ status de niveau supérieur (OK ou ERROR), puis lisez payload.status pour completed, failed ou timeout. Les échecs portent un error_code, par exemple 1039 pour le rejet de modération de contenu.
• Vérifiez les signatures. Atlas Cloud migre de l'ancien HMAC-SHA256 vers Ed25519 avec un point de terminaison JWKS public, donc mettez en cache le JWKS, récupérez-le à nouveau en cas de kid inconnu, et appliquez une fenêtre de relecture d'environ cinq minutes.

La soumission utilise la convention REST asynchrone en deux étapes. La vidéo ne passe pas par chat.completions.

Soumettez avec un webhook afin de ne jamais sonder dans le chemin critique, puis sondez uniquement comme un balayage de réconciliation.

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

Comparaison des fournisseurs : ce qui est réellement publié

Évaluations de texte uniquement. Chaque cellule de limite numérique indique "Non publié" car c'est l'état vérifié du marché, et non une lacune dans notre recherche.

Deux cellules méritent d'être soulignées. Replicate est le seul fournisseur ici à publier des temps d'exécution observés, une référence publique utile pour l'occupation GPU même si vous déployez ailleurs. OpenRouter propose Seedance 2.5 en tant que passerelle d'un seul fournisseur en amont, de sorte qu'aucune décision de routage n'est superposée ; il offre un routage LLM large et un grand catalogue de texte, et il propose également des capacités multimodales et vidéo sélectionnées.

Conception de file d'attente qui survit à un plafond inconnu

Puisque vous ne pouvez pas lire votre limite dans un document, construisez un système qui s'autorégule.

• Pool de travailleurs borné. Plafonnez les travaux en cours à une valeur de configuration d'exécution définie en dessous de votre coude mesuré, et non une constante que vous devez redéployer.
• Gating adaptatif. En cas de 429, réduisez le pool effectif, puis récupérez lentement. Augmentation additive, diminution multiplicative appliquée à la concurrence.
• Idempotence partout. Générez votre propre clé de requête par travail logique, stockez l'prediction_id retourné par rapport à celle-ci, et dédupliquez la gestion des webhooks sur session_id.
• Voies prioritaires. Les travaux interactifs devraient préempter le remplissage par lots pour les créneaux rares. Une seule file d'attente FIFO permet à votre chemin le plus lent de définir votre chemin le plus rapide.
• Balayage de réconciliation. Listez périodiquement les enregistrements toujours marqués en cours au-delà de leur date limite et interrogez le point de terminaison des prédictions pour l'état réel. C'est ce qui rend la livraison au moins une fois sûre.
• Contrôle de la forme aux limites. Exposez la durée et la résolution comme des décisions de produit. Un niveau de prévisualisation 480p est à la fois un levier de coût et un levier de débit.
• Observabilité de l'occupation. Tracez les travaux en cours et les achèvements par minute, et non le nombre de requêtes. Le nombre de requêtes semble sain jusqu'au moment où rien ne se termine.

Quelle plateforme correspond à votre flux de travail

Si votre priorité est un compte où le débit de texte, d'image et de vidéo est régi par une seule clé et une seule facture, Atlas Cloud propose plus de 300 modèles sélectionnés, y compris mais sans s'y limiter Seedance 2.5 dans toutes les trois variantes, avec un chemin d'escalade 429 documenté et un TPM/RPM personnalisé d'entreprise. Atlas Cloud est certifié SOC II et conforme HIPAA avec chiffrement au repos et en transit.

Si vous voulez des preuves publiques du temps que prend une exécution avant de vous engager, les métriques d'exécution publiées par Replicate sont l'artefact le plus transparent disponible. WaveSpeed expose le plus large éventail de points de terminaison Seedance 2.5, y compris des niveaux turbo explicites. La liste de passage d'OpenRouter place le modèle sur la même clé qu'un grand catalogue de texte. Pour la comptabilité des jetons de première partie avec un calculateur publié, Volcano Engine Ark couvre la Chine et BytePlus ModelArk couvre l'international.

FAQ

Q: Quelle est la limite de débit de Seedance 2.5 sur Atlas Cloud ? A: Aucun chiffre numérique n'est publié. Atlas Cloud documente que les limites de débit varient selon le niveau de compte et le type de modèle, et qu'une réponse 429 Too Many Requests est le signal pour contacter le support pour des limites plus élevées. Les comptes Entreprise obtiennent un TPM/RPM personnalisé configuré directement.

Q: Un fournisseur publie-t-il un tableau de concurrence Seedance 2.5 ? A: Non. Au moment de la vérification, aucun des Atlas Cloud, OpenRouter, fal.ai, Replicate, WaveSpeed, Kie.ai ou les canaux ByteDance de première partie ne publie de limite numérique de RPM, TPM ou de concurrence pour ce modèle. Traitez tout chiffre spécifique que vous voyez ailleurs comme non vérifié.

Q: Combien de travaux Seedance 2.5 concurrents dois-je prévoir ? A: Mesurez plutôt que de supposer. Fixez la forme de votre charge de travail, faites monter en puissance un pool de travailleurs borné à travers 2, 4, 8 et 16 travaux concurrents, et trouvez le niveau où les achèvements par minute se stabilisent ou où les 429 commencent. Opérez en dessous de ce coude.

Q: Les webhooks augmentent-ils mon débit ? A: Indirectement, et de manière significative. Ils suppriment les appels de sondage de votre budget de requêtes, de sorte qu'une plus grande partie de votre allocation est consacrée au travail réel. Atlas Cloud documente la livraison au moins une fois avec une échelle de réessai d'environ 10s, 20s et 40s, plafonnée à près de 30 minutes pour un maximum d'environ 10 tentatives, plus un filet de sécurité de réconciliation.

Q: Pourquoi la résolution affecte-t-elle ma limite de débit ? A: Parce que Seedance 2.x est facturé par jetons vidéo de sortie à l'achèvement, et le nombre de jetons augmente avec la durée, la largeur de sortie, la hauteur et la fréquence d'images. Ces mêmes facteurs déterminent l'occupation GPU, donc un travail 720p plus long consomme plus de votre budget de concurrence qu'un travail 480p court.

Q: Suis-je facturé lorsqu'un travail échoue ou est limité en débit ? A: Les générations échouées ne sont pas facturées sur Atlas Cloud, et le montant réservé est automatiquement reversé à votre solde. Une requête rejetée avec 429 ne démarre jamais, donc elle ne produit aucun jeton de sortie à facturer.

En résumé

Aucun fournisseur ne publie de tableau numérique de limite de débit ou de concurrence pour Seedance 2.5, et Atlas Cloud est l'un des rares à documenter explicitement le mécanisme de régulation : limites basées sur le niveau et le type de modèle, 429 comme signal d'escalade, TPM/RPM personnalisé avec surveillance par modèle et par application sur Enterprise, et un contrat de webhook suffisamment détaillé pour construire une file d'attente autorégulée.