MOSS-Image vs Krea 3: uno fattura per immagine, l'altro fattura a ore

I due modelli in questo confronto hanno prezzi in valute diverse, ed è per questo che il confronto ovvio — sei centesimi contro zero — è quello sbagliato. K​rea 3, rilasciato il 15 ottobre 2026, è un modello di editing in hosting con una tariffa pubblicata: $0,06 per immagine a 2K nativo, in meno di otto secondi end-to-end secondo la misurazione dello stesso fornitore. M​OSS-Image, rilasciato da OpenMOSS il 16 ottobre 2026 come i checkpoint Apache 2.0 M​OSS-Image-Base e M​OSS-Image-SFT, non ha alcuna tariffa. Noleggi una GPU e paghi l'ora, che tu generi un'immagine o quattrocento.

Quindi la vera domanda non è quale dei due costi meno. È come si presenta il tuo carico di lavoro nell'arco di un mese, perché una tariffa fissa per immagine e una tariffa oraria si incrociano a un volume che dipende interamente dal tuo utilizzo. Al di sotto di quel punto di incrocio, K​rea è migliore in termini di costi ed enormemente migliore in termini di latenza. Al di sopra, il costo marginale per immagine di M​OSS-Image si avvicina al costo dell'elettricità. Quasi nessuno fa i calcoli, e questa è l'intera decisione.

Entrambi vogliono una scatola, e la vogliono in unità diverse

Parti da ciò che li rende anche solo confrontabili, perché è facile trascurarlo. Nessuno dei due è un generatore "prompt-and-pray". Il tool di editing di Krea 3 include bounding box per posizionare nuovi elementi e modifiche multi-turno che mantengono il contesto tra un turno e l'altro. Il formato di layout di MOSS-Image accetta come prompt un oggetto JSON — un blocco summary più un array items in cui ogni elemento porta un'etichetta di text, character o object, una didascalia, un bounding box e, per gli elementi di testo, la stringa letterale da renderizzare.

• Da dove viene il box — MOSS-Image: un campo JSON su ogni elemento nel prompt di layout, che usa bbox_format: "yxyx" in bbox_coord_space: "abs_centralized", ovvero pixel assoluti misurati dal centro della tela. Krea 3: un controllo bounding-box nella sua interfaccia di modifica per posizionare nuovi elementi.

• Risoluzione di output — M​OSS-Image: addestrato su 256px, 512px e circa 1024², con il budget di token che passa da 576 → 3,072 → 8,192. K​rea 3: 2K nativo, con esempi citati a 2736 × 1536 px, e 1K a metà prezzo.

• Immagini di riferimento — M​OSS-Image: gli elementi sono descritti strutturalmente nel prompt di layout anziché essere forniti come immagini di riferimento. K​rea 3: fino a sei per modifica sul post di lancio, otto sulla pagina del prodotto — il materiale del fornitore stesso riporta due cifre e nessuna delle due è stata ritirata.

• Ciò che stai creando — M​OSS-Image: una composizione, da una specifica, in gran parte dal nulla. K​rea 3: una modifica a un'immagine che hai già, lasciando invariata l'area al di fuori della modifica.

Quell'ultima riga è quella che decide la maggior parte dei carichi di lavoro reali. Se il tuo lavoro è "prendere questa foto di prodotto e cambiare lo sfondo", MOSS-Image è lo strumento sbagliato — non è un editor in-place, e il suo fornitore etichetta il comportamento di editing come sperimentale. Se il tuo lavoro è "produrre quattrocento poster unici con testi specifici in posizioni specifiche", Krea 3 è lo strumento sbagliato, e il suo stesso materiale è carente sui testi lunghi — i suoi esempi di lancio sono in inglese, i suoi punti di forza documentati sono cambi di scena di prodotto, rimozione di oggetti e pulizia delle foto.

Velocità, dove solo una delle parti ha pubblicato qualcosa

Il dato principale di K​rea 3 è meno di otto secondi per modifica, dall'inizio alla fine, a 2K. È un dato del fornitore e il fornitore è insolitamente trasparente sulla sua provenienza: i tempi sono il tempo mediano dalla richiesta al risultato del batch di dodici immagini di ciascun modello, incluso il tempo in coda, misurati sulla piattaforma di K​rea tra il 24 settembre e il 1º ottobre 2026. Una metodologia pubblicata sul benchmark vale più di un semplice numero, e questo ce l'ha. Resta comunque K​rea che misura K​rea.

