> llama.cpp vs Ollama — ¿cuál deberías ejecutar?▋

Los buscadores sirven la frase llama.cpp vs Ollama como una pelea entre dos productos. Los repos cuentan otra historia: uno guarda en su raíz un archivo que nombra el número de build exacto del otro. El motor de Ollama es llama.cpp, fijado — la pelea que internet quiere no es la decisión que de verdad enfrentas.

La decisión real es cuánto motor quieres tocar. Todo lo que sigue viene de los dos repos, sus feeds de releases y hilos públicos, verificado la mañana en que se publicó este post.

¿Qué es llama.cpp, en realidad?

130.473 estrellas, licencia MIT, cuatro releases el día de esta review. llama.cpp es el motor de inferencia en C/C++ que arrancó la ola de modelos locales en marzo de 2023. Su proyecto introdujo GGUF, el formato de archivo único con el que comercia todo el ecosistema local — la escalera de cuantización que todos discuten se expresa en un formato diseñado por sus propios autores. Tiene 24.125 forks, 2.515 issues abiertas, y su contribuidor más prolífico suma 2.011 commits.

El feed de releases se lee como un diario: cuatro builds habían aterrizado para el inicio de la tarde el día de esta review (b11438 a b11443), cada uno un incremento numerado que puedes fijar. Junto al CLI entrega llama-server, un servidor HTTP compatible con OpenAI — apunta cualquier cliente y se comporta como una API hospedada que vive en tu máquina.

verify: curl -s http://127.0.0.1:11434/api/version → {"version":"..."} con un Ollama corriendo · llama-server --version → el tag de build, p. ej. b11443

¿Es Ollama algo más que un envoltorio?

Sí — y la frontera está impresa en el repositorio. La raíz de Ollama lleva tres archivos de fijación de versión: LLAMA_CPP_VERSION (b11351 al momento de la review), MLX_VERSION y MLX_C_VERSION. El código Go en llm/llama_server.go arranca un binario servidor derivado de llama.cpp como subproceso y le habla. La dependencia no es un secreto a voces; es un input de build.

Lo que Ollama añade encima es un servicio: descarga de modelos en un comando desde un registro, autodetección de hardware, una API residente en el puerto 11434, y un segundo motor — MLX — para máquinas Apple Silicon que prefieran safetensors en vez de GGUF. Esa es la definición honesta: Ollama es gestión de modelos e higiene de procesos alrededor de un motor que no escribió.

Qué significa el rezago de versión en la práctica

Noventa y dos builds separan el fix de Ollama (b11351) de la release matinal de upstream (b11443) al momento de la review. Los arreglos del motor — la aceleración prompt-lookup-drafting de septiembre que llegó a 89 puntos en Hacker News, por ejemplo — aterrizan primero en upstream y suben al tren de releases de Ollama semanas después. Si una línea del changelog arregla tu problema, el envoltorio suele ser el último en enterarse.

Entonces, ¿cuál es más rápido?

Para el mismo archivo de modelo, ninguno — el motor es compartido. Las comparaciones de tokens por segundo que afirman una brecha suelen comparar cuantizaciones distintas, tamaños de contexto distintos, o builds distintos del propio motor. Nuestra comparación con LM Studio chocó con el mismo muro: la interfaz cambia, las mates son idénticas.

Donde aparecen brechas reales vienen de los defaults y del rezago, no de los motores: Ollama elige un tamaño de contexto y descarga capas por ti (las perillas detrás de las sorpresas de VRAM), mientras que llama.cpp te las deja poner — y te castiga por olvidarlas. La pregunta de benchmark esconde una pregunta de control.

No estás eligiendo entre dos motores. Estás eligiendo cuánto motor quieres tocar.

¿Qué dice el registro contra llama.cpp?

El libro honesto, porque el registro tiene uno:

• 2.515 issues abiertas y un ritmo de asedio. Cuatro releases en una sola mañana es caudal — también es churn. Los flags se mueven, los backends se reorganizan, y tu script de build fijado pide el mismo mantenimiento.
• La comunidad lo dice en voz alta. Tomado del hilo de Hacker News sobre la aceleración de septiembre (89 puntos): "Frankly, llama.cpp is so badly written that these kind of speedups are trivial, and a hard fork (or a total rewrite) has been needed for the longest time." — rfgplk. El mismo hilo carga la preocupación de gobernanza tras el acuerdo Nvidia–Hugging Face que puso en juego al empleador del equipo núcleo.
• Tú haces las tareas. Sin registro, sin autodetección: bajas los GGUF de Hugging Face (la guía de montaje lo cubre), pasas tú los flags de descarga de capas y vigilas el proceso.

¿Cuál deberías ejecutar?

El veredicto del registro, y la línea de honestidad obligatoria: he leído el registro, no lo he ejecutado. Cada número aquí viene de los dos repos, sus feeds de releases y los hilos públicos enlazados — no de mi terminal.

Quieres	Ejecuta	Por qué, con el registro en mano
Un comando y una ventana de chat	Ollama	Descarga de modelos, autodetección, API residente — el electrodoméstico
Todos los flags y el build más nuevo	llama.cpp	Builds fijados, llama-server, backends a tu gusto
Una GUI de escritorio	LM Studio	Misma línea de motor con botones — comparado aquí
Una GPU, muchos usuarios	vLLM	Serving por caudal — aplican las salvedades GGUF

Una costura práctica: empieza en Ollama y, cuando se te resista — un flag que no expone, una detección GPU torcida (la más común), un arreglo sentado en un build más nuevo — baja a llama.cpp para ese trabajo. El archivo de modelo te acompaña; GGUF es la lengua franca. Todo el cluster, ambos incluidos, está indexado en el hub local-LLM.

El electrodoméstico te ahorra el motor hasta el día en que el motor es el problema. Ese día es la razón de ser de la segunda herramienta.

¿De qué lado del capó estás — y un default del envoltorio alguna vez te costó una tarde que un solo flag habría ahorrado?