MiniMax M2.7 : le troisième modèle du réseau Gonka

MiniMax M2.7 est un grand modèle linguistique (LLM) de la société MiniMax, basée à Shanghai. MiniMax a été fondée en 2021 par une équipe de chercheurs dirigée par Yan Junjie (anciennement chez SenseTime) et est rapidement devenue l'un des principaux laboratoires d'IA en Chine. La société a levé des fonds auprès d'Alibaba, Tencent et HongShan – le même cercle d'investisseurs stratégiques qui se cache derrière d'autres « tigres chinois de l'IA », y compris Moonshot AI, le développeur de Kimi K2.6.

Au-delà des modèles linguistiques purs, MiniMax est connue pour ses produits de consommation : les assistants de conversation Talkie et Hailuo, ainsi que l'un des générateurs vidéo les plus remarquables de l'industrie. Mais pour le réseau Gonka, la série de modèles textuels M, successeurs des modèles abab antérieurs, est particulièrement importante.

La principale caractéristique architecturale de la série M est l'accent mis sur un mécanisme d'attention efficace. Si les premiers grands modèles utilisaient l'attention quadratique classique (le coût de calcul augmente proportionnellement au carré de la longueur du contexte), MiniMax a été l'une des premières à rendre l'attention linéaire hybride accessible au public. Cela permet de traiter des séquences très longues sans une augmentation explosive du coût de calcul – une marque de fabrique historique de la gamme. Comme Qwen3-235B et Kimi K2.6, le modèle est construit sur l'architecture MoE (Mixture of Experts) : des centaines de milliards de paramètres « sur le papier », mais seule une petite partie d'entre eux est activée pour chaque requête, ce qui réduit radicalement le coût d'inference.

Dans le réseau Gonka, le modèle est identifié comme MiniMaxAI/MiniMax-M2.7 – c'est la chaîne de caractères à transmettre dans le champ model de la requête API. La version M2.7 est la dernière itération de la série M au moment de la publication de cet article.

Il est important de distinguer les caractéristiques du modèle «prêt à l'emploi» et les caractéristiques avec lesquelles il est déployé dans un réseau spécifique. Lorsque le modèle fonctionne dans le réseau décentralisé Gonka, ses paramètres de fonctionnement sont définis par la configuration vLLM-inference côté hôtes GPU, et pas seulement par l'architecture du modèle. Voici les valeurs réelles que notre Gateway renvoie:

• Fenêtre contextuelle: 131 072 jetons (environ 100 000 mots). C'est la configuration du sous-réseau dans le réseau Gonka. L'architecture MiniMax elle-même prend en charge un contexte considérablement plus long, mais le plafond pratique à tout moment est défini par la configuration d'inference sur les hôtes.
• Sortie maximale: 4 096 jetons par réponse. Ce chiffre est mesuré empiriquement - par une requête avec une génération longue forcée, qui a atteint le plafond (finish_reason: length). À titre de comparaison, pour Qwen3-235B, ce plafond est de 8 192, pour Kimi K2.6, il est de 3 072 jetons. Ce n'est pas une limite du modèle lui-même, mais une configuration du sous-réseau vLLM.
• Exigence VRAM de l'hôte: environ 320 Go de VRAM par nœud. C'est une exigence typique pour un grand modèle MoE en quantification FP8 – les mêmes 320 Go sont nécessaires pour Qwen3-235B et Kimi K2.6. En pratique, cela signifie plusieurs GPU de classe H100/H200 combinés en un seul nœud.

Le prix de l'inference dans le réseau Gonka ne dépend pas du choix du modèle et est déterminé par les paramètres du réseau: via JoinGonka Gateway, MiniMax M2.7 est disponible au même tarif que Qwen et Kimi. Le prix unifié est une conséquence du fait que le réseau est basé sur un calcul de coût unique pour le travail de calcul, et non sur le prix d'un fournisseur spécifique.

