Une carte-titre intitulée « MiniMax-H3-Image — trois surfaces, trois choses différentes que vous obtenez », au-dessus de trois cartes indiquant « Hugging Face / 68,65 Go de poids plus un encodeur de texte de 66,7 Go », « API MiniMax / 0,02333 $ par image 2K » et « MiniMax Code et Hailuo / champ de prompt uniquement, aucun endpoint ».
Guides & Insights

MiniMax-H3-Image est disponible sur trois surfaces : ce que chacune vous fournit réellement

Auteur

Rowan Sterling

Date de publication

Derniers modèles · 20Voir tous les modèles →
Benchmarks : Artificial Analysis · mis à jour quotidiennement
Retour à tous les articles

La phrase vraie la plus courte sur MiniMax-H3-Image cette semaine est qu’il est disponible à trois endroits : Hugging Face, M​iniMax Code et l’API propre à M​iniMax. La phrase dont un acheteur a réellement besoin est plus précise. Deux de ces trois vous fournissent un point de terminaison de requête et une grille tarifaire ; l’un vous remet 135 gigaoctets de poids, une licence à lire et un choix de matériel à faire. Ce ne sont pas trois variantes d’un même accès, et les traiter comme interchangeables est la façon dont une équipe finit par consacrer une semaine à quelque chose qu’elle aurait pu acheter à l’image pour deux centimes.

Le modèle lui-même est une véritable sortie plutôt qu'un reconditionnement. M​iniMax a mis les poids dans le dépôt Hugging Face MiniMaxAI/MiniMax-H3-Image le 10 novembre 2026 à 14:50 UTC et a publié un message à ce sujet à 15:40 l'après-midi même ; le dépôt lui-même date du 3 novembre, soit une semaine pendant laquelle les poids ont existé en privé avant que quiconque puisse les télécharger. C'est un transformateur de diffusion de 33,1 milliards de paramètres qui génère à environ seize mégapixels, ce qui correspond au « 4K » de l'annonce, et il assure la génération texte-image et l'édition guidée par référence à partir d'un seul checkpoint. Ce qui suit est organisé autour de la seule question à laquelle l'annonce ne répond pas : sur quelle surface faut-il se trouver ?

Trois portes d'entrée, et une seule d'entre elles est un téléchargement

Commencez par ce qu’est chaque porte, car la différence est structurelle, pas cosmétique.

L'API est la voie conventionnelle. Le modèle est répertorié comme MiniMax-H3-Image avec une variante Highspeed, sur les plateformes internationales et de Chine continentale de MiniMax, facturé par million de tokens en entrée et en sortie plutôt que par image. L'interface est étonnamment prescriptive — six étapes d'échantillonnage, aucune échelle de guidage, aucun prompt négatif — et la documentation de référence de MiniMax indique elle-même qu'une requête demandant autre chose renvoie une erreur HTTP 400. Vous achetez un point de terminaison fonctionnel avec une recette fixe à l'intérieur.

M​iniMax Code et Hailuo AI sont des surfaces produit : le même modèle derrière une zone de prompt, avec les décisions d'échantillonnage déjà prises et aucun calcul par token à effectuer de votre côté. Utiles pour évaluer si la sortie est bonne ; inutiles pour construire quoi que ce soit, car ce sur quoi vous construiriez n'est pas exposé. Notez aussi que M​iniMax Code est un produit d'agent de codage, donc la génération d'images y est une porte latérale plutôt que la fonction principale — ne lisez pas « disponible sur M​iniMax Code » comme une API d'image avec une surcouche de code.

Hugging Face est la troisième porte, et c’est la seule qui soit un transfert plutôt qu’un service. Vous obtenez un dépôt, un fichier de licence et un ensemble de poids que vous devez désormais faire fonctionner. L’auto-hébergement est la raison pour laquelle la plupart des équipes s’intéressent ne serait-ce qu’à un modèle d’image à poids ouverts ; c’est aussi là que le calcul cesse de porter sur le modèle et commence à porter sur votre rack.

A screenshot of the Hugging Face model card for MiniMaxAI/MiniMax-H3-Image, showing the text-to-image and image-to-image tags, the Diffusers and Safetensors badges, the minimax-h3-image-community-license-agreement licence line under the model name, and a like count of 214.

