Como manter um modelo do 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 depois libera-o. O pedido seguinte precisa ler os pesos do disco e mapeá-los novamente na RAM ou na VRAM, o que causa uma pausa antes da chegada do primeiro token. Por isso, uma interface de chat ou um agente de programação parece rápido, fica inativo durante algum tempo e depois volta a parecer lento na mensagem seguinte. Não há nenhuma falha. O temporizador de inatividade expirou.

O temporizador chama-se keep_alive. A configuração é específica de cada modelo e reinicia sempre que um pedido termina. Um modelo que está respondendo a um pedido nunca é descarregado, porque o servidor só remove um modelo sem pedidos ativos quando o temporizador expira. Em agosto de 2026, o valor padrão é de cinco minutos e aplica-se a todos os modelos carregados por este servidor.

Há dois locais para definir keep_alive: no pedido individual ou como valor padrão do servidor. Um drop-in do systemd faz com que o valor padrão do servidor persista após um reinício. Este guia pressupõe que o Ollama já está sendo executado como um serviço. Se não estiver, comece por instalar o Ollama numa VPS e volte aqui.

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 a próxima solicitação terá de fazer um carregamento completo. PROCESSOR indica onde os pesos foram colocados. 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, portanto parte dele é executada no processador e a geração é mais lenta.

UNTIL é a contagem regressiva e mostra um tempo relativo, como 4 minutes from now. Mostra Forever quando o modelo foi carregado com um keep_alive negativo. Mostra Stopping... durante o curto período em que o servidor está descarregando o modelo.

O conjunto de colunas mudou entre versões, portanto leia o cabeçalho em vez de contar campos num script. Para qualquer automação, 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 igual a 0 significa que o modelo está sendo executado na CPU.

O custo real do reload

Não faça estimativas. O Ollama informa o tempo de carregamento em todas as respostas, 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 é alto. Divida-o por 1000000000 para o ler em segundos. A segunda chamada é executada enquanto o modelo permanece residente e informa um valor muito menor. A diferença entre esses dois valores é o custo suportado por todos os utilizadores depois de o temporizador expirar. É essa a razão para alterar keep_alive. A maior parte dessa diferença corresponde à leitura do disco. Por isso, se moveu o diretório do modelo para um segundo volume, a velocidade desse volume define o limite mínimo de cada carregamento a frio. Para saber a velocidade de geração antes e depois dessa pausa, consulte como medir tokens por segundo no seu próprio servidor.

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

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

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

São aceites quatro formatos de valor:

• uma cadeia 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 solicitação terminar

Um valor definido na solicitação substitui o valor predefinido do servidor, em ambas as direções. 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 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 solicitação real de um utilizador não tenha de esperar pelo carregamento. A CLI faz o mesmo com uma flag:

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

Mantenha o modelo carregado por padrã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. Ele aceita os mesmos formatos que o campo do pedido, por isso 30m, 3600 e -1 funcionam.

A questão é em que ambiente a variável tem de estar definida. Executar export OLLAMA_KEEP_ALIVE=30m na sua sessão SSH não produz 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 não partilham o mesmo ambiente. Esta é a razão mais comum para 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"

Guardar grava /etc/systemd/system/ollama.service.d/override.conf. Isto é um drop-in, e não uma edição da unidade fornecida com o pacote. Por isso, 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 o funcionamento.

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 linhas escritas abaixo do marcador. O reinício remove todos os modelos carregados, por isso o pedido seguinte faz 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 mantida 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 calcular a memória necessária para executar um modelo destes numa VPS apenas com CPU 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. Numa VPS pequena, isto compete diretamente com a base de dados, a aplicação web e os jobs de build.

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 mencione ollama significa que o servidor do modelo foi terminado. Uma linha que mencione a sua base de dados significa que o modelo ganhou e que um serviço importante foi perdido. Ambos os resultados vêm da mesma decisão: uma janela longa de keep-alive num servidor sem margem de memória.

Há dois custos fáceis de ignorar. Um context length maior reserva uma KV cache 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. O tamanho depende de num_ctx, por isso aumentar a janela de contexto aumenta a memória mantida por um modelo residente durante todo o período de inatividade, e não apenas enquanto responde. Um valor de OLLAMA_NUM_PARALLEL superior a 1 reserva essa cache uma vez por slot paralelo. Se planeia servir várias pessoas a partir de um único modelo, dimensione a memória para os slots, e não apenas para os pesos.

Uma predefinição 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 produz saída, e o modelo desaparece de ollama ps. Um nome que não está carregado devolve couldn't find model "qwen3:8b" to stop. Na API, a forma correta é um pedido sem prompt e com keep_alive definido como 0:

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

A resposta contém "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 espaço disponível muito antes de atingir 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. Dá preferência a um modelo sem pedidos ativos. Também pode remover 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. Isto não fixa os pesos contra o pedido 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 juntos nesta máquina. A solução é executar 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 continuam válidas após a próxima versão

Ollama lança versões com frequência e os valores predefinidos mudam. Por isso, consulte a versão instalada em vez de memorizar números:

ollama --version
ollama serve --help

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

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

FAQ

Por que o Ollama descarrega o meu modelo após 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 carrega-os novamente a partir do disco, e esse carregamento é a pausa que se nota. 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. ollama ps mostra então Forever na coluna UNTIL. Isto remove o temporizador de inatividade, mas não altera mais nada. Se for pedido outro modelo e houver pouca memória disponível, o agendador continua a descarregar 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 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 devolve "done_reason": "unload". Confirme com ollama ps; o modelo já não deverá aparecer na lista.