MiniMax M3.1 Flash GGUF : mémoire, installation et coûts API

Pour MiniMax M3.1 Flash GGUF, commencez par UD-Q2_K_XL avec 160 GiB+ de mémoire. Préférez UD-Q4_K_XL avec 256 GiB+ si votre machine dispose de suffisamment de mémoire. Si vous devez acheter du matériel pour coder occasionnellement, calculez d’abord le coût d’un essai avec l’API.

Au 2026-11-06, ces estimations d’Unsloth supposent un contexte texte de 16K et un seul slot serveur. La mémoire peut se répartir entre RAM et VRAM, ou provenir d’une mémoire unifiée. La procédure ci-dessous permet d’exposer une API locale et de la connecter à OpenCode 1.

Combien de mémoire faut-il pour M3.1 Flash ?

Prévoyez de la mémoire pour l’ensemble des poids quantifiés, plus les besoins du moteur d’inférence. La fiche originale du modèle MiniMax indique environ 428B paramètres, dont 23B actifs par token. Ce nombre de paramètres actifs réduit les calculs ; il ne transforme pas le modèle à charger en un modèle de 23B.

Unsloth publie les tailles et les budgets mémoire suivants. Les téléchargements utilisent des GB décimaux ; les valeurs de mémoire utilisent des GiB.

Version quantifiée	Téléchargement	Taille des poids	Mémoire à prévoir
UD-IQ1_M	129.4 GB	120.5 GiB	Essai sous forte contrainte mémoire ; voir ci-dessous
UD-Q2_K_XL	143.9 GB	134.0 GiB	160 GiB+
UD-IQ3_XXS	160.0 GB	149.1 GiB	176 GiB+
UD-IQ3_S	175.5 GB	163.4 GiB	192 GiB+
UD-Q3_K_XL	194.0 GB	180.6 GiB	208 GiB+
UD-Q4_K_XL	249.4 GB	232.3 GiB	256 GiB+
UD-Q8_K_XL	259.1 GB	241.3 GiB	272 GiB+

Unsloth prévoit environ 20–32 GiB en plus des poids pour le cache de clés et de valeurs, le moteur d’inférence et le système d’exploitation. Ce cache conserve l’état d’attention du contexte en cours. Des contextes plus longs, des slots supplémentaires, la vision et le décodage spéculatif exigent davantage de mémoire.

Les poids 1-bit seuls ne laissent que 7.5 GiB sur une machine de 128 GiB. C’est moins que la marge supplémentaire indiquée. Pour Q2, retenez la recommandation plus prudente d’Unsloth : 160 GiB.

Additionner RAM et VRAM aide à planifier la répartition des poids, mais ces mémoires ne sont pas interchangeables. Si vous déportez une partie de l’exécution sur le CPU, gardez assez de RAM hôte pour les poids déplacés. Réservez aussi suffisamment d’espace disque pour le téléchargement choisi.

Le contexte annoncé de 1M ne signifie pas que ces estimations couvrent un contexte de 1M. Commencez à 16K et augmentez la limite après avoir vérifié l’utilisation de la mémoire.

Quelle version quantifiée choisir ?

Utilisez d’abord Q2 pour vérifier que le modèle tient en mémoire. Si votre capacité le permet, comparez ensuite Q4 sur vos véritables tâches de programmation. Choisissez une variante 3-bit lorsque Q4 dépasse votre budget mémoire.

Les chiffres globaux et les résultats par catégorie d’Unsloth n’ont pas le même périmètre :

Concordance top-1 publiée par Unsloth	UD-Q2_K_XL	UD-Q4_K_XL
Résumé global pondéré	91.5%	98.0%
Programmation	91.2%	97.6%
Conversation générale	88.5%	97.3%
Mathématiques	95.7%	99.0%

Le résumé global pondère sept catégories. Les lignes consacrées à la conversation et aux mathématiques décrivent chacune une catégorie. Cela explique pourquoi Q2 affiche à la fois 91.5% et 88.5%.

