Otimização de LLM no dispositivo para agentes de celular

Latência percebida vale mais que benchmark isolado

Um agente no celular é julgado em momentos pequenos. O usuário pede para responder uma mensagem, abrir um app, resumir uma notificação ou preparar uma rota. Se a resposta demora, se a bateria cai rápido ou se a tela fica em um estado confuso, o número de benchmark perde importância. A experiência boa parece imediata, compreensível e reversível.

É por isso que a otimização de LLM no dispositivo para agentes de celular começa pela latência percebida. Não basta gerar tokens rápido em laboratório. O telefone precisa carregar o modelo, entender o pedido, manter memória suficiente para o app aberto, respeitar permissões, mostrar o resultado e permitir confirmação quando a ação mexe com mensagem, conta, localização ou dado sensível.

A página de Gemini Nano no Android Developers apresenta Gemini Nano via Android AICore como caminho para IA generativa no dispositivo, com baixa latência de inferência, casos de uso voltados a privacidade e experiências sem rede quando o recurso e o aparelho oferecem suporte. Para um agente de telefone, isso aponta para uma regra prática: local ajuda muito quando a tarefa é curta, frequente e ligada ao contexto imediato.

A resposta também precisa aparecer na interface. Na FoneClaw, uma ação útil termina em algo visível: app aberto, rascunho preparado, lembrete criado, tela de confirmação pronta, resumo mostrado. Otimização local melhora a sensação de continuidade, mas a parte decisiva continua sendo o caminho entre intenção e ação Android compatível.

Esse tema se conecta ao nosso guia de controle do celular por agente de IA. Aqui, o foco é mais técnico: por que tamanho de modelo, memória, aquecimento, cache, quotas e escolha entre local e nuvem afetam o fluxo que o usuário sente na mão.

Tamanho do modelo, quantização e modelos menores no telefone

Um telefone não é um servidor com energia e refrigeração generosas. Ele precisa dividir recursos entre tela, rádio, câmera, notificações, apps, sensores e bateria. Por isso, o modelo certo para um agente no celular muitas vezes é menor, especializado e bem integrado, em vez de simplesmente o maior modelo disponível.

Modelos menores ajudam em tarefas como classificar uma intenção, resumir texto curto, preparar resposta, extrair entidade, sugerir próximo passo ou decidir se vale acionar outro recurso. Quantização reduz o peso numérico do modelo para economizar memória e processamento. Adaptadores podem recuperar qualidade ou especializar comportamento sem trocar tudo. Em linguagem simples: o telefone tenta carregar menos peso para responder mais rápido.

A Apple descreve um caminho parecido em sua pesquisa sobre atualizações dos modelos Foundation, incluindo modelo compacto no dispositivo, modelo de servidor, quantização, adaptadores e otimizações de cache. A direção é relevante para todo o setor: tarefas locais precisam equilibrar qualidade, latência, memória e energia.

No Android, esse raciocínio aparece em rotas de modelo pequeno e recursos de disponibilidade por dispositivo. A Prompt API do ML Kit GenAI trabalha com dispositivos Android compatíveis, checagem de disponibilidade, download de Gemini Nano, aquecimento para reduzir latência da primeira chamada, limites de tokens e quota por app. Isso mostra que a experiência local é prática, mas precisa ser planejada como recurso de produto, com limites claros no app.

Na FoneClaw, esse equilíbrio importa porque ações de telefone são curtas e concretas. Abrir o app certo, preparar uma frase, organizar uma notificação ou criar lembrete não precisa sempre de raciocínio pesado. O produto melhora quando usa a capacidade adequada para a tarefa e entrega uma próxima etapa visível.

AICore, Gemini Nano, ML Kit GenAI, LiteRT e LiteRT-LM no Android

