Seedance 2.5 is live — 30-second cinematic video with native audio & real-person references
Seedream 5.0 Pro : limites documentées et retests
2026/07/25

Seedream 5.0 Pro : limites documentées et retests

Distinguez limites documentées et paramètres par défaut de Seedream 5.0 Pro des défauts visuels. Mesurez via tests reproductibles plutôt qu'un seul résultat.

Bien des défauts signalés dans Seedream 5.0 Pro sont des comportements documentés ou des limites dures qui rejettent la requête avant qu'un seul pixel ne soit généré. Les défauts visuels forment une catégorie distincte : sans critère de base public spécifique au modèle, il faut les reproduire avec un test contrôlé au lieu d'affecter un taux de réussite à partir d'un seul rapport.

Cet article se lit comme une table de recherche plutôt qu'un essai. Trouvez votre symptôme dans le tableau, lisez cette section, et appliquez la correction documentée ou la procédure de retest.

TL;DR

  • L'échec du long prompt est documenté par ByteDance avec un seuil. Le champ prompt recommande de rester sous 300 caractères chinois ou 600 mots anglais et énonce la conséquence : trop de mots dispersent l'information, le modèle ignore les détails et l'image revient incomplète[1].
  • La validation acceptée n'est pas le modèle qui fait face. Le plafond dur de reAPI est 4 000 caractères[5], bien au-delà de 600 mots.
  • Aucun critère public n'établit un taux d'échec d'anatomie spécifique à Seedream. Si vous voyez des membres en surnombre ou des proportions gauches, conservez le prompt et mesurez les passes répétées avant de changer le workflow.
  • Beaucoup de « défauts » sont des rejets énumérables : 512×512 est en dessous du plancher de pixels, les références plafonnent à 10, chacune doit être en dessous de 30 Mo et 36 millions de pixels[1][2].
  • Le filigrane est une valeur par défaut, pas un défaut. Sur l'API Ark de ByteDance, watermark vaut true sauf si vous passez false[1]. reAPI le désactive[5].
  • Les tests contrôlés coûtent des centimes : dix passes de 1K d'un prompt suspect coûtent 32 cents au tarif publié[6].

Trouvez votre symptôme

Ce que vous voyezCe qui se passe réellementAllez à
Certaines choses que vous avez demandées manquent à l'imageComportement documenté au-delà d'une longueur de prompt documentéeÉléments manquants
Membres en surnombre ou proportions gauchesDéfaut visuel sans paramètre de correction documenté garantiRetest visuel
L'API retourne une erreur avant de générer quoi que ce soitL'une d'une liste finie de limites documentéesRejets
Une marque « générée par IA » dans le coinLe défaut en amont est le filigrane surFiligrane
Vous avez demandé quatre variantes et reçu une imageLa sortie de groupe n'est pas prise en charge sur ce modèleRejets
Ça marchait le mois dernier et se comporte différemment maintenantLe snapshot tamponné par version a changéBoucle de retest

Symptôme : des éléments de votre prompt manquent

Vous écrivez douze conditions, vous en recevez neuf, et rien dans la réponse ne vous dit lesquelles trois ont disparu. C'est la défaillance la plus chère en production et la mieux documentée.

Le champ prompt de ByteDance recommande pas plus de 300 caractères chinois ou 600 mots anglais, puis énonce la raison clairement : quand le nombre de mots devient trop élevé, l'information se disperse, donc le modèle peut ignorer les détails et prêter attention seulement aux points majeurs, ce qui provoque à l'image de manquer certains éléments[1]. C'est le fournisseur décrivant le mode d'échec de son propre produit, avec un nombre attaché.

Pourquoi le nombre de mots n'est pas la seule métrique. La limite de mots documentée ne garantit pas que chaque élément demandé apparaisse. Traitez chaque sujet, objet, relation spatiale, détail de garde-robe et condition d'arrière-plan comme un contrôle d'acceptation séparé, puis utilisez votre suite contrôlée pour trouver où le prompt commence à les abandonner.

Pourquoi les négations l'aggravent. Seedream 5.0 Pro n'a pas de paramètre negative_prompt, sur l'API ByteDance ou sur reAPI[1][5]. Une queue comme « pas de retouche, pas de symétrie parfaite, pas de peau plastique, pas de sourire commercial, pas de faux cils, pas de dents blanches impeccables, pas d'éclairage glamour » dépense une trentaine de mots du même budget d'attention sur ce que vous ne voulez pas.

