Un modèle ouvert de 428 milliards de paramètres qui avale un million de tokens et rivalise avec Gemini 3.1 Pro : voilà le titre que la plupart des comptes rendus retiendront. Mais ce n’est pas la bonne ligne. La taille de MiniMax M3 impressionne ; ce qui compte vraiment, c’est ce qui la rend tenable.
La taille n’a jamais été le problème
Empiler les paramètres, l’industrie sait faire. Le mur, depuis le début, c’est l’attention : son coût grimpe avec le carré du nombre de tokens (la fameuse complexité quadratique du softmax). Doubler la longueur de contexte, c’est quadrupler le calcul. À un million de tokens, l’addition devient ingérable en production.
C’est exactement ce que pointe le papier de MiniMax : les workflows agentiques, le raisonnement à l’échelle d’un dépôt de code entier, la mémoire persistante exigent tous que le modèle lise des centaines de milliers à des millions de tokens d’un coup. Sauf que la facture quadratique rend l’exercice intenable au moment du déploiement. Le vrai enjeu n’était donc pas d’écrire plus gros, mais de lire plus malin.
MiniMax Sparse Attention : lire moins pour lire mieux
La réponse s’appelle MiniMax Sparse Attention (MSA), une attention parcimonieuse par blocs. Le principe : au lieu de faire dialoguer chaque token avec tous les autres, le modèle filtre d’abord. Une branche légère (l’Index Branch) note les blocs de cache clé-valeur et sélectionne uniquement les plus pertinents (un Top-k), groupe par groupe ; la branche principale ne calcule ensuite une attention exacte que sur ces blocs retenus.
Le résultat ? Sur un modèle de 109 milliards de paramètres, MSA fait jeu égal avec l’attention classique (la Grouped Query Attention) tout en divisant par 28,4 le calcul d’attention par token à un contexte d’un million. Couplé à un kernel conçu sur mesure, cela donne, d’après l’équipe, un prefill 14,2 fois plus rapide et un décodage 7,6 fois plus rapide sur une carte H800.
La subtilité n’est pas que théorique. Chaque bloc de cache est lu une seule fois, en mémoire contiguë : d’après NVIDIA, qui a documenté le déploiement de M3 sur son infrastructure, c’est plus de quatre fois plus rapide que les implémentations de sparse attention existantes. NVIDIA chiffre le gain global à un vingtième du calcul par token de la génération précédente (M2) à contexte d’un million, sans compresser les clés-valeurs ni sacrifier la précision. C’est le pari inverse de DeepSeek, dont les variantes récentes (la sparse attention de la V3.2, puis la V4) compressent justement le cache clé-valeur pour tenir le million de tokens : MiniMax, lui, sélectionne des blocs entiers laissés intacts. La sparse attention, ici, ne rogne pas la qualité pour gagner en vitesse : elle change la nature du compromis.
L’open-weight rattrapé par l’efficience, pas par la force
C’est là que l’histoire devient intéressante pour qui orchestre l’IA au quotidien. Le compte officiel d’Unsloth annonce que MiniMax M3 (428B, dont 23B actifs) tourne désormais en local : une version quantifiée en 2 bits tient sur 138 Go de RAM ou VRAM, la version 3 bits sur 165 Go. On reste loin du laptop, mais ce sont des chiffres de station de travail haut de gamme ou de petit serveur, pas de datacenter loué à l’heure.
Faites le rapprochement. Un modèle ouvert qui prétend rivaliser avec un Gemini 3.1 Pro propriétaire, et qui tient sur une machine qu’une PME peut s’offrir : ce n’est pas la force brute qui rend ça possible, c’est l’efficience mémoire. La sparse attention est le levier qui transforme un poids lourd théorique en outil déployable hors du cloud des hyperscalers.
L’architecture y aide aussi. M3 est un Mixture-of-Experts : 128 experts au total, quatre seulement activés par token, soit 23 milliards de paramètres réellement sollicités à chaque pas. On ne paie que ce qu’on utilise. Et le modèle est nativement multimodal, entraîné sur texte, image et vidéo dès l’origine (environ 100 000 milliards de tokens entremêlés), plutôt que multimodal recollé après coup.
Ce que ça change pour un praticien
Concrètement, MSA ouvre des usages qui restaient des promesses :
- des sessions de programmation longues (NVIDIA évoque plus de huit heures continues) sans perdre le fil du dépôt ;
- la compréhension de vidéos longues et de documents massifs en une seule passe ;
- une mémoire persistante d’agent qui ne s’effondre pas sous le coût du contexte.
Le tout déployable avec les moteurs d’inférence open source habituels : SGLang, vLLM, ou TensorRT LLM pour le texte seul. L’autonomie redevient une option crédible.
Une efficience réelle, des zones d’ombre assumées
Restons lucides. Les chiffres de vitesse et le verdict « à parité avec la GQA » viennent du papier et de l’éditeur lui-même ; aucune évaluation indépendante de bout en bout n’est encore au dossier. « Rivalise avec Gemini 3.1 Pro » est une formule d’annonce, pas un benchmark arbitré. Et tourner un modèle en 2 bits, c’est accepter une dégradation de qualité dont l’ampleur reste à mesurer sur vos propres tâches.
Il y a aussi un coût caché : la sélection Top-k par blocs ajoute une logique que les implémentations naïves ne maîtrisent pas, d’où le kernel sur mesure publié par MiniMax. Sans lui, une partie des gains s’évapore. L’efficience ici n’est pas magique, elle est ingénierée.
Reste que le signal est clair. Pendant que la course aux paramètres occupe les gros titres, la vraie bascule se joue dans la manière dont les modèles gèrent leur mémoire. Si lire un million de tokens ne coûte plus vingt fois ce qu’il coûtait, la question pour les prochains modèles ne sera plus « combien de contexte », mais « qu’allons-nous enfin oser en faire » ?
