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 attiré des financements d'Alibaba, Tencent et HongShan – le même cercle d'investisseurs stratégiques qui soutient d'autres « tigres de l'IA chinoise », y compris Moonshot AI, le développeur de Kimi K2.6.

Au-delà des modèles linguistiques purs, MiniMax est connue pour ses produits grand public : les assistants de conversation Talkie et Hailuo, ainsi que l'un des générateurs de vidéo les plus remarquables de l'industrie. Mais pour le réseau Gonka, la série de modèles textuels de la série M, successeurs des modèles abab précédents, 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 grands modèles précédents utilisaient l'attention quadratique classique (le coût de calcul croît proportionnellement au carré de la longueur du contexte), MiniMax a été l'un des premiers à introduire l'attention linéaire hybride. Cela permet de traiter des séquences très longues sans explosion des coûts de calcul - une particularité historique de la gamme. Comme Qwen3-235B et Kimi K2.6, le modèle est basé 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 de l'inference.

Dans le réseau Gonka, le modèle est identifié comme MiniMaxAI/MiniMax-M2.7 – c'est la chaîne à 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 lui-même « 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 de l'inférence vLLM côté des hôtes GPU, et pas seulement par l'architecture du modèle. Voici les valeurs réelles que notre Gateway renvoie :

• Fenêtre de contexte : 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 le réglage de l'inférence sur les hôtes.
• Sortie maximale : 4 096 jetons par réponse. Ce chiffre a été 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 – 3 072 jetons. Il ne s'agit pas d'une limite du modèle lui-même, mais d'une configuration du sous-réseau vLLM.
• Exigence VRAM de l'hôte : environ 320 Go de VRAM par nœud. Il s'agit d'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, réunis en un seul nœud.

Le prix de l'inférence 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 le JoinGonka Gateway, MiniMax M2.7 est disponible au même tarif que Qwen et Kimi. Le prix unifié est la conséquence du fait que le réseau est basé sur un calcul unifié du coût du 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 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 modèles open-weights de premier plan dans les tests publics s'est réduit à quelques pour cent, 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 la place absolue dans le classement MMLU qui compte, mais la nature de la tâche : longueur du contexte, complexité des chaînes logiques, langue requise, présence de tool calling.

Orientation pratique : pour les tâches avec des documents très longs et le traitement en continu de grands 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, 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 du réseau qui a été votée sur la chaîne. La prise en charge du modèle a été incluse dans la version v0.2.13 du protocole, approuvée par la proposition #54 : elle a été acceptée le 21 mai 2026 (environ 63 % de votes « pour ») et activée à la hauteur de bloc spécifiée. C'est le même mécanisme de gouvernance par lequel le réseau adopte toutes les modifications significatives – 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 du modèle se transforme en crise de migration, et toute défaillance du seul modèle fait s'effondrer l'ensemble du service. Un réseau capable de maintenir 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'ils veulent 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 est apparu dans la liste du réseau » et « le modèle est ouvert à tous les clients ». Au début, l'inférence de 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 la passerelle. Pour plus de détails sur le fonctionnement du réseau et la raison pour laquelle les modèles sont lancés de cette manière, consultez l'article sur l'architecture du réseau Gonka.

Le même MiniMax M2.7 via OpenRouter – 0,279 $/1,20 $ par million, contre 0,001 $ chez JoinGonka.

Le chemin le plus direct est via le JoinGonka API Gateway. Étant donné que le 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": "Expliquez 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 sa génération :

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

Lors de l'inscription à JoinGonka Gateway, vous recevez gratuitement 10 millions de jetons pour tester n'importe quel modèle 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 le Gateway. Il suffit de changer le paramètre model :

• Cursor : dans les paramètres du Modèle personnalisé, spécifiez MiniMaxAI/MiniMax-M2.7
• Claude Code, Cline, Continue.dev : nom du modèle dans la configuration
• LangChain, n8n : 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 l'interface utilisateur de votre application affiche elle-même la dernière série. Si la réponse est 429 too many concurrent requests – phase normale pour un nouveau modèle au début de la croissance du réseau : répétez la requête 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 à tester avec MiniMax M2.7.

Analyse de documents longs. Si la tâche est la summarisation de contrats, l'analyse de documentation technique, le traitement de grands textes juridiques ou financiers, l'attention efficace de la série M est historiquement adaptée au maintien d'un contexte long sans augmentation significative des coûts. Transmettez le document entier dans une seule requête et demandez au modèle de travailler avec tout le volume à la fois, plutôt qu'en morceaux.

RAG et travail avec des bases de connaissances. Dans les scénarios retrieval-augmented, où des dizaines de fragments d'une base vectorielle sont mélangés dans le contexte, la capacité du modèle à maintenir de nombreux morceaux de texte hétérogènes affecte directement la qualité de la réponse. C'est un créneau naturel pour les modèles à contexte long.

Traitement des transcriptions et des journaux. Les transcriptions d'appels, les longs dialogues d'assistance, les journaux de flux – des tâches où le volume d'entrée est important et la réponse généralement courte. Ici, le plafond de sortie de 4 096 jetons ne gêne pas : de nombreux éléments 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 un appel d'outil natif stable en production joue un rôle clé – Qwen3-235B est pour l'instant plus éprouvé. Pour les tâches de raisonnement avec des logiques complexes, il convient de comparer les réponses avec Kimi K2.6. Un 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. C'est pourquoi 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'inférence bon marché rend un tel routage économiquement avantageux.