MiMo-V2.5-Pro-UltraSpeed: modelo de 1T que gera 1000 tokens por segundo

• Primeiro modelo a ultrapassar 1000 tokens/s de velocidade de decodificação em um modelo com 1 trilhão (1T) de parâmetros
• A velocidade foi alcançada usando apenas GPUs commodity, sem hardware dedicado, com saída de 1000+ tps em um único nó padrão de 8 GPUs
• A tecnologia central é um codesign de modelo-sistema que combina quantização FP4 com DFlash speculative decoding
• A API será oferecida por inscrição e por tempo limitado, promovendo cerca de 10x mais velocidade de geração por 3x o preço
• Ultrapassar 1000 tps não é apenas um ganho de velocidade, mas um ponto de virada que muda o próprio paradigma de aplicações de IA, como Coding Agents e tomada de decisão em tempo real

---

Lançamento do Xiaomi MiMo-V2.5-Pro-UltraSpeed

• Em colaboração com a TileRT, ultrapassou pela primeira vez 1000 tokens/s de velocidade de decodificação em um modelo de 1 trilhão de parâmetros, oferecendo um nível de velocidade que permite resposta em tempo real e iteração imediata
• Na comparação de velocidade de geração em tempo real, atingiu até cerca de 1200 tokens/s
• Apresenta a visão de que, quando um modelo é rápido o suficiente, ele deixa de ser uma ferramenta de espera e passa a funcionar como uma extensão do pensamento

Oferta por tempo limitado e mediante inscrição

• A API foi lançada com preço promocional limitado, oferecendo custo 3x maior que o MiMo-V2.5-Pro e cerca de 10x mais velocidade de geração (somente API, sem suporte ao Token Plan)
• Devido à limitação de recursos de inferência de alta velocidade, a operação será por inscrição e por tempo limitado; apenas usuários aprovados poderão usar a API entre 9 de junho de 2026 e 23 de junho, 23:59 (UTC+8)

• Como se inscrever

  • A plataforma da API está em platform.xiaomimimo.com/ultraspeed; a inscrição não garante aprovação, e empresas e desenvolvedores profissionais com demanda real de negócio terão prioridade
  • O acesso ao modelo padrão é oferecido pela série MiMo-V2.5

• Experiência no Chat (gratuita durante o trial)

  • Usuários aprovados recebem acesso gratuito ao Chat por 2 semanas, com entrada em ultraspeed.xiaomimimo.com
  • Máximo de 10 entradas na fila por dia por conta, até 30 minutos por sessão, com liberação automática após mais de 5 minutos de inatividade

1000 tokens/s — uma mudança de paradigma além da velocidade

• Ultrapassar 1000 tps em escala 1T não significa apenas uma máquina de escrever mais rápida, mas uma mudança que abala de forma fundamental o próprio paradigma das aplicações de IA

• Quando velocidade se converte em inteligência

  • Dentro do mesmo tempo real (wall-clock), é possível executar em paralelo dezenas de caminhos de inferência (Best-of-N / Tree Search), com verificação automática e autocorreção em segundo plano, melhorando diretamente a qualidade do raciocínio

• Remoção do limite de produtividade de Coding Agents

  • Antes, a latência de inferência era o gargalo e os desenvolvedores precisavam esperar diante da tela; com 1000 tps, a velocidade de geração de código e a eficiência produtiva aceleram em nível de paradigma

• Entrada em loops de decisão em tempo real

  • Com ciclos de "think-respond" na escala de milissegundos, um modelo flagship de 1T pode ser combinado com cenários sensíveis ao tempo, como geração de sinais de trading quantitativo de alta frequência, bloqueio imediato de transações anômalas, bidding inteligente e conversação em tempo real
  • Em aplicações como assistência cirúrgica e análise de imagens médicas, apresenta a visão de que cada segundo economizado na análise de lesões e previsão de risco dá ao cirurgião mais margem de ação

