MiniMax M3.1: O que dizem os documentos de prévia vazados — e o que ninguém confirmou

Há um checkpoint de 250 GB no Hugging Face chamado MiniMax-M3.1-preview-private que ninguém fora de um punhado de parceiros de inferência consegue abrir. Há um documento datado de 22 de setembro que se lê exatamente como a nota de arquitetura do fornecedor, circulando em um repositório público de engenharia de parceiros em vez de no site do próprio fornecedor. E em 26 de setembro, um observador de modelos amplamente seguido publicou que o MiniMax M3.1 é "o próximo modelo que chega na semana que vem" e que já estão testando uma prévia dele. Junte esses três e você tem todo o registro público do MiniMax M3.1 — um modelo cujo nome, mudanças de arquitetura, contagem de pesos e semana de chegada estão todos em circulação, e sobre nada disso o fornecedor disse uma palavra em público. O predecessor do qual ele descende, MiniMax M3, é outra história: esse foi lançado, e é a razão pela qual alguém se importa com este.

É assim que um modelo não lançado se parece visto de fora, e vale a pena ser preciso sobre a forma das evidências, porque as três vertentes não são igualmente fortes. A existência do checkpoint é corroborada: várias linhas independentes apontam para o mesmo nome de repositório privado e a mesma contagem de arquivos. O documento de arquitetura não é corroborado dessa forma — é a transcrição de um terceiro, e pode ser genuíno, desatualizado ou parcialmente inventado. A alegação da "próxima semana" é a expectativa de uma pessoa, não um cronograma. Tudo neste artigo está rotulado com a força que de fato tem, e nada aqui deve ser lido como um anúncio de lançamento.

O que torna o MiniMax M3.1 digno de um artigo antes de existir é o predecessor. O MiniMax M3 foi, segundo a maioria das avaliações, o modelo de pesos abertos mais forte que a MiniMax havia lançado — um modelo de 1 milhão de tokens, de texto, imagem e vídeo, que atingiu o Artificial Analysis Intelligence Index em 29,2 e ainda é um dos poucos modelos abertos capazes de manter coeso um contexto genuinamente longo. Se o M3.1 chegar na última semana de setembro, os números que importam para um desenvolvedor não são a plausibilidade do vazamento, mas o que mudou nas camadas e quanto custa servi-lo — e, em ambos os aspectos, o documento vazado é excepcionalmente específico.

O que está confirmado e o que está apenas em circulação

A divisão honesta, em 27 de setembro de 2026:

• Confirmado: não existe nenhuma versão pública do MiniMax M3.1. A organização MiniMaxAI no Hugging Face retorna 401 — a resposta da plataforma para "não encontrado ou não visível para você" — tanto para MiniMaxAI/MiniMax-M3.1 quanto para MiniMaxAI/MiniMax-M3.1-preview e MiniMaxAI/MiniMax-M3.1-preview-private. Seus uploads públicos mais recentes continuam sendo o MiniMax-Music3 (7 de agosto de 2026) e o MiniMax-H3 (28 de julho de 2026).

• Confirmado: o MiniMax M3.1 não é roteável em nenhum lugar que conseguimos verificar. Ele está ausente do catálogo de modelos do OrcaRouter e das listagens públicas que monitoramos; o modelo MiniMax que você pode realmente chamar hoje é o MiniMax M3, em minimax/minimax-m3.

• Confirmado: a MiniMax não publicou nada. Nenhuma ficha de modelo, nenhuma postagem em blog, nenhuma página de preços, nenhum peso, nenhum ID de modelo de API. Não há cobertura da imprensa sobre um lançamento porque não houve lançamento.

• Em circulação: o documento de arquitetura. Ele é reproduzido literalmente em um repositório público — longsco/innoferra-eval, uma suíte de integração de parceiros para endpoints de modelos hospedados, criado em 23 de setembro de 2026 — sob o nome de arquivo PREVIEW-20260922.md, com um cabeçalho que o descreve como um documento de fornecedor partilhado em 25 de setembro e uma ressalva de que "o nome do modelo, a data de lançamento do provedor e o lançamento público permanecem sujeitos ao lançamento efetivo". Essa é a ressalva do próprio documento, não nossa, e é a correta: a cópia de terceiros de uma nota de fornecedor não é uma declaração da MiniMax.

