Rollback de versão do Ollama na prática: 3 passos críticos que 90% dos devs ignoram

Clicar no aviso de atualização do Ollama e cair na versão 0.6.8: a resposta da API salta de 200 ms para 5 segundos, o uso de memória dobra e até ollama run llama3.2 começa a travar. No GitHub Issue #10652, dezenas de usuários reclamam da mesma coisa: “depois da atualização, o sistema ficou inutilizável; quero voltar, mas o site oficial não oferece download de versões antigas”.

A resposta oficial é direta: só há suporte para a versão mais recente; rollback ainda não é um recurso suportado.

Essa armadilha doeu o bastante para eu passar a fazer backup completo antes de qualquer atualização. Neste artigo, mostro três formas de rollback (troca de binário, gerenciador de pacotes e Docker), scripts de automação em um comando, configuração para coexistência de múltiplas versões e todos os problemas em que já tropecei.

Por que você precisa de rollback de versão? Cenários reais de dor

Atualizar software deveria ser bom: recursos novos, melhorias de desempenho, correções de bug. Mas uma atualização do Ollama, às vezes, entrega uma “surpresa” grande demais.

Três riscos principais: desempenho, compatibilidade e estabilidade

As três situações que mais vi foram estas:

Queda repentina de desempenho. Há relatos de usuários que, depois de atualizar para uma versão específica, viram a velocidade de inferência cair de 50 tokens por segundo para menos de 10. O uso de memória também pode dobrar sem explicação, com um modelo de 4 GB passando a consumir 8 GB. Nesse cenário, sua aplicação vira uma lesma: o usuário espera meio minuto por uma resposta, e ninguém aguenta isso por muito tempo.

Incompatibilidade de API. Essa é mais sorrateira. Você atualiza o Ollama, não muda uma linha do código, e as chamadas à API começam a falhar. Pode ser um nome de parâmetro que mudou, um formato de retorno ajustado ou um endpoint que foi removido. Em um projeto meu, depois da atualização, o parâmetro timeout de api/generate simplesmente deixou de funcionar, e todas as tarefas longas começaram a expirar. Só depois de investigar bastante percebi que a versão nova tinha alterado o comportamento padrão desse parâmetro.

Instabilidade do sistema. É o caso mais irritante. O serviço reinicia sem motivo aparente, modelos falham ao carregar e os logs ficam cheios de erros difíceis de entender. Uma vez, meu serviço do Ollama saía sozinho a cada meia hora. Eu reiniciava, ele rodava por um tempo e caía de novo. Foram dois dias de tentativa até descobrir que era um bug de vazamento de memória na versão nova.

GitHub Issue #10652: a voz de usuários reais

Esse issue foi criado em 2025-05-10 e já tinha mais de 100 usuários participando da discussão. O título é bem direto: “Ability to downgrade” (capacidade de fazer downgrade).

A descrição de quem abriu o issue ficou na minha cabeça: “Depois de atualizar para a 0.6.8, o sistema ficou praticamente inutilizável. A inferência ficou lenta demais, e as chamadas à API começaram a expirar o tempo todo. Tentei vários ajustes de configuração, mas nada resolveu. Quero voltar para a versão anterior, mas o site oficial só oferece a versão mais recente.”

Nos comentários, um usuário resumiu ainda melhor: “Gastei três dias investigando o problema e, no fim, descobri que era um bug conhecido da versão nova. Mas a correção oficial ainda não saiu, então só me resta esperar. Esperei duas semanas, e o bug continuava lá. O cronograma do meu projeto inteiro ficou preso por causa desse problema de versão.”

Não é um caso isolado. No Reddit e em fóruns da comunidade, reclamações parecidas aparecem o tempo todo. Algumas pessoas precisam pausar o desenvolvimento por causa de uma atualização; outras, para evitar risco, simplesmente deixam o Ollama travado em uma versão antiga.

A limitação oficial: só a versão mais recente

A raiz do problema é esta: a página oficial de download do Ollama sempre mostra apenas a versão mais recente. O GitHub Releases tem versões históricas, mas a documentação oficial praticamente não explica como voltar. Homebrew, APT e outros gerenciadores de pacotes também instalam a versão mais nova por padrão.

Talvez você pense: “Então é só não atualizar, certo?” Nem sempre. Às vezes a atualização vem de forma indireta: dependências do sistema, exigências de outras ferramentas ou um clique errado no botão de atualizar. Esse último foi o meu caso. Quando você percebe o problema, voltar já não parece tão simples.

E ainda tem mais. Mesmo quando você encontra o instalador antigo, o processo de rollback tem riscos próprios: os dados dos modelos vão sumir? A configuração vai entrar em conflito? O serviço vai iniciar normalmente? Tudo isso precisa ser tratado.

Por isso, ter um processo confiável de rollback de versão realmente salva tempo. A seguir, vamos destrinchar três métodos comuns para você voltar rápido e evitar as armadilhas mais frequentes.

Rollback de versão na prática: comparação e passos detalhados

Começando pela conclusão: as três opções funcionam, mas a melhor escolha depende de como você fez o deploy e de quanto tempo tem para resolver.

Comparativo: tempo, dificuldade e cenário de uso

Sendo bem honesto, se eu puder escolher, prefiro Docker. Dá menos trabalho. Mas se seu deploy não é containerizado, trocar o binário também resolve rápido. Vamos passar por cada opção em detalhes.

Opção 1: rollback por troca de binário (a mais rápida, mas manual)

Esse método substitui diretamente o executável do Ollama. A vantagem é a velocidade; a desvantagem é que backup e validação ficam por sua conta.

Passo 1: parar o serviço

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

# macOS/Linux
ollama stop
# Se o comando acima não funcionar, use este
sudo systemctl stop ollama  # Linux
# Ou mate o processo diretamente
pkill -9 ollama

Se o serviço não parar, verifique se há processos restantes:

ps aux | grep ollama
lsof -i :11434  # Verifica o uso da porta

Passo 2: fazer backup da instalação atual

Não pule esta etapa. Eu já pulei uma vez e, quando o rollback falhou, o resultado foi bem doloroso.

# Backup do arquivo binário
sudo cp /usr/local/bin/ollama ~/ollama-backup-current

# Backup da configuração e dos dados dos modelos (este diretório pode ser grande)
# O diretório ~/.ollama guarda todos os modelos; dezenas de GB são comuns
cp -r ~/.ollama ~/.ollama-backup-$(date +%Y%m%d)

Na hora de fazer backup dos dados, confira o tamanho do diretório. Em uma ocasião, descobri que meu ~/.ollama tinha mais de 40 GB e precisei limpar vários modelos antigos antes de continuar.

du -sh ~/.ollama  # Verifica o tamanho
# Se estiver grande demais, remova primeiro modelos que você não usa
ollama list  # Lista os modelos disponíveis
ollama rm unused-model-name  # Remove um modelo não usado

Passo 3: baixar a versão desejada

Vá ao GitHub Releases e encontre a versão que você quer:

# Página do GitHub Releases
https://github.com/ollama/ollama/releases

# Encontre a versão necessária, por exemplo 0.1.30
# Baixe o binário correspondente ao seu sistema
# macOS (Intel)
curl -L https://github.com/ollama/ollama/releases/download/v0.1.30/ollama-darwin -o ollama-v0.1.30

# macOS (Apple Silicon)
curl -L https://github.com/ollama/ollama/releases/download/v0.1.30/ollama-darwin-arm64 -o ollama-v0.1.30

# Linux
curl -L https://github.com/ollama/ollama/releases/download/v0.1.30/ollama-linux-amd64 -o ollama-v0.1.30

Preste atenção ao nome do arquivo. Cada sistema tem um pacote diferente. Se você baixar o arquivo errado, a troca pode até acontecer, mas a execução vai falhar.

Passo 4: substituir o binário

# Dá permissão de execução ao arquivo baixado
chmod +x ollama-v0.1.30

# Substitui o ollama instalado no sistema
sudo mv ollama-v0.1.30 /usr/local/bin/ollama

# Se aparecer problema de permissão, remova o antigo e copie de novo
sudo rm /usr/local/bin/ollama
sudo cp ollama-v0.1.30 /usr/local/bin/ollama
sudo chmod +x /usr/local/bin/ollama