Le correctif.

  • Non-négociables dans les deux premières phrases : sujet, les objets qui doivent exister, leurs relations spatiales.
  • Un élément par phrase, pas une chaîne de virgules enterrant trois conditions dans une clause.
  • Si les passes répétées abandonnent les exigences, simplifiez la scène de base et ajoutez les éléments secondaires dans un second appel.
  • Mettez le texte que vous voulez rendu à l'intérieur de guillemets doubles. C'est la technique énoncée par ByteDance, pas du folklore[3].
  • Relisez le prompt comme une liste de contrôle et cochez chaque élément dans la sortie.

Le guide de prompt de ByteDance, qui couvre les modèles lite, 4.5 et 4.0 et est antérieur à 5.0 Pro, est explicite sur la forme qui fonctionne : sujet plus action plus environnement en langage naturel connecté, avec style, couleur, lumière et composition comme expressions supplémentaires. Son propre contre-exemple marque « une fille, tenant un parapluie, rue ombragée, travail de pinceau fin comme une peinture à l'huile » comme la version à éviter, et il énonce que les prompts concis et précis battent généralement l'empilement d'un vocabulaire orné[3].

Symptôme : des membres en surnombre et des proportions gauches

Il n'y a pas de critère public spécifique au modèle pour ce symptôme et pas de paramètre documenté garantissant une correction. Traitez un mauvais résultat comme un cas de test : conservez le prompt exact, les références, le snapshot du modèle et le niveau de sortie, puis répétez la requête avant de décider si le prompt a changé le résultat.

Quand vos propres défaillances s'agglomèrent autour de membres cachés ou chevauchants, rendez l'arrangement du corps visible explicite et comparez-le avec la base de référence sauvegardée.

Configuration à haut risquePourquoi le comptage s'effondreLangage de prompt qui réduit le risque
Hanches ou genoux sous tissu lâcheLes articulations cachées arrêtent l'ancrage des jambes« deux jambes inférieures émergent sous la draperie, croisées aux chevilles »
Jambes croisées, pieds rentrésLes mollets chevauchants brouillent quel tibia est quel« jambes croisées aux chevilles, les deux pieds visibles »
Mains entrelacées, mains derrière le dosLes doigts occultés invitent du surplus« les deux mains reposent à plat sur la table, doigts visibles »
Deux figures debout près l'une de l'autreLes membres se voient attribués au mauvais corps« son bras sur son épaule, ses mains dans ses poches »

« Assis élégamment » laisse chacun de ces comptages ouvert. La version explicite terne lit comme une direction scénique parce que c'est ce qu'elle est.

La règle de processus qui compte plus que le prompt. Gardez le nombre de passes, le snapshot du modèle, les références et le niveau de sortie fixes tout en changeant un détail du prompt. Comparez le taux de passage mesuré avec la base de référence sauvegardée ; ne présentez pas cinq échantillons comme un taux d'échec à l'échelle du modèle.

La réparation qui bat la régénération. L'édition interactive vous permet de marquer une région sur une image terminée, soit en dessinant sur l'entrée, soit en écrivant des balises de coordonnées <point> / <bbox> dans le prompt, et n'édite que dans cette région[2]. Un résultat acceptable avec une mauvaise main n'a pas besoin d'une régénération complète. Vérifiez les pixels juste en dehors de la zone marquée après, car une édition locale peut pousser ses voisins. C'est exclusif à 5.0 Pro parmi les modèles Seedream, et ce n'est pas dans l'ensemble de paramètres actuel de reAPI[2][5].

Symptôme : la requête échoue avant de générer quoi que ce soit

Bonne nouvelle : ce tas est déterministe. Énumérez-le une fois, encodez-le dans votre propre validation, arrêtez de le frapper.

Ce que vous envoyezRésultatPourquoi
size: "512x512"RejetéAu-dessous du plancher de 921 600 pixels ; les documents utilisent cette valeur exacte comme exemple invalide[1]
Dimensions dépassant 4 624 220 pixels totauxRejetéC'est le plafond de 5.0 Pro ; les niveaux sont 1K et 2K, rien de plus[2]
Une 11e image de référenceRejeté5.0 Pro plafonne à 10 ; lite, 4.5 et 4.0 prennent 14[1]
Une photo de référence de 40 MoRejetéLes références doivent être en dessous de 30 Mo et 36 millions de pixels[1]
Une référence en dessous de 15 px d'un côté, ou en dehors de 1:16 à 16:1RejetéLimites d'entrée documentées[1]
Une image base64 data:Rejeté à la passerelleURL HTTP(S) publiques uniquement, à l'échelle de la plateforme sur reAPI[5]
Un champ n, seed ou negative_promptRejetéSchéma strict ; les clés inconnues échouent à la validation[5]
Une requête attendant quatre imagesUne image retournéeLa sortie de groupe n'est pas prise en charge sur 5.0 Pro ; reAPI retourne exactement une par appel[2][5]
Une requête de streaming, ou demandant une recherche webPas disponibleLes deux sont pris en charge sur 5.0 lite, non pris en charge sur 5.0 Pro[2]
Une URL de référence que ByteDance ne peut pas récupérerRejetéLes URL de référence doivent être publiquement accessibles[1]

