Rollback de versiones en Ollama: 3 pasos clave que el 90% de desarrolladores ignora

Haces clic en el aviso de actualización de Ollama, pasas a la versión 0.6.8 y la respuesta de la API pasa de 200 ms a 5 segundos, el uso de memoria se duplica y hasta ollama run llama3.2 se queda colgado. En el GitHub Issue #10652, decenas de usuarios se quejan: «Tras la actualización el sistema es inutilizable y quiero volver atrás, pero la documentación oficial no ofrece descargas de versiones antiguas».

La respuesta oficial es directa: solo se admite la última versión; el rollback no está soportado de momento.

El golpe fue tan duro que ahora, antes de cada actualización, hago un backup completo. En este artículo comparto tres métodos de rollback (reemplazo binario, gestor de paquetes y Docker), scripts de automatización en un clic, configuración para convivir con varias versiones y todos los problemas que ya me he encontrado.

¿Por qué necesitas rollback de versiones? Escenarios reales

Actualizar software suele ser buena idea: nuevas funciones, mejor rendimiento, corrección de bugs. Pero con Ollama, a veces la actualización trae una «sorpresa» grande.

Tres riesgos: rendimiento, compatibilidad y estabilidad

Estos son los tres casos que más he visto:

Caída brusca del rendimiento. Algunos usuarios reportan que, tras actualizar a cierta versión, la velocidad de inferencia pasa de 50 tokens/s a menos de 10. El uso de memoria también se duplica sin motivo aparente: un modelo de 4 GB puede consumir 8 GB. Tu aplicación se vuelve lenta y el usuario espera medio minuto por una respuesta — nadie lo tolera.

Incompatibilidad de la API. Esto es más sutil. Actualizas Ollama, no tocas el código y las llamadas a la API empiezan a fallar. Puede cambiar el nombre de un parámetro, el formato de respuesta o desaparecer algún endpoint. En un proyecto mío, tras actualizar dejó de funcionar el parámetro timeout de api/generate y todas las tareas largas se cortaban por timeout. Resultó que la nueva versión había cambiado el comportamiento por defecto de ese parámetro.

Inestabilidad del sistema. Lo peor. El servicio se reinicia sin aviso, los modelos no cargan y los logs muestran errores crípticos. En una ocasión, Ollama se cerraba cada media hora; al reiniciar funcionaba un rato y volvía a caer. Tras dos días descubrí que era un bug de fuga de memoria en la nueva versión.

GitHub Issue #10652: voces reales de usuarios

Este issue se abrió el 10 de mayo de 2025 y ya suma más de cien participantes. El título es claro: «Ability to downgrade» (posibilidad de degradar versión).

La descripción del autor me marcó: «Tras actualizar a 0.6.8, el sistema casi no funciona. La inferencia es inaceptablemente lenta y las llamadas a la API hacen timeout con frecuencia. Probé varios ajustes de configuración sin éxito. Quiero volver a la versión anterior, pero la documentación oficial solo ofrece la última».

En los comentarios, otro usuario fue más directo: «Pasé tres días depurando y al final era un bug conocido de la nueva versión. La documentación oficial aún no lo había corregido. Esperé dos semanas y el bug seguía. Todo el avance del proyecto quedó bloqueado por el problema de versión».

No es un caso aislado. En Reddit y foros similares abundan quejas parecidas. Algunos tuvieron que pausar el desarrollo; otros, para evitar riesgos, dejaron de actualizar y se quedaron en una versión antigua.

Limitación oficial: solo la última versión

La raíz del problema: la página de descarga de Ollama siempre muestra solo la última versión. En GitHub Releases sí hay versiones históricas, pero la documentación oficial no explica cómo hacer rollback. Homebrew, APT y otros gestores instalan la última versión por defecto.

Podrías pensar: «No actualizo y ya está». Pero a veces la actualización no depende de ti: dependencias del sistema, otras herramientas que lo exigen o un clic accidental en el botón de actualizar (fui yo). Cuando detectas el problema, a menudo ya es tarde para volver atrás fácilmente.

Y aunque encuentres el paquete de la versión antigua, el rollback en sí conlleva riesgos: ¿se pierden los modelos? ¿Hay conflictos de configuración? ¿Arranca el servicio? Son incógnitas.

Por eso dominar un método fiable de rollback puede salvarte. A continuación desglosamos tres enfoques habituales para hacer rollback rápido y evitar las trampas habituales.

