MOSS-Image vs Meta Muse Image : deux théories du contrôle, dont l'une coûte un centime

La manière la plus utile de comparer M​OSS-Image à M​eta M​use Image est de remarquer que les deux sont vendus sur l'idée de contrôle, et qu'ils entendent par là des choses opposées. M​eta M​use Image, lancé le 7 juillet 2026 et accessible via l'API Model de M​eta sous muse-image-1.0 à un tarif fixe de 0,01 $ par image générée, contrôle la sortie en raisonnant avant de générer — il invoque des outils de recherche et de codage, s'affine lui-même et s'améliore avec davantage de calcul à l'inférence. M​OSS-Image, publié le 16 octobre 2026 sous licence Apache 2.0 avec des poids ouverts, contrôle la sortie en refusant de deviner : vous lui donnez un objet JSON avec des boîtes englobantes, des chaînes littérales et des notes typographiques, et il génère cette spécification. Un modèle réfléchit davantage. On dit à l'autre exactement quoi faire.

Ce ne sont pas deux réglages d’un même cadran. Ce sont deux paris différents sur l’endroit où réside la difficulté de la génération d’images, et le pari que vous devriez prendre dépend de si votre problème est que vous ne savez pas décrire ce que vous voulez, ou que vous le savez exactement et que le modèle continue de vous ignorer.

Les deux théories, énoncées correctement

La théorie de Meta est que la génération échoue parce que le modèle n'en sait pas assez. Sa page de modèle décrit Muse Image comme « un modèle d'image qui raisonne avant de générer », et l'article de lancement rend le mécanisme explicite : « Au lieu d'associer directement les prompts aux images, Muse Image fonctionne comme un agent : il fait appel à des outils de recherche et de codage pour améliorer la précision, affine lui-même ses propres générations, et s'améliore en augmentant le calcul au moment du test. » Selon cette théorie, un meilleur résultat vient de davantage de réflexion, de davantage de récupération et de davantage d'auto-vérification.

La théorie d'OpenMOSS est que la génération échoue parce que le modèle ne sait pas où placer les choses. Sa réponse consiste à supprimer entièrement l'ambiguïté du prompt — la mise en page n'est pas déduite de la prose, elle est fournie sous forme de données. L'ablation du rapport lui-même sur RealLayoutArena est l'énoncé le plus clair du pari : les prompts de mise en page JSON obtiennent un score de 1 622,87 sur le même système où les prompts en langage naturel obtiennent 1 506,20. C'est un écart de 117 points attribuable à l'interface plutôt qu'aux poids.

Le test permettant de savoir quelle théorie s’applique à vous tient en une seule question. Si vous pouvez dessiner la mise en page que vous voulez sur une serviette en papier et tendre cette serviette à quelqu’un, c’est l’approche de MOSS-Image qui fonctionnera. Si vous ne pouvez pas — si la demande est « faites-moi quelque chose qui ait l’air juste pour cette marque » et que vous reconnaîtriez la réponse en la voyant — alors un modèle de raisonnement a de quoi raisonner et une spécification de mise en page n’a rien à quoi s’ancrer.

Ce qu'est M​eta M​use Image, et ce que cela coûte

Muse Image est le modèle agentique de génération et d'édition d'images de Meta, propriétaire plutôt qu'à poids ouverts, servi sur la même API et avec la même authentification que Muse Spark, le modèle de raisonnement de Meta — un appariement que Meta documente comme permettant « aux deux modèles de partager des outils et de planifier conjointement pour une puissante génération de médias agentique ». Le résultat documenté de cet appariement est un média en plusieurs parties : des GIF animés, des pages avec des images intégrées, de petits jeux interactifs.