Codesign extremo entre modelo e sistema

• Os 1000+ tps em um modelo 1T não vêm de uma única técnica, mas do resultado de um codesign extremo entre a equipe de modelos MiMo e a equipe de sistemas TileRT

• Diferentemente do uso comum na indústria de hardware dedicado para velocidades parecidas — como o Wafer-Scale da Cerebras e a arquitetura customizada com SRAM on-chip da Groq — o resultado foi alcançado em GPUs commodity apenas com codesign de modelo e sistema

• Do lado do modelo, a quantização FP4 voltada ao gargalo de largura de banda reduziu o tamanho do modelo e a carga de acesso à memória; ao mesmo tempo, a introdução do DFlash, baseado em previsão paralela com mascaramento por blocos, aumentou o comprimento de tokens aceitos por etapa de verificação

• Do lado do sistema, a TileRT fornece um mecanismo de compilação e kernels de computação ajustados às características desse algoritmo, viabilizando saída de 1000+ tps em um único nó commodity padrão de 8 GPUs

• 3.1 Quantização FP4

  • Em escala 1T, a inferência tradicional em 8 bits (FP8/INT8) e 16 bits impõe pressão excessiva de memória e largura de banda; reduzir a largura de bits contribui diretamente para a velocidade de decodificação
  • Foi adotado o formato FP4 (MXFP4), validado e praticamente sem perda, mas a aplicação simples ao modelo inteiro causa queda de desempenho em inferência complexa, lógica e geração de código
  • Na arquitetura MoE (Mixture of Experts), apenas os Experts que ocupam a maior parte dos parâmetros e têm maior tolerância à quantização foram seletivamente quantizados em FP4; os demais módulos mantiveram a precisão original
  • Com FP4 QAT (Quantization-Aware Training), foi possível reduzir o tamanho do modelo e maximizar o uso da largura de banda do hardware, mantendo desempenho geral praticamente equivalente ao original

• 3.2 DFlash Speculative Decoding

  • No speculative decoding tradicional, um pequeno draft model prevê os próximos tokens e um modelo grande os valida; a taxa de aceitação depende da qualidade do draft, mas quanto mais forte o draft, maior o custo computacional — uma tensão inerente
  • O DFlash preenche todo o bloco mascarado em uma única forward pass do draft model, removendo a restrição serial do "autoregressive drafting"
  • Usando o otimizador Muon de segunda ordem e self-distillation do modelo, o overhead da etapa de draft foi comprimido para perto do mínimo teórico
    • O draft model usa apenas Sliding Window Attention (SWA), alinhando-se naturalmente ao design SWA da série MiMo-V2 e reduzindo o custo computacional por previsão de proporcional ao tamanho do contexto para constante, ao remover totalmente a dependência de prefixo
    • Durante o treinamento, a amostragem de mask-signal foi levada para shards locais da GPU, permitindo que uma única sequência gerasse dezenas de milhares de sinais de treinamento independentes em um passo, evitando overhead de comunicação entre dispositivos
  • O tamanho do bloco foi limitado a 8 para reduzir o overhead de verificação e aumentar a simultaneidade; um alto Acceptance Length se converte diretamente em alto throughput de inferência
  • Acceptance Length médio por cenário
    • Coding 6.30 (em algumas amostras, máximo de 7.14, com 6 a 7 tokens aceitos entre 8 tokens draft)
    • Math / Reasoning 5.56
    • Agent 4.29
  • Em cenários de conversa geral, semanticamente mais dispersos e com maior incerteza, a taxa de aceitação ainda é baixa no momento, e a otimização contínua está em andamento

