O Google lançou o Gemma 4 a 2 de abril de 2026, e o modelo mudou a conversa sobre IA aberta para quem quer correr um LLM competente no próprio computador. Ao contrário do Gemini, que só existe atrás de uma API paga, o Gemma 4 sai com pesos abertos sob licença Apache 2.0, cinco tamanhos diferentes e resultados de benchmark que deixam o antecessor Gemma 3 muito para trás. Este tutorial mostra, passo a passo, como instalar o Gemma 4, testá-lo na linha de comandos, ligá-lo a uma aplicação Python e até fazer fine-tuning num portátil com uma GPU de gama média.

O objetivo é prático. Vai sair daqui com um chatbot funcional em Python, um ambiente Ollama configurado, e uma noção clara de qual dos cinco tamanhos do Gemma 4 cabe no seu hardware. Também vamos cobrir os erros mais comuns e os bugs já documentados no GitHub, para poupar horas de frustração.

Para leitores mais atentos às questões de segurança e privacidade, este guia também é relevante por outro motivo: correr um modelo localmente muda por completo o perfil de risco de uma aplicação de IA. Não há dados de prompt a atravessar a rede até um servidor de terceiros, o que simplifica a conformidade em setores regulados. Voltamos a este tema com mais detalhe numa secção dedicada, depois de terminarmos a instalação prática.

O que é o Gemma 4 e porque é diferente do Gemma 3

O Gemma 4 é a quarta geração da família de modelos abertos da Google, construída com a mesma investigação que alimenta o Gemini, mas distribuída como pesos descarregáveis. A Google lançou o modelo em cinco tamanhos: E2B (2,3 mil milhões de parâmetros efetivos, 5,1 mil milhões incluindo embeddings), E4B (4,5 mil milhões efetivos, 8 mil milhões no total), 12B Unified (cerca de 11,95 mil milhões), 26B-A4B em arquitetura Mixture of Experts (25,2 mil milhões no total, mas só 3,8 mil milhões ativos por token) e 31B denso (30,7 mil milhões de parâmetros).

A diferença mais visível em relação ao Gemma 3 está nos benchmarks de raciocínio e uso de ferramentas. No AIME 2026, o Gemma 4 31B IT em modo “thinking” atinge 89,2%, contra 20,8% do Gemma 3 27B IT. No LiveCodeBench v6, sobe de 29,1% para 80,0%. No GPQA Diamond, salta de 42,4% para 84,3%. E no τ2-bench Retail, que mede desempenho agente com ferramentas, o Gemma 3 27B ficava-se pelos 6,6%: o Gemma 4 31B chega aos 86,4%. O modelo 31B também regista 1452 pontos de Elo numa arena estilo LMArena e 85,2% no MMLU-Pro.

Todos os tamanhos, exceto E2B e E4B, suportam uma janela de contexto de 256 mil tokens. Os dois modelos mais pequenos ficam-se pelos 128 mil tokens, o que ainda é bastante para a maioria das tarefas de programação ou de resumo de documentos longos. A licença Apache 2.0 permite uso comercial sem royalties, o que já não acontecia com algumas versões anteriores da família Gemma.

Vale destacar ainda o Gemma 4 12B Unified, anunciado pela Google como atualização separada dos quatro tamanhos originais. É um modelo multimodal encoder-free, o que significa que processa texto, imagem e áudio sem depender de um encoder visual externo colado ao modelo de linguagem, uma arquitetura pensada especificamente para correr bem em portáteis com GPU integrada ou dedicada de gama média. Este tutorial foca-se sobretudo no E4B por ser o ponto de entrada mais acessível, mas praticamente todos os comandos aplicam-se aos outros tamanhos trocando apenas a etiqueta do modelo.

Pré-requisitos: hardware, software e contas necessárias

