Ollama pull vs run: onde os modelos ficam

ollama pull versus ollama run

ollama pull faz o download de um modelo e termina. ollama run só faz o download do modelo se este não existir, carrega-o para a memória e abre uma sessão de chat interativa. O download é idêntico e os ficheiros ficam no mesmo local. Apenas run continua a executar depois disso.

Essa diferença determina qual comando pertence a um script e qual deve ser executado numa sessão interativa.

ollama pull gemma4
ollama run gemma4
ollama run gemma4 "Reply with one word: ready"

A primeira linha obtém o modelo e termina, por isso é segura no aprovisionamento e numa unidade systemd. A segunda abre uma sessão de chat; escreva /bye ou prima Ctrl+D para sair. A terceira envia um único prompt, apresenta a resposta e termina. É o formato adequado para um script que precisa de uma resposta em vez de uma sessão. Este terceiro formato continua a deixar o comprimento da resposta inteiramente ao critério do modelo. Por isso, uma pergunta de uma linha pode resultar em três parágrafos. Limitar a resposta com num_predict é o que mantém um run utilizado por um script dentro de um tamanho que o processo chamador consegue realmente utilizar. Os nomes dos modelos mudam rapidamente, por isso trate gemma4 aqui como um marcador de posição. É o exemplo utilizado pela documentação oficial do Ollama em agosto de 2026, e qualquer tag da biblioteca funciona da mesma forma. Se preferir substituir o modelo por um que já tenha sido dimensionado para um servidor real, executar o Nemotron 3.5 Lightning numa VPS apresenta a tag exata a obter e a memória que o modelo espera encontrar.

Por que o primeiro ollama run parece ter bloqueado

Um primeiro run num VPS novo pode ficar sem apresentar saída durante vários minutos. Não há nenhuma falha. O prompt de chat só aparece depois de o modelo estar no disco e carregado na memória, por isso run está a fazer um download de vários gigabytes antes de ter algo para mostrar.

Duas coisas ocultam esse trabalho. O Ollama só apresenta a barra de progresso quando a saída é um terminal, por isso um run dentro de um script de shell, de um cron job, de uma etapa de CI ou de um simples ssh host ollama run ... não imprime nada enquanto o download decorre. Depois de os bytes serem gravados, o ficheiro ainda tem de ser lido do disco para a RAM antes de surgir o primeiro token. Num VPS pequeno, essa leitura é lenta. Se o sistema não tiver memória suficiente para o modelo, o kernel começa a usar swap e a espera torna-se muito mais longa.

Monitorize o processo a partir de uma segunda sessão em vez de tentar adivinhar:

df -h /
watch -n5 df -h /

A diminuição do espaço livre em etapas significa que o download ainda está a decorrer. Se o espaço livre deixar de diminuir enquanto o comando continuar ocupado, o download terminou e começou o carregamento do modelo na memória.

É por isso que deve fazer o pull antecipadamente. A pessoa que escreve ollama run nunca deve ser a mesma que fica à espera do download.

Baixe o modelo antes de alguém o solicitar

O mesmo se aplica a tudo o que não seja uma pessoa: um agente de programação apontado para o seu endpoint Ollama normalmente desiste do primeiro pedido em vez de esperar por um download de vários gigabytes. Num servidor novo, faça o pull no mesmo script que instala o servidor:

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

Se estiver a configurar o servidor pela primeira vez, a instalação completa do Ollama numa VPS explica o próprio serviço e quem pode aceder-lhe. Depois disso, vale a pena configurar um pull que sobreviva ao terminal, porque um download interrompido a meio pode deixar o repositório de modelos incompleto.

Execute-o dentro de tmux ou entregue-o ao systemd como uma unidade one-shot executada no arranque. Escreva /etc/systemd/system/ollama-pull.service:

[Unit]
Description=Pre-pull Ollama models
Wants=ollama.service network-online.target
After=ollama.service network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'until ollama list >/dev/null 2>&1; do sleep 2; done'
ExecStart=/bin/sh -c 'ollama pull gemma4'

[Install]
WantedBy=multi-user.target

