Ollama vs llama.cpp: el mismo motor debajo y distinto control encima

Ollama vs llama.cpp no es tanto una competición como una elección de capa. El propio README de Ollama pone llama.cpp como su motor: llama.cpp es el programa en C/C++ que ejecuta el modelo en tu procesador o tu tarjeta gráfica, y Ollama envuelve un motor así con una biblioteca de modelos, un servicio en segundo plano y una API sencilla. Así que la pregunta útil no es cuál es más rápido en abstracto, sino si quieres la comodidad de Ollama o el control directo de llama.cpp. Esta guía compara los dos con su documentación a 10 de octubre de 2026, enseña los valores por defecto que explican casi todas las quejas de «Ollama va más lento» y dice cuándo tiene más sentido una tercera opción, vLLM.

Ollama vs llama.cpp de un vistazo

Tabla: Ollama y llama.cpp comparados con su propia documentación (10 de octubre de 2026)

Los dos ejecutan los mismos archivos GGUF y los dos pueden repartir un modelo entre tarjeta gráfica y procesador cuando no cabe en la memoria de vídeo. Si nunca has ejecutado un modelo en tu ordenador, empieza por cómo instalar Ollama.

Qué relación hay entre Ollama y llama.cpp

llama.cpp define su objetivo como ejecutar modelos de lenguaje con una configuración mínima y un rendimiento puntero en hardware muy variado. Está escrito en C/C++ sin dependencias, se apoya en la biblioteca ggml y trae motores para NVIDIA (CUDA), AMD (HIP), Apple (Metal), Vulkan, gráficas de Intel (SYCL) y más, con soporte para los procesadores neuronales de Intel mediante OpenVINO marcado como en desarrollo. Incluye sus propias herramientas: un chat en la terminal, un servidor y un programa para cuantizar.

Ollama está un nivel por encima. Su README dice «Start building with open models», cita llama.cpp en «Supported backends» y añade lo que llama.cpp te deja a ti: una biblioteca de modelos con etiquetas, un servicio que carga el modelo cuando llega una petición y lo descarga después, el formato Modelfile para ajustes propios, una aplicación de escritorio y conexión con un comando a herramientas de programación como Claude Code, Codex y Copilot. Los comandos del día a día están en nuestra guía de comandos de Ollama.

Dos consecuencias prácticas. La primera: un modelo que funciona en uno suele funcionar en el otro, porque los dos leen GGUF. La guía de importación de Ollama incluso te manda a llama-quantize, de llama.cpp, para preparar un GGUF, porque Ollama no cuantiza los GGUF al importarlos. La segunda: los dos proyectos publican versiones por separado, así que un día cualquiera pueden no estar usando la misma versión del código de abajo.

¿Es llama.cpp más rápido que Ollama?

No los hemos medido, y las cifras de terceros que circulan no coinciden entre sí. Lo que sí deja ver la documentación es que casi todas las diferencias de velocidad y de memoria que se cuentan vienen de los valores por defecto, no de un motor distinto:

• Longitud del contexto. Ollama usa una ventana de contexto de 4.096 tokens salvo que pongas OLLAMA_CONTEXT_LENGTH o num_ctx. llama-server toma la del archivo del modelo, que en los modelos recientes puede ser de cientos de miles de tokens y necesita muchísima más memoria. Un contexto pequeño va más rápido y ocupa menos, pero recorta sin avisar las peticiones largas; uno grande puede echar capas fuera de la tarjeta gráfica. Por qué el contexto gasta memoria lo explicamos en cuánta VRAM necesitas.
• Peticiones simultáneas. Ollama atiende una petición a la vez por modelo (OLLAMA_NUM_PARALLEL=1), y su FAQ avisa de que la memoria crece con el número de peticiones en paralelo por la longitud del contexto. llama-server elige solo el número de huecos y deja activado el procesamiento por lotes continuo, que ayuda cuando lo usan varios programas a la vez.
• Capas en la gráfica y flash attention. llama.cpp decide por defecto cuántas capas van a la tarjeta gráfica (-ngl auto) y pone flash attention en automático; Ollama hace el reparto por su cuenta y lo enseña en ollama ps. Si parte del modelo acaba en el procesador, la generación se hunde en los dos: Ollama no usa la GPU explica cómo comprobarlo.
• Cuantización. Comparar un archivo Q4 en uno con un Q8 en el otro mide los archivos, no las herramientas. Lo que cuesta cada nivel en calidad y memoria está en qué es la cuantización.

Para comparar en serio, ejecuta el mismo GGUF con la misma longitud de contexto, el mismo número de capas en la gráfica y el mismo ajuste de paralelismo, y mide los tokens por segundo con tus propias peticiones.

API, modelos y comandos, uno al lado del otro

Arrancar un modelo. En Ollama, ollama run descarga el modelo de su biblioteca si hace falta y abre un chat. En llama.cpp, el arranque rápido del README es llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF para chatear y llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF para levantar un servidor compatible con OpenAI, los dos bajando el modelo directamente de Hugging Face.

La API. Ollama escucha en http://localhost:11434 con su API propia y rutas compatibles con OpenAI para chat, respuestas, embeddings y modelos, además de una compatible con Anthropic. llama-server ofrece chat, respuestas y embeddings compatibles con OpenAI, compatibilidad con la API Messages de Anthropic, reordenación de resultados, JSON ajustado a un esquema, llamadas a funciones con casi cualquier modelo, decodificación especulativa y una interfaz web. Ojo con el puerto: la documentación actual del servidor da el 9931 por defecto, mientras que muchas guías antiguas y sus propios ejemplos de Docker usan el 8080; fíjalo con --port si un programa espera uno u otro.

Varios modelos. Ollama carga por defecto hasta tres modelos por tarjeta gráfica (tres con procesador) si caben en memoria, y descarga cada uno tras cinco minutos sin uso. Si arrancas llama-server sin modelo, funciona en modo router: busca modelos en su caché o en una carpeta que le pasas con --models-dir, los carga al pedirlos y mantiene hasta cuatro a la vez por defecto.

Seguridad. Los dos escuchan solo en tu propio equipo por defecto (127.0.0.1); Ollama lo cambia con OLLAMA_HOST y llama.cpp con --host. llama-server puede exigir claves con --api-key; si abres cualquiera de los dos a la red, pon delante algún tipo de autenticación.

Cuál usar y cuándo es mejor vLLM

• Elige Ollama si quieres modelos funcionando en minutos, cambias a menudo de modelo o conectas modelos locales a aplicaciones y herramientas de programación que ya hablan su API. Compáralo con la alternativa de escritorio en Ollama vs LM Studio.
• Elige llama.cpp si quieres todos los ajustes en tus manos (contexto, tamaño de lote, capas en la gráfica, decodificación especulativa), más motores de hardware (su README cita 17, de CUDA y Metal a SYCL y Snapdragon), un servidor que atiende a varios usuarios con lotes continuos o un único programa sin servicio en segundo plano.
• Elige vLLM si vas a dar servicio a muchos usuarios desde una o varias tarjetas gráficas de centro de datos. Su README destaca un rendimiento puntero sirviendo peticiones, con gestión de memoria PagedAttention, lotes continuos y caché de prefijos, un servidor compatible con OpenAI y con la API Messages de Anthropic, y soporte para gráficas de NVIDIA, AMD e Intel y procesadores, con Apple mediante un complemento. Está pensado para servidores, no para una persona con un portátil.

Elijas lo que elijas, el hardware decide más que el software: mira nuestra guía de la mejor GPU para modelos en local antes de comprar nada.