FLUX 3 Image API: Leitfaden zu 4K und Multi-Reference-Editing

FLUX 3 Image ist über ein von Black Forest Labs betriebenes Replicate-Modell und mehrere Partner-Endpunkte verfügbar. Unterstützt werden 4K-Ausgabe und Bearbeitungen mit bis zu 10 Referenzbildern. In der nativen Dokumentation von BFL steht weiterhin FLUX 3 Video im Mittelpunkt, während sich die Bildanbieter bei Schema, Limits und Abrechnung unterscheiden.

Ist die FLUX 3 Image API tatsächlich verfügbar?

Ja, die FLUX 3 Image API ist verfügbar – allerdings sollte man den Begriff „offiziell“ genau einordnen. Der stärkste Beleg ist der aktive Eintrag black-forest-labs/flux-3-image auf Replicate, der Black Forest Labs zugeordnet ist. Der Endpunkt akzeptiert Generierungsanfragen, wechselt bei übergebenem Bild in den Editiermodus und bietet 4k als Auflösungswert an.

Der BFL-Hilfeartikel zu FLUX 3 beschreibt ausschließlich das Videomodell. Der separate BFL-eigene Replicate-Eintrag sowie die Partner-Endpunkte bestätigen dagegen die Bildbearbeitung.

Bevor der Endpunkt auftauchte, rechnete der Reddit-Nutzer u/rerri mit einem API-zentrierten Start:

„I wouldn't be surprised if the API-only Flux 3 Image launches first.“ — u/rerri auf r/StableDiffusion

Der Startverlauf passt zu dieser Einschätzung. API-Zugang bedeutet allerdings nicht, dass offene Gewichte verfügbar sind.

Was 4K und Multi-Reference-Editing in der Praxis bedeuten

FLUX 3 Image bietet eine 4k-Ausgabe und akzeptiert bis zu 10 Referenzbilder. Keine dieser Angaben garantiert, dass Identität, Produktdetails oder kleine Textzeilen vollständig erhalten bleiben. Die Providerseiten dokumentieren Funktionen und Beispiele, liefern aber keine unabhängigen Qualitätswerte.

Die Replicate-README von BFL führt 768sq, 1k, 1.5k, 2k und 4k auf. Referenzdateien dürfen im JPEG-, PNG-, GIF- oder WebP-Format vorliegen, müssen mindestens 256 mal 256 Pixel groß sein und dürfen 16 Megapixel nicht überschreiten. Bei aspect_ratio: auto bestimmt die erste Referenz das Seitenverhältnis der Bearbeitung.

Das fal-Editier-Schema ist ähnlich, aber nicht identisch. Es akzeptiert 1–10 URLs oder Data-URIs, begrenzt jede Eingabe auf 4 Megapixel, unterstützt 512sq bis 4k und weist darauf hin, dass 4K mehrere Minuten dauern kann. Die Reihenfolge der Referenzen ist semantisch relevant: „image 1“ bezeichnet das erste Element in image_urls.

Bei Multi-Reference-Bearbeitungen sollte jedes Bild eine klare Rolle bekommen: Basiskomposition, Identität des Motivs, Produkt oder Stil. Auch fal empfiehlt in den eigenen Hinweisen, pro Anfrage nur eine Änderung vorzunehmen. Ein Prompt wie „Use image 1 as the base; replace only the bottle with the product from image 2; preserve camera angle, hands, lighting, and background“ lässt sich wesentlich besser prüfen als eine Anfrage, die zusätzlich Kleidung, Typografie und Schauplatz verändert.

Ein praxistauglicher Workflow mit Queue-API

Ein produktiver FLUX-3-Image-Workflow sollte die Generierung als asynchronen Job behandeln. Die Anwendung lädt stabile Eingabe-URLs hoch, übermittelt eine klar abgegrenzte Anfrage, speichert die Request-ID des Providers, fragt den Status mit wachsendem Intervall ab und kopiert das fertige Ergebnis in den eigenen Speicher.

