MiniMax M3.1 : ce que disent les documents d’aperçu fuités — et ce que personne n’a confirmé

Il y a un checkpoint de 250 Go sur Hugging Face nommé MiniMax-M3.1-preview-private que personne en dehors d'une poignée de partenaires d'inférence ne peut ouvrir. Il y a un document daté du 22 septembre qui se lit exactement comme la note d'architecture du fournisseur, circulant dans un dépôt public d'ingénierie partenaire plutôt que sur le site du fournisseur lui-même. Et le 26 septembre, un observateur de modèles largement suivi a publié que MiniMax M3.1 est « le prochain modèle à venir pour la semaine prochaine » et qu'ils testent déjà un aperçu de celui-ci. Rassemblez ces trois éléments et vous avez l'intégralité du dossier public de MiniMax M3.1 — un modèle dont le nom, les deltas d'architecture, le nombre de poids et la semaine d'arrivée sont tous en circulation, et dont le fournisseur n'a pas dit un mot en public. Le prédécesseur dont il descend, MiniMax M3, est une autre histoire : celui-là est sorti, et c'est la raison pour laquelle tout le monde s'intéresse à celui-ci.

Voici à quoi ressemble, de l’extérieur, un modèle non publié, et il vaut la peine d’être précis sur la forme des preuves, car les trois éléments ne sont pas aussi solides les uns que les autres. L’existence du checkpoint est corroborée : plusieurs sources indépendantes convergent vers le même nom de dépôt privé et le même nombre de fichiers. Le document d’architecture n’est pas corroboré de cette manière — c’est la transcription d’un tiers, et il pourrait être authentique, obsolète ou en partie inventé. L’affirmation concernant « la semaine à venir » est une attente personnelle, pas un calendrier. Tout dans cet article est étiqueté selon la force qu’il possède réellement, et rien ici ne doit être lu comme une annonce de sortie.

Ce qui rend MiniMax M3.1 digne d'un article avant même son existence, c'est son prédécesseur. MiniMax M3 était, de l'avis général, le modèle à poids ouverts le plus puissant que MiniMax ait livré — un modèle texte-image-vidéo de 1M de tokens qui a atteint 29,2 sur l'Artificial Analysis Intelligence Index et reste l'un des rares modèles ouverts capables de tenir véritablement un contexte long. Si M3.1 arrive lors de la dernière semaine de septembre, les chiffres qui comptent pour un développeur ne sont pas la plausibilité de la fuite, mais ce qui a changé dans les couches et ce que cela coûte à servir — et sur ces deux points, le document divulgué est inhabituellement précis.

Ce qui est confirmé, et ce qui ne circule qu’à l’état de rumeur

La répartition honnête, au 27 septembre 2026 :

• Confirmé : aucune version publique de MiniMax M3.1 n'existe. L'organisation MiniMaxAI sur Hugging Face renvoie 401 — la réponse « introuvable ou non visible pour vous » de la plateforme — pour MiniMaxAI/MiniMax-M3.1, MiniMaxAI/MiniMax-M3.1-preview et MiniMaxAI/MiniMax-M3.1-preview-private indistinctement. Ses publications publiques les plus récentes restent MiniMax-Music3 (7 août 2026) et MiniMax-H3 (28 juillet 2026).

• Confirmé : MiniMax M3.1 n'est routable nulle part où nous pouvons le vérifier. Il est absent du catalogue de modèles OrcaRouter et des listes publiques que nous surveillons ; le modèle MiniMax que vous pouvez réellement appeler aujourd'hui est MiniMax M3, à l'adresse minimax/minimax-m3.

• Confirmé : MiniMax n'a rien publié. Aucune fiche de modèle, aucun article de blog, aucune page de tarification, aucun poids, aucun ID de modèle API. Il n'y a pas de couverture médiatique d'un lancement car il n'y a pas eu de lancement.

• En circulation : le document d'architecture. Il est reproduit mot pour mot dans un dépôt public — longsco/innoferra-eval, une suite d'intégration des partenaires pour les points de terminaison de modèles hébergés, créée le 23 septembre 2026 — sous le nom de fichier PREVIEW-20260922.md, avec un en-tête le décrivant comme un document fournisseur partagé le 25 septembre et une mise en garde selon laquelle « le nom du modèle, la date de publication du fournisseur et le lancement public restent subordonnés à la sortie réelle ». C'est la réserve propre au document, pas la nôtre, et c'est la bonne : la copie, par un tiers, d'une note de fournisseur ne constitue pas une déclaration de MiniMax.

