Lebenszyklus einer Aufgabe
Erfahren Sie, wie eine Aufgabe von der Anfrage zum Ergebnis gelangt, wie lange das üblicherweise dauert und wie lange Ihr Code darauf warten sollte.
Wie eine Aufgabe abläuft
Eine Erstellungsanfrage gibt eine Task-ID zurück, ohne darauf zu warten, dass die Aufgabe ausgeführt wird. Die Aufgabe läuft dann im Hintergrund, und Sie verfolgen sie auf eine von drei Arten: Abfragen des GET-Endpunkts, Öffnen des Stream-Endpunkts oder Empfangen eines Webhooks.
PENDING. Ein Worker übernimmt sie, und sie wechselt zu IN_PROGRESS, wo sie die meiste Zeit verbringt. Sie endet mit SUCCEEDED oder FAILED, und ein finaler Status ändert sich nie wieder.PENDINGIN_PROGRESSSUCCEEDEDFAILEDDie Aufgabe erfasst jeden Schritt in ihren Feldern created_at, started_at und finished_at.
Die folgende Tabelle zeigt, was Ihr Code bei jedem Status tun sollte.
| Status | Was Ihr Code tun sollte |
|---|---|
PENDING | Weiter warten. |
IN_PROGRESS | progress verfolgen: den Prozentsatz der erledigten Arbeit, von 0 bis 100. |
SUCCEEDED | Das Ergebnis herunterladen. Meshy bewahrt die Dateien für eine begrenzte Zeit auf. Siehe Aufbewahrung von Assets. |
FAILED | task_error lesen, dann die Eingabe korrigieren oder eine neue Aufgabe erstellen. Siehe Fehler. |
CANCELED | Nicht mehr warten. Die Aufgabe liefert kein Ergebnis. Nur Creative-Lab-Aufgaben verwenden diesen Status. |
SUCCEEDED, FAILED und CANCELED sind final. Nachdem eine Aufgabe einen dieser Zustände erreicht hat, ändert sich ihr Status nie wieder.
Aus Sicht Ihres Codes sieht das so aus:
Anfrage: POST/image-to-3d
Antwort: 202{ "result": "<task_id>" }Aufgabe erstellt
- Alle paar Sekunden wiederholen
Anfrage: GET/image-to-3d/<task_id>
Antwort: 200{ "status": "IN_PROGRESS","progress": 45 }Retry-After: 5
Anfrage: GET/image-to-3d/<task_id>
Antwort: 200{ "status": "SUCCEEDED","model_urls": { "glb": "…" } }
GET und derselben Task-ID ab.Verarbeitungszeiten
Die folgenden Tabellen zeigen Median-Zeiten für den Produktions-API-Verkehr im September 2026.
Eine Zeit läuft von der Aufgabenerstellung bis zum finalen Status. Fast die gesamte Zeit entfällt auf die Verarbeitung, da eine Aufgabe meist nur wenige Sekunden im Status PENDING verbleibt. Wenn die Warteschlange ausgelastet ist, können Aufgaben länger warten, bevor sie starten, und Aufgaben auf Plänen mit höherer Priorität starten in der Regel früher.
Zeiten unter 2 Minuten sind in Sekunden (s) angegeben, längere Zeiten in Minuten (min). „Nicht unterstützt“ bedeutet, dass die API diese Option mit diesem Modell nicht anbietet.
Dies sind typische Zeiten, keine garantierten Fertigstellungszeiten. In Zeiten hoher Auslastung dauern manche Aufgaben länger, sind aber dennoch erfolgreich. Den Status von Meshy erfahren Sie auf der Statusseite. Verwenden Sie diese Zeiten nicht als Timeouts in Ihrem Code. Timeout-Werte finden Sie unter Wie lange warten.
3D-Generierung
| API | Konfiguration | meshy-7.1 (latest) | meshy-6 | meshy-6-lite | meshy-t2 |
|---|---|---|---|---|---|
| Text to 3D (Preview) | Nur Netz | 75 s | 90 s | 45 s | 10 s |
| Bild zu 3D | Nur Netz | 75 s | 90 s | 40 s | 4 s |
| Netz mit 2K-Texturen | 2 min | 3 min | 75 s | 60 s | |
| Netz mit 4K-Texturen | 2,5 min | 3,5 min | Nicht unterstützt | 80 s | |
| Netz mit 8K-Texturen | 3,5 min | 4 min | Nicht unterstützt | 2,5 min | |
| Multi-Bild zu 3D | Nur Netz | 65 s | 2 min | 30 s | Nicht unterstützt |
| Netz mit 2K-Texturen | 2,5 min | 3,5 min | 85 s | Nicht unterstützt | |
| Netz mit 4K-Texturen | 3 min | 4 min | Nicht unterstützt | Nicht unterstützt | |
| Netz mit 8K-Texturen | 3,5 min | 4,5 min | Nicht unterstützt | Nicht unterstützt |
Bei Bild zu 3D und Multi-Bild zu 3D bedeutet „Nur Netz“ should_texture: false. Diese Optionen und Eingaben verändern die Zeit:
- PBR-Texturen (
enable_pbr) fügen 30 bis 60 Sekunden hinzu. - Ultra-Geometrie (
geometry_resolution: "2k"oder"4k") fügt bis zu 1 Minute hinzu. - Bei gleichen Einstellungen dauern komplexere Eingabebilder länger.
Texturierung
| API | Texturauflösung | Typische Zeit |
|---|---|---|
| Text to 3D (Refine) | 2K oder 4K | 80 s |
| 8K | 3,5 min | |
| Neutexturierung | 2K | 55 s |
| 4K | 90 s | |
| 8K | 2,5 min |
Bildgenerierung
| API | nano-banana | nano-banana-2 | nano-banana-pro | GPT-Image-Modelle |
|---|---|---|---|---|
| Text zu Bild | 20 s | 15 s | 25 s | 20 bis 35 s |
| Bild zu Bild | 40 s | 20 s | 30 s | 20 bis 40 s |
Rigging und Animation
| API | Konfiguration | Typische Zeit |
|---|---|---|
| Auto-Rigging | Automatisches Rigging | 40 s |
| Animation | Pro Anfrage | 15 s |
| Text to Motion | prime-mode | 15 s |
swift-mode | 10 s |
Nachbearbeitung
| API | Typische Zeit |
|---|---|
| Neuvernetzung | 2 min |
| UV-Entfaltung | 35 s |
| Konvertieren | 7 s |
| Größe ändern | 15 s |
3D-Druck
| API | Konfiguration | Typische Zeit |
|---|---|---|
| Druckbarkeit analysieren | Nur Netzprüfungen | 1 s |
| Netz- und Dünnwandprüfungen | 10 s | |
| Multi-Color | Pro Anfrage | 30 s |
| Druckbarkeit reparieren | Nur Netzreparatur | 10 s |
| Dünnwandprüfung, Wände beibehalten | 20 s | |
| Dünnwandprüfung, Wände verstärkt | 100 s | |
| Auto Split | Pro Anfrage | 70 s |
Bei v2 führen Druckbarkeit reparieren und Druckbarkeit analysieren immer die Dünnwandprüfung aus. Bei v1 wird sie ausgeführt, wenn Sie einen Druckertyp oder eine Druckgröße angeben.
Wie lange warten
Die Aufgabe läuft weiter, auch wenn Ihr Code aufhört zu warten. Wenn Ihre Anfrage ein Timeout erreicht, Ihre Verbindung abbricht oder Ihr Stream schließt, schlägt die Aufgabe dadurch nicht fehl und wird nicht abgebrochen.
- Warten Sie mindestens 60 Minuten, gerechnet ab dem
created_at-Wert der Aufgabe, bevor Sie aufhören zu warten. Wenn Sie früher aufhören, könnten Sie eine Aufgabe verpassen, die später erfolgreich abgeschlossen wird. Dies kommt vor allem in Zeiten hoher Auslastung vor. - Bewahren Sie die Task-ID auf. Sie können die Aufgabe jederzeit erneut abrufen. Wenn sie nach 60 Minuten immer noch nicht final ist, prüfen Sie sie später erneut. Bleibt dieser Zustand bestehen, wenden Sie sich an den Support.
- Nur
FAILEDbedeutet, dass die Aufgabe fehlgeschlagen ist. Meshy erstattet fehlgeschlagene Aufgaben automatisch.
Verwenden Sie diese Werte in Ihrem Code:
| Einstellung | Empfohlener Wert |
|---|---|
Timeout für Erstellungsanfrage (POST) | 60 Sekunden |
Timeout für Erstellungsanfrage (POST) mit einer model_url-Datei über 100 MB | 120 Sekunden. Meshy lädt die Datei herunter, bevor es antwortet. |
Timeout für Statusanfrage (GET) | 30 Sekunden |
| Abfrageintervall | Der Retry-After-Header, oder 5 Sekunden, falls dieser fehlt. Abfragen zählen zu Ihrer Ratenbegrenzung. |
Fehlgeschlagene Statusanfrage (Timeout, 429 oder 5xx) | Versuchen Sie es bei der nächsten Abfrage erneut. Das bedeutet nicht, dass die Aufgabe fehlgeschlagen ist. |
| Gesamtwartezeit pro Aufgabe | Mindestens 60 Minuten ab created_at. Setzen Sie diese Zählung nicht zurück, wenn Sie einen Stream neu verbinden. |
| Stream | Ein Stream kann schließen, bevor die Aufgabe abgeschlossen ist. Schließt er ohne finalen Status, verbinden Sie sich erneut oder wechseln Sie zum Abfragen (Polling). |
Verwenden Sie bei vielen gleichzeitigen Aufgaben Webhooks anstelle von einzelnen Abfragen. Wenn das finale Ereignis einer Aufgabe nach etwa dem Doppelten ihrer typischen Zeit noch nicht eingetroffen ist, rufen Sie die Aufgabe über ihren GET-Endpunkt ab.