• Em circulação: o checkpoint de 250 GB e seu segundo drop. A especificação de onboarding do repositório registra um checkpoint multimodal privado em MiniMaxAI/MiniMax-M3.1-preview-private — 62 arquivos, 48 arquivos safetensors, cerca de 250 GB, string de arquitetura MiniMaxM3SparseForConditionalGeneration — e depois um segundo drop maior, MiniMax-M3.1-preview2-dspark-private, com 101 arquivos e cerca de 236 GB, que adicionou um rascunho especulativo fp8 de 2,3 GB. Ambos são privados. Não podemos abrir nenhum dos dois, e você também não.

• Em circulação: a cronologia. A publicação de 26 de setembro é a única datação pública que alguém apresentou, e "próxima semana" é uma expectativa. Trate a semana de 28 de setembro como a janela a observar, não como uma data.

O único documento que traz o detalhamento de engenharia

Tudo o que se sabe de específico sobre o design do MiniMax M3.1 remonta àquele único arquivo markdown, além de dois arquivos complementares no mesmo repositório: um documento de demonstração do SGLang que descreve como o checkpoint deve ser servido, e um spec.yaml que se espera que um endpoint parceiro satisfaça. Leia o repositório como um todo e ele se parece com um provedor de inferência fazendo exatamente o que um provedor de inferência faz — recebendo uma versão antecipada da MiniMax, anotando o que mudou e construindo uma suíte de validação para ela. O repositório não é um kit de imprensa e não foi escrito para persuadir ninguém.

Isso é um ponto a seu favor, e é também o limite daquilo que prova. Nada nele é assinado pela MiniMax. Os três documentos concordam entre si da maneira como documentos reais concordam — as mesmas constantes de quantização, os mesmos nomes de variáveis de ambiente, as mesmas flags de inicialização — e discordam da maneira como lançamentos reais discordam: a prévia de 22 de setembro diz que o novo método de decodificação especulativa não tem cabeça de confiança, e o segundo lançamento de checkpoint trouxe uma configuração preliminar com enable_confidence_head definido como true. Uma fabricação normalmente não incluiria um arco de correção. Mas «incomumente coerente» não é «confirmado», e o modo de falha para um leitor é absorver as constantes abaixo como o projeto publicado da MiniMax, quando elas são, no máximo, o projeto privado da MiniMax tal como lido por outra pessoa.

As cinco alterações de engenharia, de acordo com esse documento.

Eis o delta entre o MiniMax M3 e o MiniMax M3.1 conforme descrito no documento. Cada linha é de origem do fornecedor e não auditada — nenhuma parte independente mediu qualquer resultado do MiniMax M3.1 de qualquer tipo.

• Cobertura de atenção. A atenção completa nas três primeiras camadas é substituída por atenção esparsa, então todas as camadas são esparsas. No MiniMax M3, as três primeiras camadas eram a âncora de atenção completa da pilha esparsa.

• Precisão da atenção — "Q8KV4". As queries, incluindo as queries do indexador, saem da projeção em BF16 e são convertidas para FP8 E4M3. As chaves e os valores — novamente incluindo os do indexador — são quantizados para E2M1, quatro bits, em blocos de 16, com uma escala E4M3 por bloco de amax/6 limitada a [1/512, 448]. O documento é enfático ao afirmar que a escada usa arredondamento round-half-to-even com limiares assimétricos, que a escala externa do tensor é exatamente 1 e que uma magnitude zero tem de codificar como zero positivo. O M3 usou um caminho KV de oito bits da mesma família, pelo que isto reduz novamente para metade os bytes de KV.

• Precisão especializada. Os especialistas roteados do MoE passam de MXFP8 para W4A4 NVFP4, com o especialista compartilhado deliberadamente excluído. As duas projeções de especialistas recebem esquemas de ativação diferentes: FC1 usa uma escala dinâmica por linha de 2688 dividida pelo máximo absoluto da linha, com a escala de linha aplicada após o GEMM, mas antes da função de ativação; FC2 usa uma escala externa fixa de 16. A consequência prática, explicitada no README do parceiro, é direta: "um provedor que executa o checkpoint por um caminho NVFP4 genérico sem esses ajustes produzirá resultados numéricos silenciosamente diferentes."

