Cómo ejecutar MiniMax M3 en local: configuración multi-GPU con llama.cpp y Pi Agent

MiniMax M3 es el último modelo de MiniMax con pesos abiertos para programación, uso de herramientas y flujos de trabajo de agentes de largo recorrido. Destaca frente a versiones anteriores por combinar una ventana de contexto de 1 millón de tokens, soporte multimodal nativo para texto, imágenes y vídeo, y MiniMax Sparse Attention, diseñada para hacer más práctica la inferencia con contextos muy largos. 

Fuente: MiniMax 

En esta guía te muestro cómo ejecutar MiniMax M3 en local utilizando dos GPU NVIDIA RTX PRO 6000, cómo probar el modelo desde su interfaz web integrada y cómo conectar el endpoint local compatible con OpenAI al agente de código Pi. 

La configuración usa terminales de JupyterLab en un pod de RunPod con PyTorch en lugar de SSH, con llama.cpp compilado para CUDA, sirviendo el modelo en el puerto 8910.

Requisitos del sistema para ejecutar MiniMax M3 en local

Antes de ejecutar MiniMax M3 en local, asegúrate de que tu sistema tiene suficiente memoria de GPU y almacenamiento para cargar el modelo.

• GPUs: 2× NVIDIA RTX PRO 6000 con 96 GB de VRAM cada una (192 GB de VRAM en total).
• Almacenamiento: al menos 350 GB de espacio libre para los archivos del modelo, la caché de Hugging Face, los binarios de compilación de llama.cpp y datos temporales de ejecución.
• Cuantización del modelo: usa la cuantización GGUF UD-IQ3_XXS de unsloth/MiniMax-M3-GGUF. Ocupa aproximadamente 159 GB y es la opción más práctica para este hardware.
• Runtime: una compilación de llama.cpp con CUDA y soporte multi-GPU.

MiniMax M3 es un modelo mixture-of-experts grande, por lo que sus pesos deben repartirse entre ambas GPU durante la inferencia. Aunque el sistema ofrece 192 GB de VRAM combinada, no toda esa memoria puede dedicarse al modelo.

Parte de la VRAM se reserva para la sobrecarga de ejecución, el procesamiento del prompt y la caché KV.

Por eso conviene empezar con la cuantización UD-IQ3_XXS. Con unos 159 GB, deja suficiente memoria para cargar y ejecutar el modelo. 

Evita las cuantizaciones de 4 bits de MiniMax M3 en esta configuración: el archivo de 4 bits más pequeño ronda los 208 GB y ya supera la VRAM disponible incluso antes de considerar la sobrecarga en tiempo de ejecución.

1. Configura tu entorno multi-GPU en RunPod

Crea un nuevo Pod en RunPod y selecciona 2× NVIDIA RTX PRO 6000 con la plantilla más reciente de RunPod PyTorch. Esta plantilla incluye JupyterLab, que usaremos en lugar de SSH durante toda la guía.

Configura el Pod con estos ajustes:

• Container Disk: 50 GB
• Volume Disk: 300 GB
• Expose HTTP Ports: 8910
• Environment Variables: HF_TOKEN: tu token de acceso de Hugging Face

El disco de 50 GB del contenedor se reserva para el sistema operativo, paquetes y archivos temporales. El volumen de 300 GB es donde debes ubicar el modelo MiniMax M3 y la caché de Hugging Face. 

Expón el puerto HTTP 8910, ya que más adelante llama.cpp servirá su interfaz web y la API compatible con OpenAI en este puerto. Una vez que el servidor esté en marcha, podrás acceder con una URL de este tipo:

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

La configuración del Pod utilizada para esta guía cuesta aproximadamente 4,23 $ por hora, aunque el precio puede variar según disponibilidad y ubicación. 

Te recomiendo mantener al menos 10 $ en créditos de RunPod; 15–20 $ es más seguro para la compilación inicial, la descarga del modelo y las pruebas.

Cuando el Pod esté activo, ábrelo desde el panel de RunPod:

1. Abre tu Pod.
2. Haz clic en la pestaña Connect
3. Abre JupyterLab.
4. En JupyterLab, ve a File → New → Terminal.

Primero, confirma que ambas GPU están disponibles:

nvidia-smi

Deberías ver dos NVIDIA RTX PRO 6000, cada una con unos 96 GB de VRAM.

A continuación, instala las herramientas de compilación necesarias:

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

Por último, verifica que CUDA está disponible:

nvcc --version

Deberías ver CUDA 12.8 o una versión compatible. Ya puedes compilar llama.cpp con soporte CUDA.

2. Compila la rama de MiniMax M3 de llama.cpp con CUDA

llama.cpp es un motor de inferencia de código abierto para ejecutar modelos GGUF en local. Si no lo conoces, te recomiendo leer nuestra guía completa de llama.cpp. 

Ofrece aceleración por CUDA, descarga multi-GPU, interfaz web integrada y un servidor de API compatible con OpenAI. 

