Ollama: cómo correr modelos de IA en tu propio Linux en 2026

Ollama es una herramienta open source que descarga, ejecuta y sirve modelos de lenguaje (LLM) localmente. No necesitas cuenta, no envías datos a la nube, y corre bien tanto en una workstation con GPU como en un servidor modesto solo con CPU. Esta guía te lleva de la instalación a tu primera API local.

¿Por qué Ollama y no solo “ChatGPT”?

Tres razones que importan en 2026:

• Privacidad real: nada sale de tu máquina. Útil si trabajas con código de cliente, datos sensibles o investigación.
• Costo cero por token: una vez descargado el modelo, inferencia es gratis. ChatGPT Pro cuesta 200 USD/mes.
• Sin rate limits: la API local responde tan rápido como tu hardware aguante.

Las contras: la calidad de los modelos pequeños (7B, 14B) sigue por debajo de los flagship de frontera. Para tareas de razonamiento complejo los modelos cloud siguen ganando. Para resúmenes, clasificación, transformaciones de texto, RAG, generación de código boilerplate y chat general: van bien.

Instalación en Linux

Ollama tiene instalador oficial para Linux (script curl | sh) y paquetes para varias distros. El método soportado es:

Este es el instalador oficial de Ollama para Linux: baja y ejecuta un script que crea el usuario, el servicio systemd y deja el binario en /usr/local/bin. Es la ruta soportada por el proyecto y te asegura la última versión estable de manera idempotente.

curl -fsSL descarga el script sin seguir redirects (-f falla en HTTP error, -s silencia el progreso, -S muestra errores, -L sigue redirects). Pipearlo a sh es el patrón recomendado en la doc oficial; el script detecta distro, agrega el repo si corresponde y configura systemd. Antes de correrlo, asegurate de estar como usuario con sudo y sin un Ollama previo que entre en conflicto.

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

Troubleshooting: Si el script no puede escribir en /usr/local/bin o /etc/systemd, revisa permisos y que no haya otra instalación previa de Ollama; un apt remove ollama anterior puede dejar archivos que entran en conflicto. verifica ollama --version y systemctl status ollama antes de empezar a descargar modelos.

Verifica la versión con ollama --version. El instalador crea un usuario ollama, un servicio systemd (ollama.service) y deja el binario en /usr/local/bin/ollama. La API queda escuchando en http://127.0.0.1:11434 por defecto.

Para verificar que el daemon corre:

Estos dos pasos confirman que el daemon está vivo y expone la API en el puerto por defecto. Validar la versión HTTP antes de la primera descarga evita descubrir más tarde que el servicio no quedó activo o que el puerto está siendo filtrado.

systemctl status ollama te dice si la unit está active (running), su PID y últimas líneas de log. El curl a /api/version golpea el endpoint HTTP real (puerto 11434) y devuelve la versión del servidor, no del binario CLI. Hacer ambos te separa dos problemas distintos: daemon caído vs daemon vivo pero sin escuchar.

systemctl status ollama
curl http://127.0.0.1:11434/api/version

Troubleshooting: Si systemctl status muestra inactive o failed, mira los logs con journalctl -u ollama antes de tocar nada más; un crash temprano suele ser por permiso, GPU rota o puerto ocupado. verifica conectividad con curl a 127.0.0.1 y, si la API está en otra interfaz, no la expongas sin autenticación.

Si quieres exponer la API en la red local (LAN), edita el unit y agrega OLLAMA_HOST=0.0.0.0:11434 en /etc/systemd/system/ollama.service (o /etc/systemd/system/ollama.service.d/override.conf), luego systemctl daemon-reload && systemctl restart ollama.

Tu primer modelo

Ollama organiza los modelos por familia y tamaño. El comando básico:

Este bloque descarga llama3.2:3b en disco y lo corre con un prompt corto para que la primera inferencia sirva como smoke test. El parámetro 3b es liviano: corre en CPU con poca RAM y baja en pocos minutos, ideal para validar que el stack funciona antes de gastar ancho de banda en modelos más grandes.

ollama pull baja el modelo a ~/.ollama/models (configurable con OLLAMA_MODELS). El tamaño de 3b (3 mil millones de parámetros) pesa ~2 GB en cuantización Q4_K_M — sirve para validar el stack. ollama run acepta un prompt inline como segundo argumento y termina después de la respuesta, ideal para smoke tests; sin prompt, abre un REPL interactivo.

ollama pull llama3.2:3b
ollama run llama3.2:3b "explica la diferencia entre TCP y UDP en 3 frases"

