IA no navegador não elimina o backend: ela muda o orçamento do produto

Imagine uma funcionalidade que analisa uma imagem enviada pelo usuário. No protótipo, o frontend manda o arquivo para uma API, espera a inferência e recebe o resultado. Funciona bem. Aí o uso cresce, a fatura acompanha e alguém sugere: "Vamos rodar o modelo no navegador e zerar esse custo".

A ideia parece ótima até colocar primeira carga, memória e variedade de dispositivos na conta.

Quando a inferência sai do servidor e vai para o navegador, uma parte do custo de infraestrutura realmente diminui. Em troca, o usuário passa a baixar o runtime e o modelo, reservar memória, gastar bateria e depender do hardware que tem. A equipe deixa de operar apenas uma infraestrutura relativamente previsível e passa a atender uma frota de notebooks e celulares bem diferentes entre si.

O custo não sumiu. Mudou de lugar.

O LiteRT.js torna essa conversa concreta. Ele permite executar modelos .tflite no browser, usando CPU por WASM/XNNPACK ou GPU por WebGPU. Há também um caminho experimental com WebNN. É uma caixa de ferramentas interessante para texto, visão e áudio, mas não é um botão de "remover backend".

A decisão útil é outra: qual parte do produto fica melhor no dispositivo do usuário, e qual parte ainda precisa do servidor?

A chamada de API some, mas a primeira visita fica mais cara

No fluxo com inferência remota, o navegador envia dados e espera uma resposta. O peso do modelo, a memória de execução e a maior parte do trabalho computacional ficam no servidor.

No fluxo local, o navegador precisa receber o código de execução e o modelo. A documentação do LiteRT.js deixa isso visível: a aplicação serve os arquivos WASM e busca o modelo por HTTP, ou carrega seus bytes como Uint8Array. Antes da primeira inferência, portanto, existe download, inicialização e alocação de memória.

A conta de desempenho, então, precisa começar antes da primeira inferência.

Não basta medir quanto uma inferência aquecida leva no notebook de quem desenvolveu a feature. O usuário percebe a experiência inteira:

tempo para baixar runtime e modelo;
tempo de inicialização;
latência da primeira inferência;
latência das execuções seguintes;
impacto na memória, bateria e temperatura.

Uma tarefa repetida muitas vezes na mesma sessão pode diluir o custo inicial. Uma tarefa usada uma vez e abandonada talvez nunca recupere esse investimento. Um modelo de 80 MB pode parecer aceitável no Wi-Fi do escritório e ser uma péssima primeira experiência numa conexão móvel instável.

Por isso, "rodou em 20 ms" é uma medida pequena demais para decidir a arquitetura.

WebGPU não é o seu piso de compatibilidade

O caminho mais rápido de uma demonstração costuma virar, sem querer, a expectativa de produção. Se o teste foi feito com WebGPU em uma máquina recente, é fácil começar a tratar esse resultado como característica do produto.

Só que o produto também precisa funcionar fora da máquina usada na demonstração.

O LiteRT.js aceita wasm, webgpu e webnn como aceleradores. Quando uma operação não tem suporte no caminho escolhido, ela pode cair para CPU. Esse fallback ajuda a manter a execução funcionando, mas pode mudar bastante a latência percebida. GPU, driver, throttling térmico e o próprio modelo também influenciam o resultado.

Para o frontend, fica um cuidado importante: fallback técnico não é sinônimo de experiência equivalente.

Se uma análise leva meio segundo com WebGPU e vários segundos na CPU, os dois caminhos "funcionam", mas talvez precisem de interfaces diferentes. No caminho lento, pode fazer sentido exibir progresso, permitir cancelamento ou oferecer processamento remoto. Esconder a diferença só entrega uma tela que parece travada para parte dos usuários.

O dispositivo mais forte prova que a ideia é possível. O dispositivo mais fraco que você pretende atender ajuda a dizer se ela cabe no produto.

Processamento local não garante privacidade sozinho

Manter uma imagem, um áudio ou um texto no dispositivo pode reduzir o envio de dados sensíveis, especialmente quando a tarefa não precisa de sincronização.

Mas a frase "seus dados nunca saem do navegador" só é verdadeira se o fluxo inteiro respeitar essa promessa.

Vale conferir, por exemplo:

se o arquivo é enviado para telemetria ou diagnóstico;
se resultados intermediários entram em logs remotos;
se a aplicação sincroniza o conteúdo entre dispositivos;
se um fallback automático manda os dados ao servidor;
se ferramentas de monitoramento capturam payloads ou URLs com informação sensível.

Privacidade não vem do endereço onde a inferência roda. Vem do caminho completo percorrido pelo dado.

