Ollama vs llama.cpp : ¿cuál elegir en 2026? ?

#La relación real entre Ollama y llama.cpp

llama.cpp es el proyecto de C/C++ de Georgi Gerganov que ejecuta modelos de lenguaje en formato GGUF en CPU y GPU, sin dependencia de Python ni de PyTorch. Es la pieza de inferencia de referencia de todo el ecosistema local: LM Studio, KoboldCpp, Jan y Ollama se basan en él, directamente o a través de un fork.

Ollama no es, por tanto, un competidor de llama.cpp en sentido estricto: es una capa adicional. Incluye su propio motor derivado de llama.cpp y le añade un gestor de modelos, un demonio en segundo plano y una API. Cuando escribes `ollama run qwen3`, es código procedente de llama.cpp el que genera los tokens. La cuestión no es «cuál es más rápido» —con la misma cuantización y el mismo hardware, el rendimiento es muy similar—, sino «qué nivel de abstracción te conviene».

#Lo que realmente añade Ollama sobre llama.cpp

Compilar y ejecutar llama.cpp manualmente implica gestionar por tu cuenta la descarga de los GGUF, las rutas de los archivos y una larga línea de opciones. Ollama se encarga de todo eso. Esto es, concretamente, lo que aporta además del motor por sí solo:

Registro y pull

`ollama pull qwen3:8b` descarga el modelo desde ollama.com, elige una cuantización por defecto (a menudo Q4_K_M) y lo guarda en un almacén de blobs. No hace falta buscar el archivo adecuado en Hugging Face.

Daemon persistente

Un servicio se ejecuta en segundo plano y escucha en http://localhost:11434. El modelo permanece cargado en memoria entre dos peticiones (keep-alive) y se descarga de la memoria automáticamente tras un periodo de inactividad.

Descarga automática de procesamiento a la GPU

Ollama estima la VRAM disponible y distribuye las capas entre GPU y CPU sin que tengas que ajustar `-ngl`. Útil, pero a veces demasiado cauteloso.

Modelfile

Un archivo declarativo (al estilo de un Dockerfile) que fija un modelo base, un prompt de sistema, una temperatura y una plantilla de chat bajo un nombre reutilizable.

API compatible con OpenAI

Un endpoint /v1/chat/completions listo para usar, además de la API nativa /api/generate. Cualquier cliente OpenAI se conecta a él cambiando la URL base.

Por el contrario, llama.cpp te deja hacerlo todo — pero debes hacerlo todo. Debes descargar el GGUF tú mismo, escribir la línea de comando y gestionar el ciclo de vida del proceso. Es el precio del control total, que el resto de este comparativo llama.cpp vs ollama va a detallar.

#Prerrequisitos

El único factor que realmente determina qué podrás ejecutar es la memoria (RAM o VRAM en una GPU dedicada). Estas referencias para Q4_K_M se aplican a ambas herramientas, ya que el motor es el mismo:

3B ≈ 2 GB

Cabe en casi cualquier equipo, incluida una RTX 3060 de 12 GB con un margen enorme.

7B ≈ 5 GB

Funciona con holgura a partir de 8 GB de VRAM (RTX 3060, 4060).

14B ≈ 9 GB

Cabe por completo en una RTX 3060 de 12 GB o en una 4070 de 12 GB.

32B ≈ 19 GB

Requiere una RTX 4090 de 24 GB, o un offload parcial entre CPU y GPU con 16 GB.

70B ≈ 40 GB

Requiere múltiples GPUs, un Mac con memoria unificada (M4 Pro 48 GB) o un offload agresivo.

#Instalar y lanzar los dos

1. 01
   Instalar Ollama

   El script oficial instala el daemon y la CLI en una sola orden en Linux; en macOS y Windows, se proporciona un instalador gráfico en ollama.com. Una vez instalado, el servicio escucha en http://localhost:11434.
2. 02
   Iniciar un modelo con Ollama

   `ollama run qwen3:8b` descarga el modelo en el primer llamado y luego abre una sesión de chat. No hay nada más por configurar: el offload GPU, el contexto y el template se gestionan automáticamente.