Passo 5: validar o rollback

# Verifica a versão
ollama --version
# Deve mostrar: ollama version 0.1.30 (ou a versão para a qual você voltou)

# Inicia o serviço
ollama serve

# Testa a API
curl http://localhost:11434/api/version
# Deve retornar: {"version":"0.1.30"}

# Testa a inferência com um modelo pequeno
ollama run llama3.2 "Hello, test"

Se a versão estiver correta, a API responder e o modelo rodar, deu certo. Se algo falhar, restaure o backup:

sudo mv ~/ollama-backup-current /usr/local/bin/ollama
ollama serve  # Reinicia o serviço

Opção 2: rollback via gerenciador de pacotes (a mais estável para Homebrew/APT)

Se você instalou com Homebrew (macOS) ou APT (Ubuntu), esse método costuma dar menos trabalho. O gerenciador de pacotes cuida das dependências e da instalação.

Homebrew (macOS)

# Primeiro, desinstale a versão atual
brew uninstall ollama

# Instale uma versão específica (supondo que você queira 0.1.30)
# O Homebrew nem sempre mantém todas as versões antigas, então confira antes
brew search ollama  # Verifica quais versões estão disponíveis

# Se a versão desejada não estiver disponível, use instalação manual
brew install [email protected]  # Se essa fórmula existir

# Fixa a versão para evitar atualização automática
brew pin ollama

# Valida
ollama --version

Na prática, o gerenciamento de versões do Homebrew pode ser meio cheio de pegadinhas. Às vezes a versão antiga simplesmente não está mais no repositório. Nesse caso, volte para a opção 1 e troque o binário.

APT (Ubuntu/Debian)

# Verifica versões disponíveis
apt-cache policy ollama

# Instala uma versão específica
sudo apt-get install ollama=0.1.30-1

# Fixa a versão
sudo apt-mark hold ollama

# Valida
ollama --version

O APT costuma ser mais previsível que o Homebrew, porque repositórios oficiais frequentemente mantêm várias versões por mais tempo.

Opção 3: rollback com container Docker (a mais segura, com isolação total)

Se seu deploy usa Docker, o rollback é o mais simples de todos: basta trocar a versão da imagem.

Puxar uma imagem de versão específica

# Verifica o container atual
docker ps | grep ollama

# Para o container atual
docker stop ollama-container
docker rm ollama-container

# Puxa a imagem da versão desejada
docker pull ollama/ollama:0.1.30

# Roda o container usando a tag de versão
docker run -d \
  --name ollama-container \
  -v ~/.ollama:/root/.ollama \
  -p 11434:11434 \
  ollama/ollama:0.1.30

# Valida a versão dentro do container
docker exec ollama-container ollama --version

Fixar versão com docker-compose

Se você usa docker-compose, altere o docker-compose.yml:

services:
  ollama:
    image: ollama/ollama:0.1.30  # Fixa a versão; não use latest
    volumes:
      - ~/.ollama:/root/.ollama
    ports:
      - "11434:11434"

Depois, faça o deploy novamente:

docker-compose down
docker-compose up -d

A vantagem do Docker é clara: os dados dos modelos ficam em ~/.ollama no host. Você troca a versão do container sem mexer nos dados. Além disso, containers são isolados entre si, então dá até para rodar várias versões do Ollama ao mesmo tempo. Vamos voltar a isso daqui a pouco.

Scripts de rollback automático e health check na prática

Rollback manual funciona, mas digitar uma sequência longa de comandos toda vez aumenta a chance de erro. Por isso, montei um conjunto de scripts para automatizar rollback, validação e monitoramento.

Script de rollback em um comando (ollama-rollback.sh)

Este script faz tudo automaticamente: para o serviço, cria backup, baixa a versão, substitui o binário e valida. Se algo falhar, restaura o backup.

#!/bin/bash
# ollama-rollback.sh - Script de rollback de versão do Ollama em um comando
# Uso: ./ollama-rollback.sh <versão-alvo>

TARGET_VERSION=$1
BACKUP_DIR=~/.ollama-backups
OLLAMA_BIN=/usr/local/bin/ollama

