Ollama: rodar modelo de IA local no seu computador

A conversa começa quase sempre do mesmo jeito. Alguém da equipe quer resumir um contrato, classificar chamados antigos ou revisar um texto com ajuda de um modelo de linguagem, e o jurídico responde que aquele arquivo não pode subir para servidor de terceiro.

Vem então a pergunta prática: dá para rodar isso aqui dentro, na máquina da própria pessoa? Dá, e o Ollama é hoje o caminho mais curto. São dois comandos até a primeira resposta aparecer na tela, e nenhum deles pede que você compile código.

O que trava a conversa aparece depois da instalação, e tem nome: a memória livre da máquina que está na sua mesa.

Quanta memória de vídeo a sua máquina tem livre decide qual modelo você consegue rodar, e ele costuma pesar mais na escolha que a diferença de qualidade entre dois modelos abertos. O Ollama cuida da parte repetitiva, baixar os pesos e manter uma API no ar, e devolve para você a decisão que sobra: o tamanho que cabe.

Por que o Ollama ficou o caminho mais curto

Rodar um modelo aberto na própria máquina pedia, até pouco tempo atrás, três etapas separadas. Você compilava um motor de inferência, caçava o arquivo de pesos no formato certo e escrevia o laço que transforma aquilo numa conversa. Cada etapa tinha sua própria chance de dar errado, e a maioria das pessoas desistia na primeira.

O programa junta as três num binário só. A documentação oficial lista instalador para macOS, Windows e Linux, mais uma imagem Docker publicada pelo projeto. O motor de inferência por baixo é o llama.cpp, que o próprio projeto cita como backend suportado. A licença do código é MIT, de acordo com o arquivo de licença no repositório.

O efeito é simples de medir: a distância entre "quero testar" e "está respondendo" caiu para o tempo de download dos pesos. Isso mudou quem consegue experimentar modelos pequenos numa tarde de sexta.

Instalar e rodar: os comandos que você usa de verdade

A lista de comandos da documentação é curta, e você vive com quatro deles.

O primeiro é ollama pull gemma4:e2b, que baixa os pesos e para aí. Serve para preparar a máquina na véspera de uma apresentação, quando depender da rede do cliente seria arriscado.

O segundo é ollama run gemma4:e2b, que baixa o que estiver faltando e abre a conversa no terminal. Digitar /bye encerra a sessão.

Depois vem ollama ls, que mostra o que já está no disco. Você vai usar quando o SSD começar a reclamar, porque cada modelo ocupa gigabytes e o download antigo não se apaga sozinho. Para isso existe ollama rm.

No Linux, ollama serve sobe o servidor quando ele ainda não está no ar. No macOS e no Windows o aplicativo cuida disso ao abrir.

O que decide se o modelo roda bem na sua máquina

Um modelo é um arquivo grande de números, e ele precisa estar na memória para responder rápido. Quando cabe inteiro na memória da placa de vídeo, a resposta sai fluida. Quando não cabe, parte dele vai para a RAM do sistema, e a velocidade cai de forma bem perceptível.

A documentação é direta nesse ponto. Para o Gemma 4 E2B, cujo download tem cerca de 7,2 GB, ela recomenda 8 GB de memória de vídeo livre, ou de memória unificada no caso dos Macs. Com menos que isso, o programa ainda funciona usando a RAM do sistema, só mais devagar. Janela de contexto maior também consome mais memória.

Para estimar sem instalar nada, olhe o tamanho do arquivo na biblioteca de modelos e reserve um pouco acima dele. A biblioteca publica esses números. O Qwen3 aparece em oito variantes: 523 MB na de 0,6 bilhão de parâmetros, 1,4 GB na de 1,7 bilhão, 5,2 GB na de 8 bilhões, 9,3 GB na de 14 bilhões, 20 GB na de 32 bilhões e 142 GB na de 235 bilhões.

Esses arquivos já vêm quantizados, com os pesos guardados em menos bits do que no arquivo de origem. É por isso que um modelo de 8 bilhões de parâmetros ocupa 5,2 GB em vez de algo perto de 16 GB. A quantização cobra um pouco de precisão e devolve muita memória, e é ela que coloca modelo decente num notebook de trabalho.

