MiniMax M3.1 Flash: MoE de 428B com 23B Ativos, Raciocínio Ajustável e Janela de 1M

A MiniMax disponibilizou oficialmente o MiniMax M3.1 Flash, variante recém-lançada de sua linha principal de modelos de linguagem projetada para automação corporativa multi-etapas, engenharia de software, operação visual de computadores (Computer Use) e auditoria de cibersegurança. O lançamento combina 428 bilhões de parâmetros totais com cerca de 23 bilhões de parâmetros ativos por token em uma topologia Mixture-of-Experts (MoE), janela de contexto de 1.000.000 de tokens de entrada (com até 512.000 tokens de saída) e velocidade de geração que atinge medianas (P50) de 170+ tokens por segundo (TPS), alcançando picos acima de 200 TPS em produção.

O objetivo central da versão M3.1 é solucionar o gargalo financeiro das frotas de agentes autônomos que executam dezenas de chamadas de ferramentas (tool calls) encadeadas. Ao aplicar uma esparsidade mais agressiva no roteamento entre especialistas, a MiniMax triplicou a velocidade de inferência online frente ao MiniMax M3 original e reduziu o custo médio por tarefa concluída em cerca de 70%. Na API oficial, a cobrança adota uma tarifa plana de $0,15 por milhão de tokens de entrada, $0,60 por milhão de tokens de saída e $0,015 por milhão de tokens em leitura de cache (KV Cache), extinguindo sobretaxas para contextos longos acima de 512 mil tokens.

No plano de engenharia de software, a principal mudança comportamental está no motor de reflexão do modelo. Na linha M3.1, o raciocínio é sempre ativo (always-on) e não pode ser desabilitado, sendo modulado por cinco níveis explícitos de esforço (low, medium, high, xhigh e max). Além disso, a cadeia de pensamento é emitida em um campo dedicado (reasoning_content) no payload da API, exigindo atualização imediata em integrações que antes faziam parsing de tags <think> embutidas no texto.

1. O Fato e o Contexto: Posicionamento Técnico da Linha M3.1

O lançamento da versão M3.1 ocorre em um cenário no qual equipes de desenvolvimento e operações corporativas migram de chatbots isolados para agentes de longa duração — rotinas capazes de inspecionar contratos em PDF, reconciliar lançamentos contábeis no SAP ou NetSuite, operar sistemas de CRM como Salesforce e abrir pull requests validados por suítes de testes. Nesses fluxos de trabalho (CoWork), uma única solicitação do usuário frequentemente dispara entre 30 e 100 turnos internos de leitura de estado e invocação de APIs.

Ao preservar a mesma escala nominal do MiniMax M3 (428 bilhões de parâmetros totais e aproximadamente 23 bilhões ativos), mas reformular o agendador de decodificação e a esparsidade das camadas de atenção, a MiniMax posiciona o novo checkpoint como seu motor padrão para cargas interativas e assíncronas. O serviço já opera via API (platform.minimax.io), no pacote de assinatura M Plan e no editor desktop MiniMax Code, enquanto os pesos abertos para auto-hospedagem têm liberação confirmada para 23 de outubro de 2026.

A diretriz tarifária simplifica o cálculo de TCO (Total Cost of Ownership). Enquanto o MiniMax M3 anterior cobrava $0,30 por milhão de tokens na entrada e $1,20 na saída até 512 mil tokens — dobrando o preço para $0,60/$2,40 na faixa entre 512 mil e 1 milhão de tokens —, a versão M3.1 aplica metade do valor base ($0,15/$0,60) de maneira linear do primeiro ao milionésimo token.

2. Arquitetura MoE de 428B, Atenção Esparsa e Multimodalidade Nativa

O ganho de throughput da família M3.1 apoia-se em três decisões de arquitetura: roteamento esparso entre especialistas, compressão de estados de atenção para janelas de 1M e acoplamento direto de um codificador visual ao tronco do transformador.

2.1 Proporção de Ativação (428B Totais / ~23B Ativos)

Com apenas cerca de 5,3% da rede mobilizada a cada passo de geração (~23 bilhões de parâmetros ativos dentro de um reservatório total de 428 bilhões), o modelo combina a capacidade de armazenamento semântico de uma arquitetura de porte robusto com o requisito de leitura de memória HBM típico de um modelo denso de 20B. Essa baixa pressão sobre a largura de banda de memória das GPUs permite sustentar 170+ TPS na mediana (P50) e ultrapassar 200 TPS em rajadas de geração de código ou relatórios estruturados.

