A redução de preço do Xiaomi MiMo em 99% não é marketing! Luo Fulie responde no X aos que o desacreditam

nulo

Texto | Xiang Xianzhi

Luo Fuli publicou um tweet no X, para colocar um ponto final na onda de redução de preços do Xiaomi MiMo.

26 de maio, a conta oficial do Xiaomi MiMo no X publicou um anúncio: a série MiMo-V2.5 terá redução de preço permanente na API, com até 99% de desconto. Todos os preços de contexto terão valor fixo, e os pacotes de tokens serão atualizados de 5 a 8 vezes.

Este anúncio circulou na comunidade de IA doméstica por uma semana inteira. A reação da indústria se dividiu em alguns grupos. O maior deles afirmou que se tratava de "mais uma rodada de guerra de preços" — nos últimos dois anos, desde Zhipu, DeepSeek, ByteDoudou até Alibaba Tongyi, os grandes modelos nacionais têm reduzido preços um após o outro, todos competindo ferozmente.

Outro grupo olhou de forma mais pessimista: a Xiaomi anunciou recentemente que seu lucro foi cortado pela metade neste ano, e agora ainda investe 600 bilhões em IA, além de cortar 90% das APIs — típico movimento de "perder dinheiro para ganhar mercado". Alguns também acreditam que isso é uma continuação do efeito DeepSeek — que colocou toda a indústria na base de preços mais baixos, obrigando os demais a saírem do mercado.

Portanto, como responsável pelo MiMo, Luo Fuli publicou na noite passada um blog técnico de 5000 palavras, revelando as contas de engenharia por trás da redução de preços para todos.

"Veja, isso é uma demonstração real de capacidade técnica, não uma estratégia de marketing."

Para entender o que Luo Fuli quis dizer, primeiro é preciso compreender o que exatamente caiu 99%.

Não é o modelo inteiro que teve redução de preço. O desconto de 99% é específico para uma categoria chamada Input (Cache Hit), ou seja, a parte em que "o usuário repete a leitura do histórico de contexto em diálogos longos". Para entradas novas comuns (No Cache Hit), a redução é muito menor, e a de saída do modelo (Output) é a mais limitada.

Se você imaginar o modelo como uma cafeteria, fica mais fácil de entender.

Você pede um café com meia dose de açúcar, e a cafeteria tem duas opções: fazer do zero toda vez, moendo os grãos, colocando açúcar e leite, pagando a matéria-prima toda vez; ou, sabendo que você vai pedir o mesmo café meia dose todos os dias, fazer uma grande jarra e guardar no freezer, e na próxima vez pegar uma porção. O MiMo fez a segunda opção — transformar a parte que o usuário repete em algo como "pegar na hora", reduzindo o custo real dessa parte a quase zero, e assim oferecer um desconto de 99%.

Para fazer "pegar na hora", o blog explica seis engenharias, cada uma essencial. Vamos analisá-las uma a uma.

Engenharia 1: comprimir a "memória" do modelo para 1/7

Quando o modelo conversa com você, cada token precisa calcular um "estado intermediário" que é armazenado para a próxima etapa. Isso se chama KVCache — pode entender como um "caderno de memórias de curto prazo" do modelo. A cada frase, o modelo registra um resumo no caderno, e na próxima vez, lê direto esse resumo, sem precisar ouvir tudo de novo.

Modelos tradicionais fazem "Full Attention" em todas as camadas — ou seja, cada token olha para todos os tokens da conversa, fazendo o caderno ficar cada vez mais pesado. A arquitetura do MiMo-V2.5-Pro mudou isso: entre 70 camadas, 60 só olham os últimos 128 tokens (SWA, Sliding Window Attention), e apenas 10 camadas, os "administradores de arquivo", olham tudo.

O resultado é que o KVCache ficou com um volume de 1/7 do que seria com Full Attention, e o cálculo também é 1/7.

Essa é a primeira base para redução de custos. Para ilustrar, imagine que na empresa cada funcionário tinha que lembrar de todas as reuniões — o resultado é que a cabeça de cada um fica sobrecarregada e a eficiência baixa. Com a nova regra, a carga mental de 60 funcionários é reduzida para 1/7, sobrando só 10 "administradores de arquivo" para cuidar de todo o histórico — a memória geral da empresa não diminui, mas a eficiência aumenta 7 vezes.

Engenharia 2: fazer o espaço economizado pelo SWA realmente ser utilizável

Com a arquitetura, comprimir o caderno para 1/7 é o primeiro passo, mas transformar esse "teórico 1/7" em um "real 1/7" é outro desafio.

O sistema tradicional de KVCache aloca toda a memória de vídeo (VRAM) de forma unificada, baseada na "maior demanda possível". Ou seja, mesmo que as 60 camadas de SWA só precisem de um caderno pequeno, o sistema reserva uma grande quantidade de memória para todas, como se fosse um grande arquivo — o espaço economizado pelo SWA fica inutilizado, pois foi pré-alocado.

