Alojar Ollama en un VPS de forma segura

Qué va a configurar

Un único modelo de lenguaje de pesos abiertos que se ejecuta en un servidor propio, responde mediante una API HTTP y, si lo desea, ofrece una página de chat en el navegador. Ollama descarga el modelo, lo carga en memoria y atiende las peticiones en http://127.0.0.1:11434. La instalación requiere un solo comando. La parte compleja está en otro sitio: elegir un modelo que el VPS pueda mantener realmente en la RAM y no publicar por accidente un servidor de inferencia sin autenticación en toda Internet.

Primero, dos advertencias importantes. Un VPS que sólo usa CPU ejecuta los modelos pequeños con lentitud y la API no incluye autenticación integrada. A continuación se explican ambos problemas en detalle, porque son los principales riesgos de esta configuración.

La comprobación de dimensionamiento, con cifras sencillas

La huella de memoria de un modelo es aproximadamente su tamaño de archivo, más cerca de un gigabyte de sobrecarga de ejecución y algo más para la ventana de contexto. Los modelos predeterminados de Ollama usan cuantización de 4 bits (etiquetada como Q4), que consume aproximadamente medio gigabyte de RAM por cada mil millones de parámetros. Por tanto, el cálculo es sencillo y determina todo. El último término lo establece usted: aumentar num_ctx por encima del valor predeterminado reducido de Ollama proporciona espacio para prompts más largos, pero aumenta la caché KV en la RAM. Defina la longitud de contexto antes de evaluar si un modelo cabe.

Un modelo 3B como llama3.2:3b ocupa aproximadamente 2 GB descargado y necesita alrededor de 4 GB de RAM libre para ejecutarse. Un modelo 7B u 8B como mistral:7b o llama3.1:8b ocupa aproximadamente 5 GB en disco y necesita unos 8 GB de RAM; con 16 GB funcionará con margen. Un modelo 13B o 14B necesita aproximadamente 16 GB. Cualquier modelo del rango de 30B a 70B requiere un equipo con mucha RAM o, en la práctica, una GPU. En un VPS con CPU, no cabrá o responderá tan despacio que resultará inútil.

Ahora, la velocidad, porque esta es la parte que se suele subestimar. La inferencia en CPU está limitada por el ancho de banda de memoria, no por la frecuencia de reloj, y un VPS con vCPU compartida tiene un ancho de banda moderado. Espere entre un dígito y dos dígitos bajos de tokens por segundo: un modelo Q4 de 7-8B puede procesar entre 4 y 10 tokens por segundo, y uno de 3B, entre 10 y 25. Una GPU es aproximadamente un orden de magnitud más rápida. Estas cifras son deliberadamente aproximadas. Lo correcto es medir su propio equipo, como se muestra en el paso de ejecución siguiente. Confíe en sus eval rate, no en una cifra de ningún artículo, incluido este.

La conclusión práctica es la siguiente: los modelos pequeños cuantizados en CPU resultan realmente útiles para redactar, resumir y clasificar si puede aceptar ese ritmo. Para cualquier tarea más grande o rápida, presupueste una instancia con GPU. Si prefiere ver este cálculo aplicado de principio a fin a un modelo concreto, ejecutar Nemotron 3.5 Lightning en un VPS explica qué etiqueta descargar, cuánta RAM necesita realmente y si la ejecución sólo con CPU ofrece un rendimiento suficiente.

Para comparar un modelo concreto con un equipo concreto, estime aquí su huella de memoria:

Instalar Ollama

Hay dos formas limpias de hacerlo. El script oficial es la opción más sencilla en un VPS sin configuración previa:

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

Esto crea un usuario del sistema llamado ollama, instala el binario en /usr/local/bin/ollama y registra un servicio de systemd llamado ollama.service que se inicia durante el arranque y escucha en 127.0.0.1:11434. Confirme que está activo:

systemctl status ollama
ollama --version

