API d’images FLUX 3 : guide de la 4K et des références multiples

FLUX 3 Image est désormais accessible via un modèle Replicate détenu par Black Forest Labs et plusieurs endpoints partenaires. Il prend en charge la sortie 4K et l’édition à partir de 10 références maximum. La documentation native de BFL reste toutefois centrée sur FLUX 3 Video, tandis que les fournisseurs d’images appliquent leurs propres schémas, limites et règles de facturation.

L’API d’images FLUX 3 est-elle vraiment disponible ?

Oui, l’API d’images FLUX 3 est disponible, mais le terme « officielle » mérite d’être précisé. L’indice le plus solide est la fiche active black-forest-labs/flux-3-image, détenue par Black Forest Labs sur Replicate. Elle accepte les requêtes de génération, passe en mode édition lorsqu’une image est fournie et propose 4k comme valeur de résolution.

L’article d’aide de BFL consacré à FLUX 3 ne décrit que le modèle vidéo. En revanche, la fiche Replicate détenue par BFL et les endpoints partenaires confirment bien la disponibilité de l’édition d’images.

Avant l’apparition de l’endpoint, l’utilisateur Reddit u/rerri anticipait une sortie d’abord centrée sur l’API :

« Je ne serais pas surpris que Flux 3 Image soit d’abord lancé uniquement via une API. » — u/rerri sur r/StableDiffusion

Le déploiement correspond à cette prédiction. En revanche, l’accès à l’API ne signifie pas que les poids du modèle sont disponibles librement.

Ce que changent concrètement la 4K et l’édition avec plusieurs références

FLUX 3 Image propose une sortie 4k et accepte jusqu’à 10 images de référence. Cela ne garantit pas pour autant la conservation parfaite de chaque identité, détail produit ou petite ligne de texte : les pages des fournisseurs documentent des contrôles et des exemples, pas des scores de qualité indépendants.

Le README Replicate détenu par BFL répertorie 768sq, 1k, 1.5k, 2k et 4k. Les fichiers de référence peuvent être au format JPEG, PNG, GIF ou WebP, mesurer au moins 256 par 256 pixels et ne pas dépasser 16 mégapixels. Avec aspect_ratio: auto, c’est la première référence qui détermine le ratio de l’édition.

Le schéma d’édition de fal est proche, mais pas identique. Il accepte 1 à 10 URL ou data URI, limite chaque entrée à 4 mégapixels, prend en charge les résolutions de 512sq à 4k et prévient qu’un rendu 4K peut prendre plusieurs minutes. L’ordre des références a une signification : « image 1 » désigne le premier élément de image_urls.

Pour les éditions avec plusieurs références, attribuez un rôle précis à chaque entrée : composition de base, identité du sujet, produit ou style. Les recommandations de fal préconisent d’effectuer une seule modification par requête. Un prompt comme « Utilise l’image 1 comme base : remplace uniquement la bouteille par le produit de l’image 2 et conserve l’angle de prise de vue, les mains, la lumière et l’arrière-plan » est plus facile à contrôler qu’une demande qui modifie en même temps la tenue, la typographie et le lieu.

Mettre en place un workflow API avec file d’attente

En production, une API FLUX 3 Image doit être traitée comme un système de tâches asynchrones. L’application envoie des URL d’entrée stables, soumet une requête ciblée, conserve l’identifiant fourni par le fournisseur, interroge l’état avec un délai progressif, puis copie le résultat final dans son propre stockage.

L’exemple ci-dessous utilise l’identifiant d’endpoint et les champs documentés par fal. Il s’agit d’un modèle d’intégration, pas d’une preuve que cette requête a été exécutée pendant cette revue.

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())

La documentation de la file d’attente fal accessible depuis la page du modèle expose également sync_mode, mais l’exécution en file d’attente reste le choix le plus sûr en 4K, car un rendu peut dépasser le délai d’expiration habituel d’une requête HTTP. Layer formalise ce fonctionnement asynchrone : la soumission renvoie HTTP 202, un inference_id et un intervalle d’interrogation recommandé. Layer prend aussi en charge des clés d’idempotence réutilisables pendant 24 heures, ce qui limite les doubles facturations après une nouvelle tentative réseau.

Avant d’ouvrir le trafic :