Deux comportements de la même famille qui ne sont pas des rejets mais mordent de la même façon.

Les URL expirent. Sur l'API propre de ByteDance, la rétention est de 24 heures[2] ; sur reAPI, c'est 72[5]. Un pipeline traitant l'URL retournée comme stockage permanent commence à servir des liens morts, et la défaillance refait surface des jours plus tard dans n'importe quelle base de données où vous l'avez sauvegardé.

Un résultat bloqué reste facturé. Sur reAPI, un prompt ou une référence rejeté avant génération rembourse la tâche. Une image générée puis bloquée par la vérification de résultat retourne une erreur de stratégie de contenu, masque l'image, et reste facturée, car la génération a déjà eu lieu en amont[5].

Symptôme : un filigrane que vous n'avez pas demandé

Un booléen. Sur l'API Ark de ByteDance, watermark vaut true par défaut, qui tamponne une marque générée par IA dans le coin inférieur droit de chaque image[1]. Les gens intègrent, naviguent, et remarquent le badge quand un client le pointe.

reAPI désactive le filigrane, et le champ watermark est accepté mais ignoré, conservé pour les appelants qui se sont intégrés contre la forme de requête antérieure[5].

Deux proches à vérifier pendant que vous y êtes. Sur Ark, output_format vaut jpeg par défaut, donc PNG doit être demandé, et sur la surface actuelle de reAPI, ce champ est aussi accepté et ignoré[1][5]. Et size vaut par défaut 2K, le niveau plus cher, donc quiconque l'a omis en itérant a payé le taux plus élevé pour les brouillons[2].

Un bouton existe et mérite d'être connu, car je l'ai vu décrit sous des noms inventés : optimize_prompt_options.mode sur Ark, prenant standard par défaut et fast pour une latence inférieure à un certain coût de qualité[2]. C'est le seul commutateur de mode documenté sur ce modèle.

Deux façons d'exécuter une suite de retest

Un seul défaut visuel n'établit pas un taux à l'échelle du modèle ni ne sépare les effets du prompt de la variance d'échantillonnage. À 0,032 $ pour une image 1K, dix passes d'un prompt suspect coûtent 32 cents[6]. Exécutez l'ensemble contrôlé et comptez avant de tirer une conclusion.

Conservez une suite d'échec de toute façon : cinq à dix prompts qui ont réellement cassé, sauvegardés mot pour mot avec le rapport d'aspect et le niveau auquel ils ont été exécutés.

Méthode 1 — reproduire manuellement au niveau brouillon

  1. Réexécutez chaque prompt sauvegardé cinq fois en 1K, inchangé, et enregistrez le taux de passage. C'est votre ligne de base.
  2. Changez exactement une chose : raccourcissez le prompt, préfacez les éléments clés, ou ajoutez un langage de comptage explicite.
  3. Réexécutez les mêmes cinq et comparez les taux de passage.
  4. Conservez le gagnant, puis restituez le prompt approuvé une fois en 2K pour le livrable.

Gardez le niveau constant pendant que vous mesurez. Changer la résolution change la surface d'échec, et une suite où moitié des passes sont 1K et moitié sont 2K ne vous dit rien d'exploitable.

Méthode 2 — lot de la suite via l'API

Une fois les réparations stabilisées, une suite de dix prompts est une boucle au lieu d'un après-midi de clics. Soumettez chaque prompt N fois et collectez les identifiants de tâche :

for i in $(seq 1 5); do
  curl -s https://reapi.ai/api/v1/images/generations \
    -H "Authorization: Bearer $REAPI_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
      "model": "doubao-seedream-5-0-pro",
      "prompt": "<one failed prompt from your suite>",
      "aspect_ratio": "3:4",
      "quality": "basic"
    }' | jq -r '.id'
done

Puis sondez chaque id jusqu'à ce qu'il se stabilise. Le sondage est gratuit, donc une suite de cinquante passes coûte exactement cinquante images brouillon et rien d'autre[5] :

