La facture de l'API vidéo Seedance est rarement égale au « nombre de vidéos générées multiplié par un prix fixe ». Pour une même vidéo de cinq secondes, la résolution, le palier de modèle, la présence d'une entrée vidéo, les reprises après échec et le stockage du résultat modifient la dépense réelle. Un budget établi sur le tarif affiché se révèle trop bas après la mise en production, généralement parce que ces variables n'ont pas été prises en compte, pas parce que le prix unitaire a augmenté.

Cet article décompose la facturation en quatre dimensions — durée, résolution, reprises et stockage — puis donne une formule d'estimation, une méthode de test et des moyens de contrôle budgétaire. Les prix et règles exacts peuvent évoluer ; référez-vous à la page Tarifs des modèles et à la documentation officielle de facturation.

Remarque : Seedance est un modèle de génération vidéo de ByteDance. Seedance, Doubao, Volcengine et BytePlus sont des marques de leurs détenteurs (ByteDance et ses sociétés affiliées). Cet article est purement technique et n'implique aucune affiliation ni représentation avec les détenteurs des droits. Prix, interfaces et règles de facturation font foi dans la documentation officielle et sur la page Tarifs.

1. Pourquoi une API vidéo ne se budgète pas « à la vidéo »

Les API texte ont une unité de facturation relativement uniforme ; les API vidéo, non. Derrière une requête « générer une vidéo » se cachent au moins quatre variables : la durée, la résolution, le palier de modèle et le mode d'entrée. La facture peut changer dès que l'une d'elles varie.

Plus délicat encore : une soumission ne produit pas nécessairement une vidéo utilisable. Un refus de modération, un timeout ou des images inexploitables entraînent des reprises ; quand le lien du résultat expire, il faut régénérer ou transférer le fichier. Budgéter uniquement « nombre de vidéos × prix unitaire » conduit donc à une sous-estimation systématique.

2. Quatre dimensions de facturation

Dimension Effet sur le coût À enregistrer pour l'estimation Moyen de maîtrise
Durée Facturation à la seconde ou en tokens convertis, croissante avec la durée Durée soumise, durée du rendu, découpage éventuel Tester sur une durée courte, assembler ensuite
Résolution Le nombre de pixels augmente avec la résolution, souvent avec la fréquence d'images Résolution de sortie, fréquence d'images, format Brouillon en basse résolution, montée en qualité en final
Modèle et entrée Prix différents selon la génération, le palier et le mode d'entrée Nom du modèle, image initiale ou vidéo de référence Router selon la difficulté, sans palier maximal par défaut
Échecs et reprises Une soumission répétée peut être refacturée, les règles varient selon l'échec État de la tâche, code d'erreur, nombre de reprises Classer les erreurs, idempotence, limiter les reprises
Stockage et trafic Le transfert, la conservation et la distribution du résultat coûtent en plus Taille du fichier, jours de conservation, accès Nettoyage par cycle de vie, distribution à la demande

Les séries Seedance récentes sont mesurées en tokens dans la documentation officielle, la consommation dépendant de la résolution, de la durée et du scénario d'entrée ; certaines passerelles les convertissent en affichage à la seconde ou à la vidéo. Confirmez l'unité de facturation avant de contracter.

3. Comment durée et résolution amplifient la consommation

La durée est la variable la plus intuitive. Les paliers courants sont de cinq et dix secondes, mais dix secondes ne valent pas forcément exactement le double de cinq : certaines plateformes appliquent une unité minimale de facturation, d'autres arrondissent les secondes. Le budget doit se fonder sur le débit réel de la facture, pas sur une extrapolation à partir de la durée du rendu.

L'effet de la résolution est plus discret. De 720p à 1080p, le nombre total de pixels est multiplié par environ 2,25 ; si la fréquence d'images augmente aussi, la consommation continue de croître. La facture finale ne suit pas nécessairement ce multiple, car le palier de modèle, les remises et les arrondis interviennent. La bonne méthode : fixer le prompt et la durée, ne changer que la résolution, lancer une série comparative et relever l'écart facturé.