O termo LLM móvel fica abstrato até aparecer como caminho real de execução no aparelho. No Android, há várias rotas que tornam IA local e híbrida mais prática: AICore com Gemini Nano, APIs de alto nível como ML Kit GenAI, ferramentas do Google AI Edge, LiteRT e LiteRT-LM para modelos locais.

AICore é importante porque oferece uma forma do Android disponibilizar capacidades de IA generativa no dispositivo para apps compatíveis. Gemini Nano roda por esse caminho em aparelhos suportados. Isso ajuda em tarefas de texto, resumo, reescrita ou compreensão curta quando o recurso está disponível no dispositivo.

ML Kit GenAI simplifica outra parte da experiência: verificar se o recurso está disponível, gerenciar download, aquecer o modelo antes da primeira chamada e lidar com limites de uso. Para um app de agente, isso evita tratar IA local como mágica. O app precisa saber quando o recurso está pronto, quando precisa baixar algo, quando atingiu limite e quando deve oferecer um caminho alternativo.

O Google AI Edge apresenta ferramentas para machine learning e IA no dispositivo em diferentes plataformas, incluindo APIs de tarefas, LiteRT e LiteRT-LM. O LiteRT-LM foca LLMs locais e exemplos com execução offline, CPU/GPU, memória e métricas como prefill, decode e time to first token.

A Apple também abriu um caminho de app com o Foundation Models framework, que expõe modelo de linguagem no dispositivo para tarefas de Apple Intelligence, saída estruturada e uso de ferramentas dentro de apps. Mesmo em outro ecossistema, o sinal é o mesmo: a IA local precisa de APIs estáveis, limites claros e integração direta com a experiência do app.

Para FoneClaw, runtime é produto sentido pelo usuário. Se a base local responde rápido, podemos preparar ações Android com menos espera. Se a disponibilidade muda por aparelho, versão ou quota, o fluxo precisa mostrar fallback: usar uma rota mais simples, pedir confirmação, abrir app ou salvar lembrete.

Cache, aquecimento, contexto e velocidade em fluxos repetidos

Muitas tarefas de telefone se repetem. Resumir notificações, preparar resposta, identificar contato, abrir rota, organizar lembretes. O usuário não percebe nomes técnicos como prefill, decode ou KV cache, mas percebe quando a segunda ação é mais rápida que a primeira.

Prefill é a etapa de processar o texto de entrada e contexto antes de gerar resposta. Decode é a geração token a token. Time to first token mede quando a primeira parte da resposta aparece. Warmup, ou aquecimento, prepara o modelo antes da primeira chamada real. KV cache guarda partes úteis do processamento para acelerar continuação ou reduzir trabalho repetido.

O LiteRT-LM coloca essas dimensões em primeiro plano ao tratar desempenho de LLM local: prefill, decode, time to first token, backends de CPU/GPU, memória e execução offline. Para um agente de celular, isso ajuda a responder uma pergunta prática: o usuário verá algo rápido o bastante para confiar no fluxo?

A Apple também destaca otimizações envolvendo compartilhamento de KV cache e redução de memória em seus modelos no dispositivo. Esse tipo de melhoria mostra por que cache não é detalhe acadêmico; ele afeta consumo de memória, primeira resposta e capacidade de manter contexto maior sem travar a experiência.

Na FoneClaw, pensamos cache e aquecimento como parte da rotina. Se o usuário pede todos os dias um resumo de mensagens pela manhã, o sistema deve chegar rápido a uma estrutura conhecida. Se ele costuma preparar respostas curtas, a interface deve abrir com menos passos. Se o contexto é sensível ou longo, a confirmação e o fallback continuam visíveis.

O tamanho do contexto também precisa de bom senso. Quanto mais informação o modelo recebe, maior o custo de processar. Em um telefone, o agente deve usar o contexto necessário para a próxima ação, não tentar carregar a vida inteira do usuário em toda chamada. Isso melhora velocidade, bateria e clareza.

Quando rodar localmente e quando usar raciocínio em nuvem

