MiMo da Xiaomi: anatomia de um pipeline de raciocínio, de 7B a 1T

Uma leitura técnica de pré-treino, roteamento MoE, destilação e memória de agentes.

Há um motivo para olhar de perto o Xiaomi MiMo além dos números de parâmetros: a equipe disponibiliza modelos recentes e publica o trabalho técnico que os acompanha. Para a Kuaapy, essa abertura tem valor próprio. Poder estudar um modelo, adaptar sua execução e confrontar resultados amplia quem consegue participar do desenvolvimento da IA.

A geração V2.6 faz parte dessa escolha. O anúncio oficial apresenta a abertura da série, do relatório técnico, dos ambientes de treinamento e do código de RL; os cartões públicos permitem acessar os checkpoints. Essa combinação cria oportunidades de investigação para além do serviço hospedado da empresa. Lançamento do V2.6 [1], modelos oficiais [2].

Um agente pode acertar a resposta e desperdiçar dezenas de chamadas até chegar nela. Pode gerar código correto e perder a restrição que deveria orientar a próxima alteração. Pode ter um contexto enorme e continuar administrando mal o estado da tarefa.

Para analisar um sistema desses, precisamos acompanhar três camadas: os pesos que definem a política do modelo, a infraestrutura que treina e executa essa política e o runtime que organiza ferramentas e continuidade. A trajetória pública do MiMo permite examinar as três.

Esta análise usa fontes primárias consultadas em 23 de outubro de 2026. Métricas atribuídas à Xiaomi são resultados publicados pelos autores; não representam reprodução independente pela Kuaapy.

1. O raciocínio começa antes do RL

O relatório do MiMo-7B descreve otimização conjunta do pré-treino e do pós-treino. A base recebeu aproximadamente 25 trilhões de tokens, mistura de dados em três estágios e um objetivo auxiliar de Multi-Token Prediction, ou MTP. A preparação dos dados inclui conteúdo matemático, código e raciocínio sintético.

No pós-treino, os autores usam SFT e reinforcement learning com cerca de 130 mil problemas verificáveis de matemática e programação. A recompensa de código considera a dificuldade dos testes; a reamostragem procura estabilizar o treinamento. Isso é mais específico do que afirmar que o modelo recebeu uma recompensa genérica por cada passo de raciocínio.

A conclusão adequada é que dados, objetivos de pré-treino e pós-treino contribuem em etapas diferentes. O paper não sustenta que raciocínio seja exclusivamente produto do RL. Tampouco um resultado final correto, isoladamente, permite distinguir generalização de memorização. Essa distinção exige desenho de avaliação próprio. Relatório MiMo-7B [3].

2. Escala total e computação ativa são números diferentes

O MiMo-V2-Flash combina 309 bilhões de parâmetros totais com 15 bilhões ativos por token. Seu relatório descreve atenção local com janela de 128 tokens intercalada com atenção global, em razão híbrida 5:1. O contexto de pré-treino de 32K foi estendido para 256K. Relatório V2-Flash [4].

Nos cartões oficiais da geração V2.6, a separação fica assim:

V2.6-Pro-RL — Parâmetros totais: 1,02 trilhão; Ativos por token: 42 bilhões; Experts roteados / ativados: 384 / 8; Contexto declarado: 1 milhão

V2.6-Flash-RL — Parâmetros totais: 309 bilhões; Ativos por token: 15 bilhões; Experts roteados / ativados: 256 / 8; Contexto declarado: 1 milhão

Ambos recebem texto, imagem, vídeo e áudio. São modelos distintos, não apenas duas configurações de velocidade do mesmo checkpoint. Pro [5], Flash [6].

MoE reduz o conjunto de experts usado em cada token. Isso não faz o modelo inteiro caber na memória correspondente aos parâmetros ativos. Como cálculo ilustrativo, um trilhão de parâmetros a um byte por parâmetro já representa aproximadamente um terabyte, antes de escalas de quantização, caches e buffers. Distribuição, offload e transferência dos pesos continuam sendo questões de arquitetura.

Da mesma forma, contexto máximo declarado não informa sozinho latência, custo ou qualidade de recuperação de uma informação distante.

3. Quando o rollout e o treino escolhem experts diferentes

