1 
2Durante 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.
3 
4Este 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.
5 
6É 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.
7 
8## Nem tudo precisa se tornar local
9 
10A versão infantil do argumento é: “nuvem versus dispositivo”. A versão útil é híbrida.
11 
12Algumas 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.
13 
14Outras 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.
15 
16A arquitetura saudável decide em tempo de execução:
17 
18```mermaid
19flowchart TD
20    User[Usuário] --> Browser[Navegadores]
21    Browser --> Detect[Detecção de recursos]
22    Detect -->|Suportado| Local[Inferência local]
23    Detect -->|Não compatível| Cloud[Reserva de nuvem]
24    Local --> UX[Resposta rápida]
25    Cloud --> UX
26    UX --> Metrics[Métricas e qualidade]
27```
28 
29O navegador não precisa vencer a nuvem. Deve evitar que a nuvem faça trabalhos que não precisam ser feitos lá.
30 
31## Por que WebGPU é importante
32 
33WebGPU é 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.
34 
35Para 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.
36 
37A primeira coisa a escrever, entretanto, não é um shader. É uma detecção de recurso sóbria:
38 
39```typescript
40export async function requestWebGpuDevice() {
41  if (!('gpu' in navigator)) {
42    return null;
43  }
44 
45  const adapter = await navigator.gpu.requestAdapter({
46    powerPreference: 'high-performance',
47  });
48 
49  if (!adapter) {
50    return null;
51  }
52 
53  return adapter.requestDevice();
54}
55```
56 
57Esse 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.
58 
59## IA integrada: quando o navegador traz o modelo
60 
61O 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.
62 
63Se funcionar bem, muda muito:
64 
65- menos chamadas de servidor para tarefas simples;
66- dados que podem permanecer no dispositivo;
67- menor latência;
68- experiências offline ou semi-offline;
69- UX mais natural para escrita e tradução.
70 
71Mas 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.
72 
73```typescript
74type LocalCapability = 'available' | 'downloadable' | 'unsupported';
75 
76export async function getLocalSummarizerCapability(): Promise<LocalCapability> {
77  const SummarizerApi = (globalThis as any).Summarizer;
78 
79  if (!SummarizerApi?.availability) {
80    return 'unsupported';
81  }
82 
83  const availability = await SummarizerApi.availability();
84 
85  if (availability === 'available') return 'available';
86  if (availability === 'downloadable') return 'downloadable';
87 
88  return 'unsupported';
89}
90```
91 
92O código específico mudará, mas o padrão permanecerá: você verifica a disponibilidade, explica todos os downloads, oferece alternativas e mede a qualidade.
93 
94## Fallback não é um triste plano B
95 
96A recuperação da nuvem não é uma derrota. Faz parte do produto.
97 
98```typescript
99interface AiRequest {
100  task: 'summarize' | 'rewrite' | 'classify';
101  input: string;
102}
103 
104interface AiResult {
105  output: string;
106  runtime: 'local' | 'cloud';
107}
108 
109export async function runAiTask(request: AiRequest): Promise<AiResult> {
110  const local = await tryLocalAi(request);
111 
112  if (local) {
113    return { output: local, runtime: 'local' };
114  }
115 
116  const cloud = await fetch('/api/ai', {
117    method: 'POST',
118    headers: { 'Content-Type': 'application/json' },
119    body: JSON.stringify(request),
120  }).then((res) => res.json());
121 
122  return { output: cloud.output, runtime: 'cloud' };
123}
124```
125 
126Esta 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.
127 
128Sem métricas, a IA no dispositivo torna-se uma escolha estética. Com métricas, torna-se uma alavanca do produto.
129 
130## A UX do modelo é importante
131 
132Se 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”.
133 
134Uma boa experiência:
135 
136- mostra o estado de preparação;
137- não bloqueia a página inteira;
138- permite que você continue com o fallback da nuvem;
139- evite surpresas de bateria e memória;
140- lembre-se do modelo sempre que possível;
141- explique o benefício em uma frase concreta.
142 
143O pior é um recurso “inteligente” que parece quebrado porque está baixando algo silenciosamente.
144 
145## Privacidade: melhor, não é automaticamente segura
146 
147O 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.
148 
149No entanto, local não significa automaticamente seguro. No entanto, você precisa pensar sobre:
150 
151- XSS;
152- registros acidentais;
153- dados salvos no armazenamento;
154- injeção imediata de conteúdo não confiável;
155- permissões concedidas ao modelo;
156- saídas usadas em ações automáticas.
157 
158Se 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.
159 
160## Onde fica realmente interessante
161 
162O texto é apenas o começo. O WebGPU torna confiáveis as experiências da web que até recentemente pareciam um aplicativo nativo:
163 
164- editores 3D complexos;
165- Respingos gaussianos no navegador;
166- filtros de vídeo em tempo real;
167- CAD leve;
168- visualizações científicas;
169- ferramentas criativas com visualização instantânea;
170- inferência de visão perto da UI;
171- jogos de navegador mais ambiciosos.
172 
173Aqui 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.
174 
175## Lista de verificação antes da produção
176 
177Antes de apresentar um recurso no dispositivo aos usuários, eu verificaria:
178 
1791. Almeje navegadores e dispositivos.
1802. Fallback da nuvem ou degradação elegante.
1813. Tempo de download e cache do modelo.
1824. Memória e bateria em hardware médio.
1835. Qualidade em comparação com a versão em nuvem.
1846. Política de privacidade e mensagens do usuário.
1857. Testando com entradas hostis.
1868. Métricas separadas para tempo de execução local e na nuvem.
1879. Planeje atualizar ou desativar o modelo.
188 
189É 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.
190 
191## O compromisso certo
192 
193Nã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.
194 
195WebGPU, 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.
196 
197## Fontes úteis
198 
199- [API WebGPU-MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API)
200- [Especificação WebGPU - W3C](https://www.w3.org/TR/webgpu/)
201- [IA integrada – Chrome para desenvolvedores](https://developer.chrome.com/docs/ai/built-in)
202- [APIs de IA integradas - Chrome para desenvolvedores](https://developer.chrome.com/docs/ai/built-in-apis)
203- [API WebNN](https://webnn.io/)
204