Auto-alojar Ollama en un servidor LLM y tomar control sobre la censura de IA

Palabras clave

Antes de comenzar la configuración, aquí están los términos más probables que confundan a los lectores en esta guía. Este glosario rápido mantiene clara la terminología de Linux, GPU y modelos locales desde el principio.

Por qué vale la pena auto-alojar un LLM

Si ya has hecho la parte difícil — rentado un servidor GPU, instalado Ubuntu, aprendido a moverte por SSH, y mantenido tus propios servicios en funcionamiento — se vuelve frustrante rápidamente cuando una IA alojada aún controla la última milla. Puede rechazar una solicitud perfectamente ordinaria, enterrar la respuesta bajo descargos de responsabilidad, cambiar el estilo de respuesta sin previo aviso, y mantener cada prompt fluyendo a través de los límites de otra persona. Para muchos usuarios técnicos, esa es la verdadera frustración: no solo lo que dice el modelo, sino quién controla la capa de servicio cuando lo dice.

Esta guía trata sobre arreglarlo con modelos abiertos y locales, no sobre trucos para eludir APIs propietarias. Auto-alojarás Ollama en un servidor GPU Ubuntu, ejecutarás inferencia localmente, verificarás que la ruta GPU es real, y verás qué cambia cuando eliges una familia de modelos diferente. Una idea errónea que aclarar temprano: auto-alojado no significa automáticamente sin restricciones. Significa que controlas mucho más de la pila — y dejas de depender de una ruta de servicio controlada por un proveedor — pero el modelo que ejecutes puede seguir llevando su propio comportamiento de alineación.

📝 Nota: Los comandos en esta guía están validados contra la documentación actual de Ollama, pero los resultados de terminal mostrados a continuación son ejemplos representativos en lugar de capturas de referencia en vivo. Úsalos como un patrón de éxito, no como una afirmación de rendimiento.

Al final, tendrás un servicio Ollama funcionando en Ubuntu, una API local verificada en 127.0.0.1:11434, prueba de que la inferencia respaldada por GPU está sucediendo realmente, y una comparación fundamentada entre un modelo alineado convencional y una alternativa menos restringida. Este tutorial está escrito para lectores que se sienten cómodos con SSH, Ubuntu, sudo, y systemd, pero que no necesitan experiencia previa con Ollama.

El Servidor GPU Ubuntu Exacto Utilizado en Esta Guía

Este tutorial se basa en una máquina Ubuntu real con una sola GPU, porque los consejos vagos de “debería funcionar en la mayoría de servidores” son la forma en que las guías de auto-alojamiento se vuelven engañosas. El servidor de referencia aquí es la clase exacta de host utilizado para esta guía: el tipo de máquina que una persona avanzada, un laboratorio o un pequeño equipo alquilaría cuando quiere inferencia local privada sin pasar directamente a un rack de aceleradores empresariales. Aún así, discutirá el comportamiento multi-GPU más adelante, porque Ollama cambia una vez que un modelo supera una tarjeta, pero trate esa parte como contexto orientado al futuro en lugar de prueba de este servidor exacto.

Servidor GPU — Ryzen 9 3950X + RTX 4070 Ti Super

En la práctica, esta es una configuración muy sólida para modelos de clase 8B cotidianos y sigue siendo útil para trabajos locales más grandes hasta el punto en que 16GB de VRAM se convierte en la verdadera limitación. Un modelo como llama3.1:8b con aproximadamente 4.9GB cabe fácilmente en esta tarjeta. Un modelo como gpt-oss:20b con aproximadamente 14GB es el tipo de prueba de GPU única de nivel superior que aún tiene sentido aquí. Un modelo como qwen3:30b con aproximadamente 19GB es mejor tratarlo como un punto de referencia para lo que cambia en un host más grande o dual-GPU que como un ajuste limpio para esta máquina exacta.

Esa distinción importa porque el punto de este artículo no es exprimir el número más grande posible en un titular. Es mostrar cómo se ve un servidor LLM auto-alojado sensato cuando desea privacidad, control local y suficiente memoria GPU para ejecutar modelos útiles sin compromiso constante. Esta clase de hardware es donde la inferencia auto-alojada se vuelve realista, no teórica.