Durante RL, um motor gera trajetórias; outro calcula atualizações. Em um MoE, decisões diferentes de roteamento podem fazer essas etapas ativarem experts diferentes para a mesma sequência. O problema aparece na relação entre a política que produziu a amostra e a política usada para atualizá-la.

O Rollout Routing Replay, ou R3, registra as seleções de experts durante o rollout e as reaplica no treinamento. A implementação mantém o cálculo das probabilidades do roteador no treino, preservando o caminho de gradiente. O objetivo é reduzir divergências entre os motores sem simplesmente descartar amostras difíceis.

Os experimentos do paper incluem Qwen3-30B-A3B; seus números não devem ser apresentados como medições do MiMo. O resultado relevante para a discussão é o mecanismo: o comportamento do roteador e a consistência entre stacks participam da estabilidade do RL. Paper de R3 [7].

4. MOPD integra especialistas nas trajetórias do estudante

Treinar um professor de matemática e outro de engenharia de software não resolve automaticamente como reunir suas habilidades. No MOPD, professores especializados são desenvolvidos por domínio. O estudante produz seus próprios rollouts e recebe supervisão do professor correspondente, com sinal denso por token.

Uma das formulações usa divergência KL reversa entre as distribuições do estudante e do professor nos contextos visitados pelo estudante. O objeto aprendido é uma política conjunta; o procedimento não consiste em concatenar respostas ou fazer uma média simples dos pesos dos professores.

O estudo compara a técnica com alternativas no Qwen3-30B-A3B e relata aplicação industrial no V2-Flash. Integração não significa ausência de perdas: na tabela do MiMo, alguns resultados ficam abaixo do professor especialista. Avaliar retenção por domínio é mais informativo do que anunciar um estudante superior em tudo. Paper MOPD [8].

5. Inferência: MTP e cache resolvem gargalos diferentes

No V2-Flash, os módulos MTP são reaproveitados como rascunhador para speculative decoding: propõem tokens cuja aceitação é verificada pelo modelo principal. O relatório publica aceleração de decoding de até 2,6 vezes na configuração avaliada. Esse número não é promessa para qualquer batch, hardware ou comprimento de entrada. Relatório V2-Flash [4].

Já o HySparse investiga atenção e armazenamento de KV. Uma camada de atenção completa fornece seleção de tokens e cache às camadas esparsas seguintes. Assim, a proposta procura reduzir computação e memória, em vez de economizar apenas operações enquanto mantém caches independentes.

O paper avalia modelos de 7B denso e 80B MoE; no segundo, relata redução de KV próxima de dez vezes. São experimentos daquela arquitetura. HySparse não deve ser tratado como sinônimo da atenção híbrida SWA/global do V2-Flash, nem como economia de memória demonstrada para todos os MiMo. Paper HySparse [9].

O que há por trás dos mil tokens por segundo

O anúncio UltraSpeed do V2.5-Pro combina quantização FP4 dos experts com treinamento consciente de quantização, um rascunhador DFlash e kernels adaptados pelo TileRT. Os demais módulos preservam a precisão original. A Xiaomi relata mais de mil tokens por segundo de decoding em um nó com oito GPUs.

Há três cuidados de leitura. Primeiro, decoding não descreve sozinho prefill, espera em fila ou latência total. Segundo, um nó com oito GPUs não equivale a uma máquina pessoal. Terceiro, a aceitação dos tokens propostos varia por tarefa; o próprio artigo reconhece dificuldades em conversação mais divergente.

O período de acesso anunciado era de 9 a 23 de junho de 2026. Esse anúncio histórico não comprova disponibilidade comercial atual. O interesse técnico está na combinação entre representação dos pesos, proposta especulativa e execução dos kernels. Anúncio técnico UltraSpeed [10].

6. RL agêntico também depende de quem espera por recursos

Um rollout pode depender de execução de código em CPU, avaliação em GPU e serviços externos. Reservar tudo para a trajetória inteira mantém recursos ocupados mesmo quando aquela etapa não os utiliza.

O ARL-Tangram propõe orquestração no nível da ação, com compartilhamento e elasticidade dos recursos externos. A métrica central inclui o tempo para completar ações, não apenas utilização da GPU de treinamento. Os autores relatam até 4,3 vezes de melhora nessa medida e até 1,5 vez de aceleração dos passos de treino, em seus cenários.

