¿llama.cpp no funciona? 8 errores, su mensaje exacto y el arreglo

Cuando llama.cpp falla, el registro suele señalar al culpable: un puerto ocupado (el 8080 o el 9931, según la versión), una compilación sin soporte para la GPU, un modelo más nuevo que tu versión, un fichero que no es GGUF, la memoria que se acaba, un contexto demasiado grande, una plantilla de chat que no sabe leer o una opción vieja de CMake. Aquí van los 8, con su arreglo.

llama.cpp es el motor que llevan dentro muchos programas de IA local, y usarlo a pelo es como levantar el capó: control total, cada opción en tus manos. El precio es que, cuando algo se tuerce, nadie te traduce el mensaje. Hemos comprobado cada mensaje de esta página el 15 y el 16 de octubre de 2026 contra el código de llama.cpp v0.7.0, la versión estable del 15 de octubre (compilación b11669), y contra el de la compilación diaria b11658. No hemos provocado estos errores hoy en una máquina: salen directamente del código, línea a línea. Cómo instalarlo y cargar el primer modelo está en nuestra guía para instalar llama.cpp; esta página empieza donde acaba aquella.

llama.cppFicha del programa→

«couldn’t bind HTTP server socket»: el puerto está ocupado (¿y cuál es el puerto?)

Arrancas el servidor y se para en el acto con esto:

… start: couldn't bind HTTP server socket, hostname: 127.0.0.1, port: 9931

Hay otra cosa escuchando ya en esa dirección y ese puerto: una segunda copia de llama.cpp que se te quedó olvidada en otra terminal, un programa que usa el mismo puerto o la ejecución anterior, que todavía no ha terminado de cerrarse. El arreglo es parar el otro proceso o elegir otro puerto con --port 8081 (vale cualquier número libre).

Y aquí viene el giro que está pillando a más de uno este mes. El puerto por defecto ha cambiado. Hasta la v0.6.0, la que instalaba Homebrew antes del 16 de octubre de 2026, el servidor escucha en el 8080. Desde la compilación diaria b11521 (9 de octubre de 2026), y en la estable v0.7.0 (15 de octubre), escucha por defecto en el 9931. Si instalaste una compilación diaria o la v0.7.0 (también con brew install o brew upgrade desde el 16 de octubre), el marcador de tu navegador y cualquier aplicación que apunte a http://127.0.0.1:8080 llaman ahora a una puerta donde no hay nadie, y el error no te lo dice. Tienes 2 salidas: arrancarlo con --port 8080 para conservar la dirección de siempre, o cambiar tus aplicaciones al 9931. Cuando termina de cargar el modelo, el registro muestra una línea como listening on http://127.0.0.1:9931: fíate de esa línea, no de tu memoria.

En Linux, ss -ltnp | grep 9931 (o 8080) te enseña quién tiene el puerto; en macOS, lsof -i :9931; en Windows, netstat -ano | findstr 9931.

«warning: no usable GPU found, --gpu-layers option will be ignored»

Le has pedido capas en la tarjeta con -ngl y llama.cpp te contesta:

warning: no usable GPU found, --gpu-layers option will be ignored
warning: one possible reason is that llama.cpp was compiled without GPU support
warning: consult docs/build.md for compilation instructions

El mensaje es sincero: casi siempre estás usando una compilación solo para CPU. llama.cpp publica un paquete distinto para cada acelerador: CPU, CUDA, Vulkan, ROCm, SYCL y OpenVINO en Windows y Linux, y Metal en los Mac con Apple silicon. Si bajaste el zip «cpu», la tarjeta es invisible por diseño. Descarga el paquete que corresponde a tu tarjeta (en NVIDIA, el de CUDA junto con su paquete cudart correspondiente), o vuelve a compilar con la opción correcta (lo verás en la sección de CMake, más abajo).

Cuando ve la tarjeta, el registro lo dice pronto, con una línea como ggml_cuda_init: found 1 CUDA devices (Total VRAM: …). ¿No sale esa línea y tampoco el aviso? Entonces no pasaste -ngl (su valor por defecto es auto), así que el aviso no tuvo ocasión de salir, y lo más probable es que estés usando una compilación solo para CPU. Arráncalo una vez con -ngl all: si la compilación no tiene soporte para la GPU, el aviso de arriba te lo dirá.

