MiMo-V2.6-Pro: Xiaomi lidera open weights com US$3 mi

MiMo-V2.6-Pro chegou chutando a porta

MiMo-V2.6-Pro é o tipo de lançamento que obriga todo mundo a refazer a planilha. A Xiaomi, que até ontem era vista como fabricante de celular tentando brincar de IA, colocou no ar um modelo omnimodal aberto de 1T de parâmetros com 42B ativos que assume o topo dos open weights e diz ter custado apenas US$ 3 milhões em treino. Se esse número estiver certo, e mesmo com margem de erro ele já incomoda, a conversa sobre custo por inteligência muda de patamar. Não é só mais um checkpoint no Hugging Face, é uma provocação direta ao Vale do Silício.

Para quem opera modelo em produção, a tensão é imediata. A gente passou dois anos aceitando que fronteira custa centenas de milhões e que open weights vem sempre uma geração atrás. Agora aparece um MoE gigante, nativamente omnimodal, com promessa de velocidade extrema e tooling de RL aberto. Vale a pena trocar parte da stack fechada por isso? Isso escala fora do lab da Xiaomi? Ou é só mais um modelo forte em benchmark e frágil em uso real?

O fato: o que a Xiaomi realmente lançou

A linha MiMo-V2.6 tem dois modelos principais. O MiMo-V2.6-Pro é o mais capaz até hoje da empresa, com 1T de parâmetros totais e 42B ativos por token, e entendimento nativo de texto, imagem, áudio e vídeo. O MiMo-V2.6-Flash é a versão de equilíbrio entre inteligência, eficiência e custo, pensada para quem precisa de latência baixa sem pagar inferência de modelo gigante denso. Os dois são descritos como nativamente omnimodais, não um Frankenstein de encoders colados depois.

Tem ainda um terceiro sabor, o MiMo-V2.6-Pro-UltraSpeed, que promete até 20x mais velocidade de geração com a mesma qualidade. Na prática, isso provavelmente envolve destilação especulativa, decodificação paralela ou alguma técnica de aceleração de amostragem, porque 20x sem perda em modelo MoE desse tamanho não vem só de kernel otimizado. Junto com os pesos, a Xiaomi promete abrir boa parte do tooling: receitas de código, loaders, recompensas, ambientes de cyber com o ARVO, ambiente geral com ferramentas, ambiente de web dev com grading, scorer de música e adaptadores de agentes. O ponto sensível é que o dataset completo com mais de 7 mil tarefas ainda não foi liberado.

Como funciona: RL em três eixos e MoE gigante

Na arquitetura, estamos falando de um MoE esparso clássico na filosofia, mas levado ao extremo. 1T total com 42B ativos significa que, por token, você paga algo próximo de um modelo de 40B denso, mas com capacidade de memória muito maior espalhada nos especialistas. Para quem opera, isso é bom e ruim ao mesmo tempo. Bom porque o custo por token pode ser competitivo se você tiver VRAM suficiente para servir todos os especialistas. Ruim porque servir 1T, mesmo quantizado, exige cluster com muita memória HBM, paralelismo de especialistas bem ajustado e atenção total a latência entre GPUs.

O diferencial mesmo está no pós-treino. A Xiaomi detalhou que escalou o compute de RL em três eixos. O primeiro é batch e throughput: 1.568 amostras por update, em arquitetura totalmente assíncrona, treinando com contexto de até 1M e algo entre 3,5 e 3,7B de tokens por step. Isso é brutal. Para comparar, a maioria dos labs abertos trabalha com ordens de magnitude menores por step em RL. Manter estabilidade com batch desse tamanho e contexto longo exige infraestrutura de rollout muito bem feita, senão você queima dinheiro com trajetórias inválidas.

O segundo eixo é mais tarefas e ambientes mais ricos. Em vez de RL só para matemática e código, eles misturaram coding, agentes gerais, tarefas visuais e cyber em vários harnesses. A ideia é que ganho em uma capacidade reforce a outra. Faz sentido para quem já quebrou a cabeça com overfitting de RL em um domínio só. Modelo que só aprende a passar em teste de código vira papagaio de LeetCode. Quando você mistura agente web, reprodução de vulnerabilidade e trabalho de conhecimento geral, o gradiente fica mais diverso e o modelo aprende a usar ferramentas de verdade.

Onde entra o grader e por que isso importa no custo

