MiniMax M3: ¿un modelo puntero que puedes ejecutar tú mismo?

Los clientes con datos sensibles me siguen preguntando si los modelos abiertos ya son lo bastante buenos para ejecutarlos en su propio hardware. MiniMax M3 es uno de los modelos de pesos abiertos más capaces de 2026: unos 428.000 millones de parámetros, un contexto de un millón de tokens y texto, imagen y vídeo como entrada. También es lo bastante grande como para que 'ejecutarlo tú mismo' necesite un plan de verdad. Esto es lo que es M3, lo que dicen de verdad las cifras, lo que exige alojarlo y cuándo lo usaría.

Dominik Heinrich

7 de noviembre de 202611 min de lectura

1. Qué es M3

MiniMax publicó M3 el 1 de junio de 2026, y los pesos llegaron a Hugging Face justo después. Es un modelo mixture-of-experts multimodal nativo: unos 428.000 millones de parámetros en total, de los que unos 23.000 millones están activos en cada token, con texto, imagen y vídeo como entrada y texto como salida. MiniMax lo entrenó con modalidades mezcladas desde el primer paso, en vez de añadir la visión después.

La característica estrella es la ventana de contexto de un millón de tokens. Se apoya en MiniMax Sparse Attention, que según el informe técnico de MiniMax reduce el cómputo por token con un millón de tokens de contexto a una vigésima parte del de su predecesor M2. M3 admite además tres modos de razonamiento por petición: siempre activo, adaptativo y desactivado. Este último importa en la práctica, porque puedes cambiar profundidad por latencia en cada llamada y no en cada despliegue.

2. Por qué mixture-of-experts cambia las cuentas

En un modelo denso, cada parámetro trabaja en cada token. En un modelo mixture-of-experts, un router envía cada token a unos pocos expertos especializados, así que solo unos 23.000 de los 428.000 millones de parámetros trabajan en cada token. Eso hace que las respuestas sean mucho más rápidas y baratas de calcular de lo que sugiere el tamaño total, y por eso MoE se ha convertido en el diseño habitual de los grandes modelos abiertos.

La pega es la memoria. Todos los expertos tienen que estar en la memoria de la GPU, porque el router puede elegir cualquiera para el siguiente token. Pagas memoria como un modelo de 428.000 millones de parámetros y cómputo como uno mucho más pequeño. Para alojarlo es el dato más importante: el número de GPU lo fijan los parámetros totales más el contexto, y el rendimiento de esas GPU lo fijan los parámetros activos.

Consejo práctico

Al comparar opciones de alojamiento, dimensiona las GPU por parámetros totales y estima el rendimiento por parámetros activos. Confundirlos es el error de dimensionado más común con modelos MoE.

What is Mixture of Experts?, IBM Technology (YouTube). Se carga desde YouTube solo cuando haces clic.

3. Leer las cifras con cuidado

MiniMax y la receta de vLLM indican un 59,0 % en SWE-Bench Pro, un 66,0 % en Terminal-Bench 2.1 y un 74,2 % en MCP Atlas, todos resultados fuertes para programación con agentes y uso de herramientas. Son cifras del propio fabricante, medidas con su propio montaje. Artificial Analysis, que hace sus propias pruebas independientes, da a M3 un 19 en su Intelligence Index, por debajo de la media de los modelos abiertos de su tamaño, y señala a la vez que tiene buen precio y es más rápido que la media por tarea.

Ambas cosas pueden ser ciertas a la vez. Un modelo puede ser muy bueno programando con agentes y llamando herramientas y más flojo en razonamiento amplio o preguntas de conocimiento. La única cifra que importa para tu decisión es la de tu propio conjunto de pruebas: de 30 a 50 tareas reales con resultado esperado, contra M3 y contra el modelo alojado que usas hoy, midiendo calidad, latencia y coste por tarea.

4. Pesos abiertos no es código abierto

