MiniMax-H3-Image è disponibile su tre superfici: cosa ti offre davvero ciascuna

La frase vera più breve su MiniMax-H3-Image questa settimana è che è disponibile in tre posti: Hugging Face, MiniMax Code e l'API proprietaria di MiniMax. La frase di cui un acquirente ha effettivamente bisogno è più ristretta. Due di questi tre ti danno un endpoint di richiesta e un listino prezzi; uno ti dà 135 gigabyte di pesi, una licenza da leggere e una decisione sull'hardware. Non sono tre varianti dello stesso accesso, e trattarli come intercambiabili è il modo in cui un team finisce per preventivare una settimana per qualcosa che avrebbe potuto acquistare per immagine a due centesimi.

Il modello stesso è un vero rilascio, non un reimpacchettamento. MiniMax ha reso disponibili i pesi nel repository Hugging Face MiniMaxAI/MiniMax-H3-Image il 10 novembre 2026 alle 14:50 UTC e ha pubblicato un post in merito alle 15:40 dello stesso pomeriggio; il repository stesso risale al 3 novembre, ovvero una settimana durante la quale i pesi sono esistiti in privato prima che chiunque potesse scaricarli. È un diffusion transformer da 33,1 miliardi di parametri che genera a circa sedici megapixel, il che corrisponde al "4K" dell'annuncio, e svolge text-to-image e editing guidato da riferimenti da un unico checkpoint. Quanto segue è organizzato attorno all'unica domanda a cui l'annuncio non risponde: su quale superficie dovresti trovarti.

Tre porte d'ingresso, e solo una di queste è un download

Parti da cosa è ciascuna porta, perché la differenza è strutturale, non estetica.

L'API è il percorso convenzionale. Il modello è elencato come MiniMax-H3-Image con una variante Highspeed, sulle piattaforme internazionali e della Cina continentale di M​iniMax, con fatturazione per milione di token in ingresso e in uscita anziché per immagine. L'interfaccia è insolitamente prescrittiva — sei passaggi di campionamento, nessuna scala di guidance, nessun prompt negativo — e la documentazione di riferimento di M​iniMax afferma che una richiesta che chieda qualcos'altro restituisce un HTTP 400. Stai acquistando un endpoint funzionante con una ricetta fissa al suo interno.

M​iniMax Code e Hailuo AI sono interfacce di prodotto: lo stesso modello dietro una casella di prompt, con le decisioni di campionamento già prese e nessuna aritmetica per token da fare. Utili per valutare se l'output è valido; non utili per costruire qualcosa, perché ciò su cui costruiresti non è esposto. Nota inoltre che M​iniMax Code è un prodotto di coding-agent, quindi la generazione di immagini lì è una porta secondaria anziché la funzione principale — non leggere "disponibile su M​iniMax Code" come un'API per immagini con un wrapper di codice.

Hugging Face è la terza porta, ed è l'unica che rappresenta un trasferimento anziché un servizio. Ottieni un repository, un file di licenza e una serie di pesi che ora devi far funzionare. L'hosting autonomo è il motivo per cui la maggior parte dei team prende in considerazione un modello di immagini a pesi aperti; è anche il punto in cui i calcoli smettono di riguardare il modello e iniziano a riguardare il tuo rack.

Il repository è più pesante di quanto lasci intendere il numero di parametri di punta.

33,1 miliardi di parametri in BF16 occupano circa 66 GB prima di contare qualsiasi altra cosa, e "qualsiasi altra cosa" è dove il repository sorprende le persone. Il solo diffusion transformer è di 66,28 GB. Il download completo è di 68,65 GB, che comprende il transformer, il VAE e la configurazione. Il text encoder non è incluso in quel valore: MiniMax-H3-Image riutilizza il text encoder Qwen3-VL del repository video MiniMax-H3, legge dal suo livello 50, e quel text encoder è un download separato da 66,7 GB. In altre parole, mettete in conto circa 135 GB di artefatti su disco prima della prima immagine, e questo prima di qualsiasi cache propria del framework.

L'architettura merita un paragrafo perché dice che cos'è il modello. Cinquanta strati Transformer, dimensione nascosta 5.376, 56 teste di attenzione, ampiezza feed-forward 14.336, con embedding posizionali rotazionali multimodali tridimensionali. Il VAE è un encoder convoluzionale abbinato a un decoder ViT bidimensionale a 24 strati con downsampling spaziale 16× e 24 canali latenti — una scelta di decoder che richiede più calcolo alla fine della pipeline rispetto a un semplice decoder convoluzionale, ed è plausibilmente all'origine di alcuni dei dettagli fini a 4K. Il design è descritto nella model card come l'architettura H3 meno l'audio, il che è una sintesi corretta: questo è il ramo immagini del modello video, rilasciato autonomamente.