• 3.3 Kernels / sistema de inferência de ultra baixa latência da TileRT

  • Em uma frequência operacional de 1000 tokens/s, a duração de cada operador é comprimida para a escala de microssegundos, e as "operator boundaries" dos sistemas tradicionais de inferência tornam-se um gargalo crítico
  • Cada início de execução de operador, sincronização de hardware e ida e volta à memória global interrompe o fluxo de execução, gerando "Execution Gaps" visíveis

  • Inovação de paradigma no modelo de execução da TileRT

    • Persistent Engine Kernel: abandona o modelo de inicialização por operador e mantém todo o pipeline de computação residente e fluindo continuamente dentro da GPU, alcançando sobreposição extrema entre movimentação de dados e computação
    • Warp Specialization (colaboração em pipeline heterogêneo): decompõe com mais granularidade física, no nível de tile, a comunicação, a movimentação de dados e a computação tensorial, rompendo o modelo homogêneo lock-step e transformando a GPU em um sistema de execução heterogêneo finamente orquestrado

  • Fusão profunda hardware-software em escala de microssegundos (Codesign)

    • Na camada do modelo, foram adotados quantização FP4 mista para Experts em MoE e DFlash speculative decoding alinhado a SWA para a arquitetura de 1 trilhão de parâmetros; a TileRT se integra de forma estreita a essas características algorítmicas e ao método de quantização, oferecendo mecanismo de compilação e kernels customizados
    • As duas equipes conduziram trade-offs conjuntos de engenharia baseados na física do hardware para fazer a pressão de execução convergir suavemente dentro dos limites do hardware
    • A TileRT é uma equipe de arquitetura de sistemas focada em infraestrutura de IA de próxima geração e inferência de ultra baixa latência, buscando uso extremo da capacidade computacional em ambientes heterogêneos complexos por meio de avanços full-stack em persistent kernel, pipeline por tile e colaboração heterogênea

Vídeos de demo adicionais

• Demo criando um jogo Snake em 10 segundos
• Demo recriando uma interface do MacOS em 1 minuto

Open source e perspectivas

• Checkpoint MiMo-V2.5-Pro-FP4-DFlash disponibilizado como open source no HuggingFace, incluindo pesos quantizados em FP4 e parâmetros do modelo DFlash
• Suporte UltraSpeed para o MiMo-V2.5 está em preparação

[GN⁺]

Comentários do Hacker News

• IA rápida é realmente fascinante, mas também bastante inquietante. Mesmo agora, o Claude já é mais rápido do que eu em algumas tarefas, mas ainda estamos mais ou menos no mesmo nível
  Estou rodando um prompt para organizar um PR há 1 hora e parece que ainda vai levar mais algumas horas; se isso terminasse quase instantaneamente, é difícil imaginar como o fluxo de trabalho mudaria. Às vezes começo a fazer multitarefa por causa de prompts demorados e depois me arrependo. Por outro lado, se uma IA conseguir terminar em segundos ou minutos coisas que antes levavam horas ou dias, isso muda completamente o jogo, e não faço ideia de onde nós vamos nos encaixar

  • Uso o Deepseek-v4-pro como modelo principal e às vezes ele é bem irritante. Delego uma tarefa simples e penso “vou deixar o agente cuidando disso e tirar um cochilo”, mas antes mesmo de eu me levantar da frente do computador ele já escreveu todo o código
  • Já usei groq e GPT OSS, e o 20B roda a 1000 TPS, enquanto o 120B roda a 800 TPS, então a velocidade parece meio mágica
    Ainda não usei os 3000 TPS da Cerebras, mas já testei uma demo de um modelo de 15.000 TPS cujo nome eu não lembro. Não sei se isso faz diferença real no trabalho do dia a dia, mas ver o texto enchendo a tela num piscar de olhos é realmente impressionante. É muito útil para pequenas validações, como mostrar o diff e confirmar se a mudança bate com a intenção, e poder fazer esse tipo de checagem várias vezes rapidamente ajuda bastante a realizar muitas inspeções focadas sem perder o ritmo
  • Se a latência ficar baixa o suficiente, não há motivo para multitarefa. Dá para pedir uma coisa por vez e ver o resultado imediatamente, e isso é um jeito bem bom de trabalhar
    Em tarefas que não são intensivas em computação, as UIs interativas sempre funcionaram assim. Na maior parte do tempo, os programas ficam parados esperando o usuário apertar um botão. Não deveria ser necessário ficarmos esperando os programas ou girando vários pratos ao mesmo tempo para nos manter ocupados. Mas só LLM mais rápida não basta, também precisamos de compilação e testes rápidos
  • O próximo gargalo é o compilador, mas dá para modelar isso com LLM também. Só erra uns 15% :)
    Falando sério, usar a Cerebras a cerca de 2k tokens/s com latência muito baixa dá a sensação de estar vendo o futuro. Você acaba reorganizando o fluxo de trabalho em torno de tarefas que podem acontecer sem revisão manual pesada, descrevendo explicitamente as condições de sucesso. Poucos dos meus problemas se encaixam bem nisso, mas parece ser para onde estamos indo. Claro, modelos rápidos normalmente não são os de melhor desempenho, mas se passarmos a ter alta qualidade com raciocínio quase instantâneo, isso vira um divisor de águas para o qual realmente não estamos preparados
  • Tem dois lados. Quando peço algo ao Gemini 3.5 Flash, ele entrega quase instantaneamente e funciona bem, e às vezes essa velocidade assusta um pouco
    Mas em outras tarefas ele pode seguir por um caminho totalmente errado. Antes eu conseguia interromper e dizer “pera, isso não”, mas quando o texto aparece na tela e dá tempo de reagir, ele já fez uma mudança grande. A menos que se force um commit a cada edição, é difícil impedir que ele erre tão rápido quanto acerta, e se tiver permissões demais, também pode cometer erros em APIs remotas

