¿Ollama no funciona? 9 errores, su mensaje exacto y el arreglo

Cuando Ollama falla, su registro suele decir por qué. Aquí van nueve fallos con su arreglo: el puerto 11434 ocupado, un cliente que no encuentra el servidor, un modelo atascado en la CPU, una gráfica NVIDIA o AMD que no aparece, la memoria agotada al subir el contexto, una primera respuesta lentísima y descargas o carpetas que no colaboran.

Correr un modelo en tu propio equipo es una gozada hasta que, en vez de una respuesta, te devuelve un error. La buena noticia es que los errores de Ollama son cortos y bastante sinceros, y cada uno apunta a una causa concreta. Abajo tienes cada problema con el texto exacto que vas a ver, por qué pasa y cómo se arregla en Mac, Windows y Linux, con los comandos de la versión estable vigente, la 0.40.10 (publicada el 23 de octubre de 2026). Todos los mensajes de Ollama que se citan aquí los hemos vuelto a buscar en el código y la documentación de cada versión estable desde la 0.40.0, la última vez en la 0.40.10, el 24 de octubre de 2026, y no ha cambiado ninguno; lo que añade la 0.40.0 es una columna RUNNER en ollama ps y MLX de serie en los Mac con Apple Silicon, y las secciones en las que eso importa lo dicen. La instalación, la comprobación de que el servidor responde y cómo darle variables de entorno están en nuestra guía para instalar Ollama en local; esta página empieza donde acaba aquella.

OllamaFicha del programa→

Antes de tocar nada, mira el registro

El error de la terminal es el titular; el registro (el log) es la noticia completa. Está aquí:

# macOS
cat ~/.ollama/logs/server.log

# Linux (servicio de systemd)
journalctl -u ollama --no-pager --follow --pager-end

# Docker
docker logs <nombre-del-contenedor>

# Windows: abre la carpeta con server.log (el actual)
# y server-#.log (los anteriores)
explorer %LOCALAPPDATA%\Ollama

Si arrancaste ollama serve a mano, el registro sale en esa misma terminal. Para ver más detalle, OLLAMA_DEBUG=1 lo sube a nivel de depuración y OLLAMA_DEBUG=2 a traza. Cómo pasarle esa variable a la aplicación o al servicio depende del sistema, y lo explicamos paso a paso en la guía de instalación. En Windows, la vía rápida es salir de la aplicación desde la bandeja del sistema y, en PowerShell:

$env:OLLAMA_DEBUG="1"; & "ollama app.exe"

Si prefieres verlo antes de hacerlo, este vídeo corto enseña cómo revisar los registros cuando Ollama deja de responder. Está en inglés, y donde no coincida con esta página, manda la versión 0.40.10.

«bind: address already in use» en el puerto 11434

Escribes ollama serve y te contesta esto:

Error: listen tcp 127.0.0.1:11434: bind: address already in use

Así lo dice Linux; en otros sistemas el final puede cambiar. El significado es el mismo: ya hay un servidor de Ollama funcionando. En macOS y Windows la aplicación de escritorio lanza ollama serve ella sola, y en Linux el instalador deja activado un servicio de systemd llamado ollama. Dos servidores y un solo puerto: el juego de la silla, pero con una silla.

Casi nunca hace falta escribir ollama serve. Comprueba que el que ya está en marcha contesta:

curl http://127.0.0.1:11434
Ollama is running

Si de verdad quieres tu propio servidor en primer plano, por ejemplo para ver qué escribe en directo, para antes el otro: sudo systemctl stop ollama en Linux, o sal de la aplicación desde la barra de menús (Mac) o la bandeja del sistema (Windows). La otra salida es darle otro puerto y apuntar los clientes a esa misma dirección:

OLLAMA_HOST=127.0.0.1:11435 ollama serve

En Linux, esto te dice qué proceso tiene el puerto:

sudo ss -ltnp | grep 11434

«could not connect to ollama server»

El caso contrario: el comando está instalado, pero no hay ningún servidor escuchando.

Error: could not connect to ollama server, run 'ollama serve' to start it

ollama -v da la misma noticia con más suavidad: Warning: could not connect to a running Ollama instance. En Linux, la línea de comandos nunca arranca un servidor por su cuenta, así que el mensaje solo quiere decir que el servicio está parado. En macOS y Windows, antes de rendirse, intenta abrir la aplicación; el error solo aparece si no lo consigue.

