Chrome Gemini Nano: por que 20 GB e o que devs precisam saber

Quando li que o Chrome precisa de 20 GB livres só para viabilizar a IA local, fui direto verificar no meu setup. Faz sentido? Depende. E é exatamente isso que vou destrinchar aqui, porque a nota do Tecnoblog.net deixa escapar pontos que importam para quem desenvolve — e muito.

O que realmente aconteceu com o Chrome e o Gemini Nano

Em maio, o Chrome baixou silenciosamente uma versão do Gemini Nano (~4 GB) em máquinas de vários usuários, sem aviso nem opt-in. Foi polêmico porque muitos nem usam os recursos de IA do navegador. Agora, segundo o Tecnoblog.net, o Google atualizou a documentação oficial entre 29 de julho e 1º de agosto para dizer que:

• Você precisa de no mínimo 20 GB livres no disco para que a IA local funcione;
• O browser faz uma checagem de elegibilidade de hardware antes de baixar os modelos — se não passar no critério, nem baixa;
• Os requisitos podem mudar sem aviso, porque a página de suporte deixa isso explícito.

Esse “20 GB” é a parte que ninguém comenta direito. Não é o tamanho do Gemini Nano em si — é o orçamento de armazenamento que o Chrome reserva para o ciclo de vida da feature: modelo base (~4 GB), versões incrementais para A/B testing, rollback de versões anteriores, cache de embeddings, e folga para atualizações futuras. É a mesma lógica que vejo em pipelines de ML: você nunca provisiona só o tamanho do checkpoint, sempre adiciona margem.

Por que 20 GB e não 4 GB? O “porquê” técnico

Três motivos reais, na minha leitura:

1. Múltiplas variantes do modelo. O Chrome provavelmente mantém mais de uma build do Gemini Nano no disco para comparar desempenho, fazer fallback e rodar experimentos. É padrão em sistemas que servem modelos em produção — você raramente tem uma única versão “canônica” instalada.
2. Histórico de rollback. Se uma atualização quebra algo em campo, o browser precisa conseguir voltar para a versão anterior sem redownload. Isso significa manter a versão N e a N-1 simultaneamente.
3. Cache de inferência e KV. Modelos locais que rodam em sessões longas acumulam estado. Em LLMs isso é o KV cache, que pode crescer bastante dependendo do contexto.

Se você é dev e já rodou Ollama, LM Studio ou llama.cpp, sabe: o modelo “declarado” é uma coisa, o que de fato ocupa disco é outra. O Chrome está sendo honesto — a maioria dos apps mente sobre footprint.

Comparativo real: Chrome vs. alternativas para rodar IA local

Coloquei lado a lado as opções que eu mesmo já testei em produção ou em projetos pessoais:

Na minha experiência, Ollama vence em flexibilidade, WebLLM vence em UX para apps web, e o Chrome AI só faz sentido se você quer entregar uma feature sem que o usuário instale nada. Mas nesse último caso, 20 GB silenciosos é um preço alto a pagar.

Na Prática: como checar se o Chrome já baixou o Gemini Nano na sua máquina

Antes de qualquer coisa, abra o DevTools e rode isso no console:

// Verifica se a API de IA do Chrome está disponível
if ('ai' in window && 'canCreateTextSession' in window.ai) {
  const status = await window.ai.canCreateTextSession();

  console.log('Status da IA local:', status);
  // Possíveis retornos: "readily", "after-download", "no"

  if (status === 'readily') {
    const session = await window.ai.createTextSession();
    const resposta = await session.prompt('Explique o que é Gemini Nano em uma frase.');
    console.log(resposta);
    await session.destroy();
  }

  if (status === 'after-download') {
    console.log('O modelo ainda não foi baixado. Requer ~4 GB e 20 GB livres.');
  }

  if (status === 'no') {
    console.log('Hardware não elegível. IA local não vai rodar nesta máquina.');
  }
} else {
  console.log('Esta versão do Chrome não expõe a Window.ai API. Atualize o navegador.');
}

Esse snippet é o que eu uso em QA para validar pipelines que dependem da API. Se você está construindo um SaaS e pretende usar IA no client (sumarização, autocomplete, classificação), precisa desse gate antes de chamar qualquer prompt.

Verificando o espaço real ocupado

No Linux/macOS, o cache de modelos do Chrome vive em:

# Linux
ls -lh ~/.config/google-chrome/Default/optimization_guide_model_store/

