Ollama puede ejecutarse en CPU, pero la experiencia varía enormemente. A continuación se muestra una referencia de configuración bastante realista:

Si solo quieres probarlo, puedes intentarlo con un VPS de CPU; si quieres sustituir realmente las API, usarlo con varias personas o conectarlo a sistemas de negocio, prioriza un VPS con GPU y fíjate especialmente en la VRAM, no solo en el número de núcleos de CPU.

Este artículo elige el despliegue con Docker Compose por razones sencillas:

1. Ollama y Open WebUI se pueden gestionar por separado.
2. Los directorios de datos son claros, lo que facilita la copia de seguridad y la migración.
3. Si hay un problema, los contenedores se pueden reiniciar individualmente sin contaminar el host.
4. Más adelante, conectar el proxy inverso Nginx/Caddy también resulta más cómodo.

Si ya usas 1Panel, también puedes instalar Open WebUI desde la tienda de aplicaciones y rellenar la dirección de Ollama. Pero escribir el Compose a mano es más transparente y adecuado para solucionar problemas.

Se recomienda usar Ubuntu 22.04 / 24.04 o Debian 12. Primero actualiza el sistema e instala Docker:

sudo apt update
sudo apt install -y ca-certificates curl gnupg
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER

Después de volver a iniciar sesión por SSH, confirma Docker y Compose:

docker version
docker compose version

Si los comandos devuelven los números de versión con normalidad, puedes continuar.

mkdir -p ~/ollama-webui
cd ~/ollama-webui
mkdir -p ollama open-webui

El significado de los directorios es sencillo:

• ollama/: guarda los archivos de los modelos.
• open-webui/: guarda los datos de WebUI, usuarios, registros de chat y configuración.

Los archivos de modelo pueden ser muy grandes, por lo que se recomienda que tu VPS tenga al menos 50 GB de disco disponible. Si planeas descargar varios modelos, 80 GB o más es más seguro.

Crea el archivo:

nano docker-compose.yml

Escribe el siguiente contenido:

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    volumes:
      - ./ollama:/root/.ollama
    expose:
      - "11434"

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    depends_on:
      - ollama
    ports:
      - "127.0.0.1:3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - ./open-webui:/app/backend/data

Aquí hay dos puntos de seguridad importantes:

1. Ollama solo usa expose y no se expone directamente a Internet.
2. Open WebUI se vincula a 127.0.0.1:3000, primero permitiendo solo el acceso local, y después abriendo HTTPS mediante un proxy inverso Nginx o Caddy.

No asignes 11434:11434 directamente a Internet. Una vez que la API de Ollama queda expuesta, otros pueden llamar directamente a tu modelo, lo que como mínimo agota los recursos y como máximo provoca abusos.

docker compose up -d

Comprobar el estado:

docker ps

Ver los registros:

docker logs -f ollama
docker logs -f open-webui

Si Open WebUI no arranca, las causas habituales son la descarga lenta de la imagen, disco insuficiente o memoria insuficiente. No te apresures a reinstalar; mira primero los registros.

Entra en el contenedor de Ollama:

docker exec -it ollama bash

Descarga un modelo relativamente pequeño para probar:

ollama pull llama3.1:8b
ollama run llama3.1:8b

Si tu máquina no tiene suficiente memoria, la descarga del modelo puede tener éxito, pero la ejecución será muy lenta e incluso puede provocar OOM. Los VPS de baja configuración pueden probar primero modelos más pequeños, como versiones cuantizadas de 3B o menores.

Sal del contenedor:

exit

Supongamos que tu dominio es ai.example.com. Primero apunta el registro DNS A a la IP del VPS y luego instala Nginx:

sudo apt install -y nginx certbot python3-certbot-nginx

Crea la configuración del sitio:

sudo nano /etc/nginx/sites-available/open-webui

Escribe:

server {
    listen 80;
    server_name ai.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600;
    }
}

Habilita el sitio:

sudo ln -s /etc/nginx/sites-available/open-webui /etc/nginx/sites-enabled/open-webui
sudo nginx -t
sudo systemctl reload nginx

Emite el certificado:

sudo certbot --nginx -d ai.example.com

Cuando termines, visita https://ai.example.com. La primera vez que entres en Open WebUI se creará una cuenta de administrador.

Se recomienda abrir solo estos puertos:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

No abras:

• 11434: puerto de la API de Ollama.
• 3000: puerto interno de Open WebUI, ya proxificado por Nginx.

Si usas el grupo de seguridad de un proveedor de nube, también debes restringirlo allí. Muchas personas solo configuran UFW pero olvidan el firewall de la nube, por lo que los puertos siguen siendo accesibles desde la red externa.

Es normal que un VPS de CPU ejecute modelos grandes lentamente; no es necesariamente un error de despliegue. Puedes evaluarlo desde estos aspectos:

htop
free -h
docker stats
df -h

Cuellos de botella habituales:

• Memoria insuficiente: tras cargar el modelo, la memoria disponible es casi 0 y el sistema empieza a usar swap.
• La CPU no admite AVX2: la velocidad de inferencia será peor.
• Disco demasiado lento: la carga del modelo tarda mucho.
• Demasiada concurrencia: va bien para una persona, pero se atasca cuando varias preguntan a la vez.

Sugerencias de optimización:

1. Empieza con modelos pequeños; no vayas directamente a 14B/32B.
2. Limita el número de usuarios; no uses un VPS personal como servicio de IA público.
3. Coloca el directorio de modelos en un disco NVMe, no en un VPS de almacenamiento grande muy lento.
4. Si realmente necesitas uso diario, considera un VPS con GPU o una máquina local con tarjeta gráfica.

Actualizar contenedores:

cd ~/ollama-webui
docker compose pull
docker compose up -d

Hacer copia de seguridad de los datos:

tar -czf ollama-webui-backup-$(date +%F).tar.gz ollama open-webui docker-compose.yml

Si los archivos de modelo son demasiado grandes, también puedes hacer copia de seguridad solo de open-webui/ y docker-compose.yml, y volver a descargar los modelos más adelante.

En las siguientes situaciones, se recomienda usar directamente una API o elegir un servicio con GPU:

1. Solo tienes un VPS barato de 1C1G / 1C2G.
2. Quieres que varias personas lo usen al mismo tiempo.
3. Necesitas respuestas estables y rápidas.
4. Necesitas ejecutar modelos de 14B, 32B o mayores.
5. El espacio en disco del VPS es muy pequeño, solo unos 20 GB.

El despliegue de Ollama es sencillo, pero lo realmente difícil son el coste y las expectativas de rendimiento. Si solo estás aprendiendo, puedes probar un VPS normal de 4C8G; si quieres usarlo a largo plazo, es mejor empezar a evaluar desde 8C16G o un VPS con GPU.

El valor de Ollama + Open WebUI no es "sustituir gratis todas las API de IA", sino que puedes controlar los datos, los modelos y los puntos de acceso en tus propias manos. Para bases de conocimiento personales, preguntas y respuestas internas, consulta de fragmentos de código y asistentes privados de equipos pequeños, resulta muy atractivo.

Pero la elección del VPS debe ser realista: que solo con CPU pueda ejecutarse no significa que la experiencia sea buena; que la memoria alcance para descargar un modelo no significa que sea utilizable por varias personas; que los puertos puedan abrirse no significa que deban exponerse a Internet. Lo correcto es validar primero con un modelo pequeño y luego decidir si actualizar a un VPS de mayor configuración o a un VPS con GPU según los requisitos de latencia, memoria, disco y concurrencia.