# Linux
sudo systemctl start ollama
sudo systemctl status ollama

En un Mac o en Windows, abre la aplicación de Ollama. Si el servidor vive en otro equipo o en otro puerto, el cliente necesita el mismo OLLAMA_HOST que el servidor; sin él, llama a 127.0.0.1:11434 y no le abre nadie.

¿Va por la GPU? Mira la columna PROCESSOR

Un modelo que contesta a paso de tortuga suele ser un modelo que no está en la tarjeta gráfica. Los ventiladores del portátil te lo avisarán antes que cualquier comando, pero ollama ps te lo dice con números. Sus columnas son NAME, ID, SIZE, PROCESSOR, CONTEXT, RUNNER (nueva en la 0.40.0: llamacpp o mlx) y UNTIL, y la que importa es PROCESSOR:

• 100% GPU: el modelo entero está en la gráfica. Todo en orden.
• 100% CPU: está en la memoria del sistema, o porque la gráfica no se ha detectado (las dos secciones siguientes) o porque no hay gráfica que usar.
• Un reparto como 48%/52% CPU/GPU: el modelo y su contexto no cabían en la memoria de la gráfica, y una parte va por el procesador.
• En un Mac con Apple Silicon y mlx en RUNNER: 100% GPU, porque MLX no reparte el modelo. Si el modelo en sí no cabe en la memoria libre, no se carga, y el error contiene model requires … but only … are available.

Si sale repartido, tienes tres salidas: bajar el contexto (dos secciones más abajo), usar una versión más comprimida o un modelo más pequeño, o liberar memoria descargando los modelos que no usas con ollama stop <modelo>. El buscador de modelos te dice de antemano qué modelos caben en tu equipo y con cuánto contexto.

La GPU NVIDIA no aparece

Empieza por los requisitos, que descartan mucho. Para la versión 0.40.10, Ollama pide una gráfica NVIDIA con capacidad de cómputo (compute capability) 5.0 o superior y controlador 550 o posterior; las que tienen capacidad de cómputo de 5.0 a 6.2 necesitan el controlador 570 o posterior. NVIDIA publica la capacidad de cómputo de cada tarjeta en su página de GPU CUDA.

Si tu tarjeta cumple y aun así Ollama se va a la CPU, el registro suele traer un código de error: 3 (sin inicializar), 46 (dispositivo no disponible), 100 (ningún dispositivo) o 999 (desconocido). Ve probando en este orden:

# 1. El controlador tiene que ver la tarjeta
nvidia-smi

# 2. Comprobar que está cargado el módulo de memoria unificada (UVM)
sudo nvidia-modprobe -u

# 3. Recargar el módulo de memoria unificada (el remedio documentado tras suspender y reanudar en Linux)
sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm

Si nada de eso funciona, reinicia y actualiza el controlador. Para más detalle, arranca el servidor con CUDA_ERROR_LEVEL=50 y mira sudo dmesg | grep -i nvrm. Y si alguien dejó puesta CUDA_VISIBLE_DEVICES=-1 en algún sitio, esa es justo la forma oficial de obligar a usar la CPU: quítala.

En Docker, docker run --gpus all ubuntu nvidia-smi tiene que funcionar antes de que Ollama pueda ver nada. Si el contenedor arranca en la GPU y al rato se pasa a la CPU, añade "exec-opts": ["native.cgroupdriver=cgroupfs"] a /etc/docker/daemon.json y reinicia Docker.

La GPU AMD no aparece en Linux

Con una gráfica AMD, dos líneas del registro te delatan el problema:

msg="failure during GPU discovery" ... error="failed to finish discovery before timeout"
msg="bootstrap discovery took" duration=30s

La causa habitual es la versión del controlador. Ollama 0.40.10 trae las librerías de ROCm 7, y con un controlador del núcleo de ROCm 6.x o anterior la búsqueda de la GPU se cuelga y acaba en la CPU. El arreglo: actualizar al controlador de ROCm 7 con amdgpu-install, reiniciar el equipo y reiniciar Ollama.

La otra causa son los permisos de /dev/kfd: el usuario que ejecuta Ollama tiene que estar en el grupo render (en algunos sistemas, video). El instalador oficial ya mete al usuario ollama en los dos grupos si existen; tras una instalación manual, hazlo tú:

sudo usermod -a -G render ollama

