Ollama: corre un LLM en local sin API key paso a paso 2026

TL;DR: Ollama es la forma más rápida de correr un LLM en tu propia máquina: tres comandos y tienes un modelo abierto (Llama, Qwen, Gemma, GLM) respondiendo sin API key ni factura por token. En esta guía verás cómo instalarlo, qué hardware necesitas según el tamaño del modelo, cómo montar una interfaz tipo ChatGPT con Open WebUI y cómo conectar tu código a su API compatible con OpenAI. Y lo que casi nadie cuenta: cuándo el local-first gana de verdad y cuándo te sale más caro que pagar la nube.

El problema: cada prompt es una llamada a caja registradora

Cuando desarrollas con LLMs en la nube, cada iteración cuesta. No hablo de cientos de euros, pero un dev que prototipa a diario se planta en 10-50€/mes de APIs sin darse cuenta, y eso antes de exponer nada a usuarios. A eso súmale dos pegas que no se arreglan con dinero: tus datos salen de tu red en cada petición, y dependes de la latencia y los límites de un proveedor externo.

El local-first resuelve las tres cosas a la vez: coste marginal cero por inferencia, datos que no se mueven de tu máquina y cero dependencia de una API ajena. En 2026 dejó de ser un experimento. Con modelos abiertos potentes (Qwen3, Gemma, GLM, Kimi) y un runtime que los hace correr en tu portátil, el local sirve para tareas reales. La herramienta que lo ha vuelto trivial se llama Ollama.

¿Qué es Ollama?

Ollama es un runtime open-source que descarga, gestiona y sirve modelos de lenguaje en local con un solo comando, exponiéndolos por una API HTTP en tu propia máquina. Hace por los LLMs lo que Docker hizo por las aplicaciones: empaqueta el modelo, sus pesos y su configuración en algo que arranca igual en cualquier sitio.

Por debajo usa llama.cpp (y el motor MLX en Apple Silicon) y trabaja con el formato GGUF, que se ha convertido en el estándar de facto para inferencia local: un único fichero con tokenizer, metadatos y pesos. La versión 0.30, publicada el 05/06/2026, trae hasta un 20% más de rendimiento en hardware NVIDIA y soporte Vulkan para ampliar las GPUs compatibles, según el blog oficial de Ollama.

Instalación: de cero a chatear en tres comandos

Takeaway: no hay configuración. Instalas, descargas un modelo y hablas con él.

En Linux o macOS, el primer paso es un único script de instalación. En Windows hay instalador gráfico.

Instala el runtime de Ollama en tu sistema:

# Descarga e instala Ollama (Linux/macOS); deja corriendo el servicio en localhost:11434
curl -fsSL https://ollama.com/install.sh | sh

Ahora descarga un modelo y empieza a conversar. qwen3:8b es un buen punto de partida: ronda los 5 GB y cabe en cualquier GPU decente.

# Descarga el modelo y abre un chat interactivo en la terminal
ollama run qwen3:8b

La primera vez tarda lo que pese la descarga; después arranca en segundos. Para ver qué tienes instalado:

# Lista los modelos descargados y su tamaño en disco
ollama list

Eso es todo. Tienes un LLM respondiendo offline, sin clave de API ni telemetría. El servicio queda escuchando en localhost:11434, que es la puerta que usaremos para todo lo demás.

¿Qué hardware necesito? Tabla de VRAM por tamaño de modelo

Regla rápida: el cuello de botella es la VRAM, no la CPU. Con cuantización Q4_K_M (la recomendada por defecto) un modelo de 7-8B cabe en 6-8 GB y va sobrado para uso diario. La cuantización reduce a la mitad la memoria necesaria con una pérdida de calidad mínima.

VRAM disponible	Modelos que corren bien (Q4_K_M)	Uso típico
4-6 GB	3-4B (Llama 3.2 3B, Qwen3 4B)	Tareas ligeras, autocompletado
6-8 GB	7-9B (Llama 3.1 8B, Qwen3 8B)	Punto dulce diario, ~40 tok/s
10-12 GB	12-14B (Gemma 3 12B, Qwen3 14B)	Daily driver equilibrado
16-24 GB	22-32B (Qwen3 32B, Gemma 3 27B)	Razonamiento más profundo
48 GB+	70B+ (Llama 3.3 70B)	Calidad alta, requiere workstation