2.2 Entrada Multimodal Nativa (Texto, Imagem e Vídeo)

Diferente de alternativas que processam apenas texto ou exigem modelos separados para visão, o M3.1 aceita nativamente texto, imagens estáticas e fluxos de vídeo na entrada, produzindo texto estruturado na saída. O codificador visual converte capturas de tela de alta resolução, diagramas técnicos e quadros sequenciais de vídeo em representações vetoriais compartilhadas com os tokens lexicais, sustentando a navegação direta em interfaces gráficas (GUI automation).

2.3 Comparativo Estrutural: Evolução da Família MiniMax (M2.7 vs M3 vs M3.1)

A tabela a seguir detalha a evolução técnica entre as gerações recentes da MiniMax, evidenciando o salto em capacidade de saída e redução tarifária:

3. Batalha de Benchmarks Reais: Confronto contra a Fronteira Contemporânea

Para medir com objetividade onde o novo modelo da MiniMax entrega superioridade e onde apresenta gargalos, confrontamos os resultados reportados com os principais modelos contemporâneos da mesma geração: DeepSeek V4.1 (552B totais, 8B ativos no prefill e 16B no decode), Gemini 4 Argon da Google, Claude Opus 5.5 da Anthropic, Kimi K3 (2,8T totais / 104B ativos) e GLM-5.3 (~744B totais / ~40B ativos).

3.1 Automação Corporativa e Fluxos SaaS (Automation-Bench e BankerToolBench)

Nos benchmarks desenhados para medir trabalho de escritório e orquestração de sistemas empresariais (CoWork), o M3.1 atinge o topo da tabela:

• Automation-Bench v1.0.6: Registra 62,2 pontos na tabela consolidada (e 62,8 no gráfico de esforço máximo), superando DeepSeek V4.1 (54,8), Gemini 4 Argon (53,5), Claude Opus 5.5 (50,3), GLM-5.3 (48,8), Kimi K3 (46,7) e GPT-6 Astra (45,8).

• BankerToolBench: Em rotinas financeiras e bancárias que exigem planejamento de múltiplos passos, conformidade regulatória, cruzamento entre planilhas e chamadas encadeadas de APIs, alcança 76,2 pontos, empatando na liderança com o Claude Opus 5.5 (76,2).

• LOCA-Bench 256K: Na avaliação de consistência analítica sobre contextos de 256 mil tokens, conquista a primeira colocação com 60,3 pontos.

3.2 Engenharia de Software e Código (DeepSWE v1.1)

No DeepSWE v1.1, suíte que avalia a capacidade de investigar repositórios reais, desenvolver novas funcionalidades, corrigir defeitos e validar patches por meio de testes automatizados:

• Gemini 4 Argon: 75,4%;

• DeepSeek V4.1 (build 1017): 74,2% no comparativo base (chegando a 77,0% em esforço máximo);

• MiniMax M3.1: 73,7%;

• Kimi K3: 67,5% (número confirmado de forma independente no model card oficial da Moonshot);

• GLM-5.3: 66,9%.

O índice de 73,7% confirma que a redução de custo para $0,15/$0,60 não comprometeu a capacidade de resolução de bugs em repositórios complexos, mantendo o modelo no mesmo patamar competitivo de seus pares diretos.

3.3 Operação de Computadores e Raciocínio Visual (OSWorld V2, ALE e BabyVision)

Na interação direta com ambientes gráficos e interpretação visual:

• OSWorld V2 (Computer Use): Atinge 61,7 pontos, superando o Gemini 4 Argon (59,1) e o DeepSeek V4.1 (56,2), assumindo a liderança entre os modelos de origem asiática na execução de tarefas cruzadas entre aplicativos de sistema operacional.

• Agents' Last Exam (ALE): Na bateria de 152 tarefas profissionais de valor econômico real, marca 29,6 pontos, primeiro lugar entre os laboratórios chineses.

