Aufgabenübermittlung und Polling
Die Übermittlungs-Endpunkte sind allesamt asynchrone Aufgaben: Nach dem Absenden wird einetask_id zurückgegeben; danach wird über GET /v1/midjourney/{task_id} periodisch der Status abgefragt, bis SUCCESS / FAILURE erreicht ist.
- Polling-Takt: Empfohlen alle 3–5 s; höhere Frequenz ist sinnlos und verschwendet Kontingent.
- Nicht synchron im Web-Request blockieren, bis die Aufgabe fertig ist – nach dem Absenden sofort die
task_idzurückgeben und das Frontend asynchron pollen lassen.
Prompt-Design
Guter Prompt:- Motiv zuerst: erst das Motiv, dann die Szene beschreiben, zuletzt die Modifikatoren.
- Strukturierte Parameter explizit angeben:
--ar/--v/--s(oder die entsprechenden Body-Felder) zu verwenden ist kontrollierbarer als auf Standardwerte zu vertrauen. - Mehrdeutige Wörter vermeiden:
photorealisticist eindeutiger alsrealistic.
niji: true + version: "7" übergeben; die Plattform normalisiert dies zu --niji 7, die Abrechnung läuft über midjourney@imagine-niji7.
Best Practices für bildgesteuerte Generierung
| Quelle | Empfohlene Vorgehensweise | Hinweis |
|---|---|---|
| Benutzer-Upload | Zuerst im eigenen OSS / CDN speichern, beim Absenden diese URL übergeben | Nicht direkt base64 übergeben (verschwendet Bandbreite) |
| Öffentliche URL | Direkt übergeben | SSRF beachten (muss öffentlich erreichbar sein) sowie das 12-MiB-Limit |
| Drittanbieter / andere Artefakte | Zuerst ins eigene OSS umlagern | Drittanbieter-URLs können ablaufen |
- Auf < 5 MiB komprimieren: Das Plattform-Limit liegt bei 12 MiB, aber kleinere Bilder werden schneller übertragen und verarbeitet.
- Die Formate PNG / JPG / WebP sind alle möglich, empfohlen wird hochwertiges JPG.
- Eine Auflösung von 1024–2048 px reicht aus; höher ist Verschwendung.
- Bildgewicht
iw(0–3, Standard 1): >1 näher am Original, <1 freier.
Fehlerbehandlung und Retry-Strategie
| code | Bedeutung | Retry-Strategie |
|---|---|---|
1 / 200 | Erfolg | ✅ |
4 VALIDATION_ERROR | Parameterfehler | ❌ Nicht erneut versuchen, Parameter korrigieren |
3 NOT_FOUND | Keine verfügbare Instanz / task_id existiert nicht | Bei nicht verfügbarer Instanz später erneut versuchen; bei nicht existierender task_id nicht erneut versuchen |
9 FAILURE | Ablehnung durch den Dienst / interner Fehler | ⏳ Erneut versuchbar, exponentielles Backoff (1s, 4s, 16s) |
21 MODAL | Nicht-Endzustand | ✅ Weiter /modal aufrufen |
24 BANNED_PROMPT | Sensibles Wort | ❌ Nicht erneut versuchen, Prompt ändern; bereits automatisch erstattet |
429 | Drosselung | ⏳ Exponentielles Backoff + Jitter |
5xx / Netzwerkfehler | Serverseitig / Netzwerk | ⏳ Exponentielles Backoff; bei Netzwerkfehler 1-mal sofort erneut versuchbar |
Ablauf von Folgeoperationen
⚠️ Nachdem inpaint in MODAL übergegangen ist, muss /modal innerhalb von 30 Minuten aufgerufen werden, sonst wird im Hintergrund automatisch CANCEL + Erstattung ausgelöst.
Abrechnungssteuerung bei video
- Einzelclip:
batch_size: 1→ Abzug 1 ×midjourney@video - Stapel von 4 Clips:
batch_size: 4→ Abzug 4 ×midjourney@video - HD-Einzelclip:
video_type: "vid_1.1_i2v_720"+batch_size: 1→ Abzug 1 ×midjourney@video-720p
batch_size=1 verwenden; 4 nur für Stapel-Entwürfe nutzen und nicht standardmäßig auf 4 stellen (vervielfacht die Kosten um das N-fache).
Nebenläufigkeit und Durchsatz
- Die Plattform hat eine Obergrenze für die Anzahl der Übermittlungen pro Minute; bei Überschreitung wird
429zurückgegeben und ein Retry mit Backoff ist nötig. - Die tatsächliche Generierungs-Nebenläufigkeit wird durch die Systemkapazität bestimmt; bei Überschreitung wird die Aufgabe in eine Warteschlange gestellt; bleibt eine Aufgabe lange bei
SUBMITTED, liegt das meist an der Warteschlange. - Beim Polling unbedingt
sleepeinbauen; keine Endlosschleife ohne sleep.
Monitoring-Empfehlungen
| Kennzahl | Referenzschwelle | Bedeutung |
|---|---|---|
| SUCCESS-Rate der Aufgaben (letzte 1 h) | > 95% | Niedrig deutet auf Dienst-/Netzwerkanomalien hin |
| Durchschnittliche Fertigstellungsdauer | < 90s | Hoch deutet auf eine Warteschlange hin |
| Anzahl in MODAL verweilender Aufgaben | nahe 0 | Viele deuten darauf hin, dass der Client /modal nicht aufgerufen hat |
Anteil code=24 | < 5% | Hoch deutet darauf hin, dass der Prompt häufig sensible Wörter auslöst |
Checkliste zur Fehlerbehebung
| Symptom | Untersuchungsrichtung |
|---|---|
Aufgabe lange bei SUBMITTED | System in der Warteschlange, später erneut abfragen |
Aufgabe lange bei NOT_START | Die Plattform löst später automatisch einen Timeout mit Erstattung aus, kein manuelles Eingreifen nötig |
Aufgabe MODAL über 30 Minuten | Client hat /modal nicht aufgerufen, wurde bereits automatisch CANCEL + Erstattung |
Feld prompt leer | Das Textergebnis einer describe-Aufgabe steht im Feld description |
Ein Bild fehlt in image_urls | Inhaltsprüfung hat einen Teil der Bilder blockiert, siehe fail_reason |
| Abrechnung höher als erwartet | Feld quota prüfen; bei video an × batch_size denken |