Pour la première fois, l'utilisateur du réseau Gonka a le choix entre trois modèles phares, et tous trois sont accessibles via une interface unique compatible OpenAI : le JoinGonka Gateway. La comparaison ci-dessous aide à comprendre non pas « lequel est le meilleur », mais pour quel profil de tâches chacun est optimisé.

Une mise en garde importante concernant les benchmarks en 2026 : l'écart entre les meilleurs modèles open-weights dans les tests publics s'est réduit à quelques pourcentages, et cette différence se situe souvent dans la marge d'erreur statistique des benchmarks eux-mêmes. Pour le travail pratique, ce n'est pas le classement absolu au MMLU qui compte, mais la nature de la tâche : longueur du contexte, complexité des chaînes logiques, langue requise, présence du tool calling.

Orientation pratique : pour les tâches avec de très longs documents et le traitement en continu de gros volumes de texte, il est judicieux de tester MiniMax M2.7 – l'attention efficace de sa série est historiquement conçue pour de tels scénarios. Pour un travail multilingue universel et un tool calling stable en production, Qwen3-235B est une option éprouvée. Pour les tâches de raisonnement avec une logique complexe, il faut opter pour Kimi K2.6. La meilleure stratégie en production est de conserver les trois modèles dans le code et de basculer entre eux avec un seul paramètre model sans modifier l'architecture de l'application.

L'ajout de MiniMax M2.7 n'est pas un «téléchargement de fichier sur le serveur», mais le résultat d'une mise à niveau réseau qui est passée par un vote on-chain. La prise en charge du modèle a été incluse dans la version du protocole v0.2.13, approuvée par la proposition #54 : elle a été adoptée le 21 mai 2026 (environ 63% des voix «pour») et activée à une hauteur de bloc donnée. C'est le même mécanisme de gouvernance par lequel le réseau adopte tout changement significatif - des tarifs aux nouveaux modèles.

La multimodalité pour un réseau décentralisé est une étape fondamentale. Un réseau lié à un seul modèle est fondamentalement fragile : la sortie d'une nouvelle version d'un modèle se transforme en crise de migration, et toute défaillance du modèle unique fait s'effondrer tout le service. Un réseau capable de gérer plusieurs modèles simultanément évolue en douceur : de nouveaux modèles sont ajoutés comme des «pistes» supplémentaires, les anciens continuent de fonctionner, et les hôtes GPU ont le choix de ce qu'il faut servir. Techniquement, chaque modèle vit dans son propre shard du réseau - ce même mécanisme (DevShards) a été utilisé précédemment pour lancer Kimi K2.6.

Une nuance distincte des premières étapes: il peut y avoir un décalage entre «le modèle apparaît dans la liste du réseau» et «le modèle est ouvert à tous les clients». Au début, l'inférence MiniMax M2.7 en mode broker n'était disponible que pour les clés privilégiées et renvoyait une erreur pour les requêtes normales - une phase de rodage normale. Fin mai 2026, l'accès public s'est ouvert et le modèle est devenu disponible pour tous les clients de Gateway. Pour plus de détails sur le fonctionnement du réseau et pourquoi les modèles sont lancés de cette manière, consultez l'article sur l'architecture du réseau Gonka.

Le moyen le plus direct est via le JoinGonka API Gateway. Étant donné que Gateway fournit une API compatible OpenAI, le même code qui fonctionne avec GPT, Claude, Qwen ou Kimi commencera à fonctionner avec MiniMax après avoir modifié la valeur du champ model.

Un exemple minimal via curl:

curl https://gate.joingonka.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMaxAI/MiniMax-M2.7",
    "messages": [
      {"role": "user", "content": "Explique brièvement ce qu'est l'attention linéaire"}
    ]
  }'

La même requête en Python via la bibliothèque openai:

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://gate.joingonka.ai/v1",
)

