instalar ollama en un vps de forma segura

Lo que vas a construir

Un modelo de lenguaje de pesos abiertos ejecutándose en un servidor propio, con respuestas mediante una API HTTP y, opcionalmente, una página de chat en el navegador. Ollama es el componente que descarga el modelo, lo carga en memoria y atiende las peticiones en http://127.0.0.1:11434. La instalación consiste en un solo comando. La complejidad reside en otros factores: elegir un modelo que tu VPS pueda alojar en la RAM y evitar la publicación accidental de un servidor de inferencia sin autenticación en internet.

Dos advertencias importantes. Un VPS que solo use CPU ejecutará modelos pequeños con lentitud, y la API no incluye autenticación integrada. Ambos puntos se detallan a continuación, ya que son los errores más comunes.

Verificación de dimensiones con datos reales

El consumo de memoria de un modelo es aproximadamente su tamaño de archivo, más un gigabyte de sobrecarga en tiempo de ejecución, más un margen adicional para la ventana de contexto. Los modelos predeterminados de Ollama están cuantizados a 4 bits (etiquetados como Q4), lo que consume aproximadamente medio gigabyte de RAM por cada mil millones de parámetros. El cálculo es simple y determina todo el proceso.

Un modelo de 3B como llama3.2:3b requiere una descarga de ~2 GB y necesita unos 4 GB de RAM libre para ejecutarse. Un modelo de 7B u 8B como mistral:7b o llama3.1:8b ocupa ~5 GB en disco y requiere unos 8 GB de RAM, o 16 GB para un rendimiento óptimo. Un modelo de 13B o 14B requiere aproximadamente 16 GB. Cualquier modelo en el rango de 30B a 70B necesita un equipo con mucha RAM o, de forma realista, una GPU; en un VPS con CPU, el modelo no cabrá o responderá tan lento que será inútil.

Ahora la velocidad, ya que es el aspecto que la gente subestima. La inferencia en CPU depende del ancho de banda de la memoria, no de la velocidad de reloj, y un VPS con vCPU compartida tiene un ancho de banda limitado. Se esperan de un solo dígito a poco más de diez tokens por segundo: un modelo Q4 de 7-8B podría alcanzar entre 4 y 10 tokens por segundo, y un modelo de 3B entre 10 y 25. Una GPU es aproximadamente un orden de magnitud más rápida. Estas cifras son aproximadas a propósito; lo correcto es medir su propio equipo, como se muestra en el paso de ejecución a continuación. Confíe en su eval rate, no en las cifras de ningún artículo, incluido este.

Conclusión práctica: los modelos cuantizados pequeños en CPU son útiles para redactar, resumir y clasificar si se acepta su velocidad. Para cualquier tarea más grande o rápida, presupueste una instancia con GPU.

Para comparar un modelo específico con un equipo específico, estime su consumo de memoria aquí:

Instalar Ollama

Existen dos métodos limpios. El script oficial es el más sencillo en un VPS limpio:

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

Esto crea un usuario de sistema llamado ollama, instala el binario en /usr/local/bin/ollama y registra un servicio systemd llamado ollama.service que se inicia al arrancar el sistema y vincula 127.0.0.1:11434. Confirme que funciona con:

systemctl status ollama
ollama --version

Si ya utiliza Docker, utilice el contenedor:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

Observe el prefijo 127.0.0.1: en el mapeo de puertos. Eso vincula el puerto únicamente a localhost. Escribir -p 11434:11434 en su lugar lo publica en todas las interfaces, que es el error que advierte la sección de seguridad. Elija un solo método de instalación; no ejecute el script y el contenedor al mismo tiempo, o dos procesos competirán por el puerto.

Descarga y ejecuta tu primer modelo

ollama pull llama3.2:3b
ollama run llama3.2:3b

pull descarga las capas del modelo al disco (aproximadamente 2 GB en este caso). run las carga en memoria y te entrega un prompt de >>>. Escribe una pregunta. El primer token puede tardar varios segundos mientras los pesos se cargan desde el disco a la RAM; después, la respuesta se transmite de forma continua. Escribe /bye para salir del chat; Ollama seguirá ejecutándose en segundo plano.

Verifica qué está cargado y cómo se distribuye:

ollama ps

La columna PROCESSOR indica el estado real. 100% CPU significa que no se está utilizando la GPU, lo cual causa la lentitud. Mide la velocidad real usando el flag verbose:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