Antes de avançar, confirme que tem o seguinte preparado. Não precisa de tudo desde o início, mas cada secção deste tutorial vai assumir que já tem a base instalada.

  • Sistema operativo: Linux, macOS 13 ou superior, ou Windows 11 com WSL2
  • Python 3.10 ou superior instalado e no PATH
  • Ollama (versão mais recente disponível em ollama.com)
  • Hugging Face Transformers 5.5.0 ou superior (o suporte ao Gemma 4 só entrou nesta versão)
  • Uma conta gratuita na Hugging Face, caso queira descarregar pesos diretamente do repositório
  • GPU com pelo menos 8 GB de VRAM para o modelo E4B em 4-bit, ou 16 GB para o 12B em 4-bit (valores reportados pela comunidade em fóruns como o r/LocalLLaMA, não são números oficiais da Google)
  • Cerca de 10 GB de espaço livre em disco por cada tamanho de modelo descarregado em GGUF quantizado
  • Git instalado, para clonar o llama.cpp na secção correspondente

Quem não tiver GPU dedicada ainda consegue correr o E2B ou o E4B só em CPU, mas a velocidade de geração vai ressentir-se bastante. Para experimentar sem gastar em hardware, o Google Colab com GPU T4 gratuita chega para testar o E2B com fine-tuning leve, como se vê mais à frente na secção do Unsloth.

Passo 1: Escolher o tamanho certo do modelo

O erro mais comum de quem começa com o Gemma 4 é descarregar logo o 31B sem verificar se o hardware aguenta. A tabela seguinte resume os cinco tamanhos e para que cenário cada um serve melhor.

ModeloParâmetrosContextoUso recomendado
Gemma 4 E2B2,3 mil milhões efetivos (5,1 mil milhões total)128K tokensTelemóveis, edge devices, protótipos rápidos
Gemma 4 E4B4,5 mil milhões efetivos (8 mil milhões total)128K tokensPortáteis com 8-12 GB de VRAM, chatbots locais
Gemma 4 12B Unified~11,95 mil milhões256K tokensMultimodal (texto, imagem, áudio), estações de trabalho
Gemma 4 26B-A4B (MoE)25,2 mil milhões total / 3,8 mil milhões ativos256K tokensTarefas agente e uso de ferramentas com custo controlado
Gemma 4 31B denso~30,7 mil milhões256K tokensMáximo desempenho, servidores com GPU de 24 GB+

Para a maioria dos leitores que seguem este guia num portátil ou numa GPU de consumo, o E4B é o ponto de partida mais equilibrado. Guarde o 31B para quando tiver acesso a uma GPU com pelo menos 24 GB de VRAM ou a um serviço cloud como o Google Cloud ou a Kaggle.

Passo 2: Instalar o Ollama

O Ollama continua a ser o caminho mais rápido para correr o Gemma 4 sem escrever uma linha de Python. Em Linux ou macOS, o instalador oficial faz tudo num só comando.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version

Em Windows, descarregue o instalador .exe diretamente do site oficial do Ollama e siga o assistente. Depois de instalado, o serviço fica a correr em segundo plano na porta 11434, pronto a receber pedidos.

Passo 3: Descarregar o Gemma 4 com Ollama

Com o Ollama instalado, descarregue a variante que escolheu no Passo 1. O comando por defeito traz o E4B, mas pode especificar qualquer outro tamanho com a etiqueta correta.

# Descarrega o E4B (variante por defeito)
ollama pull gemma4

# Ou escolha um tamanho específico
ollama pull gemma4:e2b
ollama pull gemma4:12b
ollama pull gemma4:26b
ollama pull gemma4:31b

# Confirme que o download terminou
ollama list

O resultado de ollama list deve mostrar o nome do modelo, o identificador da imagem e o tamanho em disco, algo como gemma4:e4b 4.9 GB 3 minutes ago. Se o download falhar a meio, basta repetir o comando: o Ollama retoma a partir do último bloco descarregado.

Passo 4: Primeira conversa na linha de comandos

Chegou a hora de testar o modelo. Corra o comando abaixo e escreva uma pergunta diretamente no terminal.

ollama run gemma4:e4b "Explica em três frases o que é fine-tuning de um LLM"