• Decodificação especulativa. O cabeçote de predição multi-token no estilo EAGLE foi removido, substituído por um método que a MiniMax chama de DSpark — um cabeçote Markov vanilla e, no documento de 22 de setembro, nenhum cabeçote de confiança. Esta é a mudança com o maior efeito sobre a sensação de um endpoint servido, porque é a única alavanca de velocidade por fluxo no design. O motor de demonstração que a MiniMax enviou junto com o checkpoint não inclui o DSpark, e o provedor mediu a diferença: no mesmo quadro de 80.000 tokens sem especulação, a vazão por fluxo é de 63,9 tokens por segundo com concorrência 1 e cai para menos de 60 com concorrência 4, portanto a própria conclusão do documento é que, sem o DSpark, a pilha não consegue manter sua meta de latência sob carga.

• Um novo campo de requisição. O MiniMax M3.1 adiciona um campo reasoning_effort de nível superior que aceita max, xhigh, high, medium ou low, injetado no prompt de sistema como uma etiqueta de esforço pelo template de chat. O M3 tinha apenas um interruptor de thinking com adaptive e disabled. O documento observa, de forma estranha e específica, que o campo é transportado sem validação e sem valor padrão obrigatório — o que o provedor interpretou como permissão para aceitar ou rejeitar um valor não listado, e o que significa que dois endpoints compatíveis poderiam se comportar de maneira diferente na mesma requisição.

Dois detalhes no checkpoint merecem ser destacados separadamente, porque são o tipo de coisa que um post de lançamento omite. Primeiro, o checkpoint traz tanto uma configuração de pré-processador de imagem quanto uma configuração de pré-processador de vídeo — o MiniMax M3.1 é um modelo multimodal por construção, não um modelo de texto com visão adicionada depois, e a orientação do próprio provedor é não rejeitar entradas de imagem na nova stack. Segundo, a segunda entrega do checkpoint removeu completamente as chaves MTP e NEXTN e não adicionou nada que as substitua, e é por isso que o draft do DSpark teve de chegar como um artefato separado de 2,3 GB. Não há nenhuma cabeça de draft nos pesos principais para ativar.

Por que não há números de benchmark do M3.1, e por que isso não é uma omissão

Todo texto sobre vazamento eventualmente chega à parte em que ou inventa uma tabela de benchmarks ou admite que não tem nenhuma. O MiniMax M3.1 não tem nenhuma. A especificação do parceiro diz isso explicitamente, em um campo que existe puramente para impedir que alguém cometa o erro:

• "Ainda não há baselines 3.1 publicados; não reutilize os números do M3 como critérios de aceitação."

Essa instrução é a frase mais útil de todo o corpus, porque a versão preguiçosa deste artigo escreve as pontuações do Artificial Analysis do MiniMax M3 sob um título de MiniMax M3.1. Não deveria. O mesmo repositório executa sondagens AIME-25 e GPQA-Diamond contra o endpoint M3.1 da própria MiniMax e registra-as como comparações entre a equipe e o fornecedor, com as pontuações ainda não definidas: no GPQA-Diamond, 0,904 para a execução da equipe contra 0,813 para a do fornecedor, e em um subconjunto de 600 perguntas do MMLU-Pro, 0,898 contra 0,821. Essas são duas execuções da mesma avaliação em discordância, não um resultado de modelo, e estão rotuladas como uma prévia com repetições contabilizadas. Qualquer pessoa que cite hoje um único número de benchmark do MiniMax M3.1 está citando algo que ainda não existe.

O que é o MiniMax M3, para que a sequência possa ser dimensionada