Ne derivano due conseguenze. Primo, un diffusion transformer della classe 33B a sedici megapixel non è un modello per laptop, per quanto il numero di parametri possa suonare diverso accanto ai moderni modelli linguistici; la memoria delle attivazioni scala con l’area dell’output, e l’area è proprio il punto centrale di questo rilascio. Secondo, poiché il text encoder è condiviso con il modello video, un’azienda che esegue già MiniMax-H3 ha già sul disco la maggior parte del download. È un risparmio concreto, ed è il tipo di cosa che la frase «disponibile su Hugging Face» non comunica.

Quattro modi per servirlo, e un numero che non concorda

La model card elenca quattro percorsi: SGLang, vLLM-Omni, diffusers e ComfyUI. Il team di vLLM ha rilasciato il supporto dal giorno zero in vLLM-Omni sia per hardware NVIDIA sia AMD il giorno del rilascio, con output nativo a circa sedici megapixel, il che è un segnale di lancio più forte dell'esistenza stessa dei pesi: qualcuno al di fuori di M​iniMax lo aveva già in funzione prima che l'annuncio compisse un'ora. Diffusers copre il percorso di riferimento, e ComfyUI copre il pubblico dei workflow a grafo.

La discrepanza vale la pena segnalarla perché prima o poi qualcuno ci inciamperà. La scheda del modello descrive l'editing con un massimo di 16 immagini di riferimento, indirizzate in base alla posizione come <Picture 1> fino a <Picture 16> nell'ordine di caricamento. La ricetta di rilascio vLLM-Omni per lo stesso modello documenta fino a 9 immagini per richiesta. Entrambe le cose possono essere vere contemporaneamente — il limite di serving di un framework e la capacità addestrata di un modello sono numeri diversi, e un vincolo di batching o di memoria nello stack di serving si imporrà per primo — ma se il tuo flusso di lavoro richiede dodici riferimenti, la risposta onesta oggi è che la capacità esiste e il percorso di serving documentato potrebbe non supportarla. Verifica il numero sul tuo stack invece di fidarti di uno dei due documenti.

La stessa cautela vale per la finestra del prompt. La scheda accetta fino a 32.000 caratteri, dei quali all'incirca i primi 4.096 token sono quelli su cui il modello si basa effettivamente. Un prompt lungo non viene rifiutato; semplicemente, la coda non svolge alcun lavoro. Chi trasferisce un prompt dettagliato di direzione artistica per abitudine da modello linguistico lo scoprirà a proprie spese.

Il sampler è un vincolo che erediti, non un'impostazione che regoli

Sei passaggi, nessuna guida senza classificatore, nessun prompt negativo. Non è un valore predefinito con margine di miglioramento; l'API rifiuta categoricamente altri numeri di passaggi e valori di guida. Il modello è distillato per funzionare in sei passaggi in avanti, e l'intera ragione per cui un transformer da 33B può restituire un'immagine da sedici megapixel abbastanza velocemente da essere utile è proprio la distillazione.

Per il percorso API questo è invisibile e va bene. Per il percorso self-host è il singolo numero più utile nella scheda tecnica, e lo è doppiamente. Limita il calcolo per immagine a sei valutazioni del transformer invece delle venticinque-cinquanta necessarie a un modello non distillato, ed è proprio questo a rendere praticabili sedici megapixel. E significa che il solito ciclo di ottimizzazione del self-hosting — provare più step, aggiungere guidance, aggiungere un negative prompt, iterare — qui non esiste. Se la qualità dell'output delude, le leve sono il prompt e i riferimenti, non il sampler. I team che mettono in budget una settimana per "ottimizzare il modello" dovrebbero metterla in budget per il lavoro sui prompt.

Quanto costa ciascun percorso, nelle unità in cui viene effettivamente fatturato

L'API fattura i token, e gli esempi di calcolo riportati nella scheda sono il modo più chiaro per interpretarlo. Una richiesta text-to-image da 1.024×1.024 costa $0,02179. Una richiesta da 2.048×2.048 costa $0,02333 — 1,07 volte il prezzo per quattro volte i pixel, perché il numero di token cresce molto più lentamente dell'area. Una richiesta da 4.096×4.096 costa $0,06879 di listino, e $0,03439 con uno sconto del 50% a tempo limitato valido fino al 17 novembre 2026 alle 16:00 UTC e che richiede che l'immagine consegnata sia di almeno 16.600.000 pixel. Le tariffe del livello Standard sono $2,30 per milione di token di testo in input, $1,50 per milione di token immagine in input e $3,80 per milione di token immagine in output; il livello Highspeed mantiene le tariffe di input e applica $7,60 per l'output.

Leggi quei tre numeri insieme e l'argomento sul prezzo a favore del 4K si dissolve quasi del tutto. Quattro volte i pixel per 1,07 volte il costo passando al 2K è un regalo; passare dal 2K al 4K costa circa tre volte tanto per lo stesso quadruplo guadagno in area, e solo lo sconto lo riporta vicino alla tariffa del 2K. Se il tuo caso d'uso non richiede 4.096 pixel per lato, il livello 2K è dove questo modello costa poco.