Rollback en la práctica: tres métodos comparados

Conclusión previa: cada método tiene pros y contras; la elección depende de cómo despliegues Ollama y del tiempo que tengas.

Comparativa: tiempo, dificultad y escenario

Si me preguntas, Docker es lo más cómodo. Si no usas contenedores, el reemplazo binario también resuelve rápido. Veamos cada método paso a paso.

Método 1: reemplazo binario (el más rápido, pero manual)

Sustituyes directamente el ejecutable de Ollama. Ventaja: velocidad. Inconveniente: backup y verificación a tu cargo.

Paso 1: detener el servicio

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

# macOS/Linux
ollama stop
# Si el comando anterior no funciona, usa esto
sudo systemctl stop ollama  # Linux
# O mata el proceso directamente
pkill -9 ollama

Si no se detiene, comprueba procesos residuales:

ps aux | grep ollama
lsof -i :11434  # Ver ocupación del puerto

Paso 2: hacer backup de la instalación actual

No te saltes este paso. Yo una vez no hice backup y, cuando el rollback falló, fue un desastre.

# Backup del binario
sudo cp /usr/local/bin/ollama ~/ollama-backup-current

# Backup de configuración y modelos (este directorio puede ser muy grande)
# ~/.ollama guarda todos los modelos; pueden ser decenas de GB
cp -r ~/.ollama ~/.ollama-backup-$(date +%Y%m%d)

Al hacer backup, mira el tamaño del directorio. Una vez vi que ~/.ollama superaba los 40 GB y tuve que limpiar modelos antiguos.

du -sh ~/.ollama  # Ver tamaño
# Si es demasiado grande, elimina modelos que no uses
ollama list  # Ver modelos instalados
ollama rm unused-model-name  # Eliminar los que no necesites

Paso 3: descargar la versión objetivo

Busca la versión en GitHub Releases:

# Abre la página de GitHub Releases
https://github.com/ollama/ollama/releases

# Localiza la versión que necesitas, por ejemplo 0.1.30
# Descarga el binario de tu 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

Atención al nombre del archivo: el paquete cambia según el sistema. Si descargas el incorrecto, fallará al reemplazar.

Paso 4: reemplazar el binario

# Dar permisos de ejecución al archivo descargado
chmod +x ollama-v0.1.30

# Reemplazar el ollama del sistema
sudo mv ollama-v0.1.30 /usr/local/bin/ollama

# Si hay problemas de permisos, elimina el antiguo y copia de nuevo
sudo rm /usr/local/bin/ollama
sudo cp ollama-v0.1.30 /usr/local/bin/ollama
sudo chmod +x /usr/local/bin/ollama

Paso 5: verificar que el rollback fue exitoso

# Comprobar versión
ollama --version
# Debería mostrar: ollama version 0.1.30 (o la versión a la que volviste)

# Iniciar servicio
ollama serve

# Probar API
curl http://localhost:11434/api/version
# Debería devolver: {"version":"0.1.30"}

# Probar inferencia (modelo pequeño para validar rápido)
ollama run llama3.2 "Hello, test"

Si la versión, la API y el modelo funcionan, listo. Si algo falla, restaura el backup:

sudo mv ~/ollama-backup-current /usr/local/bin/ollama
ollama serve  # Reiniciar servicio

Método 2: rollback con gestor de paquetes (estable, ideal para Homebrew/APT)

Si instalaste con Homebrew (macOS) o APT (Ubuntu), este método es cómodo: el gestor se encarga de versiones y dependencias.

Homebrew (macOS)

# Desinstalar versión actual
brew uninstall ollama

# Instalar versión concreta (supongamos 0.1.30)
# Homebrew no siempre tiene todas las versiones antiguas; compruébalo
brew search ollama  # Ver versiones disponibles

# Si no está la que necesitas, instala manualmente
brew install [email protected]  # Si existe esa fórmula

# Fijar versión para evitar actualizaciones automáticas
brew pin ollama

# Verificar
ollama --version

Homebrew puede ser caprichoso con versiones antiguas: a veces no están en el repositorio y toca usar el método 1.

APT (Ubuntu/Debian)

# Ver versiones disponibles
apt-cache policy ollama

# Instalar versión concreta
sudo apt-get install ollama=0.1.30-1

# Fijar versión
sudo apt-mark hold ollama

# Verificar
ollama --version

APT suele ser más predecible: el repositorio oficial a menudo conserva varias versiones.

