Comment corriger les erreurs 429 et de limite de débit de l'API Meshy

Si votre intégration rencontre des erreurs 429, RateLimitExceeded ou NoMoreConcurrentTasks lors des appels à l'API Meshy, ce guide explique pourquoi ces limites existent et comment concevoir votre intégration pour qu'elle fonctionne avec elles.

L'API Meshy se trouve devant des ressources GPU partagées utilisées pour générer des modèles 3D, des textures et d'autres ressources associées. Les limites de débit et de concurrence protègent cette infrastructure partagée afin que la qualité de génération et les délais restent constants pour chaque utilisateur de la plateforme. Chaque compte, selon son plan actuel, dispose d'un nombre maximal de requêtes qu'il peut effectuer dans une fenêtre de temps donnée et d'un nombre maximal de tâches de génération qu'il peut avoir en cours d'exécution (en file d'attente ou en cours de traitement) simultanément.

Il existe deux limites distinctes, et elles se manifestent différemment :

• Limite de débit de requêtes (429 / RateLimitExceeded) : elle plafonne le nombre d'appels API (par ex. création de tâche, interrogation de statut) que vous pouvez effectuer par minute. La dépasser signifie que vous appelez l'API trop fréquemment, indépendamment du nombre de tâches réellement en cours.

• Limite de concurrence / de file d'attente (NoMoreConcurrentTasks) : elle plafonne le nombre de tâches de génération que vous pouvez avoir en file d'attente ou en traitement en même temps. La dépasser signifie que vous avez déjà atteint le nombre maximal de tâches actives et que vous devez attendre qu'une tâche se termine avant d'en soumettre une autre.

Consultez les limites actuelles de requêtes et de concurrence de votre plan dans votre tableau de bord Meshy, car elles peuvent varier selon le niveau du plan.

Lorsque vous recevez une réponse 429 ou RateLimitExceeded, ne réessayez pas immédiatement la même requête. Au lieu de cela :

• Utilisez un backoff exponentiel : attendez un court intervalle, puis doublez-le à chaque échec suivant, jusqu'à un maximum raisonnable.

• Ajoutez du jitter (un léger décalage aléatoire) à votre intervalle de backoff afin que plusieurs workers de votre système ne réessaient pas tous au même instant.

• Respectez tout en-tête Retry-After ou tout en-tête de limite de débit renvoyé dans la réponse, le cas échéant, plutôt que de deviner un temps d'attente.

• Plafonnez le nombre de tentatives par requête afin qu'un échec persistant ne boucle pas indéfiniment.

Une erreur NoMoreConcurrentTasks signifie que vous avez déjà atteint le plafond de tâches actives de votre compte. Pour éviter de le rencontrer en production :

• Maintenez une file d'attente locale ou un ordonnanceur de tâches dans votre propre application qui ne soumet une nouvelle tâche de génération qu'une fois la précédente terminée ou lorsque votre nombre de tâches actives passe sous la limite.

• Interrogez le statut des tâches (ou utilisez des webhooks, si pris en charge dans votre flux de travail) pour savoir quand un emplacement se libère, plutôt que de soumettre de manière spéculative.

• Regroupez et régulez les tâches de génération en masse au lieu d'envoyer toutes les requêtes d'un coup — cela lisse à la fois votre débit de requêtes et votre nombre de tâches simultanées.

• Mettez en place une supervision/des alertes de votre côté afin qu'une hausse des erreurs 429/NoMoreConcurrentTasks soit visible avant qu'elle n'affecte vos utilisateurs.

L'API Meshy ne prend pas actuellement en charge un « retry » intégré d'une génération existante pour les plans individuel ou studio — si un résultat ne répond pas à vos attentes, vous soumettez une nouvelle requête de génération, qui consomme des crédits normalement. Lorsque votre pipeline automatisé gère des erreurs transitoires (comme une erreur 429), assurez-vous que votre logique de nouvelle tentative ne renvoie que la requête d'origine après un backoff, sans créer de tâches de génération en double à chaque fois.

Si vous avez mis en œuvre un backoff et une file d'attente tenant compte de la concurrence et que vous atteignez toujours régulièrement les limites de débit ou de concurrence, c'est généralement le signe que les besoins de débit de votre intégration ont dépassé les limites de votre plan actuel. Consultez votre tableau de bord pour connaître les quotas de requêtes et de concurrence de votre plan actuel, et envisagez de passer à un plan supérieur ou de contacter l'équipe commerciale de Meshy au sujet d'un accès API de niveau entreprise si vous avez besoin d'un débit soutenu plus élevé.

Cela signifie que vous avez dépassé le nombre de requêtes API autorisées dans une fenêtre de temps donnée pour votre plan. Ralentissez votre débit de requêtes et utilisez un backoff exponentiel avant de réessayer.

Cela signifie que vous avez déjà atteint le nombre maximal de tâches de génération en file d'attente ou en cours pour votre compte. Attendez qu'une tâche existante se termine, ou réduisez le nombre de tâches soumises simultanément, avant d'en soumettre d'autres.

Consultez votre tableau de bord Meshy pour voir les limites associées à votre plan actuel, car elles peuvent différer selon les niveaux de plan.

Non, pas pour les plans individuel ou studio — une génération échouée ou insatisfaisante doit être soumise à nouveau comme une nouvelle requête, qui consomme des crédits normalement. Les clients entreprise doivent contacter l'équipe commerciale au sujet de la fonctionnalité de nouvelle tentative.

Mettez en place une file d'attente locale qui régule les soumissions pour rester sous votre limite de concurrence, ajoutez un backoff exponentiel avec jitter pour toute réponse 429, et surveillez les taux d'erreur afin de pouvoir réagir avant qu'ils n'impactent vos utilisateurs.

Si vous avez déjà mis en œuvre un backoff et une file d'attente tenant compte de la concurrence et que vous atteignez toujours régulièrement ces limites, votre utilisation a probablement dépassé votre plan actuel — consultez votre tableau de bord ou contactez l'équipe commerciale au sujet d'un plan à débit plus élevé.

• Comment utiliser l'API Meshy ?

• L'API Meshy prend-elle en charge le retry pour les générations ?