El soporte para MiniMax M3 aún es experimental, así que debes compilar llama.cpp desde la rama específica minimax-m3 en lugar de usar la versión estándar. 

Ejecuta estos comandos desde el terminal de 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

Ahora configura llama.cpp con soporte CUDA y compila los binarios del servidor y la CLI:

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

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

Esto crea dos binarios en build/bin/:

• llama-server, que ofrece la interfaz de chat en el navegador y el endpoint de API compatible con OpenAI.
• llama-cli, para probar el modelo directamente desde el terminal.

Nota: esta implementación de MiniMax M3 es experimental. Soporta inferencia de texto, pero MiniMax Sparse Attention no está incluida en esta rama, por lo que llama.cpp usa atención densa. Tampoco incluye visión ni MTP/decodificación especulativa.

3. Descarga los pesos GGUF de MiniMax M3

MiniMax M3 se distribuye en varios archivos GGUF. Descarga la carpeta completa UD-IQ3_XXS en el volumen persistente de trabajo antes de iniciar el servidor.

Primero, instala la CLI más reciente de Hugging Face Hub:

pip install -U huggingface_hub

Crea un directorio para el modelo y habilita descargas más rápidas desde Hugging Face:

mkdir -p /workspace/unsloth

export HF_XET_HIGH_PERFORMANCE=1

Luego descarga la cuantización UD-IQ3_XXS:

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

La descarga ronda los 159 GB e incluye cinco fragmentos GGUF. Como el modelo se guarda en /workspace, seguirá disponible aunque detengas y reinicies el Pod.

4. Sirve MiniMax M3 en local usando varias GPU

Ve al directorio de llama.cpp y haz visibles ambas GPU para el servidor:

cd /workspace/llama.cpp

export CUDA_VISIBLE_DEVICES=0,1

Luego inicia 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

Este comando carga MiniMax M3 en ambas RTX PRO 6000. La opción --tensor-split 1,1 reparte el modelo a partes iguales entre las GPU, mientras que --n-gpu-layers 99 mantiene la mayor parte posible del modelo en memoria de GPU.

El servidor se ejecuta en el puerto 8910 y ofrece tanto la interfaz web de llama.cpp como una API compatible con OpenAI. Mantén este terminal abierto mientras el modelo esté en ejecución.

Empieza con una ventana de contexto de 8K. Esta rama experimental de llama.cpp usa atención densa en lugar de MiniMax Sparse Attention, así que emplear contextos mucho mayores puede causar problemas de memoria. Cuando el servidor funcione, puedes probar --ctx-size 16384.

Abre otro terminal de JupyterLab y ejecuta el siguiente comando para confirmar que ambas GPU están en uso:

nvidia-smi

Tras la carga del modelo, ambas GPU deberían mostrar un uso de VRAM elevado.

5. Prueba el endpoint de API compatible con OpenAI de MiniMax M3

Abre un nuevo terminal en JupyterLab y primero confirma que el servidor está activo y ha cargado 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'])"

Deberías ver un ID de modelo similar a:

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

Luego envía una solicitud de prueba al endpoint de chat completions compatible 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
  }'

Tu servidor local de MiniMax M3 funciona correctamente.

Generó una función de Python is_prime() eficiente usando math.isqrt() y la optimización 6k ± 1.

La respuesta se cortó porque alcanzó tu límite de max_tokens de 512, indicado por: "finish_reason": "length"

En esta prueba, el servidor procesó el prompt a ~357 tokens por segundo y generó texto a ~73 tokens por segundo. 

Tu velocidad puede variar según la longitud del contexto, la carga de la GPU y el tamaño del prompt. 

6. Accede a la interfaz web de llama.cpp para MiniMax M3

Como el puerto 8910 está expuesto en RunPod, también puedes probar MiniMax M3 desde la interfaz web integrada de llama.cpp.

En el panel de RunPod, abre tu Pod y haz clic en Connect. En los puertos HTTP expuestos, selecciona el enlace del puerto 8910.

Se abrirá la interfaz web de llama.cpp en tu navegador. Funciona como una app de chat ligera al estilo ChatGPT, con el modelo MiniMax M3 local ya seleccionado. Ahora puedes enviar prompts y probar el modelo sin usar terminal ni API.

Como prueba práctica, le pedí a MiniMax M3 que generara una interfaz web en Python para servir modelos de machine learning. Produjo un diseño detallado con FastAPI con cambio de modelo, solicitudes de predicción en JSON, cargas por lotes en CSV, streaming en vivo por WebSocket, registro de modelos, endpoints de salud, logging estructurado, tests y un setup con Docker.

La respuesta generó 5.510 tokens en 1 minuto y 19 segundos, a ~69 tokens por segundo. 

Para una cuantización local de 3 bits funcionando en dos RTX PRO 6000, es un resultado sólido y demuestra que MiniMax M3 puede manejar peticiones de código largas a velocidad interactiva.

7. Conecta Pi Coding Agent a tu LLM local