M​OSS-Image non ha alcun dato di latenza pubblicato, e vale la pena capire perché prima di considerarlo un'omissione. I default di campionamento sono flow-matching Euler a 50 step con CFG 3.0, shift 5.0 e negative-branch skip-layer guidance al layer 22. Il percorso di guidance predefinito richiede due forward del transformer per step. La latenza di M​OSS-Image, quindi, non è una proprietà del modello come lo è per un endpoint ospitato — è una proprietà della GPU che ci metti sotto, del numero di step che scegli e del fatto che tu elimini la guidance o esegua la distillazione. La community ha rilasciato quantizzazioni INT8 e INT4, una LoRA DMD a 4 step e una variante distillata a 8 step nel giro di circa un giorno dal rilascio, il che ti dice che le persone hanno trovato il default a 50 step troppo lento per il lavoro interattivo e se lo sono sistemato da sole.

Quindi il confronto onesto sulla velocità è questo: Krea 3 dichiara un numero che dipende da Krea, e MOSS-Image non ha alcun numero perché dipende da te. Un default da 50 passi con due forward per passo non è veloce. Una build distillata da 8 passi su una GPU noleggiata potrebbe esserlo. Nessuna di queste affermazioni è verificabile dalla pagina di un fornitore, e la seconda è verificabile da te in un pomeriggio.

L'aritmetica della revisione, che è il punto in cui i sei centesimi smettono di contare

Ecco il calcolo che cambia la decisione, e parte dalla stessa impostazione di K​rea.

A 0,06 $ per modifica, eseguire cinque passaggi e scegliere il migliore costa trenta centesimi e nessuna riunione. Questo è il pitch implicito di K​rea, ed è un buon pitch, perché l'alternativa a una riprova economica è un'ora di un designer. Centomila modifiche al mese a 2K sono 6.000 $ — e K​rea dichiara esplicitamente che il prezzo di lancio è il prezzo di listino e che si aspetta che il prezzo scenda anziché salire, il che rende i 6.000 $ un tetto piuttosto che un pavimento.

Il lato di MOSS-Image della stessa aritmetica non è una tariffa, è un problema di utilizzo. La licenza è Apache 2.0 senza soglia di fatturato, e c'è un modello open-weight da 0,008 $ per immagine nelle vicinanze di questo confronto, di un altro fornitore, come riferimento — ma non è così che funziona il percorso aperto. Il download è di circa 27,2 GB: all'incirca 16,8 GB distribuiti su quattro shard costituiscono il text encoder congelato Qwen3.5-9B e circa 10,2 GB su tre costituiscono il transformer. Il badge 5B descrive soltanto il generatore di diffusione e l'encoder è la metà più grande dell'impronta su disco.

Se questo batta i sei centesimi dipende da tre numeri che già conosci: la tua tariffa per GPU-ora, le tue immagini all'ora con il numero di step che decidi di usare, e la frazione del mese in cui la scheda è effettivamente occupata. Un team che porta avanti una linea di produzione costante otterrà un basso costo effettivo per immagine e dovrebbe ospitare in proprio. Un team che ha bisogno di quaranta immagini il martedì pomeriggio non dovrebbe noleggiare una GPU per questo, e non dovrebbe far finta che il prezzo della licenza sia il prezzo dell'immagine.

La tesi del fine-tuning, che entrambe le parti avanzano e che nessuna delle due ha dimostrato

Questa è la sezione che un confronto tra specifiche di solito trascura, ed è la cosa più interessante che questi due modelli hanno in comune.

L'affermazione di K​rea è che K​rea 3 sia il primo modello di editing su cui puoi fare fine-tuning per un prodotto specifico, una persona o uno stile, così che il packshot di un brand o un personaggio ricorrente rimanga identico per tutta una campagna. Il meccanismo è verificabile — il riferimento API contiene un endpoint "Train a custom style (LoRA)" — e se il "primo" regga o meno è un'affermazione sul settore più che una misurazione. È un'affermazione di K​rea. Ma il meccanismo esiste, è documentato, ed è l'unico percorso pubblicato da parte di K​rea per bloccare un soggetto.

L'equivalente di OpenMOSS è strutturale anziché commerciale. Base è il checkpoint preaddestrato, deliberatamente lasciato non distillato — la scheda del modello dichiara esplicitamente che non è stato applicato alcun post-addestramento né distillazione dei parametri di inferenza come CFG, al fine di preservare le informazioni di addestramento e mantenere praticabile l'addestramento LoRA. Si tratta di un fornitore che sceglie di distribuire un default peggiore in cambio di un substrato di addestramento migliore, ed è il segnale più chiaro dell'intero rilascio su a chi è destinato il checkpoint Base.

Entrambe le affermazioni puntano allo stesso acquirente: qualcuno con un soggetto ricorrente che non deve andare in drift. Nessuno dei due fornitori ha pubblicato una misurazione del drift, e la comunità si costruisce attorno a MOSS-Image — il packaging per ComfyUI, le quantizzazioni, i LoRA distillati — arrivati nel giro di circa un giorno, il che indica che il percorso di addestramento è reale anche se nessun risultato di addestramento è stato pubblicato dal fornitore.