Le dépôt est plus lourd que ne le laisse supposer le nombre de paramètres annoncé.

33,1 milliards de paramètres en BF16 représentent environ 66 Go avant même de compter quoi que ce soit d'autre, et c'est dans ce « quoi que ce soit d'autre » que le dépôt surprend les gens. Le transformateur de diffusion à lui seul fait 66,28 Go. Le téléchargement complet est de 68,65 Go, ce qui correspond au transformateur plus le VAE et la configuration. L'encodeur de texte n'est pas inclus dans ce chiffre : MiniMax-H3-Image réutilise l'encodeur de texte Qwen3-VL du dépôt vidéo MiniMax-H3, lit à partir de sa couche 50, et cet encodeur représente un téléchargement séparé de 66,7 Go. Prévoyez donc environ 135 Go d'artefacts sur disque avant la première image, et cela avant même le cache propre à tout framework.

L’architecture mérite un paragraphe, car elle indique ce qu’est le modèle. Cinquante couches de transformer, une taille cachée de 5 376, 56 têtes d’attention, une largeur feed-forward de 14 336, avec des embeddings positionnels rotatifs multimodaux tridimensionnels. Le VAE est un encodeur convolutif associé à un décodeur ViT bidimensionnel de 24 couches, avec un sous-échantillonnage spatial de 16× et 24 canaux latents — un choix de décodeur qui demande plus de calcul en fin de pipeline qu’un simple décodeur convolutif, et qui est vraisemblablement à l’origine d’une partie des détails fins en 4K. La conception est décrite dans la fiche du modèle comme l’architecture H3 sans l’audio, ce qui est un résumé fidèle : il s’agit de la branche image du modèle vidéo, livrée seule.

Deux conséquences en découlent. Premièrement, un transformateur de diffusion de classe 33B à seize mégapixels n’est pas un modèle pour ordinateur portable, quel que soit l’effet que le nombre de paramètres peut donner à côté des modèles de langage modernes ; la mémoire d’activation évolue avec la surface de sortie, et la surface est tout l’intérêt de cette publication. Deuxièmement, comme l’encodeur de texte est partagé avec le modèle vidéo, une boutique qui exécute déjà MiniMax-H3 dispose déjà sur disque de la majeure partie du téléchargement. C’est une véritable économie, et c’est le genre de chose que la mention « disponible sur Hugging Face » ne transmet pas.

A screenshot of MiniMax's release-notes page dated Nov. 10, 2026, with an entry headed "MiniMax H3 Image — A leading open-weight image model".

Quatre façons de le servir, et un chiffre qui ne concorde pas

La fiche modèle répertorie quatre voies : SGLang, vLLM-Omni, diffusers et ComfyUI. L’équipe de vLLM a assuré un support dès le jour du lancement dans vLLM-Omni pour le matériel NVIDIA comme AMD, avec une sortie native d’environ seize mégapixels, ce qui constitue un signal de lancement plus fort que l’existence même des poids — quelqu’un extérieur à M​iniMax l’avait déjà fait tourner alors que l’annonce n’avait pas une heure. Diffusers couvre la voie de référence, et ComfyUI couvre le public des graphes de workflow.

Ce désaccord mérite d’être signalé, car il finira par poser problème à quelqu’un. La fiche modèle décrit l’édition avec jusqu’à 16 images de référence, désignées par leur position sous la forme <Picture 1> à <Picture 16> dans l’ordre de téléversement. La recette de publication vLLM-Omni pour le même modèle documente jusqu’à 9 images par requête. Les deux peuvent être vrais en même temps — la limite de service d’un framework et la capacité d’entraînement d’un modèle sont des nombres différents, et une contrainte de traitement par lots ou de mémoire dans la pile de service sera la première à s’imposer — mais si votre flux de travail a besoin de douze références, la réponse honnête aujourd’hui est que la capacité existe et que le chemin de service documenté peut ne pas la prendre en charge. Testez le nombre sur votre pile plutôt que de faire confiance à l’un ou l’autre document.