• En circulation : le checkpoint de 250 GB et sa deuxième livraison. La spécification d'intégration du dépôt indique un checkpoint multimodal privé à MiniMaxAI/MiniMax-M3.1-preview-private — 62 fichiers, 48 fichiers safetensors, environ 250 GB, chaîne d'architecture MiniMaxM3SparseForConditionalGeneration — puis une deuxième livraison plus importante, MiniMax-M3.1-preview2-dspark-private, avec 101 fichiers et environ 236 GB, qui ajoutait un brouillon spéculatif fp8 de 2,3 GB. Les deux sont privés. Nous ne pouvons ouvrir ni l'un ni l'autre, et vous non plus.

• En circulation : la chronologie. Le post du 26 septembre est la seule datation publique proposée, et « la semaine à venir » est une attente. Considérez la semaine du 28 septembre comme la fenêtre à surveiller, non comme une date.

Le seul document qui contient les détails techniques

Tout ce que l’on sait de précis sur la conception de MiniMax M3.1 remonte à ce seul fichier Markdown, ainsi qu’à deux documents qui l’accompagnent dans le même dépôt : un document de démonstration SGLang décrivant comment le checkpoint est censé être servi, et un spec.yaml qu’un point de terminaison partenaire est censé respecter. Si l’on lit le dépôt dans son ensemble, il ressemble à un fournisseur d’inférence qui fait exactement ce que fait un fournisseur d’inférence — recevoir une préversion de MiniMax, consigner ce qui a changé et construire une suite de validation pour celle-ci. Le dépôt n’est pas un kit de presse et il n’est pas écrit pour convaincre qui que ce soit.

C’est un point en sa faveur, et c’est aussi la limite de ce que cela prouve. Rien en son sein n’est signé par MiniMax. Les trois documents concordent entre eux de la manière dont de vrais documents concordent — les mêmes constantes de quantification, les mêmes noms de variables d’environnement, les mêmes indicateurs de lancement — et divergent de la manière dont de vraies livraisons divergent : l’aperçu du 22 septembre indique que la nouvelle méthode de décodage spéculatif n’a pas de tête de confiance, et la deuxième livraison de checkpoint a fourni une configuration préliminaire avec enable_confidence_head défini sur true. Une fabrication n’inclurait généralement pas d’arc de correction. Mais « inhabituellement cohérent » ne veut pas dire « confirmé », et le mode de défaillance pour un lecteur consiste à absorber les constantes ci-dessous comme la conception publiée de MiniMax alors qu’elles sont, au mieux, la conception privée de MiniMax telle que lue par quelqu’un d’autre.

Les cinq modifications d’ingénierie, selon ce document

Voici l’écart entre MiniMax M3 et MiniMax M3.1 tel que le document le décrit. Chaque ligne est issue du fournisseur et non auditée — aucune partie indépendante n’a mesuré une sortie de MiniMax M3.1, de quelque type que ce soit.

• Couverture de l’attention. L’attention complète dans les trois premières couches est remplacée par de l’attention éparse, de sorte que toutes les couches sont éparses. Sur MiniMax M3, les trois premières couches constituaient l’ancre d’attention complète de la pile éparse.

• Précision de l'attention — « Q8KV4 ». Les requêtes, y compris celles de l'indexeur, sortent de la projection en BF16 et sont converties en FP8 E4M3. Les clés et les valeurs — là encore, y compris celles de l'indexeur — sont quantifiées en E2M1, sur quatre bits, par blocs de 16, avec une échelle E4M3 par bloc de amax/6, limitée à [1/512, 448]. Le document insiste sur le fait que l'échelle de quantification suit un arrondi au pair le plus proche (round-half-to-even) avec des seuils asymétriques, que l'échelle du tenseur externe vaut exactement 1, et qu'une magnitude nulle doit être encodée comme zéro positif. M3 utilisait un chemin KV de huit bits de la même famille, ce qui réduit encore de moitié les octets KV.

• Précision experte. Les experts routés du MoE passent de MXFP8 à W4A4 NVFP4, l'expert partagé étant délibérément exclu. Les deux projections d'experts reçoivent des schémas d'activation différents : FC1 utilise une échelle dynamique par ligne de 2688 divisée par le maximum absolu de la ligne, l'échelle de ligne étant appliquée après le GEMM mais avant la fonction d'activation ; FC2 utilise une échelle externe fixe de 16. La conséquence pratique, explicitée dans le README du partenaire, est sans détour : « un fournisseur qui fait passer le checkpoint par un chemin NVFP4 générique sans ces éléments produira des résultats numériques silencieusement différents. »