Ambos os comandos passam deliberadamente por /bin/sh -c. Um ExecStart= isolado precisa de um caminho absoluto, e o instalador nem sempre coloca o binário no mesmo diretório. Por isso, command -v ollama no seu próprio servidor é a única resposta fiável. Usar a shell recorre ao PATH do serviço, em vez de usar um caminho copiado de um guia. O primeiro ExecStart também é importante: After=ollama.service significa que a unidade do servidor foi iniciada, mas isso não significa que esteja pronta. Assim, o loop espera até ollama list responder antes de iniciar o pull.

sudo systemctl daemon-reload
sudo systemctl enable --now ollama-pull.service
journalctl -u ollama-pull.service

O journal deve mostrar a conclusão do pull sem erros, e ollama list deve mostrar o modelo. Para manter atualizado um tag que muda, adicione um timer do systemd ou uma entrada semanal do cron que execute o mesmo pull. Fazer novamente o pull de um tag que mudou baixa as novas layers e deixa as antigas sem referências. Essas layers são limpas na próxima vez que o servidor arrancar.

O que acontece quando um pull é interrompido

Cada camada de um modelo é armazenada com um hash do próprio conteúdo. Por isso, um pull interrompido não representa trabalho perdido: execute novamente o mesmo ollama pull, e as camadas que já terminaram serão reconhecidas e ignoradas. O download continuará a partir da camada que foi interrompida.

Uma ação destrói esse progresso. Quando o servidor Ollama é iniciado, ele remove as camadas armazenadas que não são referenciadas por nenhum manifesto de modelo. A camada parcial deixada por um pull interrompido é exatamente esse tipo de camada. Portanto, reiniciar o serviço antes de tentar novamente elimina a parte que já foi transferida. Tente o pull novamente primeiro e reinicie depois. Se for realmente necessário preservar um download parcial durante um reinício, defina OLLAMA_NOPRUNE=1 no ambiente do serviço e remova-a depois. Essa limpeza na inicialização impede que camadas órfãs se acumulem no disco.

Se o pull terminou com no space left on device, libere espaço antes de tentar novamente. Se df indicar que o disco está cheio e du no diretório do modelo não explicar esse uso, o espaço foi ocupado em outro local. Nesse caso, vale a pena ler os motivos pelos quais df e du apresentam valores diferentes antes de eliminar qualquer coisa.

Onde o Ollama armazena os modelos numa VPS?

Consulte o próprio servidor em vez de confiar num caminho de qualquer guia, incluindo este. A localização varia entre uma instalação por pacote e um contentor. Também muda se alguém tiver definido OLLAMA_MODELS.

systemctl cat ollama.service
getent passwd ollama
sudo find / -xdev -type d -name blobs 2>/dev/null

systemctl cat mostra o ficheiro da unidade juntamente com todos os drop-ins. Assim, uma linha OLLAMA_MODELS definida por si ou incluída na sua imagem também aparece nessa saída. Sem essa linha, o armazenamento fica no diretório pessoal da conta sob a qual o serviço é executado. getent passwd mostra esse diretório pessoal no sexto campo separado por dois-pontos. find pesquisa um sistema de ficheiros pelo diretório blobs. É nesse diretório que as camadas são realmente gravadas. Remova -xdev se os modelos já puderem estar num mount separado.

Agora meça e interprete os seus próprios valores:

ollama list
df -h /
sudo du -sh /the/directory/you/found
sudo du -h -d1 /the/directory/you/found

O armazenamento tem duas partes. manifests contém um ficheiro pequeno para cada tag de modelo. Esse ficheiro lista as camadas a partir das quais a tag é criada. blobs contém as próprias camadas. Cada uma recebe o nome do hash do seu conteúdo, e quase todo o espaço ocupado está aí. Como as camadas são partilhadas entre tags, dois modelos criados com os mesmos pesos indicam o seu próprio tamanho em ollama list, embora ocupem esse espaço apenas uma vez no disco. Por isso, os tamanhos indicados podem somar mais do que o valor reportado por du para o diretório.