A primeira resposta demora um pouco mais porque o Ollama carrega o modelo para memória. Nas chamadas seguintes, o modelo fica em cache e a resposta chega em poucos segundos numa GPU de gama média. Para uma sessão de conversa contínua, sem repetir o comando a cada pergunta, use apenas ollama run gemma4:e4b sem argumentos, o que abre um modo interativo.

Um exemplo real de saída, numa GPU de 12 GB, é semelhante a este:

$ ollama run gemma4:e4b "Explica em três frases o que é fine-tuning de um LLM"
Fine-tuning é o processo de continuar o treino de um modelo de linguagem
já pré-treinado, usando um conjunto de dados mais pequeno e específico
para uma tarefa. Em vez de treinar do zero, aproveitam-se os pesos
existentes e ajustam-se apenas o suficiente para o modelo se especializar
num domínio, como suporte ao cliente ou análise de contratos jurídicos.
O resultado é um modelo mais preciso nessa tarefa concreta, sem o custo
computacional de um treino completo.

total duration:       4.2s
load duration:        1.1s
eval count:            96 tokens
eval duration:         2.8s

Os valores de duração variam consoante a GPU e se é a primeira chamada depois de o modelo ter sido carregado. Se a resposta demorar muito mais do que isto numa GPU dedicada, avance para a secção de resolução de problemas mais abaixo.

Passo 5: Usar o Gemma 4 com Hugging Face Transformers

Para integrar o Gemma 4 em código Python de forma mais flexível do que a API do Ollama permite, a biblioteca Transformers da Hugging Face oferece suporte de primeira classe ao modelo desde a versão 5.5.0. Sem essa versão mínima, o model_type: gemma4 nem sequer é reconhecido.

pip install -U "transformers>=5.5.0" torch accelerate

python3 -c "
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_id = 'google/gemma-4-4b-it'
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype=torch.bfloat16,
    device_map='auto'
)

prompt = tokenizer.apply_chat_template(
    [{'role': 'user', 'content': 'Resume o Tratado de Lisboa em duas frases'}],
    tokenize=False,
    add_generation_prompt=True
)
inputs = tokenizer(prompt, return_tensors='pt').to(model.device)
output = model.generate(**inputs, max_new_tokens=200)
print(tokenizer.decode(output[0], skip_special_tokens=True))
"

Repare no torch_dtype=torch.bfloat16: sem quantização, mesmo o E4B pode não caber numa GPU de 8 GB. Para reduzir o consumo de memória, adicione o parâmetro load_in_4bit=True através da biblioteca bitsandbytes, ou avance diretamente para a secção do llama.cpp, que trata a quantização de forma nativa.

Passo 6: Correr ficheiros GGUF com llama.cpp

O llama.cpp continua a ser a opção mais leve para quem quer controlo total sobre a quantização, sem depender do daemon do Ollama. Tanto a Google como a Unsloth publicaram repositórios GGUF oficiais na Hugging Face, incluindo unsloth/gemma-4-E4B-it-GGUF e variantes em Q4_K_M, Q5_K_M e Q8_0.

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

# Descarregar o ficheiro GGUF quantizado
huggingface-cli download unsloth/gemma-4-E4B-it-GGUF \
  gemma-4-E4B-it-Q4_K_M.gguf --local-dir ./modelos

# Correr o modelo
./build/bin/llama-cli -m ./modelos/gemma-4-E4B-it-Q4_K_M.gguf \
  -p "Escreve uma função Python que calcula o número de Fibonacci" -n 256

Se a sua máquina não tiver GPU NVIDIA, remova a flag -DGGML_CUDA=ON antes de compilar para usar apenas CPU. O desempenho cai bastante, mas o modelo continua a funcionar, especialmente nos tamanhos E2B e E4B.

Passo 7: Criar uma API REST local com o Ollama

O Ollama expõe automaticamente uma API REST na porta 11434, o que permite integrar o Gemma 4 em qualquer aplicação sem escrever código de inferência à mão.

curl http://localhost:11434/api/chat -d '{
  "model": "gemma4:e4b",
  "messages": [
    { "role": "user", "content": "Quais são as três leis da robótica?" }
  ],
  "stream": false
}'

