LLMs de 1000 TPS e o novo ritmo dos agentes no telefone

Velocidade não é o agente inteiro

LLMs de 1000 TPS para agentes de telefone chamam atenção porque atacam uma dor real: espera. Quando um agente precisa entender uma intenção, planejar passos, revisar contexto e responder ao usuário, cada segundo de latência muda a sensação de controle. Em uma conversa simples, esperar pode ser apenas incômodo. Em uma sequência de ações no celular, esperar demais quebra o fluxo: o usuário perde confiança, troca de app ou decide fazer tudo manualmente.

Mas velocidade de tokens não é a mesma coisa que um agente completo. Um modelo pode responder muito rápido e ainda assim não saber se a mensagem deve ser enviada, se a rota correta foi escolhida, se o app aceita aquela ação ou se o usuário precisa confirmar antes de continuar. A qualidade de um agente de telefone depende de raciocínio, ferramentas, permissões, revisão do resultado e capacidade de concluir ou recuar com segurança.

Por isso, a pergunta prática não é “1000 tokens/s substituem a camada de ação?”. A resposta é não. A pergunta útil é: o que fica melhor quando o raciocínio acontece quase em tempo real? Em tarefas como triagem de mensagens, navegação, planejamento de agenda e limpeza de notificações, um modelo mais rápido pode reduzir microesperas e permitir ciclos menores entre planejar, agir e checar.

Na FoneClaw, tratamos velocidade como uma força a montante. Ela pode melhorar a parte de compreensão e planejamento, mas não substitui o trabalho de um agente de IA no Android que precisa respeitar permissões, ações suportadas e confirmação visível.

O que o MiMo UltraSpeed realmente prova

O sinal de mercado mais concreto aqui vem do MiMo-V2.5-Pro-UltraSpeed. Na página oficial da Xiaomi MiMo, verificada em 2026-07-15, a Xiaomi descreve o UltraSpeed como um modo de experiência do MiMo-V2.5-Pro, um modelo flagship de 1T. Segundo a Xiaomi, a velocidade máxima de inferência ultrapassa 1000 tokens/s, com saída na faixa de 500 a 1000 TPS, em comparação com 50 a 100 TPS para o MiMo-V2.5-Pro. Esses são claims da Xiaomi, não uma verificação independente de benchmark.

A mesma página oficial lista entrada e saída de texto, chamada de ferramentas, streaming e suporte a cache. Também posiciona cenários como trading quantitativo, controle de risco em tempo real, pesquisa científica e assistência de programação em tempo real. Isso importa porque mostra a direção: modelos rápidos não são apenas para respostas curtas; eles são pensados para ambientes em que atraso acumulado atrapalha decisão e acompanhamento.

Ao mesmo tempo, esse tipo de anúncio não deve virar ranking universal de modelos. Ele não prova que todo phone agent terá 1000 TPS, não prova que FoneClaw usa MiMo e não prova que velocidade resolve automação em apps. Para um contexto mais amplo sobre modelos, sem transformar esta página em lista de fornecedores, veja MiMo V2.5 Pro UltraSpeed.

O que o MiMo UltraSpeed prova, com cuidado, é que inferência rápida virou uma variável séria de produto. Se o raciocínio do agente deixa de ser o gargalo principal, o próximo gargalo aparece com mais clareza: executar ações reais com segurança.

Por que latência pesa mais em tarefas longas

Em um chat de pergunta e resposta, latência aparece como tempo até a primeira resposta. Em um agente de telefone, ela se acumula. Imagine uma rotina simples: ler notificações importantes, resumir duas mensagens, sugerir uma resposta, checar o calendário, abrir uma rota e lembrar o usuário de sair em vinte minutos. Cada etapa tem raciocínio, ação ou checagem. Se cada ciclo demora vários segundos, a tarefa deixa de parecer assistência e passa a parecer espera assistida.

É por isso que a inferência rápida muda mais as tarefas longas do que as respostas isoladas. Um modelo que responde rápido pode confirmar pequenos detalhes sem interromper o usuário: “qual contato?”, “essa é a rota certa?”, “quer enviar agora ou só deixar pronto?”. Quando o tempo de resposta é baixo, o agente consegue fazer perguntas curtas e úteis sem transformar a experiência em interrogatório lento.

Em tarefas como organizar mensagens, revisar lembretes ou limpar notificações, a vantagem não é apenas velocidade bruta. É a possibilidade de usar loops menores: planejar uma etapa, mostrar resultado, corrigir, seguir. Esse ritmo aumenta a sensação de controle porque o usuário não precisa esperar uma grande decisão opaca. Ele vê progresso em partes.

Ainda assim, latência baixa não autoriza automação cega. Um agente rápido pode errar rápido. Se ele escolhe o contato errado, interpreta mal uma notificação ou prepara uma ação sensível sem revisão, a velocidade amplifica o problema. Para tarefas longas, o ganho real vem quando a inferência rápida combina com verificações frequentes, escopo claro e interrupções humanas no momento certo.

O ciclo entre modelo rápido e modelo profundo