OrcaRouter non serve MiniMax-H3-Image — non esiste alcuna route per questo qui, e la CTA in questo articolo rimanda al modello video gemello, minimax/minimax-h3, che invece instradiamo. Ciò che offriamo è rilevante per il giorno in cui la route esisterà: 0% di markup con il prezzo di listino del provider passato così com'è, il che significa che una variazione di prezzo del fornitore come quello sconto sul 4K arriva sulla tua fattura lo stesso giorno in cui arriva sulla pagina del fornitore, e failover automatico se un percorso del provider si degrada. Fino ad allora, il confronto che conta è la spesa API rispetto al tuo hardware, e nessun livello di routing cambia quell'aritmetica.

Self-hosting, con prezzi onesti

Nessuno può darti un preventivo per un costo di self-hosting per immagine senza sapere che GPU hai, perché il termine dominante è se 135 GB di pesi stiano in memoria o debbano essere offloadati. Ciò che si può dire con precisione: il sampler a sei step fissa il carico di calcolo, l'output da sedici megapixel fissa il budget di attivazioni, ed entrambi sono elevati. Una singola scheda da 80 GB conterrà il transformer ma non il transformer più l'encoder Qwen3-VL a piena precisione, quindi le configurazioni realistiche sono multi-GPU, oppure l'offload dell'encoder, oppure un transformer quantizzato con annessa una questione di qualità. Aggiungi la corrente elettrica, aggiungi la settimana di lavoro di un ingegnere per far funzionare correttamente il serving con SGLang o vLLM-Omni, e il punto di pareggio rispetto a $0.02333 per immagine 2K è un numero di volumi nell'ordine di centinaia di migliaia di immagini, non di decine.

Il che è l'argomento a favore dell'API nella maggior parte dei casi e l'argomento a favore dei pesi in alcuni: un'azienda che, per ragioni legate ai dati, ha bisogno del modello all'interno del proprio perimetro, oppure una che già esegue MiniMax-H3 e possiede l'encoder, oppure una che genera a un volume tale per cui il costo fisso si ammortizza. Tutti gli altri dovrebbero valutare innanzitutto il costo dell'API e ricorrere al self-hosting solo se il perimetro lo richiede davvero.

Leggere la licenza prima del download, non dopo

I pesi sono rilasciati con la MiniMax-H3-Image Community License Agreement, che non è Apache 2.0 e non è MIT. «Open-weight» è accurato; «open-source» è la parola che mette i team nei guai, e questo è il punto del processo in cui un avvocato dovrebbe leggere il file vero e proprio invece di un post su un blog — incluso questo. La domanda pratica è l'uso commerciale su larga scala e se la licenza contenga termini che si applicano al tuo prodotto, e a quella domanda c'è una risposta nel repository che nessun riassunto può sostituire.

C'è un secondo artefatto più piccolo di cui vale la pena essere a conoscenza: M​iniMax include un componente Context-IR per il modello e un modello opzionale prompt-expander, MiniMax-H3-Image-PE. L'expander spiega in parte perché il modello tollera prompt lunghi e dettagliati; è opzionale, è separato dai 68,65 GB ed è il tipo di cosa che si trova nell'elenco di un repository anziché in un annuncio.

Cosa controllare nel tuo stack questa settimana

• Riferimenti — conferma se il tuo percorso di serving supporta 16 immagini o le 9 documentate dalla ricetta vLLM-Omni, con una richiesta reale anziché una lettura della documentazione.

• Area effettiva — il modello funzionerà al di sotto dei sedici megapixel e la configurazione espone un'area minima di generazione predefinita a 4.194.304 pixel. Testa l'estremo inferiore se il tuo caso d'uso riguarda miniature, perché un modello di queste dimensioni potrebbe non essere l'opzione economica a 1K.

• Memoria — misura il picco di VRAM a 4.096×4.096 prima di acquistare l'hardware. Sei passaggi sono un calcolo a basso costo; le attivazioni no.

• Conto alla rovescia per lo sconto — se il piano è il 4K, l'aliquota del 50% termina il 17 novembre 2026 alle 16:00 UTC, e se tu sia sull'API o sulla tua infrastruttura determina se quella scadenza ti riguarda.

• Licenza — leggila. Il download è di 135 GB e la decisione è reversibile; la licenza non lo è.

La cosa interessante di questo rilascio non è che sia comparso un buon modello open per le immagini — è che, per la prima volta da un po', ne è comparso uno con i pesi, le ricette del framework e l'endpoint ospitato tutti disponibili nella stessa settimana. È un segnale più forte di un grafico di benchmark, perché significa che la cosa funziona. Se convenga eseguirlo o chiamarlo dipende interamente da quale delle tre porte si attraversa, e quelle tre porte sono molto più distanti di quanto l'annuncio faccia sembrare.