LiteRT.js: rodar IA local no navegador com uma alternativa clara

O LiteRT.js é a interface do Google para executar inferência de inteligência artificial (IA) no navegador. Ele pode usar WebAssembly na unidade central de processamento (CPU) e WebGPU quando existe aceleração compatível. O design precisa considerar desde o início os dispositivos que não cobrem o caminho preferido.

O caso prático vai avaliar a qualidade de uma foto antes do upload. O modelo local detectará desfoque ou exposição ruim e mostrará uma recomendação. Se o navegador não conseguir executar o modelo, o aplicativo explicará o limite e oferecerá outro caminho.

O LiteRT.js leva o modelo ao dispositivo

Em 15 de julho de 2026, o Google documentava o LiteRT.js como um ambiente web para carregar e executar modelos compatíveis. O guia de início mostra uma API de carga e compilação e um caminho acelerado com WebGPU. A compatibilidade real depende do navegador, do hardware e do modelo.

Executar no dispositivo pode reduzir viagens de rede durante a inferência. Também permite respostas mesmo quando a conexão está instável, desde que o aplicativo e o modelo já estejam disponíveis. Isso não elimina o custo de download, compilação e memória.

Antes de escolher, defina o que ele acrescenta ao caso da fotografia. Um aviso imediato antes do upload pode poupar um envio inútil e manter a imagem fora do servidor. Essa vantagem só existe se as demais partes da página também não transmitirem a foto.

A detecção vem antes do download

Verifique as capacidades antes de baixar um modelo grande. Detecte as APIs necessárias, registre a memória disponível quando possível e considere o tipo de dispositivo. A interface precisa continuar utilizável enquanto o caminho é decidido.

Para a foto, mostre primeiro o seletor e uma explicação curta. Se o navegador cumprir as condições, inicie o carregamento do modelo com progresso visível. Se não, ofereça uma avaliação remota opcional ou permita continuar sem análise.

Não use uma detecção baseada só no nome do navegador. Versões, drivers e políticas podem variar dentro da mesma família. Execute um teste de capacidade e capture o erro de inicialização.

O carregamento precisa de estados e limites claros

O modelo acrescenta bytes, tempo de partida e memória ao percurso. Informe que a análise local está sendo preparada e permita cancelar quando o download demorar. Guarde em cache só se a política do produto e o armazenamento disponível permitirem.

Uma barra cheia não prova que o modelo está pronto. Distinga download, compilação e primeira inferência. Para o caso prático, habilite «Analisar foto» depois de confirmar que o caminho local responde a uma entrada de teste.

Defina um tempo máximo e uma recuperação. Se a compilação falhar, libere recursos e ative a alternativa. Um laço silencioso de novas tentativas consome bateria e deixa a pessoa sem uma decisão.

A qualidade deve ser medida com fotos representativas

Prepare imagens de teste com boa qualidade, desfoque, pouca luz e tamanhos diferentes. Compare a saída do modelo com uma classificação revisada e registre os erros relevantes. Uma demonstração com uma única foto não permite avaliar o comportamento.

Meça também o tempo até o primeiro resultado, a latência seguinte, a memória e a temperatura percebida em sessões longas. Inclua celulares intermediários, um equipamento sem WebGPU e navegadores representativos. Os benchmarks do fornecedor servem como referência, não como aceitação do seu produto.

Se a análise concluir que a foto está tremida, explique a ação: estabilizar o dispositivo, melhorar a luz ou repetir a captura. Uma pontuação sem contexto não ajuda. O guia de prompts aplica o mesmo princípio de resultado verificável.

A privacidade depende de todo o percurso

A inferência local descreve onde o modelo roda, não tudo o que o aplicativo faz. Analytics, registros de erro, armazenamento, miniaturas ou serviços de backup podem enviar dados. Documente cada saída de rede antes de afirmar que a imagem permanece no dispositivo.

Inspecione a rede durante seleção, análise e descarte. Repita o teste com a alternativa remota e mostre um pedido de consentimento antes do upload. O texto precisa diferenciar com clareza os dois caminhos.

Evite registrar a imagem, o conteúdo extraído dela ou identificadores desnecessários. Se precisar de telemetria, meça tempos e códigos de estado sem anexar dados pessoais. A pessoa precisa conseguir continuar quando recusa a alternativa.

A alternativa faz parte do produto

Um caminho alternativo não é um erro vergonhoso que deva ser escondido. Explique que a análise local não está disponível naquele dispositivo e ofereça opções concretas: continuar sem avaliação, usar um servidor com consentimento ou testar outra imagem. Preserve a função principal sempre que for seguro.

A alternativa remota precisa das próprias regras de retenção, acesso e exclusão. Não a ative em segundo plano. A abordagem responsável de vibe coding exige testar tanto o caminho principal quanto o degradado.

Registre quantas sessões usam cada caminho e por que o local falha. Essa evidência permite decidir se convém trocar o modelo, reduzir o tamanho dele ou retirar uma função. Não transforme o percentual numa promessa sem data e sem amostra representativa.

Os limites aparecem em download, memória e compatibilidade

Um modelo pode ser grande demais para uma conexão móvel ou esgotar a memória durante várias inferências. O WebGPU pode existir e ainda assim falhar ao compilar uma operação. Capture os dois casos e restaure a interface.

A qualidade também pode variar entre grupos de imagens que não estavam na avaliação. Revise iluminação, dispositivos e contextos diversos. Um resultado local incorreto continua sendo um resultado incorreto.

Por fim, o navegador compartilha recursos com o resto da página. Evite executar várias inferências simultâneas e libere tensores ou sessões que já não usa. Uma interface fluida importa tanto quanto o número isolado de inferência.

Confira a experiência antes de publicá-la

Percorra estas caixas em vários dispositivos. Cada resposta precisa se apoiar numa medição, numa inspeção de rede ou num comportamento visível.

• O aplicativo detecta capacidades antes de baixar o modelo.
• Carga, compilação, execução e erro têm estados compreensíveis.
• As fotos de teste cobrem qualidade, tamanhos e dispositivos diferentes.
• Todo o percurso dos dados, inclusive a telemetria, está documentado.
• A alternativa remota exige informação e consentimento explícitos.
• Uma falha libera recursos e permite continuar de forma segura.

O LiteRT.js abre um caminho útil para IA local, mas a arquitetura confiável inclui também o dispositivo que não consegue usá-la. Detecte, carregue, execute, meça e ative uma alternativa declarada. Essa sequência transforma uma demonstração numa função sustentável.