Gemma 4 on-device: testes de IA em dois Androids diferentes

Tem um tempo que a galera de tech vem batendo na tecla da IA “on-device”, modelos que rodam direto no celular, sem depender de servidor, de internet ou daquela cobrança por token que assusta qualquer time de produto. Em abril, o Google lançou o Gemma 4, a geração mais recente da família Gemma feita sob medida pra caber (literalmente) no bolso e ainda assim entender texto e imagem ao mesmo tempo.

Pra sair da teoria e ver isso funcionando de verdade, construí o EdgeScan: um app Flutter que usa o Gemma 4 nas variantes E2B e E4B, trocáveis em tempo real pra simular um “scanner inteligente” de produtos e cupons fiscais, cobrindo três cenários simples:

• Descrever: o app olha pra uma foto e conta o que vê.

• Responder: o app responde uma pergunta livre sobre a imagem.

• Extrair dados: o app tenta devolver um JSON estruturado (loja, data, total, itens) a partir de uma foto de cupom.

Sobre os nomes: o “E” é de effective parameters. O E2B tem 5,1 bi de parâmetros (≈2,3 bi efetivos) e o E4B, 8 bi (≈4,5 bi efetivos). No app, o download fica em ~2,4 GB (E2B) e ~4,3 GB (E4B).

Tudo isso rodando 100% local no Android, depois que o modelo é baixado uma vez. O código completo, com todos os detalhes de implementação, está no repositório do projeto (link abaixo), mas aqui o papo é outro: o que descobri testando isso de verdade, em dois celulares bem diferentes: um Moto G82 (intermediário, 2022) e um Galaxy S25 (topo de linha, 2025). Segura o tchan, porque tem resultado bom, resultado ruim, e resultado “isso não tava nos planos”.

Quando funciona bem: rótulo legível, modelo feliz

Vamos começar pelo lado bonito. Apontei a câmera pra uma lata de Coca-Cola Zero Açúcar e perguntei, em português: “que produto é esse e qual a variação?”

Tanto o E2B quanto o E4B acertaram de cara: “Coca-Cola Zero Açúcar”. Sem rodeio, sem inventar nada, sem “talvez seja”.

Animado, subi o nível de dificuldade: uma lata de inseticida da SBP, com rótulo bem mais carregado de informação e cores. Foi aí que a diferença entre os dois modelos começou a aparecer:

• O E2B errou o tipo de produto: identificou como um “spray de limpeza/desinfetante” da marca SBP, quando na verdade é um inseticida. E, mesmo assim, ficou em cima do muro quanto à variação exata, dizendo que “a variação específica do produto não é totalmente clara apenas pela imagem”.

• O E4B foi muito melhor: identificou corretamente “SBP Anti Aedes Aegypti”, um inseticida e ainda pegou o detalhe “Sem Cheiro Residual” escrito no rótulo.

Esse resultado já mostra a diferença entre os dois tamanhos de modelo: para perguntas do tipo “o que é isso e o que diz aqui”, o E4B foi sensivelmente mais preciso que o E2B num rótulo mais carregado de informação. O tamanho extra realmente compra mais acerto em casos mais complexos.

Quando a letra é pequena, a história muda

Agora o teste que mais me interessava de verdade, pensando no caso de uso de “scanner de cupom fiscal”: uma foto de um cupom de supermercado de verdade, com aquela fonte minúscula que eu mesmo só leio com a câmera do celular dando zoom.

Pedi para o modelo descrever a imagem. O E2B se saiu surpreendentemente bem, na humildade. Ele descreveu corretamente o formato do cupom (colunas de item, quantidade, preço unitário, total), identificou que era um cupom fiscal em português e, antes de arriscar qualquer palpite sobre os itens, disse claramente que “o texto é pequeno e a resolução não permite a leitura de todos os detalhes”.

O E4B, por outro lado, foi com muito mais confiança… e tropeçou feio. Ele “leu” um nome de estabelecimento, um endereço completo e até um CNPJ… que não correspondem em nada ao cupom real. E, pra completar, listou o mesmo item (“POTE FILHO PEIROI SHAMPOO 100G”) dezenove vezes seguidas, como se tivesse entrado em loop.

Daí fui para o cenário de extração estruturada, pedi um JSON com loja, data, total e itens. O E2B começou bem: estrutura correta, chaves certas, formato batendo com o esperado. Mas na hora de preencher o valor total, um número que ele claramente não conseguia ler com confiança, ele simplesmente começou a gerar zeros… e não parou mais, até o limite de geração cortar a resposta no meio, sem nunca fechar o JSON.