O MiniMax M3 foi lançado no final de maio de 2026 e foi disponibilizado no Hugging Face em 2 de junho — 428 bilhões de parâmetros totais com 23 bilhões ativos, 60 camadas, 128 especialistas roteados com roteamento top-4, 4 cabeças KV contra 64 cabeças de atenção, e uma janela de contexto de 1.048.576 tokens com saída máxima de 512.000. Do lado independente, a Artificial Analysis atribui a ele 29,2 no Índice de Inteligência, colocando-o em 60º entre 145 modelos amostrados, com 58,6 no índice de codificação e um p50 de 3.348 milissegundos até o primeiro token em nossa própria telemetria de roteamento. O número de destaque da própria MiniMax para ele é 83,5 no BrowseComp, que é um número do fornecedor e não auditado como tal.

A precificação é a parte que envelhece melhor em um ciclo de vazamento. O MiniMax M3 custa US$ 0,30 por milhão de tokens de entrada e US$ 1,20 por milhão de tokens de saída, com leituras em cache a US$ 0,06 — e já está disponível no OrcaRouter como minimax/minimax-m3, pelo preço de tabela do provedor, com 0% de markup, então, se a MiniMax precificar o M3.1 da mesma forma, a nova tarifa estará ativa do nosso lado no dia em que existir, em vez de um ciclo de cobrança depois.

O objetivo de repetir tudo isso não é nostalgia. É que a razão pela qual alguém está atualizando uma página de organização no Hugging Face esta semana é que o MiniMax M3 foi bom o suficiente para que seu sucessor seja uma questão de produção, e não um esporte de espectador — e que um modelo de 428 bilhões de parâmetros com contexto de 1M a $0,30/$1,20 define um patamar de custo-benefício que o M3.1 precisa superar, não apenas um patamar de capacidade.

A questão da listagem anônima, e por que ela já pode ter sido respondida

Uma thread do início de setembro vale a pena encerrar aqui. Uma listagem stealth anônima apareceu em uma plataforma de codificação de terceiros com contexto de 1.000.000 de tokens, preço de US$ 0 e níveis de raciocínio obrigatórios, e nós a cobrimos sob o nome Space Bunny Alpha, observando a taxa-base de que toda listagem anônima desse tipo acaba sendo reivindicada por um fornecedor — Pony Alpha se tornou um modelo da Zhipu, Hunter Alpha se tornou da Xiaomi, Ox Alpha se tornou um lançamento da MiniMax com um nome diferente. O tokenizador e as impressões digitais de anomalias naquela listagem apontavam para um checkpoint de prévia da MiniMax. Se o MiniMax M3.1 realmente chegar esta semana, a leitura mais provável é que a listagem anônima foi seu teste de campo, e o mistério se resolve por anúncio, e não por mais trabalho forense. Isso é inferência, não evidência, e é a última inferência deste artigo.

O que ficar de olho, e o que fazer esta semana

Os sinais que transformariam isto de um vazamento em um lançamento são específicos e verificáveis, e não são os que a maioria dos comentários acompanha. Um repositório público no Hugging Face sob a organização MiniMaxAI — não um privado — com um model card é o indicador isolado mais forte; o histórico de uploads da organização é público e registra a data de cada lançamento com precisão de dia. Uma página de modelo da MiniMax ou um ID de modelo de API é o segundo. Um preço publicado é o terceiro, e o que importa para um orçamento. Uma tabela de benchmark no Artificial Analysis datada após o lançamento é o quarto, e o único independente.

Até lá, a posição prática para qualquer pessoa que esteja construindo permanece a mesma de qualquer outra semana de pré-lançamento: o modelo que você pode rotear hoje é o MiniMax M3, uma única chave de API o alcança junto com mais de 200 outros modelos, o failover automático significa que um tropeço em um endpoint não se transforma na sua indisponibilidade, e uma rota fixada ou combinada através do DSL de roteamento ou um painel de modelos respondendo em conjunto por meio de fusão de modelos é como você reduz o risco de um modelo que você ainda não colocou em produção. Se o M3.1 chegar, trata-se de uma troca de um ID de modelo, não de uma migração — o que é o argumento inteiro para não construir uma integração sob medida contra um vazamento.

Uma coisa que este artigo não vai fazer é fingir saber quando. O ponto de verificação é real, os documentos são específicos, e a alegação pública mais recente é uma pessoa dizendo "semana que vem". Dos três, apenas os dois primeiros são coisas que você mesmo pode verificar.