La concordance top-1 indique si le modèle quantifié choisit le même token le mieux classé que le modèle de référence. Elle ne mesure pas le taux de réussite des tâches de programmation. Un résultat de 91.2% en programmation ne signifie pas que 91.2% des modifications d’un dépôt réussiront leurs tests.

Considérez 1-bit comme une expérience sous forte contrainte mémoire, malgré sa concordance globale d’environ 89.9%. Vérifiez les modifications de fichiers, les arguments des outils et le comportement sur plusieurs étapes avant de vous fier à une version quantifiée.

Q8 ajoute 9.7 GB au téléchargement par rapport à Q4. Unsloth le décrit comme une conversion sans pertes des poids publiés, qui conserve un mélange de formats NVFP4 et BF16. Le libellé « 8-bit » ne correspond donc pas à une précision uniforme pour tous les tenseurs.

Quel moteur d’inférence choisir pour votre matériel ?

Choisissez des poids et une procédure adaptés à votre moteur d’inférence. Qu’une configuration EXL3 tienne en mémoire ne prouve pas que le GGUF correspondant tiendra également.

Les sources des options ci-dessous ont été vérifiées le 2026-11-06 :

Matériel	Option à examiner	Limite pratique
Apple Silicon	Poids oQ3e de MLX-community avec oMLX	L’ensemble représente 196.152 GB / 182.681 GiB, modèle auxiliaire et composants de vision compris. Ajoutez la mémoire du moteur d’inférence et du contexte.
Un DGX Spark	Procédure SAGE-EXL3 de vcruz305	Elle vise un système GB10 de 128 GB, avec des versions de composants figées et un accès aux poids soumis à autorisation. Le service se limite au texte et à un seul flux de décodage.
AMD Instinct	Poids Quark MXFP4 d’AMD	La configuration documentée cite MI350/MI355, Linux, ROCm 7.2.3 et un exemple de parallélisme tensoriel sur quatre GPU. Ce n’est pas une procédure générique pour Radeon.
Quatre cartes RTX 3090	Inférence sur mesure mentionnée dans la publication communautaire de MiniMax du 1er novembre	MiniMax attribue à @superalesha une approche associant poids quantifiés, cache des experts et RAM système. Cette mention ne garantit pas les mêmes performances sur d’autres configurations.

Pour un premier déploiement GGUF, suivez la procédure llama.cpp détaillée ci-dessous. Avant un déploiement commercial, consultez la MiniMax Community License, notamment ses conditions d’attribution et de notification.

Compilez llama.cpp et lancez un serveur avec un contexte de 16K

Utilisez la branche prenant en charge MiniMax indiquée par Unsloth. Au 2026-11-06, la PR #31192 de llama.cpp restait ouverte et non fusionnée. L’exemple fige le commit qui se trouvait en tête de la PR lors de cette vérification.

Compilation et téléchargement

Utilisez Bash sous Ubuntu ou WSL, avec le toolkit NVIDIA CUDA déjà installé. Installez les autres prérequis, puis compilez le serveur :

sudo apt-get update
sudo apt-get install -y build-essential cmake git libssl-dev python3-venv curl jq

git clone https://github.com/ggml-org/llama.cpp
git -C llama.cpp fetch origin pull/31192/head:minimax-m31
git -C llama.cpp checkout --detach 6b95a9908d2c7b242817a447708aec38e937e2c0

cmake llama.cpp -B llama.cpp/build \
  -DCMAKE_BUILD_TYPE=Release \
  -DBUILD_SHARED_LIBS=OFF \
  -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j --target llama-server

Sous macOS, installez les outils en ligne de commande de Xcode, CMake, Python et jq. Ignorez les commandes apt-get et remplacez -DGGML_CUDA=ON par -DGGML_CUDA=OFF. La documentation de compilation indique que Metal est activé par défaut sous macOS.

