MOSS-Image vs FLUX 3: due modi per inserire un bounding box in un prompt

La cosa più interessante nel confrontare M​OSS-Image con FLUX 3 è che entrambi, nell'ultimo mese, sono arrivati alla stessa conclusione — che il modo per controllare un modello di immagini è scrivere coordinate nel prompt — e poi non sono stati d'accordo sul sistema di coordinate. Il 16 ottobre 2026, OpenMOSS ha rilasciato M​OSS-Image-Base e M​OSS-Image-SFT sotto Apache 2.0: un diffusion transformer da 5B, scaricabile, con un formato di layout JSON che posiziona gli elementi tramite offset in pixel assoluti misurati dal centro della tela. Black Forest Labs è arrivata prima con F​lux 3 Image, attiva dal 1º ottobre con un listino prezzi pubblicato, che considera ogni riquadro come [top, left, bottom, right] in numeri interi da 0 a 1000, relativi a una griglia fissa. Stessa idea, grammatica incompatibile, e solo uno dei due ti dà un file che puoi tenere.

È quella differenza — non la qualità dell'immagine — a decidere questo confronto per la maggior parte dei team, e lo decide più in fretta di qualsiasi benchmark. Quindi il confronto qui sotto è organizzato attorno ad essa. Ogni dato di M​OSS-Image è di OpenMOSS, tratto dalla release e dal suo rapporto tecnico, e nessuno di essi è stato riprodotto da alcuno. Ogni dato di F​lux 3 proviene dal listino prezzi pubblicato e dal materiale di lancio di Black Forest Labs stesso. Non esiste un confronto diretto indipendente tra questi due modelli, e non ce ne sarà uno per un po'.

Cosa ha effettivamente consegnato ciascuna parte

MOSS-Image è una coppia di checkpoint, MOSS-Image-Base e MOSS-Image-SFT, con pesi e codice di inferenza sotto Apache 2.0, un mirror ModelScope, uno Space Gradio, una pipeline personalizzata Diffusers e un plugin nativo ComfyUI. Il supporto core di ComfyUI è arrivato lo stesso giorno dei pesi. Non esiste un endpoint ospitato da OpenMOSS né un prezzo pubblicato, perché non c'è nulla da prezzare — o lo esegui o no.

F​lux 3 ha la forma opposta. Black Forest Labs lo ha annunciato a luglio 2026 come una singola architettura addestrata su video, immagini e audio, e il livello per le immagini fisse — F​lux 3 Image — è stato aperto con prezzi pubblici pay-as-you-go il 1º ottobre. La controparte a pesi aperti, FLUX 3 Image Klein, è arrivata il 15 ottobre con la licenza FLUX Kommunity, che consente l'uso commerciale gratuito solo al di sotto di un tetto di ricavi. Quindi B​FL ora offre sia un percorso a noleggio sia uno scaricabile, ma sono modelli diversi con licenze diverse, e il download è il fratello minore, non il modello di punta.

Nessuno dei due modelli è presente nel nostro catalogo. OrcaRouter serve più di 200 modelli e M​OSS-Image non è tra questi, quindi nulla di ciò che è qui va interpretato come un'offerta da parte nostra — lo stesso vale per F​lux 3. Ciò per cui il router è utile in questo confronto è l'altra metà del ciclo: quando vuoi mettere un checkpoint self-hosted a confronto con modelli di immagini hosted sugli stessi prompt, il lato hosted è raggiungibile tramite una singola chiave API, al prezzo di listino del provider senza alcun ricarico aggiunto da parte nostra, con failover automatico tra provider se uno di essi degrada a metà esecuzione.

Le grammatiche box, fianco a fianco

È qui che i due divergono in un modo che un file di configurazione noterà.

• Spazio delle coordinate — M​OSS-Image: pixel assoluti misurati dal centro della tela, usando bbox_coord_space: "abs_centralized", quindi su una tela 1024×1024 ciascun asse va da −512 a +512. F​lux 3 Image: interi normalizzati da 0 a 1000 misurati dall'angolo in alto a sinistra.

• Ordine delle coordinate — M​OSS-Image: bbox_format: "yxyx", cioè [y_min, x_min, y_max, x_max]. F​lux 3 Image: [top, left, bottom, right], che sono gli stessi quattro numeri nello stesso ordine sotto un nome diverso.

• Come arriva al modello — MOSS-Image: un singolo oggetto JSON passato come stringa di prompt, con un summary blocco per scena e stile più un items array in cui ogni elemento porta un'etichetta, una didascalia e, per gli elementi di testo, la stringa letterale da renderizzare. Flux 3 Image: un array JSON di box scritto in un normale prompt, senza che sia richiesto alcun parametro aggiuntivo.

• Accoppiamento della risoluzione — le coordinate di MOSS-Image sono pixel, quindi sono corrette solo per la larghezza e l'altezza che hai richiesto; cambia la dimensione di output e devi ricalcolare ogni riquadro. La griglia 0–1000 di Flux 3 è indipendente dalla risoluzione per costruzione: [0, 0, 500, 500] è il quarto in alto a sinistra di qualunque canvas tu richieda.

• A cosa serve il box — M​OSS-Image è presentato innanzitutto come controllo di generazione, con il fornitore che osserva che modificare la didascalia di un elemento o spostarne il box regola quella parte della composizione, descritto come sperimentale. F​lux 3 Image abbina il layout alla modifica multi-turno limitata al box come capacità di punta.

Quell'ultimo punto elenco è la distinzione pratica. La griglia di F​lux 3 sopravvive a un cambio della risoluzione di output; quella di M​OSS-Image no, ma M​OSS-Image ti permette di indicare la stringa esatta che vuoi venga renderizzata all'interno di un elemento di testo anziché descriverla. Se la tua pipeline esegue di nuovo il rendering a dimensioni diverse, la griglia è un vero vantaggio. Se la tua pipeline renderizza poster con dimensioni fisse e testo specifico, i pixel assoluti non sono un problema.

Rendering del testo, dove gli unici numeri sono quelli del fornitore

La capacità principale di MOSS-Image è il testo leggibile, e il fornitore ha creato due benchmark per misurarla. Su LongLongTextBench — 240 attività di rendering di testi letterari con una lunghezza target media di circa 1.340 caratteri — MOSS-Image ottiene 96,3 su Mean-6 text coverage, contro 64,9 per Qwen-Image-2512. La riga sopra di essa nella stessa tabella è GPT Image 2 a 99,0 e Nano Banana Pro a 96,6, il che è degno di nota: OpenMOSS ha pubblicato una tabella in cui i concorrenti vincono ancora.

Black Forest Labs non ha pubblicato alcun benchmark di rendering del testo per F​lux 3 Image. Non c'è alcun numero da mettere accanto a 96,3, da nessuna delle due parti, e inventare un confronto a partire da immagini di esempio sarebbe il genere di cosa che questo blog non dovrebbe fare. Quello che si può dire è che il VAE di FLUX.2 è quello che usa M​OSS-Image — la model card di MOSS-Image stessa segnala che carica il decoder small di FLUX.2 — quindi le due famiglie non sono estranee a livello di pixel, anche se i generatori non sono correlati tra loro.

Costo: un numero contro cinque

• M​OSS-Image — scaricabile gratuitamente, Apache 2.0, nessuna soglia di ricavi e nessun livello commerciale. Il costo è l'hardware: il repository SFT totalizza circa 27,2 GB, di cui circa 16,8 GB su quattro shard sono il text encoder congelato Qwen3.5-9B e circa 10,2 GB su tre sono il transformer. Metti in budget l'encoder, non il badge.