La línea eval rate impresa al final muestra los tokens por segundo en este hardware. Ese es el valor para realizar tus cálculos de planificación.

Ubicación de los modelos y capacidad de disco necesaria

Los modelos instalados por el script y ejecutados como servicio se encuentran en el home del usuario ollama:

sudo du -sh /usr/share/ollama/.ollama/models

Si se ejecutan de forma interactiva con su propio usuario, se encuentran en ~/.ollama/models. En el contenedor, se almacenan en el volumen con nombre ollama. Esto es importante porque el peso de los modelos cuantizados aumenta rápidamente: un modelo de 3B ocupa ~2 GB, uno de 7-8B ocupa ~5 GB y uno de 14B ocupa ~9 GB. Si descarga cuatro modelos para compararlos, habrá consumido 20 GB sin darse cuenta. Calcule el tamaño del disco según los modelos que planee conservar y elimine el resto con ollama rm <model>.

Ejecútelo como un servicio controlado por usted

El script de instalación ya registró ollama.service, por lo que se reinicia al arrancar el sistema sin necesidad de intervención adicional. El ajuste que conviene modificar es el tiempo de permanencia de un modelo en memoria y, en algunas configuraciones, la dirección de enlace (bind address); ambos se configuran en un archivo drop-in de systemd para que una actualización de Ollama no los sobrescriba:

sudo systemctl edit ollama.service

Añada esto bajo el encabezado [Service] que muestra el editor:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE define cuánto tiempo permanece un modelo en memoria tras la última solicitud (por defecto 5 minutos). Auméntelo en equipos con consultas constantes para evitar la recarga de los pesos cada vez; ajústelo a 0 en equipos con recursos limitados para liberar la RAM inmediatamente al finalizar una solicitud. systemctl edit recarga los archivos de la unidad; reinicie para aplicar los cambios:

sudo systemctl restart ollama

El punto de seguridad más importante

Por defecto, Ollama se vincula a 127.0.0.1:11434, por lo que solo los procesos en el propio VPS pueden alcanzarlo. Esa configuración predeterminada es correcta. Manténgala.

La API no tiene autenticación. Ninguna. No hay clave de API, ni inicio de sesión, ni límite de tasa, ni lista de permitidos. Cualquier usuario que pueda alcanzar el puerto 11434 puede ejecutar cualquier modelo que haya descargado, descargar nuevos, eliminarlos y saturar su CPU o GPU al 100% de carga indefinidamente. Escáneres como Shodan indexan miles de instancias de Ollama abiertas, y una instancia expuesta es detectada y abusada en cuestión de horas.

Por tanto, este es el único error que nunca debe cometer: no configure OLLAMA_HOST=0.0.0.0 ni abra el puerto 11434 en su firewall. Eso publica un servidor de inferencia sin autenticación en todo internet. Ninguna configuración hace que el puerto 11434 expuesto en 0.0.0.0 sea seguro, porque Ollama no tiene nada que configurar: la autenticación simplemente no existe.

Existen tres formas seguras de acceder al modelo desde fuera del servidor:

• Manténgalo local. Si el único cliente es otro programa en el mismo VPS —un script de cron, un bot o un servidor MCP que conecta sus herramientas con el modelo— deje el bind en 127.0.0.1 y haga que ese programa llame a http://127.0.0.1:11434. Nada queda expuesto y no se necesita nada más.
• Acceda mediante un túnel privado. Conecte el VPS a una VPN WireGuard alojada por usted mismo, configure OLLAMA_HOST con la dirección del túnel (por ejemplo 10.8.0.1, no 0.0.0.0) y solo los pares de la VPN podrán conectarse. Internet seguirá sin ver nada en el puerto 11434.
• Coloque un proxy inverso con autenticación delante. Termine la conexión TLS y requiera una contraseña o token en nginx, Traefik o Caddy, y luego haga un proxy hacia 127.0.0.1:11434. Ollama mantiene su bind en localhost; el proxy es lo único que escucha en el puerto público. Esto es igual a colocar un certificado Let's Encrypt en nginx delante de cualquier servicio local.

La opción del proxy inverso es exactamente lo que le ofrece la interfaz de chat a continuación, con un inicio de sesión real integrado.

Añadir una interfaz de chat con Open WebUI, tras TLS

Open WebUI es una interfaz de chat para alojamiento propio. Ejecútela en Docker y apúntela a Ollama local:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