Uma arquitetura híbrida precisa deixar esse limite claro. Se o fallback remoto existe, o usuário deveria saber quando ele será usado, principalmente em fluxos que prometem processamento local.

O backend fica menor em alguns pontos, não desnecessário

Mesmo que toda a inferência de uma feature rode no navegador, ainda pode existir trabalho no servidor:

autenticar o usuário e aplicar limites do produto;
distribuir e versionar modelos;
sincronizar preferências ou resultados;
registrar métricas sem capturar conteúdo sensível;
oferecer fallback para dispositivos incompatíveis;
coordenar tarefas que dependem de dados protegidos;
atualizar regras sem esperar que todo cliente baixe a versão nova.

Também existe uma questão de controle. Um modelo entregue ao navegador pode ser inspecionado e copiado com mais facilidade do que um modelo mantido no servidor. Para alguns produtos isso não importa. Para outros, muda a decisão comercial e técnica.

O backend não precisa continuar fazendo tudo. Só não deve ser removido do desenho antes de a equipe listar o que ele ainda resolve.

Faça uma prova de conceito que possa contrariar a ideia

Uma boa prova de conceito não serve apenas para mostrar que o modelo roda. Ela também precisa revelar quando rodar no cliente não vale a pena naquele caso.

Eu começaria com uma tarefa pequena e delimitada, como classificar uma imagem ou gerar um embedding curto. Depois testaria o mesmo fluxo em pelo menos um notebook modesto e um celular intermediário. O equipamento do benchmark oficial pode continuar como referência, mas não como único retrato da base de usuários.

Registre estas medidas:

Medida	O que ela revela
tamanho do runtime e do modelo	custo de rede e armazenamento em cache
tempo até a primeira resposta	experiência de quem acabou de abrir a página
latência aquecida	custo das repetições na mesma sessão
pico de memória	risco de travamento e pressão sobre outras abas
consumo de bateria e aquecimento	viabilidade de sessões mais longas
taxa de falha por acelerador	cobertura real de WASM, WebGPU e WebNN
tempo no fallback para CPU	experiência fora do caminho mais rápido

Além das medidas, provoque o cenário ruim. Desative WebGPU, limite a rede, limpe o cache e repita a primeira carga. Troque de aba durante a execução. Rode a tarefa várias vezes no celular e observe temperatura e memória. Se houver fallback remoto, interrompa a rede no meio da transição.

Esses testes parecem menos empolgantes do que uma demo rápida. Em compensação, respondem às perguntas que aparecem depois do lançamento.

Compare as três rotas com o mesmo orçamento

Antes de escolher cliente, servidor ou híbrido, coloque as três opções na mesma planilha. Não precisa inventar precisão financeira. Basta usar variáveis que o time consegue medir.

Para o cliente, considere peso do download, taxa de cache reaproveitado, tempo de execução nos dispositivos atendidos e esforço de suporte por navegador. Para o servidor, estime chamadas por usuário, duração da inferência, transferência de dados e capacidade necessária nos picos. Na opção híbrida, some o custo de manter os dois caminhos e de explicar a transição entre eles.

A execução no cliente tende a fazer sentido quando a tarefa é pequena, repetida, sensível à latência e compatível com os dispositivos do público. O servidor continua forte quando o modelo é grande, precisa de atualização centralizada ou depende de hardware previsível. O híbrido ajuda quando a experiência local é valiosa, mas deixar parte da base sem saída não é aceitável.

Nenhuma dessas rotas vence por princípio.

Se o modelo local economiza chamadas, mas aumenta abandono na primeira visita, a economia saiu de uma linha da fatura e entrou na conversão. Se o servidor entrega boa experiência, mas o custo cresce mais rápido do que a receita, a arquitetura também não fechou. Se o híbrido cobre todo mundo, mas dobra a manutenção de uma feature pouco usada, talvez o produto esteja pagando por uma segurança que não precisa.

O lugar da inferência é uma decisão de produto

Com LiteRT.js, o frontend ganha opções que antes pediam mais trabalho de infraestrutura. Uma feature de visão, texto ou áudio pode responder sem viagem de rede, manter dados no dispositivo e reduzir parte do custo recorrente do servidor.

Mas o navegador não oferece computação grátis. Ele transfere trabalho para uma máquina que a equipe não controla e para uma conexão que nem sempre conhece.

Antes de mover a inferência, escolha uma tarefa estreita, meça a experiência completa e teste o fallback. Depois compare o custo técnico e financeiro das três rotas.

Se a decisão continuar boa no celular intermediário, sem WebGPU e depois de uma primeira carga fria, aí você tem algo mais valioso do que uma demo rápida: tem uma arquitetura que conhece o próprio orçamento.