Dos consejos honestos de quien lo ha probado en máquinas normales, no en granjas de GPUs: no bajes de Q4, porque la caída en razonamiento e instrucciones se nota rápido, y quédate en 8k-16k de contexto para uso normal, ya que estirarlo a 32k suele ralentizar más de lo que ayuda. Si no tienes GPU dedicada, los modelos 3-7B corren en CPU con 8 GB de RAM, pero a 2-5 tokens/segundo: usable para pruebas, doloroso para trabajar.

Open WebUI: tu ChatGPT privado en minutos

La terminal está bien para probar, pero para uso real querrás una interfaz. Open WebUI es un frontend open-source que se parece a ChatGPT y se conecta a Ollama, con historial, subida de documentos y gestión de usuarios. La forma limpia de levantarlo es Docker.

Levanta Open WebUI apuntando a tu Ollama del host:

# Arranca Open WebUI en el puerto 3000 y lo conecta a Ollama corriendo en el host
docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

Abre http://localhost:3000, crea la cuenta (el primer usuario es el admin) y ya tienes una interfaz completa sobre tus modelos locales. Un detalle importante de red: si Open WebUI no encuentra Ollama, suele ser porque Ollama solo escucha en 127.0.0.1. Configúralo para escuchar en 0.0.0.0 con la variable OLLAMA_HOST y se arregla.

Conecta tu código: la API compatible con OpenAI

Aquí está la palanca real para developers. Ollama expone un endpoint compatible con la API de OpenAI en localhost:11434/v1. Eso significa que cualquier código escrito con el SDK de OpenAI funciona cambiando dos líneas: la base_url y la clave (que aquí es de pin, da igual el valor).

Ejemplo mínimo completo en Python. Solo necesitas pip install openai y tener un modelo descargado:

# Usa el SDK de OpenAI contra Ollama local: misma interfaz, cero coste por token
from openai import OpenAI

# La base_url apunta a Ollama; api_key es obligatoria pero su valor se ignora
client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",
)

respuesta = client.chat.completions.create(
    model="qwen3:8b",
    messages=[
        {"role": "system", "content": "Eres un asistente conciso en espanol."},
        {"role": "user", "content": "Explica que es la cuantizacion en una frase."},
    ],
)

print(respuesta.choices[0].message.content)

El patrón que me funciona: una variable de entorno LLM_ENDPOINT que en desarrollo apunta a Ollama y en producción a la API de pago. El mismo código vale para ambos, y prototipas gratis antes de gastar un euro en la nube. Esto encaja igual de bien si estás montando un pipeline de procesamiento de documentos para RAG y quieres iterar sobre el chunking sin pagar por cada prueba.

Caso real: ¿cuándo usar esto en producción?

El local-first brilla en escenarios concretos del mundo laboral:

Datos sensibles: documentación interna, datos de clientes, código propietario que no puede salir de tu red por cumplimiento o RGPD.
Volumen de prototipado alto: cuando iteras cientos de veces al día sobre prompts y la factura de la API se dispara sin aportar valor.
Asistente de código self-hosted: herramientas como Tabby te dan autocompletado tipo Copilot sin mandar tu repo entero a la nube, apoyándose en un modelo local.
Offline o entornos cerrados: máquinas sin acceso a internet o con conectividad poco fiable.

Una nota de calibración: antes de decidir qué modelo abierto usar, no te fíes de los benchmarks de marketing. Monta una mini-evaluación con tus tareas reales, igual que harías al elegir un modelo para un agente de coding. Los números de un benchmark genérico rara vez predicen cómo rinde en tu caso.

En Producción

La verdad incómoda: Ollama es excelente para un usuario, flojo para muchos a la vez. Está optimizado para latencia de una sola petición, no para throughput concurrente. Si vas a servir a usuarios reales en paralelo, hay un punto en el que Ollama deja de ser la herramienta adecuada.