Si ya usa 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 la asignación de puertos. Esto enlaza el puerto sólo con localhost. Si escribe -p 11434:11434, lo publica en todas las interfaces. Ese 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 porque dos procesos intentarán usar el mismo puerto.

Descargue y ejecute su 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 muestra un indicador >>>. Escriba una pregunta. El primer token puede tardar varios segundos mientras los pesos se cargan del disco a la RAM. Después, la respuesta se muestra progresivamente. Escriba /bye para salir del chat. Ollama sigue ejecutándose en segundo plano.

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

ollama ps

La columna PROCESSOR muestra la situación real. 100% CPU significa que no se utiliza ninguna GPU. Esa es la causa de la lentitud. Mida la velocidad real con la opción verbose:

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

La línea eval rate que aparece al final indica los tokens por segundo en este hardware. Ese es el valor que debe usar como referencia.

Dónde se almacenan los modelos y cuánto espacio de disco comprar

Instalados por el script y ejecutados como el servicio, los modelos se almacenan en el directorio personal del usuario ollama:

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

Si se ejecutan de forma interactiva con su propio usuario, se almacenan en ~/.ollama/models. En el contenedor se almacenan en el volumen con nombre ollama. Esto es importante porque los pesos cuantizados ocupan espacio rápidamente: un modelo 3B ocupa aproximadamente 2 GB, uno 7-8B ocupa aproximadamente 5 GB y uno 14B ocupa aproximadamente 9 GB. Si descarga cuatro modelos para compararlos, habrá ocupado 20 GB sin darse cuenta. Dimensione el disco para los modelos que vaya a conservar y elimine los demás con ollama rm <model>. Si el mismo VPS ya ejecuta otro servicio con un consumo elevado de espacio, como PhotoPrism o Immich con una biblioteca de fotos, reste primero ese espacio del espacio libre y considere lo que quede como su presupuesto real para modelos.

Ejecutarlo como un servicio bajo su control

El script de instalación ya registró ollama.service, por lo que se reinicia durante el arranque sin que tenga que hacer nada más. La configuración que merece la pena cambiar es cuánto tiempo permanece cargado un modelo y, en algunas configuraciones, la dirección de enlace. Ambos valores se definen en una extensión 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 indica cuánto tiempo permanece un modelo en memoria después de la última solicitud (5 minutos de forma predeterminada). Auméntelo en un equipo al que envía consultas durante todo el día para evitar volver a cargar los pesos cada vez. Establézcalo en 0 en un equipo con poca memoria para liberar la RAM en cuanto termine una solicitud. Si quiere que un modelo permanezca cargado indefinidamente en lugar de durante un intervalo fijo, mantener un modelo de Ollama cargado permanentemente explica el campo keep_alive por solicitud y cómo volver a cargar los pesos después de un reinicio, en lugar de hacerlo con la primera solicitud lenta. systemctl edit vuelve a cargar los archivos de unidad, por lo que debe reiniciar el servicio para aplicar el cambio:

sudo systemctl restart ollama

El aspecto de seguridad más importante

De forma predeterminada, Ollama se enlaza a 127.0.0.1:11434, por lo que sólo los procesos del propio VPS pueden acceder a él. Este valor predeterminado es correcto. Manténgalo.

La API no tiene autenticación. Ninguna. No hay clave de API, inicio de sesión, límite de tasa ni lista de permitidos. Cualquiera que pueda acceder al puerto 11434 puede ejecutar cualquier modelo que haya descargado, descargar modelos nuevos, eliminarlos y mantener la CPU o la GPU al 100 % de carga de forma indefinida. Escáneres como Shodan indexan por miles las instancias de Ollama expuestas, y una instancia expuesta se detecta y se utiliza de forma indebida en cuestión de horas.