La surface de capacités se décline en quatre modes dont les noms figurent sur sa page de modèle : génération d'images, édition précise, composition ancrée et affinage multi-tours. Les promesses qui la distinguent portent sur la retenue plutôt que sur le résultat. M​eta affirme que le modèle « est conçu pour modifier exactement ce que vous spécifiez et laisser tout le reste intact », et le mode de composition ancrée ancre « toute une série de générations sur un petit ensemble d'images de référence afin que le personnage, le style et le décor restent cohérents d'une image à l'autre » — la capacité qui compte pour un catalogue ou un ensemble d'annonces plutôt que pour une image unique. Côté développeur, il existe un reasoning_strength contrôle avec des réglages haut et bas, et output_format est défini par défaut sur WebP.

Le prix est l’élément qui rend ce comparatif délicat pour quiconque compare les coûts. Meta facture 0,01 $ par image générée, forfaitairement, et indique que l’ancrage de recherche est inclus dans ce prix plutôt que facturé séparément à l’usage. Il n’y a pas de palier de résolution, pas de comptabilisation de jetons et pas de remise par lot à modéliser. Pour une équipe qui a été échaudée par une facturation au pixel qui évolue discrètement avec la taille de la sortie, un centime forfaitaire représente une structure commerciale réellement différente.

Ce que M​eta ne publie pas, c’est un benchmark. Il n’y a pas de score de suivi d’instructions, ni de mesure de fidélité d’édition, ni d’évaluation indépendante de l’affirmation de raisonnement avant rendu. L’ensemble de capacités ci-dessus est décrit par le fournisseur, et le seul signal tiers disponible pour la gamme d’images M​eta est le tableau des préférences humaines d’Arena, où M​use Image figure derrière les leaders actuels — y compris derrière M​AI-Image-2.6 Preview.

Ce qu'est MOSS-Image, et ce qu'il coûte

M​OSS-Image est un transformateur de diffusion single-stream de 5B, profond de 42 blocs conjoints, d'une largeur cachée de 3 072, avec 24 têtes de 128 dimensions, doté d'un encodeur de texte Qwen3.5-9B gelé et d'un VAE FLUX.2 gelé chargé depuis FLUX.2-klein-4B avec 32 canaux latents. Les checkpoints Base et SFT sont sur Hugging Face sous Apache 2.0, aussi bien les poids que le code de pipeline autonome, sans seuil de chiffre d'affaires ni palier commercial distinct. Le dépôt SFT fait environ 27,2 Go, dont environ 16,8 Go pour l'encodeur de texte.

Son interface de mise en page utilise des coordonnées en pixels absolus mesurées depuis le centre du canevas — bbox_format "yxyx" — plutôt que la convention de coordonnées relatives qu'utilisent plusieurs autres systèmes de mise en page. L'argument du fournisseur en faveur des pixels absolus est qu'ils résistent mieux au travail multi-résolution, et c'est un argument solide, mais cela signifie aussi qu'adopter le modèle implique de réécrire toute logique de prompt que vous avez déjà.

Les preuves rattachées à l’affirmation sont substantielles et entièrement rédigées par le fournisseur. Sur 7Bench, que le rapport présente également, MOSS-Image rapporte un IoU de mise en page moyen de 0,88 contre 0,44 pour Ideogram 4.0, 0,33 pour Nano Banana Pro et Seedream 5.0 Pro, 0,31 pour Qwen Image 3.0 Pro et 0,30 pour GPT Image 2, avec un AUC de mise en page de 0,70 contre une plage allant de 0,16 à 0,20. Sur LongLongTextBench, il rapporte 96,3 Mean-6, soit 97,1 en anglais et 92,4 en chinois — avec GPT Image 2 à 99,0 et Nano Banana Pro à 96,6 dans le même tableau. Sur RealLayoutArena de bout en bout, il est deuxième avec 1 698,70 Elo, et premier avec 1 807,34 lorsque la comparaison est restreinte au backbone sous des prompts en langage naturel partagés.