A equipe de Luo Fuli dividiu o KVCache em dois pools independentes. As 10 camadas de Full Attention usam um "grande pool", alocado para toda a sequência; as 60 camadas de SWA usam um "pequeno pool", alocado apenas para uma janela de 128 tokens.

Por exemplo, imagine que a empresa distribui armários que cabem 100 anos de documentos — mas, na verdade, cada funcionário só precisa de um armário para uma semana de papéis. Os grandes armários têm 99% de espaço vazio. A nova abordagem é alocar os armários de acordo com a necessidade real. Assim, o escritório consegue acomodar mais de 5 vezes o número de funcionários no mesmo espaço — ou seja, a mesma GPU consegue atender 5 vezes mais usuários simultâneos.

Embora pareça simples, sem essa divisão, as vantagens do SWA seriam inúteis.

Engenharia 3: garantir que o cache de leitura repetida realmente funcione

Com o caderno comprimido a 1/7 e o espaço realmente utilizado, o próximo problema é a taxa de acerto do cache de prefixo.

Muitos diálogos têm início semelhante — o mesmo prompt do sistema, o mesmo código, o mesmo documento longo. O sistema armazena esses resultados já calculados, e na próxima vez, reutiliza se houver correspondência. Esse mecanismo é o cache de prefixo.

Porém, no modo SWA, há um problema: duas requisições com tokens iguais não garantem que o KV também esteja. Pode ser que o prefixo já tenha sido calculado, mas a parte fora da janela SWA já foi descartada. Se o sistema continuar usando a regra antiga de "tokens iguais, cache acerta", pode acabar lendo dados inválidos ou sobrescritos, prejudicando o desempenho do modelo.

A equipe de Luo Fuli atualizou a regra para "segurança na janela" — ou seja, só garante o cache para a parte que está dentro do comprimento completo da janela.

Por exemplo, numa biblioteca com 1 milhão de livros, você quer pegar a trilogia "Três Corpos". Antes, o sistema dizia "o livro está lá", mas na hora de pegar, só restavam as capas e o primeiro volume, os outros já tinham sido emprestados. Essa "pseudo-acerto" faz você perder tempo e precisar pegar de novo. Agora, o sistema só garante o cache para a parte que consegue pegar completo — primeiro te dá o primeiro livro, e depois traz os outros.

Parece mais rigoroso, e a taxa de acerto pode cair. Mas, na prática, é o contrário: como o KVCache foi comprimido a 1/7, o conteúdo que pode ser armazenado é muito maior, e a taxa de acerto real aumenta bastante.

O blog mostra dados de testes reais: em frameworks comuns, a taxa de acerto do cache do servidor chega a 93%, e para usuários frequentes de longo ciclo, ultrapassa 95%.

Resumindo: 95% das requisições de "leitura repetida" não precisam nem usar GPU, podem ser atendidas direto do cache. Essa é a base física do desconto de 99%.

Engenharia 4: colocar o "cache" no SSD integrado da GPU

Com a taxa de acerto melhor, o próximo passo é: onde colocar esses caches.

A memória de vídeo (HBM na GPU) é cara e limitada — uma H100 de oito GPUs tem 640GB de VRAM, mas o KVCache do MiMo pode chegar a dezenas de TB. Então, é preciso hierarquizar: os dados mais recentes ficam na memória de vídeo (L1), os um pouco mais antigos na memória RAM do CPU (L2), e os dados mais frios em cache distribuído (L3).

A prática comum na indústria é criar um cluster de armazenamento separado para o L3, com hardware dedicado e data centers específicos, pagando aluguel mensal.

A equipe de armazenamento da Xiaomi fez diferente: desenvolveram uma cache distribuída chamada GCache, que é implantada diretamente no SSD integrado às GPUs — compartilhando a mesma máquina de treinamento ou inferência.

De forma simples: enquanto outros alugam armazéns para guardar grandes volumes de dados, a Xiaomi percebeu que o "porão" da GPU está vazio, e colocou os dados lá mesmo. Assim, economiza no aluguel.

O blog afirma: "custo de armazenamento adicional é zero."

Essa inovação tem um impacto maior do que parece. No cálculo tradicional de custos de IA, o armazenamento é uma despesa fixa — quanto maior o modelo e mais usuários, maior a conta de armazenamento. Com GCache, essa despesa é eliminada. Com o SWA de baixo volume + taxa de acerto de 93-95%, a vida útil do KVCache no L3 (TTL) passa de alguns minutos para horas ou até dias — quanto maior o TTL, maior a janela de acerto do contexto histórico, e maior a taxa de cache, sustentando o desconto de 99%.

Engenharia 5: fazer as requisições de cache mais curtas

Com o cache mais eficiente, o próximo passo é: como garantir que as requisições corretas sejam roteadas para as máquinas certas.