Troubleshooting: Si la descarga se interrumpe o falla, revisa espacio en ~/.ollama, conectividad a ollama.com y reiniciá el pull; un modelo corrupto se manifiesta como error de carga al primer run. verifica la primera respuesta: respuestas incoherentes, truncadas o con caracteres basura suelen indicar poca RAM o conflicto con una GPU no detectada.

Tamaños útiles en 2026:

• llama3.2:3b — ~2 GB en disco. Sirve en CPU con 8 GB RAM. Bueno para resúmenes.
• llama3.1:8b — ~4.7 GB. Necesita ~8 GB RAM o VRAM. Balance calidad/recursos.
• qwen2.5:14b — ~9 GB. Excelente razonamiento para su tamaño, corre en GPU media.
• deepseek-r1:14b — modelo de razonamiento. Bueno para problemas lógicos.
• gemma3:27b — ya en el territorio donde necesitas GPU seria (24 GB VRAM).

Para listar los disponibles: ollama list. Para eliminar uno: ollama rm .

Uso con GPU vs CPU

Ollama detecta automáticamente CUDA (NVIDIA), ROCm (AMD) y Metal (Apple Silicon). Para verificar que está usando GPU:

ollama ps muestra los modelos cargados, el tamaño ocupado y dónde se está ejecutando la inferencia. Leerlo antes de probar la GPU te confirma si CUDA o ROCm se ven y si el modelo realmente está usando VRAM, no solo memoria de sistema.

El comando es análogo a ps para procesos pero específico de Ollama: lista los modelos residentes en memoria (no los descargados a disco), con columnas NAME, ID, SIZE, PROCESSOR y UNTIL. La columna crítica es PROCESSOR: dice 100% GPU cuando el modelo corre en CUDA/ROCm/Metal, o 100% CPU cuando cae al backend genérico. La columna SIZE coincide con el espacio que el modelo ocupa en VRAM (o RAM si es CPU).

ollama ps
# columna SIZE muestra VRAM ocupada

Troubleshooting: Si SIZE no concuerda con la VRAM disponible, Ollama está corriendo en CPU aunque tengas GPU; revisa drivers, nvidia-smi o rocminfo y los logs del servicio. verifica que el modelo no exceda la VRAM del equipo: si es así, una parte se descargará a CPU y la inferencia será mucho más lenta.

Si tienes GPU NVIDIA, asegúrate de tener drivers propietarios y CUDA toolkit. En Ubuntu 24.04:

Este comando instala el driver propietario NVIDIA y el toolkit de CUDA en Ubuntu 24.04, las dos piezas que Ollama necesita para usar la GPU. Mantenerlos desde el repositorio oficial evita desincronizar driver y toolkit.

nvidia-driver-560 es la versión del driver que matchea con CUDA 12.x (la versión exacta de CUDA se actualiza). El paquete nvidia-cuda-toolkit instala nvcc, las libs CUDA y las headers necesarias para que aplicaciones como Ollama compilen sus bindings GPU. Después de instalar, hace falta un reboot completo (no reinicio de sesión) para que el kernel module nvidia se cargue; hasta entonces, nvidia-smi va a fallar con command not found o Cannot communicate with driver.

sudo apt install nvidia-driver-560 nvidia-cuda-toolkit

Troubleshooting: Si el servicio de NVIDIA no levanta o CUDA no se detecta, un reboot completo suele ser la solución y, si persiste, mira dmesg y nvidia-smi para descartar fallo de driver. verifica nvcc --version y que ollama ps muestre VRAM ocupada: sin eso, la inferencia cae a CPU aunque el comando termine sin errores.

Si no tienes GPU (o quieres ahorrar VRAM), Ollama corre en CPU pero la inferencia es 5-20x más lenta. Para 3B y 8B en CPU moderna es usable; para 14B+ se nota.

Cuánta RAM necesitas para CPU-only:

• 3B: 6 GB
• 8B: 10 GB
• 14B: 18 GB
• 27B: 36 GB

La API local

Ollama expone una API HTTP compatible con OpenAI en /v1/chat/completions. Eso significa que cualquier cliente OpenAI funciona apuntándolo a http://127.0.0.1:11434/v1:

Esta consulta usa la API compatible con OpenAI para validar el endpoint local con un prompt simple. Hacerlo con curl antes de integrarlo en scripts o IDE te asegura que la URL y el formato JSON son correctos y que el modelo responde.

El endpoint /v1/chat/completions replica la API de OpenAI: misma estructura de mensajes (role, content), mismo formato de response. Eso permite apuntar cualquier cliente compatible (Python SDK, Continue, Cody, LangChain) a http://127.0.0.1:11434/v1 sin tocar código, solo cambiando base_url. El header Content-Type: application/json y el body con model y messages son obligatorios; un JSON mal escapado devuelve 400 Bad Request.

