Cómo instalar llama.cpp en tu propio equipo, y qué manda por su cuenta

Para usar llama.cpp te bajas 1 compilación ya hecha para tu equipo, o lo instalas con Homebrew, y escribes 1 comando: llama serve -hf seguido del nombre de un modelo. Él solo descarga el modelo, levanta un servidor compatible con OpenAI y abre una página de chat en tu navegador, todo en 127.0.0.1:9931 (8080 en la v0.6.0 y anteriores), y no manda nada a ningún sitio por su cuenta. Hay 2 cosas que conviene dejar puestas desde el primer día: un tamaño de contexto con -c 8192 y un CORS más estrecho con --cors-origins localhost.

Lo confesamos: de todos los programas que seguimos, este es el que más ilusión nos hace. llama.cpp es el motor que está en el fondo de todo, el código en C/C++ sobre el que se construyen la mayoría de los programas de IA local, y usarlo a pelo es como quitarle la tapa al reloj para ver los engranajes. También es lo que más rápido cambia de todo lo que cubrimos. Esta página usa la versión estable, la v0.7.0, publicada el 15 de octubre de 2026, y la compilación diaria b11321, publicada el 1 de octubre de 2026 a las 14:09 UTC. Cada valor de fábrica que aparece aquí lo leímos en el código de la b11321 y de la v0.5.0, y lo volvimos a comprobar en el código de la v0.6.0 el 6 de octubre de 2026 y en el de la v0.7.0 el 16 de octubre de 2026: solo ha cambiado el puerto, que pasa del 8080 al 9931. También arrancamos la compilación oficial para Linux en nuestro propio servidor para ver qué hace.

llama.cppFicha del programa→

Qué es llama.cpp y el nuevo comando llama

llama.cpp ejecuta modelos de lenguaje guardados en ficheros GGUF, un formato que creó este mismo proyecto, en casi cualquier hardware: Apple Silicon a través de Metal, NVIDIA a través de CUDA, AMD a través de ROCm o Vulkan, Intel a través de SYCL u OpenVINO, y procesadores normales y corrientes sin ayuda de nadie. Es código abierto con licencia MIT, y el motor, el servidor y la interfaz web viven en 1 solo repositorio. La ficha llama.cpp: qué manda a casa y si lo puedes auditar se ocupa de la auditoría; esta guía es la parte de mancharse las manos.

El gran cambio de 2026 es un único ejecutable que se llama llama. Estos son los subcomandos que enseña:

• llama serve: el servidor HTTP, con la API compatible con OpenAI y la interfaz web.
• llama cli: un chat en la terminal.
• llama download: se trae un modelo sin arrancar nada más.
• llama version, llama licenses y llama help. llama help all enseña además bench, quantize, perplexity y unos pocos más.

Los clásicos llama-server y llama-cli siguen en el paquete de Linux que desempaquetamos, al lado de llama, así que las instrucciones de antes siguen funcionando. En la b11321, llama --version imprime 0.5.0-dev (build 11321, commit b0aca3c65): una compilación diaria es la versión estable más todo lo que se ha incorporado desde entonces.

Si prefieres hacer clic a escribir comandos, Cómo instalar LM Studio y su servidor local, y qué manda por su cuenta y Cómo instalar Ollama en local y ver qué manda por su cuenta te llevan a la primera respuesta con menos decisiones por el camino. llama.cpp es para cuando quieres tener a mano todos los mandos.

Estable o diaria: qué versión te da cada instalador

llama.cpp tiene 2 canales. El estable lleva etiquetas como v0.7.0; el diario publica una compilación numerada, bNNNNN, cada vez que se mueve la rama principal. Entre el 30 de septiembre a las 10:32 UTC y el 1 de octubre a las 14:09 UTC salieron 30. Cada instalador sigue un canal distinto, y el 1 de octubre de 2026 daban esto:

Instalador	Comando	Versión el 1 de octubre de 2026
Homebrew (Mac y Linux)	brew install llama.cpp	0.5.0, el canal estable
Script de llama.app (Mac y Linux)	curl -fsSL https://llama.app/install.sh | sh	b11200, una compilación diaria
winget (Windows)	winget install llama.cpp	b11193, una compilación diaria
Versiones de GitHub (todos los sistemas)	descargar y desempaquetar	b11321, la compilación diaria que sigue esta guía; la v0.5.0 apunta a la compilación b11146

API de fórmulas de Homebrew, manifiestos de paquetes de winget, script de instalación de llama.app y API de versiones de GitHub, leídos el 1 de octubre de 2026 entre las 14:52 y las 14:59 UTC. El 6 de octubre de 2026 Homebrew ya servía la 0.6.0, la estable publicada el día antes, y desde el 16 de octubre de 2026 sirve la 0.7.0.