Método 3: rollback con contenedor Docker (el más seguro, aislamiento total)

Si despliegas con Docker, el rollback es sencillo: cambias de imagen.

Pull de imagen con versión concreta

# Ver contenedor en ejecución
docker ps | grep ollama

# Detener contenedor actual
docker stop ollama-container
docker rm ollama-container

# Pull de la versión objetivo
docker pull ollama/ollama:0.1.30

# Ejecutar contenedor (con etiqueta de versión)
docker run -d \
  --name ollama-container \
  -v ~/.ollama:/root/.ollama \
  -p 11434:11434 \
  ollama/ollama:0.1.30

# Verificar versión en el contenedor
docker exec ollama-container ollama --version

Fijar versión con docker-compose

Si usas docker-compose, edita docker-compose.yml:

services:
  ollama:
    image: ollama/ollama:0.1.30  # Fija la versión; no uses latest
    volumes:
      - ~/.ollama:/root/.ollama
    ports:
      - "11434:11434"

Luego redespliega:

docker-compose down
docker-compose up -d

Ventaja de Docker: los modelos viven en ~/.ollama del host; al cambiar de versión del contenedor, los datos no se mueven. Además, los contenedores están aislados: incluso puedes ejecutar varias versiones de Ollama a la vez (lo veremos más adelante).

Scripts de rollback automatizado y health check

El rollback manual funciona, pero repetir muchos comandos es propenso a errores. Preparé un conjunto de scripts que cubren rollback, verificación y monitorización.

Script de rollback en un clic (ollama-rollback.sh)

Este script detiene el servicio, hace backup, descarga, reemplaza y verifica. Si falla, restaura el backup automáticamente.

#!/bin/bash
# ollama-rollback.sh - Script de rollback de versión de Ollama en un clic
# Uso: ./ollama-rollback.sh <número de versión objetivo>

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

if [ -z "$TARGET_VERSION" ]; then
  echo "Error: especifica la versión objetivo"
  echo "Uso: ./ollama-rollback.sh <versión>"
  exit 1
fi

echo "=== Iniciando rollback de Ollama a la versión $TARGET_VERSION ==="

# Paso 1: detener servicio
echo "[1/5] Deteniendo servicio de Ollama..."
ollama stop || pkill -9 ollama
sleep 2

# Paso 2: backup de la versión actual
BACKUP_NAME="ollama-backup-$(date +%Y%m%d-%H%M%S)"
echo "[2/5] Guardando backup en $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

# Paso 3: descargar versión objetivo
echo "[3/5] Descargando 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 "¡Descarga fallida! Restaurando backup..."
  cp $BACKUP_DIR/$BACKUP_NAME/ollama-bin $OLLAMA_BIN
  exit 1
}

# Paso 4: reemplazar binario
echo "[4/5] Reemplazando binario..."
chmod +x /tmp/ollama-$TARGET_VERSION
sudo mv /tmp/ollama-$TARGET_VERSION $OLLAMA_BIN

# Paso 5: verificar
echo "[5/5] Verificando 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 exitoso. Versión actual: $INSTALLED_VERSION"
  echo "Ubicación del backup: $BACKUP_DIR/$BACKUP_NAME"
else
  echo "✗ Verificación de versión fallida. Restaurando backup..."
  sudo cp $BACKUP_DIR/$BACKUP_NAME/ollama-bin $OLLAMA_BIN
  ollama serve
  exit 1
fi

Uso:

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

El script muestra el progreso paso a paso. Si la descarga falla o la versión no coincide, restaura el backup y evita dejarte a medias.

Script de health check (health-check.sh)

Tras el rollback, la versión en pantalla no basta: hay que confirmar que el servicio funciona. Este script revisa cuatro dimensiones: versión, servicio, API y modelo.

#!/bin/bash
# health-check.sh - Script de health check del servicio Ollama

echo "=== Health check del servicio Ollama ==="