• Flux 3 Image — $0,041 a 768×768, $0,048 a circa 1 megapixel, $0,07 a 1,5K, $0,10 a 2K e $0,607 a 4K, per immagine, secondo il listino prezzi di Black Forest Labs. Uno sconto di lancio del 50% è stato attivo dal 1° ottobre all'8 ottobre ed è scaduto, quindi qualsiasi modello di costo basato su di esso necessita di una seconda riga a tariffa piena.

• FLUX 3 Image Klein — $0,008 a 768×768, che sale a $0,036 a 4K, e la generazione da testo a immagine e l'editing costano lo stesso. È drasticamente più economico del download da 5B con cui compete in manodopera, se non in licenza.

La formulazione onesta è che questi non sono lo stesso acquisto. M​OSS-Image scambia denaro con ore di GPU e ingegneria; F​lux 3 Image scambia denaro con qualcun altro che gestisce lo stack ed è prezzato per immagine consegnata a una tariffa che aumenta rapidamente con la risoluzione.

Ciò che nessuna delle due parti ha pubblicato

Non esiste alcun benchmark indipendente di MOSS-Image. Non esiste alcun benchmark indipendente nemmeno di Flux 3 Image: BFL ha distribuito il tier delle immagini senza numeri di confronto con qualsiasi altro modello di immagini, eseguiti dal fornitore o meno. Nessuno dei due modelli ha una riga su una classifica neutrale che qualcuno possa indicare. Quando entrambe le parti di un confronto sono prive di prove, la conclusione corretta non è che sono ugualmente validi; è che al momento non puoi dirlo, e che lo spareggio deve basarsi su qualcosa che puoi effettivamente misurare: licenza, formato, latenza sul tuo hardware e se la grammatica del box corrisponde al codice che hai già.

Due cose cambierebbero la situazione. Un'esecuzione indipendente di LongLongTextBench o RealLayoutArena da parte di chiunque altro oltre a OpenMOSS sarebbe la prima vera prova a sostegno dell'affermazione centrale di M​OSS-Image. Un confronto di controllo del layout di terze parti sulla griglia B​FL farebbe lo stesso per F​lux 3 Image. Nessuno dei due esiste ancora.

Quale sceglieresti davvero?

Scegli MOSS-Image se il deliverable è una pagina composta — poster, infografica, mockup di prodotto — in cui testo specifico deve finire in punti specifici e in cui vuoi i pesi nella tua infrastruttura. La licenza Apache 2.0 rende rapida la revisione commerciale, il checkpoint Base è stato deliberatamente lasciato non distillato, così che il training LoRA abbia qualcosa su cui fare presa, e il layout JSON è la parte del modello che il fornitore ha misurato con maggiore attenzione. Prevedi l'encoder nel budget e aspettati di dover fornire JSON strutturato anziché prosa: l'ablation del fornitore stesso ha assegnato ai prompt di layout JSON un punteggio di 1622,87 Elo contro 1506,20 per il linguaggio naturale sullo stesso sistema, che è un divario ampio e il segnale più chiaro del rilascio.

Scegli Flux 3 Image se hai bisogno oggi di un endpoint richiamabile, se i tuoi output variano in risoluzione o se desideri modifiche con ambito a riquadro su più turni come funzionalità supportata anziché sperimentale. La griglia 0–1000 è indipendente dalla risoluzione, il listino prezzi è pubblico e accanto c’è una variante open-weight economica se il tetto di licenza è accettabile.

La cosa da tenere d'occhio è la grammatica dei box. Qualunque convenzione il tuo tooling adotti per prima è quella che manterrai, e al momento le due convenzioni sono incompatibili — pixel assoluti relativi al centro in yxyx ordine da un lato, interi normalizzati con origine in alto a sinistra dall'altro. Una piccola funzione di adattamento converte dall'una all'altra. Il motivo per cui è importante è che è l'unica parte di questo confronto che oggi sia pienamente conoscibile.

I fallimenti documentati dell'IA e gli incidenti degli agenti dietro release come questa sono raccolti nell'OrcaRouter AI Incident Archive, dove ogni voce riporta le proprie fonti, gravità, grado di confidenza e flag di contestazione.