MOSS-Image est disponible : OpenMOSS a livré un DiT 5B qui prend des boîtes englobantes dans le prompt

Le détail gênant derrière le lancement de MOSS-Image, c'est que la déclaration la plus retentissante à son sujet n'est pas encore tout à fait vraie. Le 17 octobre, le compte de vLLM lui-même a félicité l'équipe OpenMOSS pour cette publication open source et s'est dit « fier de soutenir MOSS-Image dès le Day 0 avec vLLM-Omni ». La pull request qui ajoute réellement le modèle à ce runtime — [Modèle] Ajout de MOSImage texte-vers-image avec SLG, 3 605 lignes ajoutées sur 25 fichiers — a été ouverte le 14 octobre et reste ouverte, le relecteur réclamant des preuves de parité de sortie par rapport à une implémentation de référence épinglée. La dernière version publiée de vLLM-Omni est v0.31.0rc1, datée du 6 octobre. Aucune version livrée de vLLM-Omni ne contient donc ce modèle, et la version honnête de l'affirmation du Day 0, c'est que le chemin de serving existe sous la forme d'une branche que l'on peut compiler, et non d'un paquet que l'on peut installer. Cette distinction compte plus que d'ordinaire ici, car MOSS-Image est une publication réellement intéressante dont le véritable contenu réside dans les poids : MOSS-Image-Base et MOSS-Image-SFT, publiés le 16 octobre 2026 sous licence Apache 2.0, construits autour d'un transformateur de diffusion compact qui accepte des dispositions JSON structurées comme invite.

La version courte pour qui veut en saisir l'essentiel. OpenMOSS — le laboratoire derrière la gamme langage et parole MOSS, en collaboration avec MOSI Intelligence et des partenaires universitaires — a livré un transformer de diffusion à flux unique de 5B entraîné à partir de zéro, associé à un encodeur de texte Qwen3.5-9B gelé et à un VAE FLUX.2 gelé, sous une licence permissive qui couvre à la fois les poids et le code d'inférence. Son argument de vente n'est pas la qualité brute de l'image ; c'est que vous pouvez lui transmettre un objet JSON contenant des boîtes englobantes, des chaînes de texte littérales et des indications typographiques, et qu'il les respectera. Les chiffres de benchmark qui l'accompagnent sont ceux du fournisseur, mesurés sur deux benchmarks que le fournisseur a également conçus. Ce n'est pas disqualifiant, mais cela signifie que vous devez les lire comme le tableau de bord interne d'un laboratoire plutôt que comme un classement.

Qu'est-ce qui a réellement été livré, et où

Les artefacts sont simples et vérifiables. Sur Hugging Face, OpenMOSS-Team/MOSS-Image-Base et OpenMOSS-Team/MOSS-Image-SFT portent les poids, avec des miroirs ModelScope pour les deux, un Space Gradio fonctionnant sur un seul A10G, et un dépôt GitHub hébergeant le pipeline, le plugin ComfyUI et un rapport technique. La page du projet sur openmoss.ai indique la même date : 16 octobre 2026 — Présentation de MOSS-Image-Base, avec le code et les poids du modèle disponibles.

Deux checkpoints, une seule architecture. Base est le modèle préentraîné ; SFT est affiné sur des données sélectionnées. L'exemple de comparaison fourni par l'éditeur lui-même montre que SFT produit un regroupement de texte plus resserré et une mise en page mieux organisée, ce qui correspond à peu près à ce que l'on attend d'un affinage sur données sélectionnées d'un modèle de base délibérément laissé non distillé. La fiche de Base précise explicitement qu'il « n'a subi aucun post-entraînement ni distillation de paramètres d'inférence tels que le CFG », la raison invoquée étant de préserver les informations d'entraînement et de rendre le modèle plus facile à entraîner des LoRA. La conséquence pratique est que Base est le meilleur hôte pour l'affinage et le pire choix par défaut pour le prompting occasionnel.

La licence est Apache 2.0 pour les poids et pour le code de pipeline autonome — aucun seuil de revenus, aucune annexe d'utilisation acceptable, aucun palier commercial distinct. Pour un modèle dont la capacité phare est de générer du texte lisible dans des images, c'est un fait plus déterminant que le tableau de benchmarks, car le rendu de texte est précisément la capacité qui apparaît dans le travail commercial : maquettes de produits, compositions d'interface, infographies, affiches, mises en page publicitaires.

L’architecture, en chiffres qui comptent

Le tableau de configuration du rapport technique marque le moment où la version cesse d’être un communiqué de presse pour devenir une spécification. Le chiffre de 5B fait référence au générateur de diffusion seul — un transformer à flux unique, profond de 42 blocs conjoints, de largeur cachée 3072, avec 24 têtes d’attention de 128 dimensions chacune, un feed-forward de largeur 8192 utilisant des activations SiTU-GLU, et un encodage positionnel rotatif à quatre axes dont le premier axe est réservé à un indice de référence, de sorte que la génération conditionnée par référence puisse être ajoutée plus tard sans modifier le schéma positionnel.

