Comment exécuter MiniMax M3 en local : configuration multi-GPU avec llama.cpp et Pi Agent

MiniMax M3 est le dernier modèle open-weight de MiniMax pour le code, l’utilisation d’outils et les workflows d’agents à long horizon. Il se démarque des versions précédentes par la combinaison d’une fenêtre de contexte d’1 million de tokens, d’un support multimodal natif (texte, images, vidéo) et de la MiniMax Sparse Attention, conçue pour rendre l’inférence sur très longs contextes plus pratique. 

Source : MiniMax 

Dans ce guide, je vous montre comment exécuter MiniMax M3 en local sur deux GPU NVIDIA RTX PRO 6000, tester le modèle via son interface web intégrée et connecter l’endpoint local compatible OpenAI à l’agent de code Pi. 

La configuration utilise les terminaux JupyterLab sur un pod RunPod PyTorch au lieu de SSH, avec llama.cpp compilé pour CUDA, servant le modèle sur le port 8910.

Configuration système requise pour exécuter MiniMax M3 en local

Avant d’exécuter MiniMax M3 en local, assurez-vous que votre système dispose de suffisamment de mémoire GPU et de stockage pour charger le modèle.

• GPU : 2× NVIDIA RTX PRO 6000 avec 96 Go de VRAM chacun, soit 192 Go de VRAM au total.
• Stockage : au moins 350 Go d’espace disque libre pour les fichiers du modèle, le cache Hugging Face, les fichiers de build de llama.cpp et les données temporaires d’exécution.
• Quantification du modèle : utilisez la quantification GGUF UD-IQ3_XXS depuis unsloth/MiniMax-M3-GGUF. Elle pèse environ 159 Go et c’est l’option la plus pratique pour ce matériel.
• Runtime : une build llama.cpp activée pour CUDA avec prise en charge multi-GPU.

MiniMax M3 est un grand modèle mixture-of-experts, donc ses poids doivent être répartis sur les deux GPU à l’inférence. Même si le système offre 192 Go de VRAM combinée, toute cette mémoire n’est pas disponible pour le seul modèle. 

Une partie de la VRAM est requise pour les surcoûts d’exécution, le traitement des invites et le cache KV.

Pour cette raison, commencez avec la quantification UD-IQ3_XXS. Autour de 159 Go, elle laisse assez de mémoire pour charger et exécuter le modèle. 

Évitez les quantifications MiniMax M3 en 4 bits sur cette configuration : le plus petit fichier 4 bits disponible fait environ 208 Go et dépasse la VRAM utile avant même de compter les surcoûts d’exécution.

1. Configurez votre environnement RunPod multi-GPU

Créez un nouveau Pod RunPod et sélectionnez 2× NVIDIA RTX PRO 6000 avec le dernier template RunPod PyTorch. Ce template inclut JupyterLab, que nous utiliserons à la place de SSH dans ce guide.

Configurez le Pod avec les paramètres suivants :

• Container Disk : 50 GB
• Volume Disk : 300 GB
• Expose HTTP Ports : 8910
• Variables d’environnement : HF_TOKEN : votre jeton d’accès Hugging Face

Le disque conteneur de 50 Go sert uniquement au système, aux paquets et aux fichiers temporaires. Le volume de 300 Go hébergera le modèle MiniMax M3 et le cache Hugging Face. 

Exposez le port HTTP 8910, car llama.cpp fera tourner l’interface web et l’API compatible OpenAI sur ce port. Une fois le serveur démarré, vous pourrez y accéder via une URL de ce type :

https://<POD_ID>-8910.proxy.runpod.net

La configuration du Pod utilisée pour ce guide coûte environ 4,23 $ par heure, avec des variations possibles selon la disponibilité et la région. 

Je vous recommande d’avoir au moins 10 $ de crédits RunPod, et idéalement 15–20 $ pour la phase de build initiale, le téléchargement du modèle et les tests.

Une fois le Pod lancé, ouvrez-le depuis le tableau de bord RunPod :

1. Ouvrez votre Pod.
2. Cliquez sur l’onglet Connect
3. Ouvrez JupyterLab.
4. Dans JupyterLab, sélectionnez File → New → Terminal.

Commencez par confirmer que les deux GPU sont disponibles :

nvidia-smi

Vous devriez voir deux NVIDIA RTX PRO 6000, chacune avec environ 96 Go de VRAM.

Ensuite, installez les outils de build requis :

apt-get update && apt-get install -y \
  git \
  cmake \
  build-essential \
  curl

Enfin, vérifiez que CUDA est disponible :

nvcc --version