• Não entendo muito bem esse papo de produtividade. Do ponto de vista de um funcionário comum, não importa tanto se algo que antes levava 2 dias agora pode ser feito em 2 horas. Afinal, ele não pode usar o tempo restante como quiser; continua tendo que trabalhar 8 horas por dia
  Antes havia o prazer de passar 2 dias mergulhando fundo num problema e construindo algo. Agora o padrão vira puxar uma caça-níquel esperando que, com o prompt certo, saia a resposta certa. Para nós, isso parece até pior. Claro, para empresas e executivos a situação é totalmente o oposto, e eles provavelmente vão adorar todo esse cenário de IA

  • Se você dividir as tarefas para a IA em partes pequenas, consegue manter o controle da arquitetura e deixa de ser uma caça-níquel. Você ainda lê o código e às vezes escreve partes dele também
    Não é o que mais uso, mas é o preço que se paga por mais velocidade. Se você jogar uma tarefa grande para a IA e voltar uma hora depois, pode descobrir que desperdiçou uma hora e não conseguiu nada
  • No meu caso, modelos lentos dificultam o gerenciamento paralelo de contexto e tarefas. É muito melhor fazer uma coisa só até terminar, descansar e depois passar para a próxima
    Agora mesmo estou tocando três tarefas em paralelo em três abas, mas preciso ficar alternando de contexto o tempo todo, e isso é muito mais doloroso. Com modelos mais rápidos, deixa de ser necessário começar outra tarefa enquanto se espera
  • Com qualquer tecnologia, existe um jeito burro e um jeito inteligente de usar. Tratar isso como uma “caça-níquel que devolve a resposta certa” é o jeito burro. Pode até funcionar por um tempo, mas não dura muito, porque todo mundo pode fazer igual
    Nada impede você de usar essa tecnologia para mergulhar ainda mais fundo nos problemas do que antes. Esse é o uso inteligente
  • Não sei em que mundo as pessoas realmente trabalham 8 horas por dia. Talvez registrem 8 horas de presença, mas não passam esse tempo todo trabalhando
  • Nossa capacidade de avaliar a qualidade do resultado está ficando ainda mais para trás do que nossa capacidade de produzir o resultado. Não dá para dizer que a “resposta certa” seja necessariamente a saída mais plausível