if [ -z "$TARGET_VERSION" ]; then
  echo "Erro: informe a versão-alvo"
  echo "Uso: ./ollama-rollback.sh <versão>"
  exit 1
fi

echo "=== Iniciando rollback do Ollama para a versão $TARGET_VERSION ==="

# Passo 1: parar o serviço
echo "[1/5] Parando o serviço do Ollama..."
ollama stop || pkill -9 ollama
sleep 2

# Passo 2: fazer backup da versão atual
BACKUP_NAME="ollama-backup-$(date +%Y%m%d-%H%M%S)"
echo "[2/5] Fazendo backup da versão atual em $BACKUP_DIR/$BACKUP_NAME..."
mkdir -p $BACKUP_DIR
cp $OLLAMA_BIN $BACKUP_DIR/$BACKUP_NAME/ollama-bin
cp -r ~/.ollama $BACKUP_DIR/$BACKUP_NAME/ollama-data

# Passo 3: baixar a versão-alvo
echo "[3/5] Baixando Ollama $TARGET_VERSION..."
OS_TYPE=$(uname -s)
ARCH=$(uname -m)

if [ "$OS_TYPE" = "Darwin" ]; then
  if [ "$ARCH" = "arm64" ]; then
    DOWNLOAD_URL="https://github.com/ollama/ollama/releases/download/v${TARGET_VERSION}/ollama-darwin-arm64"
  else
    DOWNLOAD_URL="https://github.com/ollama/ollama/releases/download/v${TARGET_VERSION}/ollama-darwin"
  fi
else
  DOWNLOAD_URL="https://github.com/ollama/ollama/releases/download/v${TARGET_VERSION}/ollama-linux-${ARCH}"
fi

curl -L $DOWNLOAD_URL -o /tmp/ollama-$TARGET_VERSION || {
  echo "Download falhou! Restaurando o backup..."
  cp $BACKUP_DIR/$BACKUP_NAME/ollama-bin $OLLAMA_BIN
  exit 1
}

# Passo 4: substituir o binário
echo "[4/5] Substituindo o arquivo binário..."
chmod +x /tmp/ollama-$TARGET_VERSION
sudo mv /tmp/ollama-$TARGET_VERSION $OLLAMA_BIN

# Passo 5: validar
echo "[5/5] Validando o rollback..."
ollama serve
sleep 3

