Cycle de vie d'une tâche
Découvrez comment une tâche passe de la requête au résultat, combien de temps cela prend généralement, et combien de temps votre code doit l'attendre.
Déroulement d'une tâche
Une requête de création renvoie un ID de tâche sans attendre l'exécution de la tâche. La tâche s'exécute ensuite en arrière-plan, et vous la suivez de l'une des trois façons suivantes : interroger son point de terminaison GET, ouvrir son point de terminaison de flux, ou recevoir un webhook.
PENDING. Un worker la prend en charge et elle passe en IN_PROGRESS, où elle passe la majeure partie de son temps. Elle se termine par SUCCEEDED ou FAILED, et un statut final ne change jamais.PENDINGIN_PROGRESSSUCCEEDEDFAILEDLa tâche enregistre chaque étape dans ses champs created_at, started_at et finished_at.
Le tableau suivant montre ce que votre code doit faire à chaque statut.
| Statut | Ce que votre code doit faire |
|---|---|
PENDING | Continuer d'attendre. |
IN_PROGRESS | Suivre progress : le pourcentage du travail effectué, de 0 à 100. |
SUCCEEDED | Télécharger le résultat. Meshy conserve les fichiers pendant une durée limitée. Voir Conservation des ressources. |
FAILED | Lire task_error, puis corriger l'entrée ou créer une nouvelle tâche. Voir Erreurs. |
CANCELED | Arrêter d'attendre. La tâche ne produira pas de résultat. Seules les tâches Creative Lab utilisent ce statut. |
SUCCEEDED, FAILED et CANCELED sont finaux. Une fois qu'une tâche atteint l'un de ces statuts, celui-ci ne change plus jamais.
Depuis votre code, cela ressemble à ceci :
Requête: POST/image-to-3d
Réponse: 202{ "result": "<task_id>" }tâche créée
- Répéter toutes les quelques secondes
Requête: GET/image-to-3d/<task_id>
Réponse: 200{ "status": "IN_PROGRESS","progress": 45 }Retry-After: 5
Requête: GET/image-to-3d/<task_id>
Réponse: 200{ "status": "SUCCEEDED","model_urls": { "glb": "…" } }
GET plus tard avec le même ID de tâche.Temps de traitement
Les tableaux suivants montrent les temps médians sur le trafic API de production en septembre 2026.
Un temps s'écoule entre la création de la tâche et le statut final. Il s'agit presque entièrement de traitement, car une tâche reste généralement en PENDING pendant seulement quelques secondes. Lorsque la file d'attente est chargée, les tâches peuvent attendre plus longtemps avant de démarrer, et les tâches sur des forfaits avec une priorité plus élevée démarrent généralement plus tôt.
Les temps inférieurs à 2 minutes sont en secondes (s), et les temps plus longs sont en minutes (min). « Non pris en charge » signifie que l'API ne propose pas cette option avec ce modèle.
Il s'agit de temps types, et non de délais d'exécution garantis. Pendant les périodes chargées, certaines tâches prennent plus de temps mais aboutissent tout de même. Pour vérifier l'état de Meshy, consultez la page de statut. N'utilisez pas ces temps comme timeouts dans votre code. Pour les valeurs de timeout, consultez Combien de temps attendre.
Génération 3D
| API | Configuration | meshy-7.1 (latest) | meshy-6 | meshy-6-lite | meshy-t2 |
|---|---|---|---|---|---|
| Texte en 3D (Preview) | Maillage uniquement | 75 s | 90 s | 45 s | 10 s |
| Image en 3D | Maillage uniquement | 75 s | 90 s | 40 s | 4 s |
| Maillage avec textures 2K | 2 min | 3 min | 75 s | 60 s | |
| Maillage avec textures 4K | 2,5 min | 3,5 min | Non pris en charge | 80 s | |
| Maillage avec textures 8K | 3,5 min | 4 min | Non pris en charge | 2,5 min | |
| Multi-image en 3D | Maillage uniquement | 65 s | 2 min | 30 s | Non pris en charge |
| Maillage avec textures 2K | 2,5 min | 3,5 min | 85 s | Non pris en charge | |
| Maillage avec textures 4K | 3 min | 4 min | Non pris en charge | Non pris en charge | |
| Maillage avec textures 8K | 3,5 min | 4,5 min | Non pris en charge | Non pris en charge |
Pour Image en 3D et Multi-image en 3D, « Maillage uniquement » signifie should_texture: false. Ces options et entrées modifient le temps :
- Les cartes PBR (
enable_pbr) ajoutent 30 à 60 secondes. - La géométrie ultra (
geometry_resolution: "2k"ou"4k") ajoute jusqu'à 1 minute. - Avec les mêmes paramètres, des images d'entrée plus complexes prennent plus de temps.
Texturisation
| API | Résolution de texture | Temps type |
|---|---|---|
| Texte en 3D (Refine) | 2K ou 4K | 80 s |
| 8K | 3,5 min | |
| Retexturisation | 2K | 55 s |
| 4K | 90 s | |
| 8K | 2,5 min |
Génération d'images
| API | nano-banana | nano-banana-2 | nano-banana-pro | Modèles GPT Image |
|---|---|---|---|---|
| Texte en image | 20 s | 15 s | 25 s | 20 à 35 s |
| Image en image | 40 s | 20 s | 30 s | 20 à 40 s |
Rigging et Animation
| API | Configuration | Temps type |
|---|---|---|
| Auto-Rigging | Rigging automatique | 40 s |
| Animation | Par requête | 15 s |
| Texte en mouvement | mode prime | 15 s |
mode swift | 10 s |
Post-traitement
| API | Temps type |
|---|---|
| Remaillage | 2 min |
| Dépliage UV | 35 s |
| Convertir | 7 s |
| Redimensionner | 15 s |
Impression 3D
| API | Configuration | Temps type |
|---|---|---|
| Analyser l'imprimabilité | Vérifications de maillage uniquement | 1 s |
| Vérifications de maillage et de parois fines | 10 s | |
| Multi-Color | Par requête | 30 s |
| Réparer l'imprimabilité | Réparation de maillage uniquement | 10 s |
| Vérification des parois fines, parois conservées | 20 s | |
| Vérification des parois fines, parois épaissies | 100 s | |
| Auto Split | Par requête | 70 s |
Sur la v2, Réparer l'imprimabilité et Analyser l'imprimabilité exécutent toujours la vérification des parois fines. Sur la v1, elles l'exécutent lorsque vous envoyez un type d'imprimante ou une taille d'impression.
Combien de temps attendre
La tâche continue de s'exécuter même si votre code cesse de l'attendre. Si votre requête expire, si votre connexion se coupe ou si votre flux se ferme, la tâche n'échoue pas et n'est pas annulée.
- Attendez au moins 60 minutes, comptées à partir du
created_atde la tâche, avant de cesser d'attendre. Si vous arrêtez plus tôt, vous risquez de manquer une tâche qui aboutit plus tard. Cela se produit principalement pendant les périodes chargées. - Conservez l'ID de la tâche. Vous pouvez récupérer la tâche à tout moment. Si elle n'est toujours pas dans un état final après 60 minutes, vérifiez-la à nouveau plus tard. Si cela persiste, contactez le support.
- Seul
FAILEDsignifie que la tâche a échoué. Meshy rembourse automatiquement les tâches en échec.
Utilisez ces valeurs dans votre code :
| Paramètre | Valeur recommandée |
|---|---|
Timeout de la requête de création (POST) | 60 secondes |
Timeout de la requête de création (POST) avec un fichier model_url de plus de 100 Mo | 120 secondes. Meshy télécharge le fichier avant de répondre. |
Timeout de la requête de statut (GET) | 30 secondes |
| Intervalle d'interrogation | L'en-tête Retry-After, ou 5 secondes si celui-ci est absent. Les interrogations comptent dans votre limite de débit. |
Échec de la requête de statut (timeout, 429 ou 5xx) | Réessayez à la prochaine interrogation. Cela ne signifie pas que la tâche a échoué. |
| Attente totale par tâche | Au moins 60 minutes à partir de created_at. Ne redémarrez pas ce décompte lorsque vous reconnectez un flux. |
| Flux | Un flux peut se fermer avant que la tâche ne se termine. S'il se ferme sans statut final, reconnectez-vous ou passez à l'interrogation. |
Pour de nombreuses tâches à la fois, utilisez les webhooks plutôt que d'interroger chacune d'elles. Si l'événement final d'une tâche n'est pas arrivé après environ deux fois son temps habituel, récupérez la tâche depuis son point de terminaison GET.