Chrome quer LLM no navegador: Firefox tem razão?

O problema que ninguém pediu

Você está desenvolvendo uma aplicação web que usa um modelo de linguagem. Hoje, você depende de APIs cloud como OpenAI ou de soluções on-device como WebGPU + Transformers.js. Agora o Google Chrome quer simplificar isso com uma LLM Prompt API nativa no navegador. Parece conveniente, mas o Firefox acabou de se posicionar contra. E talvez eles estejam certos.

O fato: Firefox vs Chrome na LLM Prompt API

A equipe do Firefox publicou uma declaração no Mastodon se opondo à proposta do Chrome de incluir uma API de prompt para LLMs diretamente no motor do navegador. A justificativa oficial: riscos de privacidade e centralização do ecossistema. Em vez disso, o Firefox defende que a web deve suportar múltiplos provedores de modelo via APIs abertas, e não um único integrado ao navegador.

A proposta do Chrome, ainda em estágio inicial, permitiria que sites chamassem um modelo de linguagem local ou remoto através de uma API padronizada, sem necessidade de bibliotecas externas. O Google tem testado isso com o Gemini Nano em versões experimentais do Chrome.

Como funciona (visão de operador)

Pelo que se sabe, a LLM Prompt API exporia uma interface simples: navigator.llm.prompt('texto') retornaria uma resposta gerada por um modelo nativo. A implementação atual usa o Gemini Nano otimizado para dispositivos com pouca memória. Mas aqui vêm as perguntas técnicas:

• Latência: Um modelo local roda rápido (milissegundos), mas ocupa RAM e CPU. Em dispositivos low-end, pode impactar o desempenho geral do navegador.
• Tamanho: O Gemini Nano tem cerca de 1.5GB de parâmetros? Desconheço o tamanho exato, mas qualquer modelo local significativo consome centenas de MBs de download. Isso não é trivial.
• Custo: Para o Google, rodar inferência local reduz custos de servidor, mas aumenta o custo de manutenção do navegador e do modelo embarcado.
• Privacidade: O prompt fica no dispositivo, mas quem controla o modelo? Se o Google atualizar o modelo remotamente, há brecha para coleta de dados? A API pode enviar telemetria?

O Firefox argumenta que uma API proprietária (mesmo que padronizada) tende a favorecer o modelo do Google, criando um monopólio de fato. Eles preferem que a web use APIs abertas como fetch para chamar qualquer LLM, mantendo a escolha do usuário.

O que isso muda na prática

Se o Chrome implementar a API, desenvolvedores terão um caminho fácil para adicionar IA a sites, sem dependências externas. Isso pode acelerar features como sumarização automática, chatbots inline ou assistentes de escrita. Mas o preço é a dependência do ecossistema Google e a fragmentação: Firefox e Safari provavelmente não adotarão a API, então você precisará de fallback.

Ação prática: Se você está construindo uma aplicação web que usa LLM hoje, monitore a evolução dessa proposta, mas não abandone soluções portáteis como Transformers.js ou APIs REST. Planeje fallbacks para navegadores que não suportarem a API nativa.

A tensão real: isso resolve ou só muda o gargalo?

Centralizar a IA no navegador reduz a fricção de implementação, mas levanta questões de controle. Quem define quais modelos são incluídos? O Google, no caso. E se o modelo tiver viés ou falhar? O navegador se torna responsável pela qualidade da IA. Além disso, a privacidade prometida é real se a telemetria do Chromium continuar enviando dados de uso? Me parece um trade-off: conveniência imediata versus controle e transparência a longo prazo.

O Firefox tem razão em erguer a bandeira da descentralização, mas a história mostra que a web acaba seguindo o Chrome. Se a LLM Prompt API vingar, teremos mais um lock-in.

Conclusão

A disputa expõe um dilema clássico: eficiência vs. soberania do usuário. A LLM Prompt API pode ser boa para produtividade, mas talvez o preço seja alto demais. Enquanto o debate esquenta, continue usando abordagens agnósticas. E, no fundo, fica a pergunta: até onde deixamos os navegadores decidirem como usamos IA?