Los pesos se publican con la MiniMax Community License, no con MIT ni con Apache 2.0. El uso comercial es posible, pero tiene condiciones, así que lee la licencia con tu equipo legal antes de construir un producto encima, y otra vez antes de cada versión importante, porque las licencias cambian entre lanzamientos.

Trata la licencia como parte del artefacto. Guarda el texto de la licencia junto a los archivos del modelo en tu propio registro, anota qué versión ejecutas y dónde, y haz que esa información sea fácil de encontrar en una auditoría. Distingue además las familias de modelos: MiniMax publica varios modelos con la misma marca, como su modelo de vídeo H3, que es aparte, y cada uno tiene sus propias condiciones. 'Usamos MiniMax' no es lo bastante concreto para una revisión de cumplimiento; 'ejecutamos MiniMax-M3, esta revisión, con esta licencia, para estos casos de uso' sí lo es.

5. Qué hace falta para alojarlo

En BF16, solo los pesos ocupan unos 860 GB; en 8 bits, unos 430 GB. Encima va la caché KV para contextos largos, y con cientos de miles de tokens no es pequeña, ni siquiera con sparse attention. La configuración por defecto de la receta de vLLM es un único nodo con 8× H200, paralelismo de tensores y BF16. En AMD, BF16 también necesita ocho GPU, mientras que la variante MXFP8 funciona desde cuatro. MiniMax publica una versión MXFP8 y la receta recoge variantes NVFP4 y MXFP4 para hardware más nuevo.

Siendo realistas, es un nodo GPU dedicado en tu región cloud o centro de datos, no una estación de trabajo ni un clúster compartido que también ejecuta tus aplicaciones web. Usa la calculadora de abajo para ver cómo cambia la memoria según la precisión, y compara el precio de un nodo GPU reservado con lo que gastas hoy en llamadas a APIs alojadas. Para muchos equipos, solo compensa con un volumen alto y constante o cuando los datos sencillamente no pueden salir.

bash

# vLLM recipe default: one node, 8x H200, tensor parallel, BF16
vllm serve MiniMaxAI/MiniMax-M3 \
  --block-size 128 \
  --max-model-len 65536 \
  --tensor-parallel-size 8 \
  --tool-call-parser minimax_m3 \
  --enable-auto-tool-choice \
  --reasoning-parser minimax_m3

Consejo práctico

En el lanzamiento, el soporte de M3 no estaba en ninguna versión estable de vLLM; la receta fija una imagen de contenedor propia. Revisa la receta antes de fijar versiones en producción.

Interactivo

¿Cuánto cuesta alojar un modelo mixture-of-experts?

Todos los expertos deben estar en la memoria de la GPU, pero cada token solo pasa por los activos. La memoria escala con los parámetros totales y la velocidad con los activos.

Parámetros totales (miles de millones)428B

Activos por token (miles de millones)23B

Precisión

≈ 428 GB

pesos en memoria de GPU

GPUs de 80 GB, mínimo

23B

cómputo por token, como un modelo denso de este tamaño

Estimación para planificar: pesos más un 15 % para caché KV y ejecución. El rendimiento real depende del tamaño de lote, la interconexión y el motor de serving.

Todas las calculadoras y checklists

6. Ejecutarlo en Kubernetes como un servicio

Pon el modelo en un node pool con GPU dedicado y con un taint, para que solo caigan ahí los pods de inferencia, y usa el NVIDIA GPU Operator o las imágenes de nodos GPU de tu nube para mantener los drivers coherentes. En AKS, un node pool con GPU y el tamaño de VM adecuado te da la misma pieza. Guarda en caché los pesos en un object storage o en un volumen persistente ya cargado cerca del clúster, porque descargar cientos de gigabytes de internet en cada reinicio convierte el escalado y la recuperación en una caída.

Expón la API compatible con OpenAI de vLLM solo dentro de tu red, detrás de tu gateway y tu inicio de sesión único, nunca directamente en internet. Escala según la longitud de la cola y el tiempo hasta el primer token, no según la CPU, y alerta sobre memoria de GPU, tasa de errores y tokens por segundo. Las peticiones de contexto largo merecen sus propios límites, para que alguien que pega una base de código entera no deje sin servicio a los demás.

