Aloje un LLM propio en su VPS.
Sin GPU. Sin clave de API. Ningún prompt sale jamás de su máquina.

La versión honesta de esta sección vale más que una entusiasta, porque la forma más rápida de abandonar un modelo autoalojado es ponerlo a hacer justo la tarea en la que peor rinde y concluir que toda la idea era una tontería.

Cabe con holgura. Cualquier cosa cuya salida sea corta y cuyo valor esté en el criterio y no en la prosa. Clasificar un mensaje entre un puñado de categorías. Decidir si un ticket de soporte es urgente. Extraer cinco campos de una factura como JSON. Resumir un hilo en tres frases. Etiquetar un documento. Reescribir la descripción de un producto. Traducir una cadena corta. Detectar si dos registros describen a la misma persona. Tachar nombres de un párrafo antes de que vaya a ningún otro sitio. Cada una de esas tareas consume una entrada larga y produce una salida corta, que es exactamente la asimetría que una CPU maneja bien.

Cabe, con paciencia. Trabajo sin ningún humano esperando la respuesta. Lotes nocturnos, workers de colas, una pasada nocturna sobre los documentos del día, un informe programado. Si nada depende de esperar la respuesta, una tasa de tokens que sería intolerable en una ventana de chat deja de importar por completo — un trabajo que corre durante seis minutos a las tres de la madrugada es sencillamente un trabajo que se hizo.

No cabe. Un asistente interactivo que a la gente realmente le guste usar: a estas velocidades el cursor se arrastra y la experiencia es peor que no tener asistente. Generación de textos largos —escríbeme dos mil palabras— donde toda la salida es la parte lenta. Agentes de programación que iteran sobre un repositorio grande, donde tanto el contexto como el nivel de calidad exigido superan lo que un modelo pequeño puede sostener. Cualquier cosa que necesite un contexto de cien mil tokens, donde solo la caché ya desborda la máquina. Y los modelos de imagen o vídeo, que son una disciplina completamente distinta y sí necesitan de verdad una GPU.

Si su carga de trabajo vive en ese último grupo, la respuesta sensata no es comprar una máquina de CPU más grande — es un híbrido. Mantenga un modelo local para el grueso de las llamadas y enrute el puñado que necesita razonamiento de vanguardia hacia una API alojada en la nube, que es exactamente la forma que describe la guía sobre ejecutar un agente de IA 24/7 para la parte del runtime. Esa guía dejó deliberadamente el modelo en sí fuera de alcance. Esta es la mitad que faltaba.

Refuerce primero la máquina — SSH solo por clave, un firewall que no permita nada que usted no haya pedido, actualizaciones de seguridad desatendidas. La checklist de la primera hora lleva alrededor de una hora, y esta es una máquina que dentro de poco va a guardar cada pregunta que usted le haga.

A continuación instale el runner. Ollama es llama.cpp con un registro de modelos, una API REST y una unidad systemd envolviéndolo todo, y el instalador de una línea configura los tres a la vez:

apt update && apt install -y curl
curl -fsSL https://ollama.com/install.sh | sh

systemctl status ollama --no-pager
ss -ltnp | grep 11434
# → 127.0.0.1:11434 — loopback only. Leave it that way.

Esa última línea es la que hay que leer dos veces. Recién instalado, el servicio escucha en la interfaz de loopback, que es exactamente lo correcto, y el error más habitual de los próximos diez minutos es poner OLLAMA_HOST en 0.0.0.0 porque algo en otra máquina no podía alcanzarlo. El paso 04 explica cómo alcanzarlo correctamente; no hay ninguna versión de esto en la que el puerto 11434 dé directamente a internet.

Merece la pena fijar ahora dos ajustes en vez de descubrirlos más tarde. Los modelos se guardan por defecto bajo /usr/share/ollama y pesan mucho, así que apunte eso a donde tenga sitio. Y el valor por defecto mantiene un modelo residente en RAM durante cinco minutos después de la última petición, lo cual es generoso en una máquina que también hace otras cosas:

systemctl edit ollama

[Service]
Environment="OLLAMA_MODELS=/var/lib/ollama/models"
Environment="OLLAMA_KEEP_ALIVE=30m"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"

systemctl daemon-reload && systemctl restart ollama

Tanto las peticiones en paralelo como tener varios modelos cargados a la vez multiplican el uso de memoria, y en una máquina dimensionada para sostener exactamente un modelo no sobra ni un gigabyte para una segunda copia. Serializar la cola no es una limitación de este hardware; es la única configuración que no se cae.

