Em agosto de 2026 há praticamente um modelo de linguagem novo a cada dois dias, segundo os rastreadores de lançamentos da indústria. Entre eles, dois nomes mudaram a conversa sobre onde correr esses modelos: o DeepSeek V4 Flash, lançado a 31 de julho sob licença MIT, e o Muse Glimmer 30B da Meta, que chegou a 10 de agosto com licença Apache 2.0. Ambos são open-weight, o que significa que qualquer pessoa pode descarregar os pesos e correr o modelo na própria máquina, sem depender de uma API paga nem enviar dados para servidores de terceiros.

O problema é que “descarregar os pesos” não é trivial sem a ferramenta certa. É aqui que entra o Ollama, um runtime open source que embrulha a complexidade de correr LLMs (gestão de memória, quantização, servidor HTTP) num punhado de comandos de terminal. O projeto ultrapassou as 178 mil estrelas no repositório oficial no GitHub em agosto de 2026, segundo dados do star-history.com, tornando-se a porta de entrada mais popular para quem quer IA local na Europa e em Portugal.

Este guia mostra, passo a passo, como instalar o Ollama, escolher o modelo certo para o teu hardware, configurar quantização, criar um Modelfile personalizado e construir uma aplicação funcional que fala com o modelo através da API REST local. No final, vais ter um assistente de linha de comandos completo, feito em Node.js, a correr inteiramente na tua máquina.

O Que É o Ollama e Porque Está a Dominar os LLMs Locais

O Ollama é um runtime local para modelos de linguagem que gere o download, a quantização e a execução de modelos open-weight através de uma interface de linha de comandos e de uma API REST compatível com o formato usado por clientes OpenAI. Em vez de configurares manualmente CUDA, PyTorch e scripts de inferência, corres um único instalador e ficas com um servidor a escutar em localhost:11434.

O crescimento do projeto acompanha uma mudança de fundo no mercado de IA. Até há pouco tempo, os modelos mais capazes ficavam trancados atrás de APIs fechadas (GPT, Claude, Gemini). Em 2026 isso mudou: a Meta reverteu a sua estratégia de pesos fechados e lançou o Muse Glimmer sob Apache 2.0, a DeepSeek continua a publicar a família V4 sob MIT, e a Alibaba abriu o Qwen3.8-Max ao público a 3 de agosto. Cada um destes lançamentos é candidato a correr dentro do Ollama assim que entra na biblioteca oficial.

Isto não quer dizer que os modelos fechados tenham perdido relevância. GPT, Claude e Gemini continuam à frente em muitos benchmarks de raciocínio complexo, e para tarefas críticas em produção continuam a ser a escolha mais segura. O que mudou é a existência de uma alternativa credível para quem não quer, ou não pode, enviar dados sensíveis para um servidor externo. Um escritório de advogados, uma clínica ou uma equipa de desenvolvimento que lida com código proprietário ganham com a opção de correr um modelo competente sem esse dado sair do edifício.

Para empresas e programadores em Portugal, correr modelos localmente resolve três problemas de uma vez: custo previsível (sem faturação por token), latência mais baixa numa rede local, e conformidade mais simples com o RGPD, porque nenhum dado sai da máquina. Não é por acaso que o tema aparece cada vez mais junto de discussões sobre o AI Act europeu e as suas exigências de transparência.

Há ainda uma razão prática que pesa tanto quanto as outras três: a maioria dos modelos open-weight de 2026 já está disponível no Hugging Face, o maior repositório público de pesos de IA, mas descarregar um ficheiro de lá e pô-lo a correr de forma eficiente exige normalmente escrever o teu próprio código de inferência. O Ollama elimina esse passo ao empacotar o motor de inferência, a gestão de quantização e um servidor HTTP num único binário. Isso reduz o tempo entre “vi este modelo novo lançado hoje” e “estou a conversar com ele no meu terminal” de horas para minutos.