1. Refusez les images de moins de 256 pixels par côté et appliquez la limite de mégapixels du fournisseur sélectionné.
2. Conservez l’ordre du tableau et rédigez les prompts en faisant référence à image 1, image 2, etc.
3. Utilisez une clé d’idempotence unique lorsque le fournisseur le permet ; sinon, persistez la requête avant de la relancer.
4. Limitez la durée des interrogations et exposez un état en attente au lieu de maintenir ouverte une requête applicative.
5. Copiez les fichiers terminés dans un stockage contrôlé, car les URL de résultats hébergées peuvent ne pas respecter la politique de conservation de l’application.
6. Journalisez pour chaque tâche l’ID du modèle, le fournisseur, la résolution, le nombre de références, le coût annoncé, le temps écoulé et le résultat de la modération.

Le vrai compromis entre coût et qualité

La comparaison des coûts reste limitée : les fournisseurs n’avaient pas publié de grille complète par résolution sur les pages vérifiées. fal affichait un tarif promotionnel de 0,024 $ par image en 1K, qui devait passer à 0,048 $ après la promotion. Le fournisseur précisait également que le nombre de références ne modifiait pas le prix. Les tarifs exacts en 2K et 4K n’étaient pas indiqués sur cette page modèle : impossible donc de déduire un budget 4K à partir du tarif 1K.

Mieux vaut adopter une stratégie en deux étapes que de considérer la 4K comme le meilleur réglage par défaut :

Une résolution supérieure apporte des pixels, pas une meilleure fidélité d’édition : une mauvaise édition en 1K devient simplement un échec plus grand en 4K. Réservez la 4K aux éditions validées destinées à l’impression, aux affiches grand format ou aux recadrages importants.

Au démarrage de l’application, envoyez une tâche de test minimale et valide ou interrogez la grille tarifaire du fournisseur. Enregistrez le montant annoncé et désactivez la 4K si le tarif est absent ou dépasse le budget prévu pour la tâche. La réponse initiale de Layer peut inclure estimated_price_creative_units, mais sa page modèle publique ne fournit pas de conversion en dollars. La page Replicate consultée documentait les paramètres d’entrée, sans prix fixe. Ces zones d’ombre doivent être clarifiées dans le tableau de bord du compte avant le lancement : ce ne sont pas des chiffres à deviner dans le code.

Choisir l’endpoint selon les besoins opérationnels

Le choix du fournisseur doit découler du contrat dont votre application a besoin. Le fait de partager le même modèle ne rend pas les schémas interchangeables.

• Replicate : choisissez la fiche détenue par BFL si la provenance est prioritaire et que votre stack utilise déjà le workflow de prédictions de Replicate. C’est ici que la limite d’entrée documentée est la plus généreuse, avec 16 MP, et l’endpoint inclut des options facultatives de grounding web/image.
• fal : choisissez l’endpoint partenaire d’édition si vous privilégiez des contrôles d’édition clairs, un workflow en file d’attente et un tarif 1K visible. Sa limite d’entrée de 4 MP impose de réduire les images plus tôt.
• Layer : choisissez-le pour l’organisation en espaces de travail, le contrat HTTP 202, les indications de polling et l’idempotence pendant 24 heures. Vérifiez la conversion des Creative Units en dollars avant de fixer un budget.

Ne déduisez pas l’identité d’un fournisseur de la présence de « FLUX3 » dans son domaine ou le nom de son dépôt. Vérifiez l’ID du modèle, la mention du propriétaire ou du partenaire, les valeurs d’enum actuelles, les conditions commerciales et la réussite d’une requête peu coûteuse. Le wrapper Anil-matcha/Flux-3-Dev-API, qui apparaissait haut dans les résultats, indiquait encore que ses routes d’image étaient « à venir » au moment de la vérification, alors que les endpoints Replicate détenu par BFL et fal partenaire étaient actifs.

La checklist avant mise en production

FLUX 3 Image convient à des tests API contrôlés, notamment en 4K et avec jusqu’à 10 références. Ne passez en production qu’après avoir soumis au même endpoint un jeu représentatif d’éditions, en 1K puis dans la résolution finale.

La recommandation la plus pragmatique consiste à commencer par l’édition en 1K, à journaliser les tarifs annoncés et la latence, puis à activer la 2K ou la 4K uniquement pour les livrables finaux validés. Vous bénéficiez ainsi des capacités les mieux documentées du nouveau modèle, sans supposer à tort que la qualité ou le coût en haute résolution sont déjà prévisibles.

À lire aussi

• Présentation du produit FLUX 3
• Comparatif des API de génération d’images les moins chères