# macOS
ls -lh "~/Library/Application Support/Google/Chrome/Default/optimization_guide_model_store/"

# Verifica tamanho total
du -sh ~/.config/google-chrome/Default/

No Windows, o caminho é %LOCALAPPDATA%\Google\Chrome\User Data\Default\optimization_guide_model_store\. Se quiser limpar manualmente (fora do alcance do usuário médio), apague essa pasta e reinicie o Chrome — mas saiba que o download vai acontecer de novo no próximo uso elegível.

Erros Comuns — o que devs fazem errado com IA no browser

Depois de revisar código de vários times, esses são os deslizes mais frequentes:

• Assumir que a API sempre existe. Window.ai ainda é experimental e está atrás de flags. Trate como recurso opcional, nunca como dependência crítica do fluxo.
• Não medir custo de inferência no client. Mesmo um “pequeno” modelo de 1B parâmetros pode consumir 2 GB de RAM durante inferência. Em devices low-end, isso trava a aba.
• Esquecer do estado do KV cache. Sessões longas vazam memória. Sempre chame session.destroy() ou limite topK e temperature.
• Confundir “IA local” com “IA privada”. Local significa que o dado não vai pra servidor — mas o browser ainda loga telemetria. Se privacidade for requisito, leia o que está em chrome://policy.
• Ignorar o gate de elegibilidade. Chamar createTextSession() sem checar canCreateTextSession() resulta em promessa rejeitada e UX quebrada. Sempre gate primeiro.

Implicações para quem está construindo produto

Se você está lançando um app web com IA embutida, três decisões práticas que eu tomaria hoje:

1. Ofereça fallback server-side. O usuário não pode ficar sem funcionalidade porque o Chrome decidiu que a máquina dele não roda Gemini Nano. Mantenha um endpoint de API tradicional (mesmo que mais caro) como plano B.
2. Seja transparente sobre o download. O problema do Chrome em maio foi a falta de aviso. Se você for entregar um app PWA que baixa modelo, mostre um modal claro explicando o que vai acontecer, quanto vai ocupar e por quê.
3. Documente o “não”. Muitos devs só descrevem o caminho feliz. Liste no README os devices/navegadores que não vão rodar — isso poupa ticket de suporte.

FAQ — Perguntas que devs realmente fazem

1. Por que o Chrome reserva 20 GB se o Gemini Nano tem ~4 GB?

Porque o navegador mantém múltiplas variantes para A/B testing, mantém a versão anterior para rollback, e reserva folga para atualizações incrementais. É orçamento de ciclo de vida, não footprint do modelo isolado.

2. Como desativar o download do Gemini Nano no Chrome?

Acesse chrome://settings/performance e desative “Recursos de IA no dispositivo”. Também vale limpar a pasta optimization_guide_model_store manualmente. O Google promete não baixar em hardware não elegível, mas se você quiser garantir, bloqueie via política de empresa (Chrome Enterprise).

3. Gemini Nano roda em qualquer máquina?

Não. O Google não publicou os requisitos mínimos completos (VRAM? NPU? RAM?), apenas que o Chrome detecta se o hardware é potente o bastante antes de baixar. Na prática, modelos pequenos como o Nano precisam de GPU dedicada ou NPU moderna — CPUs antigas ficam de fora.

4. Vale a pena usar a Window.ai API em produção?

Depende do público. Se sua base tem Macs M1+ e Windows com NPU, sim — economiza custo de servidor e dá latência melhor. Se o público é broad (incluindo devices antigos), não — trate como experimento e tenha fallback robusto.

5. WebLLM é alternativa viável ao Chrome AI?

Para apps web, sim, e com mais controle. WebLLM roda via WebGPU e armazena modelos em OPFS (Origin Private File System). A diferença: você controla o versionamento, o usuário vê o que está sendo baixado, e não fica preso ao que o Google decide servir.

O que eu leio disso tudo

O movimento do Google é coerente com a estratégia de IA embarcada que toda big tech está empurrando. Mas a execução foi ruim — baixar 4 GB silenciosamente é erro de iniciante em produto. Reservar 20 GB declaradamente é, no mínimo, honesto.

Para nós, devs, o recado prático é: pare de tratar IA local como feature “grátis”. Tem custo de disco, custo de RAM, custo de manutenção e custo de suporte. Modele isso no seu roadmap. Se for usar, gate, fallback, monitore. Se não for usar, desabilite no Chrome antes que ele te use.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.