O padrão que se repete nos dois modelos é revelador: quando o modelo não consegue “ler” um número ou texto com confiança, ele não responde “não sei”, ele inventa um valor plausível (caso do E4B) ou entra em loop repetindo algo (caso do E2B). É o comportamento clássico de um modelo compacto tentando “completar” uma informação que, na prática, não está disponível na imagem com a resolução que ele recebeu. Bom saber disso antes de colocar em produção para ler notas fiscais, né, meu chapa?

Hardware importa, e muito mais do que parece

Aqui talvez esteja o resultado mais concreto de todos. Rodei o mesmo prompt de descrição de imagem nos dois aparelhos, com os dois modelos, e cronometrei o tempo de inferência, ou seja, quanto tempo o modelo leva para gerar a resposta depois de já estar carregado na memória, que é o que se repete a cada nova foto escaneada durante o uso do app:

Aparelho	Modelo	Inferência (modelo já carregado)
Moto G82 (2022, intermediário)	Gemma 4 E2B	~4 min 20 s
Moto G82 (2022, intermediário)	Gemma 4 E4B	trava o app
Galaxy S25 (2025, topo de linha)	Gemma 4 E2B	~17,5 s
Galaxy S25 (2025, topo de linha)	Gemma 4 E4B	~83,5 s

Alguns pontos que valem destaque:

• No Moto G82, o E4B simplesmente não rodou. Em todas as tentativas, o app travava durante a preparação do modelo, antes mesmo de chegar à etapa de inferência medida acima. Sinal de que os 4,3 GB do E4B não cabem confortavelmente na memória disponível desse aparelho, independentemente dos ajustes de configuração que tentei.

• O E2B roda nos dois aparelhos, mas com uma diferença de quase 15 vezes no tempo de resposta entre o intermediário e o topo de linha. Quatro minutos e meio para descrever uma imagem está, claramente, bem longe do aceitável.

• Em ambos os casos a inferência rodou na CPU. Cheguei a tentar usar a GPU do Moto G82 para acelerar, mas ela travou o app com um erro nativo bem no meio da inferência, então, pelo menos com essa combinação de modelo e runtime, a CPU foi o caminho viável.

O que isso significa na prática

Juntando tudo, consegui tirar algumas conclusões bem concretas para quem está pensando em IA generativa on-device em Flutter (ou em qualquer stack mobile):

1. “O que é isso?” funciona bem / “leia esse número aqui” ainda não. Para reconhecimento geral de produtos com rótulos legíveis, o Gemma 4 (mesmo o E2B) já entrega valor real, hoje, sem depender de nuvem. Para OCR de precisão, cupons fiscais, números de série, letras pequenas, ainda é território arriscado, e o modelo tende a inventar em vez de admitir que não sabe.

2. E2B é o ponto de partida seguro. Ele roda em aparelhos mais simples, é bem mais rápido e, pelo menos nos meus testes, foi consistentemente mais “honesto” sobre suas próprias limitações do que o E4B.

3. E4B compensa em casos específicos, mas custa caro. Quando o texto é legível, o E4B entrega respostas mais precisas e detalhadas. Mas o custo é alto: cerca de 5 vezes mais lento que o E2B no mesmo aparelho, e simplesmente inviável em hardware intermediário.

4. Teste no hardware real, sempre. A diferença entre “funciona muito bem” e “trava o aparelho” foi, literalmente, qual celular usei para o teste. Se o público do seu produto usa aparelhos intermediários, o que é a realidade da maior parte do Brasil, isso precisa entrar na conta antes de qualquer decisão.

Pra fechar

Não vai ter aqui aquele final raso de “e tudo funcionou perfeitamente, aproveitem!”, e isso não é uma coisa ruim. Aprendi onde o Gemma 4 brilha (reconhecimento geral com texto legível, rodando inteiramente offline, sem custo de API) e onde ele ainda exige cuidado redobrado (qualquer coisa que dependa de ler números pequenos com precisão, principalmente em hardware mais modesto).

Se você quiser ver o app completo, os prompts exatos que usei e os detalhes de configuração (incluindo a história da GPU do Moto G82 que não quis cooperar), o repositório do projeto está aberto aqui: https://github.com/fernandesrenan/edge-scan. E se você já testou o Gemma ou outro modelo on-device por aí, bora trocar ideia nos comentários, quero saber se bateu com a minha experiência.