yaml

# Inference pod on a tainted 8-GPU node, weights from a pre-filled volume
spec:
  tolerations:
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule
  containers:
    - name: vllm
      image: vllm/vllm-openai:minimax-m3
      args: ["--model", "/models/MiniMax-M3", "--tensor-parallel-size", "8",
             "--block-size", "128", "--max-model-len", "65536"]
      resources:
        limits:
          nvidia.com/gpu: 8
      volumeMounts:
        - { name: weights, mountPath: /models }
        - { name: shm, mountPath: /dev/shm }
  volumes:
    - name: weights
      persistentVolumeClaim: { claimName: minimax-m3-weights }
    - name: shm
      emptyDir: { medium: Memory, sizeLimit: 64Gi }

Consejo práctico

Descarga la imagen y carga el volumen de pesos antes de necesitarlos. Un arranque en frío que baja 800 GB no es autoescalado, es una caída.

Arquitectura para alojar un modelo mixture-of-experts abierto en Kubernetes: un node pool con GPU dedicado ejecuta vLLM con paralelismo de tensores y de expertos, los pesos se cargan en caché desde object storage, una API interna compatible con OpenAI está detrás de un gateway con inicio de sesión único, el despliegue escala según la cola y la monitorización sigue la memoria de GPU, la latencia y los errores. (AWS) — Alojar un modelo MoE abierto: nodos GPU dedicados, pesos en caché, una API interna detrás de tu gateway y escalado según la cola.

7. Operarlo como un producto, no como un experimento

Un modelo alojado por ti es un servicio con usuarios, así que necesita lo que necesita cualquier servicio: un responsable, un plan de versiones, monitorización y una vuelta atrás. Pon delante un gateway de modelos que también conozca tus modelos alojados, para que las aplicaciones llamen a un único endpoint y el gateway enrute según clase de dato, coste y calidad. Así una actualización de modelo se convierte en un cambio de enrutado que puedes revertir en segundos.

La guía de Azure Well-Architected para cargas de IA y la Generative AI Lens de AWS insisten en las mismas bases de operación: evaluar de forma continua, vigilar la calidad y no solo la disponibilidad, y planificar la capacidad para los picos. En la práctica significa que tu conjunto de pruebas se ejecuta en cada cambio de modelo o de configuración, que un panel muestra calidad, latencia y coste por tarea de cada modelo uno al lado del otro, y que alguien lo mira cada semana.

8. Dónde encaja

M3 brilla donde los datos no pueden salir de tu red, donde documentos largos o bases de código enteras tienen que caber en un único contexto y donde los agentes trabajan con tus propias herramientas y servidores MCP. Ejecútalo junto a un modelo puntero alojado detrás de tu gateway, enruta según la clase de dato y compara calidad y coste con trabajo real durante unas semanas antes de decidir cuánto tráfico le das.

Vigila el ritmo de lanzamientos. En octubre de 2026 MiniMax publicó M3.1-Flash: la misma clase de tamaño, sparse attention en todo el modelo, entrenamiento consciente de la cuantización y decodificación especulativa, con el objetivo de mejores resultados y una inferencia más eficiente. Revisa la variante más nueva antes de comprar hardware. Y para las tareas de razonamiento más difíciles con datos que sí pueden salir de tu red, yo seguiría empezando con un modelo puntero alojado y dejaría que el conjunto de pruebas me diga cuándo uno abierto lo ha alcanzado.

Conclusión
M3 convierte el autoalojamiento en una opción seria para el trabajo sensible, si presupuestas las GPU. Toma los benchmarks como punto de partida, revisa la licencia y deja que decida tu propio conjunto de pruebas.

Proyectos reales relacionados

Robot con IA offline sobre un ESP32

Pruébalo tú mismo

¿Lo quieres en tu empresa? Hablemos mail@dominikheinrich.ch

Fuentes y guías oficiales

Más artículos