• Dove risiede il LoRA — Krea 3: un endpoint ospitato sulla piattaforma di Krea, addestrato sul modello di Krea e sull'infrastruttura di Krea. MOSS-Image: i tuoi pesi, il tuo addestramento, la tua GPU, con un checkpoint che il fornitore ha deliberatamente lasciato in uno stato addestrabile.

• Quanto ti costa — K​rea 3: la conversazione di addestramento è una conversazione sulla licenza. M​OSS-Image: la conversazione di addestramento è la tua bolletta elettrica e la settimana di qualcuno.

• Cosa ti restituisce — K​rea 3: uno stile che puoi richiamare, sull'uptime di qualcun altro. M​OSS-Image: un checkpoint che possiedi tu, che continua a funzionare se il fornitore se ne va.

Access, e dove un router si inserisce in una pipeline a due strumenti

Krea 3 è chiuso. Krea ha già rilasciato pesi aperti in passato — Krea 2 RAW e Turbo sono sull'Hub — ma Krea 3 non è tra questi, e le FAQ di Krea collocano il self-hosting sotto i piani enterprise, sulle proprie GPU, con termini di licenza e dimensionamento hardware da discutere. Quindi è una decisione. MOSS-Image è un download, e il download è l'intero prodotto.

Nessuno dei due è nel catalogo di OrcaRouter — serviamo più di 200 modelli e nessuno di questi due è tra loro — quindi entrambi implicano rivolgersi alla fonte: per K​rea 3, l'API di K​rea stessa e diverse piattaforme di terze parti; per M​OSS-Image, i repository e il tuo hardware.

Ciò per cui il router è utile in una pipeline come questa è la parte che non appartiene a nessuno dei due modelli. Posizionare un elemento in un frame è di solito un passaggio di un lavoro che richiede anche un generatore ospitato per l'immagine di base, un modello separato per l'upscaling e una fase di captioning o di valutazione — ed è qui che un solo endpoint su qualche centinaio di modelli con failover automatico e i prezzi di listino dei provider passati con ricarico 0% elimina il lavoro di integrazione anziché il lavoro sul modello. Il DSL di routing conta per lo stesso motivo: se il passaggio dell'immagine di base e il passaggio di modifica sono due modelli diversi, fissare ciascuno per richiesta in un'unica configurazione batte il dover mantenere due SDK di fornitori diversi. È la plumbing, e l'architettura stessa di M​OSS-Image è un promemoria di quanto valga la plumbing rispetto al modello — il più forte risultato di layout end-to-end del fornitore è stato prodotto da una pipeline la cui metà dedicata alla specificazione del prompt gira interamente su un modello di terze parti.

Quale, e il crossover che lo decide

Scegli Krea 3 se il risultato è una modifica a un'immagine esistente, se il tuo team misura la propria latenza in minuti, e se il tuo volume è abbastanza irregolare che una GPU noleggiata resterebbe inattiva per la maggior parte del mese. Sei centesimi con un round trip inferiore a otto secondi, una storia di precisione documentata e un endpoint LoRA sull'infrastruttura del fornitore stesso è un prodotto coerente per quel lavoro, e il fatto che il prezzo di lancio sia indicato come prezzo di listino significa che è improbabile che l'economia peggiori. Procedi sapendo che ogni dato di prestazione ad esso associato è di Krea stessa, che il conteggio dei riferimenti è documentato in due modi, e che non porta alcun punteggio indipendente di alcun tipo — il che è l'intera spiegazione della sua assenza dalle classifiche, poiché è stato rilasciato il giorno prima che venissero raccolte le ricerche per questo articolo.

Scegli MOSS-Image se produci immagini composte a partire da una specifica a volume costante, se un bounding box in un prompt JSON è più adatto alla tua pipeline di una casella nella UI di qualcun altro, oppure se possedere il checkpoint è un requisito anziché una preferenza. Apache 2.0 senza soglia di ricavi rende breve la revisione legale, il checkpoint Base è intenzionalmente addestrabile e lo schema di layout è una vera specifica. Procedi sapendo che la latenza dipende da te, che l'encoder costituisce la maggior parte del download, che le quantizzazioni della community esistono perché il default a 50 passaggi è lento e che nessuno dei due benchmark del fornitore è stato riprodotto da alcuno.

Il crossover non è un mistero. Dividi il costo mensile della tua GPU per le tue immagini al mese e confronta il risultato con sei centesimi. Se non riesci a stimare con sicurezza le immagini all'ora, quell'incertezza è la risposta: noleggia K​rea per un mese, genera il volume che effettivamente prevedi e lascia che la fattura ti dica se vale la pena costruire il percorso aperto. È un esperimento più economico che noleggiare una scheda per un mese per scoprirlo.

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.