La même prudence s’applique à la fenêtre de prompt. La carte accepte jusqu’à 32 000 caractères, dont environ les 4 096 premiers tokens sont ceux sur lesquels le modèle se conditionne réellement. Un prompt long n’est pas rejeté ; la fin ne fait simplement aucun travail. Quiconque transpose un prompt détaillé de direction artistique par habitude des modèles de langage le découvrira à ses dépens.

L’échantillonneur est une contrainte dont vous héritez, pas un réglage que vous ajustez.

Six étapes, pas de guidage sans classifieur, pas de prompts négatifs. Ce n’est pas une valeur par défaut que l’on peut dépasser ; l’API rejette purement et simplement les autres nombres d’étapes et valeurs de guidage. Le modèle est distillé pour fonctionner en six passes avant, et c’est uniquement grâce à cette distillation qu’un transformeur de 33 B peut produire une image de seize mégapixels assez rapidement pour être utile.

Pour la voie API, c’est invisible et sans problème. Pour la voie auto-hébergée, c’est le nombre le plus utile de la fiche technique, et ce à double titre. Il plafonne le calcul par image à six évaluations de transformer au lieu des vingt-cinq à cinquante dont aurait besoin un modèle non distillé, ce qui rend seize mégapixels réellement exploitable. Et cela signifie que la boucle de réglage habituelle en auto-hébergement — essayer plus d’étapes, ajouter un guidage, ajouter un prompt négatif, itérer — n’existe pas ici. Si la qualité de sortie déçoit, les leviers sont le prompt et les références, pas l’échantillonneur. Les équipes qui prévoient une semaine pour « régler le modèle » devraient plutôt la prévoir pour le travail sur les prompts.

Combien coûte chaque parcours, dans les unités dans lesquelles il est réellement facturé

L'API facture des tokens, et les exemples chiffrés de la fiche tarifaire sont le moyen le plus clair de le comprendre. Une requête texte-image en 1,024×1,024 coûte $0.02179. Une requête en 2,048×2,048 coûte $0.02333 — 1,07 fois le prix pour quatre fois plus de pixels, car le nombre de tokens augmente bien plus lentement que la surface. Une requête en 4,096×4,096 coûte $0.06879 au tarif catalogue, et $0.03439 avec une remise de 50 % à durée limitée, valable jusqu'au 17 novembre 2026 à 16:00 UTC et exigeant que l'image livrée fasse au moins 16 600 000 pixels. Les tarifs du niveau Standard sont de $2.30 par million de tokens de texte en entrée, $1.50 par million de tokens d'image en entrée et $3.80 par million de tokens d'image en sortie ; le niveau Highspeed conserve les tarifs d'entrée et facture $7.60 pour la sortie.

Si l'on considère ces trois chiffres ensemble, l'argument tarifaire en faveur de la 4K s'évapore en grande partie. Quatre fois plus de pixels pour 1,07 fois le prix au palier 2K, c'est un cadeau ; passer de la 2K à la 4K coûte environ trois fois plus cher pour le même gain de surface quadruplé, et seule la remise le ramène près du tarif 2K. Si votre cas d'usage n'a pas besoin de 4 096 pixels par côté, c'est au palier 2K que ce modèle est bon marché.

OrcaRouter ne propose pas MiniMax-H3-Image — aucune route ne lui est associée ici, et le CTA de cet article pointe vers l'équivalent vidéo, minimax/minimax-h3, que nous routons bien. Ce que nous proposons est pertinent pour le jour où cette route existera : 0 % de marge, avec le prix catalogue du fournisseur répercuté tel quel, ce qui signifie qu'une modification tarifaire d'un fournisseur comme cette remise 4K se répercute sur votre facture le jour même où elle apparaît sur la page du fournisseur, et un basculement automatique en cas de dégradation d'un chemin fournisseur. D'ici là, la comparaison qui compte est celle des dépenses API par rapport à votre propre matériel, et aucune couche de routage ne change ce calcul.

A screenshot of MiniMax's image pricing page showing a limited-time offer of 50% off 4K image generation until November 17, 2026 at 16:00 UTC for delivered images of at least 16,600,000 pixels, the per-million-token image generation rate table, and a detached sentence fragment at the top reading "ith x height)." where the banner is cut by the sticky header.

Auto-hébergement, un prix honnête

