Ollama pull vs run: onde os modelos ficam no Linux

ollama pull vs ollama run

ollama pull transfere um modelo e termina. ollama run transfere o modelo apenas se este não existir, carrega-o para a memória e abre uma sessão de chat interativa. A transferência é idêntica e os ficheiros ficam no mesmo local. Apenas run continua depois disso.

Essa diferença determina qual comando deve ser usado num script e qual deve ser usado 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. Este é o formato adequado para um script que precisa de uma resposta em vez de uma sessão. Os nomes dos modelos mudam rapidamente. Por isso, considere gemma4 um marcador de posição: é o exemplo usado na documentação oficial do Ollama em agosto de 2026, e qualquer tag da biblioteca funciona da mesma forma.

Por que a primeira execução de ollama parece ter bloqueado

A primeira execução de run num VPS novo pode ficar vários minutos sem apresentar saída. Não há nenhuma falha. O prompt de chat só pode aparecer 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 uma tarefa cron, de uma etapa de CI ou de um ssh host ollama run ... simples não apresenta 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, e 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 aumenta bastante.

Observe 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 deixa de diminuir enquanto o comando continua ocupado, o download terminou e começou o carregamento do modelo na memória.

Este é o motivo para fazer o pull antecipadamente. A pessoa que executa ollama run nunca deve ser a mesma que fica à espera do download.

Baixe o modelo antes de alguém o solicitar

Numa máquina nova, faça o download no mesmo script que instala o servidor:

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

Se está 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 download que continue depois de fechar o terminal, porque uma transferência interrompida a meio pode deixar o armazenamento de modelos incompleto.

Execute-o dentro de tmux ou entregue-o ao systemd como uma unidade one-shot executada no boot. 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 intencionalmente 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 na própria máquina é a única resposta fiável. Usar a shell aproveita o PATH do serviço, em vez de 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. Por isso, o loop espera até ollama list responder antes de iniciar o download.

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

O journal deve mostrar que o download terminou sem erros. Em seguida, ollama list deve mostrar o modelo. Para manter uma tag móvel atualizada, adicione um timer do systemd ou uma entrada semanal do cron que execute o mesmo download. Repetir o download de uma tag que mudou baixa as novas camadas e deixa as antigas sem referências. Essas camadas 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 base num hash do seu próprio conteúdo. Por isso, um pull interrompido não significa trabalho perdido: execute novamente o mesmo ollama pull, e as camadas que já foram concluídas 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 arranca, remove as camadas armazenadas às quais nenhum manifesto de modelo faz referência. A camada parcial deixada por um pull interrompido é exatamente uma dessas camadas. Portanto, reiniciar o serviço antes de tentar novamente elimina a parte que já foi transferida. Tente executar 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-o depois, porque essa limpeza no arranque impede a acumulação de camadas órfãs no disco.

Se o pull terminar com no space left on device, liberte espaço antes de tentar novamente. Se df indicar que o disco está cheio e du no diretório do modelo não explicar o consumo, o espaço foi utilizado noutro local. Nesse caso, vale a pena ler as razões pelas 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 indicado por qualquer guia, incluindo este. A localização varia entre uma instalação por pacote e um contentor, e muda novamente 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 aparece nessa saída. Sem essa linha, o armazenamento fica no diretório pessoal da conta com que o serviço é executado, e getent passwd mostra esse diretório pessoal no sexto campo separado por dois-pontos. find pesquisa num sistema de ficheiros pelo diretório blobs, que é onde as camadas são efetivamente 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 por cada tag de modelo, e esse ficheiro lista as camadas a partir das quais a tag é criada. blobs contém as próprias camadas, cada uma com 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 que du apresenta para o diretório.

Os ficheiros dos modelos enchem o sistema de ficheiros root de uma VPS pequena mais depressa do que qualquer outro componente que provavelmente irá instalar. O fator que mais influencia o tamanho é o formato dos pesos. Escolher entre q4, q8 e fp16 pode representar vários 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 esteja 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. Assim, a unidade fornecida pelo pacote permanece intacta e uma atualização do pacote não substitui 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 mostrava 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. Esse utilizador precisa de acesso de leitura e escrita ao destino, que é a função da linha chown acima. Verifique journalctl -e -u ollama à procura de erros de permissões que indiquem o novo caminho. Elimine a cópia antiga apenas depois de a lista estar correta. Se a mudança falhar e a origem for eliminada, terá de 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 confirma que o bind está ativo. Um bind mount é útil quando outro componente do servidor já espera a localização predefinida. Tem uma limitação: os ficheiros copiados continuam no ponto de montagem do disco raiz, ocultos pela montagem. O espaço só é recuperado depois de desmontar o volume e remover esses ficheiros. A variável de ambiente é a opção mais simples de explicar à pessoa que iniciar sessão a seguir.

Onde o container os mantém

A imagem oficial armazena os modelos no local que você montar, e não em nenhum diretório do host pertencente a um usuário 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 grava dentro do container. Por isso, executar du nos caminhos da seção anterior não encontra nada: não há nada nesses caminhos. 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, em seguida, execute sudo du -sh nesse local. 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 container. O container grava como root, portanto 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. Por isso, a propriedade no host será diferente: executar o Ollama no Podman rootless explica esse mapeamento.

Há um aviso importante sobre a limpeza. docker volume prune remove todos os volumes que não são referenciados por nenhum container. Remova ou recrie o container ollama sem o respetivo volume, e uma execução posterior de prune eliminará todos os modelos que você descarregou, sem possibilidade de recuperação, exceto descarregá-los 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 manifest dessa tag e, em seguida, elimina as layers que já não são referenciadas por nenhum manifest. O espaço fica disponível assim que esses ficheiros são desligados, pelo que df avança 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 dela. Esse é o comportamento esperado, não uma falha na eliminação.

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

Há ainda uma última distinção, porque estes dois conceitos são constantemente 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 que um modelo permanece residente na RAM depois de concluída a transferência é uma definição separada, explicada 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 na 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 programável de run.

Por que a primeira execução de ollama run parece ficar bloqueada?

O modelo está a ser transferido. O prompt de 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 mostra a barra de progresso apenas quando a saída é um terminal, por isso um run dentro de um script, de um cron job ou de um ssh host ollama run ... não mostra nada enquanto está a funcionar. Abra uma segunda sessão e execute watch -n5 df -h /: a diminuição do espaço livre em etapas indica que a transferência está em curso. Transfira o modelo antecipadamente para eliminar a espera.

Onde o Ollama armazena os modelos?

A localização depende da instalação, por isso deve ser apresentada em vez de assumida. Execute systemctl cat ollama.service para verificar se OLLAMA_MODELS está definido na unidade ou num drop-in. Se não estiver, o armazenamento fica 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 de camadas. Na imagem de contentor, o armazenamento fica dentro do volume montado, e docker volume inspect ollama apresenta o seu 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 quase sempre significa que o utilizador ollama não consegue ler o novo diretório; journalctl -e -u ollama apresenta o caminho.

Eliminar os ficheiros do modelo liberta espaço?

Eliminar ficheiros manualmente liberta os bytes, mas deixa o armazenamento inconsistente. Remova um blob e o manifesto continuará a listar esse modelo, que continuará a aparecer em ollama list e falhará quando for utilizado. Remova um manifesto e as respetivas camadas permanecerão 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 precisa. Se os ficheiros já tiverem sido eliminados manualmente, execute ollama rm na tag para limpar a entrada e reinicie o servidor, que remove as camadas sem referência de qualquer manifesto.