Artigo por Xiang Xianzhi
Luo Fuli postou um X para encerrar o escândalo de redução de preços do MiMo da Xiaomi.
Em 26 de maio, a conta oficial do MiMo da Xiaomi postou um anúncio no X: as APIs da série MiMo-V2.5 terão redução permanente de preços, com redução máxima de 99%. Todos os comprimentos de contexto terão preço único, e os pacotes de tokens serão upgrade em 5 a 8 vezes.
Este anúncio dominou o círculo de IA na China por uma semana inteira. A reação inicial da indústria dividiu-se em várias correntes. A maior delas afirmou que se trata de "outra rodada de guerra de preços" — nos últimos dois anos, desde Zhipu, DeepSeek, ByteDance DouBao até Alibaba Tongyi, os grandes modelos nacionais têm se alternado em reduções de preços, e ninguém está fora da competição.
Outra perspectiva é mais pessimista: a Xiaomi acabou de anunciar que seu lucro este ano foi reduzido à metade, e ainda assim está investindo 60 bilhões em IA e cortando 90% dos gastos com API — um clássico "perder dinheiro para conquistar mercado". Alguns também acreditam que isso é uma continuação do efeito DeepSeek — que puxou todo o padrão de precificação da indústria para o chão; quem não seguir, sai do jogo.
Como responsável pelo MiMo, Luo Fuli apresentou diretamente ontem à noite um blog técnico de 5.000 palavras, tornando públicas as contas técnicas do corte de preços.
Veja, esta é uma verdadeira capacidade de engenharia, não uma estratégia de marketing.
Para entender o que Luo Fuli está dizendo, primeiro é preciso saber exatamente o que foi reduzido em 99%.
Não é um desconto geral em todo o modelo. O desconto de 99% aplica-se exclusivamente a uma faixa de precificação chamada Input (Cache Hit) — ou seja, a parte em que o usuário lê repetidamente o contexto histórico em conversas longas. Os novos inputs comuns (No Cache Hit) têm descontos muito menores, e a saída do modelo (Output) tem o menor desconto.
Se você pensar no modelo como uma cafeteria, isso fica mais fácil de entender.
Você pede um latte com meia dose de açúcar, e a cafeteria tem duas maneiras de fazer: cada vez moer os grãos, medir o xarope e despejar o leite, pagando pelos ingredientes e mão de obra a cada vez; mas o modelo sabe que, nesta semana, você vai beber o mesmo latte com meia dose de açúcar todos os dias, então faz um grande recipiente e guarda na geladeira, servindo uma porção de cada vez na próxima vez. O MiMo fez exatamente isso desta vez — transformou a parte repetida da leitura do usuário de "calcular em tempo real" para "buscar em tempo real", tornando o custo real dessa parte próximo de 0, permitindo naturalmente um desconto de 99%.
Para alcançar o "retirada imediata", o blog técnico descreveu seis engenharias, nenhuma das quais pode faltar. Vamos analisar cada uma separadamente.
Projeto 1: Reduzir a "memória" do modelo para 1/7
Durante a conversa com você, o modelo calcula um "estado intermediário" para cada token e o armazena para uso na próxima etapa. Esse componente é chamado de KVCache — pode ser entendido como um "caderno de memória de curto prazo" do modelo. A cada frase dita, o modelo anota um resumo dessa frase no caderno e, na próxima vez, simplesmente consulta as anotações, sem precisar ouvir novamente todo o conteúdo já dito.
O modelo tradicional aplica "Atenção Total" em cada camada — ou seja, cada token analisa todos os tokens da conversa inteira, fazendo o caderno ficar cada vez mais grosso. O MiMo-V2.5-Pro modificou a arquitetura: das 70 camadas, 60 analisam apenas os últimos 128 tokens (SWA, Sliding Window Attention), enquanto apenas 10 camadas, os "administradores de arquivos", analisam todos os tokens.
O resultado é que o tamanho do KVCache foi reduzido diretamente para 1/7 do Full Attention, e a quantidade de cálculo também é 1/7.
Esta é a primeira base para redução de custos. Por exemplo, anteriormente, todos os funcionários da empresa eram obrigados a memorizar todas as atas de reuniões, resultando em sobrecarga mental e baixa eficiência. A nova regra reduziu a carga mental de 60 funcionários para 1/7, mantendo apenas 10 administradores de arquivos responsáveis por todo o histórico — a capacidade geral de memória da empresa não diminuiu, mas a eficiência aumentou sete vezes.
Projeto 2: Tornar o espaço economizado pelo SWA realmente utilizável
Reduzir o notebook para 1/7 na arquitetura é o primeiro passo, mas há um obstáculo para transformar o "1/7 teórico" no "1/7 real".
O sistema tradicional de KVCache aloca memória GPU uniformemente para todas as camadas com base no "uso máximo possível". Isso significa que, mesmo que as 60 camadas do SWA precisem apenas de um caderno pequeno, o sistema aloca para todas as camadas como se fosse o "caderno grande do administrador de arquivos" — o espaço economizado pelo SWA é simplesmente reservado inutilmente, equivalendo a não ter economizado nada.
A abordagem da equipe Luo Fuli consiste em dividir o KVCache em dois pools independentes. As 10 camadas de Full Attention utilizam o "pool grande", alocadas conforme o comprimento total; as 60 camadas de SWA utilizam o "pool pequeno", alocadas apenas conforme uma janela de 128 tokens.
Por exemplo, anteriormente, a empresa fornecia a cada funcionário um armário capaz de armazenar arquivos por 100 anos — mas 60 funcionários realmente precisavam apenas de pequenos armários para armazenar arquivos de uma semana, com 99% do espaço desses grandes armários vazio. A nova abordagem é distribuir armários conforme a necessidade real. Como resultado, o escritório pode acomodar mais de cinco vezes mais colegas para trabalhar — o número de usuários simultâneos que uma única GPU pode atender dobrou cinco vezes.
Este passo parece simples, mas sem ele, as vantagens da arquitetura SWA anteriores seriam inúteis.
Projeto 3: Garantir que "usuários antigos leiam novamente" realmente atinja o cache
Notebook pressionado em 1/7 + espaço realmente acessível; o próximo passo é resolver um problema antigo: a taxa de acerto do cache de prefixos.
Muitas conversas de usuários começam da mesma forma — com o mesmo prompt do sistema, o mesmo repositório de código e o mesmo documento longo. O sistema armazena os resultados já calculados e, na próxima correspondência, reutiliza-os diretamente. Esse mecanismo é chamado de cache de prefixo.
Mas no modo SWA, existe uma armadilha: duas solicitações com o mesmo token não significam que o KV ainda esteja válido. O prefixo pode ter sido calculado, mas as partes fora da janela SWA já foram descartadas. Se o sistema ainda reutilizar com base na regra antiga de "mesmo token = acerto", você poderá ler dados inválidos ou sobrescritos, e o desempenho do modelo entrará em colapso.
A equipe de Luo Fuli atualizou as regras para "comprimento de segurança da janela" — comprometendo-se apenas com "a parte que você pode emprestar integralmente".
Por exemplo, uma biblioteca tem um milhão de livros e você quer emprestar a coleção completa de três volumes de "The Three-Body Problem". A arquitetura antiga lhe diria "este livro está disponível", mas ao ir até lá, você descobre que na prateleira só resta a capa e o primeiro volume — os dois últimos já foram emprestados. Esse tipo de "falso acerto" faz você perder tempo e ter que solicitar novamente. O novo sistema alterou a regra para apenas prometer o que você pode obter integralmente — primeiro, lhe entrega o primeiro volume, depois busca e fornece os dois restantes.
Parece que ficará mais rigoroso e a taxa de acerto diminuirá. Mas, na realidade, é o contrário: como o SWA reduz o tamanho do KVCache para 1/7, o mesmo espaço de armazenamento pode conter várias vezes mais conteúdo, aumentando significativamente a taxa de acerto real.
No blog de Luo Fuli, foram fornecidos números reais online: a taxa de acerto de cache no servidor, sob frameworks de harness principais, é em média de 93%, podendo ultrapassar 95% para usuários de alto volume e ciclos longos.
O significado deste número: 95% das solicitações de "leitura repetida" não utilizam nenhuma GPU, sendo recuperadas diretamente do cache. Essa é a base física do desconto de 99%.
Projeto 4: Colocar o "cache" no SSD integrado à GPU
A taxa de acerto aumentou; a próxima pergunta é: onde esses caches estão armazenados.
A memória de vídeo (HBM na GPU) é cara e limitada — uma máquina com oito GPUs H100 possui apenas 640 GB de memória de vídeo, mas o KVCache que o MiMo precisa armazenar pode ser da ordem de dezenas de TB. Portanto, é necessário implementar uma arquitetura em camadas: os dados mais recentes são armazenados na memória de vídeo (L1), os dados um pouco mais antigos na memória RAM do CPU (L2) e os dados frios no cache distribuído (L3).
É como gerenciar seu dinheiro. O dinheiro na carteira é a memória de vídeo — disponível para uso imediato, mas com capacidade limitada. O saldo do cartão bancário é a memória RAM do CPU — leva 30 segundos para sacar, mas permite armazenar muito mais. A poupança a prazo é o cache distribuído L3 — leva 2 minutos para sacar, mas é muito mais barato.
A prática comum da indústria é criar um cluster de armazenamento separado para L3, com máquinas dedicadas e data center dedicado, pagando aluguel mensalmente.
A abordagem da equipe de armazenamento da Xiaomi é diferente. Eles desenvolveram internamente um cache distribuído chamado GCache, implantado diretamente nos SSDs integrados às máquinas GPU — compartilhando a mesma máquina com tarefas de treinamento e inferência.
Alguém alugou um armazém inteiro para armazenar grandes quantidades de dados; a Xiaomi descobriu que o galpão com máquinas GPU estava vazio e armazenou os dados lá diretamente. Economizou o aluguel mensal.
O custo adicional de armazenamento é zero.
O impacto desta questão é maior do que parece. Nos cálculos tradicionais de custo de computação de empresas de IA, o custo de armazenamento é um item de despesa fixa — quanto maior o seu modelo e mais usuários você tiver, mais longa será a fatura de armazenamento. A abordagem do GCache elimina diretamente esse item. Combinado com o tamanho reduzido do SWA e uma taxa de acerto de 93-95%, o tempo de vida (TTL) do KVCache no L3 aumenta de minutos para horas, ou até dias — quanto maior o TTL, mais amplo é o intervalo de acerto para o contexto histórico, maior a taxa de acerto do cache e mais sustentável se torna o desconto de 99%.
Projeto 5: Faça com que as solicitações que atingem o cache percorram o caminho mais curto
O cache pode armazenar, pesquisar e é barato; o último passo é: como direcionar as solicitações corretas para os servidores corretos.
A Xiaomi desenvolveu um sistema de agendamento próprio chamado LLM-Router, que realiza três tarefas:
Primeiro, agendamento afim. Requisitos com o mesmo prefixo são roteados para a mesma máquina, maximizando a reutilização de cache.
Em segundo lugar, agrupamento por tamanho. Redirecione solicitações curtas (0-64K), médias (64K-256K) e longas (256K-1M) para canais de processamento distintos, evitando que solicitações curtas sejam afetadas por solicitações longas.
Terceiro, otimização do TTFT. Na fila de espera por inferência, priorize o agendamento de solicitações com menor carga de cálculo real (ou seja, aquelas que atingem amplamente o cache) — evite que sejam bloqueadas por solicitações de "entrada totalmente nova" que exigem cálculos pesados.
Por exemplo, na programação convencional de aeroportos, todos os passageiros com destino ao mesmo local são concentrados no mesmo salão de embarque e compartilham o processo de retirada de bagagem — isso é agendamento por afinidade. Passageiros com bagagem de mão e aqueles com três malas despachadas seguem por dois canais de segurança diferentes, evitando que os rápidos sejam atrasados pelos lentos — isso é bucketing por comprimento. Durante o embarque, prioriza-se quem leva apenas bagagem de mão, pois embarcam mais rápido, permitindo que o avião decole mais cedo — isso é otimização TTFT.
Esta estratégia de agendamento reduziu em 25% a taxa de acerto do cache L2, aumentou em 30% o throughput de entrada por servidor e reduziu em 30% a latência P90 para solicitações longas.
A mesma GPU pode atender mais usuários. A outra metade da lógica da redução de preços está aqui — a produção efetiva por unidade de poder de cálculo é maior e o custo por usuário é menor.
Projeto seis: tornar o modelo "digitar" mais rápido
As cinco primeiras coisas otimizam o lado da "leitura" — reduzindo o custo para o usuário reler o contexto histórico para quase zero. A sexta coisa otimiza o lado da "escrita" — ou seja, o processo de geração do próximo token pelo modelo.
Modelos tradicionais geram apenas 1 token por vez. O MiMo suporta nativamente 3 níveis de MTP (Multi-Token Prediction) — prevendo os próximos 3 tokens de uma vez, e pulando diretamente os cálculos intermediários se as previsões forem corretas.
Por exemplo, digitar tradicionalmente é digitar uma letra de cada vez — se você quiser digitar "今天天气", precisa pressionar 4 teclas. O MTP tem como se tivesse uma previsão automática que adivinha seus próximos 1-2 caracteres — se ela acertar, você não precisa pressionar aquelas duas teclas.
O MTP do MiMo em cenários agênticos demonstrou aceleração de 2,3 vezes nos primeiros 128 tokens e 1,5 vezes entre 128 e 256 tokens.
O significado disso é que o desconto de 99% se aplica especificamente ao Input (Cache Hit), mas quando o modelo atende os usuários reais, input e output ocorrem na mesma requisição — se o output não for economizado, o custo total da requisição é reduzido apenas pela metade. O MTP também reduz essa metade do output, fechando assim o modelo de lucro com a redução completa de custos.
Ligue seis coisas em uma cadeia de redução de custos:
Arquitetura SWA → KVCache 1/7 → Dois pools liberam verdadeiramente capacidade → Uma única GPU pode acomodar mais de 5x mais concorrência → Taxa de acerto de cache de prefixo de 93-95% → 95% das requisições quase não precisam de cálculo → GCache reduz o custo de armazenamento a zero → O agendamento prioriza as requisições com acerto → MTP também economiza geração → O tempo de GPU por requisição diminui uma ordem de grandeza → O custo por unidade cai mais de 95% → O preço cai 99%, mas a margem bruta permanece positiva.
Qualquer etapa ausente fará com que essa cadeia se quebre em algum ponto. O desconto de 99% não é um número de marketing, mas um efeito acumulado resultante da combinação de seis pilares de engenharia e validação online real.
Olhando para as várias interpretações iniciais da indústria, cada uma tinha algum fundamento. A guerra de preços entre as empresas chinesas de modelos grandes nos últimos dois anos é real; a redução da lucratividade da Xiaomi pela metade enquanto ainda investe pesadamente em IA é real; o DeepSeek também realmente puxou os preços da indústria para o chão.
Mas ao publicar este blog técnico e detalhar abertamente os aspectos técnicos, Luo Fuli certamente espera refutar as afirmações sobre a guerra de preços, deixando claro que "problemas técnicos pertencem à tecnologia e problemas de marketing pertencem ao marketing."
Ela escreveu no blog que a eficiência de inferência dos modelos da série MiMo-V2.5 não se deve a uma única inovação em um único componente, mas sim ao resultado da otimização coordenada em múltiplas dimensões. O Hybrid SWA beneficia tanto o prefill quanto o decode, mas uma implementação mal otimizada do KVCache pode aumentar os custos em todos os estágios. Em torno desse objetivo, a equipe MiMo reestruturou sistematicamente o gerenciamento do KVCache, o cache hierárquico e a árvore de cache de prefixos, superando os problemas centrais do KVCache SWA, otimizando as estratégias de agendamento e as cadeias de prefill/decode, e validando essas melhorias em cenários reais em produção, transformando assim as vantagens teóricas de eficiência em resultados práticos. Somente então o Hybrid SWA conseguiu demonstrar plenamente suas vantagens arquiteturais em termos de potência e eficiência na inferência de textos longos. Combinado com configurações MoE e diversas otimizações para inferência multimodal, o desempenho dos serviços de inferência em produção foi significativamente aprimorado.
Este é um sistema sistemático de engenharia de IA e também uma abordagem de redução de custos que a indústria pode considerar e adotar.
A guerra de preços não precisa de um blog, a realização técnica é que precisa.