Os ficheiros dos modelos enchem o sistema de ficheiros root de uma VPS pequena mais depressa do que quase tudo o que provavelmente irá instalar. O fator que mais influencia o tamanho é o formato dos pesos. Escolher entre q4, q8 e fp16 pode poupar gigabytes por modelo.

Mova os modelos para um volume de dados com OLLAMA_MODELS

Se o plano incluir um segundo disco ou um volume de dados maior, mova o armazenamento antes de o sistema de ficheiros raiz ficar cheio. Pare primeiro o servidor, para não copiar um ficheiro que ainda está a ser escrito.

sudo systemctl stop ollama
sudo mkdir -p /mnt/data/ollama-models
sudo rsync -a /the/directory/you/found/ /mnt/data/ollama-models/
sudo chown -R ollama:ollama /mnt/data/ollama-models
sudo systemctl edit ollama.service

systemctl edit abre um editor num ficheiro drop-in, mantendo a unidade fornecida pelo pacote intacta e impedindo que uma atualização do pacote substitua a sua alteração. Adicione estas duas linhas:

[Service]
Environment="OLLAMA_MODELS=/mnt/data/ollama-models"

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

systemctl show deve apresentar o novo caminho, e ollama list deve mostrar os mesmos modelos que apresentava antes da mudança. Uma lista vazia significa que o servidor não consegue ler o novo diretório. O serviço é executado como o utilizador ollama, por isso esse utilizador precisa de acesso de leitura e escrita ao destino. Essa é a função da linha chown acima. Consulte journalctl -e -u ollama para procurar erros de permissões que indiquem o novo caminho. Apague a cópia antiga apenas depois de a lista estar correta, porque uma mudança falhada seguida da eliminação da origem obriga a descarregar tudo novamente.

A outra opção mantém o caminho original e monta o volume de dados nesse caminho:

echo '/mnt/data/ollama-models /the/directory/you/found none bind 0 0' | sudo tee -a /etc/fstab
sudo mount -a
findmnt /the/directory/you/found
df -h /

A apresentação do ponto de montagem por findmnt significa que o bind está ativo. Um bind mount é útil quando outro componente do servidor já espera a localização predefinida. Existe uma particularidade: os ficheiros que copiou continuam no ponto de montagem do disco raiz, ocultos pelo mount. O espaço só é recuperado depois de desmontar o volume e remover esses ficheiros. A variável de ambiente é a opção mais fácil de explicar à próxima pessoa que iniciar sessão.

Onde o contentor os mantém

A imagem oficial armazena os modelos no local que montar, e não num diretório do host pertencente a um utilizador ollama. O comando de execução documentado é:

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

ollama antes dos dois pontos é um volume Docker nomeado, e /root/.ollama é o local onde o servidor escreve dentro do contentor. Por isso, executar du nos caminhos da secção anterior não encontra nada: os ficheiros não estão lá. Mostre o local e o tamanho reais:

docker volume inspect ollama
docker system df -v
docker exec -it ollama ollama list

Leia o campo Mountpoint de docker volume inspect e execute sudo du -sh nesse caminho. Para colocar os modelos num volume de dados, substitua o volume nomeado por um diretório do host (-v /mnt/data/ollama:/root/.ollama) e recrie o contentor. O contentor escreve como root, pelo que esse diretório do host fica pertencente a root. No Podman rootless, os IDs são mapeados para o intervalo de subuid do seu utilizador, pelo que a propriedade no host será diferente: executar o Ollama com Podman rootless explica esse mapeamento.

Tenha atenção à limpeza. docker volume prune remove todos os volumes que nenhum contentor utiliza. Se remover ou recriar o contentor ollama sem o respetivo volume, uma execução posterior de prune elimina todos os modelos que transferiu, sem possibilidade de recuperação, exceto transferindo-os novamente. Leia como limpar o uso de disco do Docker numa VPS antes de executar prune num servidor que aloja modelos.

Remova um modelo com ollama rm, não com rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm elimina o manifesto dessa tag e, em seguida, elimina as layers que já não são referenciadas por nenhum manifesto. O espaço fica disponível assim que esses ficheiros são desvinculados, por isso df apresenta o resultado imediatamente. Como as layers são partilhadas, remover uma de duas tags estreitamente relacionadas pode libertar muito menos espaço do que o tamanho ollama list apresentado junto da tag. Esse é o comportamento esperado, não uma falha na remoção.

