WebGPU e IA no dispositivo: o navegador está se tornando um tempo de execução sério

Durante anos, o navegador foi a cara legal do aplicativo e a nuvem foi o lugar onde as coisas difíceis aconteciam. O usuário escreve, clica, carrega um arquivo; o frontend envia tudo para o servidor; o servidor chama um modelo; a resposta volta.

Este esquema continua muito útil, mas não é gratuito. Cada chamada traz questões de latência, custo, dependência de rede e privacidade. Se o usuário está escrevendo uma frase e quer uma sugestão, meio segundo pesa. Se você classificar milhares de pequenos insumos, os centavos se tornarão dinheiro de verdade. Se o texto for confidencial, enviá-lo para fora do dispositivo não é uma escolha neutra.

É por isso que a WebGPU e a IA no dispositivo estão em alta. Não porque rodaremos todos os modelos no navegador amanhã. Porque alguns dos recursos inteligentes podem chegar mais perto do usuário.

Nem tudo precisa se tornar local

A versão infantil do argumento é: “nuvem versus dispositivo”. A versão útil é híbrida.

Algumas tarefas ficam ótimas no dispositivo: resumos curtos, detecção de linguagem, reescritas leves, classificações simples, filtros de imagem, modelos de visão pequena, experiências criativas com feedback imediato.

Outras tarefas permanecem melhores na nuvem: raciocínio complexo, modelos de fronteira, dados do lado do servidor, auditoria centralizada, qualidade uniforme, fluxo de trabalho onde é necessário controlar cuidadosamente cada etapa.

A arquitetura saudável decide em tempo de execução:

O navegador não precisa vencer a nuvem. Deve evitar que a nuvem faça trabalhos que não precisam ser feitos lá.

Por que WebGPU é importante

WebGPU é uma API moderna para usar a GPU do navegador. Não se trata apenas de gráficos 3D mais agradáveis. Também é importante porque expõe primitivos adequados para computação: cargas de trabalho paralelas, shaders, pipelines mais próximos do que as GPUs fazem bem.

Para IA, visualização científica, editores 3D, filtros de vídeo e ferramentas criativas, essa diferença é sentida. O WebGL fez muito pela web, mas o WebGPU nasceu com um modelo mais adequado ao presente.

A primeira coisa a escrever, entretanto, não é um shader. É uma detecção de recurso sóbria:

export async function requestWebGpuDevice() {
  if (!('gpu' in navigator)) {
    return null;
  }

  const adapter = await navigator.gpu.requestAdapter({
    powerPreference: 'high-performance',
  });

  if (!adapter) {
    return null;
  }

  return adapter.requestDevice();
}

Esse recurso diz uma coisa importante: WebGPU não é um direito concedido em todos os dispositivos. É uma capacidade a ser verificada. Alguns navegadores não oferecem suporte total, algumas GPUs têm limitações, alguns ambientes corporativos desativam recursos, alguns usuários usam hardware modesto.

IA integrada: quando o navegador traz o modelo

O Chrome está implementando APIs integradas para tarefas como prompts locais, resumo, redação, reescrita, tradução, detecção de idioma e revisão. A ideia é muito interessante: o navegador gerencia modelo, disponibilidade e atualizações; o aplicativo usa uma API mais próxima da plataforma.

Se funcionar bem, muda muito:

• menos chamadas de servidor para tarefas simples;
• dados que podem permanecer no dispositivo;
• menor latência;
• experiências offline ou semi-offline;
• UX mais natural para escrita e tradução.

Mas deve ser tratado como um aprimoramento progressivo. Algumas APIs são estáveis, outras estão em teste ou visualização de origem, outras ainda dependem da versão, idioma e dispositivo.

type LocalCapability = 'available' | 'downloadable' | 'unsupported';

export async function getLocalSummarizerCapability(): Promise<LocalCapability> {
  const SummarizerApi = (globalThis as any).Summarizer;

  if (!SummarizerApi?.availability) {
    return 'unsupported';
  }

  const availability = await SummarizerApi.availability();

  if (availability === 'available') return 'available';
  if (availability === 'downloadable') return 'downloadable';

  return 'unsupported';
}

O código específico mudará, mas o padrão permanecerá: você verifica a disponibilidade, explica todos os downloads, oferece alternativas e mede a qualidade.

Fallback não é um triste plano B

A recuperação da nuvem não é uma derrota. Faz parte do produto.