Téléchargez les quatre fragments Q2 avec la CLI de Hugging Face :

python3 -m venv .venv-m31
source .venv-m31/bin/activate
python -m pip install -U huggingface_hub

hf download unsloth/MiniMax-M3.1-Flash-GGUF \
  --local-dir unsloth/MiniMax-M3.1-Flash-GGUF \
  --include "UD-Q2_K_XL/*"

Gardez les fragments ensemble. Le serveur charge l’ensemble lorsque vous lui indiquez le premier fichier.

Lancement et vérification

Commencez avec un seul slot, un contexte explicitement fixé à 16K et un décodage texte classique :

./llama.cpp/build/bin/llama-server \
  --model unsloth/MiniMax-M3.1-Flash-GGUF/UD-Q2_K_XL/MiniMax-M3.1-Flash-UD-Q2_K_XL-00001-of-00004.gguf \
  --alias m31-local \
  --ctx-size 16384 \
  --parallel 1 \
  --n-gpu-layers auto \
  --jinja \
  --flash-attn on \
  --temp 1.0 \
  --top-p 0.95 \
  --top-k 0 \
  --min-p 0.0 \
  --chat-template-kwargs '{"reasoning_effort":"high"}' \
  --host 127.0.0.1 \
  --port 8080

Pour cette implémentation de l’attention éparse, la PR impose Jinja, Flash Attention et un seul slot. Les options de llama-server permettent d’attribuer automatiquement les couches au GPU.

Cette commande n’ajoute ni projecteur de vision ni modèle auxiliaire DSpark. Le serveur n’utilise aucune clé API et n’écoute que sur l’adresse de boucle locale.

Si l’allocation de VRAM échoue, réduisez le nombre de couches sur le GPU. Vérifiez aussi la RAM hôte disponible. Si la mémoire totale manque, choisissez une version quantifiée plus petite ou ajoutez de la mémoire. Déporter l’exécution sur le CPU ne supprime pas la nécessité de stocker les poids.

Dans un second terminal Bash, vérifiez si le serveur est prêt :

curl -sS -i http://127.0.0.1:8080/health

Continuez lorsque vous recevez HTTP 200 avec {"status":"ok"}. HTTP 503 avec Loading model signifie que l’initialisation est encore en cours.

Consultez ensuite le modèle disponible et demandez une réponse :

curl -sS http://127.0.0.1:8080/v1/models | jq '.data[].id'

curl -sS http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  --data '{
    "model": "m31-local",
    "messages": [
      {"role": "user", "content": "Reply with LOCAL_OK."}
    ],
    "reasoning_effort": "low",
    "max_tokens": 4096,
    "stream": false
  }' | jq '{message: .choices[0].message, finish_reason: .choices[0].finish_reason}'

Vérifiez que la liste contient m31-local et que message.content contient la réponse demandée. Pour ce test de base, l’effort de raisonnement low de la requête remplace le réglage high du serveur.

Si finish_reason vaut length, la réponse a atteint son plafond de sortie. Augmentez ce plafond sans dépasser le contexte total avant de conclure à un problème de chargement faute de texte final.

Connectez OpenCode 1 et vérifiez un appel d’outil

Reliez OpenCode au serveur grâce à son intégration documentée pour les fournisseurs personnalisés. OpenCode exécute les outils de fichiers ; llama-server génère les réponses du modèle.

Cette configuration suit la documentation d’OpenCode 1. OpenCode 1 et OpenCode 2 utilisent la même commande opencode. Si vous utilisez déjà V2, préparez un environnement séparé.

Pour une nouvelle installation de V1, avec Node.js et npm disponibles :

npm install -g opencode-ai
opencode --version

Intégrez cette configuration à opencode.json, à la racine du projet. Elle suit l’exemple officiel du fournisseur llama.cpp :

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "local": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "MiniMax local",
      "options": {
        "baseURL": "http://127.0.0.1:8080/v1"
      },
      "models": {
        "m31-local": {
          "name": "MiniMax M3.1 Flash Q2",
          "limit": {
            "context": 16384,
            "output": 4096
          }
        }
      }
    }
  }
}