Vous devriez voir CUDA 12.8 ou une version compatible. Vous êtes prêt à compiler llama.cpp avec le support CUDA.

2. Compilez la branche MiniMax M3 de llama.cpp avec CUDA

llama.cpp est un moteur d’inférence open source pour exécuter des modèles GGUF en local. Je vous conseille de lire notre guide complet sur llama.cpp si vous ne connaissez pas encore l’outil. 

Il prend en charge l’accélération CUDA, le déchargement multi-GPU, une interface web intégrée et un serveur d’API compatible OpenAI. 

Le support de MiniMax M3 est encore expérimental, vous devez donc compiler llama.cpp depuis la branche dédiée minimax-m3 au lieu d’utiliser la release standard. 

Exécutez les commandes suivantes dans votre terminal JupyterLab :

cd /workspace

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp

git fetch origin pull/24523/head:minimax-m3
git checkout minimax-m3

Ensuite, configurez llama.cpp avec le support CUDA et compilez les binaires du serveur et en ligne de commande :

cmake -B build \
  -DGGML_CUDA=ON \
  -DCMAKE_BUILD_TYPE=Release

cmake --build build \
  -j"$(nproc)" \
  --target llama-server llama-cli

Deux binaires sont créés dans build/bin/ :

• llama-server, qui fournit l’interface de chat dans le navigateur et l’endpoint API compatible OpenAI.
• llama-cli, pour tester le modèle directement depuis le terminal.

Remarque : il s’agit d’une implémentation MiniMax M3 expérimentale. Elle prend en charge l’inférence texte, mais la MiniMax Sparse Attention n’est pas incluse dans cette branche ; llama.cpp utilise donc une attention dense. Le support vision et MTP/décodage spéculatif n’est pas non plus inclus.

3. Téléchargez les poids GGUF de MiniMax M3

MiniMax M3 est distribué en plusieurs fichiers GGUF. Téléchargez l’intégralité du dossier UD-IQ3_XXS sur le volume persistant avant de démarrer le serveur.

Commencez par installer la dernière CLI Hugging Face Hub :

pip install -U huggingface_hub

Créez un répertoire pour le modèle et activez des téléchargements Hugging Face plus rapides :

mkdir -p /workspace/unsloth

export HF_XET_HIGH_PERFORMANCE=1

Puis téléchargez la quantification UD-IQ3_XXS :

hf download unsloth/MiniMax-M3-GGUF \
  --include "UD-IQ3_XXS/*" \
  --local-dir /workspace/unsloth

Le téléchargement pèse environ 159 Go et comprend cinq shards GGUF. Comme le modèle est stocké dans /workspace, il reste disponible lorsque vous arrêtez et redémarrez le Pod.

4. Servez MiniMax M3 en local sur plusieurs GPU

Placez-vous dans le répertoire llama.cpp et rendez les deux GPU visibles pour le serveur :

cd /workspace/llama.cpp

export CUDA_VISIBLE_DEVICES=0,1

Puis démarrez MiniMax M3 :

MODEL_FILE="/workspace/unsloth/UD-IQ3_XXS/MiniMax-M3-UD-IQ3_XXS-00001-of-00005.gguf"

./build/bin/llama-server \
  -m "$MODEL_FILE" \
  --host 0.0.0.0 \
  --port 8910 \
  --ctx-size 8192 \
  --parallel 1 \
  --split-mode layer \
  --tensor-split 1,1 \
  --n-gpu-layers 99 \
  --flash-attn on \
  --jinja \
  --temp 1.0 \
  --top-p 0.95 \
  --top-k 40

Cette commande charge MiniMax M3 sur les deux RTX PRO 6000. L’option --tensor-split 1,1 répartit le modèle équitablement entre les GPU, tandis que --n-gpu-layers 99 garde un maximum de couches en mémoire GPU.

Le serveur tourne sur le port 8910 et expose à la fois l’interface web de llama.cpp et une API compatible OpenAI. Laissez ce terminal ouvert tant que le modèle est en cours d’exécution.

Commencez avec une fenêtre de contexte 8K. Cette branche expérimentale de llama.cpp utilise une attention dense plutôt que la MiniMax Sparse Attention ; augmenter fortement la fenêtre de contexte peut donc entraîner des problèmes de mémoire. Une fois le serveur stable, vous pouvez tester --ctx-size 16384.

Ouvrez un autre terminal JupyterLab et exécutez la commande suivante pour confirmer l’utilisation des deux GPU :

nvidia-smi

Après le chargement du modèle, les deux GPU doivent afficher une utilisation VRAM significative.

5. Testez l’endpoint API compatible OpenAI de MiniMax M3