Pré-Requisitos: Hardware, Software e Versões

Antes de instalar seja o que for, confirma que a tua máquina cumpre o mínimo para o tamanho de modelo que queres correr. Estes valores baseiam-se em quantização de 4 bits (Q4_K_M), a opção recomendada para a maioria dos utilizadores consumer:

  • Sistema operativo: Linux (qualquer distribuição recente com kernel 5.x+), macOS 13 ou superior, ou Windows 10/11 de 64 bits
  • Ollama: versão mais recente disponível em ollama.com/download (o instalador atualiza automaticamente)
  • RAM: mínimo 8 GB para modelos de 7B, 16 GB para 13B, 32 GB para 30B, 64 GB para 70B
  • GPU (opcional mas recomendada): NVIDIA com drivers CUDA atualizados, AMD com ROCm, ou Apple Silicon com memória unificada
  • Espaço em disco: pelo menos 20 GB livres para um primeiro modelo de 7B-13B em Q4, mais se pensares guardar vários modelos
  • Docker (opcional): versão mais recente, apenas se quiseres correr o Ollama em contentor
  • Node.js: versão 20 LTS ou superior, necessário apenas para a aplicação de exemplo deste guia

Não precisas de GPU para começar. O Ollama corre em CPU, mas a diferença de velocidade é enorme: um modelo de 7B numa GPU com 8 GB de VRAM responde a dezenas de tokens por segundo, enquanto o mesmo modelo em CPU pode demorar vários segundos por frase.

Passo 1: Preparar o Sistema Operativo

Antes do instalador, faz três verificações rápidas. Primeiro, confirma que tens espaço em disco suficiente com df -h no Linux/macOS ou o Explorador de Ficheiros no Windows. Segundo, se tens uma GPU NVIDIA, confirma que os drivers estão instalados correndo nvidia-smi num terminal, o comando deve devolver o modelo da placa e a versão do driver. Terceiro, fecha qualquer outro processo que já esteja a usar a porta 11434, já que é essa a porta por omissão do servidor Ollama.

Se estiveres num portátil, liga-o à corrente antes de descarregares modelos grandes. Um download de 20 GB interrompido a meio obriga a recomeçar, e a inferência sustentada consome mais energia do que a maioria das aplicações do dia a dia.

Passo 2: Instalar o Ollama em Linux, macOS e Windows

O processo de instalação muda ligeiramente por sistema operativo, mas o resultado final é sempre o mesmo: um binário ollama disponível no terminal e um serviço em segundo plano pronto a receber pedidos.

Linux

No Linux, um único comando trata da instalação completa:

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

O script deteta automaticamente se tens uma GPU NVIDIA ou AMD compatível e instala os componentes necessários. No final, o Ollama fica registado como serviço systemd e arranca sozinho no boot seguinte.

macOS

Em macOS há duas vias. A mais rápida para quem já usa Homebrew:

brew install ollama

Em alternativa, descarrega o instalador .dmg a partir de ollama.com/download, arrasta o ícone Ollama para a pasta Aplicações e abre a app. Ela fica residente na barra de menu e o serviço arranca automaticamente.

Windows

No Windows, descarrega o OllamaSetup.exe a partir da página de downloads oficial e corre o instalador com as opções por omissão. O Ollama fica instalado em C:\Users\%USERNAME%\.ollama e o serviço arranca em segundo plano sem precisares de abrir mais nada.

Se preferires seguir a documentação oficial passo a passo em vez do resumo acima, o guia rápido oficial do Ollama cobre casos específicos, como instalações sem privilégios de administrador ou máquinas atrás de proxy corporativo.

Em qualquer um dos três sistemas, confirma a instalação com o mesmo comando:

ollama --version

Se o terminal devolver um número de versão em vez de “comando não encontrado”, a instalação correu bem.

Passo 3: Verificar a Instalação e Comandos Essenciais