También explica algunas opciones que verá más adelante: mistral se usa primero porque proporciona una prueba rápida y sin fricción de que la pila funciona, mientras que la comparación de comportamiento se mantiene en la clase 8B donde esta máquina es cómoda. qwen3:30b aún aparece más adelante, pero como un ejemplo teórico del tipo de modelo que puede desencadenar la colocación multi-GPU en un host más grande en lugar de como una prueba en vivo de este servidor. Con las expectativas establecidas, el siguiente paso es validar el host antes de que Ollama lo toque.

Ejecuta Estas Verificaciones Previas a la Instalación Antes de Tocar Ollama

Comienza con nvidia-smi. Si este comando falta o falla, detente ahí y corrige el controlador NVIDIA primero. No instales Ollama aún, porque una pila NVIDIA rota hará que cada síntoma posterior parezca un fallo de aplicación cuando en realidad es un fallo de plataforma.

Ejecuta primero la verificación de GPU:

nvidia-smi

❗Si Ubuntu dice que nvidia-smi falta, no asumas que el servidor no tiene GPU. Un modo de fallo común en servidores Ubuntu alquilados es que la tarjeta está presente pero aún vinculada a nouveau en lugar del controlador NVIDIA. Consulta primero la sección “Corregir Problema del Controlador Nvidia en Ubuntu“.

Un resultado saludable en esta clase de servidor debería verse aproximadamente así:

Una vez que nvidia-smi funciona y la GPU es visible, continúa con las verificaciones a continuación.

Lo que quieres confirmar es simple: la GPU instalada es visible, reporta aproximadamente 16GB de VRAM en este host, y el controlador está cargado correctamente. Si estás en un servidor multi-GPU, el mismo comando debería listar cada tarjeta.

nvidia-smi -L

❗ Importante: La documentación actual de soporte de GPU de Ollama utiliza controlador NVIDIA 531+ como el piso real para inferencia NVIDIA soportada. Trata 531+ como el requisito para esta guía, incluso si has visto notas comunitarias antiguas citando versiones más bajas.

Ahora confirma que el host es realmente el entorno Ubuntu que esta guía asume:

lsb_release -a

Finalmente, verifica el espacio en disco libre antes de comenzar a descargar modelos. La instalación en sí es pequeña; los modelos no lo son. Una vez que vayas más allá de pruebas pequeñas, una biblioteca de 20B-30B puede consumir decenas de gigabytes rápidamente, así que 100GB+ libres es la mentalidad correcta antes de trabajo serio con modelos locales.

df -h /

Si estas verificaciones pasan, has aclarado las incógnitas principales de infraestructura: las GPUs están presentes, la línea base del controlador es sensata, Ubuntu está confirmado, y el disco tiene espacio para descargas de modelos reales. Ese es el punto donde instalar Ollama se convierte en un siguiente paso limpio en lugar de una adivinanza.

Corregir Problema del Controlador Nvidia en Ubuntu

Sigue los pasos a continuación para corregir problemas con el comando “nvidia-smi”.

lspci -nnk | grep -A3 -Ei 'VGA|3D|NVIDIA'

Si esa salida muestra una tarjeta NVIDIA y una línea como Kernel driver in use: nouveau, instala el paquete de controlador Ubuntu recomendado en lugar de instalar solo nvidia-utils.

Instala el paquete ubuntu-drivers-common (necesario para la gestión de controladores) y los encabezados del kernel para tu kernel actualmente en ejecución.

apt update
apt install -y ubuntu-drivers-common linux-headers-$(uname -r)

Escanea tu sistema y enumera los controladores propietarios disponibles (por ejemplo, controladores GPU NVIDIA) que se pueden instalar.

ubuntu-drivers devices

Luego instala el paquete de controlador recomendado. En nuestro caso fue: nvidia-driver-595-open:

apt install -y nvidia-driver-595-open
reboot

Después del reinicio, vuelve a ejecutar:

nvidia-smi
nvidia-smi -L