Das folgende Beispiel verwendet die dokumentierte Endpunkt-ID und die dokumentierten Request-Felder von fal. Es handelt sich um eine Integrationsvorlage, nicht um den Nachweis, dass die Anfrage im Rahmen dieses Tests ausgeführt wurde.

import os
import time
import requests

ENDPOINT = "https://queue.fal.run/blackforestlabs/flux-3/edit-image"
headers = {
    "Authorization": f"Key {os.environ['FAL_KEY']}",
    "Content-Type": "application/json",
}
payload = {
    "prompt": (
        "Use image 1 as the base. Replace only its package with the product "
        "from image 2. Preserve the hands, camera angle, shadows, and background."
    ),
    "image_urls": [
        "https://cdn.example.com/base.jpg",
        "https://cdn.example.com/product.png",
    ],
    "resolution": "1k",
    "aspect_ratio": "auto",
    "output_format": "png",
    "safety_tolerance": 2,
}

submitted = requests.post(ENDPOINT, headers=headers, json=payload, timeout=30)
submitted.raise_for_status()
job = submitted.json()

status_url = job["status_url"]
response_url = job["response_url"]
while True:
    status = requests.get(status_url, headers=headers, timeout=30)
    status.raise_for_status()
    state = status.json().get("status")
    if state == "COMPLETED":
        break
    if state in {"FAILED", "CANCELLED"}:
        raise RuntimeError(status.text)
    time.sleep(2)

result = requests.get(response_url, headers=headers, timeout=30)
result.raise_for_status()
print(result.json())

Die auf der Modellseite verlinkte fal-Queue-Dokumentation bietet ebenfalls sync_mode. Für 4K ist die Ausführung über eine Queue jedoch die sicherere Voreinstellung, da ein Render länger dauern kann als das Timeout einer normalen HTTP-Anfrage. Layer macht diesen asynchronen Vertrag explizit: Die Übermittlung liefert HTTP 202, eine inference_id und ein empfohlenes Abfrageintervall zurück. Außerdem unterstützt Layer Idempotency-Keys, die 24 Stunden lang erneut verwendet werden können. Das hilft, doppelte Abrechnungen nach Netzwerkfehlern zu vermeiden.

Vor dem produktiven Einsatz:

1. Bilder mit weniger als 256 Pixeln pro Seite ablehnen und das Megapixel-Limit des jeweiligen Providers erzwingen.
2. Die Reihenfolge der Arrays beibehalten und Prompts erzeugen, die sich auf image 1, image 2 und so weiter beziehen.
3. Wenn der Provider dies unterstützt, einen eindeutigen Idempotency-Key verwenden; andernfalls die Anfrage vor einem Retry persistieren.
4. Die maximale Polling-Zeit begrenzen und statt einer dauerhaft offenen Anfrage einen ausstehenden Status anzeigen.
5. Fertige Dateien in einen kontrollierten Speicher kopieren, da gehostete Ergebnis-URLs möglicherweise nicht zur Aufbewahrungsrichtlinie der Anwendung passen.
6. Für jeden Job Modell-ID, Provider, Auflösung, Zahl der Referenzen, angegebenen Preis, verstrichene Zeit und Moderationsergebnis protokollieren.

Die realistische Abwägung zwischen Kosten und Qualität

Ein belastbarer Kostenvergleich ist nur eingeschränkt möglich, weil die geprüften Providerseiten keine vollständige Tabelle mit Preisen pro Auflösung veröffentlichten. fal nannte für 1K einen Aktionspreis von 0,024 $ pro Bild, der nach der Aktion auf 0,048 $ steigt. Außerdem wurde angegeben, dass die Zahl der Referenzen den Preis nicht verändert. Konkrete Preise für 2K und 4K waren auf der Modellseite nicht aufgeführt. Ein 4K-Budget lässt sich daher nicht aus dem 1K-Preis ableiten.