El flag --network=host es el detalle importante en un VPS Linux. Coloca el contenedor en el namespace de red del host; así, 127.0.0.1 dentro del contenedor es el loopback del host y el contenedor alcanza a Ollama en 127.0.0.1:11434 sin que Ollama escuche en otra interfaz. La receta de bridge-network que verá en otros sitios — --add-host=host.docker.internal:host-gateway con OLLAMA_BASE_URL=http://host.docker.internal:11434 — no funciona aquí: ese nombre resuelve a la puerta de enlace del bridge de Docker, y un servicio vinculado a 127.0.0.1 en el host no es alcanzable a través del bridge. Por tanto, Open WebUI fallará al no poder conectar con Ollama.

La desventaja de usar host networking es que Open WebUI ahora escucha en el puerto 8080 del host en todas las interfaces; cualquier mapeo de -p se descarta y Docker imprimirá un aviso al respecto. Por ello, cierre 8080 tanto en el firewall del host como en el del proveedor y deje que el proxy inverso TLS sea el único acceso público. En la primera visita, Open WebUI le pedirá crear una cuenta de administrador; esa cuenta es su capa de autenticación, así que elija una contraseña segura.

Para abrir el chat desde su laptop mediante HTTPS, coloque un proxy inverso TLS delante de 127.0.0.1:8080. Si ya gestiona varias aplicaciones Docker en el servidor, Traefik con TLS automático para múltiples apps es la opción más limpia: un bloque de labels emite el certificado y redirige chat.example.com a Open WebUI. La regla de la sección de seguridad se mantiene: el proxy gestiona el puerto público y el inicio de sesión, mientras Ollama permanece en localhost y el 8080 de Open WebUI permanece protegido por el firewall.

Use el endpoint compatible con OpenAI desde su código

Ollama utiliza un subconjunto de la API de chat de OpenAI en /v1, por lo que la mayoría de las librerías cliente de OpenAI funcionan tras cambiar dos parámetros: la URL base y una clave temporal.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

La api_key es requerida por la librería cliente pero es ignorada por Ollama, por lo que cualquier cadena de texto es válida. model debe ser un nombre que ya haya descargado; un nombre desconocido devuelve model "x" not found, try pulling it first. Una llamada curl simple sigue la misma lógica:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

Este es también el método para integrar el modelo en herramientas de agentes y editores. Si ya desarrolla en el servidor, un modelo local puede respaldar scripts y plugins junto a Claude Code ejecutándose en el VPS dentro de tmux, manteniendo el trabajo de redacción privado y económico fuera de una API de pago, mientras que el razonamiento complejo se mantiene en un modelo alojado.

Modos de fallo, con las cadenas exactas que verá

El proceso se interrumpe con "Killed" durante la generación. Inicia un modelo grande y la terminal imprime Killed, o el log del servidor muestra llama runner process has terminated: signal: killed. El OOM killer de Linux detuvo el proceso porque el modelo requiere más RAM de la disponible en el equipo. Confirme la causa con sudo dmesg | grep -i oom, donde verá una línea como Out of memory: Killed process ... (ollama). La solución es usar un modelo más pequeño o con mayor cuantización — llama3.2:3b en lugar de un 13B — o añadir swap para que una carga que desborda la RAM física sobreviva lentamente en lugar de fallar. El swap convierte un error inmediato en una respuesta lenta; no hace que un modelo de 70B sea práctico en 4 GB.

"Error: model requires more system memory". Ollama se niega a iniciar el modelo e imprime Error: model requires more system memory (X GiB) than is available (Y GiB). Esta es la versión controlada del error anterior: Ollama calculó el uso de memoria y se detuvo antes de que el OOM killer lo hiciera. Incluso le proporciona los dos valores numéricos. Elija un modelo cuyos requisitos sean menores a su RAM libre (verifique con free -h), reduzca la longitud del contexto o use un VPS más grande. Ningún flag permite que el modelo quepa; la memoria es un límite físico.

El primer token tarda demasiado, luego funciona bien. Un modelo en frío no imprime nada durante cinco a treinta segundos y luego transmite normalmente. Esa pausa es la carga de los pesos desde el disco a la RAM por primera vez; el almacenamiento lento empeora esto. Una vez cargado, el modelo permanece en memoria durante OLLAMA_KEEP_ALIVE, por lo que el segundo prompt responde al instante. Aumente ese valor si las pausas le molestan y use ollama ps para verificar si un modelo está cargado actualmente.