Si ROCm no da soporte a tu tarjeta, puedes hacerla pasar por una pariente cercana. El ejemplo documentado es una RX 5400 (gfx1034) que se presenta como gfx1030:

HSA_OVERRIDE_GFX_VERSION="10.3.0"

Con varias tarjetas, una variable numerada como HSA_OVERRIDE_GFX_VERSION_0 lo fija tarjeta a tarjeta. La alternativa es Vulkan, que viene activado si está su motor (OLLAMA_VULKAN=0 lo apaga); para que Ollama lea la memoria libre real a través de Vulkan, ejecuta sudo setcap cap_perfmon+ep /usr/local/bin/ollama. Para verlo todo con lupa: AMD_LOG_LEVEL=3, OLLAMA_DEBUG=1 y sudo dmesg | grep -i amdgpu.

Se queda sin memoria al subir el contexto

El contexto (cuánto texto tiene el modelo a la vista) tiene una factura de memoria, la caché KV, y con llama.cpp (llamacpp en la columna RUNNER de ollama ps) se paga por adelantado al cargar el modelo. Si pides demasiado, Ollama se para con un mensaje del tipo llama-server reported out-of-memory during startup: …, o con uno que contiene out of memory, cudaMalloc failed o hipMalloc failed. A veces no hay error: el modelo se reparte en silencio entre CPU y GPU.

La versión 0.40.10 elige el contexto por defecto según la memoria gráfica que detecta: 4096 tokens por debajo de 23 GiB, 32 768 desde 23 GiB y 262 144 desde 47 GiB. El registro apunta la elección como default_num_ctx. Para cambiarlo:

# Para todo el servidor
OLLAMA_CONTEXT_LENGTH=8192 ollama serve

# Dentro de una sesión de ollama run
/set parameter num_ctx 8192

# En cada petición, por la API
"options": {"num_ctx": 8192}

La aplicación de escritorio tiene un deslizador para esto en sus ajustes. El resultado lo ves en la columna CONTEXT de ollama ps.

En un Mac con Apple Silicon y un modelo que va con MLX (mlx en RUNNER), estos ajustes funcionan distinto: MLX no reserva el contexto al cargar el modelo, su caché KV crece a medida que crece la conversación, y la cifra de CONTEXT ni reserva memoria ni recorta la conversación; el techo es el contexto máximo del propio modelo. Ahí la memoria se va llenando a medida que la conversación se alarga, no de golpe al cargar.

¿Cuánto cuesta? Hemos echado las cuentas con nuestra propia calculadora para un Mac de 16 GB, que deja 13,0 GiB para el modelo, con compresión Q4_K_M y la caché KV en f16, la de serie en Ollama:

Mac con M4 y 16 GB unificadosFicha del equipo→

Modelo	4k	8k	32k	64k	De 8k a 32k
Qwen3 8B	5,92 GiB	6,56 GiB	10,38 GiB	15,48 GiB ✗	+3,82 GiB
Gemma 4 12B	7,68 GiB	7,82 GiB	8,65 GiB	9,75 GiB	+0,82 GiB
gpt-oss-20b	11,60 GiB	11,77 GiB	12,78 GiB	14,13 GiB ✗	+1,01 GiB

Memoria total necesaria (archivo del modelo + caché KV + consumo propio del programa). Cálculo de Local AI Scope del 5 de octubre de 2026 (la fila de Gemma 4 12B, del 15 de octubre de 2026): tamaños de archivo medidos, caché KV calculada con la arquitectura de cada modelo, consumo propio estimado. ✗ = no cabe en los 13,0 GiB disponibles.

En un Mac con Apple Silicon, desde la 0.40.0, ollama pull gemma4:12b trae en su lugar la versión MLX (compresión NVFP4, 7,18 GiB de descarga frente a 7,47 GiB la GGUF), que paga su contexto sobre la marcha, como se explica arriba; la fila de Gemma 4 12B es la versión GGUF, la que reciben Windows, Linux y los Mac con Intel. A 7 de octubre de 2026, Qwen3 8B y gpt-oss-20b solo existen en GGUF y también en el Mac van con llama.cpp.

Esa última columna tiene su miga: para agentes y tareas de programación, Ollama recomienda un contexto de al menos 64 000 tokens. En una gráfica de 8 GB la historia se repite antes: Qwen3 8B cabe a 4k, muy justo a 8k y ya no a 32k. El buscador de modelos hace esta cuenta para tu propio equipo.