A resposta chega em JSON, com o texto gerado no campo message.content e metadados como o número de tokens processados e o tempo total em nanossegundos. Este é o endpoint que vamos usar no projeto do próximo passo. Uma resposta típica tem este aspeto:

{
  "model": "gemma4:e4b",
  "created_at": "2026-09-10T14:32:07Z",
  "message": {
    "role": "assistant",
    "content": "As três leis da robótica, formuladas por Isaac Asimov,
estabelecem que um robô não pode causar dano a um ser humano, deve
obedecer às ordens dadas por humanos exceto quando entram em conflito
com a primeira lei, e deve proteger a própria existência desde que
isso não viole as duas leis anteriores."
  },
  "done": true,
  "total_duration": 3120456789,
  "eval_count": 78,
  "eval_duration": 1980456789
}

Repare que total_duration e eval_duration vêm em nanossegundos, não em segundos. Se estiver a construir dashboards de monitorização, divida por 1 000 000 000 antes de apresentar o valor ao utilizador.

Passo 8: Construir um chatbot completo em Python

Com o Ollama e o modelo já a funcionar, este passo junta tudo num pequeno projeto funcional: um chatbot de linha de comandos com memória de conversa, pronto a correr localmente sem depender de nenhuma API externa.

import requests
import json

OLLAMA_URL = "http://localhost:11434/api/chat"
MODEL = "gemma4:e4b"

def chat():
    historico = []
    print("Chatbot Gemma 4 local. Escreva 'sair' para terminar.\n")
    while True:
        pergunta = input("Você: ")
        if pergunta.lower() == "sair":
            break
        historico.append({"role": "user", "content": pergunta})
        resposta = requests.post(OLLAMA_URL, json={
            "model": MODEL,
            "messages": historico,
            "stream": False
        })
        conteudo = resposta.json()["message"]["content"]
        historico.append({"role": "assistant", "content": conteudo})
        print(f"Gemma 4: {conteudo}\n")

if __name__ == "__main__":
    chat()

Guarde este ficheiro como chatbot.py e corra python3 chatbot.py num terminal com o Ollama já ativo. Cada mensagem enviada acumula-se no array historico, o que dá ao modelo contexto sobre a conversa anterior. Para conversas mais longas do que a janela de contexto permite, terá de implementar uma estratégia de resumo ou de corte das mensagens mais antigas.

Passo 9: Fazer fine-tuning do Gemma 4 com Unsloth

O Unsloth suporta fine-tuning do Gemma 4 em todos os tamanhos (E2B, E4B, 12B, 26B-A4B e 31B), incluindo texto, visão, áudio e reinforcement learning, com notebooks oficiais no Google Colab. Para quem já tem experiência com LoRA, o processo é semelhante ao usado no Unsloth para outras famílias de modelos.

pip install unsloth

python3 -c "
from unsloth import FastLanguageModel
import torch

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = 'unsloth/gemma-4-E2B-it',
    max_seq_length = 4096,
    load_in_4bit = True,
)

model = FastLanguageModel.get_peft_model(
    model,
    r = 16,
    target_modules = ['q_proj', 'k_proj', 'v_proj', 'o_proj'],
    lora_alpha = 16,
    use_gradient_checkpointing = 'unsloth',
)
print('Modelo pronto para treino LoRA')
"

Segundo relatos da comunidade em fóruns como o r/LocalLLaMA, um treino LoRA do E2B cabe confortavelmente numa GPU T4 gratuita do Google Colab, que tem 16 GB de VRAM, usando entre 8 e 10 GB durante o treino. Para o 31B, vai precisar de hardware dedicado ou de um plano pago de Colab/Kaggle com GPU A100.

Antes de lançar o treino, prepare o conjunto de dados no formato de conversa que o Unsloth espera, normalmente uma lista de pares pergunta-resposta em JSON ou num dataset da Hugging Face já estruturado com os campos role e content. Datasets mal formatados são uma das causas mais comuns de erros silenciosos durante o treino, em que o processo corre até ao fim sem gerar avisos mas produz um modelo que não aprendeu a tarefa pretendida. Vale sempre a pena treinar primeiro com uma amostra pequena, de algumas dezenas de exemplos, para confirmar que o pipeline funciona de ponta a ponta antes de investir horas de GPU no conjunto de dados completo.

