MiniMax M3 lokal ausführen: Multi-GPU-Setup mit llama.cpp und Pi Agent

MiniMax M3 ist MiniMax’ aktuelles Open-Weight-Modell für Codegenerierung, Tool-Aufrufe und langlaufende Agent-Workflows. Im Vergleich zu früheren MiniMax-Modellen sticht es durch die Kombination aus einem Kontextfenster mit 1 Million Tokens, nativer Multimodalität für Text, Bilder und Videos sowie MiniMax Sparse Attention hervor, das extrem lange Kontexte in der Praxis handhabbarer machen soll. 

Quelle: MiniMax 

In dieser Anleitung zeige ich dir, wie du MiniMax M3 lokal über zwei NVIDIA RTX PRO 6000 GPUs laufen lässt, das Modell über die integrierte Weboberfläche testest und den lokalen, OpenAI-kompatiblen Endpunkt mit dem Pi Coding Agent verbindest. 

Das Setup nutzt JupyterLab-Terminals auf einem RunPod-PyTorch-Pod statt SSH. llama.cpp wird mit CUDA-Unterstützung kompiliert und stellt das Modell auf Port 8910 bereit.

Systemanforderungen für den lokalen Betrieb von MiniMax M3

Bevor du MiniMax M3 lokal startest, stell sicher, dass dein System genügend GPU-Speicher und Festplattenspeicher zum Laden des Modells hat.

• GPUs: 2× NVIDIA RTX PRO 6000 GPUs mit jeweils 96 GB VRAM, insgesamt also 192 GB VRAM.
• Speicherplatz: Mindestens 350 GB freier Speicher für Modelfiles, den Hugging-Face-Cache, llama.cpp-Build-Dateien und temporäre Laufzeitdaten.
• Modellquantisierung: Verwende die UD-IQ3_XXS-GGUF-Quantisierung aus unsloth/MiniMax-M3-GGUF. Sie ist ca. 159 GB groß und für diese Hardware die praktikabelste Option.
• Runtime: Ein CUDA-fähiger Build von llama.cpp mit Multi-GPU-Unterstützung.

MiniMax M3 ist ein großes Mixture-of-Experts-Modell, daher müssen die Gewichte beim Inferenzlauf auf beide GPUs verteilt werden. Obwohl das System 192 GB kombinierten VRAM bietet, steht nicht der komplette Speicher allein dem Modell zur Verfügung. 

Ein Teil des VRAMs wird für Laufzeit-Overhead, Prompt-Verarbeitung und den KV-Cache benötigt.

Starte deshalb mit der UD-IQ3_XXS-Quantisierung. Mit rund 159 GB bleibt genug Speicher, damit das Modell laden und laufen kann. 

Meide 4-Bit-Quantisierungen von MiniMax M3 in diesem Setup, da die kleinste verfügbare 4-Bit-Datei etwa 208 GB groß ist und den verfügbaren VRAM bereits ohne Laufzeit-Overhead überschreitet.

1. Richte deine RunPod-Multi-GPU-Umgebung ein

Erstelle einen neuen RunPod-Pod und wähle 2× NVIDIA RTX PRO 6000 GPUs mit dem aktuellen RunPod PyTorch-Template. Dieses Template enthält JupyterLab, das wir in dieser Anleitung statt SSH verwenden.

Konfiguriere den Pod mit folgenden Einstellungen:

• Container Disk: 50 GB
• Volume Disk: 300 GB
• HTTP-Ports freigeben: 8910
• Umgebungsvariablen: HF_TOKEN: Dein Hugging-Face-Access-Token

Die 50 GB Container Disk sind nur für Betriebssystem, Pakete und temporäre Dateien gedacht. Auf der 300 GB Volume Disk sollten das MiniMax-M3-Modell und der Hugging-Face-Cache liegen. 

Gib den HTTP-Port 8910 frei, da llama.cpp später sowohl die Weboberfläche als auch die OpenAI-kompatible API auf diesem Port bereitstellt. Sobald der Server läuft, erreichst du ihn über eine URL in diesem Format:

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

Die hier verwendete Pod-Konfiguration kostet ungefähr $4,23 pro Stunde, der Preis kann je nach Verfügbarkeit und Standort variieren. 

Ich empfehle, mindestens $10 RunPod-Guthaben vorzuhalten, besser $15–$20 für den ersten Build, den Modelldownload und die Tests.

Sobald der Pod läuft, öffne ihn über das RunPod-Dashboard:

1. Öffne deinen Pod.
2. Klicke auf den Tab Connect.
3. Öffne JupyterLab.
4. Wähle in JupyterLab File → New → Terminal.

Prüfe zuerst, ob beide GPUs verfügbar sind:

nvidia-smi

Du solltest zwei NVIDIA RTX PRO 6000 GPUs mit jeweils rund 96 GB VRAM sehen.

Installiere anschließend die nötigen Build-Tools:

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

Zum Schluss prüfe, ob CUDA verfügbar ist:

nvcc --version

Du solltest CUDA 12.8 oder eine kompatible Version sehen. Jetzt kannst du llama.cpp mit CUDA-Unterstützung bauen.

2. Baue den MiniMax-M3-Branch von llama.cpp mit CUDA

llama.cpp ist eine Open-Source-Inferenz-Engine, mit der sich GGUF-Modelle lokal ausführen lassen. Wenn du noch nicht damit vertraut bist, lies am besten unsere umfassende llama.cpp-Anleitung. 

llama.cpp unterstützt CUDA-Beschleunigung, Multi-GPU-Offloading, eine integrierte Weboberfläche und einen OpenAI-kompatiblen API-Server. 

Die MiniMax-M3-Unterstützung ist noch experimentell. Du musst daher den dedizierten minimax-m3-Branch bauen statt eines Standard-Releases. 

Führe in deinem JupyterLab-Terminal folgende Befehle aus:

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

Konfiguriere anschließend llama.cpp mit CUDA und kompiliere die Server- und CLI-Binaries:

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

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

Damit entstehen zwei Binaries in build/bin/:

• llama-server: Browserbasierte Chatoberfläche und OpenAI-kompatibler API-Endpunkt.
• llama-cli: Teste das Modell direkt im Terminal.

Hinweis: Dies ist eine experimentelle MiniMax-M3-Implementierung. Textinferenz wird unterstützt, aber MiniMax Sparse Attention ist in diesem Branch nicht enthalten, daher verwendet llama.cpp dichte Attention. Vision-Support und MTP/speculative decoding sind ebenfalls nicht Teil dieses Builds.

3. Lade die MiniMax-M3-GGUF-Gewichte herunter

MiniMax M3 wird als mehrere GGUF-Dateien ausgeliefert. Lade den kompletten Ordner UD-IQ3_XXS vor dem Serverstart in das persistente Workspace-Volume.

Installiere zuerst die aktuelle Hugging-Face-Hub-CLI:

pip install -U huggingface_hub

Erstelle ein Verzeichnis für das Modell und aktiviere schnellere Hugging-Face-Downloads:

mkdir -p /workspace/unsloth

export HF_XET_HIGH_PERFORMANCE=1

Lade dann die UD-IQ3_XXS-Quantisierung:

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

Der Download umfasst ca. 159 GB und enthält fünf GGUF-Shards. Da das Modell unter /workspace gespeichert ist, bleibt es erhalten, wenn du den Pod stoppst und neu startest.

4. MiniMax M3 lokal über mehrere GPUs bereitstellen

Wechsle ins llama.cpp-Verzeichnis und mache beide GPUs für den Server verfügbar:

cd /workspace/llama.cpp

export CUDA_VISIBLE_DEVICES=0,1

Starte dann 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

Dieser Befehl lädt MiniMax M3 auf beide RTX PRO 6000 GPUs. Die Einstellung --tensor-split 1,1 teilt das Modell gleichmäßig zwischen den GPUs auf, während --n-gpu-layers 99 so viel wie möglich im GPU-Speicher hält.

Der Server läuft auf Port 8910 und stellt sowohl die llama.cpp-Weboberfläche als auch eine OpenAI-kompatible API bereit. Lass dieses Terminal geöffnet, solange das Modell läuft.

Starte mit einem 8K-Kontextfenster. Der experimentelle llama.cpp-Branch verwendet dichte Attention statt MiniMax Sparse Attention, daher können deutlich größere Kontexte zu Speicherkonflikten führen. Wenn der Server stabil läuft, kannst du --ctx-size 16384 testen.

Öffne ein weiteres JupyterLab-Terminal und prüfe mit folgendem Befehl, ob beide GPUs genutzt werden:

nvidia-smi

Sobald das Modell geladen ist, sollten beide GPUs deutlich VRAM belegt haben.

5. Die OpenAI-kompatible API von MiniMax M3 testen

Öffne ein neues JupyterLab-Terminal und prüfe zuerst, ob der Server läuft und MiniMax M3 geladen hat:

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

Du solltest eine Modell-ID ähnlich der folgenden sehen:

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

Sende als Nächstes eine Testanfrage an den OpenAI-kompatiblen Chat-Completions-Endpunkt:

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
  }'

Dein lokaler MiniMax-M3-Server funktioniert korrekt.

Er hat eine effiziente Python-Funktion is_prime() mit math.isqrt() und der 6k ± 1-Optimierung erzeugt. 

Die Antwort wurde abgeschnitten, weil sie dein Limit von max_tokens = 512 erreicht hat; erkennbar an "finish_reason": "length".

In diesem Test hat der Server den Prompt mit etwa 357 Tokens pro Sekunde verarbeitet und mit rund 73 Tokens pro Sekunde generiert. 

Deine Geschwindigkeit kann je nach Kontextlänge, GPU-Auslastung und Promptgröße variieren. 

6. Die llama.cpp-Weboberfläche für MiniMax M3 nutzen

Da der Port 8910 über RunPod freigegeben ist, kannst du MiniMax M3 auch über die integrierte llama.cpp-Weboberfläche testen.

Öffne im RunPod-Dashboard deinen Pod und klicke auf Connect. Wähle unter den freigelegten HTTP-Ports den Link für Port 8910.

Damit öffnet sich die llama.cpp-Weboberfläche in deinem Browser. Sie funktioniert wie eine schlanke ChatGPT-ähnliche Chat-App, mit dem lokal laufenden MiniMax-M3-Modell bereits vorausgewählt. Du kannst jetzt Prompts senden und das Modell ohne Terminal oder API testen.

Für einen Praxistest habe ich MiniMax M3 gebeten, eine Python-Weboberfläche zum Bereitstellen von ML-Modellen zu entwerfen. Es lieferte ein detailliertes FastAPI-Dashboard mit Modellwechsel, JSON-Prediction-Requests, CSV-Batch-Uploads, Live-WebSocket-Streaming, Model Registry, Health-Endpoints, strukturiertem Logging, Tests und Docker-Setup.

Die Antwort umfasste 5.510 Tokens in 1 Minute und 19 Sekunden, also rund 69 Tokens pro Sekunde. 

Für eine 3-Bit-Quantisierung auf zwei RTX PRO 6000 GPUs ist das ein starkes Ergebnis und zeigt, dass MiniMax M3 auch längere Coding-Aufgaben in interaktiver Geschwindigkeit bewältigt.

7. Pi Coding Agent mit deinem lokalen LLM verbinden

Pi ist ein terminalbasierter Coding-Agent, der direkt mit deinen lokalen Projektdateien arbeiten, Befehle ausführen, Code inspizieren und dein lokal gehostetes MiniMax-M3-Modell nutzen kann.

Öffne ein drittes JupyterLab-Terminal. Lass das erste Terminal mit llama-server weiterlaufen und installiere und konfiguriere Pi in diesem Terminal.

Installiere Pi mit dem offiziellen Installationsskript:

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

Wenn der Installer fragt, ob Node.js installiert werden soll, tippe Y und drücke Enter. Pi installiert dann die benötigte Node.js-Runtime und das pi-Kommandozeilentool.

Wenn die Installation abgeschlossen ist, zeigt der Installer ggf. einen Befehl zum Aktualisieren deiner Shell-Umgebung. Führe ihn aus und starte dann die Shell neu:

exec bash -l

Prüfe, ob Pi verfügbar ist:

pi --version

Du solltest die installierte Pi-Versionsnummer sehen.

0.79.10

Pi unterstützt benutzerdefinierte OpenAI-kompatible Provider über eine models.json. Lege das Konfigurationsverzeichnis von Pi an:

mkdir -p ~/.pi/agent

Erstelle dann die Provider-Konfiguration:

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

Diese Konfiguration teilt Pi mit, den lokalen llama.cpp-Server auf Port 8910 zu nutzen. Die Einstellung openai-completions passt zum OpenAI-kompatiblen Chat-Completions-Endpunkt von llama.cpp.

Die Kompatibilitätsflags verhindern, dass Pi nicht unterstützte Felder oder Rollen sendet, die bei manchen lokalen OpenAI-kompatiblen Servern Probleme verursachen könnten. Konkret verwendet Pi die Standardrolle system statt der neueren developer-Rolle und sendet max_tokens, wie es llama.cpp erwartet.

Das Modell ist als textbasiert mit 8K-Kontextfenster hinterlegt, passend zu deiner Serverkonfiguration. Die Kosten sind auf 0 gesetzt, da MiniMax M3 lokal auf deiner RunPod-Instanz läuft und nicht über eine kostenpflichtige API.

8. Pi mit MiniMax M3 ausführen

Öffne für Pi ein neues JupyterLab-Terminal. Für ein angenehmeres Agent-Erlebnis kannst du JupyterLab unter Settings → Theme → JupyterLab Dark auf den Dark Mode umstellen.

Klonen als Nächstes das Projekt, an dem MiniMax M3 arbeiten soll:

cd /workspace

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

Starte Pi:

pi

Gib in Pi Folgendes ein:

/model

Suche nach local, dann wähle MiniMax M3 Local 3-bit. Pi sollte den lokalen Provider anzeigen und bestätigen, dass das MiniMax-M3-GGUF-Modell ausgewählt ist.

Starte mit einer Read-only-Aufgabe, damit Pi das Repository inspizieren kann, ohne Dateien zu ändern. Zum Beispiel:

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

Pi nutzt Terminaltools wie ls und read, um das Repository zu erkunden, die README zu inspizieren und begleitende Dateien wie .env.example, requirements.txt und das Jupyter-Notebook anzusehen.

In diesem Beispiel hat MiniMax M3 die Hauptdateien korrekt identifiziert und erklärt, dass es sich um eine semantische Caching-Demo mit Olostep und Qdrant handelt. 

Es hob den Notebook-basierten Workflow hervor, die notwendigen Umgebungsvariablen für die APIs, die Cache-Schwelle und TTL-Einstellungen sowie die im Projekt enthaltenen Auswertungen zu Latenz, Cache-Hit-Rate und Kostenersparnis.

Ich habe es außerdem gebeten, ein ASCII-Workflow-Diagramm der semantischen Cache-Pipeline zu erstellen. Es zeigte klar den Fluss: Nutzeranfrage wird eingebettet, gegen den Qdrant-Cache geprüft, anhand des Ähnlichkeitsschwellenwerts bewertet und entweder aus dem Cache geliefert oder an Olostep gesendet, bevor das Ergebnis gespeichert wird.

Für größere Repositories oder tiefere Multi-Step-Aufgaben brauchst du ggf. ein größeres Kontextfenster. Erhöhe dazu den Wert von --ctx-size im llama-server-Befehl und starte den Server neu. Steigere zunächst von 8192 auf 16384 und teste dann 32768, wenn noch GPU-Speicher frei ist.

Springe nicht direkt auf ein 100K-Kontextfenster. Dieser experimentelle MiniMax-M3-Branch von llama.cpp nutzt dichte Attention statt MiniMax Sparse Attention. Sehr große Kontexte erhöhen den Speicherbedarf massiv und können zu Out-of-Memory-Fehlern führen.

Abschließende Gedanken

Nach dem lokalen Betrieb von MiniMax M3 finde ich, dass es einen deutlich besseren Kompromiss bietet als der Versuch, extrem große Coding-Modelle wie GLM 5.2 oder Kimi K2.7 Code lokal zu betreiben. 

Diese Modelle sind in manchen Fällen leistungsfähiger, benötigen aber deutlich mehr GPU-Speicher und werden lokal schnell teuer in der Miete und im Betrieb.

Mit MiniMax M3 konnte ich ein fähiges Coding- und Agentenmodell über zwei RTX PRO 6000 GPUs laufen lassen, es über den Browser nutzen, über eine OpenAI-kompatible API bereitstellen und als lokalen Coding-Agent in Pi einbinden. 

In meinen Tests generierte es mit rund 70 Tokens pro Sekunde und meisterte Repository-Erkundung, README-Analyse, Befehlsausführung, Projekterklärungen und Workflow-Diagramme zuverlässig.

Das Setup ist noch nicht perfekt. Die llama.cpp-Unterstützung ist experimentell, Sparse Attention fehlt und das Kontextfenster sollte relativ klein bleiben, sofern nicht mehr VRAM zur Verfügung steht. Für ein lokal laufendes, 3-Bit-quantisiertes Modell sind die Ergebnisse dennoch beeindruckend.