Ensuite, il y a la partie que l’étiquette « 5B » exclut discrètement :

• Encodeur de texte — Qwen3.5-9B, gelé, transmettant les états cachés des tokens de la couche finale en dimension 4096 via une projection linéaire vers 3072, plus deux blocs transformer uniquement textuels. Un encodeur 9B greffé à un générateur 5B représente une empreinte nettement plus importante que ne le laisse penser le chiffre mis en avant.

• VAE — le VAE de FLUX.2, gelé et chargé depuis FLUX.2-klein-4B, 32 canaux latents avec un facteur de sous-échantillonnage spatial de 8, avec des patchs latents 2×2 donnant un pas d’image effectif de 16 pixels. La fiche de modèle de MOSS-Image elle-même indique qu’il utilise le décodeur small de FLUX.2.

• Taille du téléchargement — le dépôt SFT totalise environ 27,2 Go, dont l’encodeur de texte représente environ 16,8 Go répartis sur quatre fragments et le transformer environ 10,2 Go sur trois. Prévoyez l’encodeur, pas le badge.

• Plafond de prompt — 4096 tokens à l’étape finale de pré-entraînement, ce qui correspond à l’affirmation du fournisseur « jusqu’à 4K tokens ». Les dimensions de sortie doivent être des multiples positifs de 16, le guide recommandant un, un et demi ou deux mégapixels et une plage d’extrapolation prise en charge de 0,25 M (512×512) à 4 M.

• Valeurs par défaut d’échantillonnage — flow-matching Euler, 50 étapes, CFG 3.0, shift 5.0, avec guidage skip-layer sur la branche négative à la couche 22. Le chemin de guidage par défaut nécessite deux passes avant de transformer par étape, ce qui explique pourquoi 50 étapes n’est pas le réglage économique que cela laisse penser.

• Entraînement — trois étapes progressives de résolution : 256 px pendant 2,1 M d'étapes, 512 px pendant 2,1 M d'étapes, puis environ 1024² pendant 0,31 M d'étapes, le nombre maximal de tokens par échantillon passant de 576 à 3 072 puis à 8 192. Le corpus est un ensemble dérivé de ReLAION, ramené d'environ 5 milliards à 3 milliards d'images par déduplication et suppression des images générées par IA, le rapport précisant qu'aucun filtrage supplémentaire n'est appliqué — les images dont les légendes contiennent des artefacts sont conservées et leurs artefacts décrits, plutôt que supprimées. L'optimisation repose sur un hybride Muon–AdamW, et l'ablation à 1 milliard de paramètres du fournisseur indique 33,2 % et 28,6 % d'étapes en moins pour atteindre la même perte qu'AdamW à deux points de contrôle. L'entraînement est déclaré comme ayant utilisé des plateformes GPU hétérogènes, ce qui relève d'une affirmation sur l'approvisionnement en matériel plutôt que sur le modèle, et le rapport ne les nomme pas.

Une chose à signaler avant les benchmarks

Le module d'amélioration de prompt — l'élément qui transforme « design an English koala knowledge infographic » en une spécification complète de contenu et de mise en page — n'est pas un petit modèle propre au fournisseur. Le rapport indique clairement que 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 avec le dépôt est décrite comme conçue pour les agents de la famille G​PT-6. Ainsi, le résultat de bout en bout le plus solide ci-dessous n'est pas la sortie d'un seul modèle ; c'est un pipeline à deux modèles dont la moitié de spécification tourne sur l'API de quelqu'un d'autre. Si vous lisiez le classement Elo comme une mesure pure du générateur, ce n'est pas cela.

Le tableau de référence, et qui l'a rédigé

MOSS-Image est évalué sur deux benchmarks fournis avec la version, nés de l'argument même du fournisseur selon lequel les tests existants ne mesurent pas ce qui l'intéresse. LongLongTextBench comprend 240 tâches de rendu de texte littéraire — 120 en anglais, 120 en chinois, pour une longueur cible moyenne de 1 339,8 caractères, soit environ onze fois la moyenne de LongTextBench. RealLayoutArena regroupe 61 tâches de design (20 affiches, 20 infographies, 21 interfaces utilisateur), jugées par comparaison humaine en aveugle par paires et ajustées sur une échelle Elo de Bradley–Terry. Lorsque des références apparaissent, il s'agit des exécutions par le fournisseur des modèles d'autres personnes. Chaque chiffre de cette section est rapporté par le fournisseur, non reproduit, et rien n'a fait l'objet d'un audit indépendant.