Passo 10: Avaliar o modelo com benchmarks próprios

Depois de instalado e, opcionalmente, afinado, vale a pena confirmar que o modelo responde bem ao seu caso de uso concreto antes de o colocar em produção. Uma forma simples é criar um pequeno conjunto de perguntas representativas do domínio e comparar respostas antes e depois do fine-tuning.

import requests
import time

perguntas_teste = [
    "Resume este contrato em 3 pontos principais",
    "Classifica este email como spam ou não spam",
    "Traduz esta frase para inglês técnico",
]

for p in perguntas_teste:
    inicio = time.time()
    r = requests.post("http://localhost:11434/api/chat", json={
        "model": "gemma4:e4b",
        "messages": [{"role": "user", "content": p}],
        "stream": False
    })
    duracao = time.time() - inicio
    print(f"Pergunta: {p}\nTempo: {duracao:.2f}s\nResposta: {r.json()['message']['content'][:200]}\n")

Guarde os tempos de resposta e a qualidade percebida num ficheiro CSV simples. Isto dá-lhe uma base objetiva para decidir se compensa subir de tamanho de modelo (por exemplo, de E4B para 12B) ou se o ganho de qualidade não justifica o custo extra de VRAM e latência. Para tarefas mais estruturadas, como classificação ou extração de dados, vale a pena ir além da inspeção manual e calcular uma métrica objetiva, como percentagem de respostas corretas contra um gabarito previamente definido, em vez de confiar apenas na impressão subjetiva de que “parece melhor”.

Passo 11: Otimizar VRAM e escolher a quantização certa

A escolha do nível de quantização tem um impacto direto na qualidade das respostas e no consumo de memória. Q4_K_M é o ponto de equilíbrio mais usado pela comunidade, mas Q8_0 aproxima-se mais do desempenho original em bfloat16, ao custo de mais VRAM.

QuantizaçãoQualidade relativaVRAM aproximada (E4B, reportado pela comunidade)
fp16 / bfloat16Referência (100%)~16 GB
Q8_0Muito próxima do original~9 GB
Q4_K_MBoa para a maioria das tarefas~6-8 GB
Q4_0Aceitável, alguma perda em tarefas complexas~5-6 GB

Estes números são estimativas recolhidas em discussões de utilizadores e não valores publicados oficialmente pela Google, por isso trate-os como ponto de partida e não como garantia. Se notar respostas incoerentes ou perda de qualidade acentuada, suba um nível de quantização antes de assumir que o modelo tem um problema.

Passo 12: Erros comuns a evitar

Depois de configurar dezenas de instalações do Gemma 4, alguns erros repetem-se com frequência suficiente para merecerem destaque próprio.

  • Escolher um tamanho incompatível com o hardware: tentar correr o 31B numa GPU de 8 GB sem quantização agressiva vai resultar em erros de memória (out of memory) ou em lentidão extrema. Comece sempre pelo E4B e só suba de tamanho depois de confirmar que o hardware aguenta com margem.
  • Não atualizar a Transformers: versões anteriores à 5.5.0 simplesmente não reconhecem o model_type: gemma4, gerando um erro de modelo desconhecido. Este é o erro mais reportado por quem segue tutoriais antigos de outras versões do Gemma sem verificar a versão da biblioteca.
  • Confundir VRAM da GPU com RAM do sistema: um modelo pode caber na RAM mas continuar a falhar na GPU se o device_map não estiver configurado corretamente, levando a um erro de CUDA out of memory mesmo com RAM de sobra na máquina.
  • Ativar flash-attention com drafter model e KV cache quantizado ao mesmo tempo: esta combinação específica é conhecida por provocar crashes no E4B em llama.cpp. Se precisar das três funcionalidades, teste-as isoladamente antes de as combinar em produção.
  • Usar sempre o contexto máximo de 256K: pedir sempre a janela de contexto completa desperdiça memória quando a maioria das conversas não passa dos poucos milhares de tokens. Defina um limite de contexto realista para o seu caso de uso em vez de usar o valor máximo por defeito.
  • Ignorar o tool_choice em tarefas com chamadas de ferramentas: sem restringir a gramática de saída, o modelo pode entrar num ciclo de repetição ao gerar chamadas de função, consumindo tokens e tempo de resposta sem produzir um resultado útil.
  • Esquecer de fixar a versão do llama.cpp e da Transformers em produção: ambos os projetos evoluem depressa e um update automático pode quebrar um pipeline que estava estável. Fixe versões exatas num ficheiro de dependências e só atualize depois de testar num ambiente separado.