# 1. Verificación de versión
VERSION=$(ollama --version 2>&1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
if [ -n "$VERSION" ]; then
  echo "✓ Versión: $VERSION"
else
  echo "✗ Fallo en comprobación de versión"
  exit 1
fi

# 2. Estado del servicio
SERVICE_PID=$(pgrep -f "ollama serve")
if [ -n "$SERVICE_PID" ]; then
  echo "✓ Servicio en ejecución (PID: $SERVICE_PID)"
else
  echo "✗ Servicio no está en ejecución"
  ollama serve
  sleep 3
fi

# 3. Respuesta de la 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 responde correctamente"
else
  echo "✗ API anómala (HTTP $API_RESPONSE)"
  exit 1
fi

# 4. Prueba de modelo
TEST_MODEL=$(ollama list | head -2 | tail -1 | awk '{print $1}')
if [ -z "$TEST_MODEL" ]; then
  echo "⚠ No hay modelos instalados"
else
  echo "Modelo de prueba: $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 "✓ Inferencia del modelo correcta"
  else
    echo "✗ Fallo en inferencia del modelo"
    cat /tmp/model-test.log
    exit 1
  fi
fi

echo ""
echo "=== Health check completado ==="

La salida puede verse así:

=== Health check del servicio Ollama ===
✓ Versión: 0.1.30
✓ Servicio en ejecución (PID: 12345)
✓ API responde correctamente
Modelo de prueba: llama3.2:latest
✓ Inferencia del modelo correcta

=== Health check completado ===

Si algo falla, el script termina con error y ayuda a localizar el problema.

Script de comparación de rendimiento (monitorización)

Tras el rollback, conviene comparar rendimiento antes y después. Este script mide tiempo de respuesta y uso de memoria.

#!/bin/bash
# performance-check.sh - Script de comparación de rendimiento

echo "=== Prueba de referencia de rendimiento ==="

# Medir tiempo de respuesta de la API
echo "Probando velocidad de respuesta de la 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 "Tiempo de respuesta de la API: ${RESPONSE_TIME}ms"

# Comprobar uso de memoria
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 memoria: ${MEMORY_USAGE}% (${MEMORY_MB}KB)"

# Guardar en archivo
echo "$(date): versión=$(ollama --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+'), respuesta=${RESPONSE_TIME}ms, memoria=${MEMORY_MB}KB" >> ~/.ollama-performance.log

echo ""
echo "Datos guardados en ~/.ollama-performance.log"
echo "Compara valores antes y después del rollback para confirmar la recuperación"

Tras un rollback mío, la respuesta pasó de 5000 ms a 200 ms y la memoria del 80 % al 35 %. Con esos números supe que el rollback había funcionado de verdad.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Tengo estos scripts en GitHub para descarga directa. Junto con las estrategias de convivencia de versiones que veremos, puedes acercarte a una gestión casi automatizada.

Convivencia de varias versiones: configuración y estrategia

A veces necesitas ejecutar varias versiones a la vez: entorno de desarrollo con una versión de prueba y producción con una estable. Ollama no lo admite por defecto, pero se puede sortear.

Tres enfoques: pros y contras

Enfoque 1: tags para distinguir versiones

Lo más simple: Ollama permite etiquetar modelos y usar el tag como versión.

# Crear distintas versiones del modelo (con tags)
ollama create myproject-llama3.2:v1.0 -f Modelfile-v1.0
ollama create myproject-llama3.2:v2.0 -f Modelfile-v2.0

# Ver todas las versiones
ollama list
# Salida similar a:
# myproject-llama3.2:v1.0    4.7 GB   2026-05-10
# myproject-llama3.2:v2.0    4.7 GB   2026-05-14

# Ejecutar una versión concreta
ollama run myproject-llama3.2:v1.0 "tu prompt"
ollama run myproject-llama3.2:v2.0 "tu prompt"

Trampa: solo una versión cargada a la vez. Para paralelismo real, usa los enfoques siguientes.

Enfoque 2: multiinstancia (puertos distintos)

Útil cuando quieres varios modelos a la vez. Cada instancia escucha en un puerto.

# Primera instancia (puerto por defecto 11434)
ollama serve

# Segunda instancia (puerto 11435)
OLLAMA_HOST=0.0.0.0:11435 ollama serve &
# Proceso independiente en el puerto 11435

# Probar ambas instancias
curl http://localhost:11434/api/version  # Primera
curl http://localhost:11435/api/version  # Segunda

# API indicando puerto
curl http://localhost:11435/api/generate \
  -d '{"model":"llama3.2","prompt":"test"}'

Es flexible, pero duplica recursos: cada instancia carga modelos en memoria. Con modelos grandes (decenas de GB), la presión de RAM es alta. También hay que recordar qué puerto corresponde a qué versión.

Enfoque 3: varios contenedores Docker (el más estable)

Para aislamiento real entre versiones, Docker es la opción más fiable: un contenedor por versión.

# 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"  # Expuesto en el host como 11435

Despliegue:

# Iniciar todos los contenedores
docker-compose up -d

# Ver estado
docker-compose ps

# Probar ambas versiones
curl http://localhost:11434/api/version  # Estable (0.1.30)
curl http://localhost:11435/api/version  # Desarrollo (0.6.8)

Cada contenedor tiene su directorio de datos (data-stable, data-dev); los modelos no se pisan. Puedes tener llama3.2 en un contenedor y mistral en otro, ejecutándose a la vez.

Estrategia de gestión: nombres, bloqueo y limpieza

Con varias versiones conviven, hace falta disciplina o el disco explota.

Convención de nombres: nombres claros por versión.

# Recomendado: proyecto + modelo + versión
myproject-llama3.2:prod-v1.0
myproject-llama3.2:dev-v2.0
myproject-mistral:test-v0.1

# No recomendado: nombres vagos
test-model-1
test-model-2

Fijar versión: evitar actualizaciones accidentales.

# Homebrew
brew pin ollama

# APT
sudo apt-mark hold ollama

# Docker: etiqueta concreta, no latest
image: ollama/ollama:0.1.30  # Versión fijada
# No uses image: ollama/ollama:latest

Limpieza periódica: eliminar versiones que ya no uses.

# Ver todos los modelos
ollama list

# Eliminar versiones antiguas (ejemplo)
ollama rm myproject-llama3.2:test-v0.5
ollama rm myproject-llama3.2:dev-v1.2

# O limpieza por lotes con script
for model in $(ollama list | grep "test-" | awk '{print $1}'); do
  ollama rm $model
done

Issues de GitHub: limitaciones oficiales y soluciones de la comunidad

Este tema se debate mucho. Los issues #2109 y #11196 señalan que Ollama no admite convivencia nativa de varias versiones.

La postura oficial: un solo proceso de Ollama carga una instancia de modelo a la vez. Para varias versiones, o usas tags (enfoque 1) o varios procesos/contenedores (enfoques 2 y 3).

Un comentario acertado: «La limitación oficial complica la gestión multiversión, pero los workarounds de la comunidad son útiles. Varios contenedores Docker es lo más estable: algo más de configuración, pero aislamiento real».

En mis pruebas, Docker multi-contenedor fue lo más tranquilo. Unas líneas más de configuración, pero mejor aislamiento y estabilidad. En producción, lo recomiendo.

Resolución de problemas y buenas prácticas

En el rollback he repetido algunos errores más de una vez. Aquí va un manual rápido para localizarlos.

Problemas frecuentes

Problemas de permisos

Muy habitual: reemplazas el binario y olvidas los permisos de ejecución.

# Síntoma: al ejecutar ollama, "Permission denied"
# Solución:
sudo chmod +x /usr/local/bin/ollama

# Si el directorio tiene permisos incorrectos
sudo chown -R $(whoami) ~/.ollama

La primera vez que hice rollback me quedé bloqueado aquí: el archivo estaba reemplazado pero sin permiso de ejecución tras descargarlo con curl.

Fallo al iniciar el servicio

Tras el rollback, a menudo el puerto sigue ocupado o queda un proceso colgado.

# Síntoma: ollama serve devuelve "Address already in use"
# Comprobar puerto
lsof -i :11434

# Matar proceso que ocupa el puerto
kill -9 <PID>

# O reiniciar servicio
sudo systemctl restart ollama  # Linux

Una vez, tras rollback, el puerto 11434 seguía en uso: el proceso antiguo seguía en segundo plano. Tras pkill -9 ollama arrancó bien.

Error al cargar modelos

Algunos modelos fallan tras el rollback por archivos dañados o incompatibilidad de versión.

# Síntoma: ollama run model-name devuelve error
# Comprobar estado del modelo
ollama show model-name

# Forzar nueva descarga
ollama pull model-name --force

# Si sigue fallando, borrar y volver a descargar
ollama rm model-name
ollama pull model-name

En un caso, un modelo no cargaba hasta que volví a hacer pull: el archivo se había corrompido durante el rollback. Otro motivo para hacer backup de ~/.ollama.

Conflictos de configuración

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

A veces la configuración de la versión nueva no encaja con la antigua.

# Síntoma: inferencias raras o caídas del servicio
# Resetear configuración
rm ~/.ollama/ollama.db  # Eliminar base de configuración
ollama serve  # Al reiniciar, se regenera la configuración

# Restaurar modelos manualmente
ollama pull model-name

Problema sutil: parámetros de la versión nueva en el archivo de config que la antigua no entiende y el servicio cae. Borrar ollama.db y regenerar suele bastar.

Buenas prácticas: cuatro reglas para evitar problemas

Tras tantos tropiezos, estas prácticas evitan la mayoría de los fallos.

Regla 1: fijar la versión

Antes de actualizar, bloquea la versión actual. Si la actualización falla, sabes exactamente a qué versión volver.

# Homebrew
brew pin ollama

# APT
sudo apt-mark hold ollama

# Docker: etiqueta de versión
image: ollama/ollama:0.1.30

Regla 2: probar antes de producción

En producción, prueba el rollback antes en desarrollo. Valida con el script de health check.

# Probar rollback en desarrollo
./ollama-rollback.sh 0.1.30

# Health check
./health-check.sh

# Comparación de rendimiento
./performance-check.sh

Regla 3: documentar cada rollback

Anota motivo, versiones y resultado para futuras incidencias.

# Registro breve
echo "Rollback: $(date) - de 0.6.8 a 0.1.30, motivo: caída de rendimiento" >> ~/.ollama-rollback-log.txt

# Registro detallado
cat >> ~/.ollama-rollback-log.txt << EOF
Fecha: 2026-05-14
Versión origen: 0.6.8
Versión objetivo: 0.1.30
Motivo: tras actualizar, respuesta API de 200 ms a 5000 ms
Resultado: éxito, respuesta vuelve a ~200 ms
Notas: backup en ~/.ollama-backups/ollama-backup-20260514
EOF

Regla 4: backups periódicos

Haz backup periódico de ~/.ollama, sobre todo de los modelos. Puede ocupar mucho, pero vale la pena.

# Backup simple (solo configuración)
cp ~/.ollama/ollama.db ~/.ollama-backup.db

# Backup completo (incluye modelos; necesitas espacio)
tar -czf ~/.ollama-backup-$(date +%Y%m%d).tar.gz ~/.ollama

# Limpiar backups antiguos (conservar los 5 más recientes)
ls -t ~/.ollama-backup-*.tar.gz | tail -n +6 | xargs rm -f

Herramientas recomendadas: tres scripts para automatizar

Los tres scripts mencionados:

• ollama-rollback.sh: rollback en un clic con restauración automática si falla
• health-check.sh: health check en cuatro dimensiones
• cleanup_models.sh: limpieza por lotes de modelos antiguos (del Part 2)

Con ellos, la gestión de versiones puede ser casi automática. En un incidente, un comando puede bastar.

Resumen

En esencia, son tres pasos: backup, rollback y verificación.

El backup es el primero y el más ignorado. Hacer backup de ~/.ollama antes del rollback puede salvarte. Yo una vez no lo hice y perdí un día reconfigurando tras un rollback fallido.

El método depende de cómo despliegues Ollama. Con Docker, cambiar de imagen es lo más cómodo. Con instalación manual, el reemplazo binario también es rápido. Elige el método y sigue los pasos con calma.

No te saltes la verificación. Tras el rollback, ejecuta el health check: versión, servicio, API y modelo. No basta con que coincida el número de versión; yo ya me equivoqué así.

Tres cosas que puedes hacer ahora:

1. Probar el flujo de rollback ya. En desarrollo, recorre todo el proceso, descarga los scripts y ejecuta un health check. No esperes a tener un incidente.

2. Guardar estos tres scripts. ollama-rollback.sh, health-check.sh y performance-check.sh. En un apuro acortan mucho el tiempo de diagnóstico.

3. Fijar tu versión estable. Si la que usas ahora va bien, bloquéala: brew pin, apt-mark hold o etiqueta de versión en Docker. Evita actualizaciones accidentales.

La gestión de versiones parece secundaria hasta que bloquea un proyecto entero. Con este flujo, al menos no estarás improvisando bajo presión.

Este artículo es la Parte 3 de la guía práctica de LLM local con Ollama. La Parte 1 cubre los fundamentos; la Parte 2, gestión básica de modelos; aquí profundizamos en rollback y convivencia de versiones. En la Parte 4 veremos afinación de parámetros en Modelfile: cómo hacer que el modelo vaya más rápido, más estable y con menos coste.

Si te resultó útil, guárdalo o compártelo. Si tienes dudas, déjalas en los comentarios y intentaré responder.