response = client.chat.completions.create(
    model="MiniMaxAI/MiniMax-M2.7",
    messages=[{"role": "user", "content": "Bonjour, MiniMax"}],
)
print(response.choices[0].message.content)

Streaming (Server-Sent Events) – pour les interfaces interactives où la réponse est affichée au fur et à mesure de la génération:

stream = client.chat.completions.create(
    model="MiniMaxAI/MiniMax-M2.7",
    messages=[{"role": "user", "content": "Écris un court essai sur un long contexte"}],
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

Lors de l'inscription au JoinGonka Gateway, vous recevez 10 millions de jetons gratuits pour tester tous les modèles du réseau – cela suffira pour comparer les trois modèles sur vos propres tâches.

Compatibilité avec les outils de développement : tout ce qui fonctionne avec l'API OpenAI fonctionne également avec MiniMax via Gateway. Il suffit de modifier le paramètre model :

• Cursor : dans les paramètres du modèle personnalisé, spécifiez MiniMaxAI/MiniMax-M2.7
• Claude Code, Cline, Continue.dev : le nom du modèle dans la configuration
• LangChain, n8n : le paramètre model lors de l'initialisation du client

La liste actuelle des modèles est toujours disponible à l'endpoint GET /v1/models – il est pratique de la récupérer dynamiquement pour que votre interface utilisateur affiche l'ensemble le plus récent. Si la réponse est 429 too many concurrent requests – c'est une phase normale pour un nouveau modèle au début de la croissance du réseau : réessayez après quelques secondes.

La présence de trois modèles dans un même réseau est précieuse car elle permet de choisir un outil différent pour différentes tâches, sans changer de fournisseur ni de code d'intégration. Voici des scénarios où il est judicieux de commencer les tests avec MiniMax M2.7.

Analyse de documents longs. Si la tâche est de résumer des contrats, d'analyser de la documentation technique, de traiter de longs textes juridiques ou financiers, l'attention efficace de la série M est historiquement conçue pour maintenir un long contexte sans augmentation brutale des coûts. Transmettez le document entier en une seule requête et demandez au modèle de travailler sur tout le volume à la fois, et non par fragments.

RAG et travail avec des bases de connaissances. Dans les scénarios Retrieval-Augmented Generation (RAG), où des dizaines de fragments d'une base vectorielle sont insérés dans le contexte, la capacité du modèle à retenir de nombreux morceaux de texte hétérogènes affecte directement la qualité de la réponse. C'est une niche naturelle pour les modèles à long contexte.

Traitement des transcriptions et des journaux. Les transcriptions d'appels, les longs dialogues d'assistance, les journaux en continu – des tâches où le volume d'entrée est important, et la réponse est généralement courte. Ici, le plafond de sortie de 4 096 jetons n'est pas un obstacle : beaucoup d'informations entrent, et un résumé ou des faits extraits sortent.

Quand choisir un autre modèle. Si votre application nécessite une réponse très longue pour une seule requête (un grand document généré, un gros morceau de code), n'oubliez pas le plafond de sortie de 4 096 jetons – pour Qwen3-235B, il est deux fois plus élevé (8 192). Si le tool calling natif stable en production joue un rôle clé – Qwen3-235B est testé depuis plus longtemps. Pour les tâches de raisonnement avec une logique complexe, il vaut la peine de comparer les réponses avec Kimi K2.6. Conseil universel : exécutez le même ensemble de vos requêtes réelles sur les trois modèles et comparez les résultats – les 10 millions de jetons gratuits lors de l'inscription suffiront pour un test comparatif complet.

Techniquement, le basculement entre les modèles est un changement d'une seule ligne dans le champ model. Par conséquent, une architecture d'application bien conçue sur le réseau Gonka ne «choisit pas un modèle pour toujours», mais permet de router les requêtes entre Qwen, Kimi et MiniMax en fonction du type de tâche – l'inference économique rend un tel routage économiquement avantageux.