A API local e o motivo de ela imitar a OpenAI

Depois que o servidor sobe, a API do Ollama fica em localhost, na porta 11434. A documentação lista ali a rota própria do projeto, em /api/chat, e também rotas compatíveis com o formato da OpenAI, em /v1.

Essa compatibilidade é o detalhe que mais economiza trabalho. Você aponta o endereço base do seu cliente para http://localhost:11434/v1/, preenche a chave de API com qualquer texto (o servidor local ignora esse campo) e o código que já falava com a nuvem passa a falar com a sua máquina. A documentação lista suporte a /v1/chat/completions, /v1/completions, /v1/responses, /v1/models e /v1/embeddings, com ressalvas por rota.

Para quem monta ambiente interno, isso significa que uma interface de chat como a do LibreChat conversa com o seu servidor local sem adaptador no meio. O mesmo vale para plugin de editor de código e para automação que você já escreveu.

Ollama, LM Studio, llama.cpp ou API em nuvem

As quatro opções resolvem o mesmo pedido por caminhos diferentes, e a escolha costuma ser decidida por quem vai operar.

Quem gosta de janela gráfica e quer escolher modelo clicando tende a ficar no LM Studio. Quem precisa de controle fino de parâmetro de inferência vai para o llama.cpp, que é o motor por baixo das outras duas. Quem só quer um servidor local estável para o resto da equipe consumir fica com a primeira coluna. E quem precisa do modelo maior que existe não tem como fugir da quarta, porque ele não cabe em máquina de escritório.

O dado que não pode sair da rede

Esse é o motivo que faz empresa olhar para modelo local, e ele vale mais que economia de token. Quando o texto do contrato, o laudo ou a planilha de folha são processados na máquina de quem trabalha com eles, não existe terceiro recebendo cópia e não existe cláusula de retenção para interpretar.

A alternativa que acontece no silêncio é pior: funcionário colando dados da empresa no ChatGPT sem avisar ninguém. Oferecer um servidor interno que funciona bem resolve o problema pela porta da frente, porque remove o incentivo.

Vale separar duas coisas que se confundem. A licença do programa que serve o modelo e a licença dos pesos são independentes. O código do projeto é MIT, pelo arquivo de licença do repositório, enquanto cada modelo da biblioteca carrega a licença de quem o treinou. Antes de usar em produto, leia a segunda, assunto que também aparece quando se discutem alternativas abertas ao ChatGPT.

Como começar sem perder a tarde

1. Veja quanta memória de vídeo você tem livre. Esse número manda na escolha, e você precisa dele antes de baixar qualquer coisa.
2. Escolha um modelo cujo arquivo caiba nessa folga. A biblioteca mostra o tamanho do download ao lado de cada variante.
3. Baixe antes de precisar. O comando de download existe separado do de conversa justamente para isso.
4. Converse no terminal primeiro. Dez minutos de perguntas reais do seu trabalho dizem mais que qualquer benchmark de terceiro.
5. Só depois ligue a API. Aponte um cliente para http://localhost:11434/v1/ e confirme que a resposta chega antes de mexer em código.
6. Meça o que importa para você. Tempo até a primeira palavra, qualidade na sua tarefa e quanto a máquina esquenta com o modelo carregado.
7. Compare com um modelo aberto hospedado. Rodar o DeepSeek pela nuvem ajuda a calibrar o que você está perdendo em qualidade ao ficar no tamanho que cabe.

A parte difícil de rodar modelo aberto mudou de lugar. Baixar e servir virou tarefa de dois comandos, e o gargalo passou a ser físico: quanta memória de vídeo existe na máquina e qual arquivo cabe nela.

O número mais útil desta página é um tamanho de arquivo. O Qwen3 de 8 bilhões de parâmetros tem 5,2 GB de download, e a documentação recomenda 8 GB de memória de vídeo livre para um modelo dessa ordem. Olhe a especificação da sua placa de vídeo e você já sabe por onde começar a testar.