FLUX 3 Klein promet 8 GB de VRAM. Les fichiers disent autre chose

Black Forest Labs a publié FLUX 3 Image Klein le 15 octobre, et le chiffre qui sert de titre est 8. Huit, comme 8 GB de VRAM, censément de quoi faire tourner un modèle image de 5.6 milliards de paramètres avec sortie 4K native, dix images de référence et un contrôle de mise en page par boîtes englobantes. Pour qui a passé deux ans à voir les modèles image ouverts exiger une carte de 24 GB et une prière, cela ressemble à la fin d'une longue attente.

Ce chiffre est aussi, de la manière dont ces chiffres le sont d'ordinaire, exact sur le plan technique et trompeur sur le plan pratique. Les deux moitiés de la phrase méritent qu'on s'y arrête, parce que Klein est réellement intéressant et que l'écart entre son argumentaire et la taille de ses fichiers dit beaucoup de l'état réel de la génération d'images en local.

Ce qui est sorti

Klein est le membre à poids ouverts de la famille FLUX 3. Le modèle FLUX 3 Image arrivé le 1er octobre était réservé à l'API ; Klein est celui qu'on peut télécharger. Son architecture est un transformer d'images de 5.6 milliards de paramètres, associé à un encodeur de texte Qwen3-VL 4B sous licence Apache 2.0 — détail qui vaut d'être noté, puisque les poids principaux ne sont pas Apache.

Trois capacités tiennent dans un seul jeu de poids : texte-vers-image, édition à partir d'une référence unique, et génération multi-références avec jusqu'à dix images dans un prompt. C'est la limite de références qui compte pour la production. S'il faut garder le même acteur, le même costume et le même accessoire d'un plan à l'autre, dix emplacements suffisent pour assigner un rôle à chaque référence au lieu d'espérer qu'une planche d'ambiance s'additionne correctement.

Le contrôle de mise en page repose sur des boîtes englobantes dans une grille 0-to-1000 grid. On dessine une zone, puis on demande au modèle de placer, recolorer, déplacer, remplacer ou supprimer ce qu'elle contient. L'interaction n'a rien à voir avec le prompt-et-prière. Elle tient plutôt de l'outil de mise en page, et c'est pourquoi cette sortie se lit moins comme un lancement de modèle que comme l'ajout d'une fonction à un flux de design.

BFL livre aussi deux checkpoints. Un distillé, 16 étapes sans guidance, destiné à l'inférence. Un base, 50 étapes à CFG 3.5, destiné à l'entraînement — la fiche modèle précise noir sur blanc que le checkpoint distillé est un mauvais point de départ pour du fine-tuning. La recette LoRA documentée entraîne sur Base et sert sur Distilled, et comme les deux partagent la même architecture, l'adaptateur se charge sans conversion. Dans l'exemple chiffré de BFL, un LoRA de style sur vingt peintures du domaine public légendées, en rank 32, a demandé environ 4.5 heures sur un seul GPU.

L'argument des 8 GB, poste par poste

Voici l'arithmétique que l'annonce ne fait pas à votre place. Le dépôt ComfyUI liste les fichiers des composants.

Le transformer pèse 11.1 GB en BF16, 5.8 GB en INT8. L'encodeur de texte Qwen3-VL fait 8.9 GB en BF16, 4.9 GB en INT8. Le VAE, 0.3 GB. Et il y a le prompt upsampler, un modèle dérivé de Qwen3.5-9B, à 18.8 GB en BF16 ou 9.8 GB en INT8.

Prenez les deux plus gros blocs en INT8 : 5.8 plus 4.9 font 10.7 GB de poids avant qu'une seule activation soit allouée. Une carte de 8 GB ne peut pas contenir les deux. L'argument des 8 GB suppose donc de décharger l'un des deux vers la RAM système, ce qui fonctionne, et c'est aussi pourquoi la fiche du constructeur mesure un pic de 31 GB en BF16 et de 26 GB en FP8 en 1024×1024 sur une B200 — upsampler désactivé.

Cette dernière précision pèse plus qu'elle n'en a l'air. La fiche indique clairement qu'un prompt court saisi tel quel produit une sortie générique et que l'upsampler est nécessaire pour de bons résultats. Or l'upsampler réclame environ 28 GB en pleine précision sur une carte de 80 GB. Ce n'est pas un composant de luxe optionnel : il fait partie de la façon dont le modèle est censé être utilisé, et il est à peu près de la taille du modèle lui-même.

Le résumé honnête est donc celui-ci : 8 GB vous offrent une exécution, en INT8, avec déchargement agressif, à vitesse réduite, et sans doute avec un chemin de prompt plus faible. Pas l'expérience de la vidéo de lancement.

Ce que les chiffres de vitesse disent, et ne disent pas

BFL annonce environ quatre secondes pour une image d'un mégapixel sur une RTX 5090, et moins de neuf secondes sur une RTX 4070. Ce sont de bons chiffres. Ils sont aussi mesurés sur le checkpoint distillé, avec les réglages choisis par BFL, pour une image unique, hors chargement du modèle. Si votre flux enchaîne plusieurs modèles — un upscaler, une passe d'inpainting, une restauration de visage — le temps réel par visuel fini sera plusieurs fois supérieur.

Le constructeur affirme en outre que Klein dépasse plusieurs modèles ouverts plus gros sur les benchmarks de texte-vers-image, de multi-références et d'édition. Cette affirmation n'est pas vérifiée par des tiers à l'heure où nous écrivons, et les comparaisons internes au lancement sont le genre de benchmark le moins fiable. Les classements indépendants existants placent Klein au milieu du peloton sur l'esthétique brute et nettement mieux sur le respect des consignes d'édition, ce qui correspond aux priorités de conception.

La licence, la partie que tout le monde saute

Les poids de Klein sont sous FLUX Kommunity License, pas sous Apache 2.0. Les droits de sortie commerciale sont accordés aux personnes et aux entreprises dont le chiffre d'affaires annuel brut, affiliés compris, reste sous 5 millions de dollars. Au-delà, il faut une licence commerciale de BFL, ou passer par l'API.

Pour un designer indépendant, un petit studio ou un vidéaste qui monte un clip, c'est une vraie autorisation. Pour une agence qui vient de franchir le seuil, c'est une ligne de conformité qui ressortira lors d'un audit deux ans plus tard. « Poids ouverts » et « open source » sont employés comme synonymes dans la plupart des articles consacrés à cette sortie, et ce ne sont pas la même chose.

Il y a aussi une inversion des prix qui mérite un calcul. L'API démarre autour de 0.008 à 0.009 dollar l'image. À mille images par mois, cela fait moins de dix dollars. Une carte de 24 GB coûte plus de mille. Héberger Klein soi-même n'a de sens financier qu'à des volumes où la facture d'API devient le plus gros chiffre, ou dans les cas où les images ne peuvent pas quitter votre machine.

Qui devrait vraiment le télécharger

Si votre travail exige la cohérence d'un personnage ou d'un produit sur une série d'images — storyboards, catalogue où un même objet apparaît dans vingt scènes, bande dessinée où le même visage revient à chaque case — les dix références et le contrôle par boîtes de Klein sont l'outil le plus direct disponible aujourd'hui en poids ouverts. Cette combinaison est réellement nouvelle à cette échelle.

Si votre travail consiste à produire une seule belle image d'accroche, l'API est moins chère, plus rapide et meilleure que ce que donnera votre installation locale.

Si vous voulez des poids locaux pour des raisons de confidentialité — médical, juridique, produit non annoncé — c'est le pic de 31 GB en BF16 qu'il faut prendre comme base de planification, pas huit. Prévoyez une carte de 32 GB, ou attendez les quantifications GGUF de la communauté, qui arrivent toujours en un mois ou deux.

Le schéma est constant depuis deux ans sur les modèles image ouverts : l'annonce cite l'empreinte la plus faible possible, la fiche modèle cite la vraie, et la communauté comble l'écart avec des versions quantifiées qui échangent un peu de qualité contre beaucoup de marge. Klein suit ce schéma à la lettre. Savoir quel chiffre vous concerne, c'est l'essentiel de la décision.