Cette configuration locale ne nécessite pas de clé API factice. La limite de contexte correspond à celle du serveur. Le plafond de sortie constitue un budget choisi pour les réponses, pas le maximum du modèle.

Dans un projet Node contenant package.json, exécutez :

opencode run --model local/m31-local \
  "Read package.json with a file tool. Report scripts.test, or say it is missing. Do not edit files or run commands."

Repérez une véritable étape de lecture par un outil, puis comparez la réponse au contenu du fichier. L’affirmation du modèle selon laquelle il a lu le fichier ne suffit pas.

Si le client ne se connecte pas, vérifiez l’URL de base avec /v1 et l’alias du modèle. Vérifiez aussi que le serveur fonctionne. Si les réponses texte fonctionnent, mais pas les outils, vérifiez --jinja. Refaites ce test limité avant de lancer des modifications du dépôt.

Gardez une première session courte. Si les définitions d’outils occupent trop de contexte, appliquez la méthode du guide sur le coût du contexte MCP avant d’agrandir la fenêtre du serveur.

Quand vaut-il mieux utiliser l’API ?

Commencez par l’API si vous devez acheter du matériel pour un usage occasionnel. Envisagez un déploiement local si vous disposez déjà de suffisamment de capacité ou devez exécuter le modèle sur votre machine.

Au 2026-11-06, le tarif standard de l’API MiniMax indique :

Élément facturé	USD par 1 million de tokens
Entrée sans cache	$0.15
Lecture de l’entrée en cache	$0.015
Sortie	$0.60

Ces frais d’utilisation de l’API sont prélevés sur le solde du compte. MiniMax décrit également les tarifs par token de Flash comme uniformes. Sa formule de facturation du cache couvre les nouvelles entrées, les tokens retrouvés dans le cache et les sorties. Elle n’ajoute pas de poste distinct pour l’écriture dans le cache.

Prenons une charge mensuelle illustrative de 20 millions de tokens d’entrée sans cache et de 2 millions de tokens de sortie facturés :

API token charge = 20 × $0.15 + 2 × $0.60
                 = $4.20 per month

Cet exemple suppose des appels limités au texte, sans tokens provenant du cache ni outils serveur payants. Les taxes et les frais appliqués au paiement sont exclus.

Pour comparer, considérez ce budget local illustratif :

Hardware allocation = $3,000 ÷ 36 months
                    = $83.33 per month

Active electricity  = 0.15 kW × 60 hours × $0.20/kWh
                    = $1.80 per month

Local subtotal      = $85.13 per month

Tous les paramètres du calcul local sont des hypothèses. Ce calcul n’est ni le devis d’une machine vérifiée ni la preuve qu’elle réalisera cette charge en 60 heures. Ajoutez la consommation au repos, l’installation, la maintenance et les éventuelles mises à niveau matérielles avant de décider d’un achat.

Comparez les exécutions avec le même effort de raisonnement. L’API MiniMax utilise max par défaut, tandis que ce serveur local utilise high. Utilisez les volumes de sortie facturés et mesurez le coût par tâche de programmation terminée, en incluant les nouvelles tentatives et les étapes d’outils échouées.

Au 2026-11-06, BetterToken propose également MiniMax-M3.1-Flash avec paiement à l’usage. Son URL de base documentée compatible avec OpenAI est https://www.bettertoken.ai/v1. Utilisez ses prix actuels pour chiffrer cette option.

Si vous possédez déjà le matériel, remplacez le budget d’acquisition illustratif par vos coûts supplémentaires réels. Mesurez ensuite des tâches représentatives. Un déploiement local devient utile lorsque la mémoire disponible, le temps de réalisation et les résultats acceptés répondent à vos besoins.