Ouvrez un nouveau terminal JupyterLab et vérifiez d’abord que le serveur fonctionne et a bien chargé MiniMax M3 :

curl -s http://127.0.0.1:8910/v1/models \
  | python3 -c "import sys, json; print(json.load(sys.stdin)['data'][0]['id'])"

Vous devriez voir un ID de modèle similaire à :

MiniMax-M3-UD-IQ3_XXS-00001-of-00005.gguf

Ensuite, envoyez une requête de test à l’endpoint de complétions de chat compatible OpenAI :

curl http://127.0.0.1:8910/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMax-M3-UD-IQ3_XXS-00001-of-00005.gguf",
    "messages": [
      {
        "role": "user",
        "content": "Write a Python function that checks whether a number is prime."
      }
    ],
    "temperature": 1.0,
    "top_p": 0.95,
    "max_tokens": 512
  }'

Votre serveur MiniMax M3 local fonctionne correctement.

Il a généré une fonction Python is_prime() efficace en utilisant math.isqrt() et l’optimisation 6k ± 1. 

La réponse a été tronquée car elle a atteint votre limite max_tokens de 512, indiquée par : "finish_reason": "length"

Dans ce test, le serveur a traité l’invite à environ 357 tokens/s et généré du texte à environ 73 tokens/s. 

Votre débit peut varier selon la longueur du contexte, la charge GPU et la taille de l’invite. 

6. Accédez à l’interface web de llama.cpp pour MiniMax M3

Comme le port 8910 est exposé via RunPod, vous pouvez également tester MiniMax M3 via l’interface web intégrée de llama.cpp.

Dans le tableau de bord RunPod, ouvrez votre Pod et cliquez sur le bouton Connect. Sous les ports HTTP exposés, sélectionnez le lien du port 8910.

Cela ouvre l’interface web de llama.cpp dans votre navigateur. Elle fonctionne comme une application de chat légère à la ChatGPT, avec le modèle MiniMax M3 local déjà sélectionné. Vous pouvez maintenant envoyer des invites et tester le modèle sans passer par le terminal ou l’API.

Pour un test concret, j’ai demandé à MiniMax M3 de générer une interface web Python pour servir des modèles de machine learning. Il a produit une conception détaillée de tableau de bord sous FastAPI avec changement de modèle, requêtes de prédiction JSON, envois CSV par lot, streaming WebSocket en direct, registre de modèles, endpoints de santé, logs structurés, tests et configuration Docker.

La réponse a généré 5 510 tokens en 1 minute et 19 secondes, soit environ 69 tokens/s. 

Pour une quantification locale en 3 bits répartie sur deux RTX PRO 6000, c’est un excellent résultat qui montre que MiniMax M3 gère de longues requêtes de code à une vitesse interactive.

7. Connectez Pi Coding Agent à votre LLM local

Pi est un agent de code en terminal qui peut travailler directement avec vos fichiers de projet locaux, exécuter des commandes, inspecter le code et utiliser votre modèle MiniMax M3 hébergé localement.

Ouvrez un troisième terminal JupyterLab. Gardez le premier terminal avec llama-server actif, puis utilisez ce terminal pour installer et configurer Pi.

Installez Pi avec le script officiel :

curl -fsSL https://pi.dev/install.sh | sh

Si l’installateur vous demande s’il doit installer Node.js, tapez Y puis Entrée. Pi installera ensuite son runtime Node.js requis et l’outil en ligne de commande pi.

À la fin, l’installateur peut afficher une commande pour mettre à jour votre shell. Exécutez la commande fournie, puis redémarrez le shell :

exec bash -l

Confirmez que Pi est disponible :

pi --version

Vous devriez voir le numéro de version installé de Pi.

0.79.10

Pi prend en charge des fournisseurs personnalisés compatibles OpenAI via un fichier models.json. Créez le répertoire de configuration de Pi :

mkdir -p ~/.pi/agent

Puis créez la configuration du fournisseur :

cat > ~/.pi/agent/models.json <<'EOF'
{
  "providers": {
    "local-minimax": {
      "baseUrl": "http://127.0.0.1:8910/v1",
      "api": "openai-completions",
      "apiKey": "none",
      "compat": {
        "supportsDeveloperRole": false,
        "supportsReasoningEffort": false,
        "supportsUsageInStreaming": false,
        "maxTokensField": "max_tokens"
      },
      "models": [
        {
          "id": "MiniMax-M3-UD-IQ3_XXS-00001-of-00005.gguf",
          "name": "MiniMax M3 Local 3-bit",
          "reasoning": false,
          "input": ["text"],
          "contextWindow": 8192,
          "maxTokens": 2048,
          "cost": {
            "input": 0,
            "output": 0,
            "cacheRead": 0,
            "cacheWrite": 0
          }
        }
      ]
    }
  }
}
EOF

