Em 27 de setembro, a equipe MiMo da Xiaomi publicou um post técnico revisando um problema que os desenvolvedores vinham reclamando desde o lançamento do MiMo-V2.6: em agentes de programação, o modelo emitia repetidamente chamadas de ferramentas idênticas ou quase idênticas, consumindo contexto e poder computacional sem que a tarefa avançasse. Os pesos corrigidos já foram disponibilizados como código aberto, com nomes de arquivo trazendo o sufixo MOPD; a plataforma de API já havia migrado para a nova versão desde as 6h de 25 de setembro (horário de Pequim), e os usuários do MiMo Desktop tiveram toda a cota restante do período redefinida, como forma de compensação.
Separando "muitas chamadas" de "chamadas repetidas"
O post não trata todo excesso de chamadas como um problema. A Xiaomi lista três situações: chamadas paralelas são uma otimização normal, em que várias chamadas buscam informações diferentes cada uma; proliferação de chamadas é quando a quantidade excede o necessário para a tarefa; já a repetição de chamadas ocorre quando nem o estado do ambiente nem as informações já conhecidas mudaram, mas o modelo repete a mesma ação mesmo assim. A equipe se concentrou em corrigir apenas o terceiro caso.
Segundo a avaliação interna da Xiaomi, a taxa de repetição em nível de resposta ultrapassou o limite de tolerância de 0,05%, com diferenças consideráveis entre os ambientes:
| Ambiente | Flash | Pro |
|---|---|---|
| OpenCode | 1,02% | 0,54% |
| Claude Code | 0,27% | 0,10% |
| MiMo Desktop | 0,19% | 0,19% |
| MiMo Code | 0,11% | 0,07% |
Os números mais preocupantes vieram da versão Flash no OpenCode, onde cerca de 1 a cada 100 respostas ficava travada em loop.
A raiz do problema está na fase de aprendizado por reforço
A equipe revisou os checkpoints do treinamento de aprendizado por reforço e descobriu que a proporção de amostras com mais de dez chamadas em uma única rodada subiu de 11,1% no passo 0 para 24,6% no passo 20; no ambiente MiMo Code, o aumento foi ainda mais acentuado, de 30,6% para 41,7%. O treinamento originalmente previa uma penalidade apenas quando uma rodada ultrapassasse 32 chamadas. A partir do passo 15, o número de amostras que acionavam essa penalidade cresceu visivelmente, indicando que o limiar de 32 era frouxo demais e não impediu o modelo de desenvolver o hábito de que "algumas chamadas a mais nunca fazem mal".
O post traz um número bem direto: antes da correção, a probabilidade de o modelo optar por continuar chamando ferramentas na 12ª chamada de uma rodada era de 94,56%, contra apenas 5,43% de probabilidade de parar. Em termos simples, ele praticamente não conseguia parar sozinho.
Duas soluções, uma diferença de uma ordem de grandeza
A primeira opção era a mais direta: reduzir o limiar de penalidade de 32 para 8 e retreinar com o fluxo MixRL original. Nos testes internos, a taxa de repetição caiu de 13,45% para 3,83%, mas isso exigiria retroceder 20 passos de treinamento e recomeçar; a Xiaomi estimou o custo em cerca de US$ 2,31 milhões, e o resultado poderia se tornar instável com outro conjunto de dados.
A solução finalmente adotada foi a MOPD, destilação online com múltiplos professores. O método consistiu em usar amostras repetidas coletadas internamente para treinar separadamente um "professor" de aprendizado por reforço especializado em aprender "quando deve parar", rodando apenas 12 passos com cerca de 7.000 exemplos; em seguida, o modelo principal foi retrocedido 5 passos e continuou o treinamento sob a orientação desse professor. O processo completo custou cerca de US$ 90 mil, cerca de 4% do custo da primeira opção.
Em termos de resultado, a probabilidade de parar na 12ª chamada subiu de 5,43% para 92,17%. Segundo a curva cumulativa de parada apresentada no post, antes da correção o modelo só ultrapassava 50% de probabilidade de parar por volta da 59ª chamada; depois da correção, já na 8ª chamada essa probabilidade chega a 99,87%. A Xiaomi afirma que a taxa de repetição caiu drasticamente em todas as plataformas, o comportamento se manteve consistente em diferentes tamanhos de contexto, e as pontuações gerais de benchmark não caíram.
Encaixando no contexto do V2.6
O MiMo-V2.6 foi lançado e disponibilizado como código aberto em 22 de setembro, ocasião em que a Xiaomi destacou principalmente a escala do pós-treinamento: segundo números divulgados pela imprensa, as versões Pro e Flash passaram cada uma por 30 passos de aprendizado por reforço, com custo total de cerca de US$ 3,5 milhões. Cinco dias depois, esta revisão expõe um efeito colateral daquela rodada de treinamento, chegando a detalhar que a correção poderia ter custado mais US$ 2,31 milhões.
Não é comum que equipes de modelos chinesas publiquem revisões de incidentes após o lançamento, e é ainda mais raro que listem também o custo das soluções que fracassaram. Para desenvolvedores que usam modelos nacionais chineses no OpenCode ou no Claude Code, o ponto prático é: quem enfrentou nos últimos dias o MiMo lendo repetidamente o mesmo arquivo ou executando repetidamente o mesmo comando já está usando, via API, a versão corrigida; quem faz autohospedagem precisa trocar para os pesos com o sufixo MOPD. Todos esses números de taxa de repetição vêm da avaliação interna da Xiaomi, e ainda não há resultados de verificação independente por terceiros.
Fontes: blog técnico da equipe MiMo da Xiaomi, CocoLoop; as taxas de repetição e proliferação por ambiente, bem como os custos das duas soluções, seguem a avaliação interna da Xiaomi.