• BabyVision (com ferramentas) e CharXiv RQ: Na leitura de gráficos científicos e raciocínio visual auxiliado por ferramentas, alcança 91,0% no BabyVision (frente a 89,6% da DeepSeek e 85,7% do Kimi K3) e 82,5% no CharXiv RQ. No HLE (Humanity's Last Exam) sem ferramentas, anota 43,4%.

3.4 Segurança Cibernética (CyberGym)

No benchmark CyberGym, dedicado à descoberta de vulnerabilidades e validação de exploits em código real, o modelo registra 82,0%, mostrando alta eficácia em auditoria estática, construção de patches de segurança, análise de artefatos maliciosos e engenharia reversa.

3.5 Limitações Reais e Pontos de Atenção (Terminal-Bench 4.0 e Refatoração)

Todo engenheiro de IA deve avaliar as limitações antes de colocar um modelo em produção:

• Desempenho fraco em linha de comando pura (Terminal-Bench 4.0): O resultado mais baixo do M3.1 ocorre no Terminal-Bench 4.0, onde marca 38,1 pontos — ficando 13,7 pontos atrás do Claude Opus 5.5 (51,8), embora próximo do GLM-5.3 (37,9) e acima da DeepSeek (31,2) e do Kimi K3 (12,6).

• Refatoração pesada e criação de repositórios do zero: No SWE-Refactor-Bench, anota 23,0 pontos contra 31,0 do Claude Opus 5.5; no NL2Repo-Bench, fica 14,1 pontos atrás do Opus 5.5.

• Sensibilidade ao harness de avaliação: Todos os números iniciais vêm da bateria oficial da MiniMax, e mudanças no scaffold agêntico alteram os resultados. No Automation-Bench, por exemplo, o card público do Kimi K3 reporta 30,8 em um subconjunto de 600 tarefas, enquanto a tabela da MiniMax lista 46,7 sob seu próprio harness, além de uma pequena divergência interna onde o gráfico de custo plota 62,8 no esforço máximo e a tabela resumo informa 62,2.

4. Raciocínio Always-On e os 5 Níveis de Esforço (reasoning_effort)

A mudança mais importante de engenharia na migração para o M3.1 está no comportamento do raciocínio: ele está sempre ligado (always-on) e não pode ser desativado.

4.1 Como funcionam os 5 Níveis de Esforço

Em vez de uma chave binária liga/desliga, o desenvolvedor seleciona um entre cinco níveis no parâmetro reasoning_effort:

• low: Pensamento mínimo para classificação, roteamento de intenções e triagem rápida (pontua 52,8 no Automation-Bench com latência mínima);

• medium: Indicado para extração de entidades em JSON, sumarização de documentos e geração de consultas SQL/GraphQL;

• high: Ponto intermediário para implementação de código, escrita de testes unitários e revisão de pull requests;

• xhigh: Recomendado para auditoria SecOps, conciliação financeira multi-arquivos e depuração de concorrência;

• max: Configuração padrão recomendada pela MiniMax, habilitando a cadeia completa de reflexão para automação corporativa e Computer Use (chegando a 62,2–62,8 no Automation-Bench).

4.2 Quebra de Compatibilidade: thinking.type=disabled e Campo reasoning_content

Existem dois alertas críticos de migração em relação ao MiniMax M3:

• Rejeição de chamadas sem raciocínio: Qualquer requisição que envie thinking.type="disabled" ou reasoning_effort="none" receberá um erro HTTP 400 da API. Isso impõe um piso mínimo de consumo de tokens e de tempo até o primeiro token visível (TTFT) mesmo em chamadas triviais.

• Fim das tags <think> inline: Enquanto integrações antigas costumavam filtrar blocos <think>...</think> dentro da string principal de resposta, na versão M3.1 o raciocínio é entregue separadamente no atributo reasoning_content (que pode estar ausente em determinados turnos). Parsers legados precisam ser atualizados para ler esse campo estruturado.

5. Implementação Prática em Python: Cliente Agêntico com Raciocínio Ajustável

O código a seguir implementa um cliente assíncrono utilizando httpx para consumir o MiniMax M3.1 via API compatível com OpenAI, validando os cinco níveis de esforço permitidos, separando o streaming de reasoning_content da resposta final e processando chamadas de ferramentas:

import asyncio import json import os import sys from typing import Any, AsyncGenerator, Dict, List, Optional import httpx MINIMAX_API_URL = "https\://api.minimax.io/v1/text/chatcompletion_v2" MINIMAX_API_KEY = os.getenv("MINIMAX_API_KEY", "SUA_CHAVE_API_MINIMAX") VALID_EFFORT_LEVELS = {"low", "medium", "high", "xhigh", "max"} BANKER_TOOLS_SCHEMA: List[Dict[str, Any]] = [ { "type": "function", "function": { "name": "reconciliar_lancamento_erp", "description": ( "Cruza fatura comercial com ordem de compra no ERP e valida " "retenção fiscal." ), "parameters": { "type": "object", "properties": { "invoice_id": { "type": "string", "description": "Código identificador da fatura.", }, "po_number": { "type": "string", "description": "Número da ordem de compra vinculada.", }, "currency": {"type": "string", "enum": ["BRL", "USD", "EUR"]}, }, "required": ["invoice_id", "po_number", "currency"], }, }, } ] class MiniMaxM31Agent: def __init__(self, api_key: str, endpoint: str = MINIMAX_API_URL) -> None: self.api_key = api_key self.endpoint = endpoint self.headers = { "Authorization": f"Bearer {self.api_key}", "Content-Type": "application/json", } async def stream_turn( self, messages: List[Dict[str, Any]], effort: str = "max", tools: Optional[List[Dict[str, Any]]] = None, ) -> AsyncGenerator[Dict[str, Any], None]: if effort not in VALID_EFFORT_LEVELS: raise ValueError( f"Esforço '{effort}' inválido. Valores suportados: " f"{sorted(VALID_EFFORT_LEVELS)}" ) payload: Dict[str, Any] = { "model": "MiniMax-M3.1-Flash", "messages": messages, "stream": True, "reasoning_effort": effort, "temperature": 0.2, "max_tokens": 8192, } if tools: payload["tools"] = tools payload["tool_choice"] = "auto" async with httpx.AsyncClient(timeout=120.0) as http_client: async with http_client.stream( "POST", self.endpoint, headers=self.headers, json=payload ) as response: if response.status_code != 200: raw_err = await response.aread() raise RuntimeError( f"Falha na API MiniMax (HTTP {response.status_code}): " f"{raw_err.decode('utf-8')}" ) async for line in response.aiter_lines(): if not line.startswith("data: "): continue payload_str = line[6:].strip() if payload_str == "[DONE]": break try: chunk = json.loads(payload_str) choice = chunk["choices"][0] delta = choice.get("delta", {}) yield { "reasoning_content": delta.get("reasoning_content") or "", "content": delta.get("content") or "", "tool_calls": delta.get("tool_calls"), "finish_reason": choice.get("finish_reason"), } except (KeyError, IndexError, json.JSONDecodeError): continue async def run_audit_workflow() -> None: if MINIMAX_API_KEY == "SUA_CHAVE_API_MINIMAX": print("Configure a variável de ambiente MINIMAX_API_KEY para executar o fluxo em produção.") sys.exit(0) agent = MiniMaxM31Agent(api_key=MINIMAX_API_KEY) conversation: List[Dict[str, Any]] = [ { "role": "system", "content": ( "Você é um auditor financeiro automatizado operando sobre o ERP " "corporativo." ), }, { "role": "user", "content": ( "Reconcilie a fatura INV-9082 com a ordem PO-4410 em USD e aponte " "divergências." ), }, ] print("--- [Iniciando Raciocínio Always-On (effort=xhigh)] ---") async for step in agent.stream_turn( messages=conversation, effort="xhigh", tools=BANKER_TOOLS_SCHEMA ): if step["reasoning_content"]: print(step["reasoning_content"], end="", flush=True) if step["content"]: print(step["content"], end="", flush=True) if step["tool_calls"]: print("[Chamada de Ferramenta]:", json.dumps(step["tool_calls"], ensure_ascii=False)) if __name__ == "__main__": asyncio.run(run_audit_workflow()) 

6. Economia de Escala, Custo por Tarefa e Guia de Deploy On-Premises

Ao avaliar a adoção de um modelo para agentes corporativos, a métrica central é o custo por tarefa concluída, e não apenas o preço isolado por milhão de tokens.

6.1 Análise de Custo por Tarefa vs. Concorrentes

Nos gráficos de custo-eficiência publicados pela MiniMax:

• Automation-Bench abaixo de $0,05: Em todos os 5 níveis de esforço (low, medium, high, xhigh e max), o custo médio para completar uma tarefa inteira de automação SaaS permanece abaixo de $0,05, variando de 52,8 pontos de eficácia no nível low até 62,8 pontos no nível max.

• Agents' Last Exam por ~111: A execução completa das 152 tarefas profissionais do ALE custou cerca de 111 no total para atingir a marca de 29,6 pontos — uma fração do custo exigido por modelos proprietários que cobram 10 a 15 por milhão de tokens de saída.

• Impacto do Cache KV a $0,015/M: Em fluxos onde o agente mantém 100 mil tokens fixos na janela (documentação de APIs, esquemas de ferramentas MCP e histórico acumulado) ao longo de 40 chamadas consecutivas, a leitura de cache a $0,015 por milhão gera uma despesa total de apenas $0,06 para os 4 milhões de tokens lidos em cache.

A tabela abaixo resume o confronto técnico e financeiro entre os principais modelos da categoria:

6.2 Requisitos de Hardware para Auto-Hospedagem (Pesos em 23 de Outubro)

Para empresas que aguardam a liberação dos pesos em 23 de outubro de 2026 para execução local em clusters próprios:

• Tamanho do Checkpoint: Mantendo a estrutura de 428B parâmetros totais da linha M3, a build quantizada em precisão MXFP8 ocupa aproximadamente 440 GB.

• Topologia de GPUs Recomendada: Um único nó 8x NVIDIA H200 (141 GB de VRAM cada, totalizando 1.128 GB de memória HBM3e) ou 8x NVIDIA B200 acomoda confortavelmente os 440 GB dos pesos com paralelismo de tensores (--tensor-parallel-size 8) no vLLM ou SGLang, deixando mais de 600 GB livres para o KV Cache de sessões concorrentes de até 1 milhão de tokens. Em clusters 8x NVIDIA H100 (80 GB, 640 GB totais), o deploy exige quantização FP8/INT4 mais compacta ou particionamento de pipeline entre dois nós via InfiniBand/RoCEv2.

• Endpoints Compatíveis na Nuvem: Enquanto os pesos não são liberados, a API em platform.minimax.io aceita tanto clientes configurados para o SDK da OpenAI (Chat Completions e Responses) quanto clientes construídos para o SDK da Anthropic, permitindo testar o modelo em esteiras existentes apenas trocando a base_url e a chave de autenticação.

7. Anatomia de Execução no BankerToolBench e Conciliação Documental Multi-Etapas

Para compreender por que o MiniMax M3.1 alcança 76,2 pontos no BankerToolBench (empatando tecnicamente com o Claude Opus 5.5) e 62,2 pontos no Automation-Bench, vale examinar como o modelo gerencia estados intermediários em fluxos corporativos reais de longa duração. Em rotinas de tesouraria, controladoria e backoffice bancário, o agente raramente responde a uma pergunta isolada; ele precisa coordenar uma sequência estrita de validações determinísticas.

Considere um fluxo típico de fechamento cambial e auditoria de faturas internacionais avaliado pela suíte:

• Ingestão de Contratos e Extratos: O agente lê simultaneamente contratos comerciais em PDF, arquivos de remessa bancária SWIFT MT940, planilhas de centros de custo e tabelas de alíquotas fiscais vigentes, aproveitando a janela linear de 1 milhão de tokens sem truncar cláusulas de rodapé;

• Planejamento no Campo reasoning_content: Antes de invocar a primeira ferramenta, o modelo (operando em reasoning_effort="xhigh" ou "max") constrói um grafo de verificação passo a passo, listando quais chaves primárias (CNPJ/Tax ID, número da Purchase Order, código IBAN e data de liquidação) precisam bater entre os documentos;

• Execução Encadeada de Tool Calls: O modelo dispara chamadas sequenciais para APIs de consulta de câmbio PTAX, validação de retenções tributárias (IRRF, IOF, PIS/COFINS) e lançamento de provisões no sistema ERP, mantendo a consistência numérica ao longo de 30 a 50 turnos;

• Recuperação de Erros e Retentativas: Caso um endpoint externo retorne timeout ou erro de validação de esquema, o raciocínio sempre ativo permite ao modelo diagnosticar a mensagem de erro HTTP, reformular os parâmetros JSON e repetir a chamada sem perder o fio condutor da auditoria.

8. Guia Prático de Parametrização para vLLM, SGLang e Integração com Ferramentas CLI

Com a chegada dos pesos abertos prevista para 23 de outubro de 2026 e o suporte imediato em ferramentas de linha de comando como MiniMax Code, Claude Code e OpenCode (via provedores compatíveis e Ollama Cloud), equipes de infraestrutura de IA já podem preparar seus ambientes de orquestração.

8.1 Consumo Imediato em Ferramentas de Terminal e IDEs Agênticas

Para desenvolvedores que utilizam interfaces de codificação assistida no terminal ou IDEs integradas, o M3.1 pode ser conectado diretamente através dos endpoints compatíveis com Anthropic e OpenAI em platform.minimax.io ou via roteadores como OpenRouter e Ollama:

• No MiniMax Code...