Como executar o MiniMax M3 localmente: configuração multi‑GPU com llama.cpp e Pi Agent

MiniMax M3 é o mais novo modelo open-weight da MiniMax para programação, uso de ferramentas e fluxos de trabalho agent com horizonte longo. O que o diferencia dos modelos anteriores da MiniMax é a combinação de uma janela de contexto de 1 milhão de tokens, suporte multimodal nativo para texto, imagens e vídeo, e o MiniMax Sparse Attention, projetado para tornar mais prática a inferência com contexto muito longo. 

Fonte: MiniMax 

Neste guia, vou mostrar como executar o MiniMax M3 localmente em duas GPUs NVIDIA RTX PRO 6000, testar o modelo pela interface web integrada e conectar o endpoint local compatível com OpenAI ao agente de código Pi. 

A configuração usa terminais do JupyterLab em um pod RunPod PyTorch em vez de SSH, com o llama.cpp compilado para CUDA e servindo o modelo na porta 8910.

Requisitos do sistema para executar o MiniMax M3 localmente

Antes de rodar o MiniMax M3 localmente, verifique se seu sistema tem memória de GPU e armazenamento suficientes para carregar o modelo.

• GPUs: 2× NVIDIA RTX PRO 6000 com 96 GB de VRAM cada, totalizando 192 GB de VRAM.
• Armazenamento: Pelo menos 350 GB de espaço livre para os arquivos do modelo, cache do Hugging Face, arquivos de build do llama.cpp e dados temporários de runtime.
• Quantização do modelo: Use a quantização GGUF UD-IQ3_XXS de unsloth/MiniMax-M3-GGUF. Ela tem aproximadamente 159 GB e é a opção mais prática para este hardware.
• Runtime: Uma build do llama.cpp com CUDA habilitado e suporte a múltiplas GPUs.

MiniMax M3 é um grande modelo de mixture‑of‑experts, então seus pesos precisam ser divididos entre as duas GPUs durante a inferência. Embora o sistema forneça 192 GB de VRAM combinada, nem toda essa memória pode ser usada pelo modelo em si. 

Parte da VRAM é necessária para overhead do runtime, processamento do prompt e o KV cache.

Por isso, comece pela quantização UD-IQ3_XXS. Com cerca de 159 GB, ela deixa memória suficiente para carregar e rodar o modelo. 

Evite quantizações 4‑bit do MiniMax M3 nesta configuração, pois o menor arquivo 4‑bit disponível tem cerca de 208 GB e já excede a VRAM disponível antes mesmo do overhead do runtime.

1. Configure seu ambiente multi‑GPU no RunPod

Crie um novo Pod no RunPod e selecione 2× NVIDIA RTX PRO 6000 com o template mais recente do RunPod PyTorch. Esse template inclui o JupyterLab, que vamos usar no lugar do SSH ao longo deste guia.

Configure o Pod com as seguintes definições:

• Container Disk: 50 GB
• Volume Disk: 300 GB
• Expose HTTP Ports: 8910
• Environment Variables: HF_TOKEN: seu token de acesso do Hugging Face

O disco de 50 GB do container é apenas para o sistema operacional, pacotes e arquivos temporários. O volume de 300 GB é onde o modelo MiniMax M3 e o cache do Hugging Face devem ficar. 

Exponha a porta HTTP 8910, pois o llama.cpp vai rodar a interface web e a API compatível com OpenAI nessa porta. Quando o servidor estiver ativo, você poderá acessá-lo por uma URL neste formato:

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

A configuração do Pod usada neste guia custa aproximadamente US$ 4,23 por hora, embora o preço possa variar conforme disponibilidade e região. 

Recomendo manter pelo menos US$ 10 em créditos do RunPod, mas US$ 15–US$ 20 é mais seguro para o build inicial, download do modelo e testes.

Depois que o Pod estiver rodando, abra-o pelo dashboard do RunPod:

1. Abra seu Pod.
2. Clique na aba Connect
3. Abra o JupyterLab.
4. No JupyterLab, selecione File → New → Terminal.

Primeiro, confirme que as duas GPUs estão disponíveis:

nvidia-smi

Você deve ver duas NVIDIA RTX PRO 6000, cada uma com aproximadamente 96 GB de VRAM.

Em seguida, instale as ferramentas de build necessárias:

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

Por fim, verifique se o CUDA está disponível:

nvcc --version

Você deve ver o CUDA 12.8 ou uma versão compatível. Agora você está pronto para compilar o llama.cpp com suporte a CUDA.

2. Compile o branch do MiniMax M3 no llama.cpp com CUDA

llama.cpp é um engine de inferência open source para rodar modelos GGUF localmente. Sugiro ler nosso guia completo de llama.cpp se você ainda não conhece. 

Ele oferece aceleração por CUDA, offloading multi‑GPU, interface web integrada e um servidor de API compatível com OpenAI. 

O suporte ao MiniMax M3 ainda é experimental, então você precisa compilar o llama.cpp a partir do branch dedicado minimax-m3 em vez de usar o release padrão. 

