■ espacio · carril prosa

■ primero la respuesta

100% GPU — la GPU está bien, deja de leer.

40%/60% CPU/GPU split — no cupo en la VRAM, usa un quant más pequeño.

100% CPU — no se encontró GPU utilizable: driver desactualizado, grupo render/video ausente (AMD), un OLLAMA_LLM_LIBRARY fijado, o un contenedor sin flags de GPU.

LOS DOS COMANDOS

# in one terminal: load a model
ollama run llama3.2 "hello"

# in another: see where it runs
ollama ps
NAME             ID           SIZE     PROCESSOR    UNTIL
llama3.2:latest  a80c4de17cd9 3.3 GB   100% GPU     4 minutes from now

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

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

En una máquina NVIDIA sana quieres una línea como esta:

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

Ninguna línea del todo, o una que termine en mensaje de reserva solo-CPU, y has encontrado tu problema. La detección ocurre una vez al arrancar, no por petición — tras cualquier arreglo, sudo systemctl restart ollama antes de volver a comprobar.

LA TABLA DE ARREGLOS

Trabaja las causas en orden — nueve de cada diez veces la línea de log ya te dijo en qué fila estás:

SíntomaCausa probableArreglo
100% CPU, tarjeta NVIDIA presenteDriver demasiado viejo para el CUDA incluidoActualiza el driver, reinicia la máquina, reinicia el servicio
100% CPU, AMD en LinuxGrupo render/video ausenteusermod -aG render,video, vuelve a iniciar sesión
100% CPU, tarjeta AMD no soportadaROCm rechaza el objetivo gfxHSA_OVERRIDE_GFX_VERSION=10.3.0
40%/60% CPU/GPU splitModelo + contexto exceden la VRAMQuant más pequeño o num_ctx
La GPU iba ayer, la CPU hoyFijado OLLAMA_LLM_LIBRARY o driver anticuadoEncuentra y quita la variable de entorno; actualiza el driver
GPU nativa, CPU en DockerContenedor lanzado sin flags de GPURecréalo con --gpus=all (o devices de AMD)

NVIDIA: EL DRIVER, NO CUDA

El culpable habitual es el driver, no CUDA. Ollama trae sus propias librerías del runtime CUDA, así que no necesitas el CUDA toolkit — pero el runtime incluido necesita un driver bastante nuevo para hablar con él. Que nvidia-smi funcione es no es prueba: solo prueba que existe un driver, no que sea suficientemente nuevo.

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

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

# then re-detect:
sudo systemctl restart ollama

verify: journalctl -u ollama --no-pager | grep -i "inference compute" → library=CUDA

EL SPLIT: EL OFFLOAD PARCIAL ES MATEMÁTICAS, NO UN FALLO

Los pesos del modelo más el cache KV deben caber en la VRAM. Mismo modelo, contexto más grande — el cache crece más que la tarjeta y el resto se derrama a la CPU:

Tres maneras de cerrar la brecha, la más barata primero: un quant más pequeño (Q8 → Q4 parte los pesos a la mitad por un coste de calidad modesto); un contexto más corto (num_ctx domina el tamaño del cache — 32K en una tarjeta de 8 GB significa que la mayoría de las capas se quedan en CPU); y menos capas de GPU — la opción num_gpu pone un tope a los offloads, y bajarla por debajo del número de capas garantiza un split. Si alguien la puso en un Modelfile o una llamada a la API, quítala. Otra trampa más: 100% GPU pero sigue lento — el modelo anda haciendo swap sobre la RAM del sistema; contrasta ollama ps SIZE contra tu VRAM real.

AMD EN LINUX: TRES COSAS COMPROBABLES

1. ROCm en el binario — el script de instalación oficial lo incluye. Confirma lo que el servidor detectó: journalctl -u ollama --no-pager | grep -iE "rocm|inference compute".

2. Pertenencia al grupo — el runtime exige /dev/kfd + /dev/dri, o sea los grupos render/video:

sudo usermod -aG render,video $USER
# log out and back in, then:
sudo systemctl restart ollama

El grupo ausente es el post «Ollama no usa GPU en Ubuntu» más repetido en todos los foros — el driver nunca fue el problema.

3. Una GPU soportada — o un rodeo. Las tarjetas de consumo RDNA2 no soportadas (gfx1031, gfx1032) fallan la detección incluso con una pila ROCm funcionando. El rodeo estándar es disfrazarse de tarjeta soportada: sudo systemctl edit ollama, luego:

[Service]
Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"

Después reinicia. No soportado pero muy usado — si se porta mal, quítalo. En Windows, el soporte de AMD es más estrecho; revisa la lista de GPUs soportadas de Ollama antes de dar por rota la instalación.

verify: journalctl -u ollama --no-pager | grep -iE "rocm|inference compute" → tu objetivo gfx listo

«AYER FUNCIONABA»

Las actualizaciones cambian una de estas tres cosas, por orden de probabilidad:

  1. Una librería de backend fijada. OLLAMA_LLM_LIBRARY fuerza un runner (cuda_v11, rocm, incluso cpu) y gana por encima de la autodetección en silencio. Es un interruptor de depuración que persiste en perfiles de shell y archivos de servicio mucho después de que se olvide el motivo. Encuéntralo: systemctl show ollama --property=Environment | grep -i llm_library y env | grep OLLAMA — luego quítalo.
  2. El driver se quedó atrás del runtime. Las actualizaciones de Ollama traen un runtime CUDA más nuevo; tu driver no se mueve hasta que lo muevas tú. El mismo arreglo que la sección del driver.
  3. El servicio es un contenedor y las flags se esfumaron. Un contenedor Docker recreado sin flags de GPU es un contenedor solo-CPU — recréalo con --gpus=all (o los devices de AMD).
■ sello honesto Probado en: ollama · RTX 3060 / 4070 · driver 535 → 570 · Ubuntu · WSL2 · Docker. Primera publicación 2026-09-16. Los tres estados de PROCESSOR, la línea de detección al arrancar y cada arreglo de la tabla son el comportamiento documentado de ollama observado en esas máquinas — tecleado desde GPUs que regresaron, no desde la imaginación.

fin de las cinco causas · nada descargado · todo local