• Décodage spéculatif. La tête de prédiction multi-jetons de style EAGLE a disparu, remplacée par une méthode que MiniMax appelle DSpark — une tête de Markov standard et, dans le document du 22 septembre, pas de tête de confiance. C'est le changement qui a le plus grand effet sur ce que l'on ressent d'un point de terminaison servi, car c'est le seul levier de vitesse par flux dans la conception. Le moteur de démonstration livré par MiniMax avec le checkpoint n'inclut pas DSpark, et le fournisseur a mesuré l'écart : sur la même fenêtre de 80 000 jetons sans spéculation, le débit par flux est de 63,9 jetons par seconde avec une concurrence de 1 et tombe sous les 60 avec une concurrence de 4, de sorte que la conclusion du document lui-même est que, sans DSpark, la pile ne peut pas tenir son objectif de latence sous charge.

• Un nouveau champ de requête. MiniMax M3.1 ajoute un champ reasoning_effort de premier niveau prenant max, xhigh, high, medium ou low, injecté dans le prompt système sous forme d'étiquette d'effort par le template de chat. M3 ne disposait que d'un interrupteur thinking avec adaptive et disabled. Le document note, curieusement et spécifiquement, que le champ est transmis sans validation ni valeur par défaut obligatoire — ce que le fournisseur a interprété comme la permission d'accepter ou de rejeter une valeur non listée, et ce qui signifie que deux points de terminaison conformes pourraient se comporter différemment sur la même requête.

Deux détails du checkpoint méritent d’être signalés séparément, car ils font partie de ces éléments qu’un article de lancement omet. Premièrement, le checkpoint embarque à la fois une configuration de préprocesseur d’images et une configuration de préprocesseur vidéo — MiniMax M3.1 est un modèle multimodal par construction, et non un modèle textuel auquel la vision a été greffée après coup, et les consignes du fournisseur lui-même sont de ne pas rejeter les entrées d’images sur la nouvelle pile. Deuxièmement, la deuxième livraison du checkpoint a entièrement supprimé les clés MTP et NEXTN et n’a rien ajouté qui puisse s’y substituer, ce qui explique pourquoi le draft DSpark a dû arriver sous la forme d’un artefact distinct de 2,3 Go. Il n’y a pas de tête de draft dans les poids principaux à activer.

Pourquoi il n'y a pas de chiffres de benchmark pour M3.1, et pourquoi ce n'est pas un oubli

Chaque article sur une fuite finit par arriver au passage où, soit il invente un tableau de benchmarks, soit il admet qu’il n’en a aucun. MiniMax M3.1 n’en a aucun. La spécification du partenaire le dit explicitement, dans un champ qui existe uniquement pour empêcher quelqu’un de commettre l’erreur :

• « Aucune base de référence 3.1 publiée à ce jour ; ne pas réutiliser les chiffres M3 comme seuils d'acceptation. »

Cette instruction est la phrase la plus utile de tout le corpus, car la version paresseuse de cet article inscrit les scores Artificial Analysis de MiniMax M3 sous un titre MiniMax M3.1. Ce ne devrait pas être le cas. Le même dépôt exécute des sondes AIME-25 et GPQA-Diamond contre l’endpoint M3.1 propre à MiniMax et les enregistre comme des comparaisons équipier-contre-fournisseur, les scores n’étant pas stabilisés : sur GPQA-Diamond, 0,904 pour l’exécution de l’équipe contre 0,813 pour celle du fournisseur, et sur un sous-ensemble MMLU-Pro de 600 questions, 0,898 contre 0,821. Ce sont deux exécutions de la même évaluation qui ne concordent pas, et non un résultat de modèle, et elles sont étiquetées comme un aperçu, avec les répétitions comptabilisées. Quiconque cite aujourd’hui un seul chiffre de benchmark MiniMax M3.1 cite quelque chose qui n’existe pas encore.

Ce qu'est MiniMax M3, afin de pouvoir dimensionner la suite

MiniMax M3 est sorti fin mai 2026 et a été mis en ligne sur Hugging Face le 2 juin — 428 milliards de paramètres au total avec 23 milliards actifs, 60 couches, 128 experts routés avec un routage top-4, 4 têtes KV contre 64 têtes d’attention, et une fenêtre de contexte de 1 048 576 tokens avec une sortie maximale de 512 000. Du côté indépendant, Artificial Analysis lui attribue 29,2 sur l’Intelligence Index, ce qui le place 60e sur 145 modèles échantillonnés, avec 58,6 sur l’indice de codage et un p50 de 3 348 millisecondes jusqu’au premier token dans notre propre télémétrie de routage. Le chiffre phare de MiniMax lui-même pour ce modèle est 83,5 sur BrowseComp, qui est un chiffre fournisseur et non audité en tant que tel.

Les tarifs sont l'élément qui vieillit le mieux dans un cycle de fuite. MiniMax M3, c'est 0,30 $ par million de tokens d'entrée et 1,20 $ par million de tokens de sortie, avec les lectures en cache à 0,06 $ — et il est disponible sur OrcaRouter sous minimax/minimax-m3, au tarif catalogue du fournisseur avec 0 % de marge, donc si MiniMax applique le même tarif à M3.1, le nouveau tarif est en vigueur chez nous le jour où il existe, plutôt qu'un cycle de facturation plus tard.

Le but de répéter tout cela n'est pas la nostalgie. C'est que la raison même pour laquelle on rafraîchit une page d'organisation Hugging Face cette semaine, c'est que MiniMax M3 était assez bon pour que son successeur soit une question de production plutôt qu'un sport de spectateur — et qu'un modèle de 428 milliards de paramètres avec un contexte de 1M à 0,30 $/1,20 $ fixe une barre de prix-performance que M3.1 doit franchir, pas seulement une barre de capacité.

L’angle de l’annonce anonyme, et pourquoi il y a peut-être déjà une réponse

Un fil de discussion du début septembre mérite d'être clos ici. Une annonce furtive anonyme est apparue sur une plateforme de codage tierce avec un contexte de 1 000 000 de tokens, un tarif de 0 $ et des niveaux de raisonnement obligatoires, et nous l'avons traitée sous le nom de Space Bunny Alpha, en notant le taux de base selon lequel toute annonce anonyme de ce type finit par être revendiquée par un fournisseur — Pony Alpha est devenu un modèle Zhipu, Hunter Alpha est devenu celui de Xiaomi, Ox Alpha est devenu une sortie MiniMax sous un autre nom. Le tokeniseur et les empreintes d'anomalies de cette annonce pointaient vers un checkpoint de préversion de MiniMax. Si MiniMax M3.1 arrive bien cette semaine, l'interprétation la plus probable est que l'annonce anonyme était son test sur le terrain, et le mystère se résout par une annonce plutôt que par un travail forensique plus poussé. C'est une inférence, pas une preuve, et c'est la dernière inférence de cet article.

Ce qu’il faut surveiller et ce qu’il faut faire cette semaine

Les signaux qui feraient passer ceci d’une fuite à un lancement sont précis et vérifiables, et ce ne sont pas ceux que la plupart des analyses suivent. Un dépôt Hugging Face public sous l’organisation MiniMaxAI — et non privé — avec une fiche de modèle est l’indicateur unique le plus fort ; l’historique des téléversements de l’organisation est public et date chaque publication au jour près. Une page de modèle MiniMax ou un identifiant de modèle API vient en deuxième. Un prix publié est le troisième, et celui qui compte pour un budget. Un tableau de benchmarks sur Artificial Analysis daté d’après la sortie est le quatrième, et le seul à être indépendant.

D'ici là, la position pratique pour quiconque développe reste inchangée par rapport à toute autre semaine de pré-lancement : le modèle que vous pouvez router aujourd'hui est MiniMax M3, une seule clé API y donne accès aux côtés de plus de 200 autres modèles, le basculement automatique signifie qu'un flottement d'endpoint ne devient pas votre panne, et une route épinglée ou mixte via le DSL de routage ou un panel de modèles répondant ensemble via la fusion de modèles est la manière de réduire le risque lié à un modèle que vous n'avez pas mis en production. Si M3.1 arrive, c'est un échange d'un ID de modèle, pas une migration — ce qui est tout l'argument pour ne pas construire d'intégration sur mesure contre une fuite.

Une chose que cet article ne fera pas, c’est prétendre savoir quand. Le point de contrôle est réel, les documents sont précis, et la déclaration publique la plus récente est une personne qui dit « la semaine prochaine ». Sur les trois, seuls les deux premiers sont des choses que vous pouvez vérifier vous-même.