Rode os comandos abaixo no terminal do 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

Depois, configure o llama.cpp com suporte a CUDA e compile os binários do servidor e da linha de comando:

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

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

Isso cria dois binários em build/bin/:

• llama-server, que fornece a interface de chat no navegador e o endpoint de API compatível com OpenAI.
• llama-cli, que permite testar o modelo diretamente pelo terminal.

Observação: esta é uma implementação experimental do MiniMax M3. Ela oferece inferência de texto, mas o MiniMax Sparse Attention não está incluído neste branch, então o llama.cpp usa atenção densa. Suporte a visão e MTP/decodificação especulativa também não fazem parte deste build.

3. Baixe os pesos do modelo GGUF do MiniMax M3

O MiniMax M3 é distribuído em vários arquivos GGUF. Baixe a pasta completa UD-IQ3_XXS para o volume persistente de workspace antes de iniciar o servidor.

Primeiro, instale a versão mais recente da CLI do Hugging Face Hub:

pip install -U huggingface_hub

Crie um diretório para o modelo e ative downloads mais rápidos do Hugging Face:

mkdir -p /workspace/unsloth

export HF_XET_HIGH_PERFORMANCE=1

Depois, baixe a quantização UD-IQ3_XXS:

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

O download tem cerca de 159 GB e inclui cinco shards GGUF. Como o modelo é salvo em /workspace, ele continua disponível quando você parar e reiniciar o Pod.

4. Sirva o MiniMax M3 localmente em múltiplas GPUs

Vá para o diretório do llama.cpp e disponibilize as duas GPUs para o servidor:

cd /workspace/llama.cpp

export CUDA_VISIBLE_DEVICES=0,1

Depois, inicie o 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

Esse comando carrega o MiniMax M3 nas duas RTX PRO 6000. A opção --tensor-split 1,1 divide o modelo igualmente entre as GPUs, enquanto --n-gpu-layers 99 mantém o máximo possível do modelo na memória das GPUs.

O servidor roda na porta 8910 e oferece tanto a interface web do llama.cpp quanto uma API compatível com OpenAI. Mantenha este terminal aberto enquanto o modelo estiver em execução.

Comece com uma janela de contexto de 8K. O branch experimental do llama.cpp usa atenção densa em vez do MiniMax Sparse Attention, então usar uma janela muito maior pode causar problemas de memória. Quando o servidor estiver estável, você pode testar --ctx-size 16384.

Abra outro terminal do JupyterLab e rode o comando abaixo para confirmar o uso das duas GPUs:

nvidia-smi

Após o carregamento do modelo, ambas as GPUs devem mostrar uso significativo de VRAM.

5. Teste o endpoint de API compatível com OpenAI do MiniMax M3

Abra um novo terminal do JupyterLab e primeiro confirme que o servidor está rodando e que o MiniMax M3 foi carregado:

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

Você deve ver um ID de modelo semelhante a:

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

Em seguida, envie uma requisição de teste ao endpoint de chat completions compatível com 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
  }'

Seu servidor local do MiniMax M3 está funcionando corretamente.

Ele gerou uma função Python is_prime() eficiente usando math.isqrt() e a otimização 6k ± 1. 

A resposta foi cortada porque atingiu o limite de max_tokens de 512, indicado por: "finish_reason": "length"

Neste teste, o servidor processou o prompt a cerca de 357 tokens por segundo e gerou texto a aproximadamente 73 tokens por segundo. 

Sua velocidade pode variar conforme o tamanho do contexto, carga da GPU e tamanho do prompt. 

6. Acesse a Web UI do llama.cpp para o MiniMax M3

Como a porta 8910 está exposta pelo RunPod, você também pode testar o MiniMax M3 pela interface web integrada do llama.cpp.

No dashboard do RunPod, abra seu Pod e clique no botão Connect. Em exposed HTTP ports, selecione o link da porta 8910.

Isso abre a interface web do llama.cpp no seu navegador. Ela funciona como um chat leve no estilo do ChatGPT, já com o modelo MiniMax M3 local selecionado. Agora você pode enviar prompts e testar o modelo sem usar o terminal ou a API.

Para um teste prático, pedi ao MiniMax M3 para gerar uma interface web em Python para servir modelos de machine learning. Ele produziu um design detalhado de dashboard com FastAPI, incluindo troca de modelos, requisições de predição em JSON, uploads em lote por CSV, streaming ao vivo por WebSocket, um registry de modelos, endpoints de health, logging estruturado, testes e configuração Docker.

A resposta gerou 5.510 tokens em 1 minuto e 19 segundos, chegando a aproximadamente 69 tokens por segundo. 

Para uma quantização local de 3 bits rodando em duas RTX PRO 6000, é um resultado muito bom e mostra que o MiniMax M3 consegue lidar com pedidos de código mais longos em velocidade interativa.

7. Conecte o Pi Coding Agent ao seu LLM local