Resolução de problemas: os erros mais reportados

Esta secção reúne os problemas mais documentados publicamente para o Gemma 4, com o número do issue original sempre que existe um registo público no GitHub, para facilitar a pesquisa se precisar de mais detalhe.

  • Tokens <unused> em loop infinito no backend Vulkan: registado como issue #21516 no llama.cpp. Acontece tanto com aceleração por GPU como só em CPU. Solução: mudar para backend CUDA ou Metal em vez de Vulkan.
  • Segfault em contextos longos com modelos multimodais: issue #21336. O workaround documentado é desativar a flash attention com a flag --flash-attn off.
  • Suporte de áudio em falta: issue #21325 confirma que o caminho de processamento de áudio ainda não está implementado corretamente para o Gemma 4 no llama.cpp.
  • Falha na reutilização de cache mesmo com -fa e --swa-full ativos: issue #21468. O workaround reportado é definir -np 2 no arranque do servidor.
  • Crash do E4B com flash-attention, drafter e KV cache quantizado em simultâneo: issue #24400. Basta remover a flash-attention ou o modelo drafter para o crash desaparecer.
  • Falha na conversão de certos checkpoints com convert_hf_to_gguf.py: issue #21403, reportado especificamente com checkpoints modificados (“abliterated”). Tentar a conversão direta para Q8_0 costuma contornar o problema.
  • Ciclo de repetição infinita em chamadas de ferramentas via llama-server: issue #21375. Mitigação: definir parallel_tool_calls: false, limitar max_tokens ou forçar tool_choice: "required".
  • Chamada de ferramenta devolvida como texto normal em vez de function call: issue #22786, observado numa RTX 4070 com backend CUDA.
  • Erro de KeyError ao treinar com FSDP2: issue #45663 no repositório da Transformers, relacionado com a forma como os estados de KV partilhados são reconstruídos entre camadas do decoder durante o treino distribuído.
  • Modelo não reconhecido em pipelines de quantização de terceiros: issue #2562 no llm-compressor, causado por o projeto fixar uma versão da Transformers anterior à 5.5.0, que ainda não tinha suporte ao gemma4.

Segurança e privacidade ao correr o Gemma 4 localmente

Correr o Gemma 4 em hardware próprio resolve um problema concreto de privacidade: nenhum prompt, documento ou dado de cliente sai da sua rede para ser processado num servidor de terceiros. Para equipas que lidam com informação sensível, contratos, dados de saúde ou código-fonte proprietário, isto elimina uma categoria inteira de risco associada a enviar esse conteúdo para uma API externa. Ainda assim, correr localmente não elimina todos os riscos de segurança relacionados com LLMs.

A API REST do Ollama, por defeito, não tem autenticação. Se o serviço ficar acessível numa rede partilhada ou for exposto acidentalmente à internet através de um reencaminhamento de porta mal configurado, qualquer pessoa na mesma rede consegue enviar pedidos ao seu modelo e, dependendo da integração, aceder a dados que o modelo tenha em contexto. A prática recomendada é vincular o serviço apenas a 127.0.0.1 em ambientes de desenvolvimento e colocar sempre um proxy com autenticação à frente antes de expor a API a qualquer rede mais ampla.