Une mise en garde doit accompagner ces chiffres, car elle change ce qu’ils mesurent. Le rapport indique clairement que son module d’amélioration de prompt, LayoutPE, utilise G​PT-6 avec des instructions de tâche modulaires au moment de l’inférence, et la compétence d’amélioration de prompt fournie est décrite comme conçue pour les agents de la famille G​PT-6. Le résultat de bout en bout le plus solide est donc un pipeline à deux modèles dont la moitié consacrée aux spécifications s’exécute sur l’API d’un tiers.

Ligne par ligne

• Sortie — M​eta M​use Image le 7 juillet 2026 ; M​OSS-Image le 16 octobre 2026

• Prix — M​eta M​use Image : 0,01 $ par image générée, tarif fixe, ancrage par recherche inclus ; M​OSS-Image téléchargeable gratuitement avec une empreinte d'environ 27,2 GB, en plus de votre propre temps GPU.

• Licences — M​eta M​use Image est propriétaire, uniquement via API ; M​OSS-Image est sous Apache 2.0 pour les poids et le code de pipeline autonome

• Identifiant du modèle — muse-image-1.0 sur l'API Model propre à M​eta ; OpenMOSS-Team/M​OSS-Image-Base et OpenMOSS-Team/M​OSS-Image-SFT sur Hugging Face et ModelScope

• Mécanisme de contrôle — M​eta M​use Image raisonne avant le rendu, invoquant des outils de recherche et de codage et s'auto-affinant ; M​OSS-Image effectue le rendu d'une disposition JSON fournie avec des boîtes englobantes, des chaînes et des notes typographiques

• Contrôle du raisonnement — Meta expose un réglage reasoning_strength de high ou low ; MOSS-Image n'a aucun composant de raisonnement du tout, par conception

• Gestion des références — la composition ancrée de M​eta maintient la cohérence des personnages, du style et du cadre sur toute une série ; l’encodage de position à quatre axes de M​OSS-Image réserve son premier axe à un indice de référence, un point d’accroche que le fournisseur décrit comme tourné vers l’avenir plutôt que déjà livré

• Mesure indépendante — aucun des deux n’en dispose. Meta ne publie aucun benchmark de quelque nature que ce soit pour Muse Image ; les résultats de MOSS-Image au classement proviennent de benchmarks rédigés par ses propres auteurs.

• Accès aux poids — Meta Muse Image ne peut pas être quantisé, affiné ou auto-hébergé ; MOSS-Image peut l’être pour ces trois aspects, et des quantisations communautaires et des variantes distillées sont apparues environ un jour après sa sortie.

Là où chaque théorie gagne réellement

L’approche agentique justifie ses 0,01 $ dans les situations où le plus difficile est la connaissance plutôt que la composition. Si un prompt fait référence à quelque chose de réel — un bâtiment précis, un produit, un style visuel actuel —, l’ancrage par recherche est un mécanisme qu’une spécification de mise en page n’a tout simplement pas. Il en va de même pour tout ce qui nécessite un calcul : M​eta documente l’exécution de code comme la voie vers des tracés précis et des QR codes, et aucune quantité de précision de boîte englobante ne vous donnera un graphique correct sans quelque chose qui sait faire de l’arithmétique. Et l’auto-raffinement compte le plus lorsque vous ne pouvez pas écrire à quoi « correct » ressemble, ce qui est exactement le cas où une spécification de mise en page ne peut pas aider.

L'approche par spécification mérite sa place dans la situation opposée. Lorsque vous savez précisément où va chaque élément — une affiche avec une grille fixe, une maquette d'interface utilisateur avec des positions réelles de composants, une infographie dont le texte doit être lisible et correctement placé au caractère près — alors le raisonnement est une surcharge et l'inférence est un risque. Vous ne demandez pas au modèle de décider quoi que ce soit. Vous lui demandez d'exécuter un dessin, et l'ablation 1 622,87 contre 1 506,20 est la preuve du fournisseur que l'exécution d'un dessin et l'interprétation d'une description sont des capacités différentes avec des scores différents.

