MiniMax M2.7 : 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 « out-of-the-box » et les caractéristiques avec lesquelles il est déployé sur un réseau spécifique. Lorsqu'un modèle fonctionne sur le réseau décentralisé Gonka, ses paramètres opérationnels sont définis par la configuration vLLM-inferenced côté hôtes GPU, et non uniquement par l'architecture du modèle. Voici les valeurs réelles fournies par notre Gateway :

• Fenêtre de contexte : 200 000 jetons (environ 150 000 mots). Il s'agit de la configuration du subnet au sein du réseau Gonka. L'architecture MiniMax elle-même prend en charge un contexte nettement plus long, mais le plafond pratique est défini à tout moment par les paramètres d'inferenced sur les hôtes.
• Sortie maximale : 8 192 jetons par réponse. Ce chiffre a été mesuré empiriquement — par une requête avec une génération forcée longue, qui a atteint le plafond (finish_reason: length). Actuellement, ce plafond est identique pour tous les modèles du réseau — jusqu'à 8 192 jetons. Il ne s'agit pas d'une limite du modèle lui-même, mais de la configuration du subnet vLLM.
• Exigence VRAM pour 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 Kimi K2.6. En pratique, cela signifie plusieurs GPU de classe H100/H200, regroupés en un seul nœud.

Le prix de l'inferenced sur 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, le MiniMax M2.7 est accessible au même tarif que Kimi K2.6. Ce prix unifié est le résultat du fait que le réseau repose sur un calcul unique du coût du travail informatique, et non sur la grille tarifaire d'un fournisseur spécifique.

Les utilisateurs du réseau Gonka ont le choix entre deux modèles phares, tous deux accessibles via l'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 de 2026 : l'écart entre les meilleurs modèles open-weights dans les tests publics s'est réduit à quelques pourcents, et cette différence se situe souvent dans la marge d'erreur statistique des benchmarks eux-mêmes. Pour une application pratique, ce n'est pas la position 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.

Conseil pratique : pour les tâches impliquant des documents très longs et le traitement en flux de gros volumes de texte, il est judicieux de tester MiniMax M2.7 — l'attention efficace de sa série est historiquement adaptée à ces scénarios. Pour les tâches de raisonnement avec une logique complexe et un contexte long, il vaut la peine de comparer les réponses avec Kimi K2.6. La meilleure stratégie en production consiste à intégrer les deux modèles dans le code et à basculer entre eux via 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 adopté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 proposal #54 : elle a été acceptée le 21 mai 2026 (environ 63 % de votes « pour ») et activée à une hauteur de bloc donnée. C'est le même mécanisme de governance grâce auquel le réseau accepte 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 du modèle devient une crise de migration, et toute panne du modèle unique fait tomber l'ensemble du service. Un réseau capable de gérer plusieurs modèles simultanément évolue en douceur : les nouveaux modèles sont ajoutés comme des « pistes » supplémentaires, les anciens continuent de fonctionner, et les GPU-hosts ont le choix de ce qu'ils servent. 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 importante des premières étapes : un décalage peut exister entre le moment où « 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 de MiniMax M2.7 en mode broker n'était disponible que pour des clés privilégiées et renvoyait une erreur pour les requêtes standard — une phase de rodage normale. Fin mai 2026, l'accès public a été ouvert et le modèle est devenu disponible pour tous les clients Gateway. Pour en savoir plus sur le fonctionnement du réseau et les raisons pour lesquelles 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 coûte $0.279/$1.20 par 1M, contre $0.003/$0.009 chez JoinGonka.

Le moyen le plus direct est d'utiliser la JoinGonka API Gateway. Comme la Gateway fournit une API compatible avec OpenAI, le code qui fonctionne avec GPT, Claude ou Kimi fonctionnera avec MiniMax après avoir modifié la valeur du champ model.

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 s'affiche 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 le long contexte"}],
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)
Lors de votre inscription sur la JoinGonka Gateway, vous recevez 10 millions de jetons gratuits pour tester n'importe quel modèle du réseau — c'est suffisant pour comparer les deux modèles du réseau 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 la Gateway. Il suffit de changer le paramètre model :
Cursor : dans les paramètres Custom Model, indiquez 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 via l'endpoint GET /v1/models — il est pratique d'y accéder dynamiquement pour que l'interface utilisateur de votre application affiche automatiquement les dernières nouveautés. Si vous recevez 429 too many concurrent requests — c'est une phase normale pour un nouveau modèle lors de la phase initiale de croissance du réseau : réessayez la requête après quelques secondes.

Avoir deux modèles dans le même réseau est précieux, car vous pouvez choisir l'outil approprié pour différentes tâches sans changer de fournisseur ni modifier le code d'intégration. Voici des scénarios où il est judicieux de commencer les tests avec MiniMax M2.7.

Analyse de longs documents. Si votre tâche concerne la synthèse de contrats, l'étude de documentation technique ou le traitement de textes juridiques ou financiers volumineux, l'attention efficace de la série M est historiquement adaptée au maintien d'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 l'ensemble du volume plutôt que par fragments.

RAG et bases de connaissances. Dans les scénarios de type retrieval-augmented, où des dizaines de fragments issus d'une base vectorielle sont intégrés au contexte, la capacité du modèle à retenir de nombreux segments hétérogènes influence directement la qualité de la réponse. C'est une niche naturelle pour les modèles à long contexte.

Traitement de transcriptions et de logs. Transcriptions d'appels, longs dialogues de support, logs en flux — ce sont des tâches où le volume d'entrée est important, mais la réponse est généralement courte. Ici, la limite de sortie de 8 192 jetons ne pose pas de problème : en entrée, on a beaucoup de données, en sortie, un résumé ou des faits extraits.

Quand choisir un autre modèle. Actuellement, tous les modèles du réseau fournissent jusqu'à 8 192 jetons par réponse ; par conséquent, si votre application a besoin d'une très longue réponse en une seule requête (grand document généré, bloc de code volumineux), prenez en compte ce plafond global dans votre architecture et divisez la génération en plusieurs parties. Pour les tâches nécessitant des raisonnements complexes en plusieurs étapes, il est conseillé de comparer les réponses avec Kimi K2.6. Conseil universel : exécutez le même ensemble de vos requêtes réelles via les deux modèles et comparez les résultats — les 10 millions de jetons offerts à l'inscription suffisent pour un test comparatif complet.

Techniquement, basculer entre les modèles consiste à changer 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 de modèle définitivement », mais permet de router les requêtes entre Kimi K2.6 et MiniMax M2.7 selon le type de tâche — un inference bon marché rend ce routage économiquement rentable.