O ganho de uma ação não se converte automaticamente no mesmo ganho do treinamento completo. Esse descompasso é precisamente uma razão para medir o pipeline inteiro. Paper ARL-Tangram [11].

7. Repetição de ferramentas: medir o caminho até a resposta

A Xiaomi documentou repetição no V2.6. Para uma medida reproduzível, contou chamadas idênticas, com argumentos JSON canonicalizados, dentro de um turno antes do feedback das ferramentas. A taxa é (N − U) / N: chamadas totais menos únicas, dividido pelo total.

Essa medida não captura loops entre turnos, quase duplicatas ou subchamadas escondidas em scripts. Também não confunde repetição com retries justificados.

Apertar uma penalidade de volume foi uma tentativa com generalização limitada. A correção final treinou um professor RL especializado e incorporou o comportamento por MOPD. Acertar a tarefa e evitar ações redundantes precisavam entrar no processo de treinamento.

A empresa relata redução da repetição; isso não significa ausência universal de loops. Os checkpoints corrigidos usam o sufixo MOPD, distinção importante ao reproduzir uma avaliação. Diagnóstico e correção [12], Pro-MOPD [13], Flash-MOPD [14].

8. Memória de agente é arquitetura de estado

No MiMo Code, a continuidade envolve um writer separado, checkpoints estruturados e reconstrução do contexto. Memórias de sessão, projeto e usuário têm ciclos de vida distintos; o histórico permite voltar aos registros originais. O desenho também inclui seleção de candidatos, verificação de conclusão e workflows executados em código.

Isso permite encadear janelas físicas limitadas em uma sessão lógica mais longa. Não transforma a janela do modelo em memória infinita. A consolidação de registros e a criação de skills alteram o contexto e os procedimentos disponíveis ao agente; não equivalem, por si, a atualizar os pesos.

Esse é o ponto técnico mais útil para quem constrói agentes: continuidade exige decidir o que persistir, quem pode escrever e como recuperar o estado. Um resumo pode ajudar, mas precisa fazer parte de um contrato operacional. Arquitetura do MiMo Code [15].

9. Uma família aberta que vai além do modelo principal

O conjunto de papers e projetos mostra frentes complementares:

MiMo-VL — O que acrescenta à família: Integra visão e linguagem; disponibiliza checkpoints SFT e RL do modelo de7B.; Material oficial: Repositório MiMo-VL [16]

MiMo-Audio — O que acrescenta à família: Investiga compreensão e geração de áudio, incluindo aprendizagem com poucos exemplos.; Material oficial: Repositório MiMo-Audio [17]

MiMo-V2.5-ASR — O que acrescenta à família: Reconhecimento de fala com foco documentado em mandarim, inglês, dialetos chineses e condições acústicas difíceis.; Material oficial: Repositório MiMo-V2.5-ASR [18]

MiMo-V2.6 — O que acrescenta à família: Modelos Pro e Flash omnimodais, com pesos e documentação públicos.; Material oficial: Anúncio e materiais [1]

Esse percurso pode ser acompanhado nas seções de papers [19] e blog técnico [20]. A contribuição está tanto nos modelos quanto na possibilidade de examinar escolhas e problemas de engenharia. Disponibilizar uma correção e explicar a falha que a motivou também produz conhecimento útil para quem está construindo outros sistemas.

O exemplo do Distill-Qwen-9B

O MiMo-V2.6-Distill-Qwen-9B torna essa circulação de conhecimento especialmente concreta. Segundo o cartão oficial, ele foi desenvolvido por SFT do Qwen3.5-9B com dados gerados pelo MiMo, como ponto de partida aberto para pesquisa em RL agêntico. O cartão declara licença MIT.

É um checkpoint de9B com uma origem técnica explicitada. Isso permite investigar a transferência de capacidades para outra escala sem confundi-lo com uma versão reduzida automaticamente do MoE de1,02T. Também não estabelece que os demais modelos MiMo tenham a mesma base Qwen. Modelo e descrição do treinamento [21].

10. Voz: uma frente que queremos ouvir em português

A família MiMo-V2.5-TTS inclui síntese com vozes prontas, criação de voz por descrição e clonagem a partir de amostras. O controle expressivo por instruções e marcações de áudio permite trabalhar ritmo, emoção e entonação. É uma frente interessante para agentes cuja interação precisa ir além do texto. Apresentação do TTS [22].