Vale também considerar o risco de injeção de prompt, que continua válido mesmo em modelos locais: se a sua aplicação injeta conteúdo de terceiros (emails recebidos, páginas web, ficheiros carregados por utilizadores) diretamente no contexto do Gemma 4 sem qualquer filtragem, um atacante pode incluir instruções escondidas nesse conteúdo para tentar manipular o comportamento do modelo. Trate sempre o texto vindo de fontes externas como não fiável e separe claramente, na estrutura do prompt, o que é instrução do sistema e o que é conteúdo de terceiros.

Por fim, verifique sempre a origem dos ficheiros GGUF antes de os descarregar. Prefira repositórios oficiais da Google ou de organizações verificadas como a Unsloth na Hugging Face, e confirme os hashes SHA-256 publicados quando disponíveis. Ficheiros de modelo de origem duvidosa podem, em teoria, ser modificados para incluir comportamento malicioso ou pesos comprometidos.

Quanto custa correr o Gemma 4 em casa vs usar uma API na cloud

Uma pergunta recorrente de quem chega a este tutorial é se compensa financeiramente investir em hardware local em vez de simplesmente pagar por tokens numa API gerida. A resposta depende do volume de uso. Para volumes baixos, testes pontuais ou protótipos, uma API paga por token quase sempre sai mais barata do que comprar uma GPU dedicada, porque não há custo inicial de hardware nem consumo elétrico contínuo.

Para volumes altos e previsíveis, como um chatbot interno com uso diário intenso, ou para casos em que os dados não podem, por razões legais ou contratuais, sair da infraestrutura da empresa, correr o Gemma 4 localmente amortiza o investimento em poucos meses e elimina a dependência de disponibilidade de um fornecedor externo. Uma GPU de consumo com 16 GB de VRAM, suficiente para o E4B ou para o 12B em quantização Q4, tem um custo de aquisição único e um consumo elétrico que, na maioria dos países europeus, fica muito abaixo do que se pagaria em tokens de API para o mesmo volume de pedidos ao longo de um ano.

O cálculo mais honesto inclui também o custo de engenharia: manter um serviço local exige monitorização, atualizações de dependências como a Transformers ou o llama.cpp, e alguém disponível para resolver problemas como os listados na secção de resolução de problemas. Se a sua equipa já tem experiência com DevOps e infraestrutura própria, esse custo é marginal. Se não tem, pode facilmente anular a poupança teórica em hardware.

Dicas avançadas para levar o Gemma 4 para produção

Depois de validar o modelo localmente, há um conjunto de ajustes que fazem diferença real num ambiente de produção. Primeiro, isole o Ollama ou o llama-server atrás de um proxy reverso com autenticação, já que a API por defeito não tem controlo de acesso. Segundo, monitorize o tempo de resposta por tamanho de modelo: muitas equipas descobrem que o 26B-A4B, por usar arquitetura Mixture of Experts com apenas 3,8 mil milhões de parâmetros ativos por token, oferece uma relação custo-latência melhor do que o 31B denso para tarefas agente, mesmo tendo mais parâmetros no total.

Terceiro, para aplicações com muitos utilizadores simultâneos, considere o vLLM em vez do Ollama, já que o vLLM foi desenhado para servir múltiplos pedidos em paralelo com batching contínuo, ao contrário do modelo de um-pedido-de-cada-vez do Ollama em configuração por defeito. Quarto, se o seu caso de uso envolve chamadas de ferramentas em produção, teste sempre com tool_choice: "required" antes de expor o endpoint a tráfego real, dado o histórico de loops de repetição já documentado no llama.cpp. Por fim, mantenha um pipeline de avaliação automática que corra o mesmo conjunto de perguntas de teste sempre que atualizar a versão do modelo ou do runtime, para detetar regressões de qualidade antes que cheguem aos utilizadores finais.

Registe também métricas básicas de cada pedido, como o tamanho do prompt, o número de tokens gerados e o tempo total de resposta, mesmo que seja apenas para um ficheiro de log local. Estes dados tornam-se essenciais quando precisar de justificar uma mudança de tamanho de modelo ou de diagnosticar uma lentidão que só aparece sob carga real, algo que dificilmente se reproduz num teste manual isolado no terminal.