O terceiro eixo é mais compute no grader. Eles usam comparação relativa dentro de cada grupo para dar sinal de recompensa mais preciso em tarefas de horizonte longo, fechando um loop de auto-melhoria que empurra o modelo para caminhos mais curtos e menos tokens por tarefa. Traduzindo para operador: não é só acertar, é acertar gastando menos. Isso tem impacto direto em custo de inferência. Se o modelo aprende a resolver com 2 mil tokens em vez de 8 mil, sua conta no fim do mês cai junto, mesmo com preço por token igual.

Sobre os US$ 3 milhões, dá para fazer uma inferência plausível sem tomar como verdade absoluta. Esse valor provavelmente conta só a fase final de RL, não o pré-treino completo do zero, nem salários, nem experimentos falhados. Ainda assim, é um número agressivo. Sugere uso pesado de infraestrutura própria, chips com custo amortizado e pipeline assíncrono que mantém GPU ocupada quase o tempo todo. Se você tentar reproduzir isso em nuvem alugada no preço cheio americano, vai gastar bem mais. O recado é menos sobre o número exato e mais sobre eficiência de engenharia.

O que isso muda na prática

Quem ganha primeiro é quem já opera com open weights. Startups que hoje pagam API fechada para coding, agentes e RAG pesado podem testar trocar parte do tráfego para MiMo-V2.6-Flash como modelo barato e deixar o Pro para tarefa difícil. Laboratórios chineses ganham ainda mais tração, porque a sequência de lançamentos em dez semanas, com Kimi, Qwen, DeepSeek, GLM e agora MiMo, mostra um ritmo que o ocidente aberto não está acompanhando. Quem perde é quem vende simplicidade de API fechada como único caminho, porque a diferença de 10x a 50x no custo fica difícil de justificar para caso de uso comum.

Quem opera precisa ajustar agora. Não dá para ignorar um MoE aberto omnimodal no topo do ranking, mas também não dá para colocar em produção cega. A ação prática mais sensata é montar um harness próprio de avaliação com suas tarefas reais. Separe 50 a 100 exemplos do seu dia a dia, com uso de ferramentas, código, navegação e multimodalidade se você usa imagem ou áudio. Rode MiMo-V2.6-Pro, Flash e seu modelo fechado atual lado a lado, medindo taxa de sucesso, tokens por tarefa, latência p95 e custo total. Se o Flash entregar 90 por cento da qualidade com 30 por cento do custo, você já achou onde cortar.

• Teste Flash para triagem e Pro para exceção, com roteamento por confiança e fallback automático para modelo fechado quando falhar.
• Meça tokens por tarefa resolvida, não só preço por milhão, porque modelo verboso come toda a economia do open weights.
• Valide os ambientes abertos da Xiaomi, de código, web dev e cyber, antes de confiar no UltraSpeed de 20x em workload com ferramenta externa.

Será que escala ou só move o gargalo?

Aqui está a tensão real. Treinar barato é ótimo, servir 1T não é. Para rodar o Pro com contexto longo e velocidade decente, você vai precisar de nós com muita VRAM, provavelmente quantização FP8 ou INT8, paralelismo de especialistas e cache KV bem gerenciado. Para muita empresa brasileira sem cluster próprio, isso significa depender de provider que hospede o modelo. E aí parte da economia evapora em markup de hospedagem, latência maior e fila. Resolve o custo de treino, mas move o gargalo para inferência e operação.

Tem outro ponto que me incomoda. Abrir ambiente e receita sem abrir as 7 mil tarefas é meio caminho. Ajuda a comunidade a entender o como, mas não entrega o quê que fez o modelo ficar bom. Sem o dado, reproduzir o resultado fica muito mais caro do que parece. E omnimodalidade nativa é linda no paper, mas na produção ela cobra preço em avaliação, segurança e observabilidade. Como você audita um modelo que lê imagem, ouve áudio e executa ferramenta ao mesmo tempo? O custo de engenharia para domar isso não aparece nos US$ 3 milhões.

Conclusão

MiMo-V2.6-Pro é o sinal mais forte até agora de que a fronteira open weights não está mais uma geração atrás, ela está brigando de frente e custando menos. A pergunta que fica para quem constrói é simples: quanto da sua conta de API fechada sobrevive se um MoE aberto fizer o mesmo trabalho por uma fração do preço?