curl http://127.0.0.1:11434/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{
    "model": "llama3.2:3b",
    "messages": [{"role": "user", "content": "resume en una línea: HTTP es un protocolo stateless"}]
  }'

Troubleshooting: Si ves connection refused, el daemon no está escuchando en esa interfaz; si es 404, la ruta cambió entre versiones; si responde vacío o con error, el modelo no está descargado o el nombre difiere del listado por ollama list. verifica que el model devuelto coincida con el esperado y que el JSON no esté siendo truncado por un proxy o un Content-Length incorrecto.

Para integrarlo con herramientas (Continue, Cody, scripts Python), solo cambias base_url y dejas la api_key vacía o con cualquier string. Ejemplo Python con openai SDK:

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": "Hola"}]
)
print(resp.choices[0].message.content)

Casos de uso reales

• RAG local: indexa tus docs con chromadb o faiss, recuperas contexto y lo pasas al LLM vía Ollama. Nada sale de tu red.
• Asistente de código en IDE: Continue (VS Code) o Cody apuntan a Ollama. Autocompletado y chat privados.
• Pipeline de transformación: scripts que renombran archivos, resumen logs, generan descripciones de productos en bulk.
• Sandbox para experimentar: pruebas de prompts y chains sin gastar créditos.

Seguridad y buenas prácticas

• No expongas el puerto 11434 a internet sin autenticación. La API no trae auth. Si necesitas acceso remoto, ponlo detrás de un reverse proxy con auth (Caddy, Nginx + basic auth, o Tailscale).
• Limita el bind a 127.0.0.1 si solo lo usas local. Cambiar a 0.0.0.0 abre la API a toda tu LAN.
• Modelos grandes pueden leer todos tus archivos si el sistema permite. Mantén los modelos en su sandbox y no les des acceso al filesystem a menos que sepas lo que haces.
• Actualiza Ollama con frecuencia. Las versiones nuevas mejoran performance y corrigen bugs de seguridad. ollama --version vs la última release en GitHub.

Modelos personalizados: Modelfile

Puedes crear tus propios modelos con un Modelfile:

FROM llama3.2:3b
SYSTEM """Eres un asistente técnico que responde en español de forma concisa. Máximo 3 párrafos por respuesta."""
PARAMETER temperature 0.7
PARAMETER num_ctx 4096

Guárdalo como ~/asistente.Modelfile y créalo:

Este bloque crea un modelo personalizado a partir de llama3.2:3b con un system prompt en español y luego lo ejecuta con una pregunta. Dejar el system prompt en el Modelfile te ahorra enviarlo en cada request y asegura que el tono se mantenga estable entre llamadas.

ollama create toma un Modelfile (sintaxis similar a Dockerfile, con FROM para el modelo base y directivas como SYSTEM, PARAMETER, TEMPLATE) y registra un nuevo tag local. El nombre asistente es el que después usas en ollama run o en la API. Sin el modelo base descargado, el create falla; validá con ollama list antes. El system prompt queda embebido en el modelo, así que no necesitas mandarlo en cada llamada.

ollama create asistente -f ~/asistente.Modelfile
ollama run asistente "explica qué es un socket Unix"

Troubleshooting: Si el modelo no queda creado, validá que el FROM exista con ollama list y que las comillas escapadas del SYSTEM no rompan el parseo del Dockerfile. verifica que el system prompt se aplique: la primera respuesta debe respetar la indicación de idioma y concisión, si la ignora, el Modelfile no se cargó bien o el modelo base no se descargó por completo.

Conclusión

Ollama es la forma más directa de tener IA local en Linux sin pelearte con PyTorch, transformers ni dependencias. Para casos donde la privacidad o el costo por token importan, es la mejor opción 2026. Para razonamiento de frontera, sigue siendo mejor un modelo cloud grande. Lo útil: ya puedes elegir caso por caso.

FAQ

¿Necesito GPU?

No. CPU funciona, solo más lento. Modelos 3B-8B son usables en CPU con 8-16 GB RAM.

¿Los modelos son gratis?

Sí, Ollama es open source (MIT) y los modelos que descarga son de varias licencias (la mayoría permiten uso comercial, revisa cada modelo).

¿Cómo sé si Ollama usa GPU?

ollama ps muestra el modelo cargado y su tamaño. Si coincide con VRAM disponible, está en GPU.

¿Funciona offline después de la descarga?

Sí. Una vez que el modelo está en ~/.ollama/models, no necesitas internet para inferencia.

Fuentes

• https://github.com/ollama/ollama
• https://ollama.com/library
• https://ollama.com/docs
• https://github.com/ollama/ollama/blob/main/docs/api.md

---

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux