Como manter um modelo Ollama carregado na memória

Por que o Ollama descarrega o modelo depois de alguns minutos?

O Ollama mantém um modelo carregado na memória durante cinco minutos após o último pedido e, em seguida, liberta-o. O pedido seguinte tem de ler os pesos do disco e mapeá-los novamente para a RAM ou VRAM. Por isso, fica bloqueado antes de o primeiro token chegar. É por isso que uma interface de chat ou um agente de programação parece rápido, fica inativo durante algum tempo e volta a parecer lento na mensagem seguinte. Não há nenhuma avaria. O temporizador de inatividade expirou.

O temporizador chama-se keep_alive. É específico de cada modelo e reinicia sempre que um pedido termina. Um modelo que esteja a responder a um pedido nunca é descarregado, porque o servidor só expira um modelo sem pedidos ativos. Em agosto de 2026, o valor predefinido é cinco minutos e aplica-se a todos os modelos carregados por este servidor.

Há dois locais onde pode definir keep_alive: no pedido individual ou como predefinição do servidor. Um drop-in do systemd faz com que a predefinição do servidor seja mantida após um reinício. Este guia pressupõe que o Ollama já está a ser executado como serviço. Se não estiver, comece por instalar o Ollama num VPS e volte a este guia.

Quais modelos estão residentes agora e quando expiram?

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

Uma saída vazia significa que nada está carregado, portanto o próximo pedido terá de carregar o modelo integralmente. PROCESSOR indica onde os pesos foram carregados. 100% GPU e 100% CPU são os casos claros. Uma divisão como 25%/75% CPU/GPU significa que o modelo não coube na VRAM. Nesse caso, uma parte é executada no processador e a geração é mais lenta.

UNTIL é a contagem decrescente e apresenta um tempo relativo, como 4 minutes from now. Apresenta Forever quando o modelo foi carregado com um valor negativo em keep_alive. Apresenta Stopping... durante o breve período em que o servidor está a descarregar o modelo.

O conjunto de colunas mudou entre versões. Por isso, leia o cabeçalho em vez de contar campos num script. Para qualquer processo automatizado, consulte a API:

curl -s http://localhost:11434/api/ps

Cada entrada contém expires_at, um timestamp absoluto como 2026-08-09T14:38:31.83753Z, e size_vram, a parte desse modelo que está na memória da GPU. Um size_vram de 0 significa que o modelo está a ser executado no CPU.

O custo efetivo do reload

Não faça estimativas. O Ollama informa o tempo de carregamento em cada resposta, no campo load_duration, em nanossegundos.

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

A primeira chamada carrega o modelo, por isso o valor de load_duration é elevado. Divida-o por 1000000000 para o ler em segundos. A segunda chamada é executada enquanto o modelo permanece residente e apresenta um valor muito menor. A diferença entre esses dois valores é o custo suportado por cada utilizador depois de o temporizador expirar. É essa a razão para alterar keep_alive. Para consultar a velocidade de geração antes e depois dessa pausa, veja como medir tokens por segundo no seu próprio servidor.

Manter um modelo Ollama carregado na memória numa única requisição

Envie keep_alive com a requisição. Esta opção aplica-se a esse modelo a partir do momento em que a requisição termina.

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

São aceitos quatro formatos de valor:

• uma string de duração: "30m", "24h", "90s"
• um número simples, interpretado como segundos: 3600
• um valor negativo, -1 ou "-1m", que significa que não existe tempo limite de inatividade
• 0, que significa descarregar o modelo assim que esta requisição terminar

Um valor definido na requisição substitui o valor padrão do servidor, nos dois sentidos. Isto é mais importante do que parece: um cliente que envie o seu próprio keep_alive prevalece sobre qualquer configuração definida no servidor.

Também pode carregar um modelo sem gerar conteúdo. Envie apenas o nome do modelo. O servidor carrega o modelo e devolve uma resposta vazia com "done": true.

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

Esse é o comando a executar depois de um reboot ou depois de obter um modelo novo, para que a primeira requisição real de um utilizador não tenha de esperar pelo carregamento. A CLI faz o mesmo com uma opção:

ollama run --keepalive 30m qwen3:8b "hello"

Mantenha o modelo carregado por predefinição com OLLAMA_KEEP_ALIVE

O servidor lê OLLAMA_KEEP_ALIVE no arranque e usa esse valor para todos os modelos que não tenham um valor próprio. O parâmetro aceita os mesmos formatos que o campo do pedido, por isso 30m, 3600 e -1 funcionam.

O ponto crítico é definir a variável no ambiente correto. Executar export OLLAMA_KEEP_ALIVE=30m na sua sessão SSH não tem efeito, porque a instalação empacotada executa o servidor como um serviço systemd, com o seu próprio utilizador e ambiente. A sua shell de início de sessão e esse serviço nunca partilham o mesmo ambiente. Esta é a causa mais comum de a configuração parecer ser ignorada.

Faça a configuração sobreviver a um reinício com um drop-in do systemd

sudo systemctl edit ollama.service

O editor abre com dois marcadores de comentário. Escreva entre eles: o systemd descarta tudo o que for escrito abaixo do segundo marcador.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Ao guardar, é escrito /etc/systemd/system/ollama.service.d/override.conf. Isto é um drop-in, não uma edição da unidade fornecida pelo pacote. Assim, uma atualização do pacote Ollama que substitua ollama.service mantém a sua configuração. Se os drop-ins e os ficheiros de unidade forem novos para si, o guia de serviços e temporizadores do systemd explica estes mecanismos.

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

O último comando mostra o ambiente com que o serviço será realmente executado. Se OLLAMA_KEEP_ALIVE=30m não aparecer nessa linha, o drop-in não foi aplicado. A causa é quase sempre a ausência do cabeçalho [Service] ou a introdução de linhas abaixo do marcador. O reinício remove todos os modelos carregados, por isso o pedido seguinte fará um carregamento a frio. Aqueça o modelo com a chamada de pré-carregamento acima.

O custo de manter um modelo residente

A coluna SIZE em ollama ps representa a memória ocupada durante toda a janela de inatividade, e não apenas durante um pedido. Um modelo 8B com quantização de 4 bits ocupa cerca de 5 a 6 GB. Um modelo 27B é uma situação diferente, e vale a pena analisar o cálculo da memória para executar um modelo apenas com CPU num VPS antes de decidir mantê-lo residente. Definir keep_alive como -1 significa decidir que o modelo terá prioridade permanente sobre tudo o resto no servidor. Num VPS pequeno, isto compete diretamente com a sua base de dados, a sua aplicação web e os seus trabalhos de compilação.

Observe os valores reais em vez de confiar numa estimativa. Execute isto enquanto um modelo estiver carregado e repita depois de ollama stop:

free -h

A coluna available mostra a memória que o kernel ainda pode atribuir a um processo novo. Num servidor com GPU NVIDIA, nvidia-smi mostra a mesma situação na VRAM. Se o servidor ficar sem memória, o kernel termina um processo para recuperar recursos:

sudo dmesg -T | grep -i "out of memory"

Uma linha que indique ollama significa que o servidor do modelo foi a vítima. Uma linha que indique a sua base de dados significa que o modelo ganhou e que algo importante para si foi perdido. Ambos os resultados provêm da mesma decisão: uma janela de keep-alive longa num servidor sem margem de memória.

É fácil não considerar dois custos. Um comprimento de contexto maior reserva uma cache KV maior (key value cache, o estado de atenção por token que o modelo mantém durante a geração), e essa cache faz parte do tamanho residente. Um valor de OLLAMA_NUM_PARALLEL superior a 1 reserva essa cache uma vez por slot paralelo. Se pretende servir várias pessoas a partir de um único modelo, dimensione a memória para os slots, e não apenas para os pesos.

Um valor predefinido razoável: um modelo num servidor com margem de memória pode usar -1. Um servidor partilhado deve usar uma janela que cubra os intervalos entre os seus pedidos, como 30m, para que a memória seja libertada quando deixar de trabalhar.

Descarregar um modelo imediatamente

ollama stop qwen3:8b

O comando não devolve qualquer saída, e o modelo desaparece de ollama ps. Um nome que não esteja carregado devolve couldn't find model "qwen3:8b" to stop. Na API, faça um pedido sem prompt e defina keep_alive como 0:

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