Homebrew es el camino tranquilo: te da la versión estable, con paquetes para Apple Silicon y para Linux en x86_64 y arm64. El script de llama.app es el que el README del propio proyecto pone ahora en primer lugar. Descarga unos pequeños programas de sondeo que buscan CUDA, luego ROCm, luego Vulkan, y si no encuentran nada se quedan con el procesador; instala la compilación que corresponde en ~/.llama-app y la copia a ~/.local/bin/llama. En un Mac busca chips del M1 al M5 (y el A18); en un Mac con Intel, el script se detiene con No prebuilt llama binary is available for your system, es decir, que no hay binario hecho para tu equipo. Además, es la única instalación en la que funciona llama update, y funciona volviendo a ejecutar ese mismo script. winget reparte compilaciones diarias, no el canal estable.

Qué compilación descargar para tu equipo

La compilación b11321 de GitHub trae 35 ficheros. Casi todo el mundo necesita exactamente 1:

Tu equipo	El fichero que tienes que coger (b11321)	Tamaño
Mac con Apple Silicon	llama-b11321-bin-macos-arm64.tar.gz, con Metal incluido	11,8 MB
Linux con tarjeta NVIDIA	llama-b11321-bin-ubuntu-cuda-13.4-x64.tar.gz (o cuda-12.8-x64), más su fichero de bibliotecas cudart-…	152,2 MB + 440,2 MB
Windows con tarjeta NVIDIA	llama-b11321-bin-win-cuda-13.4-x64.zip (o cuda-12.4-x64), más cudart-llama-bin-win-cuda-13.4-x64.zip	152,8 MB + 423,5 MB
GPU de AMD, Intel u otras	la compilación vulkan: ubuntu-vulkan-x64 o win-vulkan-x64. Hay compilaciones con ROCm 10.0 para Linux y Windows	31,5 MB / 33,2 MB
Sin GPU que sirva	ubuntu-x64 o win-cpu-x64	17,5 MB / 19,3 MB

Nombres y tamaños de los ficheros adjuntos a la versión b11321 en GitHub, leídos el 1 de octubre de 2026.

La compilación para Mac con Intel existe, pero el proyecto la compila con Metal desactivado, así que en un Mac con Intel llama.cpp funciona solo con el procesador. Si estás eligiendo entre nuestros equipos, estos son los 3 que usamos en los ejemplos de más abajo:

PC con RTX 4060 8 GBFicha del equipo→ PC con RTX 3060 12 GBFicha del equipo→ Mac con M4 y 16 GB unificadosFicha del equipo→

Desempaqueta el fichero, abre una terminal en esa carpeta y ejecuta ./llama --version. En Linux, las bibliotecas van en la misma carpeta que el programa; nosotros arrancamos la compilación para CPU desde su propia carpeta, con LD_LIBRARY_PATH apuntando ahí. Si te apetece ver a alguien hacer una instalación de principio a fin antes de lanzarte, este vídeo es buena compañía. Los comandos cambian con cada compilación: donde el vídeo y esta página no coincidan, esta página sigue la compilación b11321.

Tu primer modelo: llama serve -hf y llama cli

El comando que da el README del proyecto:

llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

-hf recibe un repositorio de Hugging Face, y si quieres, una compresión detrás de dos puntos, como :Q4_K_M. Si no le dices ninguna, llama.cpp elige Q4_K_M, la misma compresión que usan nuestros tamaños de modelo, o el primer fichero del repositorio si no hay Q4_K_M. Si el modelo tiene parte de visión, se trae también su fichero mmproj (--no-mmproj se lo salta). Después abre http://127.0.0.1:9931 en el navegador y ahí tienes la página de chat. Esa es la dirección de la estable v0.7.0 y de las compilaciones diarias desde la b11521 (9 de octubre de 2026). La v0.6.0 y anteriores, y las diarias más antiguas como la b11321 de la tabla de arriba, escuchan en el 8080, igual que una instalación de Homebrew anterior al 16 de octubre de 2026, que te daba la 0.6.0: con ellas, abre http://127.0.0.1:8080, o arranca con --port 9931 y todas las direcciones de esta página te valen tal cual.

Si prefieres charlar en la terminal:

llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF

Y para comprobar la API desde otra terminal:

curl http://127.0.0.1:9931/health
curl http://127.0.0.1:9931/v1/models

Para un cliente de OpenAI, la URL base es http://127.0.0.1:9931/v1.

Sin ningún modelo, llama serve arranca igual. Lo probamos: imprimió starting server in router mode. models will be automatically loaded on-demand (arranca en modo router y carga los modelos según se le pidan), listó los modelos que ya tenía en su caché (0, en una cuenta recién creada) y los cargaba cuando se le pedían, hasta 4 a la vez de fábrica. También imprimió router mode enabled – do not expose to untrusted environments, que viene a decir que no lo expongas en entornos de los que no te fías. Es un buen consejo, y el apartado de seguridad lo convierte en comandos.