Esta es la parte de la guía que evita que pase algo malo, así que se dice sin rodeos: la API de Ollama no tiene contraseña, ni token, ni modelo de usuarios, ni sistema de permisos. Cualquier cosa que pueda abrir una conexión TCP al puerto 11434 puede generar texto en su CPU, enumerar los modelos que ha descargado, descargar otros nuevos y borrar los que usa. No hay ningún ajuste que activar, porque no hay ningún mecanismo que activar.

El puerto 11434 se escanea de forma continua, por el motivo obvio: un runner de modelos abierto es cómputo gratuito que pertenece a otra persona. El síntoma no es una alerta. Es una máquina que se siente lenta durante quince días y una gráfica de ancho de banda que no corresponde a nada que usted haya hecho. Mantenga el servicio en loopback, y ponga delante algo que pregunte quién llama.

Si nada fuera de esta máquina necesita el modelo, deténgase aquí — ya ha terminado. Loopback más un firewall es una respuesta completa, y un agente, una plataforma de automatización o una aplicación web que corra en el mismo VPS llega al modelo por 127.0.0.1 sin nada de lo que sigue. Continúe solo si algo en otra máquina tiene que llamarlo.

El proxy, y el token. Genere un token largo y aleatorio, apunte un registro A hacia la máquina, y deje que Caddy se encargue tanto del certificado como de la puerta:

openssl rand -hex 32      # → the bearer token, store it in a password manager
apt install -y caddy

/etc/caddy/Caddyfile

llm.example.com {
    @unauthorised not header Authorization "Bearer PASTE_THE_HEX_TOKEN_HERE"
    respond @unauthorised "unauthorised" 401

    reverse_proxy 127.0.0.1:11434 {
        # Generation is slow by nature — do not let the proxy give up first.
        transport http {
            read_timeout 10m
        }
    }
}

systemctl reload caddy
ufw allow 80,443/tcp
ufw status                # 11434 must appear nowhere

Hay una pequeña elegancia en elegir un token bearer en vez de autenticación básica. Ollama expone una API compatible con OpenAI, todo cliente de OpenAI envía su clave exactamente como esa cabecera, así que el token que acaba de generar se convierte en la clave de API que sus aplicaciones ya saben cómo llevar. Nada necesita una cabecera personalizada, y rotar el acceso es una línea en el Caddyfile y una variable de entorno en quien llama.

Verifíquelo desde una máquina que no sea el servidor. La primera llamada debería ser rechazada y la segunda debería responder:

curl -s -o /dev/null -w '%{http_code}\n' https://llm.example.com/api/tags
# → 401

curl -s https://llm.example.com/api/tags -H "Authorization: Bearer THE_TOKEN" | jq '.models[].name'
# → the list of models you pulled

Si el modelo lo van a llamar agentes en lugar de usted, la cuestión de la exposición merece el tratamiento más completo de la guía sobre alojar un servidor MCP remoto — el mismo razonamiento sobre TLS, tokens y qué debe ser alcanzable desde dónde, aplicado a un servicio que entrega herramientas en lugar de tokens.

Limite el contexto. La longitud de contexto es el dial principal sobre el uso de memoria, y el valor por defecto es más generoso de lo que le conviene a una máquina pequeña. Fíjelo globalmente a lo que realmente necesite su prompt más largo y realista — la mayoría del trabajo de clasificación y extracción va cómodo dentro de cuatro mil tokens — y súbalo por petición en la rara llamada que necesite más:

Environment="OLLAMA_CONTEXT_LENGTH=4096"

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "…a long document…",
  "options": { "num_ctx": 16384 },
  "stream": false
}'

Decida cuánto tiempo permanece el modelo en memoria. Un modelo residente responde de forma instantánea, pero mantiene varios gigabytes secuestrados. En una máquina dedicada a la inferencia, manténgalo cargado para siempre; en una compartida, deje que se descargue al cabo de un rato. El valor también viaja por petición, así que un lote nocturno puede fijar el modelo durante su ejecución y liberarlo al terminar:

OLLAMA_KEEP_ALIVE=-1     # resident until the service restarts
OLLAMA_KEEP_ALIVE=30m    # a sensible default on a shared box
OLLAMA_KEEP_ALIVE=0      # unload immediately after each request