Este es el único error que nunca debe cometer: no configure OLLAMA_HOST=0.0.0.0 ni abra 11434 en el firewall. Eso expone un servidor de inferencia sin autenticación a todo Internet. Ninguna configuración hace que un servicio que escucha directamente en 11434 sobre 0.0.0.0 sea seguro, porque Ollama no ofrece ningún mecanismo de autenticación que se pueda configurar; la autenticación simplemente no existe. Esta regla se aplica a este servicio concreto. No prohíbe abrir puertos en todos los casos: un relay RustDesk autohospedado para escritorio remoto debe aceptar tráfico público para funcionar, y lo hace mediante su propia autenticación basada en claves y una lista breve y documentada de puertos. Ollama no ofrece nada de eso.

Hay tres formas seguras de acceder al modelo desde un equipo distinto del propio servidor:

• Mantenerlo local. Si el único cliente es otro programa del mismo VPS, un script de cron, un bot o un servidor MCP que conecte sus herramientas con el modelo, deje el enlace en 127.0.0.1 y haga que ese programa llame a http://127.0.0.1:11434. No se expone nada más y no hace falta ninguna configuración adicional.
• Acceder mediante un túnel privado. Incluya el VPS en una VPN de WireGuard administrada por usted, establezca OLLAMA_HOST en la dirección del túnel (por ejemplo, 10.8.0.1, no 0.0.0.0) y permita conexiones sólo de los pares de la VPN. Internet sigue sin ver nada en 11434.
• Colocar un reverse proxy con autenticación delante. Termine TLS y solicite una contraseña o un token en nginx, Traefik o Caddy. Después, haga proxy hacia 127.0.0.1:11434. Ollama mantiene el enlace a localhost; el proxy es el único proceso que escucha en el puerto público. Es la misma estructura que colocar un certificado de Let's Encrypt en nginx delante de cualquier servicio local.

La opción del reverse proxy es exactamente la que ofrece a continuación la interfaz de chat, con un inicio de sesión real asociado.

Añadir una interfaz de chat con Open WebUI detrás de TLS

Open WebUI es una interfaz de chat autoalojada. Ejecútela en Docker y configúrela para usar la instancia local de Ollama:

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 indicador --network=host es el detalle importante en un VPS Linux. Coloca el contenedor en el espacio de nombres de red del host, por lo que 127.0.0.1 dentro del contenedor es el propio loopback del host y el contenedor accede a Ollama mediante 127.0.0.1:11434 sin que Ollama escuche en ninguna otra interfaz. La receta de red bridge que verá en otra sección, --add-host=host.docker.internal:host-gateway con OLLAMA_BASE_URL=http://host.docker.internal:11434, no funciona aquí: ese nombre se resuelve en la gateway del bridge de Docker, y un servicio enlazado a 127.0.0.1 en el host no es accesible a través del bridge. Por eso Open WebUI se limita a informar de que no puede conectarse a Ollama.

La contrapartida de usar la red del host es que Open WebUI ahora escucha en el puerto 8080 del host en todas las interfaces. Cualquier asignación -p se descarta y Docker muestra una advertencia que lo indica. Por tanto, cierre 8080 tanto en el host como en el firewall del proveedor, y haga que el reverse proxy TLS sea el único punto de acceso público. En la primera visita, Open WebUI le pide que cree 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 portátil mediante HTTPS, coloque un reverse proxy TLS delante de 127.0.0.1:8080. Si ya encamina varias aplicaciones Docker en el servidor, Traefik con TLS automático para varias aplicaciones es la opción más adecuada: un único bloque de etiquetas emite el certificado y encamina chat.example.com a Open WebUI. El mismo encaminamiento basado en etiquetas por aplicación se usará para cualquier otra interfaz web del servidor, ya sea un panel de estado o algo más informal como Halcyon, que presenta una biblioteca de Jellyfin como un videoclub de los años 90, cada una con su propio nombre de host y su propio inicio de sesión. La regla de la sección de seguridad sigue siendo válida: el proxy controla el puerto público y el inicio de sesión, mientras Ollama permanece en localhost y el propio 8080 de Open WebUI permanece protegido por el firewall.