Le format d'image influence aussi le nombre de pixels. En portrait et en paysage, à « palier de résolution » identique, le nombre réel de pixels peut différer ; établissez des budgets séparés plutôt qu'une moyenne mensuelle commune.

4. Pourquoi reprises et stockage sont souvent oubliés

Les reprises après échec sont la partie la plus difficile à contenir dans le coût vidéo. Une erreur de paramètre ne doit pas être réessayée ; soumettre à nouveau un contenu refusé par la modération est généralement inutile ; seules les limites de débit et certaines erreurs serveur justifient un backoff.

Enregistrez l'identifiant de tâche en base, vérifiez l'idempotence avant soumission et réutilisez le même enregistrement métier pour une reprise. Sinon, une boucle de script peut soumettre des dizaines de tâches identiques en quelques minutes, avec une facture difficile à justifier.

Le coût de stockage est souvent négligé. Les liens de résultat ont généralement une durée de validité ; après expiration, il faut régénérer. Le transfert vers un stockage objet entraîne ensuite des frais de stockage, de requêtes et de trafic sortant. Transférez le résultat après succès et fixez des règles de nettoyage : sept jours pour les brouillons, archivage des rendus par projet, suppression rapide des éléments abandonnés.

5. Écrire le coût par vidéo sous forme de formule

L'indicateur le plus fiable n'est pas « prix unitaire × durée », mais le coût par vidéo utilisable :

Coût par vidéo utilisable = (coût des tâches réussies + coût des tâches échouées mais facturées + stockage et trafic + revue humaine) ÷ nombre de vidéos validées et directement utilisables

Le dénominateur est le nombre de rendus utilisables, pas le nombre de soumissions. Le code Python ci-dessous effectue la conversion ; lisez les montants dans la facture et ne les figez pas dans le code :

def cost_per_usable_video(task_costs, usable_count, storage_cost=0.0, review_cost=0.0):
    """task_costs : montant facturé par tâche ; usable_count : nombre de rendus utilisables"""
    if usable_count == 0:
        raise ValueError("Aucun rendu utilisable : vérifier d'abord le prompt, les médias et les paramètres")
    total = sum(task_costs) + storage_cost + review_cost
    return total / usable_count

# Remplacer les valeurs d'exemple après export des montants de la facture, en gardant la même unité
weekly_task_costs = [0.0] * 40
print(cost_per_usable_video(weekly_task_costs, usable_count=28))

Enregistrez aussi, avec les champs d'usage de la réponse, le modèle, la durée, la résolution, l'état et le temps d'exécution. Une méthode cohérente permet de comparer d'une semaine à l'autre ; ne mélangez pas les données de canaux différents.

6. Étapes standard d'un test par petits lots

  1. Fixez un palier de modèle, une durée et une résolution comme base de référence.
  2. Préparez vingt à trente prompts métier réels et images initiales, pas seulement des exemples qui passent facilement.
  3. Enregistrez pour chaque tâche l'état, le code d'erreur, le temps d'exécution et le montant débité.
  4. Intégrez les tâches échouées au coût total et calculez le coût par vidéo utilisable.
  5. Observez sept jours consécutifs, extrapolez le coût mensuel à partir de la moyenne quotidienne, puis ajoutez stockage, trafic et temps de revue.
  6. Ne modifiez qu'une variable à la fois, par exemple un palier de résolution, pour mesurer la sensibilité du coût.
  7. Déduisez de ces résultats un « palier de test » et un « palier de rendu final », et consignez-les dans les règles d'équipe.

La valeur d'un test par petits lots n'est pas seulement le chiffre obtenu : c'est de savoir à quelle variable le coût est le plus sensible.