Instalar Ollama y Confirmar que el Servicio Está Saludable

La ruta de Ubuntu compatible es el instalador oficial de Ollama, no un flujo de tarball personalizado ni un desvío de Docker. Eso importa porque esta guía se trata de obtener un servicio local confiable con valores predeterminados predecibles, integración systemd y comportamiento de propiedad sensato en Linux.

Ejecuta el instalador exactamente como se documenta:

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

En un sistema saludable, el script instala el binario, crea el usuario del servicio ollama, agrega las membresías de grupo correctas cuando están disponibles, escribe la unidad systemd e inicia el servicio vinculado a 127.0.0.1:11434.

Una vez que el script finaliza, valida el servicio en lugar de asumir el éxito:

sudo systemctl status ollama --no-pager

Estás buscando tres cosas aquí: el archivo de unidad está presente, el servicio está habilitado para el arranque, y Active: active (running) confirma que el servidor realmente está funcionando.

Primero, establece la cuenta de usuario del servicio Linux de manera concreta, y solo después piensa en cómo y dónde se manejará el almacenamiento del modelo.

getent passwd ollama

Esa única línea explica mucho del comportamiento futuro. Los modelos en Linux viven bajo la propiedad del servicio, y si luego los mueves a otro disco sin corregir los permisos para el usuario ollama, creas tu propio daño.

Una verificación más cierra el bucle en el enlace predeterminado:

ss -tlnp | grep 11434

⚠️ Advertencia: Ollama no requiere autenticación en la API local de forma predeterminada. Eso está bien cuando está vinculado a 127.0.0.1, pero no es seguro exponer el puerto 11434 directamente a Internet como si fuera un servicio público endurecido.

Si el servicio no se inicia correctamente, ve a los registros primero en lugar de reinstalar ciegamente:

journalctl -u ollama -n 100 --no-pager

Esa es la forma más rápida de detectar problemas de permisos, errores de inicio, problemas de detección de controladores o problemas de enlace. Una vez que el servicio está saludable en localhost, lo siguiente que debes entender es cómo se comporta la colocación de GPU en tiempo de ejecución.

Cómo Ollama Realmente Usa Una o Múltiples GPUs

Aunque el servidor utilizado para esta guía tiene una GPU, el comportamiento de múltiples GPUs sigue siendo importante entender porque muchos usuarios pueden tener máquinas más grandes o pueden expandirse más adelante. Mucha de la confusión sobre dos GPUs comienza con la expectativa equivocada: “Tengo dos tarjetas, así que ambas deberían estar activas todo el tiempo.” Así no es como funciona Ollama. La regla práctica es mucho más simple: si un modelo cabe en una GPU, Ollama generalmente lo mantendrá en una GPU. Solo se distribuye entre múltiples GPUs cuando el modelo no cabe cómodamente en una sola tarjeta.

Usa estas dos verificaciones juntas siempre que quieras ver el rendimiento de la GPU:

ollama ps

watch -n 1 nvidia-smi

ollama ps te dice cómo se está procesando el modelo cargado. 100% GPU significa que el modelo reside completamente en la memoria GPU. 100% CPU significa que la aceleración GPU no se está utilizando. Un estado mixto te dice que parte de la carga de trabajo o residencia se derramó fuera de la ruta GPU. watch -n 1 nvidia-smi complementa eso mostrando el uso de VRAM en tiempo real por tarjeta mientras el modelo está cargado.

La forma más rápida de mantener esos roles claros es esta:

📝 Nota: CUDA_VISIBLE_DEVICES es un control de visibilidad, no un interruptor “usa ambas GPUs”. Si alguna vez restringes el acceso a GPU, prefiere los UUIDs de nvidia-smi -L sobre IDs numéricos porque el orden de GPU puede variar entre entornos y reinicios.

Ejecuta Tu Primer Modelo Local y Verifica la Inferencia GPU

En este punto, no necesitas un modelo gigante para probar que el servidor funciona. Necesitas un éxito rápido y honesto. mistral es una buena primera descarga porque es pequeño, rápido de descargar y fácil de cargar, aunque llama3.1:8b será la línea de base posterior para la comparación de comportamiento.