interface AiRequest {
  task: 'summarize' | 'rewrite' | 'classify';
  input: string;
}

interface AiResult {
  output: string;
  runtime: 'local' | 'cloud';
}

export async function runAiTask(request: AiRequest): Promise<AiResult> {
  const local = await tryLocalAi(request);

  if (local) {
    return { output: local, runtime: 'local' };
  }

  const cloud = await fetch('/api/ai', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(request),
  }).then((res) => res.json());

  return { output: cloud.output, runtime: 'cloud' };
}

Esta arquitetura permite melhorar progressivamente. Aqueles com suporte local obtêm melhor latência e privacidade. Quem não tem ainda usa o recurso. Você pode medir porcentagem de solicitações locais, tempos, erros, memória, qualidade percebida e custo.

Sem métricas, a IA no dispositivo torna-se uma escolha estética. Com métricas, torna-se uma alavanca do produto.

A UX do modelo é importante

Se o navegador precisar baixar um modelo, o usuário percebe. Não o esconda atrás de um botão giratório vago. Melhor deixar claro: “Preparamos o modelo para usar essa função de forma mais rápida e até offline”.

Uma boa experiência:

• mostra o estado de preparação;
• não bloqueia a página inteira;
• permite que você continue com o fallback da nuvem;
• evite surpresas de bateria e memória;
• lembre-se do modelo sempre que possível;
• explique o benefício em uma frase concreta.

O pior é um recurso “inteligente” que parece quebrado porque está baixando algo silenciosamente.

Privacidade: melhor, não é automaticamente segura

O processamento de dados no dispositivo pode ser uma grande vantagem. Um rascunho de e-mail, documento interno ou nota pessoal não precisa sair do seu navegador para receber uma sugestão.

No entanto, local não significa automaticamente seguro. No entanto, você precisa pensar sobre:

• XSS;
• registros acidentais;
• dados salvos no armazenamento;
• injeção imediata de conteúdo não confiável;
• permissões concedidas ao modelo;
• saídas usadas em ações automáticas.

Se um modelo local puder ler uma página da web e preencher um formulário, essa página poderá tentar manipulá-la. Se puder chamar a ferramenta, será necessária confirmação. Se produzir resultados estruturados, deve ser validado. O fato de rodar no aparelho reduz alguns riscos de privacidade, mas não elimina o modelo de segurança.

Onde fica realmente interessante

O texto é apenas o começo. O WebGPU torna confiáveis as experiências da web que até recentemente pareciam um aplicativo nativo:

• editores 3D complexos;
• Respingos gaussianos no navegador;
• filtros de vídeo em tempo real;
• CAD leve;
• visualizações científicas;
• ferramentas criativas com visualização instantânea;
• inferência de visão perto da UI;
• jogos de navegador mais ambiciosos.

Aqui frontend, gráficos e aprendizado de máquina começam a se misturar. É uma área um tanto estranha, mas também fértil: o navegador volta a ser uma plataforma de aplicação séria, e não apenas o local onde colocamos formulários e dashboards.

Lista de verificação antes da produção

Antes de apresentar um recurso no dispositivo aos usuários, eu verificaria:

1. Almeje navegadores e dispositivos.
2. Fallback da nuvem ou degradação elegante.
3. Tempo de download e cache do modelo.
4. Memória e bateria em hardware médio.
5. Qualidade em comparação com a versão em nuvem.
6. Política de privacidade e mensagens do usuário.
7. Testando com entradas hostis.
8. Métricas separadas para tempo de execução local e na nuvem.
9. Planeje atualizar ou desativar o modelo.

É uma lista concreta porque o problema é concreto. Um recurso de IA lento, frágil ou opaco não fica melhor só porque é executado no navegador.

O compromisso certo

Não acredito que o futuro seja “tudo no aparelho”. E também não creio que a nuvem continuará sendo o único lugar razoável para inferência. O futuro mais provável é uma mistura: local quando melhora a latência, a privacidade ou o custo; nuvem quando são necessários dados de qualidade, atualizados e controle centralizado.

WebGPU, WebNN e APIs de IA integradas não tornam o navegador onipotente. Eles o tornam mais adulto. E para aqueles que criam produtos web, esta é uma grande notícia.

Fontes úteis

• API WebGPU-MDN
• Especificação WebGPU - W3C
• IA integrada – Chrome para desenvolvedores
• APIs de IA integradas - Chrome para desenvolvedores
• API WebNN