7. Contrôle budgétaire concret

  • Une clé par projet, test et production séparés, pour éviter de mélanger les coûts.
  • Fixer un plafond de quota par clé dans la console et configurer des alertes d'usage quotidien ou hebdomadaire.
  • Estimer une fois avant soumission avec les paramètres courants ; au-delà d'un seuil par vidéo, passer en validation humaine.
  • Limiter la concurrence et le nombre maximal de reprises, en particulier pour les scripts par lots.
  • Utiliser systématiquement la basse résolution pour les brouillons ; ne générer en haute définition que les plans validés.
  • Transférer rapidement les résultats et définir un cycle de vie ; rapprocher chaque semaine par projet, modèle et résolution.

La passerelle fournit généralement des quotas par clé, une liste blanche de modèles et un export d'usage ; référez-vous à la console. Les alertes doivent atteindre une personne : envoyer dans un groupe que personne ne lit revient à ne pas en avoir.

8. Ordre de réduction des coûts et trois erreurs fréquentes

Réduisez les coûts par ordre d'impact décroissant : améliorez d'abord le taux de réussite, réduisez ensuite les reprises inutiles, puis différenciez les résolutions et raccourcissez les durées, traitez ensuite le stockage, et seulement en dernier envisagez un changement de canal. Inverser cet ordre aboutit souvent à un prix unitaire plus bas, mais à un taux d'échec et un coût total plus élevés.

Trois erreurs fréquentes :

  1. Regarder seulement le tarif affiché, sans le taux de réussite ni les reprises. Un canal bon marché mais instable peut coûter plus cher par vidéo utilisable.
  2. Tester sur la durée la plus courte, puis produire sur la durée la plus longue et en haute résolution : le budget ne peut pas correspondre.
  3. Ignorer la durée de validité des liens de résultat et régénérer après expiration, ce qui revient à payer deux fois.

Questions fréquentes

L'API Seedance est-elle facturée à la vidéo, à la seconde ou au token ?

Les séries Seedance récentes sont généralement mesurées en tokens dans la documentation officielle, la consommation dépendant de la résolution, de la durée et du mode d'entrée ; certaines passerelles les convertissent en affichage à la seconde ou à la vidéo. Confirmez l'unité de facturation avant l'intégration et référez-vous à la page Tarifs des modèles.

Passer de 720p à 1080p double-t-il le coût ?

Le nombre total de pixels est multiplié par environ 2,25, mais le montant réel dépend aussi du palier de modèle, de l'unité minimale de facturation et des remises : on ne peut pas simplement multiplier par deux. Un test comparatif avec le même prompt est plus fiable.

Les tâches échouées ou refusées par la modération sont-elles facturées ?

Les règles varient selon la plateforme et la cause de l'échec. Certaines erreurs système ne sont pas facturées, d'autres le sont dès la création de la tâche. Vérifiez avec une commande de test avant l'intégration et intégrez le coût des échecs au coût par vidéo.

Pourquoi le coût augmente-t-il si vite après la mise en production alors que les tests étaient bon marché ?

Causes courantes : tests en cinq secondes et basse résolution, production en dix secondes et haute définition ; multiplication des reprises ; frais de transfert et de distribution ; clé partagée empêchant l'attribution. Séparez les clés par projet et enregistrez la facture au niveau de la tâche.

Comment fixer un plafond budgétaire pour la génération vidéo ?

Au moins trois niveaux : quota par clé, budget par projet et estimation avant soumission au niveau de la tâche. Au seuil atteint, suspendez les tâches non critiques et prévenez le responsable, sans attendre la facture de fin de mois.

Étape suivante

Créez d'abord une clé de test sur ZSQH AI Gateway, lancez vingt à trente tâches avec la configuration minimale, enregistrez le taux de réussite, le temps d'exécution et les montants débités, puis convertissez le budget mensuel à partir de la page Tarifs des modèles. Pour comprendre d'abord le flux des tâches asynchrones, lisez ensuite le guide d'intégration du site.

À lire aussi :