3. 03
   Compilar llama.cpp

   Se clona el repositorio ggml-org/llama.cpp y se compila con CMake. La opción de backend GPU depende de tu hardware: CUDA para NVIDIA, Metal (activado por defecto) en Mac, ROCm o Vulkan para AMD.
4. 04
   Ejecutar un GGUF con llama.cpp

   `llama-cli` carga un archivo .gguf especificado explícitamente, con todos sus ajustes indicados en la línea de comandos: número de capas GPU (`-ngl`), tamaño de contexto (`-c`), hilos CPU (`-t`). No se deduce ningún ajuste por ti.

# Installer (Linux) puis lancer un modèle
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:8b

# Vérifier le daemon et lister les modèles
curl http://localhost:11434/api/tags
ollama list

# Cloner et compiler avec le backend CUDA (NVIDIA)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

# Lancer un GGUF avec 35 couches sur le GPU et 8192 de contexte
./build/bin/llama-cli -m ./qwen3-8b-Q4_K_M.gguf -ngl 35 -c 8192 -p "Bonjour"

#Benchmark sencillo de ambos con el mismo GGUF

La mejor forma de poner fin a los debates: medir ambos con el mismo archivo y en la misma máquina. llama.cpp ofrece `llama-bench`, una herramienta dedicada que aísla la velocidad de generación (tokens/segundo) y el procesamiento del prompt (prompt processing).

# Débit brut du moteur sur le GGUF, tout GPU
./build/bin/llama-bench -m ./qwen3-8b-Q4_K_M.gguf -ngl 99
# Sortie : colonnes pp (prompt) et tg (génération) en tok/s

# Importer le GGUF dans Ollama sans le re-télécharger
printf 'FROM ./qwen3-8b-Q4_K_M.gguf\n' > Modelfile
ollama create qwen3-local -f Modelfile

# Chronométrer une génération (--verbose affiche les tok/s)
ollama run qwen3-local --verbose "Explique la photosynthèse en 200 mots"

El resultado típico en 2026, con un GGUF idéntico y todas las capas en la GPU: la tasa de generación es casi idéntica, con diferencias de apenas un pequeño porcentaje. Es lógico: se utiliza el mismo núcleo de cálculo. Las diferencias que se observan provienen casi siempre de ajustes implícitos distintos, no del motor:

Capas transferidas (offload)

Ollama puede dejar algunas capas en la CPU por precaución respecto a la VRAM disponible, mientras que `llama-bench -ngl 99` coloca todo en el GPU. Resultado: Ollama parece más lento, aunque se debe a una decisión de distribución.

Tamaño de contexto

Un contexto más grande reserva más VRAM para la caché KV y reduce el espacio para los pesos. Compara con el mismo tamaño de contexto.

Flash Attention y caché KV

Activados o no, cuantizados o no, estos ajustes modifican el throughput. En llama.cpp los fijas; en Ollama dependen de la versión y de las variables de entorno.

#Ajustes finos accesibles solo en llama.cpp

Es aquí donde la comparación llama cpp vs ollama se inclina claramente hacia uno de los dos. Al exponer directamente las opciones del motor, llama.cpp da acceso a ajustes que Ollama oculta o solo expone parcialmente. Para un uso avanzado, estos ajustes lo cambian todo:

Offload quirúrgico (-ngl)

Decides, con precisión de una capa, cuántas capas van a la GPU. Con una VRAM apenas suficiente, colocar 2 o 3 capas más en la GPU que con Ollama puede hacer que un modelo pase de «lento» a «fluido».

Caché KV cuantizada (-ctk/-ctv)

Cuantizar la caché KV en q8_0 reduce casi a la mitad la memoria del contexto, lo que permite ventanas mucho más largas con la misma cantidad de VRAM: una opción poco accesible en Ollama.

Flash attention (--flash-attn)

Activación explícita de la atención optimizada, con un impacto directo en la velocidad y la memoria de contextos largos.

Decodificación especulativa (--model-draft)

Conectar un pequeño modelo «borrador» para acelerar un modelo grande. La mejora de velocidad puede ser considerable con código, y esta función es nativa en llama.cpp.

Gramáticas GBNF (--grammar)