Comienza descargando el modelo:

ollama pull mistral

Ahora ejecuta un pequeño prompt a través de él para que la máquina haga algo útil, no solo administrativo. La respuesta podría tomar algunos segundos.

ollama run mistral "In one sentence, explain why people self-host LLMs."

Para probar que esta es inferencia respaldada por GPU en lugar de un fallback de CPU, verifica el estado de ejecución:

ollama ps

Y para ver qué ya está en disco, lista el inventario local:

ollama list

mistral es la prueba correcta al principio porque te da una respuesta rápida sin convertir la validación de configuración en una larga espera. Más tarde, llama3.1:8b se vuelve más útil porque es una línea de base alineada más fuerte para comparar el comportamiento del modelo.

Finalmente, verifica dónde la instalación de Linux está almacenando modelos:

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

Esa ruta — /usr/share/ollama/.ollama/models — es el almacén de modelos estándar de Linux documentado por Ollama.

Una vez que veas una respuesta exitosa, 100% GPU en ollama ps, y el uso de disco aumentando en la ubicación esperada, tendrás la primera prueba significativa de que la pila local funciona.

Demuestra que es un servidor, no solo un envoltorio CLI

Un símbolo del sistema de línea de comandos es agradable, pero la razón para auto-alojar Ollama no es solo chatear dentro de una terminal. Es ejecutar un servidor de inferencia local que otras herramientas, scripts y aplicaciones puedan llamar sin enviar solicitudes a través del límite de API de otra persona. La prueba más rápida es una solicitud HTTP limpia al endpoint nativo de Ollama.

Envía una solicitud de generación local con streaming deshabilitado para que la primera respuesta sea fácil de inspeccionar:

curl http://localhost:11434/api/generate -d '{
"model": "mistral",
"prompt": "Say hello from a self-hosted Ollama server in one sentence.",
"stream": false
}'

Una respuesta exitosa debe volver como JSON y verse aproximadamente así:

{
  "model": "mistral",
  "created_at": "2026-05-13T12:45:12.000000Z",
  "response": "Hello from a self-hosted Ollama server running locally on Ubuntu.",
  "done": true,
  "done_reason": "stop",
  "total_duration": 812345678,
  "load_duration": 12345678,
  "prompt_eval_count": 14,
  "eval_count": 12
}

La lista de verificación de éxito es directa: la solicitud HTTP funciona localmente, JSON válido vuelve, done: true está presente, y la respuesta del modelo está en response. Ese es el punto donde Ollama deja de ser “un CLI que descarga modelos” y se convierte en infraestructura que realmente puedes integrar en herramientas locales y automatización.

Si deseas compatibilidad con software que espera una forma de solicitud compatible con OpenAI, Ollama también expone endpoints /v1 localmente:

curl -X POST http://localhost:11434/v1/chat/completions
-H "Content-Type: application/json"
-d '{
"model": "mistral",
"messages": [
{"role": "user", "content": "Say this is a test."}
]
}'

📝 Nota: Esa etiqueta “compatible con OpenAI” es fácil de malinterpretar. No significa que estés hablando con OpenAI, y no cambia el hecho de que el servidor sigue siendo local. Solo significa que la forma de la solicitud es lo suficientemente familiar para herramientas y SDKs construidos alrededor del patrón de API de OpenAI. La URL base sigue siendo http://localhost:11434/v1/, y cualquier clave API de marcador de posición que algunas bibliotecas de cliente insistan en puede ignorarse para el uso local de Ollama.

De dónde vienen realmente las restricciones del modelo

Esta es la parte que normalmente se aplana en una única idea vaga de “censura”, pero técnicamente hay tres capas diferentes involucradas: la capa de servicio del proveedor, la alineación del modelo y el ajuste de instrucciones, y el comportamiento de solicitud/tiempo de ejecución que controlas tú mismo. El auto-alojamiento cambia algunas de esas capas dramáticamente. No las borra todas.

Una forma simple de visualizarlo es esta:

Cloud API request:
You -> Vendor API gateway -> Vendor moderation / policy layer -> Model -> Response