INSTALLED_VERSION=$(ollama --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
if [ "$INSTALLED_VERSION" = "$TARGET_VERSION" ]; then
  echo "✓ Rollback concluído com sucesso! Versão atual: $INSTALLED_VERSION"
  echo "Backup em: $BACKUP_DIR/$BACKUP_NAME"
else
  echo "✗ Falha na validação da versão! Restaurando o backup..."
  sudo cp $BACKUP_DIR/$BACKUP_NAME/ollama-bin $OLLAMA_BIN
  ollama serve
  exit 1
fi

O uso é simples:

chmod +x ollama-rollback.sh
./ollama-rollback.sh 0.1.30

O script imprime o progresso, com retorno em cada etapa. Se o download falhar ou a versão instalada não bater, ele restaura o backup automaticamente, sem deixar o ambiente preso em um estado intermediário.

Criar um bom script de health check (health-check.sh)

Depois do rollback, olhar só o número da versão não basta. Você precisa validar se o serviço realmente está funcionando. Este script checa quatro pontos: versão, serviço, API e modelo.

#!/bin/bash
# health-check.sh - Script de health check do serviço Ollama

echo "=== Health check do serviço Ollama ==="

# 1. Validação da versão
VERSION=$(ollama --version 2>&1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
if [ -n "$VERSION" ]; then
  echo "✓ Versão: $VERSION"
else
  echo "✗ Falha ao verificar a versão"
  exit 1
fi

# 2. Estado do serviço
SERVICE_PID=$(pgrep -f "ollama serve")
if [ -n "$SERVICE_PID" ]; then
  echo "✓ Serviço em execução (PID: $SERVICE_PID)"
else
  echo "✗ Serviço não está em execução"
  ollama serve
  sleep 3
fi

# 3. Resposta da API
API_RESPONSE=$(curl -s -w "%{http_code}" http://localhost:11434/api/version -o /tmp/api-test.json)
if [ "$API_RESPONSE" = "200" ]; then
  echo "✓ API respondendo normalmente"
else
  echo "✗ API com erro (HTTP $API_RESPONSE)"
  exit 1
fi

# 4. Teste de modelo
TEST_MODEL=$(ollama list | head -2 | tail -1 | awk '{print $1}')
if [ -z "$TEST_MODEL" ]; then
  echo "⚠ Nenhum modelo instalado"
else
  echo "Modelo de teste: $TEST_MODEL"
  ollama run $TEST_MODEL "Say hello" --verbose > /tmp/model-test.log 2>&1
  if grep -q "hello" /tmp/model-test.log; then
    echo "✓ Inferência do modelo funcionando"
  else
    echo "✗ Falha na inferência do modelo"
    cat /tmp/model-test.log
    exit 1
  fi
fi

echo ""
echo "=== Health check concluído ==="

Ao rodar, a saída fica parecida com isto:

=== Health check do serviço Ollama ===
✓ Versão: 0.1.30
✓ Serviço em execução (PID: 12345)
✓ API respondendo normalmente
Modelo de teste: llama3.2:latest
✓ Inferência do modelo funcionando

=== Health check concluído ===

Se qualquer item falhar, o script encerra com erro e ajuda você a localizar o problema rapidamente.

Script de comparação de desempenho (monitoramento)

Depois do rollback, vale comparar o desempenho antes e depois. Este script mede tempo de resposta e uso de memória.

#!/bin/bash
# performance-check.sh - Script de comparação de desempenho

echo "=== Teste de benchmark de desempenho ==="

# Testa o tempo de resposta da API
echo "Testando velocidade de resposta da API..."
START=$(date +%s%N)
curl -X POST http://localhost:11434/api/generate \
  -d '{"model":"llama3.2","prompt":"Hello","stream":false}' \
  -H "Content-Type: application/json" > /tmp/perf-test.json 2>&1
END=$(date +%s%N)
RESPONSE_TIME=$((($END - $START) / 1000000))

echo "Tempo de resposta da API: ${RESPONSE_TIME}ms"

# Verifica uso de memória
MEMORY_USAGE=$(ps aux | grep ollama | grep -v grep | awk '{print $4}')
MEMORY_MB=$(ps aux | grep ollama | grep -v grep | awk '{print $6}')

echo "Uso de memória: ${MEMORY_USAGE}% (${MEMORY_MB}KB)"

# Registra em arquivo
echo "$(date): versão=$(ollama --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+'), resposta=${RESPONSE_TIME}ms, memória=${MEMORY_MB}KB" >> ~/.ollama-performance.log

echo ""
echo "Dados salvos em ~/.ollama-performance.log"
echo "Compare os dados antes e depois do rollback para confirmar a recuperação de desempenho"

Uma vez, depois de voltar a versão, rodei esse script e vi o tempo de resposta cair de 5000 ms para 200 ms, enquanto o uso de memória caiu de 80% para 35%. Foi aí que fiquei realmente tranquilo: o rollback tinha resolvido o problema.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Também deixei esses scripts organizados no GitHub para uso direto. Junto com as opções de coexistência de versões que vêm a seguir, eles deixam o gerenciamento de versões quase todo automatizado.

Coexistência de múltiplas versões na prática: configuração e estratégia

Às vezes, você precisa rodar várias versões de modelo ao mesmo tempo. Por exemplo: ambiente de desenvolvimento com uma versão de teste e produção travada em uma versão estável. O Ollama não oferece coexistência de versões por padrão, mas dá para contornar essa limitação.

Três opções de coexistência: cada uma com seus custos

Opção 1: separar versões com tags

Esse é o método mais simples. O Ollama permite aplicar tags a modelos, e você pode usar essas tags para diferenciar versões.

# Cria versões diferentes do modelo usando tags
ollama create myproject-llama3.2:v1.0 -f Modelfile-v1.0
ollama create myproject-llama3.2:v2.0 -f Modelfile-v2.0

# Lista todas as versões
ollama list
# Saída parecida:
# myproject-llama3.2:v1.0    4.7 GB   2026-05-10
# myproject-llama3.2:v2.0    4.7 GB   2026-05-14

# Executa uma versão específica
ollama run myproject-llama3.2:v1.0 "seu prompt"
ollama run myproject-llama3.2:v2.0 "seu prompt"

Mas existe uma pegadinha: no mesmo instante, só dá para carregar uma versão. Se você precisa rodar várias versões em paralelo, use uma das opções abaixo.

Opção 2: múltiplas instâncias (portas diferentes)

Esse método serve quando você quer executar vários modelos ao mesmo tempo. Cada instância usa uma porta diferente.

# Inicia a primeira instância (porta padrão 11434)
ollama serve

# Inicia a segunda instância (porta 11435)
OLLAMA_HOST=0.0.0.0:11435 ollama serve &
# Este processo roda de forma independente na porta 11435

# Testa as duas instâncias
curl http://localhost:11434/api/version  # Primeira
curl http://localhost:11435/api/version  # Segunda

# Especifica a porta ao chamar a API
curl http://localhost:11435/api/generate \
  -d '{"model":"llama3.2","prompt":"test"}'

A vantagem das múltiplas instâncias é a flexibilidade. O custo é o consumo de recursos: cada instância precisa carregar o modelo na memória. Se seus modelos são grandes, com dezenas de GB, a pressão na memória fica séria. A gestão também fica mais chata, porque você precisa lembrar qual porta corresponde a qual versão.

Opção 3: vários containers Docker (a mais estável)

Se você quer isolação real entre versões, Docker é a opção mais confiável. Cada container roda uma versão, totalmente independente.

# docker-compose.yml
version: '3'
services:
  ollama-stable:
    image: ollama/ollama:0.1.30
    container_name: ollama-stable
    volumes:
      - ./data-stable:/root/.ollama
    ports:
      - "11434:11434"

  ollama-dev:
    image: ollama/ollama:0.6.8
    container_name: ollama-dev
    volumes:
      - ./data-dev:/root/.ollama
    ports:
      - "11435:11434"  # Mapeia para a porta 11435 no host

Deploy:

# Inicia todos os containers
docker-compose up -d

# Verifica o estado dos containers
docker-compose ps

# Testa as duas versões
curl http://localhost:11434/api/version  # Versão estável (0.1.30)
curl http://localhost:11435/api/version  # Versão de desenvolvimento (0.6.8)

Cada container tem seu próprio diretório de dados (data-stable, data-dev), então os modelos não interferem uns nos outros. Você pode instalar llama3.2 em um container e mistral em outro, rodar os dois ao mesmo tempo e evitar conflitos.

Estratégia de gerenciamento de versões: nomear, fixar e limpar

Depois que várias versões coexistem, a estratégia de gerenciamento importa bastante. Sem isso, o número de modelos cresce e o disco estoura.

Padrão de nomes: use nomes claros para separar versões.

# Recomendado: nome do projeto + nome do modelo + versão
myproject-llama3.2:prod-v1.0
myproject-llama3.2:dev-v2.0
myproject-mistral:test-v0.1

# Não recomendado: nomes vagos
test-model-1
test-model-2

Fixação de versão: evite atualizações acidentais.

# Homebrew
brew pin ollama

# APT
sudo apt-mark hold ollama

# Docker: use tag de versão, não latest
image: ollama/ollama:0.1.30  # Versão fixa
# Não use image: ollama/ollama:latest

Limpeza regular: remova versões que você não usa.

# Lista todos os modelos
ollama list

# Remove versões antigas em lote (exemplo)
ollama rm myproject-llama3.2:test-v0.5
ollama rm myproject-llama3.2:dev-v1.2

# Ou use um script para limpeza em lote
for model in $(ollama list | grep "test-" | awk '{print $1}'); do
  ollama rm $model
done

Análise de issues no GitHub: limite oficial e alternativas da comunidade

Essa necessidade aparece bastante nas discussões da comunidade. GitHub Issue #2109 e #11196 mencionam a mesma limitação: por padrão, o Ollama não suporta coexistência de múltiplas versões.

A posição oficial é que um único processo do Ollama só carrega uma instância de modelo. Se você precisa de várias versões, use tags (opção 1) ou rode múltiplos processos/containers (opções 2 e 3).

Um comentário resume bem: “A limitação oficial torna o gerenciamento de múltiplas versões mais complexo, mas os workarounds da comunidade são bem práticos. Usar vários containers Docker é a opção mais estável; exige um pouco mais de configuração, mas entrega isolação de verdade.”

Testei as três opções, e os vários containers Docker realmente dão menos dor de cabeça. Você escreve algumas linhas a mais de configuração, mas ganha em isolação e estabilidade. Em produção, é a opção que eu recomendo com mais força.

Troubleshooting e boas práticas

No processo de rollback, algumas armadilhas aparecem mais de uma vez. Aqui está um pequeno manual de troubleshooting para localizar problemas com rapidez.

Problemas comuns

Problema de permissão

Esse é o mais comum. Depois de substituir o binário, muita gente esquece de dar permissão de execução.

# Sintoma: ao rodar ollama, aparece "Permission denied"
# Solução:
sudo chmod +x /usr/local/bin/ollama

# Se houver problema de permissão no diretório
sudo chown -R $(whoami) ~/.ollama

Meu primeiro rollback travou exatamente aqui. O arquivo tinha sido substituído, mas executar sempre retornava erro de permissão. Só depois percebi que o arquivo baixado com curl não vinha com permissão de execução.

Falha ao iniciar o serviço

Depois do rollback, se o serviço não inicia, geralmente a porta está ocupada ou sobrou algum processo antigo.

# Sintoma: ollama serve retorna "Address already in use"
# Verifica uso da porta
lsof -i :11434

# Mata o processo que ocupa a porta
kill -9 <PID>

# Ou reinicia o serviço
sudo systemctl restart ollama  # Linux

Uma vez, depois de voltar a versão, a porta continuava ocupada. Depois de investigar, encontrei um processo antigo rodando em segundo plano. Só depois de usar pkill -9 ollama o serviço subiu normalmente.

Erro ao carregar modelos

Depois do rollback, alguns modelos podem falhar ao carregar. A causa pode ser arquivo corrompido ou incompatibilidade com a versão.

# Sintoma: ollama run model-name retorna erro
# Verifica o estado do modelo
ollama show model-name

# Força um novo download
ollama pull model-name --force

# Se ainda falhar, remova e baixe novamente
ollama rm model-name
ollama pull model-name

Já passei por um caso em que um modelo falhava sempre depois do rollback. No fim, o arquivo do modelo tinha sido alterado acidentalmente durante o processo. Baixar de novo resolveu. Por isso o backup de ~/.ollama antes do rollback é tão importante.

Conflito de configuração

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Às vezes, configurações geradas por uma versão nova não são compatíveis com uma versão antiga.

# Sintoma: resultado de inferência estranho ou serviço caindo
# Redefine a configuração
rm ~/.ollama/ollama.db  # Remove o banco de configuração
ollama serve  # Reinicia e gera a configuração novamente

# Restaura modelos manualmente
ollama pull model-name

Essa armadilha é mais discreta. Há relatos de usuários com parâmetros da versão nova ainda presentes nos arquivos de configuração; a versão antiga não conseguia interpretá-los, e o serviço caía. Remover o banco de configuração e deixar o Ollama recriá-lo resolveu.

Boas práticas: quatro regras para evitar armadilhas

Depois de tropeçar bastante, cheguei a um conjunto de boas práticas. Seguindo isso, você evita a maior parte dos problemas.

Regra 1: estratégia de versão fixa

Antes de atualizar, fixe a versão atual. Assim, se a atualização quebrar algo, você pelo menos sabe para qual versão deve voltar.

# Homebrew
brew pin ollama

# APT
sudo apt-mark hold ollama

# Docker: use tag de versão
image: ollama/ollama:0.1.30

Regra 2: teste antes de produção

Antes de fazer rollback em produção, teste o fluxo inteiro no ambiente de desenvolvimento. Use o script de health check para garantir que tudo funciona.

# Testa o fluxo de rollback no ambiente de desenvolvimento
./ollama-rollback.sh 0.1.30

# Health check
./health-check.sh

# Comparação de desempenho
./performance-check.sh

Regra 3: registre o rollback

Em cada rollback, registre motivo, versão e resultado. Isso ajuda muito em investigações futuras.

# Registra o rollback
echo "Registro de rollback: $(date) - de 0.6.8 para 0.1.30, motivo: queda de desempenho" >> ~/.ollama-rollback-log.txt

# Registro detalhado
cat >> ~/.ollama-rollback-log.txt << EOF
Data: 2026-05-14
Versão original: 0.6.8
Versão-alvo: 0.1.30
Motivo: depois da atualização, o tempo de resposta da API saltou de 200 ms para 5000 ms
Resultado: sucesso, resposta voltou para 200 ms
Observação: backup em ~/.ollama-backups/ollama-backup-20260514
EOF

Regra 4: backups regulares

Faça backup regular do diretório ~/.ollama, especialmente dos arquivos de modelo. Esse diretório pode ser grande, mas é importante.

# Backup simples (somente configuração)
cp ~/.ollama/ollama.db ~/.ollama-backup.db

# Backup completo (inclui modelos e exige espaço suficiente)
tar -czf ~/.ollama-backup-$(date +%Y%m%d).tar.gz ~/.ollama

# Limpeza regular de backups antigos (mantém os 5 mais recentes)
ls -t ~/.ollama-backup-*.tar.gz | tail -n +6 | xargs rm -f

Ferramentas recomendadas: três scripts para automatizar o gerenciamento

Os três scripts citados acima já deixam boa parte do processo organizada:

• ollama-rollback.sh: rollback em um comando, com restauração automática em caso de falha
• health-check.sh: health check em quatro dimensões
• cleanup_models.sh: limpeza em lote de modelos antigos (vindo da Part 2)

Com esses scripts, o gerenciamento de versões fica quase automático. Na hora crítica, um comando resolve o rollback, sem correria e sem depender de memória.

Conclusão

Depois de tudo isso, o núcleo do processo cabe em três passos: backup, rollback e validação.

Backup é o primeiro passo e também o mais fácil de ignorar. Fazer backup de ~/.ollama antes do rollback realmente pode salvar o dia. Uma vez, por não ter backup, perdi um dia inteiro refazendo configuração depois de uma tentativa de rollback falhar.

A escolha do método depende do seu deploy. Quem usa Docker sofre menos: é só trocar a versão da imagem. Quem instalou manualmente consegue resolver rápido com troca de binário. O ponto é escolher o método certo e seguir os passos sem improvisar.

Validação não é opcional. Depois do rollback, rode o script de health check e confirme versão, serviço, API e modelo. Não basta olhar o número da versão e assumir que está tudo certo. Eu já caí nessa.

Três coisas que você pode fazer agora:

1. Teste o fluxo de rollback hoje. Rode em um ambiente de desenvolvimento, entenda cada etapa e execute o health check. Não espere a emergência para descobrir o processo.

2. Guarde estes três scripts: ollama-rollback.sh, health-check.sh e performance-check.sh. Na hora crítica, eles ajudam a localizar problemas rápido e evitam horas de investigação.

3. Fixe sua versão estável. Se a versão que você usa hoje está estável, trave-a agora. Use brew pin, apt-mark hold ou uma tag de versão no Docker, conforme o seu ambiente. Não deixe uma atualização acidental bagunçar o sistema.

Gerenciamento de versões parece pequeno no dia a dia, mas quando dá problema, pode travar um projeto inteiro. Dominar esse fluxo não elimina todos os riscos, mas evita que você fique sem direção quando uma atualização quebra o ambiente.

Este é o Part 3 da série Guia Prático de LLM Local com Ollama. O Part 1 cobriu os fundamentos, o Part 2 entrou no gerenciamento básico de modelos, e este artigo mergulhou em rollback de versão e coexistência de múltiplas versões. No próximo, Part 4, vamos falar de ajuste de parâmetros no Modelfile: como fazer o modelo rodar mais rápido, com mais estabilidade e menor custo.

Se este artigo foi útil, salve e compartilhe. Se tiver dúvidas, deixe um comentário; vou responder sempre que der.