Gemma 4 vs Qwen3.8 vs DeepSeek V4: como se posiciona

Quem já testou outros modelos abertos vai querer saber onde o Gemma 4 se encaixa face à concorrência mais recente. A tabela seguinte compara as características publicamente confirmadas de cada família, sem misturar benchmarks que não foram medidos nas mesmas condições.

ModeloMaior tamanho abertoLicençaContexto máximo
Google Gemma 431B denso / 26B-A4B MoEApache 2.0256K tokens
Alibaba Qwen3.827B (Qwen3.8-27B)Apache 2.0262K tokens
DeepSeek V4V4-Pro / V4-FlashMIT (com pesos incluídos)Varia por variante

As três famílias partilham a mesma filosofia de licenciamento permissivo, sem royalties para uso comercial. A escolha entre elas depende menos da licença e mais do ecossistema de ferramentas já disponível: o Gemma 4 tem a vantagem de suporte nativo desde o dia zero no Unsloth e integração direta com o stack da Google Cloud, o que pesa para equipas que já usam Vertex AI ou Kaggle no dia a dia.

Na prática, muitas equipas acabam por manter mais do que um modelo em produção, usando o Gemma 4 E4B para latência baixa em tarefas simples e reservando o 31B ou uma API cloud para pedidos que exigem mais raciocínio. Esta abordagem híbrida evita o desperdício de correr sempre o modelo maior quando uma resposta simples não o justifica, e é a estratégia mais comum entre quem já testou os três ecossistemas em paralelo.

Perguntas frequentes sobre o Gemma 4

O Gemma 4 é grátis para uso comercial?

Sim. Todos os tamanhos do Gemma 4 são distribuídos sob licença Apache 2.0, que permite uso comercial sem pagamento de royalties, incluindo em produtos vendidos a clientes.

Qual é a diferença entre o Gemma 4 E2B e o E4B?

O E2B tem cerca de 2,3 mil milhões de parâmetros efetivos e foi otimizado para velocidade e baixa latência, sendo cerca de três vezes mais rápido do que o E4B em algumas medições internas da Google. O E4B, com 4,5 mil milhões efetivos, entrega respostas de qualidade superior à custa de mais tempo de resposta e mais VRAM.

Preciso de GPU para correr o Gemma 4?

Não é obrigatório. Os tamanhos E2B e E4B correm em CPU, embora com respostas mais lentas. Para os tamanhos 12B, 26B-A4B e 31B, uma GPU torna a experiência utilizável em tempo real.

O Ollama e o llama.cpp dão os mesmos resultados?

Ambos usam o mesmo motor de inferência baseado em GGUF por baixo, por isso os resultados devem ser equivalentes para o mesmo nível de quantização. A diferença está na conveniência: o Ollama gere o download e o serviço automaticamente, enquanto o llama.cpp dá mais controlo sobre flags de compilação e parâmetros de execução.

Posso fazer fine-tuning do Gemma 4 sem GPU própria?

Sim, para os tamanhos mais pequenos. O Unsloth disponibiliza notebooks oficiais no Google Colab que correm em GPUs T4 gratuitas, suficientes para um treino LoRA do E2B ou do E4B.

Porque é que o meu modelo entra em loop ao usar chamadas de ferramentas?

Este é um problema já documentado no llama.cpp (issue #21375) quando o parser de chamadas de ferramentas não tem restrições suficientes. Definir parallel_tool_calls: false e um limite de max_tokens costuma resolver.

Qual a diferença entre o Gemma 4 12B Unified e os outros tamanhos?

O 12B Unified é o único desenhado como modelo multimodal encoder-free, pensado para portáteis, e foi anunciado como atualização separada dos quatro tamanhos originais lançados em abril de 2026.

O Gemma 4 substitui o Gemini nas aplicações da Google?

Não. O Gemini continua a ser o modelo de topo da Google, servido apenas via API. O Gemma 4 é a versão aberta e mais pequena, pensada para quem quer correr o modelo em hardware próprio ou personalizá-lo via fine-tuning, não para substituir o Gemini em capacidade máxima.