Pra mim, frameworks de inferência no browser evoluíram mais rápido do que a maioria dos times de frontend percebeu. O WebGPU atingiu suporte padrão em Chrome, Firefox, Edge e Safari, cobrindo mais de 70% dos browsers ativos, e eliminou a barreira que manteve a inferência local como experimento durante anos. Transformers.js v4, biblioteca de inferência de modelos no browser da Hugging Face lançada em fevereiro de 2026, roda Llama 3.2 3B a cerca de 60 tokens por segundo em hardware com chip M4 Pro Max. WebLLM, runtime de inferência de LLMs no browser, executa Llama 3.1 8B quantizado a 4 bits a 41 tokens por segundo em um M3 Max dentro de uma aba do Chrome, atingindo entre 71% e 80% da velocidade nativa. Na minha avaliação, a mudança de viabilidade torna necessário separar os casos onde a inferência local resolve um problema real dos casos onde ela existe pra cumprir uma narrativa de produto.
O mecanismo que viabiliza a inferência no browser opera em duas camadas. A primeira é o WebGPU, que expõe acesso direto à GPU do dispositivo com desempenho 3 a 5 vezes superior ao WebGL em modelos transformer e 10 a 15 vezes superior ao WebAssembly puro no mesmo workload. A segunda é a quantização, que comprime os pesos do modelo de float32 para int4, reduzindo o footprint de memória em até 75% e tornando modelos de 8 bilhões de parâmetros executáveis em hardware de consumo. ONNX Runtime Web, engine de inferência cross-platform da Microsoft, suporta conversão direta de PyTorch, TensorFlow e HuggingFace para o formato ONNX com backend WebGPU, o que elimina boa parte do atrito de integração. Na minha análise, funcionar e ser adequado em produção continuam sendo condições distintas.
Os casos onde a inferência local resolve um problema estrutural compartilham uma propriedade comum: ou o dado não deve sair do dispositivo, ou a latência de rede é inaceitável quando a conectividade é intermitente. Classificação de sentimento em texto digitado pelo usuário, detecção de objetos em imagens capturadas pela câmera, autocompleção com modelos pequenos, validação semântica de formulários, análise de toxicidade em tempo real antes do envio: essas tarefas operam sobre inputs de tamanho limitado, com latência abaixo de 100 milissegundos, em cima de dados que o usuário pode preferir que não trafeguem pra um servidor. Um modelo BERT quantizado pra classificação de sentimento ocupa entre 30 e 80 megabytes e executa inferência em milissegundos. A Hugging Face recomenda modelos abaixo de 2 bilhões de parâmetros pra compatibilidade ampla entre dispositivos, o que basta pra classificação, embedding e extração de entidades. Nesse segmento, a inferência local opera como a arquitetura correta, porque resolve o problema sem introduzir dependência de rede.
O ponto de degradação aparece quando o modelo excede a capacidade do dispositivo médio do público-alvo, e esse ponto é mais baixo do que os benchmarks sugerem. Os 60 tokens por segundo em Llama 3.2 3B foram obtidos em um M4 Pro Max, topo da curva de hardware de consumo. Um laptop com GPU integrada Intel ou AMD produz entre 2 e 5 tokens por segundo via WebAssembly pro mesmo modelo, e o fallback pra CPU transforma a experiência em algo inutilizável pra qualquer tarefa interativa. O ArrayBuffer do JavaScript tem limite prático de 2 gigabytes e o WebGPU impõe limites de buffer que variam por plataforma: Safari limita a 256 megabytes em iPhones antigos e 993 megabytes em iPads recentes, e o Chrome frequentemente limita maxStorageBufferBindingSize a 128 megabytes independente do que o hardware reporta. O download inicial é outro fator: um modelo de 8 bilhões de parâmetros quantizado a 4 bits ocupa entre 4 e 5 gigabytes, ou seja, o primeiro acesso do usuário envolve um download do tamanho de um jogo mobile inteiro antes de qualquer inferência. Pra mim, aplicações que fazem o usuário esperar 30 segundos a 2 minutos pra baixar um modelo antes de poder usar uma feature estão tratando a inferência local como demonstração técnica.
Na minha avaliação, o trade-off entre privacidade e capacidade é estrutural e não se resolve no plano discursivo. A inferência local garante que o dado não sai do dispositivo, mas restringe a capacidade do modelo ao hardware do cliente, que é heterogêneo e está fora do controle do desenvolvedor. A inferência no servidor permite modelos maiores com latência consistente, mas exige que o dado trafegue pela rede. A decisão depende do que o dado é e do que a tarefa exige. Dados biométricos, conteúdo médico, inputs financeiros pessoais: a inferência local é uma exigência funcional. Geração de texto longo, sumarização de documentos complexos, reasoning multi-step: a inferência local no browser produz resultados inferiores em hardware médio, com latência e consumo de memória que degradam a experiência.
O efeito de segunda ordem é que a disponibilidade de frameworks como Transformers.js v4, WebLLM e ONNX Runtime Web criou uma pressão de adoção que precede a existência de casos de uso legítimos em muitos produtos. Pra mim, a pergunta operacional que separa uso legítimo de teatro é se a remoção da inferência local degradaria a experiência ou apenas removeria uma demonstração de capacidade. Quando o servidor faz o mesmo trabalho com latência aceitável, sem forçar o dispositivo a alocar gigabytes de memória, a inferência local é uma decisão de marketing vestida de decisão de engenharia. O frontend ganhou capacidade de inferência real, com aplicações concretas em privacidade, offline-first e classificação leve, mas a linha entre capacidade e adequação continua sendo definida pela combinação de hardware do usuário, tamanho do modelo e honestidade sobre o que o problema exige.