Come eseguire MiniMax M3 in locale: configurazione multi-GPU con llama.cpp e Pi Agent

MiniMax M3 è l’ultimo modello open-weight di MiniMax per coding, uso di tool e workflow agentici a lungo raggio. Ciò che lo distingue dai precedenti modelli MiniMax è la combinazione di una finestra di contesto da 1M token, supporto multimodale nativo per testo, immagini e video, e MiniMax Sparse Attention, progettata per rendere più pratiche le inferenze con contesti molto lunghi. 

Fonte: MiniMax 

In questa guida ti mostro come eseguire MiniMax M3 in locale su due GPU NVIDIA RTX PRO 6000, testare il modello tramite l’interfaccia web integrata e collegare l’endpoint locale compatibile con OpenAI all’agente di coding Pi. 

Il setup usa i terminali di JupyterLab su un pod RunPod PyTorch al posto di SSH, con llama.cpp compilato per CUDA, servendo il modello sulla porta 8910.

Requisiti di sistema per eseguire MiniMax M3 in locale

Prima di eseguire MiniMax M3 in locale, assicurati che il tuo sistema abbia memoria GPU e storage sufficienti per caricare il modello.

• GPU: 2× GPU NVIDIA RTX PRO 6000 con 96 GB di VRAM ciascuna, per un totale di 192 GB di VRAM.
• Storage: Almeno 350 GB di spazio libero su disco per i file del modello, la cache di Hugging Face, i file di build di llama.cpp e i dati temporanei a runtime.
• Quantizzazione del modello: Usa la quantizzazione GGUF UD-IQ3_XXS da unsloth/MiniMax-M3-GGUF. È di circa 159 GB ed è l’opzione più pratica per questo hardware.
• Runtime: Una build di llama.cpp abilitata a CUDA con supporto multi-GPU.

MiniMax M3 è un ampio modello a mixture-of-experts, quindi i suoi pesi devono essere suddivisi tra entrambe le GPU durante l’inferenza. Anche se il sistema offre 192 GB di VRAM combinata, non tutta quella memoria può essere usata per il modello stesso. 

Una parte della VRAM è necessaria per l’overhead del runtime, l’elaborazione del prompt e la cache KV.

Per questo motivo, inizia con la quantizzazione UD-IQ3_XXS. Con circa 159 GB, lascia memoria sufficiente per caricare ed eseguire il modello. 

Evita le quantizzazioni 4-bit di MiniMax M3 su questa configurazione, perché il file 4-bit più piccolo disponibile è circa 208 GB e supera la VRAM disponibile prima ancora di considerare l’overhead del runtime.

1. Configura l’ambiente multi-GPU su RunPod

Crea un nuovo Pod su RunPod e seleziona 2× GPU NVIDIA RTX PRO 6000 con il template RunPod PyTorch più recente. Questo template include JupyterLab, che useremo al posto di SSH in tutta la guida.

Configura il Pod con le seguenti impostazioni:

• Container Disk: 50 GB
• Volume Disk: 300 GB
• Expose HTTP Ports: 8910
• Variabili d’ambiente: HF_TOKEN: il tuo token di accesso Hugging Face

Il disco container da 50 GB serve solo per sistema operativo, pacchetti e file temporanei. Il volume da 300 GB è dove devono risiedere il modello MiniMax M3 e la cache di Hugging Face. 

Esponi la porta HTTP 8910, perché llama.cpp eseguirà in seguito la sua interfaccia web e l’API compatibile con OpenAI su questa porta. Una volta che il server è in esecuzione, puoi accedervi tramite un URL in questo formato:

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

La configurazione del Pod usata in questa guida costa circa $4,23 all’ora, anche se il prezzo può variare in base a disponibilità e località. 

Ti consiglio di mantenere almeno $10 di crediti RunPod, ma $15–$20 è più sicuro per la build iniziale, il download del modello e i test.

Dopo l’avvio del Pod, aprilo dalla dashboard di RunPod:

1. Apri il tuo Pod.
2. Clicca sulla scheda Connect .
3. Apri JupyterLab.
4. In JupyterLab, seleziona File → New → Terminal.

Per prima cosa, conferma che entrambe le GPU siano disponibili:

nvidia-smi

Dovresti vedere due GPU NVIDIA RTX PRO 6000, ognuna con circa 96 GB di VRAM.

Poi, installa gli strumenti di build necessari:

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

Infine, verifica che CUDA sia disponibile:

nvcc --version

Dovresti vedere CUDA 12.8 o una versione compatibile. Ora sei pronto per compilare llama.cpp con supporto CUDA.

2. Compila il branch llama.cpp per MiniMax M3 con CUDA

llama.cpp è un motore di inferenza open-source per eseguire modelli GGUF in locale. Ti suggerisco di leggere la nostra guida completa a llama.cpp se non lo conosci. 

Supporta l’accelerazione CUDA, l’offloading multi-GPU, un’interfaccia web integrata e un server API compatibile con OpenAI. 

Il supporto a MiniMax M3 è ancora sperimentale, quindi devi compilare llama.cpp dal branch dedicato minimax-m3 invece di usare la release standard. 