Inferência local é ótima para ações rápidas, repetitivas e próximas do aparelho: resumir texto curto visível, classificar notificação, preparar frase, extrair horário, sugerir lembrete ou entender comando de voz simples. Raciocínio em nuvem continua útil para tarefas mais longas, conhecimento amplo, planejamento complexo, análise pesada e contexto que exige modelos maiores.

A experiência ideal combina os dois caminhos de forma transparente para o usuário. Local quando basta; nuvem quando agrega qualidade; sempre com interface clara. Esse debate é explorado de forma mais ampla em agente de IA local versus nuvem. Neste artigo, o foco é otimização: como escolher a rota certa ajuda latência, quota, bateria e recuperação de interface.

Em um agente de telefone, o roteamento também depende de permissão e ação final. Preparar rascunho local pode ser suficiente; enviar a mensagem pede confirmação. Resumir notificações pode rodar no aparelho; interpretar um documento grande pode exigir outra rota. Abrir app e mostrar tela é uma ação Android visível; alterar algo em conta ou pagamento pede cuidado maior.

Na FoneClaw, conectamos esse raciocínio a ações compatíveis no Android. O usuário não precisa pensar em modelo local ou nuvem a cada pedido. Ele precisa ver a próxima etapa: rascunho, app, lembrete, resumo, confirmação ou fallback. Nosso produto usa a rota adequada para manter o fluxo útil e compreensível.

Também há quota e bateria. Um recurso local pode ter limite por app, token ou dispositivo. Uma chamada em nuvem pode depender de rede e política do provedor. Um fluxo bem desenhado reconhece essas condições e oferece caminho prático: reduzir contexto, dividir tarefa, salvar lembrete ou abrir app para ação manual.

O resultado bom não é uma disputa ideológica entre local e nuvem. É uma experiência em que o telefone responde rápido quando pode, raciocina mais fundo quando precisa e mostra ao usuário o que será feito antes de concluir ações importantes.

Checklist para avaliar LLM no dispositivo em um telefone

Ao avaliar uma função de IA local em um telefone, olhe além do nome do modelo. O que importa é a experiência: suporte do aparelho, comportamento sem rede, privacidade, latência, quota, bateria, recuperação de tela e fallback quando a ação não cabe no caminho local.

• Suporte do dispositivo: verifique se o recurso funciona no modelo, região, idioma e versão do Android.
• Disponibilidade: veja se o app checa suporte, baixa modelo e informa quando a função está pronta.
• Primeira resposta: observe se há aquecimento ou atraso inicial antes do primeiro uso.
• Memória e bateria: teste se o telefone aquece, fecha apps ou consome energia demais.
• Privacidade: entenda quais partes rodam no aparelho e quais usam rede.
• Quota e limites: procure limites de tokens, chamadas por app ou recursos por sessão.
• Interface: confirme se o resultado aparece como ação visível, não apenas texto solto.
• Fallback: veja se o app oferece rota alternativa quando a IA local não está pronta.

Para agentes de sistema e apps, também vale entender a arquitetura maior. O guia sobre base de três camadas do agente de sistema cobre o encaixe entre modelo, sistema e ação. A otimização de LLM no dispositivo é uma peça importante, mas a experiência final depende da ligação com permissões, apps e confirmações.

Na FoneClaw, avaliamos IA local pelo que ela permite fazer no telefone real: abrir app, resumir, preparar texto, checar estado visível, criar lembrete e deixar o usuário confirmar. Uma melhoria de cache ou quantização só importa quando reduz atrito nessa sequência.

O caminho de 2026 é híbrido, prático e orientado ao usuário. Modelos menores ajudam no imediato; modelos maiores ajudam no complexo; runtimes móveis tornam o local viável; e o produto precisa transformar tudo isso em ações Android confiáveis. Essa é a diferença entre ter um LLM no aparelho e ter um agente de celular que realmente ajuda.