Uma arquitetura útil para agentes combina respostas rápidas com decisões mais profundas. Em vez de usar sempre o mesmo modelo para tudo, o sistema pode usar um componente leve para checagens imediatas e um raciocínio mais robusto para decisões difíceis. Não estamos descrevendo uma implementação interna específica da FoneClaw; estamos falando de um padrão de design que faz sentido quando latência vira parte central da experiência.

O modelo rápido pode lidar com triagem, reformulação, detecção de intenção simples, pequenas confirmações e continuidade de conversa. Ele mantém a experiência viva. O modelo mais profundo pode entrar quando há ambiguidade, conflito de contexto, tarefa longa ou consequência importante. Em uma conversa em tempo real, isso evita dois extremos: respostas lentas para tudo ou decisões apressadas para coisas difíceis.

Para agentes de telefone, essa divisão é especialmente útil. Uma notificação pode ser classificada rapidamente, mas uma resposta sensível precisa de revisão. Uma rota pode ser aberta com baixa fricção, mas compartilhar localização exige mais cuidado. Um lembrete simples pode ser preparado na hora, enquanto uma sequência que mistura agenda, mensagem e app de mapa talvez precise de raciocínio mais completo.

O ponto é que arquitetura importa tanto quanto TPS. Uma inferência rápida mal orquestrada pode virar ruído: respostas demais, interrupções demais, tentativas demais. Um sistema bem desenhado usa velocidade para reduzir espera e usa raciocínio profundo quando a tarefa exige. O usuário não deveria sentir a arquitetura; deveria sentir que o agente responde no ritmo certo e sabe quando desacelerar.

Por que ações no telefone ainda precisam de uma camada de ação

Raciocinar sobre uma tarefa e agir no telefone são coisas diferentes. O modelo pode entender que o usuário quer responder a uma mensagem, criar um lembrete ou abrir uma rota. Mas o telefone ainda precisa lidar com permissões, apps, telas, notificações, políticas do sistema e confirmação humana. Um LLM rápido pode dizer o que fazer; a camada de ação decide como, quando e se aquilo pode ser feito com segurança.

Esse limite aparece em tarefas comuns. Preparar uma mensagem não é o mesmo que enviá-la. Abrir um app de mapa não é o mesmo que compartilhar localização. Sugerir uma configuração não é o mesmo que alterá-la. Quando a ação toca contatos, dados pessoais, localização ou apps de terceiros, o usuário precisa ver o resultado e aprovar o que importa. A velocidade do modelo reduz espera, mas não elimina responsabilidade.

Na FoneClaw, focamos ações Android suportadas. Isso significa que não prometemos qualquer app, qualquer dispositivo ou controle total do sistema. Nosso trabalho é transformar intenção em passos visíveis quando há suporte, permissão e contexto suficiente. Se a ação não é segura ou não está disponível, o fallback deve ser parte do fluxo: abrir a tela correta, explicar o limite ou pedir intervenção manual.

Essa separação evita confundir o avanço dos modelos com uma solução completa de telefone. Para entender por que o smartphone se tornou o lugar onde contexto, permissões e ações no telefone se encontram, há um guia próprio. Aqui, a conclusão é mais estreita: 1000 TPS melhora o raciocínio, mas a execução confiável ainda precisa de produto.

Como usamos essa lição na FoneClaw

Na FoneClaw, lemos a tendência de inferência rápida como uma mudança importante, mas não como substituição do nosso papel. Modelos mais rápidos fortalecem a camada de raciocínio: entendem instruções com menos espera, acompanham tarefas longas com mais fluidez e tornam conversas de correção mais naturais. Isso é bom para qualquer agente de telefone. Mas a parte que define confiança continua sendo o que acontece depois do raciocínio.

Esse avanço já tem um uso prático na FoneClaw. A FoneClaw obteve acesso interno de teste ao MiMo V2.5 Pro UltraSpeed e está usando esse modelo de classe 1T, com pico acima de 1000 TPS segundo a Xiaomi, para melhorar a experiência do produto. Em fluxos de agente no telefone, o ganho não é uma velocidade abstrata: é entender a intenção mais rápido, revisar etapas com menos espera e responder com mais agilidade em ações compatíveis do Android.

Nosso papel é construir a ponte entre intenção e ação Android compatível. Quando o usuário pede uma tarefa, o sistema precisa decidir se há suporte, qual permissão está envolvida, que resultado deve ser mostrado e onde a confirmação é necessária. Se um modelo rápido ajuda a identificar isso em menos tempo, melhor. Mas nós não transformamos velocidade em licença para agir sem visibilidade.

Também não afirmamos usar MiMo, alcançar 1000 TPS ou controlar todos os apps. Esse cuidado é essencial porque números grandes chamam atenção e podem criar expectativas erradas. O usuário não precisa apenas de uma resposta rápida; ele precisa de uma ação correta, revisável e segura. Em alguns casos, o melhor agente é aquele que responde rápido. Em outros, é aquele que sabe parar.

A lição prática é esta: a próxima era dos agentes de telefone não será definida só por modelos mais velozes. Ela será definida pela combinação entre inferência rápida, planejamento confiável, permissões claras e execução visível. É nessa combinação que trabalhamos na FoneClaw: usar avanços de modelo como energia para uma experiência Android mais fluida, sem abrir mão dos limites que tornam a ação confiável.