Esegui i seguenti comandi dal terminale di 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

Poi configura llama.cpp con supporto CUDA e compila i binari del server e della riga di comando:

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

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

Questo crea due binari in build/bin/:

• llama-server, che fornisce l’interfaccia chat via browser e l’endpoint API compatibile con OpenAI.
• llama-cli, che consente di testare il modello direttamente dal terminale.

Nota: questa è un’implementazione sperimentale di MiniMax M3. Supporta l’inferenza testuale, ma MiniMax Sparse Attention non è inclusa in questo branch, quindi llama.cpp usa attention densa. Il supporto vision e MTP/decodifica speculativa non fanno parte di questa build.

3. Scarica i pesi del modello GGUF di MiniMax M3

MiniMax M3 è distribuito come più file GGUF. Scarica l’intera cartella UD-IQ3_XXS nello spazio di lavoro persistente prima di avviare il server.

Per prima cosa, installa la versione più recente della CLI di Hugging Face Hub:

pip install -U huggingface_hub

Crea una directory per il modello e abilita download più veloci da Hugging Face:

mkdir -p /workspace/unsloth

export HF_XET_HIGH_PERFORMANCE=1

Quindi scarica la quantizzazione UD-IQ3_XXS:

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

Il download è di circa 159 GB e include cinque shard GGUF. Poiché il modello è salvato in /workspace, rimane disponibile quando interrompi e riavvii il Pod.

4. Servi MiniMax M3 in locale su più GPU

Spostati nella directory di llama.cpp e rendi entrambe le GPU disponibili al server:

cd /workspace/llama.cpp

export CUDA_VISIBLE_DEVICES=0,1

Poi avvia 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

Questo comando carica MiniMax M3 su entrambe le RTX PRO 6000. L’impostazione --tensor-split 1,1 divide il modello equamente tra le GPU, mentre --n-gpu-layers 99 mantiene quanto più modello possibile in memoria GPU.

Il server gira sulla porta 8910 e fornisce sia l’interfaccia web di llama.cpp sia un’API compatibile con OpenAI. Mantieni aperto questo terminale mentre il modello è in esecuzione.

Inizia con una finestra di contesto da 8K. Il branch sperimentale di llama.cpp usa attention densa e non MiniMax Sparse Attention, quindi usare finestre molto più grandi può causare problemi di memoria. Una volta che il server funziona, puoi testare --ctx-size 16384.

Apri un altro terminale JupyterLab ed esegui il seguente comando per confermare che entrambe le GPU sono utilizzate:

nvidia-smi

Dopo il caricamento del modello, entrambe le GPU dovrebbero mostrare un notevole utilizzo della VRAM.

5. Testa l’endpoint API compatibile con OpenAI di MiniMax M3

Apri un nuovo terminale JupyterLab e prima conferma che il server sia in esecuzione e abbia caricato 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'])"

Dovresti vedere un ID modello simile a:

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

Quindi invia una richiesta di test all’endpoint chat completions compatibile con 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
  }'

Il tuo server locale MiniMax M3 funziona correttamente.

Ha generato una funzione Python is_prime() efficiente usando math.isqrt() e l’ottimizzazione 6k ± 1. 

La risposta è stata troncata perché ha raggiunto il tuo limite max_tokens di 512, come indicato da: "finish_reason": "length"

In questo test, il server ha elaborato il prompt a circa 357 token al secondo e generato testo a circa 73 token al secondo. 

La velocità può variare in base alla lunghezza del contesto, al carico GPU e alla dimensione del prompt. 

6. Accedi alla Web UI di llama.cpp per MiniMax M3

Poiché la porta 8910 è esposta tramite RunPod, puoi testare MiniMax M3 anche attraverso l’interfaccia web integrata di llama.cpp.

Nella dashboard di RunPod, apri il tuo Pod e clicca sul pulsante Connect. Sotto le porte HTTP esposte, seleziona il link per la porta 8910.

Questo apre l’interfaccia web di llama.cpp nel browser. Funziona come una leggera app di chat in stile ChatGPT, con il modello MiniMax M3 in esecuzione locale già selezionato. Ora puoi inviare prompt e testare il modello senza usare terminale o API.

Per un test pratico, ho chiesto a MiniMax M3 di generare un’interfaccia web Python per servire modelli di machine learning. Ha prodotto un progetto dettagliato basato su FastAPI con switch dei modelli, richieste di previsione JSON, upload batch CSV, streaming live via WebSocket, un registro modelli, endpoint di health, logging strutturato, test e setup Docker.

La risposta ha generato 5.510 token in 1 minuto e 19 secondi, raggiungendo circa 69 token al secondo. 

Per una quantizzazione locale a 3 bit in esecuzione su due RTX PRO 6000, è un ottimo risultato e mostra che MiniMax M3 può gestire richieste di coding più lunghe a velocità interattiva.

7. Collega Pi Coding Agent al tuo LLM locale

Pi è un agente di coding da terminale che può lavorare direttamente con i file del tuo progetto locale, eseguire comandi, ispezionare codice e usare il tuo modello MiniMax M3 ospitato in locale.