curl -s https://reapi.ai/api/v1/tasks/$TASK_ID \
  -H "Authorization: Bearer $REAPI_API_KEY" | jq '.status, .output.image_urls[0]'

Deux remarques opérationnelles. Le taux limite documenté est 500 images par minute par compte par version du modèle, ce qui est généreux mais un plafond réel si vous éventrez une grande suite à la fois[2]. Et réexécutez la suite complète quand l'identifiant du modèle change : ByteDance expédie des snapshots tampon avec version, l'actuel étant doubao-seedream-5-0-pro-260628[4], et le comportement à cette couche glisse tranquillement entre eux.

FAQ

Seedream 5.0 Pro a-t-il un problème de main spécifiquement ?

Aucun critère public n'isole un taux d'erreur d'anatomie spécifique à Seedream 5.0 Pro, donc ne transformez pas un résultat individuel en affirmation à l'échelle du modèle. Conservez le prompt et les références exacts, répétez-les à un niveau, et signalez le taux de passage mesuré pour cet ensemble de test.

Combien de temps un prompt peut-il être ?

reAPI accepte jusqu'à 4 000 caractères[5], mais ByteDance recommande moins de 300 caractères chinois ou 600 mots anglais et explique que le dépassement cause des éléments abandonnés[1]. Comptez les exigences discrètes ainsi que les mots, et divisez la requête quand les tests répétés les abandonneront.

Puis-je corriger une mauvaise main sans régénérer l'image ?

Sur l'API ByteDance, oui, via l'édition interactive avec une région marquée ou des balises <point> / <bbox>[2]. C'est exclusif à 5.0 Pro parmi les modèles Seedream et ne se trouve pas dans l'ensemble de paramètres actuel de reAPI[5].

Pourquoi ma requête 512×512 a-t-elle échoué ?

Il est en dessous du minimum. Seedream 5.0 Pro nécessite entre 921 600 et 4 624 220 pixels totaux, et la documentation nomme 512×512 comme exemple invalide pour exactement cette raison[1].

Puis-je obtenir quatre variantes en un seul appel ?

Non sur ce modèle. La sortie d'image de groupe n'est pas prise en charge pour 5.0 Pro bien que 5.0 lite, 4.5 et 4.0 l'aient[2]. Envoyez quatre appels ; l'API est asynchrone donc ils s'exécutent en parallèle.

Le modèle hérite-t-il de l'angle de la caméra de ma photo de référence ?

Le guide de ByteDance aborde la partie contrôlable : énoncez explicitement ce qui doit être pris de la référence et, séparément, ce que la scène générée devrait être[3]. Testez le comportement de la caméra avec votre propre image au lieu d'assumer que la référence la verrouille.

Ces problèmes en font-ils le mauvais modèle ?

Pas nécessairement. Les limites de requête et les défauts ont des corrections documentées. Pour les défauts visuels, comparez le coût par image acceptée sur un ensemble contrôlé de vos propres prompts plutôt que de compter sur une anecdote intermodèle.

Corriger ce que vous pouvez, régénérer ce que vous ne pouvez pas

Lisez la documentation des paramètres une fois, car beaucoup d'échecs signalés sont une limite ou une valeur par défaut assis en texte brut. Puis construisez une suite d'échec pour les défauts visuels que la documentation ne peut pas trancher. Le problème du long prompt a un nombre attaché, la liste de rejet appartient à votre propre validation, et le filigrane est un booléen. Ce qui reste devrait être mesuré avec des prompts explicites et des retours contrôlés au prix brouillon publié.

References

  1. Volcano Engine. Image generation API — prompt guidance, reference-image limits, parameter defaults. Retrieved July 2026 from volcengine.com/docs/82379/1541523
  2. Volcano Engine. Doubao Seedream 5.0 Pro guide — capability matrix, interactive editing, resolution tiers, rate limit, retention. Retrieved July 2026 from volcengine.com/docs/82379/2582774
  3. Volcano Engine. Seedream 4.0-5.0 prompt guide — prompt structure, quoted text rendering, reference-image instructions. Retrieved July 2026 from volcengine.com/docs/82379/1829186
  4. Volcano Engine. Model release announcements — doubao-seedream-5-0-pro-260628. Retrieved July 2026 from volcengine.com/docs/82379/1159178
  5. reAPI. Seedream 5.0 Pro API reference — request body, limits, errors, retention. Retrieved July 2026 from reapi.ai/docs/seedream-5-0-pro
  6. reAPI. Seedream 5.0 Pro — live pricing table. Retrieved July 2026 from reapi.ai/models/seedream-5-0-pro

Further reading