• A otimização de preço e velocidade dos fornecedores chineses, somada ao aumento de preços das empresas americanas, deve mudar o jogo em breve. Muitas empresas já estão tendo problemas com a conta de IA

  • Os modelos chineses são bons o suficiente e baratos.
    Uso a assinatura anual do GitHub Copilot, e a Microsoft recentemente mudou a cobrança para um modelo baseado em tokens. Ainda cobra por unidade de solicitação premium, mas o GPT 5.4 passou do antigo 1x para 6x
  • Como não estou com muito dinheiro sobrando, ultimamente tenho usado o máximo possível DeepSeek v4 Flash, GLM 5.1 etc. em vez de Claude ou GPT
  • Outro problema é que todos os modelos americanos são de código fechado. Se eu fosse uma grande empresa, talvez não quisesse que minha organização ficasse refém da OpenAI ou da Anthropic.
    Realmente não entendo qual fosso competitivo esses laboratórios de modelos dos EUA têm. Se a melhoria recursiva de si mesmos está logo ali, e os laboratórios chineses estão só um pouco atrás dos principais modelos americanos, então qual é o fosso dos laboratórios dos EUA? Que os modelos americanos fazem melhoria recursiva de si mesmos melhor do que os modelos open source chineses? Posso estar completamente errado, mas se eu tivesse colocado dinheiro na OpenAI ou na Anthropic, gostaria de tirar tudo agora. Acho bem possível que isso vá para quase 0 nos próximos anos
  • Um problema ainda maior é a consistência do modelo. Não dá para saber se a Anthropic, cobrando preço de Opus, vai rotear a solicitação para um modelo mais barato.
    Por isso, não dá para prever o custo do trabalho. Talvez seja preciso reiniciar várias vezes e pagar a cada tentativa. Além disso, é preciso enviar mais prompts só para tentar medir se o modelo é de verdade ou falso, o que também aumenta o uso de tokens
  • Fico curioso sobre a estrutura econômica que leva a essas decisões de preço. Não sei se as empresas chinesas subsidiam mais os modelos do que as americanas, ou se isso é resultado de diferenças nas políticas energéticas entre os países

• Se o MiMo for tão barato quanto o Deepseek, então, com base nesta discussão anterior https://news.ycombinator.com/item?id=48282814, mesmo multiplicando por 3 pela velocidade ultra-alta ainda continua assustadoramente barato

  • MiMo e DeepSeek não são baratos; Anthropic e OpenAI é que são caros em relação ao valor que entregam

• A versão de velocidade normal do MiMo V2.5 Pro ainda é o modelo aberto com pesos para coding agent mais forte que testamos. É interessante como recebeu muito menos atenção do que lançamentos com desempenho inferior.
  O preço do “fast mode” aqui também é muito competitivo. Os dados estão em https://gertlabs.com/rankings

  • Por que o deepseek v4 pro aparece muito abaixo do flash? Onde está o mimo 2.5?