Usa el endpoint compatible con OpenAI desde tu código

Ollama implementa un subconjunto de la API de chat de OpenAI en /v1, por lo que la mayoría de las bibliotecas cliente de OpenAI funcionan después de cambiar dos elementos: la URL base y una clave desechable.

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 obligatoria para la biblioteca cliente, pero Ollama la ignora, por lo que cualquier cadena funciona. model debe ser un nombre que ya hayas descargado; un nombre desconocido devuelve model "x" not found, try pulling it first. Una llamada simple con curl sigue la misma idea:

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"}]}'

Esta es también la forma de integrar el modelo en herramientas de agentes y editores. Si ya desarrollas en el servidor, un modelo local puede respaldar scripts y plugins junto con Claude Code ejecutándose en el VPS dentro de tmux, de modo que el trabajo de redacción privado y de bajo coste no pase por una API de pago, mientras el razonamiento complejo se mantiene en un modelo alojado.

Modos de fallo, con las cadenas exactas que verá

El proceso aparece como "Killed" durante la generación. Inicia un modelo grande y el terminal muestra Killed, o el registro del servidor muestra llama runner process has terminated: signal: killed. El OOM killer de Linux lo detuvo porque el modelo necesitaba más RAM de la disponible en el equipo. Confirma la causa con sudo dmesg | grep -i oom, donde verás una línea similar a Out of memory: Killed process ... (ollama). La solución es usar un modelo más pequeño o con una cuantización más agresiva, llama3.2:3b en lugar de uno de 13B, o añadir swap para que una carga que apenas supera la RAM física termine lentamente en lugar de finalizar con un error. La swap convierte un bloqueo inmediato en una respuesta lenta; no hace viable un modelo de 70B en 4 GB. El proceso termina sin avisar, salvo que estés observando el terminal, por lo que en un equipo al que consultas desde otro lugar, asociar una unidad de OnFailure= a ollama.service que publique en un servidor ntfy que alojes para recibir alertas push te informa en el momento en que termina, en lugar de obligarte a descubrirlo en la siguiente solicitud.

"Error: model requires more system memory". Ollama se niega a iniciar el modelo y muestra Error: model requires more system memory (X GiB) than is available (Y GiB). Es la versión controlada del fallo anterior: Ollama hizo el cálculo y se detuvo en lugar de dejar que lo hiciera el OOM killer. También le proporciona los dos valores. Elija un modelo cuyo requisito sea inferior a la RAM libre; compruébelo con free -h. También puede reducir la longitud del contexto o migrar a un VPS más grande. Ningún flag hace que el modelo quepa. La memoria necesaria es real.

La primera respuesta tarda mucho y después funciona con normalidad. Un modelo en frío no muestra nada durante entre cinco y treinta segundos y después transmite la respuesta con normalidad. Durante esa pausa, los pesos se cargan del disco en la RAM por primera vez, y un almacenamiento lento la prolonga. Una vez cargado, el modelo permanece en memoria durante el tiempo de OLLAMA_KEEP_ALIVE, por lo que el segundo prompt responde al instante. Si esa primera carga supera algún tiempo de espera en la ruta de la llamada, se produce un error en lugar de una respuesta lenta. Determinar qué capa informó de que se superó el plazo de contexto permite saber si el cliente, el proxy o la propia carga agotó su tiempo de espera. Aumente ese valor si las pausas resultan molestas y use ollama ps para comprobar si hay un modelo cargado.

Todo es simplemente lento. Diez tokens por segundo o menos, sin ningún error. Eso es la inferencia en CPU funcionando como corresponde. ollama ps muestra 100% CPU, lo que significa que no hay GPU. No es un error y ningún ajuste lo soluciona, porque el límite es el ancho de banda de memoria, no una configuración incorrecta. Use un modelo más pequeño, acepte la velocidad o migre a una instancia con GPU. Antes de decidir que algo falla, mida la velocidad real con --verbose. Si la espera se debe a la longitud de la respuesta y no a la velocidad de generación, limitar la respuesta con num_predict evita que un modelo propenso a extenderse dedique minutos a generar tokens que nunca iba a leer.