Si llama.cpp se para con un error, aquí o más adelante, nuestra guía de errores de llama.cpp repasa 8 uno a uno, cada uno con el mensaje exacto que vas a ver y su arreglo.

La memoria: el contexto completo de fábrica, y qué hace --fit con él

Este es el valor de fábrica que pilla a la gente por sorpresa. El tamaño de contexto de llama.cpp, -c, vale 0 de fábrica, que significa loaded from model: el que diga el modelo, es decir, el contexto más largo para el que se entrenó. En qwen3-4b-2507 son 262.144 tokens.

Lo que pasa cuando eso no cabe es distinto de vLLM, que directamente se niega a arrancar. llama.cpp tiene --fit, activado de fábrica, que ajusta todo lo que no hayas fijado tú, en este orden: primero recorta el contexto, hasta un suelo de 4.096 tokens; después decide cuántas capas van a la GPU y pone el resto en la RAM del sistema, dejando 1.024 MiB libres en cada dispositivo. -ngl, el número de capas en la GPU, vale auto de fábrica, lo que deja esa decisión en manos de --fit, y la flash attention, -fa, también vale auto.

Así que el servidor arranca, pero no necesariamente con el contexto que esperabas, y quizá con parte del modelo en el procesador, que va más lento. La solución es decirle lo que quieres:

llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF -c 8192

Nuestro buscador de modelos y nuestras fichas de equipo lo calculan todo con 8.192 tokens, así que con -c 8192 llama.cpp cuadra con las cifras de nuestra web. Esta es la diferencia en nuestros 3 equipos de ejemplo, con cada modelo en Q4_K_M:

Equipo (memoria para el modelo)	Modelo	Necesita a 8.192 tokens	Necesita en el máximo del propio modelo	Contexto más largo que cabe (caché de 16 bits)
RTX 4060 8 GB (7,20 GiB)	qwen3-4b-2507	4,20 GiB	43,73 GiB a 262.144 (36,0 GiB de ellos, caché)	16.384
RTX 4060 8 GB (7,20 GiB)	qwen3-8b	6,56 GiB, justo	11,66 GiB a 40.960	8.192
RTX 3060 12 GB (11,20 GiB)	gemma4-12b	7,82 GiB	16,35 GiB a 262.144	65.536
Mac con M4, 16 GB (13,00 GiB)	gpt-oss-20b	11,77 GiB, justo	16,83 GiB a 131.072	32.768

Cálculo propio con el motor que hay detrás de nuestro buscador de modelos: fichero del modelo en Q4_K_M, más la caché KV según la disposición real de atención de cada modelo, más la memoria de trabajo; datos de modelos del 30 de septiembre (del 15 de octubre en gemma4-12b) y de equipos del 1 de octubre de 2026. El «contexto más largo» es el mayor de 4.096, 8.192, 16.384… hasta el máximo del modelo que todavía cabe. No es el algoritmo --fit del propio llama.cpp, que además puede pasar capas a la RAM.

qwen3-4b-2507Ficha del modelo→ gemma4-12bFicha del modelo→

Ninguno de los 4 modelos cabe en su máximo en el equipo de su fila. Pide el contexto completo en una 4060 con qwen3-4b-2507 y necesitaría más de 5 veces la tarjeta (un modelo de 4B con ínfulas de centro de datos, el pobre).

Si prefieres que llama.cpp te avise en vez de decidir por ti, --fit off apaga el ajuste y -ngl all pide todas las capas en la GPU. Pedir -c 0 de forma explícita también desactiva el recorte de contexto: o te da el contexto completo, o las capas se van a la RAM.

Cómo cerrarlo: CORS abierto, sin clave y un puerto nuevo

De fábrica, llama serve escucha solo en 127.0.0.1, en el puerto 9931 (8080 en la v0.6.0 y anteriores). Lo comprobamos en el socket de nuestro servidor: nada en las demás interfaces de red. Esa es la buena noticia, y coloca a llama.cpp junto a Ollama, LM Studio y MLX, no junto a vLLM.

Lo demás pide que estés atento:

• Sin clave. Cualquiera que llegue al puerto puede usarlo.
• El CORS refleja cualquier origen, con credenciales. Mandamos una petición con la cabecera Origin: https://some-site.example y el servidor contestó Access-Control-Allow-Origin: https://some-site.example y Access-Control-Allow-Credentials: true. Dicho en cristiano: una página web que abras en tu navegador puede mandar peticiones a tu servidor local y leer las respuestas mientras la tengas abierta. El propio servidor lo avisa al arrancar: security: no API key is set and CORS allows all origins, o sea, que no hay clave y que el CORS deja pasar cualquier origen.
• La página de chat está encendida de fábrica, en el mismo puerto.