Aqui fica uma vontade nossa: poder experimentar essa proposta em português brasileiro. Na documentação consultada, as vozes prontas estão identificadas em chinês e inglês; não encontramos suporte oficial documentado ao português. Fica a expectativa de ver nosso idioma contemplado, especialmente pelo que uma voz expressiva pode acrescentar à acessibilidade. Ainda não fizemos uma avaliação própria da qualidade sonora. Documentação de síntese e vozes [23].

O TTS é apresentado nesses materiais como serviço de API. Sua disponibilidade não deve ser confundida com a liberação de pesos dos outros modelos: a abertura precisa ser identificada em cada componente.

O que precisamos medir em um sistema real

Nossa leitura é que uma avaliação de agentes deve reunir resultado, trajetória e continuidade. Além dos testes da tarefa, vale registrar chamadas redundantes, consumo de contexto, tempo sem avanço, custo por tarefa concluída e fidelidade às restrições depois de uma reconstrução de contexto.

Para reproduzir uma comparação, o registro precisa identificar checkpoint e revisão, tokenizer e template, precisão, motor de inferência, hardware, parâmetros de geração, harness e conjunto de tarefas. Deve separar avaliação de uma execução isolada de tarefas com várias interações, incluindo falhas e dispersão dos resultados.

Os cartões V2.6 consultados declaram MIT. Isso não autoriza atribuir uma licença única a todo o ecossistema: o repositório GitHub do V2-Flash, por exemplo, apresenta Apache-2.0. É necessário identificar o artefato citado. Cartão Pro-MOPD [13], repositório V2-Flash [24].

Na Kuaapy, essa investigação se conecta à experiência de quem depende do agente para concluir uma tarefa: quantas decisões precisam ser repetidas, quantas correções são necessárias e quanto esforço humano sobra depois da suposta automação. São perguntas de engenharia e de acessibilidade que podem orientar experimentos, sem antecipar seus resultados.

A abertura dos modelos é, por isso, uma parte central do valor que reconhecemos no Xiaomi MiMo. Ter pesos disponíveis, documentação e referências amplia o espaço para examinar e desenvolver tecnologia, inclusive fora de grandes laboratórios. Essa é também uma direção que consideramos para os modelos que viermos a desenvolver na Kuaapy. Os formatos e as condições de uma eventual disponibilização ainda serão definidos.

Conheça o Xiaomi MiMo nas fontes oficiais

Para acompanhar o trabalho da equipe, consultar os modelos e explorar os materiais originais:

• Site oficial do Xiaomi MiMo [25] — novidades, pesquisas e produtos.

• Xiaomi MiMo no Hugging Face [2] — modelos, cartões técnicos e coleções publicados pela equipe.

• Xiaomi MiMo no GitHub [26] — repositórios oficiais dos projetos.

• MiMo Code [27] — página oficial do agente de programação.

• Papers da equipe [19] e blog técnico [20] — índices para acompanhar a pesquisa.

• Família MiMo-V2.5-TTS [22] e documentação de síntese de voz [23].

Papers e documentação técnica deste artigo

• MiMo-7B: do pré-treino ao pós-treino [28].

• MiMo-V2-Flash — relatório técnico [4].

• Rollout Routing Replay — alinhamento dos roteadores [29].

• MOPD — destilação on-policy com múltiplos professores [30].

• HySparse — atenção esparsa e compartilhamento de KV [9].

• ARL-Tangram — infraestrutura para RL agêntico [11].

• MiMo Code — arquitetura para tarefas longas [15].

• Diagnóstico e correção de chamadas repetidas [12].

• UltraSpeed — codesign com TileRT [10].

Modelos citados e checkpoints corrigidos

• MiMo-V2.6-Pro-RL [5].

• MiMo-V2.6-Flash-RL [6].

• MiMo-V2.6-Pro-MOPD [13].

• MiMo-V2.6-Flash-MOPD [14].

• Repositório oficial do MiMo-V2-Flash [24].

• MiMo-V2.6-Distill-Qwen-9B [21].

• MiMo-VL [16], MiMo-Audio [17] e MiMo-V2.5-ASR [18].