O Ollama tem uma dúzia de comandos, mas usarás sobretudo estes sete no dia a dia:

ComandoFunçãoExemplo
ollama pullDescarrega um modelo sem o correrollama pull llama3.1:8b
ollama runDescarrega (se necessário) e abre uma sessão interativaollama run llama3.1:8b
ollama listLista os modelos já instalados localmenteollama list
ollama psMostra os modelos atualmente carregados em memóriaollama ps
ollama rmRemove um modelo do discoollama rm llama3.1:8b
ollama serveArranca o servidor manualmente (útil em Docker)ollama serve &
ollama createCria um modelo personalizado a partir de um Modelfileollama create meu-modelo -f Modelfile

Na maioria das distribuições Linux e no Windows, o serviço já arranca sozinho, por isso não precisas de correr ollama serve manualmente. Esse comando só é relevante quando corres o Ollama dentro de um contentor Docker ou quando desativaste o arranque automático.

Há ainda um comando que vale a pena memorizar cedo: ollama show, seguido do nome do modelo, devolve detalhes como o número de parâmetros, o formato de quantização e o tamanho do contexto configurado. É a forma mais rápida de confirmares exatamente que versão de um modelo tens instalada, sem teres de abrir o Modelfile ou consultar a biblioteca online.

Passo 4: Descarregar e Correr o Primeiro Modelo

Para o primeiro teste, escolhe sempre um modelo pequeno, mesmo que tenhas hardware topo de gama. Isto confirma que a instalação está correta antes de gastares tempo a descarregar um modelo de 20 GB:

ollama run llama3.1:8b

Na primeira execução, o Ollama descarrega o modelo (cerca de 4,7 GB em Q4_K_M) e abre de imediato uma sessão de conversa no terminal. Escreve uma pergunta e observa a resposta a ser gerada em tempo real, token a token. Para sair da sessão, escreve /bye.

Exemplo de saída típica logo após o comando:

pulling manifest
pulling 8934d96d3f08... 100% ▕████████████████▏ 4.7 GB
pulling 8c17c2ebb0ea... 100% ▕████████████████▏  7.0 KB
verifying sha256 digest
writing manifest
success
>>> Send a message (/? for help)

Depois de confirmares que tudo funciona, remove o modelo de teste se não precisares dele com ollama rm llama3.1:8b, ou mantém-no como modelo de reserva rápido para tarefas simples.

Passo 5: Escolher o Modelo Certo para o Teu Hardware

A biblioteca do Ollama cresce quase todas as semanas. Em agosto de 2026, os três lançamentos open-weight mais relevantes para quem procura desempenho sem depender de uma API paga são estes:

ModeloCriadorLançamentoLicençaContextoMelhor para
DeepSeek V4 Flash 0731DeepSeek31 jul. 2026MIT1M tokensProgramação a baixo custo
Muse Glimmer 30BMeta10 ago. 2026Apache 2.0128K tokensMultimodal (texto + imagem) numa única GPU
Qwen3.8-MaxAlibaba2-3 ago. 2026Não divulgada nos materiais oficiaisNão divulgadoClusters com múltiplas GPUs (2,4 biliões de parâmetros totais, 95 mil milhões ativos)
Llama 3.1 8BMeta2024Comunidade Llama128K tokensPrimeiro teste, hardware modesto

Para a maioria dos utilizadores domésticos ou de pequenas equipas, o Muse Glimmer 30B é o ponto de equilíbrio mais interessante em 2026: corre numa única GPU de 24-32 GB ou num Mac topo de gama, aceita imagens como input, e usa uma licença Apache 2.0 sem as restrições que a Meta tinha imposto a versões anteriores da família Llama. Já o DeepSeek V4 Flash compensa em tarefas de código graças ao contexto de 1 milhão de tokens e ao preço de referência de cerca de 0,14 dólares por milhão de tokens quando usado via API, útil como comparação de custo quando decides entre correr localmente ou pagar por pedido.