Sur la couverture textuelle Mean-6 de LongLongTextBench, MOSS-Image obtient 96,3 — le meilleur chiffre open-weight du tableau du fournisseur, bien au-dessus des 64,9 de Qwen-Image-2512, et ses scores sur les conditions les plus longues sont de 97,1 en anglais et 92,4 en chinois. Le chiffre qui garde ce tableau honnête est la ligne juste au-dessus : sur le benchmark du fournisseur lui-même, sur les propres exécutions du fournisseur, GPT Image 2 obtient 99,0 et Nano Banana Pro 96,6. OpenMOSS a publié un tableau dans lequel un concurrent l'emporte encore, ce qui n'est pas rien.

Sur le contrôle de mise en page de 7Bench, l'écart est bien plus large — l'IoU moyen sur les objets cibles détectés est de 0,88 pour MOSS-Image 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 une AUC de mise en page de 0,70 contre un champ s'échelonnant de 0,16 à 0,20. Si ces chiffres résistent à la reproduction, le placement précis des objets est la capacité que ce modèle possède réellement.

Sur RealLayoutArena en bout en bout, MOSS-Image atteint 1698,70 Elo avec un intervalle de confiance à 95 % de 1655,96 à 1741,43 — deuxième au classement général, derrière GPT Image 2 à 1844,35 et devant Seedream 5.0 Pro (1661,16), Q​wen Image 3.0 Pro avec amélioration de prompt (1614,84) et Nano Banana Pro (1590,19). Lorsque la comparaison est restreinte au backbone seul, avec des prompts en langage naturel améliorés partagés, MOSS-Image arrive en tête à 1807,34, devant ERNIE Image à 1748,51 et SenseNova-U1 à 1689,23. L'ablation de la stratégie de prompt est la ligne la plus utile de l'article pour quiconque envisage de l'utiliser : les prompts de mise en page JSON obtiennent 1622,87, les prompts en langage naturel 1506,20 sur le même système. L'interface de mise en page n'est pas une fonctionnalité bonus. C'est là que réside la performance.

Deux réserves que le rapport formule à son propre encontre méritent d’être répétées. LongTextBench est décrit comme proche de la saturation pour les modèles actuels puissants, ce qui, de la part du fournisseur, revient à expliquer pourquoi il a conçu un test plus difficile plutôt que de s’appuyer sur un test plus ancien. Et l’intervalle de confiance sur l’Elo de bout en bout n’a aucun chevauchement, mais il est large — 85 points Elo — sur une arène de 61 tâches jugée par des évaluateurs humains.

L'exécuter vous-même, et ce que cela coûte

Aujourd'hui, il n'existe aucune API commerciale pour MOSS-Image que nous puissions vérifier, et il ne figure pas dans notre propre catalogue — OrcaRouter propose plus de 200 modèles et MOSS-Image n'en fait pas partie, donc rien ici ne doit être interprété comme une offre de notre part. Ce qui existe, c'est l'auto-hébergement : la voie Diffusers avec un pipeline personnalisé (pipeline_moss_image, diffusers 0.38 ou version ultérieure, transformers 5.3 ou version ultérieure, torch 2.9 ou version ultérieure, Python 3.10+), une application Gradio, et un plugin natif ComfyUI installable via ComfyUI Manager, avec une intégration au dépôt officiel ComfyUI décrite comme en cours. Il existe également une compétence d'amélioration de prompt pour les frameworks d'agents, et elle compile des brouillons à coordonnées en pixels dans le format JSON à coordonnées centrées du modèle sans appeler de service d'image — un petit outil vraiment utile.

La communauté a déjà fait la partie que le fournisseur n’a pas faite. En l’espace d’environ un jour après la sortie, des builds tiers sont apparus sur Hugging Face : un packaging Comfy-Org du modèle, un build Kijai expérimental, des quantisations GGUF, des conversions ConvRot INT8 et INT4, un build W4A8 OrbitQuant, et — le plus utile pour quiconque n’a pas de datacentre — un LoRA DMD à 4 étapes et une variante distillée à 8 étapes qui s’attaquent de front au réglage par défaut de 50 étapes. Aucun de ces éléments n’est pris en charge par le fournisseur et aucun n’a fait l’objet de benchmarks, mais ils constituent le signal habituel qu’une sortie a trouvé son public chez des personnes qui comptent l’utiliser plutôt que la citer.