Personne ne peut vous citer un coût d'auto-hébergement par image sans connaître votre GPU, car le terme dominant est de savoir si 135 Go de poids tiennent en mémoire ou doivent être déchargés. Ce que l'on peut affirmer précisément : l'échantillonneur en six étapes fixe le calcul, la sortie de seize mégapixels fixe le budget d'activations, et les deux sont élevés. Une seule carte de 80 Go contiendra le transformateur, mais pas le transformateur plus l'encodeur Qwen3-VL en pleine précision ; les configurations réalistes sont donc le multi-GPU, le déchargement de l'encodeur, ou un transformateur quantifié avec une question de qualité associée. Ajoutez l'électricité, ajoutez la semaine-ingénieur nécessaire pour faire fonctionner correctement SGLang ou vLLM-Omni en serving, et le seuil de rentabilité face à 0,02333 $ par image 2K devient un volume de l'ordre de centaines de milliers d'images, pas de dizaines.

L’argument en faveur de l’API dans la plupart des cas, et en faveur des poids dans quelques-uns, est le suivant : une boutique qui a besoin du modèle dans son propre périmètre pour des raisons de données, ou une autre qui exploite déjà MiniMax-H3 et détient l’encodeur, ou une autre encore qui génère à un volume où le coût fixe s’amortit. Tous les autres devraient d’abord évaluer le coût de l’API et ne s’auto-héberger que si le périmètre l’exige vraiment.

Lire la licence avant le téléchargement, pas après

Les poids sont publiés sous la MiniMax-H3-Image Community License Agreement, qui n’est ni Apache 2.0 ni MIT. « Open-weight » est exact ; « open-source » est le mot qui attire des ennuis aux équipes, et c’est le moment, dans le processus, où un juriste devrait lire le fichier réel plutôt qu’un article de blog — y compris celui-ci. La vraie question est l’utilisation commerciale à grande échelle et de savoir si la licence comporte des conditions qui s’attachent à votre produit, et cette question a une réponse dans le dépôt qu’aucun résumé ne remplace.

Il existe un second artefact, plus petit, qu’il vaut la peine de connaître : MiniMax fournit un composant Context-IR pour le modèle, ainsi qu’un modèle d’extension de prompt facultatif, MiniMax-H3-Image-PE. L’extenseur explique en partie pourquoi le modèle tolère des prompts longs et détaillés ; il est facultatif, il est distinct des 68,65 Go, et c’est le genre de chose que l’on trouve dans la liste d’un dépôt plutôt que dans une annonce.

Ce qu’il faut vérifier sur votre propre stack cette semaine

• Références — confirmez si votre chemin de service respecte 16 images ou les 9 documentées par la recette vLLM-Omni, au moyen d’une requête réelle plutôt que d’une simple lecture de documentation.

• Surface utile — le modèle fonctionnera en dessous de seize mégapixels, et la configuration expose une surface de génération minimale définie par défaut à 4 194 304 pixels. Testez le bas de la plage si votre cas d’usage concerne les vignettes, car un modèle de cette taille pourrait ne pas être l’option économique en 1K.

• Mémoire — mesurez la VRAM de pointe en 4 096 × 4 096 avant d'acheter du matériel. Six étapes, c'est du calcul peu coûteux ; les activations, elles, ne le sont pas.

• Compte à rebours de la remise — si la 4K est au programme, le tarif à 50 % se termine le 17 novembre 2026 à 16:00 UTC, et le fait d’être sur l’API ou sur votre propre matériel détermine si cette échéance vous concerne.

• Licence — lisez-la. Le téléchargement fait 135 Go et la décision est réversible ; la licence ne l'est pas.

Ce qui est intéressant avec cette sortie, ce n’est pas qu’un bon modèle d’image ouvert soit apparu — c’est que, pour la première fois depuis un moment, l’un d’eux est apparu avec les poids, les recettes de framework et le point de terminaison hébergé tous disponibles la même semaine. C’est un signal plus fort qu’un graphique de benchmark, car cela signifie que la chose tourne. Que vous deviez l’exécuter vous-même ou l’appeler dépend entièrement de laquelle des trois portes vous franchissez, et ces trois portes sont bien plus éloignées les unes des autres que l’annonce ne le laisse entendre.