Confirma sempre na biblioteca oficial (ollama.com/library) se o modelo que procuras já está publicado antes de tentares um ollama pull. Nem todos os lançamentos chegam ao Ollama no mesmo dia em que saem os pesos originais no Hugging Face. A página oficial de IA da Meta e o site da DeepSeek costumam anunciar o lançamento dos pesos antes de estes chegarem convertidos para GGUF, por isso vale a pena acompanhar as duas fontes se quiseres ser dos primeiros a testar um modelo novo.

Outro fator a pesar na escolha é o tipo de tarefa que vais correr com mais frequência. Para revisão de código e refactoring, o contexto alargado do DeepSeek V4 Flash permite carregar ficheiros inteiros ou até um pequeno repositório na mesma conversa, algo que um modelo com contexto de 8K ou 16K simplesmente não consegue. Para tarefas que combinam texto e imagem, como analisar uma captura de ecrã de um erro ou descrever um diagrama de arquitetura, o Muse Glimmer é a escolha óbvia porque a maioria dos modelos open-weight ainda não processa imagens nativamente.

Passo 6: Perceber Quantização e Requisitos de VRAM

Quantização é a técnica que reduz a precisão numérica dos pesos de um modelo (de 16 ou 32 bits para 4, 5 ou 8 bits) para ocupar menos memória, ao custo de uma pequena perda de qualidade. O Ollama usa maioritariamente formatos GGUF, identificados por sufixos como Q4_K_M, Q5_K_M ou Q8_0.

Como regra prática, um modelo em Q4 ocupa cerca de 0,6 GB de VRAM por cada mil milhões de parâmetros. Isto dá a seguinte tabela de referência:

Tamanho do modeloRAM mínimaVRAM (Q4_K_M)Disco aproximado
7B8 GB4-6 GB4-5 GB
13B16 GB8-10 GB8 GB
27-30B32 GB16-20 GB18-20 GB
70B64 GB40-48 GB40 GB+

Q4_K_M é o ponto de equilíbrio recomendado para a generalidade dos casos: mantém a qualidade de resposta muito próxima da versão original e cabe em GPUs consumer. Q8_0 duplica aproximadamente o consumo de memória face a Q4 para o mesmo modelo, e só compensa se tiveres VRAM de sobra e precisares da máxima fidelidade possível, por exemplo em tarefas de tradução técnica ou geração de código crítico.

Uma RTX 4090 com 24 GB de VRAM cobre confortavelmente modelos de 7B e 13B em Q4, e ainda consegue correr um 30B se aceitares um contexto mais curto. Já uma GPU de 8 GB, comum em portáteis de gama média, fica limitada a modelos de 7B em Q4_K_M sem margem de manobra. Se o teu hardware ficar entre estes dois extremos, começa sempre pela quantização mais agressiva e só sobes para Q5 ou Q8 se notares perda de qualidade nas respostas que realmente importam para o teu caso de uso.

Para escolher a quantização de um modelo específico, adiciona o sufixo ao nome ao fazer o pull:

ollama pull llama3.1:8b-instruct-q4_K_M
ollama pull llama3.1:8b-instruct-q8_0

Passo 7: Criar um Modelfile Personalizado

Um Modelfile funciona como um Dockerfile, mas para modelos de IA: define o modelo base, o prompt de sistema e parâmetros de execução num único ficheiro de texto. É a forma correta de fixar um comportamento (por exemplo, “responde sempre em português europeu”) sem repetires instruções em cada conversa.

Cria um ficheiro chamado Modelfile (sem extensão) com este conteúdo:

FROM llama3.1:8b

SYSTEM Responde sempre em português de Portugal, de forma direta e técnica.

PARAMETER temperature 0.3
PARAMETER num_ctx 8192
PARAMETER num_gpu_layers 35

Depois de guardares o ficheiro, cria o modelo personalizado com:

ollama create assistente-pt -f Modelfile
ollama run assistente-pt

A partir daqui, assistente-pt passa a aparecer em ollama list como se fosse mais um modelo da tua biblioteca, mas já com o prompt de sistema e os parâmetros fixados.

Passo 8: Usar a API REST do Ollama

O verdadeiro valor do Ollama para quem programa está na API HTTP local, que corre por omissão na porta 11434 e aceita pedidos de qualquer linguagem capaz de fazer um pedido HTTP. Testa com curl:

curl -X POST http://localhost:11434/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.1:8b",
    "prompt": "Explica em duas frases o que é quantização Q4.",
    "stream": false
  }'

A resposta chega em JSON, com o texto gerado no campo response:

{
  "model": "llama3.1:8b",
  "created_at": "2026-08-14T10:32:11Z",
  "response": "Quantização Q4 reduz a precisão dos pesos do modelo para 4 bits, cortando o uso de memória sem alterar a arquitetura. O resultado é um modelo mais pequeno e mais rápido, com uma perda de qualidade quase impercetível na maioria das tarefas.",
  "done": true
}

Por omissão, stream vem a true, o que devolve a resposta em vários blocos JSON separados por linha, à medida que os tokens são gerados. Para aplicações simples que só precisam do texto final, define "stream": false como no exemplo acima.

Passo 9: Construir uma Aplicação Completa – Assistente CLI em Node.js

Com o servidor a correr e a API testada, o passo seguinte é ligar tudo a uma aplicação real. Este projeto cria um assistente de linha de comandos em Node.js que mantém histórico de conversa e fala com o Ollama local.

Cria uma pasta nova, inicializa o projeto e instala a única dependência necessária:

mkdir assistente-ollama && cd assistente-ollama
npm init -y
npm install node-fetch@3

Cria o ficheiro assistente.js com o seguinte conteúdo:

import readline from "node:readline/promises";
import { stdin, stdout } from "node:process";
import fetch from "node-fetch";

const OLLAMA_URL = "http://localhost:11434/api/chat";
const MODEL = "llama3.1:8b";
const historico = [
  { role: "system", content: "Responde sempre em português de Portugal." }
];

async function perguntar(texto) {
  historico.push({ role: "user", content: texto });

  const resposta = await fetch(OLLAMA_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ model: MODEL, messages: historico, stream: false })
  });

  if (!resposta.ok) {
    throw new Error(`Ollama respondeu com estado ${resposta.status}`);
  }

  const dados = await resposta.json();
  historico.push(dados.message);
  return dados.message.content;
}

async function iniciar() {
  const rl = readline.createInterface({ input: stdin, output: stdout });
  console.log("Assistente local pronto. Escreve 'sair' para terminar.\n");

  while (true) {
    const entrada = await rl.question("Tu: ");
    if (entrada.trim().toLowerCase() === "sair") break;

    const resposta = await perguntar(entrada);
    console.log(`\nAssistente: ${resposta}\n`);
  }

  rl.close();
}

iniciar();

Corre a aplicação com:

node assistente.js

Repara que o endpoint usado aqui é /api/chat, não /api/generate. A diferença importa: /api/chat aceita um array de mensagens com papéis (system, user, assistant) e mantém o contexto da conversa automaticamente, enquanto /api/generate trata cada pedido como isolado. Para um assistente com memória, /api/chat é sempre a escolha certa.

Passo 10: GPU, Docker e Ajustes de Desempenho

Se tens uma GPU e as respostas continuam lentas, o problema está normalmente em quantas camadas do modelo ficam na placa gráfica. O parâmetro num_gpu_layers, que já viste no Modelfile, controla exatamente isso: quanto mais alto, mais camadas saem da CPU e entram na GPU, até ao limite da VRAM disponível.

Também podes ajustar estes parâmetros diretamente num pedido à API, sem editar o Modelfile:

curl -X POST http://localhost:11434/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.1:8b",
    "prompt": "Resume as vantagens de correr LLMs localmente.",
    "options": { "num_ctx": 8192, "num_gpu_layers": 35 }
  }'

Correr o Ollama em Docker

Para quem prefere isolar o serviço num contentor, por exemplo num servidor partilhado, a imagem oficial trata da instalação:

docker run -d --gpus=all -v ollama:/root/.ollama \
  -p 11434:11434 --name ollama ollama/ollama

docker exec -it ollama ollama pull llama3.1:8b

A flag --gpus=all só funciona se tiveres o NVIDIA Container Toolkit instalado no host. Sem GPU, remove a flag e o contentor cai automaticamente para inferência em CPU, mais lenta mas funcional. Guarda sempre os modelos num volume Docker nomeado, como no exemplo acima, para não perderes os pesos descarregados de cada vez que recrias o contentor.

Passo 11: Proteger o Acesso à API do Ollama

Por omissão, a API do Ollama escuta apenas em localhost, o que já protege a maioria das instalações domésticas. O risco aparece quando alguém expõe o serviço à rede (por exemplo, definindo OLLAMA_HOST=0.0.0.0 para o aceder a partir de outro dispositivo) sem adicionar qualquer autenticação. Sem uma camada extra, qualquer máquina na mesma rede, ou em casos piores na internet, consegue enviar pedidos e consumir a tua GPU.

A forma mais simples de mitigar isto é colocar o Ollama atrás de um proxy reverso (Nginx ou Caddy) com autenticação básica ou um token, e nunca expor a porta 11434 diretamente à internet. Se precisares de TLS entre serviços internos, o guia sobre mTLS em Node.js com TLS 1.3 mostra como configurar certificados mútuos para chamadas API-a-API, um padrão útil quando a tua aplicação e o servidor Ollama correm em máquinas diferentes da mesma rede.

Vale ainda lembrar que correr um modelo localmente não elimina riscos de prompt injection se a tua aplicação processar texto vindo de fontes externas (páginas web, PDFs, emails). As técnicas de mitigação são as mesmas que se aplicam a qualquer LLM, incluindo os que correm atrás de uma API paga, como descrito no guia sobre como bloquear prompt injection em aplicações Node.js.

Erros Comuns e Resolução de Problemas

Estes são os problemas que mais aparecem em instalações reais, com a causa provável e a correção:

  • “CUDA out of memory” ao correr um modelo: o modelo escolhido é grande demais para a VRAM disponível. Muda para um modelo mais pequeno ou para uma quantização mais agressiva (Q4_K_M em vez de Q8_0).
  • “address already in use” na porta 11434: já existe um processo Ollama a correr. Confirma com ollama ps e termina a instância antiga antes de arrancar outra.
  • “model not found” ao correr um modelo: o nome ou a tag não correspondem exatamente ao que está na biblioteca. Confirma com ollama list e usa sempre o nome completo, incluindo a tag (por exemplo llama3.1:8b, não apenas llama3.1).
  • Respostas muito lentas mesmo com GPU: o modelo pode estar a correr parcialmente ou totalmente em CPU. Confirma com ollama ps, que mostra quanto do modelo está carregado em VRAM.
  • Download interrompido a meio: corre novamente o mesmo ollama pull. O Ollama retoma o download a partir do último bloco verificado em vez de recomeçar do zero.
  • Serviço não arranca após reiniciar o computador: no Linux, confirma o estado do serviço com systemctl status ollama e reativa-o com systemctl enable ollama se necessário.
  • Erro de permissões ao aceder a ~/.ollama: costuma acontecer quando o Ollama foi instalado uma vez como root e depois usado por um utilizador normal. Corrige a posse da pasta com chown -R $USER ~/.ollama.
  • API devolve HTML em vez de JSON: normalmente sinal de que o pedido foi enviado para a porta errada ou para um caminho inexistente. Confirma que o URL termina em /api/generate ou /api/chat, não apenas em /.