Todo es simplemente lento. Diez tokens por segundo o menos, sin ningún error. Eso es inferencia por CPU operando normalmente. ollama ps muestra 100% CPU, lo que significa que no hay GPU. Esto no es un error y ninguna configuración lo soluciona, ya que el límite es el ancho de banda de la memoria, no una mala configuración. Use un modelo más pequeño, acepte la velocidad o use una instancia con GPU; mida su tasa real con --verbose antes de decidir que algo falla.

Connection refused desde otra máquina. Desde su laptop recibe curl: (7) Failed to connect to <ip> port 11434: Connection refused. Esto funciona según lo diseñado: Ollama solo se vincula a localhost. No intente "solucionarlo" vinculando 0.0.0.0, lo cual es precisamente el error de exposición mencionado antes. Acceda al modelo mediante la VPN o a través de un proxy con autenticación.

Expuso el puerto 11434 a internet. Si configuró OLLAMA_HOST=0.0.0.0, abrió el firewall y ahora ve descargas de modelos que usted no inició o la CPU al 100% por clientes desconocidos, ha sido detectado y utilizado. Este es el error principal, no un caso aislado. Vincule de nuevo a 127.0.0.1 o a la dirección de la VPN, cierre el puerto 11434 en el firewall y coloque autenticación delante. Asuma que cualquier entidad que haya podido alcanzar esa dirección mientras estaba abierta realizó consultas.

Backups y actualizaciones

La pérdida de datos es mínima. Los modelos se pueden volver a descargar, por lo que solo es necesario respaldar el volumen de datos de Open WebUI (cuentas, historial de chat, configuraciones) y cualquier archivo de configuración systemd que haya creado. Respalde el volumen usando un contenedor temporal:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

Actualice Ollama ejecutando nuevamente el script de instalación; actualice Open WebUI con docker pull ghcr.io/open-webui/open-webui:main y luego recree el contenedor. No fije versiones a largo plazo: tanto la calidad de los modelos como el entorno de ejecución cambian rápidamente. Lea las notas de la versión y realice nuevas pruebas de rendimiento en su propio equipo en lugar de confiar en los resultados del trimestre anterior.

FAQ

¿Puedo ejecutar un LLM en un VPS que solo tiene CPU?

Sí, con limitaciones. Los modelos cuantizados pequeños en el rango de 3B a 8B funcionan en CPU y son útiles para redactar, resumir y clasificar, aunque de forma lenta, con una velocidad de un solo dígito o poco más de diez tokens por segundo en una vCPU compartida. Cualquier modelo de 13B en adelante es extremadamente lento o no cabrá en la RAM. Para obtener velocidad real o usar modelos más grandes, necesita una instancia con GPU.

¿Cuánta RAM necesita cada modelo?

Una regla aproximada para los modelos cuantizados predeterminados de 4 bits es: unos 0.5 GB de RAM por cada mil millones de parámetros para los pesos, más aproximadamente 1 GB de sobrecarga y un poco más para el contexto. Por tanto, un modelo de 3B requiere unos 4 GB libres, un modelo de 7-8B unos 8 GB, y un modelo de 14B unos 16 GB. Verifique su margen disponible con free -h y deje espacio para el sistema operativo y otros procesos en el servidor.

¿La API de Ollama está autenticada?

No. Ollama no tiene autenticación integrada, clave de API ni límite de tasa (rate limit); cualquier usuario que pueda alcanzar el puerto 11434 tiene control total. Por este motivo, Ollama se vincula a 127.0.0.1 por defecto y no debe exponer el puerto 11434 en 0.0.0.0 a internet. Acceda de forma local, mediante una VPN privada o a través de un reverse proxy que añada un inicio de sesión.

¿Cómo añado una interfaz de chat web?

Ejecute Open WebUI en Docker con --network=host para que comparta el loopback del host y acceda a Ollama en http://127.0.0.1:11434. Luego, coloque un reverse proxy con TLS delante de su puerto 8080 para acceder desde su portátil. Mantenga el puerto 8080 cerrado en el firewall para que el proxy sea el único punto de acceso público. La cuenta de administrador de Open WebUI gestiona el inicio de sesión y la contraseña se establece en el primer inicio.

¿Cómo lo llamo desde mi propia aplicación?

Utilice el endpoint compatible con OpenAI en http://127.0.0.1:11434/v1. Configure cualquier SDK de OpenAI con esa URL base, envíe cualquier cadena como clave de API (ya que se ignora) y establezca model con un nombre de modelo que ya haya descargado. El código de OpenAI existente suele funcionar sin cambios, excepto por la URL base y la clave.