Apri un terzo terminale JupyterLab. Mantieni il primo terminale con llama-server in esecuzione, poi usa questo terminale per installare e configurare Pi.

Installa Pi con lo script ufficiale di installazione:

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

Se l’installer chiede se deve installare Node.js, digita Y e premi Invio. Pi installerà quindi il runtime Node.js richiesto e lo strumento a riga di comando pi.

Al termine dell’installazione, l’installer può mostrare un comando per aggiornare l’ambiente della shell. Esegui il comando fornito, poi riavvia la shell:

exec bash -l

Conferma che Pi sia disponibile:

pi --version

Dovresti vedere il numero di versione di Pi installato.

0.79.10

Pi supporta provider personalizzati compatibili con OpenAI tramite un file models.json. Crea la directory di configurazione di Pi:

mkdir -p ~/.pi/agent

Poi crea la configurazione del provider:

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

Questa configurazione dice a Pi di usare il server llama.cpp locale in esecuzione sulla porta 8910. L’impostazione API openai-completions corrisponde all’endpoint chat completions compatibile con OpenAI di llama.cpp.

Le impostazioni di compatibilità impediscono a Pi di inviare campi o ruoli di messaggio non supportati che possono creare problemi con alcuni server locali compatibili con OpenAI. In particolare, Pi userà il ruolo system invece del più recente ruolo developer e invierà max_tokens, che è ciò che si aspetta llama.cpp.

Il modello è indicato come solo testo con una finestra di contesto da 8K, in linea con la configurazione del server avviata in precedenza. I costi sono impostati a zero perché MiniMax M3 gira in locale sulla tua istanza RunPod e non tramite un’API a pagamento.

8. Esegui Pi con MiniMax M3

Apri un nuovo terminale JupyterLab per Pi. Per un’esperienza più confortevole con l’agente di coding, passa JupyterLab alla dark mode selezionando Settings → Theme → JupyterLab Dark.

Poi clona il progetto su cui vuoi far lavorare MiniMax M3:

cd /workspace

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

Avvia Pi:

pi

Dentro Pi, digita:

/model

Cerca local, poi seleziona MiniMax M3 Local 3-bit. Pi dovrebbe mostrare il provider locale e confermare che il modello GGUF MiniMax M3 è selezionato.

Inizia con un’attività in sola lettura così che Pi possa ispezionare il repository senza modificare file. Per esempio:

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

Pi userà strumenti da terminale come ls e read per esplorare il repository, ispezionare il README e rivedere file di supporto come .env.example, requirements.txt e il notebook Jupyter.

In questo esempio, MiniMax M3 ha identificato correttamente i file principali del progetto e ha spiegato che il repository è una demo di caching semantico costruita con Olostep e Qdrant. 

Ha evidenziato il workflow basato su notebook, le variabili d’ambiente richieste per le API, le impostazioni di soglia della cache e TTL, e le valutazioni di latenza, cache-hit e risparmio crediti incluse nel progetto.

Ho anche chiesto di creare un diagramma di workflow ASCII della pipeline di cache semantica. Ha generato un flusso chiaro che mostra come una query utente venga incorporata, verificata contro la cache Qdrant, valutata rispetto alla soglia di similarità e restituita dalla cache o inviata a Olostep prima di archiviare il risultato.

Per repository più grandi o attività multi-step più profonde, potresti aver bisogno di una finestra di contesto più ampia. Aggiorna il valore --ctx-size nel comando llama-server e riavvia il server. Inizia aumentando da 8192 a 16384, poi testa 32768` se la memoria GPU rimane disponibile.

Evita di passare direttamente a una finestra di contesto da 100K. Questo branch sperimentale di MiniMax M3 per llama.cpp usa attention densa invece di MiniMax Sparse Attention, quindi contesti molto ampi possono aumentare significativamente l’uso di memoria e causare errori di out-of-memory.

Considerazioni finali

Dopo aver eseguito MiniMax M3 in locale, penso offra un equilibrio molto migliore rispetto al tentativo di eseguire modelli di coding estremamente grandi come GLM 5.2 o Kimi K2.7 Code. 

Questi modelli possono essere più potenti in alcuni casi, ma richiedono anche molta più memoria GPU e possono diventare molto costosi da noleggiare e servire in locale.

Con MiniMax M3, sono riuscito a eseguire un modello capace per coding e agentica su due RTX PRO 6000, usarlo tramite un’interfaccia browser, esporlo tramite un’API compatibile con OpenAI e collegarlo a Pi come agente di coding locale. 

Nei miei test, ha generato a circa 70 token al secondo e ha gestito bene esplorazione di repository, analisi del README, esecuzione di comandi, spiegazioni di progetto e diagrammi di workflow.

Non è ancora una configurazione perfetta. Il supporto in llama.cpp è ancora sperimentale, Sparse Attention non è disponibile e la finestra di contesto deve restare relativamente piccola a meno di avere più VRAM. Tuttavia, per un modello quantizzato a 3 bit in esecuzione in locale, i risultati sono stati notevoli.