Armadilhas Mais Comuns a Evitar

Além dos erros técnicos, há hábitos que custam tempo e espaço em disco sem gerar nenhum benefício real:

  • Descarregar o maior modelo possível “para garantir qualidade”: um modelo de 70B que passa metade do tempo a trocar dados entre RAM e disco é mais lento do que um modelo de 13B totalmente carregado em VRAM. Escolhe o tamanho que cabe confortavelmente no teu hardware.
  • Ignorar a tag de quantização ao fazer pull: sem especificares a tag, o Ollama usa a quantização por omissão da biblioteca, que nem sempre é a mais equilibrada para o teu caso de uso.
  • Deixar vários modelos grandes instalados sem necessidade: cada modelo em Q4 de 13B ocupa cerca de 8 GB em disco. É fácil esgotar espaço sem perceber, sobretudo em portáteis com SSD de 256 GB.
  • Expor a API à rede sem autenticação: como referido no passo 11, isto transforma a tua GPU num recurso partilhado sem controlo.
  • Usar num_ctx muito alto “por segurança”: um contexto de 32K ou 128K quando a tarefa só precisa de 4K desperdiça memória que podia ir para camadas do modelo na GPU, tornando tudo mais lento.

Dicas Avançadas para Produção

Depois de dominares o básico, há ajustes que fazem diferença real em ambientes com mais do que um utilizador ou mais do que um modelo em uso.

Define OLLAMA_NUM_PARALLEL como variável de ambiente para controlar quantos pedidos simultâneos o servidor aceita por modelo, útil quando várias pessoas da mesma equipa partilham a mesma máquina com GPU. Usa OLLAMA_MAX_LOADED_MODELS para limitar quantos modelos diferentes ficam em memória ao mesmo tempo, evitando que a troca constante entre modelos (model swapping) prejudique a latência.

Para cargas de trabalho de código, combina um modelo generalista (Muse Glimmer ou Llama) para conversas gerais com um modelo especializado (DeepSeek V4 Flash) só para tarefas de programação, e troca entre eles no lado da aplicação consoante o tipo de pedido. Isto evita manter um único modelo grande carregado o tempo todo quando só uma fração dos pedidos precisa da capacidade extra.

Por fim, se pensas colocar isto em produção a sério, mede sempre o desempenho real no teu hardware antes de assumires números publicados noutros artigos. As figuras de tokens por segundo variam muito consoante driver, versão do kernel e até temperatura da GPU sob carga sustentada, um simples script que corre 50 pedidos e mede a média dá uma base muito mais fiável do que qualquer benchmark genérico.

Vale também a pena automatizar o arranque de modelos que uses todos os dias. Em vez de escreveres ollama run manualmente de cada vez, cria um pequeno script de arranque que faz o pull do modelo (caso ainda não exista em disco) e confirma que o serviço está ativo antes de a tua aplicação começar a enviar pedidos. Isto evita o erro clássico de a aplicação arrancar mais depressa do que o modelo fica carregado em memória, resultando num primeiro pedido a falhar por timeout.

Se a tua equipa partilha modelos personalizados (Modelfiles com prompts de sistema específicos para cada projeto), guarda esses ficheiros num repositório Git junto do resto do código. Um Modelfile pesa poucos kilobytes e a diferença entre versões é fácil de rever num pull request, ao contrário dos pesos do modelo em si, que devem ficar fora do controlo de versões pelo tamanho.

Ollama vs Alternativas: LM Studio, llama.cpp e vLLM

O Ollama não é a única forma de correr LLMs localmente, e vale a pena perceber onde se encaixa face às alternativas mais usadas.

