Ollama error 500 «unable to load model»: por qué pasa y qué hacer

Cómo se ve el error

El texto cambia según la versión, la causa y desde dónde llames a Ollama, pero siempre empieza por 500. En la terminal suele aparecer como «Error: 500 Internal Server Error:» seguido de un detalle: «unable to load model:» con la ruta del archivo del modelo, o «llama-server process has terminated: exit status 1», como en este informe de Windows en GitHub. Nuestro script, que llamaba a la API, solo recibió «HTTP Error 500: Internal Server Error», sin más pistas.

Todas esas variantes dicen lo mismo: el modelo no llegó a cargarse. El porqué no está en ese mensaje.

Encuentra la causa en server.log

Con la aplicación de Ollama, el registro está en %LOCALAPPDATA%\Ollama\server.log y los anteriores se guardan como server-1.log, server-2.log… Si necesitas más detalle, cierra la aplicación y arráncala con OLLAMA_DEBUG=1 (solución de problemas de Ollama). Busca la última línea «Load failed» y lee lo que hay justo encima: ahí aparece si faltó memoria, si el formato no se reconoce o si falló CUDA.

Nuestro caso: un modelo de 35B en una gráfica de 16 GB

Descargamos qwen3.6:35b (22 GB en disco) en un PC con Windows 11, RTX 5060 Ti de 16 GB y 31,3 GB de RAM, de los que en ese momento había 9,3 GB libres. El registro lo calculó claro: «projected to use 20912 MiB of device memory vs. 15172 MiB of free device memory» y «need to reduce device memory by 7650 MiB». Ollama lo repartió solo: 12,4 GB en la GPU y 8,3 GB en la RAM.

La primera carga, con contexto 4.096, respondió. Las siguientes, con 8.192 y después otra vez con 4.096, acabaron en error 500. El registro mostraba un fallo de CUDA durante el calentamiento del modelo, «CUDA error: shared object initialization failed», dentro de una función de flash attention, y el proceso terminó con el código 0xc0000409.

Probamos las dos salidas que más se recomiendan. Desactivar flash attention (OLLAMA_FLASH_ATTENTION=0; el registro confirmó «flash_attn = disabled») y forzar 20 capas en GPU (num_gpu 20; el registro dijo «offloaded 20/42 layers to GPU»). Las dos fallaron con el mismo «CUDA error» en ggml-cuda.cu:110. No aislamos una causa única: en este equipo y con esta versión, el 35B no fue utilizable, y los modelos de 4–12B funcionaron sin problemas. Los datos están en el experimento velocidad y VRAM en una RTX 5060 Ti.

Qué significa 0xc0000409 (y por qué no es un ataque)

Windows acompaña ese código de un texto que alarma: «The system detected an overrun of a stack-based buffer in this application». No quiere decir que te hayan atacado ni, necesariamente, que haya habido un desbordamiento. Como explica Raymond Chen, de Microsoft, ese código se usa hoy para cualquier cierre inmediato («fail fast») de un programa que detecta un error grave, incluido el que provoca abort() (STATUS_STACK_BUFFER_OVERRUN doesn’t mean that there was a stack buffer overrun). En nuestro caso, llama-server se cerró a sí mismo tras el error de CUDA.

Qué hacer, en este orden

Cambia una sola cosa cada vez y prueba de nuevo; si cambias tres, no sabrás cuál lo arregló.

• Libera memoria: ollama ps para ver qué hay cargado, ollama stop <modelo> para descargarlo y cierra juegos o editores de vídeo. nvidia-smi te dice cuánta VRAM queda.
• Baja el contexto: dentro de ollama run, /set parameter num_ctx 2048; por la API, "options": {"num_ctx": 2048}. Si con menos contexto carga, el problema era de memoria.
• Pon menos capas en GPU: /set parameter num_gpu 20. A nosotros no nos sirvió, pero resuelve los casos en que la gráfica justo no llega.
• Desactiva flash attention para descartarla: $env:OLLAMA_FLASH_ATTENTION = "0"; ollama serve.
• Actualiza Ollama (ollama -v para ver tu versión). Un modelo de arquitectura reciente puede no cargar en una versión antigua.
• Ruta sin caracteres raros: si tu usuario de Windows tiene tildes, eñes u otros alfabetos, mueve los modelos con [Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "C:\ollama-modelos", "User"), reinicia Ollama y vuelve a descargarlos. Fue la solución en el informe de GitHub citado arriba.
• Descarga limpia: ollama rm <modelo> y ollama pull <modelo>, por si el archivo está dañado.
• Modelo más pequeño o más cuantizado. Antes de comprar hardware para un modelo, pruébalo: nosotros no conseguimos usar el 35B en 16 GB.

Cómo comprobar que ha quedado arreglado

Que cargue una vez no basta: en nuestro caso, la primera carga funcionó y las siguientes no. Carga el modelo, descárgalo con ollama stop y repítelo dos o tres veces, con el contexto que vayas a usar de verdad. Después confirma con ollama ps que está cargado y dónde (columna PROCESSOR) y que en server.log no hay ningún «Load failed» nuevo desde la hora de la prueba. Si PROCESSOR muestra un reparto entre CPU y GPU, funcionará, pero lento: lo explicamos en Ollama no usa la GPU en Windows.

Casos raros

• Modelos GGUF descargados de Hugging Face: pueden traer metadatos o una arquitectura que tu versión de Ollama no reconoce, y el registro lo dirá al cargar. Actualiza o usa la versión de la biblioteca de Ollama.
• Modelos con visión: cargan un segundo archivo (el proyector de imágenes). En nuestro 35B el registro estimó 1.134 MiB solo para él. Si es ese archivo el que falla, el registro lo nombra.
• Error 500 que no tiene nada que ver con cargar: si falla OpenCode u otro agente y el modelo sí carga, el problema puede ser el contexto. Ver OpenCode con Ollama no funciona.
• La memoria que cuenta es la libre, no la instalada: el escritorio de Windows ya ocupaba unos 3 GB de VRAM en reposo. Más en IA local en Windows: RAM, VRAM y cuantización.

Preguntas frecuentes

¿El error 500 de Ollama siempre es falta de memoria? No. Es el aviso genérico de que el modelo no cargó. Puede ser memoria, una versión que no reconoce el modelo, una ruta con caracteres no ASCII, un archivo dañado o un fallo de CUDA como el nuestro. Solo server.log lo dice.

¿Qué hago con «timed out waiting for server to start»? Significa que la carga tardó más de lo permitido, algo típico de modelos grandes repartidos entre GPU y RAM o de discos lentos. Libera memoria y prueba un modelo más pequeño. El límite lo fija OLLAMA_LOAD_TIMEOUT, que según la ayuda de ollama serve es el tiempo que se permite a una carga atascada antes de abandonarla; en nuestro registro valía 5m0s. No lo hemos reproducido.

¿Y «context deadline exceeded»? Es un tiempo de espera agotado en la petición: el cliente se cansó de esperar a que el modelo cargara o respondiera. Las causas y los arreglos son los mismos que los de la pregunta anterior.

¿LM Studio da «unable to allocate CUDA0 buffer»? Es el mismo fondo: no hay VRAM libre para lo que se pide. Baja las capas en GPU o el contexto al cargar el modelo. LM Studio no entró en nuestras pruebas.