Il existe une considération de second ordre qu’aucun des deux fournisseurs ne met en avant. Une spécification de mise en page est inspectable avant d’être rendue, ce qui signifie qu’elle peut être générée, versionnée, comparée et testée unitairement comme n’importe quelle autre donnée structurée. Un pipeline agentique qui décide de sa propre approche n’est pas inspectable de cette manière ; son déterminisme vient du modèle plutôt que de votre code. Si votre pipeline nécessite une étape d’approbation — un humain qui valide la composition avant que quoi que ce soit ne soit rendu — une seule de ces deux architectures la prend en charge proprement.

La question du routage, traitée honnêtement

Aucun des deux modèles de cette comparaison n'est servi par nous, et il vaut mieux être précis là-dessus plutôt que de se contenter d'évoquer une prétention de plateforme. Meta Muse Image ne figure pas dans notre catalogue — on y accède via l'API de modèles de Meta elle-même, sous muse-image-1.0, et c'est le seul endroit où il existe. MOSS-Image ne figure pas non plus dans notre catalogue ; c'est un téléchargement que vous exécutez vous-même. Ce qui figure dans notre catalogue, c'est le reste du panel par rapport auquel ces deux modèles sont mesurés, sur une seule clé API, au prix catalogue du fournisseur, avec 0 % de marge : ainsi, une évolution tarifaire d'un fournisseur sur un modèle hébergé se répercute ici le jour même. Les modèles meta/muse-spark-1.1 et meta/muse-spark-1.2 de Meta sont, eux, servis ici, ce qui est utile si votre pipeline mélange des images générées et du texte généré — mais Muse Spark est le modèle de raisonnement de Meta, pas son modèle d'image, et les deux ne sont pas interchangeables.

Là où cela compte pour cette confrontation précise, c'est la modélisation des coûts. Le centime forfaitaire de M​eta est facile à appréhender et impossible à comparer aux poids ouverts tant que vous ne chiffrez pas vos propres heures de GPU ; les modèles hébergés auxquels vous compareriez M​OSS-Image sont ceux qui exigent un chiffre par image, et c'est précisément ce chiffre qu'une couche de routage à tarification en répercussion (pass-through) vous permet de lire en direct plutôt que de le déduire.

Lequel choisir, en un paragraphe de conseils

Choisissez M​eta M​use Image si la requête est de nature conversationnelle, si elle renvoie au monde réel, si elle exige un raffinement itératif au fil des tours, ou si votre équipe financière veut une seule ligne de facturation à un centime par image, sans mauvaise surprise de résolution. Choisissez M​OSS-Image si vous possédez vos propres GPU, si votre mise en page est connaissable à l'avance, si vous devez affiner ou quantifier, ou si une revue de licence qui se conclut par « Apache 2.0, aucune négociation » vaut plus qu'un point de terminaison appelable. Si vous avez besoin des deux — une interface frontale agentique pour l'exploration et un back end de spécification pour la production —, vous décrivez deux systèmes, car rien ici ne fait les deux.

Ce qui changerait ce conseil le plus vite est la même chose pour les deux modèles, et elle n'existe pas encore. M​eta n'a publié aucune mesure du suivi d'instructions ni de la fidélité d'édition de M​use Image, si bien que son affirmation de retenue — « changez exactement ce que vous spécifiez et ne touchez à rien d'autre » — est infalsifiable de l'extérieur. OpenMOSS a publié énormément de choses, toutes auto-rédigées. Des exécutions indépendantes de l'un ou l'autre feraient passer cela de décrit à mesuré, et d'ici là, le choix repose sur l'architecture et le prix plutôt que sur la qualité, ce qui est une chose inhabituelle à pouvoir dire de deux modèles d'image sortis à quatre mois d'intervalle.

Les défaillances d'IA et les incidents d'agents documentés derrière des versions comme celle-ci sont recueillis dans l'OrcaRouter AI Incident Archive, où chaque entrée comporte ses propres sources, son niveau de gravité, son niveau de confiance et un indicateur de contestation.