Criterio	Ollama (quédate aquí)	vLLM (escala aquí)
Concurrencia	1 a pocos usuarios	Decenas en paralelo (continuous batching, 2-4x throughput)
Observabilidad	Logging básico	Métricas Prometheus, request-level logging
Caso ideal	Dev local, prototipo, equipo pequeño	Servicio en producción con SLA de latencia
Curva de entrada	Tres comandos	Configuración y tuning de GPU

Coste real: el local no es gratis, es coste hundido. La inferencia no te cuesta por token, pero pagas el hardware (una GPU con 8-12 GB de VRAM es la entrada razonable) y la electricidad durante sesiones largas, donde la térmica y el consumo acaban siendo el límite antes que los tokens/segundo. Haz la cuenta: si gastas 15-20€/mes en API y un modelo de 8B te sobra, la GPU tarda años en amortizarse. El local compensa por privacidad y control, no siempre por dinero.

Cuándo NO usar local: si necesitas capacidad frontera (los modelos cerrados de gama alta siguen por delante en razonamiento complejo), si tu carga es esporádica (la nube paga por uso, sin hardware parado) o si requieres alta concurrencia con monitoreo serio. Y recuerda que la calidad de un modelo local también se degrada o se queda corta: vigílala con el mismo rigor con el que mides la calidad de tu IA en producción, no por intuición.

Errores comunes y depuración

Error: Open WebUI no ve los modelos. Causa: Ollama escucha solo en 127.0.0.1 y el contenedor no llega. Solución: exporta OLLAMA_HOST=0.0.0.0 y reinicia el servicio.
Error: out-of-memory al cargar el modelo. Causa: el modelo no cabe en VRAM y hace offload pesado a CPU. Solución: baja a un tamaño menor o usa una cuantización más agresiva (de Q5 a Q4), nunca por debajo de Q4.
Error: respuestas lentísimas (2-5 tok/s). Causa: el modelo corre en CPU porque no detecta GPU. Solución: verifica drivers con nvidia-smi y arranca con --verbose para ver el offload por capas.
Error: respuestas inconsistentes. Causa: temperatura por defecto o falta de system prompt. Solución: ajusta un Modelfile con temperatura 0.7-0.8 y un system prompt específico del proyecto.

Preguntas frecuentes

¿Necesito GPU para usar Ollama?

No es obligatoria. Los modelos de 3-7B corren en CPU con 8 GB de RAM, pero a 2-5 tokens/segundo. Para trabajar con fluidez (20-40 tok/s en un modelo 7B) necesitas una GPU con 8 GB o más de VRAM.

¿Ollama es seguro para datos confidenciales?

Sí, porque todo corre en tu máquina y no hay telemetría ni datos saliendo a una API externa. Es una de sus mayores ventajas frente a la nube para escenarios con requisitos de RGPD o documentación interna.

¿Qué modelo abierto elijo para empezar?

Para uso general con 8-12 GB de VRAM, un modelo de 7-8B como Qwen3 8B con cuantización Q4_K_M es el punto dulce. Para razonamiento más exigente y si tienes 16-24 GB, sube a un 27-32B. Evalúalo siempre con tus propias tareas antes de comprometerte.

Cierre

Hemos visto que con Ollama pasas de cero a un LLM corriendo en local en tres comandos, que el límite real es la VRAM y no la CPU, y que su API compatible con OpenAI te deja prototipar gratis con el mismo código que luego apuntará a la nube. La clave está en elegir bien la batalla: el local gana en privacidad, coste de iteración y control, mientras que la nube y herramientas como vLLM siguen ganando en capacidad frontera y concurrencia. No es local contra nube, es saber enrutar cada tarea a donde rinde.

¿Ya tienes un modelo abierto corriendo en tu máquina, o te frena el hardware? Cuéntame tu setup en los comentarios o en Twitter @sergiomarquezp_. En el próximo artículo montaremos un RAG completo encima de Ollama para darle a tu modelo local acceso a tus propios documentos.