C'est là qu'une couche de routage justifie sa place, et il vaut la peine d'être précis quant à la frontière. Nous n'hébergeons pas MOSS-Image, donc nous ne pouvons pas le servir et ne laisserons pas entendre le contraire. Ce que nous pouvons faire, c'est l'autre moitié de la comparaison : si vous voulez mesurer un MOSS-Image auto-hébergé face à des modèles d'images hébergés, le côté hébergé est accessible via une seule clé d'API sur notre catalogue au prix catalogue du fournisseur, avec 0 % de marge — ainsi, un changement de prix d'un fournisseur sur un modèle hébergé est effectif ici le jour même, et non selon un cycle contractuel trimestriel — avec un basculement automatique entre fournisseurs et un DSL de routage qui vous permet de placer plusieurs modèles derrière un point de terminaison unique. Tester un checkpoint non éprouvé face à un modèle loué ne devrait pas exiger un second SDK, et c'est la seule affirmation qui est faite.

Qui devrait passer à l'action, et qui devrait attendre

Si votre travail consiste à générer des images contenant du texte multilingue correct et lisible à des positions précises — affiches, maquettes d’interface, fiches d’information, tout cas où la mise en page est le livrable plutôt qu’un heureux hasard —, MOSS-Image est la publication open-weights la plus directement ciblée du mois dernier, et sa licence Apache 2.0 signifie que l’examen commercial habituel est bref. Commencez par le checkpoint SFT, attendez-vous à fournir du JSON structuré plutôt que de la prose, et prévoyez les 16,8 Go de l’encodeur avant de prévoir ceux du générateur.

Attendez si vous avez besoin d'un point de terminaison appelable cette semaine, si vous louez de la capacité plutôt que de la posséder, ou si vous voulez un chiffre indépendant avant de vous engager. L'architecture est une conception épurée à flux unique avec un encodeur gelé et un VAE gelé, ce qui la rendra simple à exécuter — mais 50 étapes à deux passes avant par étape représentent un vrai coût de service, le badge « 5B » sous-estime le téléchargement, et les scores mis en avant ont été produits par le fournisseur sur ses propres benchmarks à l'aide d'une étape de spécification qui s'exécute sur un modèle tiers. Attendez une reproduction, ou que la voie vLLM-Omni soit fusionnée dans quelque chose que vous pouvez installer.

Deux questions que cette version ne tranche pas

Le contrôle de la mise en page du modèle justifie-t-il un changement de flux de travail ?

Cela dépend de si vous pouvez exprimer votre intention sous forme de boîtes et de chaînes. Le JSON de mise en page utilise des coordonnées en pixels absolus mesurées depuis le centre du canevas, avec bbox_format « yxyx », ce qui diffère des conventions de coordonnées relatives qu'emploient plusieurs autres systèmes de mise en page récents — le fournisseur soutient que les pixels absolus conviennent mieux au travail multi-résolution. L'adopter implique de réécrire toute la logique de prompt que vous avez déjà, et l'écart de 7Bench du fournisseur lui-même (0,88 mIoU contre un panel à 0,30–0,44) est la seule preuve que la réécriture en vaut la peine. Il a été mesuré par les personnes qui ont écrit la métrique.

L'histoire du Fine-Tuning est-elle aussi ouverte que la licence le suggère ?

En partie inconnu. Les poids et le code du pipeline sont sous Apache 2.0, et Base a été délibérément laissé non distillé afin que les LoRAs aient quelque chose sur quoi mordre, ce qui est un véritable engagement. Mais la recette d’entraînement du rapport — le curriculum de résolution par étapes, les décisions de filtrage ReLAION, la répartition Muon–AdamW — relève de la documentation, et non de données publiées, et les conseils de fine-tuning jusqu’à présent consistent en instructions spécifiques (garder l’encodeur de texte gelé ; ne pas le fine-tuner) plus un prompt de légendage. L’affirmation selon laquelle un simple SFT débloque la génération basée sur référence et la sortie GIF est présentée comme une conclusion avec un « restez à l’écoute » attaché, et non comme un résultat vérifiable aujourd’hui.

Trois choses feraient passer MOSS-Image du statut de dépôt impressionnant à celui de choix établi, et aucune n'existe encore : une exécution indépendante de LongLongTextBench ou de RealLayoutArena par quelqu'un d'autre que les auteurs, le correctif vLLM-Omni fusionné dans une version étiquetée avec les preuves de parité de sortie demandées par son relecteur, et un checkpoint distillé en quelques étapes bénéficiant de l'aval d'un éditeur, plutôt que de simples conversions communautaires. D'ici là, le résumé exact est le suivant — un transformateur de diffusion de 5B bien documenté, doté d'une interface texte-et-mise en page inhabituellement solide, une licence permissive qui couvre le code comme les poids, une position de leader sur les benchmarks dans des tests qu'il a lui-même écrits et la deuxième place dans la comparaison de bout en bout, et une histoire de serving bien réelle, mais qui reste encore dans une pull request ouverte.

Les défaillances documentées de l’IA et les incidents d’agents à l’origine de versions comme celle-ci sont recueillis dans l’OrcaRouter AI Incident Archive, où chaque entrée comporte ses propres sources, sa gravité, sa note de confiance et un indicateur de contestation.