PC con RTX 4060 8 GBFicha del equipo→

La primera respuesta tarda: el modelo salió de la memoria

La primera pregunta después del café tarda una eternidad y la siguiente vuela. No es una avería: Ollama mantiene un modelo en memoria 5 minutos después de usarlo por última vez y luego lo descarga, así que la siguiente pregunta paga la carga otra vez. La columna UNTIL de ollama ps te dice cuánto le queda.

OLLAMA_KEEP_ALIVE en el servidor, o keep_alive en cada petición, lo cambia: una duración como 10m o 24h, un número de segundos, un número negativo para dejarlo cargado para siempre o 0 para descargarlo en cuanto conteste. Lo que pongas en la petición manda sobre la variable. Para precargar un modelo y dejarlo ahí:

curl http://localhost:11434/api/generate -d '{"model": "llama3.2", "keep_alive": -1}'

Cambia llama3.2 por tu modelo. Para liberar la memoria, ollama stop <modelo>. Si lo que no acaba nunca es la carga, el mensaje empieza por timed out waiting for llama-server to start: por defecto se rinde tras 5 minutos sin avanzar y OLLAMA_LOAD_TIMEOUT amplía ese plazo. Con un modelo en MLX, el mensaje empieza en cambio por timeout waiting for mlx runner, y el plazo lo marca la misma variable, aunque ahí cuenta la carga entera y no solo el tiempo sin avanzar.

Descargas que fallan tras un proxy y permisos de carpetas en Linux

Detrás del proxy de la empresa, ollama pull necesita el proxy en el entorno del servidor, no en tu terminal:

HTTPS_PROXY=https://proxy.example.com

Se pone igual que cualquier otra variable del servidor, y el certificado del proxy tiene que estar instalado como certificado del sistema. En Docker, pásalo con -e HTTPS_PROXY=https://proxy.example.com, o crea una imagen que añada el certificado y ejecute update-ca-certificates.

¿La descarga pasa de pulling manifest y se para? Mira ollama -v. Hasta la 0.40.5 (en los modelos GGUF, desde la 0.35.0), los ficheros del modelo no pasaban por ese proxy: Ollama los bajaba directamente del servidor de descargas, después de resolver su nombre en el propio equipo, así que en una red donde solo el proxy sale a internet la descarga fallaba, con redirect target not allowed: resolving …: no such host si el equipo no podía resolver ese nombre. Desde la 0.40.6 los ficheros también van por el proxy: actualizar lo arregla.

¿Has movido los modelos y ya no carga nada? Por defecto viven en ~/.ollama/models en macOS, en /usr/share/ollama/.ollama/models en Linux y en C:\Users\%username%\.ollama\models en Windows, y OLLAMA_MODELS los cambia de sitio. En Linux el servicio corre con su propio usuario, ollama, que necesita leer y escribir en la carpeta nueva:

sudo chown -R ollama:ollama /ruta/a/tus/modelos

Si esa carpeta ha crecido desde que actualizaste, es por esto: en la 0.40.0, la 0.40.1 y la 0.40.2, un modelo descargado con una versión anterior podía convertirse para llama.cpp en segundo plano la primera vez que lo ejecutabas, si en el disco cabía la copia, y Ollama guardaba el original en la misma carpeta como respaldo por si volvías a una versión anterior, así que los pesos de un modelo convertido están dos veces en el disco. La 0.40.3 puso en pausa esa conversión, y la 0.40.10 sigue sin reanudarla: ya no se lanza al cargar un modelo, y lo convertido hasta ahora sigue en el disco, copia y respaldo incluidos. Desde la 0.40.2, ollama list muestra cada modelo una sola vez, y las notas de la 0.40.2 traen un comando que borra los respaldos (después, volver a una versión anterior a la 0.40 obliga a descargar otra vez esos modelos).

Mensajes, comandos y valores por defecto de las páginas de resolución de problemas, preguntas frecuentes, GPU, Linux y longitud de contexto de Ollama y de su código fuente, versión 0.40.10, leídos el 24 de octubre de 2026 (la primera lectura fue sobre la 0.35.1, el 3 de octubre de 2026): los mensajes no cambian, y la columna RUNNER y las notas sobre MLX salen de la 0.40.0.

Qué manda Ollama por su cuenta mientras todo esto funciona, y cómo queda frente a los demás programas, lo tienes en su ficha.