A resposta inclui "done_reason": "unload". Use esta opção em vez de reiniciar o serviço. systemctl restart ollama também liberta a memória, mas remove todos os outros modelos carregados e termina qualquer pedido em execução.

Executar mais de um modelo no mesmo servidor

OLLAMA_MAX_LOADED_MODELS limita o número de modelos mantidos carregados ao mesmo tempo. Em agosto de 2026, o valor predefinido é três por GPU ou três num sistema apenas com CPU. O limite conta modelos, mas a memória é a limitação real. Por isso, um segundo modelo grande pode não ter memória disponível muito antes de chegar aos três modelos.

Quando é solicitado um modelo novo e não existe memória suficiente para o carregar, o agendador descarrega um dos modelos residentes para libertar espaço. Prefere um modelo sem pedidos ativos. Também pode expulsar um modelo cujo temporizador ainda não expirou, incluindo um modelo carregado com -1. Portanto, um valor negativo em keep_alive significa que não existe tempo limite de inatividade. Isso não fixa os pesos para impedir o carregamento de outro modelo.

Essa decisão é registada no nível de depuração. Adicione uma segunda linha Environment="OLLAMA_DEBUG=1" ao mesmo drop-in, reinicie o serviço e monitorize:

sudo journalctl -u ollama -f

Uma linha sobre o descarregamento de um runner para libertar espaço, junto do pedido que o desencadeou, indica que estes dois modelos não cabem simultaneamente nesta máquina. A solução é usar menos modelos neste servidor ou definir uma janela longa para o modelo que tem de responder rapidamente e 0 para o modelo que é chamado raramente.

Orientações que permanecem válidas após a próxima versão

Ollama lança versões com frequência e os valores predefinidos mudam. Por isso, verifique a compilação que está a utilizar em vez de memorizar números:

ollama --version
ollama serve --help

ollama serve --help apresenta as variáveis de ambiente que a compilação lê efetivamente, incluindo OLLAMA_KEEP_ALIVE. Duas regras mantiveram-se entre versões e são seguras para utilizar. Um valor definido no pedido tem precedência sobre o valor predefinido do servidor. E ollama ps é a fonte de verdade sobre o que está carregado, independentemente do que um ficheiro de configuração indique.

Se um editor ou um agente controlar o servidor, verifique o que esse cliente envia antes de atribuir a causa ao servidor. Configurar um agente de programação para utilizar o seu próprio servidor Ollama explica onde essas definições do pedido ficam.

FAQ

Por que o Ollama descarrega o meu modelo depois de 5 minutos?

Cinco minutos é o valor predefinido de keep_alive, o temporizador de inatividade que o Ollama inicia quando um pedido termina. Quando o temporizador expira, o servidor liberta os pesos. O pedido seguinte volta a carregá-los a partir do disco, e esse carregamento é a pausa que sente. Aumente o valor para um pedido enviando "keep_alive": "30m" no corpo JSON ou para todo o servidor com a variável de ambiente OLLAMA_KEEP_ALIVE.

Como mantenho um modelo Ollama carregado permanentemente na memória?

Use um valor negativo: "keep_alive": -1 no pedido ou OLLAMA_KEEP_ALIVE=-1 para o servidor. Em seguida, ollama ps mostra Forever na coluna UNTIL. Isto remove apenas o temporizador de inatividade. Se for solicitado outro modelo e a memória for insuficiente, o agendador ainda descarrega este modelo para libertar espaço.

Por que OLLAMA_KEEP_ALIVE está a ser ignorada?

Verifique onde a definiu. Execute systemctl show ollama --property=Environment. Se a variável não aparecer nessa saída, o servidor nunca a recebeu, porque uma variável exportada na sua shell não é transmitida a um serviço systemd. Defina-a com sudo systemctl edit ollama.service e execute depois sudo systemctl daemon-reload e sudo systemctl restart ollama. A outra causa é um cliente que envia o seu próprio keep_alive no pedido, substituindo o valor predefinido do servidor.

Como liberto a memória sem reiniciar o Ollama?

ollama stop qwen3:8b descarrega imediatamente esse modelo e mantém o servidor e todos os outros modelos carregados em execução. Através da API, envie um pedido sem prompt e com "keep_alive": 0. A resposta será devolvida com "done_reason": "unload". Confirme com ollama ps. O modelo já não deverá aparecer na lista.