Restringir la salida a una gramática formal (JSON estricto, enumeración, formato propio). Es indispensable para obtener una salida estructurada fiable y permite un control mucho más detallado que el modo JSON de Ollama.

RoPE y escalado del contexto

Ajustar `--rope-freq-base` y `--rope-freq-scale` para extender el contexto más allá del entrenamiento original, controlando la degradación.

Ollama ofrece parte de estos ajustes mediante los parámetros del Modelfile o las variables de entorno, pero rara vez con el mismo nivel de detalle y, a menudo, con cierto retraso respecto a las novedades de llama.cpp. Si lo que necesitas es «el contexto más largo posible con mi VRAM» o «JSON cuya validez esté garantizada», el motor sin la capa adicional te da acceso a tornillos que esta ha soldado.

#Servidor API: Ollama vs llama-server

Ambos pueden servir un modelo mediante HTTP. Ollama expone su daemon en http://localhost:11434 con una API nativa (/api/generate, /api/chat) y un endpoint compatible con OpenAI (/v1/chat/completions). Por su parte, llama.cpp proporciona `llama-server`, un binario que inicia una API compatible con OpenAI y una pequeña interfaz web incluida.

# API OpenAI-compatible sur le port 8080, tout GPU
./build/bin/llama-server -m ./qwen3-8b-Q4_K_M.gguf -ngl 99 -c 8192 --port 8080
# Interface web : http://localhost:8080  ·  API : /v1/chat/completions

Modelos múltiples a demanda

Ollama carga/y descarga automáticamente varios modelos según las solicitudes. `llama-server` sirve un modelo por proceso — más sencillo de entender, menos mágico.

Control de flags

Con llama-server, cada ajuste del motor (contexto, caché KV, Flash Attention) se especifica mediante un flag explícito al iniciar el servidor. Ideal para fijar una configuración de producción reproducible.

Ecosistema

La API 11434 de Ollama se ha convertido en un estándar de hecho: Open WebUI, los editores de código y las integraciones se conectan directamente a ella. Es una ventaja real en términos de comodidad.

#Veredicto por perfil: principiante, desarrollador, homelab

Como el motor es el mismo, el veredicto no depende del rendimiento, sino de tu perfil y de tu tolerancia a la línea de comandos.

Para principiantes → Ollama

Un comando para instalar, otro para arrancar, un modelo que «funciona» sin necesidad de ajustar nada. No hay razón para compilar C++ para hablar con un LLM. Quédate con Ollama, opcionalmente con Open WebUI como interfaz.

Desarrollador → ambos

Ollama para crear prototipos rápidamente y disponer de inmediato de la API OpenAI; llama.cpp cuando necesites gramáticas GBNF, decodificación especulativa o un control exacto de la caché KV. Pasar de uno a otro no supone ninguna dificultad: ambos utilizan el mismo GGUF.

Homelab / auto-hospedaje → llama.cpp (llama-server)

Para aprovechar hasta el último recurso de una VRAM limitada, fijar una configuración reproducible y ampliar el contexto, el motor sin capas adicionales es la mejor opción. La contrapartida —compilar, escribir los flags, gestionar los procesos— es precisamente lo que buscas dominar.

En una frase: Ollama es el mejor punto de partida y basta para la inmensa mayoría de los usos; pasas a usar llama.cpp directamente cuando un ajuste preciso —contexto, caché KV, gramática, offload con precisión de una capa— se convierte en el factor limitante. No es un reemplazo, es un paso hacia un mayor control.

#Para ir más allá

Estas guías amplían esta comparativa, desde la instalación hasta el ajuste fino:

Empezar con Ollama

«Instalar Ollama en 5 minutos (Windows, macOS, Linux)» cubre la instalación del daemon y del primer modelo con un enfoque sencillo.

Servir sin Ollama

«llama-server: una API OpenAI local con llama.cpp» detalla el control preciso de la descarga de capas y la interfaz web incluida, en lo que respecta al control.

Elegir la cuantización

«Cuantización GGUF en 2026: Q4_K_M vs Q5_K_M vs Q6_K» ayuda a seleccionar el archivo .gguf adecuado, común a ambas herramientas.