Se rechaza la conexión desde otra máquina. Desde su portátil obtiene curl: (7) Failed to connect to <ip> port 11434: Connection refused. El comportamiento es el previsto: Ollama sólo escucha en localhost. No lo "solucione" haciendo que escuche en 0.0.0.0, porque ese es exactamente el error de exposición descrito arriba. Acceda al modelo mediante la VPN o a través del proxy con autenticación.

Ha expuesto 11434 a Internet. Si configuró OLLAMA_HOST=0.0.0.0, abrió el firewall y ahora observa descargas de modelos que no inició o la CPU al 100% debido a clientes desconocidos, alguien ha encontrado el servicio y lo ha utilizado. Este es el error principal, no un caso excepcional. Vuelva a enlazarlo con 127.0.0.1 o con la dirección de la VPN, cierre 11434 en el firewall y coloque la autenticación delante del servicio. Suponga que cualquier servicio accesible en esa dirección mientras estuvo expuesto fue consultado por terceros.

Copias de seguridad y actualizaciones

Hay poco estado que conservar. Los modelos se pueden volver a descargar, por lo que sólo merece la pena hacer copias de seguridad del volumen de datos de Open WebUI, las cuentas, el historial de chats, la configuración y cualquier archivo drop-in de systemd que haya creado. Haga una copia de seguridad del volumen con un contenedor temporal:

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

Actualice Ollama volviendo a ejecutar el script de instalación. Actualice Open WebUI con docker pull ghcr.io/open-webui/open-webui:main y vuelva a crear el contenedor. No fije versiones a largo plazo: tanto la calidad de los modelos como el runtime cambian rápidamente. Lea las notas de la versión y vuelva a medir el rendimiento en su propio equipo en lugar de confiar en los valores del trimestre anterior.

FAQ

¿Puedo ejecutar realmente un LLM en un VPS que sólo tiene CPU?

Sí, con limitaciones. Los modelos pequeños cuantizados, del rango de 3B a 8B, funcionan con CPU y son realmente útiles para redactar, resumir y clasificar, aunque lentamente: entre un solo dígito y las decenas bajas de tokens por segundo en una vCPU compartida. Cualquier modelo de 13B o más será demasiado lento o no cabrá en la RAM. Para obtener más velocidad o usar modelos más grandes, necesita una instancia con GPU.

¿Cuánta RAM necesita cada modelo?

Como regla aproximada para los modelos cuantizados de 4 bits predeterminados, calcule unos 0.5 GB de RAM por cada mil millones de parámetros para los pesos, más aproximadamente 1 GB de sobrecarga y algo más para el contexto. Por tanto, un modelo de 3B necesita unos 4 GB libres, uno de 7-8B unos 8 GB y uno de 14B unos 16 GB. Compruebe el margen disponible con free -h y deje espacio para el sistema operativo y el resto de servicios del servidor.

¿La API de Ollama tiene autenticación?

No. Ollama no incluye autenticación, clave de API ni límite de tasa. Cualquiera que pueda acceder al puerto 11434 tiene control total sobre ella. Por eso se enlaza a 127.0.0.1 de forma predeterminada y nunca debe exponer 11434 en 0.0.0.0 a Internet. Acceda localmente, 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 web de chat?

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

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

Use el endpoint compatible con OpenAI en http://127.0.0.1:11434/v1. Apunte cualquier SDK de OpenAI a esa URL base, pase cualquier cadena como clave de API porque se ignora y establezca model con el nombre de un modelo que haya descargado. El código existente de OpenAI suele funcionar sin cambios, aparte de la URL base y la clave.