Índice do artigofaltam 11 min de leitura
Rodar IA no navegador deixou de ser demonstração faz seis anos. O que mudou em 2026 foi o caminho: o PyTorch passou a compilar direto para a web, sem intermediário. O que não mudou é quem paga a conta, que continua sendo a máquina do usuário.
Existe uma conversa antiga sobre inferência no cliente que costuma travar no mesmo ponto: alguém mostra um LLM respondendo dentro de uma aba, a plateia acha impressionante, e a pergunta seguinte mata o assunto. Funciona no notebook de quem?
Este artigo responde essa pergunta com número. Ele reúne o que já roda em produção com base de usuário grande, mostra o que o ecossistema PyTorch ganhou este ano, e termina no piso de hardware que decide se a sua aplicação pode contar com isso ou não.
Resumo do artigo
- O efeito de fundo do Google Meet roda no cliente desde 2020, com um modelo de 400 KB e 70 quadros por segundo num notebook de 2018.
- O ExecuTorch ganhou um backend WebGPU que compila o mesmo grafo do PyTorch para o navegador via Emscripten, com benchmark oficial de julho de 2026.
- O navegador entrega de 71% a 80% do desempenho de decodificação da inferência nativa na mesma máquina, segundo o paper do WebLLM.
- Pela telemetria do Chrome, 31% dos usuários de Windows não têm GPU no nível exigido pelo WebGPU, o que torna o caminho de CPU obrigatório como plano B.
IA no navegador já é produção, e o caso mais antigo tem seis anos
O efeito de desfoque de fundo do Google Meet roda inteiro no computador do usuário, e é um dos poucos casos em que a empresa publicou o pipeline inteiro, com arquitetura, tamanho de modelo e latência medida. O time do Google Research publicou o pipeline completo em 2020: um modelo de segmentação de 193 mil parâmetros, com 400 KB depois da quantização em float16, executado em WebAssembly com SIMD e composto na tela via WebGL2.
Os números de desempenho explicam por que aquilo sobreviveu em produção. A inferência não é o gargalo, e a máquina antiga continua dando conta.
Fonte: Google Research, "Background Features in Google Meet, Powered by Web ML", 30/10/2020. As resoluções citadas no estudo, 256x144 e 160x96, são a entrada do modelo, não a do vídeo.
Vale uma precisão que costuma se perder na repetição: o que fica no cliente é o processamento do efeito, não o vídeo. Numa chamada, o stream naturalmente trafega para os outros participantes. O que o desenho evita é uma segunda viagem, a de mandar cada quadro para um servidor de inferência e esperar a máscara voltar.
O Meet não está sozinho. Em post do Google I/O de 2024, o time do Chrome lista o Photoshop para web da Adobe, que atribui explicitamente ao TensorFlow.js, além dos efeitos de realidade aumentada do YouTube e da edição do Google Photos como usos reais de computação pesada no cliente.
O ExecuTorch passou a compilar PyTorch direto para o navegador
O ExecuTorch, runtime de inferência local do PyTorch, ganhou um backend WebGPU que transforma subgrafos delegados em shaders WGSL e os executa via Dawn com o compilador Tint. A documentação oficial é direta sobre o alvo: as builds de navegador compilam o mesmo caminho de execução com Emscripten e emdawnwebgpu.
O detalhe de arquitetura que importa é a ausência de tradução. O mesmo arquivo .pte exportado do PyTorch alimenta tanto o runtime nativo, que desce para Metal ou Vulkan, quanto o runtime de navegador compilado para WebAssembly. Não há conversão para um formato de terceiro no meio do caminho.
O benchmark publicado no repositório mede um Llama 3.2 de 1 bilhão de parâmetros em 4 bits, e mostra o comportamento que todo mundo que trabalha com LLM reconhece: a velocidade cai conforme o contexto cresce.
Cair de 188 para 96 tokens por segundo quando o contexto vai de 128 para 8.192 é uma queda de quase metade, e ela precisa entrar no desenho da interface. Um assistente que acumula histórico longo fica visivelmente mais lento ao longo da sessão, e o usuário vai atribuir isso ao seu produto.
O benchmark vale para um M4 Pro no Chrome Canary, não para o parque do seu usuário
O próprio README registra três limites: os números descrevem aquele artefato e aquele aparelho, o backend está declarado em desenvolvimento ativo, e mais de cem operadores registrados não garantem que um modelo arbitrário rode de ponta a ponta. Ignorá-los é o jeito mais rápido de prometer o que não se entrega.
Um Apple M4 Pro no Chrome Canary é o topo do que existe em notebook, e o Canary não é o navegador do seu usuário. Tratar esse número como piso, e não como teto, é o erro que transforma prova de conceito em incidente de produção.
Três caminhos levam um modelo PyTorch até a aba do usuário
Os três caminhos são o ONNX Runtime Web, da Microsoft, o transformers.js, da Hugging Face, e o backend WebGPU do ExecuTorch. A escolha entre eles é menos sobre desempenho e mais sobre quanto do ecossistema você quer carregar junto: os dois primeiros têm adoção medida no registro npm, e o terceiro ainda é declarado pelo projeto como em desenvolvimento ativo.
| Critério | ONNX Runtime Web | transformers.js | ExecuTorch WebGPU |
|---|---|---|---|
| Como o modelo chega | Exportação para ONNX | Modelos prontos do Hub | Arquivo .pte do próprio PyTorch |
| Quem mantém | Microsoft | Hugging Face | Meta, dentro do PyTorch |
| Downloads npm por semana | 4,28 mi | 2,82 mi | Não distribuído por npm |
| Última versão publicada | 1.29.0, ago/2026 | 4.2.0, abr/2026 | Declarado em desenvolvimento ativo |
| Melhor quando | Você já tem pipeline ONNX | Quer o modelo funcionando hoje | Quer o mesmo grafo no app e na web |
Fontes: registro npm, downloads da semana de 23 a 29/08/2026; documentação oficial de cada projeto, leitura de 30/08/2026.
O transformers.js exige menos decisão prévia: pega modelos direto do Hub da Hugging Face e resolve a exportação por você. A versão 4, de março de 2026, trocou o runtime WebGPU por uma reimplementação em C++ feita junto com o time do ONNX Runtime, e passou a rodar modelos que antes não cabiam. O release cita um GPT-OSS de 20 bilhões de parâmetros a cerca de 60 tokens por segundo num M4 Pro Max.
O ExecuTorch ocupa outro lugar. Ele só ganha de verdade quando você já mantém o mesmo modelo dentro de um aplicativo, e passa a querer a mesma coisa na web sem manter duas exportações. Esse caso é real e é exatamente o assunto do artigo irmão sobre ExecuTorch em apps.
O navegador cobra entre 20% e 30% do desempenho
O navegador entrega entre 71% e 80% do desempenho de decodificação do mesmo motor rodando nativo, e isso está medido. O paper do WebLLM comparou o motor de navegador contra o mesmo runtime rodando nativo na mesma máquina, um MacBook Pro M3 Max, com modelos em 4 bits.
Reter de 71% a 80% do desempenho nativo é um resultado bom, e ao mesmo tempo é uma perda que precisa ser justificada por outra coisa. Ninguém escolhe o navegador porque ele é mais rápido. Escolhe porque o custo de inferência vai a zero, porque não há viagem de rede no meio, e porque o dado do usuário não sai do aparelho dele. Se nenhuma dessas três razões vale para o seu caso, o servidor é a resposta.
O WebGPU chegou aos quatro navegadores, mas não no mesmo lugar
O acesso à GPU pelo JavaScript é o que separa "roda um modelo pequeno na CPU" de "roda um LLM". Chrome e Edge entregam WebGPU estável desde a versão 113, e no Android desde a 121. Os outros dois chegaram depois, e a chegada foi fatiada.
-
O Firefox entra, só no Windows
Primeira liberação da API em canal estável, restrita a uma plataforma.
-
A Apple fecha o quadrado
WebGPU em iOS, iPadOS, visionOS e macOS. O post do WebKit cita transformers.js e ONNX Runtime funcionando bem.
-
macOS, apenas em Apple Silicon
Macs com processador Intel não foram contemplados em nenhuma das etapas seguintes.
-
As demais versões de macOS
Extensão do suporte para todas as versões de macOS ainda mantidas, sempre em Apple Silicon.
-
Service workers
A API passa a funcionar fora da thread principal. O Linux continua sem suporte.
Fontes: release notes do Firefox 141, 145, 147 e 148; post do WebKit sobre o Safari 26.0; documentação de plataforma do Chrome. Leitura de 30/08/2026.
Duas leituras práticas saem daí. A primeira é que "o Firefox suporta WebGPU" é uma frase que só faz sentido com a plataforma junto. A segunda é que a especificação ainda é um Candidate Recommendation Draft no W3C, o que significa que o contrato pode mudar antes de virar recomendação final.
Um terço da base Chrome no Windows não tem a GPU exigida
Trinta e um por cento dos usuários de Chrome no Windows não têm Direct3D no nível que o WebGPU exige, segundo telemetria publicada pelo próprio Google. O número saiu na justificativa de um modo de compatibilidade mais restrito, e é ele que decide se a sua aplicação pode contar com a GPU.
Fonte: Intent to Ship do WebGPU Compatibility Mode, lista blink-dev, thread de janeiro de 2026. O critério é Direct3D feature level 11.1 ou superior no Windows e Vulkan 1.1 no Android. O dado de Windows é telemetria do Chrome; o de Android vem dos dashboards da plataforma.
Quase um terço da base de Chrome no Windows fora significa que WebGPU não pode ser requisito, tem que ser aceleração. O desenho que sobrevive a esse número detecta a capacidade, usa a GPU quando ela existe, e cai para WebAssembly na CPU quando não existe, com um modelo menor e expectativa menor. Foi exatamente esse o desenho do Google Meet, anos antes de o WebGPU chegar ao canal estável.
O limite que quebra LLM no navegador é o buffer, não a memória
A restrição que derruba modelo grande não é a memória total da máquina, é o tamanho máximo de um único bloco de memória de GPU. A especificação do WebGPU garante bem pouco: qualquer implementação precisa suportar apenas 256 MiB por buffer e 128 MiB por binding de storage. Os pesos de um modelo sério não cabem nisso sem serem fatiados.
Pior: a aplicação não descobre quanta memória a GPU tem de verdade. O Chrome arredonda os limites reportados para degraus fixos, e o seu código só fica sabendo em qual degrau caiu.
| Degrau no Chrome | Maior binding de storage buffer |
|---|---|
| Compatibilidade e degrau 0 | 128 MiB, o mínimo garantido pela especificação |
| Degrau 1 | 256 MiB |
| Degrau 2 | 512 MiB |
| Degrau 3 | 1 GiB, onde um LLM quantizado começa a ficar confortável |
| Degraus 4 e 5 | 2 GiB e 4 GiB, hardware de ponta |
Fonte: Limits.cpp do Dawn, implementação de WebGPU do Chrome, leitura de 22/08/2026. O próprio código registra que os degraus são provisórios até haver métricas melhores.
O efeito disso aparece no código de quem já enfrentou o problema. O runtime que sustenta o WebLLM pede 1 GiB de buffer, aceita degradar para 256 MB, e desiste com erro se o aparelho não oferecer 32 KiB de memória compartilhada por grupo de trabalho ou dez storage buffers por estágio. Esses dois últimos não têm plano B: ou o aparelho tem, ou o usuário recebe uma mensagem pedindo para trocar de navegador.
No Safari a conta é outra, e mais apertada em telefone: no iOS o buffer é um terço da capacidade reportada pelo Metal, com piso de 256 MiB e teto de 1 GiB. Um modelo que roda no seu Mac pode simplesmente não carregar no iPhone do usuário.
Onde rodar no cliente ganha de verdade
Quatro padrões concentram os casos que deram certo, e eles têm uma coisa em comum: o modelo é pequeno, o ganho é imediato e a alternativa no servidor seria cara ou lenta.
- Processamento contínuo de mídia: desfoque de fundo, remoção de fundo, filtros de câmera, onde mandar cada quadro para o servidor é inviável.
- Recursos que o navegador já embute: o Chrome e o Edge expõem tradução e detecção de idioma com modelo local, sem você distribuir peso nenhum.
- Dado que não deveria sair do aparelho: rascunho, documento pessoal, conteúdo em edição antes de o usuário decidir publicar.
- Funcionalidade de altíssimo volume e baixo valor unitário, onde a inferência no servidor custaria mais do que o recurso entrega.
O segundo item merece atenção porque é o de menor esforço. O Chrome tem tradução com modelo local estável desde a versão 138, e o Edge levou tradução e detecção de idioma para o canal estável na versão 148, com mais de 145 idiomas. Não há download de pesos por sua conta nem escolha de runtime. Existe uma limitação que precisa ser dita: no Chrome essas APIs funcionam em computador e não em dispositivo móvel, e uma política corporativa pode desativar o download do modelo em máquina gerenciada.
Onde continua sendo servidor
Três situações desaconselham o cliente, e nenhuma delas melhora com hardware melhor.
Modelo grande com resposta previsível. Se o produto promete uma qualidade específica de resposta, você não pode depender do aparelho de quem abriu a página. A mesma pergunta vai ter resposta diferente para quem caiu no degrau 0 e para quem caiu no degrau 3.
Primeiro acesso que precisa ser rápido. Os pesos precisam ser baixados antes da primeira inferência, e isso é da ordem de centenas de megabytes para qualquer modelo de linguagem útil. Cache resolve a segunda visita, não a primeira.
Lógica que você não quer publicar. Tudo que roda no cliente pode ser lido pelo cliente, incluindo os pesos e o prompt do sistema. Se a inteligência do produto está aí, ela está aberta.
Como decidir no seu projeto
A decisão fica objetiva quando você responde quatro perguntas antes de escolher runtime.
- Qual porcentagem do seu público está em Windows ou Android antigo? Esse número é o tamanho do seu plano B, não uma exceção.
- O modelo que você precisa cabe em quantos megabytes? Se passar de algumas centenas, o download vira parte da experiência e precisa ser desenhado.
- Existe razão de privacidade ou de custo para não usar servidor? Se não existir nenhuma das duas, o servidor entrega mais previsibilidade.
- Você já mantém esse modelo dentro de um aplicativo? Se sim, o caminho do ExecuTorch evita manter duas exportações do mesmo grafo.
O erro mais comum não é escolher errado entre os runtimes. É tratar a inferência no cliente como substituta do servidor, quando ela funciona muito melhor como camada de frente: resolve rápido e de graça o caso comum, e chama o servidor quando o caso é difícil ou quando o aparelho não dá conta.
Precisa decidir onde a IA do seu produto vai rodar?
Solicite um orçamento e avance com arquitetura, escopo e entrega definidos.
Fontes e método
A apuração deste artigo foi feita em 30 de agosto de 2026, em fonte primária. O backend WebGPU do ExecuTorch, incluindo benchmark, arquitetura e ressalvas, vem do README.md do diretório backends/webgpu no repositório pytorch/executorch, com as datas de commit conferidas pela API do GitHub. Os limites de plataforma vêm da especificação do WebGPU no W3C, do Limits.cpp do Dawn e do HardwareCapabilities.mm do WebKit, lidos direto no código. Os números de adoção vêm do registro npm, na semana de 23 a 29 de agosto de 2026.
Os casos em produção vêm dos blogs de engenharia das próprias empresas: Google Research para o Meet, Chrome for Developers para as APIs embutidas e para a lista de produtos, e o blog do Microsoft Edge. A comparação entre navegador e nativo vem do paper do WebLLM, publicado no arXiv sob o identificador 2412.15803. A cronologia de suporte a WebGPU vem das release notes do Firefox 141, 145, 147 e 148, do post do WebKit sobre o Safari 26.0 e da documentação de plataforma do Chrome.
Nenhum teste de performance foi executado pela X-Apps para este artigo, e nenhuma medição própria é apresentada. Todos os produtos e projetos citados são externos, sem relação comercial com a X-Apps.
Perguntas frequentes
Sim, por três caminhos: exportar para ONNX e usar o ONNX Runtime Web, usar o transformers.js da Hugging Face, ou usar o backend WebGPU do ExecuTorch, que compila o mesmo grafo para WebAssembly.
Não. O paper do WebLLM mede entre 71% e 80% do throughput de decodificação nativo na mesma máquina. A vantagem do navegador é custo de inferência zero, latência sem rede e o dado não sair do dispositivo.
É a API que dá ao JavaScript acesso à GPU para computação, não só para desenho. Sem ela, a inferência fica limitada à CPU via WebAssembly, o que inviabiliza modelos maiores.
Os quatro principais já entregam, mas não em todo lugar. O Firefox ainda não liberou no Linux nem em Macs Intel, e a especificação segue como Candidate Recommendation Draft no W3C.
O tamanho máximo de buffer da GPU. A especificação garante apenas 256 MiB por buffer, e os pesos de um modelo grande não cabem nisso sem serem fatiados.
Pela telemetria do próprio Chrome, 31% dos usuários de Windows não têm Direct3D no nível exigido, e 23% dos usuários Android não têm Vulkan 1.1, segundo os dashboards do Android.