• Pode soar como propaganda, mas existe crescimento exponencial. Vamos chegar a um ponto em que criaremos quase instantaneamente vários softwares a partir de um prompt e escolheremos o melhor entre eles.
  Discussões sobre escolher a biblioteca com o melhor nome de método em açúcar sintático vão parecer tão estranhas quanto sugerir que se escreva a entrada em assembly

  • Isso soa como crescimento exponencial de software ruim. Não é que antes já não existisse lixo produzido em massa em engenharia de software, mas agora ele vai explodir
  • Houve uma época em que surgia um novo framework de frontend a cada 3 meses. Agora isso quase parou e ninguém mais liga
  • Não sei. Os engenheiros ainda podem criar software do jeito antigo. Por exemplo, passar meses fazendo algo como Obsidian ou Ghostty, cuidando de cada linha de código, das dependências e de uma boa arquitetura.
    É o jeito realmente antigo, e se o produto for bom, vai dar certo
  • Sou mais otimista. Conforme a IA melhora e fica mais rápida, podemos melhorar código com mais rapidez e de forma iterativa, inclusive código que antes evitávamos por causa do volume de trabalho.
    Na prática, graças à IA já fiz várias refatorações em um nível que normalmente seria impensável. Não é só pelo volume de trabalho; às vezes existe uma fricção dupla porque nem se sabe se vai dar certo. Com IA, você pode testar uma refatoração enquanto toma um café e ver onde ela emperra. No geral, a IA vai fazer a humanidade revelar a si mesma de forma mais extrema. Tanto para o bem quanto para o mal. Só acho que vai haver mais do lado ruim
  • A tendência exponencial deve levar, em alguns anos, a computação totalmente em memória, o que será 100 vezes mais eficiente. Isso significa que modelos pelo menos 10 vezes maiores serão possíveis, muito mais inteligentes e ainda muito rápidos.
    Em pequenas empresas, o código poderá ser simplesmente pulado, e a UI será renderizada diretamente em velocidade de conversa a partir de dados de contexto e prompts. Algo semelhante ao que o Google Genie faz em jogos, mas de forma muito mais precisa

• Isso vai ser realmente poderoso em voz. Por causa da capacidade de raciocínio, os LLMs ficam muito mais inteligentes, mas em voz o orçamento de latência é tão apertado que normalmente não dá para gastar esse tempo

• A Cerebras está testando o Kimi K2.6 a 3000t/s, só por convite. Estou ansioso pelo momento em que hardware rápido fique mais comum também para modelos de fronteira.
  Modelos projetados pela Nvidia para acompanhar essa velocidade podem ser um bom complemento para fechar essa lacuna

  • O texto original diz que, até agora, para alcançar esse tipo de velocidade era necessário hardware especial e muito caro, como o da Cerebras.
    A novidade deste resultado é ter passado de 1000 token/s em um modelo com mais de 1 trilhão de parâmetros usando apenas hardware padrão, ou seja, um único servidor com 8 GPUs
  • Queria saber a fonte. No site da Cerebras aparece 1000t/s https://www.cerebras.ai/blog/which-is-faster-gemini-3-5-flas...
  • A Cerebras teve sorte de abrir capital no mês passado. Se fosse agora, seria diferente
  • A Cerebras atualmente não oferece desconto de prefix caching, então, em cargas de trabalho com agentes, o custo de uso fica sqr(n_turns) vezes mais caro

• Interessante. Os modelos de fronteira ficaram bem impressionantes, mas ainda são um pouco lentos para codificação interativa com humano no loop. Então isso acaba empurrando na direção de vibe coding e de executar vários agentes em paralelo. Um agente rápido parece mais um parceiro
  Por um tempo usei o Cerebras GLM 4.7 em várias tarefas. Não é um modelo muito inteligente, mas a experiência de deixar um protótipo ao vivo do site aberto e digitar “aumenta um pouco a fonte. Não, não tanto assim” e ver tudo mudar em tempo real é excelente. E o MiMo 2.5 é muito mais capaz que o GLM 4.7

  • Testei o GLM 4.7 como agente de escrita de código, e ele foi extremamente ruim até em scripts simples de 200 a 1000 linhas. Tive que desistir dos modelos oferecidos pela Cerebras, e os modelos inteligentes só estão no plano enterprise
  • O MiMo 2.5 não é o mesmo modelo que o MiMo 2.5 Pro
    O GLM 5.1 é a iteração mais recente da z.ai e um dos modelos de código com pesos abertos mais populares. Se você já usou, fico curioso para saber como o GLM 5.1 se compara ao MiMo 2.5 Pro, que ainda ficou mais barato depois do corte recente de 70% no preço

• 1k TPS é excelente, mas o mais interessante é quantos comentários gerados por IA existem nesta thread