Cette configuration indique à Pi d’utiliser le serveur llama.cpp local qui tourne sur le port 8910. Le paramètre d’API openai-completions correspond à l’endpoint de complétions de chat compatible OpenAI de llama.cpp.

Les paramètres de compatibilité empêchent Pi d’envoyer des champs ou rôles de message non pris en charge susceptibles de poser problème avec certains serveurs locaux compatibles OpenAI. En particulier, Pi utilisera le rôle system au lieu du rôle developer plus récent et enverra max_tokens, attendu par llama.cpp.

Le modèle est déclaré « texte uniquement » avec une fenêtre de contexte 8K, en phase avec la configuration du serveur démarrée plus tôt. Les coûts sont à zéro puisque MiniMax M3 tourne en local sur votre instance RunPod et non via une API payante.

8. Utilisez Pi avec MiniMax M3

Ouvrez un nouveau terminal JupyterLab pour Pi. Pour un confort accru, passez JupyterLab en mode sombre via Settings → Theme → JupyterLab Dark.

Ensuite, clonez le projet sur lequel vous souhaitez faire travailler MiniMax M3 :

cd /workspace

git clone https://github.com/kingabzpro/semantic-web-cache
cd semantic-web-cache

Lancez Pi :

pi

Dans Pi, tapez :

/model

Recherchez local, puis sélectionnez MiniMax M3 Local 3-bit. Pi doit afficher le fournisseur local et confirmer que le modèle GGUF MiniMax M3 est sélectionné.

Commencez par une tâche en lecture seule pour que Pi puisse inspecter le dépôt sans modifier de fichiers. Par exemple :

"Read the README.md file and explain how this project is structured."

Pi utilisera des outils de terminal comme ls et read pour explorer le dépôt, lire le README et consulter des fichiers comme .env.example, requirements.txt et le notebook Jupyter.

Dans cet exemple, MiniMax M3 a correctement identifié les principaux fichiers du projet et expliqué que le dépôt est une démo de cache sémantique construite avec Olostep et Qdrant. 

Il a mis en avant le workflow basé sur notebook, les variables d’environnement nécessaires pour les API, les paramètres de seuil de cache et de TTL, ainsi que les évaluations de latence, de taux de hit et d’économies de crédits incluses dans le projet.

Je lui ai aussi demandé de créer un diagramme ASCII du pipeline de cache sémantique. Il a généré un flux clair montrant comment une requête utilisateur est embarquée, vérifiée dans le cache Qdrant, comparée au seuil de similarité, puis renvoyée depuis le cache ou envoyée à Olostep avant stockage du résultat.

Pour de plus grands dépôts ou des tâches multi-étapes plus profondes, vous aurez peut-être besoin d’une fenêtre de contexte plus large. Modifiez la valeur --ctx-size dans la commande llama-server et redémarrez le serveur. Commencez par passer de 8192 à 16384, puis testez 32768` si la mémoire GPU le permet.

Évitez de passer directement à 100K de contexte. Cette branche MiniMax M3 expérimentale de llama.cpp utilise une attention dense plutôt que la MiniMax Sparse Attention, donc des contextes très larges augmentent fortement l’usage mémoire et peuvent provoquer des erreurs d’épuisement de mémoire.

Conclusion

Après avoir fait tourner MiniMax M3 en local, je pense qu’il offre un bien meilleur compromis que de tenter d’exécuter des modèles de code extrêmement volumineux comme GLM 5.2 ou Kimi K2.7 Code. 

Ces modèles peuvent être plus puissants dans certains cas, mais ils exigent bien davantage de mémoire GPU et leur location/serveur local peut devenir très coûteux.

Avec MiniMax M3, j’ai pu faire tourner un modèle d’agent et de code performant sur deux RTX PRO 6000, l’utiliser via une interface web, l’exposer via une API compatible OpenAI et le connecter à Pi comme agent de code local. 

Dans mes tests, il générait autour de 70 tokens/s et gérait correctement l’exploration de dépôts, l’analyse de README, l’exécution de commandes, les explications de projet et les diagrammes de workflow.

Ce n’est pas encore une configuration parfaite : le support dans llama.cpp est expérimental, la Sparse Attention n’est pas disponible et la fenêtre de contexte doit rester relativement modeste sauf si vous disposez de plus de VRAM. Malgré tout, pour un modèle quantifié en 3 bits en local, les résultats sont impressionnants.