Hay 2 casos en los que ni el paquete correcto basta. En un Mac con Intel, el binario oficial viene compilado sin Metal, así que solo tira de la CPU. Y en una tarjeta AMD, el paquete de CUDA solo tira de la CPU: necesitas el paquete de ROCm o el de Vulkan.

«unknown model architecture»: el modelo es más nuevo que tu versión

El modelo se descarga y, al cargarlo, todo se para con:

llama_model_load: error loading model: unknown model architecture: 'xxxx'

seguido de failed to load model. El fichero GGUF dice a qué familia pertenece el modelo, y tu versión todavía no conoce esa familia. No es un fichero roto: es un problema de calendario. llama.cpp añade soporte para familias nuevas casi cada semana, y un modelo que salió el martes pasado necesita una compilación posterior al martes pasado.

El arreglo es actualizar. Con llama.cpp publicando unas 16 compilaciones al día de media (481 en los 30 días hasta el 23 de octubre de 2026), «la última» es un blanco móvil, y aquí eso es buena noticia: lo más probable es que la compilación que conoce tu modelo ya exista. Con Homebrew te llega el canal estable, que puede ir unas semanas por detrás de las diarias; si el modelo es muy nuevo, coge una compilación diaria de la página de versiones o del instalador. Si ni la compilación más reciente conoce el nombre, el modelo todavía no está soportado: mientras tanto, elige otra cuantización de una familia soportada.

«invalid magic characters … expected ‘GGUF’» o «failed to load model»

Este es corto:

gguf_init_from_reader: invalid magic characters: 'xxxx', expected 'GGUF'

Todo fichero GGUF empieza con las 4 letras GGUF. Si no están, llama.cpp no está leyendo un GGUF. Los sospechosos habituales: le has dado un fichero .safetensors o una carpeta entera de Hugging Face (llama.cpp solo carga GGUF), guardaste la página de descarga en vez del fichero o la descarga se cortó a medias. Si lo que te sale es failed to read magic, el fichero está vacío o no existe.

Los genéricos failed to load model from … y failed to load model '…' siempre llegan con una línea más precisa justo encima: lee esa. Una ruta con una errata es una causa habitual.

La forma fácil de esquivar todo esto es dejar que llama.cpp baje el modelo por su cuenta: -hf user/model:Q4_K_M descarga el GGUF de Hugging Face a la caché compartida, con el fichero correcto, siempre.

qwen3-8bFicha del modelo→

«cudaMalloc failed: out of memory» o «failed to allocate buffer for kv cache»

En una tarjeta NVIDIA, quedarse sin memoria tiene esta pinta:

ggml_backend_cuda_buffer_type_alloc_buffer: allocating … MiB on device 0: cudaMalloc failed: out of memory

y a veces, justo después de cargar el modelo:

failed to allocate buffer for kv cache

En un Mac, el mismo muro se lee failed to allocate Metal buffer of … bytes (out of memory). El primer número te dice cuánto intentó reservar; la causa es una de estas 3. Los pesos del modelo no caben en la tarjeta (un modelo de 14B en 8 GB, por ejemplo). La caché del contexto no cabe (de eso hablamos justo debajo). O hay otra cosa usando la tarjeta: un juego, un navegador con aceleración por hardware, otra copia de llama.cpp, Ollama en segundo plano.

Los arreglos, de más fácil a más difícil: cierra los otros programas; baja el contexto con -c 8192; deja menos capas en la tarjeta con un -ngl más pequeño (el resto va a la RAM, más lento pero funciona); guarda la caché en 8 bits con -ctk q8_0 -ctv q8_0; o pásate a una cuantización más pequeña del mismo modelo. El buscador de modelos te dice de antemano qué modelo y qué cuantización caben en tu tarjeta con el contexto que quieres.

«failed to fit params to free device memory»: el contexto por defecto es el máximo del modelo

Este es el problema que no parece un problema. llama.cpp arranca, responde y, aun así, algo no cuadra: va más lento de lo esperado, o un documento largo vuelve con request (… tokens) exceeds the available context size (… tokens), try increasing it. La culpa es del contexto por defecto. De serie, llama.cpp carga el contexto completo con el que se entrenó el modelo (-c 0 significa justo eso), y luego un mecanismo llamado --fit, activado por defecto, lo ajusta todo a la memoria libre: primero encoge el contexto, hasta un suelo de 4.096 tokens, y después pasa capas de la tarjeta a la RAM, dejando siempre 1.024 MiB libres en cada dispositivo. Cada paso se registra a nivel de traza, así que con el registro por defecto no ves el porqué; solo ves el resultado, en una línea como n_ctx_seq (32768) < n_ctx_train (40960) -- the full capacity of the model will not be utilized. Si el propio ajuste falla, te sale un aviso:

failed to fit params to free device memory: …

La cura es decidir tú el contexto en vez de dejar que --fit decida por ti. Elige el contexto que necesita tu tarea (8.192 tokens dan de sobra para chatear; los documentos largos piden más), escríbelo con -c y, si quieres más en la misma tarjeta, añade -ctk q8_0 -ctv q8_0, que reduce la caché casi a la mitad. Nuestra guía para instalar llama.cpp y la ficha de la RTX 3060 usan la misma calculadora.

PC con RTX 3060 12 GBFicha del equipo→

«chat template parsing error»: la plantilla del modelo no se deja leer

El modelo carga, pero el servidor se para antes de empezar a escuchar, y el registro dice:

… init: chat template parsing error: …
please consider disabling jinja via --no-jinja, or use a custom chat template via --chat-template
for example: --no-jinja --chat-template chatml

Justo después sale exiting due to model loading error. Cada modelo trae su propia receta para convertir una conversación en texto, y llama.cpp la lee con su motor Jinja, ahora activado por defecto (la vieja opción --jinja ya no hace falta). Algunos ficheros GGUF llevan plantillas con construcciones que todavía no sabe leer. El mensaje te da las 2 salidas: --no-jinja vuelve a las plantillas integradas, y --chat-template chatml (u otro nombre integrado) fuerza una. Si el mismo modelo funciona en una compilación más nueva, mejor actualiza: el soporte de plantillas mejora casi tan rápido como el de modelos.

Las respuestas que parecen un galimatías, que repiten los nombres de los roles o que no paran nunca son de la misma familia de problemas, solo que sin error: prueba primero un GGUF del repositorio oficial del modelo.

Para ver qué le manda de verdad la plantilla al modelo, el propio servidor te lo puede enseñar. En este vídeo, un desarrollador abre la interfaz web integrada del servidor, activa el registro detallado y lee el prompt exacto que recibe el modelo una vez aplicada la plantilla:

CMake: «LLAMA_CUBLAS is deprecated, use GGML_CUDA instead»

Si compilas llama.cpp tú mismo con una receta antigua, CMake se para en el primer paso:

LLAMA_CUBLAS is deprecated, use GGML_CUDA instead

Este sí es un error en toda regla: la compilación no sigue. Las opciones de GPU pasaron del prefijo LLAMA_ a GGML_ hace ya tiempo, y los comandos de compilación antiguos siguen usando los nombres viejos. El comando moderno para NVIDIA es cmake -B build -DGGML_CUDA=ON y después cmake --build build --config Release. Los otros nombres antiguos (LLAMA_CUDA, LLAMA_METAL, LLAMA_NATIVE, LLAMA_SYCL…) todavía funcionan, con un aviso como LLAMA_CUDA is deprecated, use GGML_CUDA instead; cámbialos antes de que dejen de funcionar también.

Ya puestos: las compilaciones antiguas también llamaban a los programas main y server. Esos nombres ya no existen. El paquete de hoy trae llama, con llama serve y llama cli, y sigue incluyendo llama-server y llama-cli por separado. Si un script falla con «command not found», casi siempre es solo eso.

Y si tu problema no está aquí

3 costumbres resuelven casi todo lo demás. Apunta el número de compilación antes de pedirle ayuda a nadie: muchas respuestas dependen de él. Vuelve a empezar con el modelo más pequeño que tengas y -c 4096: si así funciona, el problema es la memoria, no llama.cpp. Y prueba el mismo GGUF en un programa que lo ejecuta con llama.cpp, como Ollama o LM Studio: si allí funciona, compara opciones. Nuestra comparativa llama.cpp vs Ollama recoge los ajustes que Ollama elige por ti, como el contexto y las peticiones a la vez. Nuestras guías para cuando Ollama no funciona y cuando vLLM no funciona cubren sus propios errores.

Si prefieres volver a empezar desde una instalación limpia, en este vídeo otro desarrollador ejecuta llama.cpp en Docker (con una imagen para la CPU y otra para tarjetas NVIDIA), desde el primer fichero GGUF hasta el servidor y su interfaz web. Está grabado con el puerto 8080 y las opciones de entonces: si algún comando del vídeo no coincide con esta página, quédate con la página.