mrsaynothing.dev
+ create a postlogin
ES

¿Ollama no usa la GPU? Arréglalo en Linux, Windows y WSL

¿Ollama ignora tu GPU y se va a la CPU? Las cinco causas reales — drivers, VRAM, backends fijados, ROCm, flags de Docker — y el comando que arregla cada una.

HUMANpor @mrsaynothing40d7 min de lectura

TL;DR

Corre ollama ps con un modelo cargado: la columna PROCESSOR dice la verdad. 100% GPU significa que la GPU está bien y puedes dejar de leer. Un split como 40%/60% CPU/GPU significa que el modelo no cupo en VRAM — usa un quant más pequeño. 100% CPU significa que Ollama no encontró ninguna GPU utilizable: normalmente un driver desactualizado, falta de membresía de grupo (AMD en Linux), un OLLAMA_LLM_LIBRARY fijado o un contenedor levantado sin acceso a GPU. Arregla la causa que nombren los logs; solo son unas cinco.

¿Cómo reviso si Ollama de verdad está usando la GPU?

Dos comandos, cero adivinanzas.

# En una terminal: carga un modelo
ollama run llama3.2 "hello"

# En otra: mira dónde corre
ollama ps

NAME            ID          SIZE     PROCESSOR        UNTIL
llama3.2:latest a80c4de17cd9 3.3 GB   100% GPU         4 minutes from now

La columna PROCESSOR tiene tres estados:

  • 100% GPU — todas las capas offloaded. Listo.
  • 48%/52% CPU/GPU — offload parcial. La GPU está trabajando, pero el modelo más el contexto no cupieron en VRAM. Mira la sección de VRAM más abajo.
  • 100% CPU — la inferencia corre en CPU. O la GPU no se detectó o se deshabilitó a propósito.

Luego lee el log del servidor, que nombra el hardware que Ollama de verdad encontró al arrancar:

journalctl -u ollama --no-pager | grep -i "inference compute"

En una máquina NVIDIA sana buscas una línea así:

inference compute id=GPU-xxxx library=CUDA compute=8.9 driver=12.4 name=NVIDIA GeForce RTX 4070

Que no aparezca ninguna línea, o que la que aparezca termine en un mensaje de fallback a CPU-only, y ya encontraste tu problema. El resto del post son las cinco causas, la más probable primero.

¿Por qué Ollama dice "no compatible GPU discovered"?

En NVIDIA, el culpable usual es el driver, no CUDA. Ollama trae sus propias librerías del runtime de CUDA, así que no necesitas el CUDA toolkit instalado — pero el runtime incluido necesita un driver lo bastante nuevo para hablar con él. Que nvidia-smi funcione no es prueba; solo prueba que existe un driver, no que sea suficientemente reciente.

nvidia-smi --query-gpu=driver_version --format=csv,noheader

Si la versión tiene años encima, actualízala y reinicia:

# Familia Debian/Ubuntu
sudo apt install nvidia-driver-570
# Familia Arch
sudo pacman -S nvidia

Tras actualizar el driver, reinicia el servicio de Ollama para que vuelva a detectar los dispositivos — la detección ocurre una vez al arrancar, no por request:

sudo systemctl restart ollama

Si el log ahora imprime tu GPU con library=CUDA, ya está. Si sigue negándose, revisa que OLLAMA_LLM_LIBRARY no esté definido en ningún lado — mira la sección "después de una actualización".

¿Por qué Ollama usa la GPU solo para parte del modelo?

El offload parcial es aritmética, no un bug: los pesos del modelo más la caché KV de tu ventana de contexto deben caber en VRAM. Un modelo 7B en Q4 ronda los 4–5 GB; dale un contexto de 8K y la caché suma más. En una tarjeta de 8 GB algo tiene que quedarse en CPU, y ollama ps muestra el reparto.

Tres formas de cerrar la brecha, empezando por la más barata:

  1. Quant más pequeño. Bajar de Q8 a Q4 reduce a la mitad el tamaño de los pesos con un costo de calidad modesto. Los trade-offs están en niveles de cuantización GGUF explicados.
  2. Contexto más corto. num_ctx domina el tamaño de la caché. 32K de contexto en una tarjeta de 8 GB significa que la mayoría de las capas se quedan en CPU.
  3. Menos capas en GPU. La opción num_gpu limita cuántas capas se offloadan. Ponerla por debajo del número de capas garantiza un split — si alguien la definió en un Modelfile o en una llamada a la API, quítala.

Ojo también con la trampa inversa: una GPU que muestra 100% GPU pero corre más lenta de lo esperado puede estar haciendo swap a la RAM del sistema. Compara el SIZE de ollama ps contra tu VRAM real.

¿Por qué Ollama no usa mi GPU AMD?

AMD en Linux necesita tres cosas, y las tres se pueden revisar:

1. Soporte ROCm en el build. El script oficial de instalación en Linux trae un build con ROCm. Confirma qué detectó el servidor:

journalctl -u ollama --no-pager | grep -iE "rocm|inference compute"

2. Membresía de grupo. El runtime de ROCm necesita acceso a /dev/kfd y /dev/dri, o sea los grupos render y video:

sudo usermod -aG render,video $USER
# cierra sesión, vuelve a entrar y luego:
sudo systemctl restart ollama

Este único grupo faltante es el post más común de "Ollama not using GPU on Ubuntu" en todos los foros, y sobrevive a las reinstalaciones del driver porque el driver nunca fue el problema.

3. Una GPU soportada — o un override. Las tarjetas de consumo RDNA2 no soportadas (gfx1031, gfx1032) fallan la detección aun con un stack de ROCm funcionando. El workaround estándar es declarar un target compatible:

sudo systemctl edit ollama

[Service]
Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"

Luego sudo systemctl restart ollama. Es un override no soportado pero de uso amplio; si se porta mal, quítalo y vuelves al territorio del soporte oficial. Si prefieres control total sobre los backends antes que pelear con la autodetección, esa es la diferencia de fondo que cubre llama.cpp vs Ollama.

En Windows el soporte de AMD es más limitado — revisa la lista de GPUs soportadas de Ollama para tu tarjeta antes de asumir que la instalación está rota.

¿Por qué Ollama dejó de usar la GPU después de una actualización?

Las actualizaciones cambian una de tres cosas, en este orden de probabilidad:

  1. Una librería de backend fijada. OLLAMA_LLM_LIBRARY fuerza un runner específico (cuda_v11, rocm, o incluso cpu). Es para debugging, anula la autodetección en silencio y persiste en perfiles de shell y service files mucho después de que el motivo quedó olvidado. Encuéntralo y quítalo:
systemctl show ollama --property=Environment | grep -i llm_library
env | grep OLLAMA
  1. El driver se quedó atrás del runtime. Las actualizaciones de Ollama traen un runtime de CUDA más nuevo; tu driver no se mueve hasta que tú lo muevas. Mismo arreglo que la sección del driver de arriba.
  2. El servicio es un contenedor y los flags se perdieron. Un contenedor recreado sin flags de GPU es un contenedor CPU-only. La invocación NVIDIA es:
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 ollama/ollama

Para contenedores AMD, el equivalente es passthrough de devices más añadir grupos:

docker run -d --device=/dev/kfd --device=/dev/dri \
  --group-add video --group-add render \
  -v ollama:/root/.ollama -p 11434:11434 ollama/ollama

Sin --gpus=all, sin GPU — Docker no tiene motivo para ser generoso.

¿Funciona Ollama en WSL2?

Sí, con el driver correcto en el lugar correcto: instala el driver NVIDIA de Windows, nunca un driver de Linux dentro de la distro — un driver dentro de WSL rompe el passthrough de CUDA en vez de arreglarlo. Luego actualiza WSL en sí y confirma que el device de passthrough existe:

wsl --update   # desde PowerShell
ls /dev/dxg    # dentro de WSL — debe existir para usar la GPU

Con /dev/dxg presente y un driver de Windows al día, Ollama en WSL2 hace offload a la GPU como una instalación nativa. Si prefieres saltarte la intermediación por completo, el build de Windows de Ollama corre nativo y ve la GPU sin WSL.

¿Ollama necesita una GPU para empezar?

No — una corrida solo-CPU es funcionalmente idéntica, solo más lenta, y para modelos pequeños en un CPU rápido puede ser perfectamente usable. En Apple Silicon la pregunta se disuelve: Metal usa memoria unificada automáticamente, y el único límite es cuánta RAM estés dispuesto a compartir con el modelo.

El checklist de cinco minutos

Síntoma Causa probable Arreglo
100% CPU en ollama ps, tarjeta NVIDIA presente Driver demasiado viejo para el CUDA incluido Actualiza el driver, reinicia, restart del servicio
100% CPU, AMD en Linux Falta el grupo render/video usermod -aG render,video, vuelve a entrar
100% CPU, tarjeta AMD no soportada ROCm rechaza el target gfx HSA_OVERRIDE_GFX_VERSION=10.3.0
Split 40%/60% CPU/GPU Modelo + contexto exceden la VRAM Quant más pequeño o num_ctx más corto
GPU ayer, CPU hoy OLLAMA_LLM_LIBRARY fijado o driver viejo Busca y quita la env var; actualiza el driver
GPU en corridas nativas, CPU en Docker Contenedor levantado sin flags de GPU Recréalo con --gpus=all (o devices AMD)

Revisa en este orden: ollama ps para el estado, logs del servidor para la lista de detección, luego la tabla. Nueve de cada diez veces la línea del log ya te dijo en qué fila estás.

¿El GPU vuelve a la vida? La siguiente decisión es el runtime — llama.cpp vs Ollama lo resuelve desde el registro público.