Pi es un agente de código basado en terminal que puede trabajar directamente con tus archivos de proyecto, ejecutar comandos, inspeccionar código y usar tu modelo MiniMax M3 alojado en local.

Abre un tercer terminal en JupyterLab. Mantén el primer terminal ejecutando llama-server, y usa este terminal para instalar y configurar Pi.

Instala Pi con el script oficial:

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

Si el instalador te pregunta si debe instalar Node.js, escribe Y y pulsa Intro. Pi instalará el runtime de Node.js requerido y la herramienta de línea de comandos pi.

Al finalizar, el instalador puede mostrar un comando para actualizar tu shell. Ejecútalo y reinicia la shell:

exec bash -l

Confirma que Pi está disponible:

pi --version

Deberías ver el número de versión instalada de Pi.

0.79.10

Pi admite proveedores personalizados compatibles con OpenAI mediante un archivo models.json. Crea el directorio de configuración de Pi:

mkdir -p ~/.pi/agent

Luego crea la configuración del proveedor:

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

Esta configuración indica a Pi que use el servidor local de llama.cpp en el puerto 8910. El ajuste de API openai-completions coincide con el endpoint de chat completions compatible con OpenAI de llama.cpp.

Las opciones de compatibilidad evitan que Pi envíe campos o roles de mensaje no compatibles que puedan causar problemas con algunos servidores locales. En particular, Pi usará el rol estándar system en lugar del más reciente developer y enviará max_tokens, que es lo que espera llama.cpp.

El modelo se declara como solo texto con una ventana de 8K, en línea con la configuración del servidor que iniciaste. Los costes están a cero porque MiniMax M3 se ejecuta en tu instancia de RunPod en lugar de a través de una API de pago.

8. Ejecuta Pi con MiniMax M3

Abre un nuevo terminal de JupyterLab para Pi. Para una experiencia más cómoda, cambia JupyterLab a modo oscuro desde Settings → Theme → JupyterLab Dark.

A continuación, clona el proyecto en el que quieres que trabaje MiniMax M3:

cd /workspace

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

Lanza Pi:

pi

Dentro de Pi, escribe:

/model

Busca local, luego selecciona MiniMax M3 Local 3-bit. Pi debería mostrar el proveedor local y confirmar que el modelo GGUF de MiniMax M3 está seleccionado.

Empieza con una tarea de solo lectura para que Pi inspeccione el repositorio sin cambiar archivos. Por ejemplo:

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

Pi usará herramientas de terminal como ls y read para explorar el repositorio, inspeccionar el README y revisar archivos de apoyo como .env.example, requirements.txt y el cuaderno de Jupyter.

En este ejemplo, MiniMax M3 identificó correctamente los archivos principales y explicó que el repositorio es una demo de caché semántica creada con Olostep y Qdrant. 

Destacó el flujo de trabajo basado en notebook, las variables de entorno necesarias para las APIs, los ajustes de umbral de caché y TTL, y las evaluaciones de latencia, aciertos de caché y ahorro de créditos incluidas en el proyecto.

También le pedí un diagrama ASCII del flujo de la canalización de caché semántica. Generó un esquema claro que muestra cómo una consulta se incrusta, se comprueba en la caché de Qdrant, se evalúa contra el umbral de similitud y se devuelve desde la caché o se envía a Olostep antes de almacenar el resultado.

Para repositorios más grandes o tareas de varios pasos, quizá necesites una ventana de contexto mayor. Actualiza el valor de --ctx-size en el comando de llama-server y reinicia el servidor. Sube primero de 8192 a 16384 y luego prueba 32768 si aún queda memoria de GPU disponible.

Evita saltar directamente a 100K de contexto. Esta rama experimental de MiniMax M3 para llama.cpp usa atención densa en lugar de MiniMax Sparse Attention, por lo que contextos muy grandes incrementan notablemente el uso de memoria y pueden causar errores de falta de memoria.

Reflexiones finales

Tras ejecutar MiniMax M3 en local, creo que ofrece un equilibrio mucho mejor que intentar ejecutar modelos de código extremadamente grandes como GLM 5.2 o Kimi K2.7 Code. 

Esos modelos pueden ser más potentes en algunos casos, pero requieren mucha más memoria de GPU y pueden resultar muy caros de alquilar y servir en local.

Con MiniMax M3 pude ejecutar un modelo capaz para programación y agentes en dos RTX PRO 6000, usarlo desde el navegador, exponerlo mediante una API compatible con OpenAI y conectarlo a Pi como agente de código local. 

En mis pruebas, generó a ~70 tokens por segundo y gestionó bien la exploración de repos, el análisis del README, la ejecución de comandos, las explicaciones del proyecto y los diagramas de flujo.

Aún no es una configuración perfecta. El soporte en llama.cpp sigue siendo experimental, Sparse Attention no está disponible y la ventana de contexto debe mantenerse relativamente pequeña salvo que dispongas de más VRAM. Aun así, para un modelo cuantizado a 3 bits en local, los resultados son muy buenos.