Lo que lo cierra:

export LLAMA_API_KEY="una-cadena-larga-y-aleatoria"
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF -c 8192 --cors-origins localhost

• --cors-origins localhost solo deja que le hablen páginas servidas desde localhost. También vale una lista de orígenes exactos separados por comas.
• LLAMA_API_KEY, o --api-key, obliga a los clientes a mandar la clave como token Bearer. Con la variable, la clave no aparece en la lista de procesos. --api-key-file lee varias claves de un fichero.
• --no-ui apaga la página de chat si solo quieres la API.

El puerto. El cambio que anunciaba el servidor ya está también en el canal estable: el puerto de fábrica es el 9931 en la v0.7.0, publicada el 15 de octubre de 2026, y en las compilaciones diarias desde la b11521 (9 de octubre). La v0.6.0 y las compilaciones anteriores escuchan en el 8080, y al hacerlo imprimen notice: server default port will be changed to :9931 in a future release; desde la b11521 ese aviso ya no sale. Desde el 16 de octubre de 2026 Homebrew instala la 0.7.0: si aún tienes la 0.6.0 de antes, brew upgrade te lleva del 8080 al 9931. Las imágenes de Docker del proyecto mantienen el 8080 dentro del contenedor. Si tus scripts dependen del 8080, escribe --port 8080 en ellos y ninguna actualización te lo moverá. --host acepta también la ruta de un socket UNIX acabada en .sock y, desde la v0.5.0, varias direcciones separadas por comas.

Qué manda llama.cpp por su cuenta, y qué sale cuando tú se lo pides

Por su cuenta: nada. Buscamos bibliotecas de analítica, telemetría y seguimiento en el código de la compilación b11321 que forma el motor, el servidor, el cliente de terminal y la interfaz web, y no encontramos ninguna. Las direcciones escritas en ese código son enlaces que aparecen en mensajes y textos de ayuda, más los servicios de la lista de abajo, y a cada uno de ellos solo se llama cuando tú das la orden. Cuando arrancamos el servidor sin modelo y con una carpeta personal vacía, su registro no mostró ninguna petición de salida y la carpeta siguió vacía. Eso es lo que leímos y lo que vimos en el registro; no capturamos el tráfico de red.

Lo que sale cuando se lo pides:

• Las descargas de modelos, con -hf, --model-url o llama download, van a huggingface.co. La petición identifica al programa como llama-cpp/ más el número de compilación y el commit, y lleva tu HF_TOKEN si tienes uno configurado.
• Los modelos empaquetados como imágenes de contenedor, solo con --docker-repo, van al registro de Docker.
• llama update, solo en instalaciones hechas con el script de llama.app, descarga y vuelve a ejecutar ese script.

Dónde van los modelos. A la caché estándar de Hugging Face, ~/.cache/huggingface/hub, con la misma estructura de carpetas que usan las herramientas de la propia Hugging Face, así que un modelo que ya descargaste con otro programa no se descarga dos veces. LLAMA_CACHE, HF_HUB_CACHE o HF_HOME la cambian de sitio. Cuando ya tengas ahí tus modelos, --offline (o LLAMA_ARG_OFFLINE=1) obliga a llama.cpp a tirar de la caché y le impide salir a la red.

Dónde van los chats. La página de chat guarda tus conversaciones en el almacenamiento de tu navegador, no en una carpeta del servidor, según nuestra auditoría de la ficha. Si borras los datos del sitio en el navegador, se borran con ellos. La caché de prompts del servidor vive en la RAM, con 8.192 MiB como máximo de fábrica, y no se escribe en disco salvo que se lo pidas.

En este orden acabas con un llama.cpp que funciona y está cerrado:

1. Elige tu canal: brew install llama.cpp para la versión estable, o la compilación exacta para tu equipo desde la página de versiones de GitHub.
2. Compruébalo con llama --version y apunta el número de compilación.
3. Pon LLAMA_API_KEY antes del primer llama serve.
4. Arranca con -c 8192 --cors-origins localhost, y añade --port 8080 si algo depende del puerto antiguo (desde la v0.7.0, el de fábrica es el 9931).
5. Si el modelo entra justo, añade -ctk q8_0 -ctv q8_0 antes de bajar el contexto.
6. Cuando tengas los modelos descargados, añade --offline.

Las otras guías de esta serie cubren Cómo instalar MLX en un Mac con mlx-lm, y qué manda por su cuenta y Cómo instalar vLLM en tu propio equipo, y qué manda por su cuenta, y los 5 programas se comparan uno al lado del otro en 5 programas de IA local: telemetría, llamadas y auditoría. Si dudas entre llama.cpp y Ollama, que arranca por dentro el propio servidor de llama.cpp, nuestra comparativa llama.cpp vs Ollama pone sus ajustes de fábrica uno al lado del otro.