Eliminar ficheiros manualmente quebra a relação entre estes elementos. Remova um blob com rm e o manifesto continuará a listá-lo, por isso ollama list continuará a apresentar o modelo e qualquer tentativa de o utilizar falhará quando a layer em falta for lida. Remova um manifesto manualmente e as respetivas layers permanecerão no disco sem nada que as referencie, ocupando espaço que nenhum comando do Ollama lhe mostrará. Se já fez isso, ollama rm na tag elimina a entrada restante, e reiniciar o servidor elimina as layers que já não são referenciadas.

Há uma última distinção, porque estes dois conceitos são frequentemente confundidos. ollama rm diz respeito ao disco. ollama stop gemma4 descarrega um modelo da memória e não liberta espaço em disco. O tempo durante o qual um modelo permanece residente na RAM depois de concluída a transferência é controlado por uma definição separada, descrita em manter um modelo carregado em vez de o recarregar a cada pedido.

FAQ

Qual é a diferença entre ollama pull e ollama run?

ollama pull transfere um modelo para o disco e termina. ollama run verifica se o modelo já está no disco, transfere-o se não estiver, carrega-o para a memória e abre uma sessão de chat interativa. Ambos escrevem os mesmos ficheiros no mesmo diretório. Use pull durante o provisionamento e em scripts, e use run quando houver uma pessoa ao teclado. ollama run <model> "your prompt" envia um prompt e termina, sendo a forma utilizável em scripts de run.

Por que motivo o meu primeiro ollama run parece bloquear?

Está a fazer uma transferência. O prompt do chat só pode aparecer depois de o modelo estar no disco e carregado na memória, e um modelo ocupa vários gigabytes. O Ollama apresenta a barra de progresso apenas quando a saída é um terminal. Por isso, um run dentro de um script, de uma tarefa cron ou de um ssh host ollama run ... não mostra nada enquanto trabalha. Abra uma segunda sessão e execute watch -n5 df -h /: a diminuição do espaço livre em etapas significa que a transferência está em curso. Transfira o modelo antecipadamente para eliminar a espera.

Onde é que o Ollama armazena os modelos?

A localização depende da instalação. Por isso, apresente-a em vez de presumir qual é. Execute systemctl cat ollama.service para verificar se OLLAMA_MODELS está definido na unidade ou num drop-in. Se não estiver, o armazenamento encontra-se no diretório pessoal da conta com que o serviço é executado, que getent passwd ollama apresenta. sudo find / -xdev -type d -name blobs 2>/dev/null localiza diretamente o diretório das camadas. Na imagem do contentor, o armazenamento fica dentro do volume montado, e docker volume inspect ollama apresenta o respetivo Mountpoint no host.

Como movo os modelos do Ollama para outro disco?

Pare o serviço, copie o armazenamento para a nova localização com rsync -a, atribua o diretório à conta de serviço com sudo chown -R ollama:ollama <directory>, execute sudo systemctl edit ollama.service e adicione Environment="OLLAMA_MODELS=<directory>" sob uma linha [Service]. Recarregue com sudo systemctl daemon-reload e reinicie. Confirme com systemctl show ollama --property=Environment e ollama list. Uma lista vazia significa quase sempre que o utilizador ollama não consegue ler o novo diretório; journalctl -e -u ollama indica o caminho.

Apagar os ficheiros do modelo liberta espaço?

Apagar ficheiros manualmente liberta os bytes, mas deixa o armazenamento inconsistente. Se remover um blob, o manifesto continua a listar esse modelo. Por isso, ele continua a aparecer em ollama list e falha quando é utilizado. Se remover um manifesto, as respetivas camadas permanecem no disco sem nada que faça referência a elas. Use ollama rm <model>, que elimina o manifesto e depois as camadas de que nenhum outro modelo necessita. Se os ficheiros já tiverem sido apagados manualmente, execute ollama rm na tag para limpar a entrada e reinicie o servidor. O reinício remove as camadas às quais nenhum manifesto faz referência.