A Xiaomi criou seu próprio sistema de agendamento chamado LLM-Router, que faz três coisas:

1. Afinidade de agendamento. Requisições com prefixos semelhantes são enviadas à mesma máquina, maximizando o reaproveitamento do cache.

2. Agrupamento por comprimento. Requisições curtas (0-64K), médias (64K-256K) e longas (256K-1M) são enviadas por canais diferentes, evitando que requisições longas atrasem as curtas.

3. Otimização TTFT. Na fila de inferência, prioriza requisições com menor carga de cálculo real (ou seja, que aproveitam o cache), evitando que requisições de entrada nova, que precisam de cálculo completo, bloqueiem o sistema.

Por exemplo, num aeroporto, passageiros com o mesmo destino são agrupados na mesma sala de embarque, para otimizar o processamento — é a afinidade. Passageiros com poucas malas ou muitas malas passam por filas diferentes, para não atrasar os outros — é o agrupamento por comprimento. E quem tem apenas uma mala de mão embarca primeiro, para o avião partir mais cedo — é a prioridade TTFT.

Essa estratégia de agendamento aumentou em 25% a taxa de acerto do cache L2, melhorou 30% a throughput por GPU, e reduziu em 30% a latência P90 de requisições longas.

Resumindo: uma mesma GPU consegue atender mais usuários. A lógica do desconto de preço está aqui — maior eficiência por unidade de cálculo, menor custo por usuário.

Engenharia 6: acelerar a "digitação" do modelo

As primeiras cinco melhorias focaram em otimizar a leitura — reduzir o custo de leitura do contexto repetido a quase zero. A sexta é sobre otimizar a "escrita" — ou seja, o processo de geração do próximo token pelo modelo.

Tradicionalmente, o modelo gera um token por vez. O MiMo suporta nativamente uma previsão de 3 tokens (Multi-Token Prediction, MTP) — prevê os próximos 3 tokens de uma vez, e, se acertar, pula a parte intermediária de cálculo.

Por exemplo, digitar normalmente é uma letra por vez — para escrever "Hoje o tempo está bom", você precisa pressionar 8 vezes. Com MTP, é como se tivesse uma sugestão automática que prevê os próximos 1-2 caracteres — se acertar, você pula essas etapas.

Na prática, em cenários agentic, o MTP acelerou a decodificação em 2,3 vezes para os primeiros 128 tokens, e 1,5 vezes para entre 128 e 256 tokens.

O impacto é que, embora o desconto de 99% seja direcionado ao Input (Cache Hit), na realidade, o input e o output ocorrem na mesma requisição — se o output não for economizado, o custo total só é reduzido pela metade. O MTP reduz também a parte do output, fechando o ciclo de lucros do desconto.

Resumindo, as seis melhorias formam uma cadeia de redução de custos:

Arquitetura SWA → KVCache 1/7 → liberação real de capacidade com pools duplos → maior capacidade de atendimento na mesma GPU → taxa de cache de 93-95% → 95% das requisições não precisam de cálculo → GCache elimina custos de armazenamento → agendamento prioriza requisições cacheadas → MTP acelera geração → tempo por requisição na GPU cai em uma ordem de grandeza → custo por requisição cai mais de 95% → preço reduzido em 99%, margem de lucro ainda positiva.

Qualquer passo faltando quebra essa cadeia. A redução de 99% não é marketing, é o resultado de seis pilares de engenharia combinados e validados na prática.

Revisando as interpretações iniciais da indústria, cada uma tem sua parte de verdade. Nos últimos anos, a guerra de preços entre as empresas chinesas de grandes modelos é real; a Xiaomi realmente cortou lucros e investe em IA; DeepSeek realmente puxou os preços para baixo.

Porém, o blog técnico detalhado de Luo Fuli, com explicações concretas, é uma resposta clara às críticas de guerra de preços — separando "questões técnicas" de "estratégias de marketing".

Ela escreveu no blog que a eficiência do MiMo-V2.5 não vem de uma única inovação, mas de uma otimização multidimensional. O Hybrid SWA permite que prefill e decode se beneficiem simultaneamente, mas uma implementação não otimizada do KVCache pode aumentar custos. Para isso, a equipe de MiMo reestruturou sistematicamente a gestão do KVCache, o cache hierárquico, a árvore de cache de prefixo, resolveu problemas centrais do SWA KVCache, otimizou a estratégia de agendamento e as ligações de prefill/decode, e testou tudo em cenários reais, garantindo que a eficiência teórica se refletisse na produção. Assim, o Hybrid SWA consegue mostrar sua vantagem em inferências de textos longos, com alta eficiência e desempenho. Combinando com configurações MoE e otimizações multimodais, o desempenho de inferência online foi significativamente melhorado.

Essa é uma abordagem sistemática de engenharia de IA, que serve de referência para a indústria na redução de custos.

Guerra de preços não precisa de blog — é a implementação técnica que importa.