Pi é um agente de código em terminal que pode trabalhar diretamente com seus arquivos de projeto locais, executar comandos, inspecionar código e usar seu modelo MiniMax M3 hospedado localmente.

Abra um terceiro terminal do JupyterLab. Mantenha o primeiro terminal rodando o llama-server, e use este terminal para instalar e configurar o Pi.

Instale o Pi com o script oficial:

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

Se o instalador perguntar se deve instalar o Node.js, digite Y e pressione Enter. O Pi vai instalar o runtime de Node.js necessário e a ferramenta de linha de comando pi.

Quando a instalação terminar, o instalador pode mostrar um comando para atualizar seu ambiente de shell. Rode o comando indicado e reinicie o shell:

exec bash -l

Confirme que o Pi está disponível:

pi --version

Você deve ver o número da versão instalada do Pi.

0.79.10

O Pi suporta provedores personalizados compatíveis com OpenAI via um arquivo models.json. Crie o diretório de configuração do Pi:

mkdir -p ~/.pi/agent

Depois, crie a configuração do provedor:

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

Essa configuração informa ao Pi para usar o servidor local do llama.cpp rodando na porta 8910. A opção de API openai-completions corresponde ao endpoint de chat completions compatível com OpenAI do llama.cpp.

As definições de compatibilidade impedem o Pi de enviar campos ou papéis de mensagem não suportados que podem causar problemas com alguns servidores locais compatíveis com OpenAI. Em especial, o Pi usará o papel padrão system em vez do mais recente developer e enviará max_tokens, como o llama.cpp espera.

O modelo está listado como apenas texto com janela de contexto de 8K, alinhado à configuração do servidor iniciada anteriormente. Os valores de custo estão em zero porque o MiniMax M3 está rodando localmente na sua instância do RunPod, e não via uma API paga.

8. Rode o Pi com o MiniMax M3

Abra um novo terminal do JupyterLab para o Pi. Para uma experiência mais confortável com o coding agent, mude o JupyterLab para o modo escuro em Settings → Theme → JupyterLab Dark.

Em seguida, clone o projeto no qual você quer que o MiniMax M3 trabalhe:

cd /workspace

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

Inicie o Pi:

pi

Dentro do Pi, digite:

/model

Busque por local, então selecione MiniMax M3 Local 3-bit. O Pi deve mostrar o provedor local e confirmar que o modelo GGUF MiniMax M3 foi selecionado.

Comece com uma tarefa apenas de leitura, para que o Pi possa inspecionar o repositório sem alterar arquivos. Por exemplo:

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

O Pi usará ferramentas de terminal como ls e read para explorar o repositório, inspecionar o README e revisar arquivos de suporte como .env.example, requirements.txt e o notebook Jupyter.

Neste exemplo, o MiniMax M3 identificou corretamente os principais arquivos do projeto e explicou que o repositório é um demo de cache semântico construído com Olostep e Qdrant. 

Ele destacou o fluxo baseado em notebook, as variáveis de ambiente exigidas pelas APIs, as definições de threshold e TTL do cache e as avaliações de latência, acerto de cache e economia de créditos incluídas no projeto.

Também pedi para criar um diagrama ASCII do pipeline de cache semântico. Ele gerou um fluxo claro mostrando como a consulta do usuário é embutida, checada no cache do Qdrant, avaliada contra o threshold de similaridade e devolvida do cache ou enviada ao Olostep antes de armazenar o resultado.

Para repositórios maiores ou tarefas multi‑etapas mais profundas, você pode precisar de uma janela de contexto maior. Atualize o valor de --ctx-size no comando do llama-server e reinicie o servidor. Comece aumentando de 8192 para 16384, depois teste 32768 se ainda houver memória de GPU disponível.

Evite pular direto para uma janela de 100K. Este branch experimental do MiniMax M3 no llama.cpp usa atenção densa em vez do MiniMax Sparse Attention, então contextos muito grandes aumentam bastante o uso de memória e podem causar erros de falta de memória.

Considerações finais

Depois de rodar o MiniMax M3 localmente, acredito que ele oferece um equilíbrio bem melhor do que tentar executar modelos de código extremamente grandes como GLM 5.2 ou Kimi K2.7 Code. 

Esses modelos podem ser mais poderosos em alguns casos, mas também exigem muito mais memória de GPU e podem ficar bem caros para alugar e servir localmente.

Com o MiniMax M3, consegui rodar um modelo competente para código e agentes em duas RTX PRO 6000, usá-lo por uma interface no navegador, expô-lo por uma API compatível com OpenAI e conectá-lo ao Pi como agente de código local. 

Nos testes, ele gerou por volta de 70 tokens por segundo e se saiu bem em exploração de repositório, análise de README, execução de comandos, explicações de projeto e diagramas de workflow.

Ainda não é uma configuração perfeita. O suporte no llama.cpp é experimental, o Sparse Attention não está disponível e a janela de contexto precisa ficar relativamente pequena, a menos que você tenha mais VRAM. Mesmo assim, para um modelo quantizado em 3 bits rodando localmente, os resultados foram impressionantes.