Self-hosted Ollama request:
You -> Local Ollama server on 127.0.0.1 -> Model -> Response

Resultados:
– La capa de servicio controlada por el proveedor desaparece de la ruta local
– El límite de red local y registro se convierte en tuyo
– El propio entrenamiento y alineación del modelo siguen siendo parte del modelo

Una vez que separas las capas, los pasos de configuración anteriores se vuelven mucho más significativos:

Puedes pensarlo como una producción teatral. El auto-alojamiento cambia el escenario, la iluminación, los micrófonos y las notas del director. No reentrena al actor. Si un modelo fue ajustado para responder con cautela, dudar a menudo o rechazar ciertos tipos de enmarque, ejecutarlo localmente no deshará mágicamente ese entrenamiento.

Lo que tu configuración actual ya ha probado es más estrecho, pero aún importante: controlas el proceso del servidor, controlas el límite de la API, y ya no estás enrutando solicitudes locales a través de una capa de moderación propiedad del proveedor. Ese es un cambio real en privacidad y control. Lo que no ha probado es que cada modelo local se comportará de la misma manera o que cada rechazo en el futuro fue causado por un proveedor en la nube.

Ahí es donde entra la elección del modelo. Si quieres el efecto práctico de menos renuncias, respuestas más directas o comportamiento menos propenso al rechazo, no llegas allí diciendo “auto-alojado” más fuerte. Llegas allí eligiendo una familia de modelos o ajuste fino diferente — y entendiendo los compromisos que conlleva.

Elige un Modelo Local Menos Restringido

Si deseas una prueba justa, compara modelos que ocupen aproximadamente la misma clase de tamaño. Por eso esta guía utiliza llama3.1:8b como línea base alineada convencional y dolphin3 como modelo de comparación menos restringido. Ambos tienen alrededor de 4.9GB, lo que facilita la interpretación de la diferencia de comportamiento sin cambiar también demasiado drásticamente la huella de hardware.

Descarga los modelos de comparación localmente:

ollama pull llama3.1:8b

ollama pull dolphin3

# Optional older reference model
ollama pull dolphin-mistral

Aquí está el marco práctico para los tres nombres que es más probable que veas en esta parte del ecosistema Ollama:

⚠️ Advertencia: Un ajuste fino diferente no es “el mismo modelo con la censura eliminada”. Puede cambiar la directividad, la densidad de descargos de responsabilidad y la disposición a seguir el marco del usuario, pero también puede cambiar el tono, la precisión, la consistencia y la personalidad general.

Rendimiento de GPU

Antes de ejecutar los modelos deseados, primero es esencial comprender las posibilidades y limitaciones del hardware involucrado. Entonces, hay dos cosas que probar conceptualmente: primero, cómo se ve el comportamiento limpio de una sola GPU en el hardware real utilizado para esta guía; segundo, qué cambia si luego ejecuta la misma pila en un host de dos GPU. Ambas importan, pero solo la primera es una prueba en vivo de esta máquina exacta.

En este servidor, la mejor prueba de tiempo de ejecución de gama alta es gpt-oss:20b. Es lo suficientemente grande para ser interesante mientras sigue teniendo sentido en una tarjeta de 16GB.

ollama pull gpt-oss:20b

ollama stop mistral

ollama run gpt-oss:20b "Explain in one paragraph why a 14GB model is a realistic upper-end single-GPU test on a 16GB card."

Después de que se cargue el modelo, confirme el estado de tiempo de ejecución:

ollama ps

Esa es la prueba práctica que desea en esta máquina. Muestra que los modelos más pequeños caben fácilmente y que un modelo local más grande pero aún realista puede llevar una tarjeta de 16GB cerca de su envolvente utilizable sin necesidad de múltiples GPU.

Si luego ejecuta Ollama en un host de dos GPU, un modelo como qwen3:30b se convierte en el tipo de carga de trabajo que puede demostrar la colocación de múltiples GPU. El flujo de trabajo es el mismo — observe nvidia-smi, ejecute el modelo, inspeccione ollama ps — pero el punto no es hacer que ambas tarjetas se iluminen por su propio bien. El punto es confirmar que Ollama solo distribuye un modelo entre múltiples GPU cuando el modelo ya no cabe limpiamente en una.