ollama ps                # what is resident right now, and how much it holds

Serialice la cola. Dos peticiones simultáneas contra un modelo no van al doble de rápido; compiten por la misma ruta de memoria saturada y cada una se vuelve más lenta, y si Ollama decide cargar una segunda copia para atenderlas, la máquina se queda sin RAM. En esta clase de hardware, una petición a la vez, con una cola delante, es a la vez la configuración más rápida y la única segura — por eso OLLAMA_NUM_PARALLEL y OLLAMA_MAX_LOADED_MODELS se fijaron en uno allá en el paso 02.

Vigile el disco. Comparar cuatro modelos deja cuatro modelos atrás, y a cinco gigabytes cada uno eso es un disco que se va llenando en silencio mientras nada se queja. Convierta la limpieza en parte de la comparación, no en una tarea para más adelante:

ollama list
du -sh /var/lib/ollama/models
ollama rm mistral:7b qwen2.5:14b

Por último, haga copia de seguridad de lo que no es reproducible. Los pesos del modelo no lo son — un pull los recupera. Lo que merece un repositorio es la configuración, el Caddyfile, el token, los prompts que fue puliendo durante tres semanas y, si construyó uno, el índice vectorial detrás de su recuperación. La guía de copias de seguridad cifradas cubre la mecánica; la lista de qué incluir para esta máquina es corta y merece la pena anotarla.

La gente razona sobre la privacidad de los modelos como si el riesgo estuviera en la salida. No es así. La salida es texto genérico; otras mil personas recibieron algo parecido. El artefacto revelador es la entrada — y un año de entradas es un retrato asombrosamente completo de una organización.

Piense en lo que realmente contiene un registro de peticiones. El contrato que pegó para que se lo resumieran. El correo del cliente que pidió clasificar, con el cliente incluido dentro. La carta médica, la cifra del salario, la carta de dimisión que estaba redactando, el código de un repositorio que no es público. Y luego los metadatos alrededor: qué preguntas, en qué orden, a qué hora, desde qué dirección, a lo largo de cuántos meses. Nadie firma un documento que diga «esta es nuestra estrategia» — pero la secuencia de preguntas es ese documento, ensamblado honestamente, por usted, una llamada cada vez.

Capa uno — lo que guarda el endpoint. Los proveedores serios publican políticas serias, y los buenos de verdad no entrenan con el tráfico de la API de negocio. Eso no es la misma promesa que no retenerlo. Las peticiones normalmente se almacenan durante un periodo para vigilancia de abusos, son accesibles por el personal bajo condiciones definidas, y pueden ser requeridas por un proceso legal — que es exactamente la forma correcta de operar una gran plataforma, y exactamente el sitio equivocado para un texto que usted no le enviaría por correo a un desconocido. Un modelo en su propia máquina no tiene ese registro a menos que usted mismo lo escriba.

Capa dos — la identidad a la que se asocia el registro. La retención por sí sola es solo la mitad de la exposición. La otra mitad es la clave a la que se asocia: una cuenta, el nombre de una empresa, una dirección de facturación, una tarjeta. Esa asociación es lo que convierte «alguien preguntó sobre adquirir a un competidor» en «esta empresa preguntó, ese martes». Quitar el modelo de la ecuación elimina la retención; quitar la identidad de la máquina elimina la asociación. Un VPS abierto sin dirección de correo ni documento de identidad, en una jurisdicción nórdica, pagado en Monero, es la segunda mitad del mismo movimiento.

Capa tres — los registros que usted mismo escribe. Alojar el modelo usted mismo desplaza el riesgo en lugar de eliminarlo, y conviene tener claro dónde acaba cayendo. Es probable que su aplicación registre sus propios prompts. Su proxy inverso registra cada línea de petición. Una sesión de depuración de hace dos meses dejó una salida detallada en el journal. El modelo en sí no guarda nada entre llamadas, pero la maquinaria que lo rodea puede guardarlo todo — así que decida deliberadamente qué se anota, fije una retención sobre ello, y exija a ese registro el mismo estándar que no estaba dispuesto a aceptarle a otro.

Nada de eso convierte un modelo local en una garantía de privacidad por sí solo. Lo convierte en la única arquitectura en la que la garantía depende de usted: el texto se queda en el hardware que alquila, bajo una jurisdicción que eligió, detrás de un token que emitió usted mismo, y no responde ante nada más.