Statt grundsätzlich 4K zu verwenden, ist ein zweistufiger Prozess sinnvoll:

Eine höhere Auflösung liefert mehr Pixel, aber keine bessere Editiergenauigkeit. Aus einer schlechten 1K-Bearbeitung wird bei 4K lediglich ein größerer Fehler. 4K sollte für freigegebene Bearbeitungen reserviert bleiben, die für den Druck, Billboard-Layouts oder starke Ausschnitte bestimmt sind.

Beim Start der Anwendung sollte ein minimaler gültiger Testjob übermittelt oder die Preisschnittstelle des Providers abgefragt werden. Den zurückgegebenen Preis erfassen und 4K deaktivieren, wenn kein Preis vorliegt oder das Jobbudget überschritten wird. Die erste Antwort von Layer kann estimated_price_creative_units enthalten; die öffentliche Modellseite lieferte jedoch keine Umrechnung in Dollar. Die abgerufene Replicate-Modellseite dokumentierte Eingaben, aber keinen festen Preis. Das sind Beschaffungslücken, die vor dem Launch im Account-Dashboard geklärt werden müssen – keine Werte, die man im Code schätzen sollte.

Den Endpunkt nach dem operativen Bedarf auswählen

Die Wahl des Providers sollte sich nach dem Vertrag richten, den die Anwendung benötigt. Nur weil zwei Anbieter dasselbe Modell nennen, sind ihre Schemas noch lange nicht austauschbar.

• Replicate: Die BFL-eigene Variante ist sinnvoll, wenn die Herkunft des Modells Priorität hat und der Stack bereits den Prediction-Workflow von Replicate verwendet. Sie dokumentiert hier mit 16 MP das großzügigste Eingabelimit und bietet optionales Web-/Bild-Grounding.
• fal: Der Partner-Endpunkt passt, wenn klar definierte Bildbearbeitungsoptionen, ein Queue-Workflow und ein sichtbarer 1K-Preis wichtiger sind. Das Eingabelimit von 4 MP erfordert allerdings eine frühere Verkleinerung.
• Layer: Layer eignet sich für Workspace-Organisation, einen formal definierten HTTP-202-Vertrag, Hinweise zum Polling und 24-stündige Idempotenz. Vor der Budgetplanung muss geklärt werden, wie Creative Units in Dollar umgerechnet werden.

Ein Anbieter sollte nicht allein anhand des Begriffs „FLUX3“ in einer Domain oder einem Repository identifiziert werden. Prüfe stattdessen Modell-ID, Eigentümer- oder Partnerkennzeichnung, aktuelle Enum-Werte, kommerzielle Bedingungen und eine erfolgreiche Anfrage mit niedrigen Kosten. Der gut platzierte Anil-matcha/Flux-3-Dev-API-Wrapper kennzeichnete seine Bildrouten zum Prüfzeitpunkt weiterhin als „coming soon“, während die BFL-eigene Replicate-Route und die fal-Partnerroute aktiv waren.

Checkliste für den Produktivstart

FLUX 3 Image eignet sich für kontrollierte API-Tests, einschließlich 4K und bis zu 10 Referenzen. Ausgerollt werden sollte die Lösung erst, wenn der ausgewählte Endpunkt denselben repräsentativen Testsatz sowohl in 1K als auch in der finalen Auflösung besteht.

Die praktische Empfehlung lautet, zunächst mit 1K-Bearbeitungen zu starten, Preis- und Latenzdaten zu protokollieren und 2K oder 4K erst für freigegebene finale Assets zu aktivieren. So bleiben die am besten dokumentierten Funktionen des neuen Modells verfügbar, ohne ungeprüfte Annahmen zu Qualität oder Kosten bei hoher Auflösung zu treffen.

Weiterführende Artikel

• FLUX 3 im Überblick
• Vergleich der günstigsten APIs für Bildgenerierung