Consideraciones sobre Evasión de Censura

Para la comparación de comportamiento, mantén las condiciones controladas para que estés probando el modelo más que la aleatoriedad. Usa el mismo endpoint, el mismo prompt, stream: false, una temperatura baja y una semilla fija:

curl http://localhost:11434/api/generate -d '{
"model": "llama3.1:8b",
"prompt": "<comparison prompt>",
"stream": false,
"options": {
"temperature": 0.2,
"seed": 42
}
}'

Luego repite la misma solicitud con “model”: “dolphin3”. La semilla fija no elimina toda la varianza, pero reduce suficiente aleatoriedad para que las diferencias de tono y cumplimiento sean más fáciles de ver.

1. Un primer prompt seguro es: “¿Significa el auto-alojamiento de un LLM que el usuario controla completamente el comportamiento del modelo? Responde en 4 puntos. Sé directo y omite preámbulos.” Una respuesta representativa de llama3.1:8b tiende a sonar así:

   - Self-hosting gives you more control over deployment, privacy, and availability.
   - It does not automatically remove the model's built-in alignment behavior.
   - The model may still refuse or soften some responses depending on its training.
   - Full control comes from combining self-hosting with careful model selection and configuration.

   Una respuesta representativa de dolphin3 al mismo prompt a menudo suena más simplificada:

   - You control the machine, the network boundary, and the serving layer.
   - You do not erase the model's training history just by running it locally.
   - Vendor-side policy can disappear, but model-side alignment can still remain.
   - Real control comes from choosing a model whose behavior matches your use case.

2. Un segundo prompt útil es: “Escribe un argumento agudo de cinco oraciones sobre por qué un equipo sensible a la privacidad podría rechazar IA gestionada por proveedores. Sin introducción y sin conclusión.” llama3.1:8b generalmente cumple, pero con un tono corporativo más medido. dolphin3 sigue más fácilmente la agudeza solicitada. Ese es el tipo de diferencia que buscas aquí: no una salida dramática sin ley, sino cambios en la directividad, el encuadre y la densidad de descargos de responsabilidad.
3. La tercera categoría de prompt para validación puede ser la siguiente: pide cinco razones factuales por las que un escritor podría preferir un modelo local para trabajo creativo inusual, de nicho o no convencional. En la práctica, ambos modelos responden, pero dolphin3 tiende a mantenerse más cerca del tono sin moralización solicitado y respuestas directas.

El patrón se ve así:

Y así, aquí están las conclusiones honestas:

1. La elección del modelo local cambia significativamente el comportamiento de salida.
2. Los diferentes modelos varían en directividad y densidad de descargos de responsabilidad.
3. El auto-alojamiento elimina una capa de servicio controlada por el proveedor.

Ahora Controlas la Stack, No Solo el Prompt

La frustración desde el principio de esta guía nunca fue solo sobre un modelo rechazando una solicitud. Fue sobre el hecho de que la capa de servicio, capa de política y límite de privacidad vivían en otro lugar. Después de esta configuración, esa parte ha cambiado. Tu servidor de inferencia se ejecuta en tu máquina Ubuntu, el límite de API local es tuyo, el menú de modelos es tuyo, y tus valores predeterminados de prompt/runtime son tuyos para ajustar.

Lo que aún requiere criterio es la parte que ningún instalador puede resolver por ti: elegir modelos que coincidan con tu caso de uso, dirigirlos con valores predeterminados sensatos, y exponer acceso de forma segura si vas más allá de localhost. Esa es la verdadera forma de control del auto-alojamiento. No libertad mágica de toda restricción, sino propiedad de la stack que decide cómo, dónde, y con qué modelo ocurre la inferencia. Si quieres el mejor próximo paso, comienza creando un Modelfile personalizado — o poniendo acceso remoto seguro frente a la API local cuando estés listo.

Qué hacer después de la configuración base