O llama.cpp é o motor de inferência que o próprio Ollama usa por baixo, mas exposto diretamente, sem a camada de gestão de modelos e sem servidor HTTP embutido por omissão. Escolher llama.cpp em vez de Ollama faz sentido quando precisas de controlo fino sobre cada flag de compilação ou queres correr em hardware muito específico sem a camada extra.

O LM Studio cobre o mesmo objetivo do Ollama mas com interface gráfica em vez de terminal, mais amigável para quem não quer usar linha de comandos, embora com menos flexibilidade para automatizar através de scripts.

O vLLM joga noutra liga: é pensado para servir muitos pedidos simultâneos em produção, com técnicas de batching contínuo que o tornam mais rápido que o Ollama em cenários de alto volume, mas exige mais configuração inicial e normalmente uma GPU dedicada em servidor, não um portátil.

Para experimentação individual, prototipagem rápida e a maioria das aplicações de pequena e média escala, o Ollama continua a ser o ponto de partida mais direto: instalação em minutos, biblioteca de modelos atualizada com frequência e uma API simples o suficiente para integrar em qualquer linguagem.

Uma forma prática de decidir é pensar em três perguntas. Quantos pedidos simultâneos vais servir? Um a dez, o Ollama resolve sem esforço, acima disso o vLLM começa a fazer diferença real. Precisas de interface gráfica para pessoas não técnicas testarem modelos? O LM Studio poupa-te tempo de suporte. Precisas de controlar cada detalhe da compilação para hardware exótico? Só o llama.cpp direto te dá esse nível de acesso.

Perguntas Frequentes

O Ollama é gratuito?
Sim, o Ollama é open source e gratuito. Os custos que possas ter vêm apenas do hardware (GPU, RAM, eletricidade), não da ferramenta em si.

Preciso de GPU para usar o Ollama?
Não. O Ollama corre em CPU, mas a velocidade cai bastante face a uma GPU dedicada, sobretudo em modelos acima de 13B parâmetros.

Os meus dados saem da minha máquina ao usar o Ollama?
Não, desde que corras o servidor localmente e não o exponhas à internet. Todo o processamento acontece na tua máquina, sem chamadas externas.

Qual a diferença entre /api/generate e /api/chat?
/api/generate trata cada pedido de forma isolada, sem memória. /api/chat aceita um histórico de mensagens com papéis e mantém o contexto da conversa.

Posso correr o DeepSeek V4 Flash e o Muse Glimmer 30B no Ollama?
Consegues assim que os modelos estiverem publicados na biblioteca oficial do Ollama. Confirma sempre em ollama.com/library antes de tentares o pull, porque a disponibilidade depende de cada equipa publicar os pesos convertidos para GGUF.

Qual a diferença entre Q4_K_M e Q8_0?
Q4_K_M usa cerca de metade da memória de Q8_0 para o mesmo modelo, com uma perda de qualidade normalmente impercetível na conversa do dia a dia. Q8_0 vale a pena apenas quando tens VRAM de sobra e precisas da máxima fidelidade possível.

O Ollama funciona sem ligação à internet depois de instalado?
Sim, depois de descarregares um modelo, a inferência corre inteiramente offline. Só precisas de internet para instalar o Ollama e para fazer o pull de novos modelos.

Como atualizo o Ollama para a versão mais recente?
No Linux e macOS, corre novamente o comando de instalação (curl -fsSL https://ollama.com/install.sh | sh ou brew upgrade ollama). No Windows, descarrega e corre de novo o instalador a partir de ollama.com/download.

Este guia cobriu a instalação, a escolha de modelo, a quantização, a criação de um Modelfile e a construção de uma aplicação funcional em Node.js. A partir daqui, o próximo passo natural é experimentar diferentes combinações de modelo e quantização até encontrares o equilíbrio certo entre velocidade e qualidade para o teu hardware específico, e talvez avaliar se algum dos modelos mais recentes, como o Muse Glimmer 30B, compensa o upgrade de GPU face à alternativa de continuar num modelo mais pequeno.