En este punto, la promesa central se cumple. El servidor funciona, la API funciona, la ruta GPU es real, y las diferencias de comportamiento del modelo ya no son abstractas. El siguiente paso no es “instalar más cosas ciegamente”. Es ajustar las partes de la pila que ahora te pertenecen.

Personalizar el comportamiento del modelo con un Modelfile

Un Modelfile es la forma más limpia de cambiar los valores predeterminados de solicitud local sin tocar los pesos del modelo. Comienza inspeccionando la definición actual del modelo para entender qué estás ampliando:

ollama show --modelfile dolphin3

Luego crea una variación local simple:

FROM dolphin3

SYSTEM You are a direct, factual assistant for a self-hosted Ubuntu LLM server. 
Prefer short, practical answers and avoid padded disclaimers.

PARAMETER temperature 0.2
PARAMETER num_ctx 8192

Constrúyelo como un nuevo nombre de modelo y pruébalo:

ollama create dolphin3-local -f ./Modelfile
ollama run dolphin3-local "Summarize what changed in this custom model in 3 bullets."

❗ Importante: Un Modelfile cambia el comportamiento de solicitud y tiempo de ejecución, no el historial de entrenamiento del modelo. Puede dirigir el tono y los valores predeterminados, pero no reentrena el modelo subyacente.

Asegurar la configuración

El enlace a localhost es un buen valor predeterminado, pero no es el final de la historia de seguridad. Vuelve a verificar la dirección de escucha actual primero:

ss -tlnp | grep 11434

Si el objetivo es mantener Ollama solo local, fija ese comportamiento explícitamente con una anulación de systemd:

sudo systemctl edit ollama

Añade lo siguiente:

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_NO_CLOUD=1"

Luego recarga y reinicia el servicio:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Si necesitas acceso remoto más adelante, no publiques 11434 directamente. En su lugar, coloca un proxy inverso con TLS y autenticación frente a él:

server {
    listen 443 ssl http2;
    server_name llm.example.com;

    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;
    }
}

⚠️ Advertencia: Trata la exposición pública como un proyecto de endurecimiento separado. Ollama por sí solo es un servidor de inferencia local, no una puerta de enlace de API lista para producción con autenticación integrada, limitación de velocidad y valores predeterminados orientados a Internet.

Modelos recomendados para este hardware

Una vez que la instalación base funciona, la mejora de mayor valor es elegir modelos que realmente se ajusten bien a esta máquina en lugar de perseguir el titular más grande. Para el servidor de una sola 4070 Ti SUPER utilizado aquí, el menú práctico se ve así:

Inicio automático y mantenimiento

Después de la parte divertida viene la parte que mantiene un servidor LLM local usable un mes a partir de ahora. Confirma el comportamiento en el tiempo de arranque, mantén el servicio actualizado, observa los registros y sabe cómo descargar modelos grandes cuando necesites la VRAM de vuelta.

sudo systemctl is-enabled ollama

sudo systemctl enable --now ollama

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

journalctl -u ollama -n 100 --no-pager

Para operaciones de modelo día a día, estos son los comandos que usarás más a menudo:

ollama list
ollama ps
ollama stop gpt-oss:20b
sudo du -sh /usr/share/ollama/.ollama/models

Y si el almacenamiento de modelos tiene que moverse a un disco más grande, prepara el directorio para el usuario del servicio antes de redirigir Ollama:

sudo mkdir -p /mnt/ai/ollama-models
sudo chown -R ollama:ollama /mnt/ai/ollama-models

Luego establece OLLAMA_MODELS a través de systemctl edit ollama. Ese detalle de propiedad es lo que evita que una migración de almacenamiento se convierta en un problema de permisos.

Referencia de solución de problemas

Cuando algo se rompe, el camino más rápido suele ser hacer coincidir el síntoma con la capa correcta en lugar de intentar bucles de reinstalación aleatorios. Usa esta tabla como el primer paso:

Si solo recuerdas una regla operativa de esta sección, que sea esta: trata Ollama como un servicio real, no como una utilidad CLI desechable. Los registros, la propiedad, las direcciones de enlace y las rutas de almacenamiento importan tanto como la ventana de solicitud.