llama.cpp

llama.cpp es un motor de inferencia en C/C++ para grandes modelos de lenguaje, creado por Georgi Gerganov y lanzado por primera vez en marzo de 2023. Lo que comenzó como un experimento de una sola noche para ejecutar el modelo Llama de Meta en un MacBook sin GPU se ha convertido en la infraestructura fundamental para prácticamente todas las herramientas de LLM locales existentes: Ollama, LM Studio, Jan y AnythingLLM utilizan llama.cpp como su backend de inferencia principal. El proyecto tiene licencia MIT, cuenta con más de 108,000 estrellas en GitHub y ha lanzado más de 5,000 compilaciones versionadas. Se ejecuta en Apple Silicon (Metal), GPU de NVIDIA (CUDA), GPU de AMD (HIP), Vulkan para soporte de GPU de múltiples proveedores y CPU pura con optimizaciones del conjunto de instrucciones AVX/AVX2/AVX512.

El motor es compatible con más de 50 arquitecturas de modelos, incluyendo variantes de LLaMA, Mistral, Mixtral, Gemma, Phi, DeepSeek y Qwen. Utiliza el formato de archivo GGUF, que Gerganov introdujo en agosto de 2023 y que desde entonces se ha convertido en el estándar universal para la distribución de LLM locales. Las opciones de cuantización van desde 1.5 bits hasta 8 bits, lo que permite que un modelo de 7 mil millones de parámetros quepa en menos de 4 GB de RAM. El proyecto incluye un servidor HTTP completo compatible con OpenAI (llama-server), una interfaz de chat de línea de comandos (llama-cli), herramientas de evaluación comparativa y soporte de inferencia multimodal a través de la biblioteca libmtmd añadida en abril de 2025. El tamaño de instalación es inferior a 90 MB. No hay dependencia de la nube, no se requiere cuenta y ningún dato sale de la máquina que lo ejecuta.

Lo que llama.cpp realmente hace en mayo de 2026

La compilación actual (b9012, 3 de mayo de 2026) incluye una pila de inferencia local completa. El punto de entrada principal para la mayoría de los desarrolladores es llama-server, que lanza una API compatible con OpenAI en localhost:8080 con un solo comando. Cualquier cliente creado con el SDK de OpenAI funciona sin modificaciones, lo que significa que llama.cpp se integra directamente en complementos de VS Code, scripts de Python o cualquier aplicación que utilice /v1/chat/completions.

La cuantización es la capacidad técnica central que hace que llama.cpp sea viable en hardware de consumo. El formato GGUF empaqueta el modelo cuantizado, el vocabulario y la configuración de la arquitectura en un solo archivo. La recomendación predeterminada para la mayoría de los casos de uso es Q4_K_M (aproximadamente 4.5 GB para un modelo de 7B), que ofrece una pérdida de calidad insignificante en comparación con la versión de precisión completa mientras se ejecuta en un MacBook con 8 GB de RAM a más de 40 tokens por segundo. Para dispositivos con recursos limitados, el formato Q1_0 de abril de 2026 permite que modelos capaces ocupen menos de 1 GB. Para los usuarios que priorizan la calidad, están disponibles Q8_0 o Q5_K_M.

La descarga de hardware se maneja automáticamente. Cuando un modelo supera la VRAM de la GPU disponible, llama.cpp lo divide: las capas que caben van a la GPU y el resto se procesa en la RAM de la CPU. El rendimiento se degrada gradualmente en lugar de fallar. En Apple Silicon, la aceleración de Metal es nativa. En Linux con hardware de NVIDIA, CUDA es el predeterminado. Se puede compilar un único binario con soporte para Vulkan para ejecutarse en AMD, Intel Arc o cualquier GPU compatible con Vulkan sin controladores específicos del proveedor.

Las compilaciones de abril de 2026 agregaron paralelismo de tensores independiente del backend a través de NCCL y RCCL, que divide operaciones individuales en múltiples GPU simultáneamente en lugar de solo dividir las capas del modelo. Para configuraciones de múltiples GPU, esto produce ganancias de rendimiento de 3 a 4 veces en comparación con el enfoque anterior de partición de capas y hace que llama.cpp sea cada vez más viable para pequeñas implementaciones de producción, no solo para uso personal. El mismo mes, se lanzó la rotación de caché KV de Walsh-Hadamard, elevando las puntuaciones de referencia de razonamiento AIME25 del 0.0% al 21.7% bajo la cuantización Q4_0, una mejora significativa para la inferencia cuantizada en tareas de razonamiento de múltiples pasos.

La descarga de modelos se integra directamente con Hugging Face y Docker Hub. Al pasar un ID de modelo de Hugging Face a llama-server, se extrae el archivo GGUF y se inicia el servidor. Dado que Hugging Face indexa de forma nativa los archivos GGUF, esto funciona para miles de modelos cuantizados por la comunidad sin ningún paso de conversión.

"Logré manejar el conjunto de datos de 13B en una sola Pi4 de 8 gigas... la realidad actual de los LLM reproducibles en casa en cualquier cosa que tengas" - cameron_b, Hacker News, septiembre de 2023

Dónde se sitúa llama.cpp frente a vLLM y MLX

llama.cpp vs. vLLM: Estas dos herramientas sirven a diferentes extremos del espectro de implementación y rara vez compiten por el mismo caso de uso. vLLM es un marco de inferencia basado en Python y centrado en servidores GPU, construido en torno al procesamiento por lotes continuo y PagedAttention, un mecanismo para gestionar la memoria caché KV a nivel de página. En una NVIDIA H200 a carga máxima, vLLM ofrece 35 veces el rendimiento de solicitudes y 44 veces la salida de tokens por segundo en comparación con llama.cpp, pero esa comparación solo se mantiene con más de 10 usuarios simultáneos en hardware de nivel empresarial. Para cargas de trabajo de un solo usuario o de baja concurrencia, la latencia entre tokens de llama.cpp es drásticamente menor porque no agrupa las solicitudes. vLLM requiere CUDA y no se ejecuta de manera significativa en hardware de consumo, escritorios de Windows o Apple Silicon. llama.cpp se ejecuta en todas partes. Compara vLLM si estás implementando una API de producción en un servidor GPU dedicado con más de 5 usuarios simultáneos; llama.cpp es la opción correcta para todo lo demás.

llama.cpp vs. MLX: MLX es el propio marco de aprendizaje automático de Apple, optimizado para la arquitectura de memoria unificada de los chips Apple Silicon. Debido a que la CPU y la GPU comparten la misma memoria física en Apple Silicon, MLX logra operaciones de tensores sin copia (zero-copy), eliminando la sobrecarga de transferencia de datos en la que incurre llama.cpp al mover datos entre los sombreadores de Metal. En un M2 Pro ejecutando Llama 3.1 8B en Q4_K_M, MLX alcanza aproximadamente 45-58 tokens por segundo frente a los 38-48 de llama.cpp. Para flujos de trabajo de desarrollo exclusivos de Mac, esa diferencia importa. MLX también admite el ajuste fino nativo de LoRA y QLoRA, algo que llama.cpp no hace. La limitación crítica: MLX es exclusivo de Apple Silicon. No se ejecuta en Windows, Linux ni Android. También requiere la conversión del modelo desde el formato GGUF, y los modelos de la comunidad a menudo aparecen primero en GGUF, mientras que las conversiones a MLX se retrasan horas o días. llama.cpp tiene soporte desde el primer día para los nuevos lanzamientos de la comunidad y se ejecuta en cualquier hardware.

"Acabo de cambiar desde ollama y la velocidad de generación de tokens y la ganancia de eficiencia han sido sobresalientes." - reseña de usuario, itsfoss.com, 2025

Cómo es el flujo de trabajo de inferencia diario

El camino mínimo para ejecutar un modelo consta de tres pasos: descargar un archivo GGUF desde Hugging Face, ejecutar llama-server -m model.gguf y acceder a localhost:8080/v1/chat/completions. El servidor se inicia en menos de cinco segundos en un almacenamiento rápido. Detener y reiniciar con un modelo diferente toma la misma cantidad de tiempo. Sin gestión de demonios, sin registro de modelos, sin servicios en segundo plano consumiendo recursos cuando está inactivo.

Para uso interactivo, llama-cli -m model.gguf --interactive abre una sesión de chat en la terminal. Las restricciones gramaticales te permiten forzar la salida en JSON o restringir las respuestas a un esquema definido, lo cual es útil para canalizaciones de extracción de datos estructurados. La longitud de la ventana de contexto es configurable mediante un indicador de línea de comandos, limitada por la RAM disponible.

La interfaz de usuario web, introducida en 2024, proporciona una interfaz de chat basada en el navegador alojada por llama-server. Admite conversaciones de múltiples turnos, configuración de prompts del sistema y ajuste de parámetros sin tocar la línea de comandos. No está tan pulida como la interfaz de LM Studio, pero funciona en cualquier navegador y no requiere instalación más allá del binario del servidor.

Para los usuarios que construyen aplicaciones sobre llama.cpp, los complementos de VS Code y Vim/Neovim se incluyen como parte del proyecto, enrutando las solicitudes de autocompletado de código a través del endpoint local de llama-server. La capa de compatibilidad con OpenAI significa que cualquier herramienta que acepte una URL base personalizada, como AnythingLLM o Continue.dev, se conecta sin cambios de configuración.

Para quién está diseñado llama.cpp

llama.cpp está dirigido a desarrolladores y usuarios técnicos que desean un control total sobre su pila de inferencia y están dispuestos a dedicar de 30 a 60 minutos en la configuración inicial para evitar la dependencia de la nube, los costos por token o las capas de abstracción que añaden las herramientas de nivel superior. Los usuarios preocupados por la privacidad que no pueden o no quieren enviar datos a API externas confían en él. Los investigadores que realizan experimentos en hardware de consumo lo utilizan para acceder a los mismos pesos de modelo servidos por los proveedores de la nube con un costo marginal cero por consulta. Los desarrolladores de sistemas integrados y edge lo compilan para dispositivos Raspberry Pi, Android (aceleración nativa a través de Qualcomm Hexagon desde abril de 2026) y ChromeOS.

La importancia en el ecosistema es difícil de exagerar: incluso los usuarios que nunca tocan llama.cpp directamente probablemente lo estén ejecutando si utilizan alguna herramienta frontend de LLM local. Entender qué es llama.cpp ayuda a los usuarios a comprender dónde ocurre realmente su inferencia, por qué ciertos niveles de cuantización GGUF funcionan mejor en su hardware y cómo depurar problemas de rendimiento que su interfaz gráfica no expone.

Los usuarios que combinan llama.cpp directamente con los modelos Llama de Meta obtienen la máxima compatibilidad, ya que el proyecto se construyó originalmente para Llama y ambos siguen estrechamente alineados en el soporte de nuevas arquitecturas. El ecosistema de modelos de la comunidad en Hugging Face, donde existen miles de cuantizaciones GGUF para cada lanzamiento importante de pesos abiertos, convierte efectivamente a llama.cpp en la vía de acceso para cualquier modelo nuevo a las pocas horas de su lanzamiento.

Lo que llama.cpp no es

llama.cpp no es una aplicación gráfica. Los usuarios que esperan una gestión de modelos de apuntar y hacer clic encontrarán la CLI poco familiar. LM Studio y Jan existen precisamente para añadir esa capa de interfaz gráfica sobre el motor de inferencia de llama.cpp.

No es un servidor de inferencia multiusuario a gran escala. El motor procesa las solicitudes de forma secuencial. Con cinco o más usuarios simultáneos, la latencia de la cola crece exponencialmente. Para el servicio de API en producción con requisitos de concurrencia reales, vLLM o un endpoint alojado son más apropiados.

No es una herramienta de ajuste fino. No hay bucle de entrenamiento, ni implementación de LoRA, ni canalización de conjuntos de datos. Si necesitas ajustar un modelo, ese trabajo se realiza en un marco de Python (PyTorch, MLX, Axolotl) y los pesos resultantes se convierten luego a GGUF para la inferencia.

No es un centro de modelos ni una herramienta de descubrimiento. llama.cpp no selecciona ni recomienda modelos. Los usuarios encuentran modelos en Hugging Face o a través de recursos de la comunidad como r/LocalLLaMA, y luego descargan los archivos GGUF directamente.

También vale la pena ser claros sobre la atribución en el ecosistema. Muchos usuarios de Ollama o LM Studio no se dan cuenta de que esas herramientas dependen de llama.cpp para su inferencia. Una frustración persistente en la comunidad, que surgió en el problema #3185 de GitHub y se discutió repetidamente en Hacker News, es que Ollama no acredita claramente a llama.cpp en su documentación o interfaz de usuario. Esto importa porque los problemas de rendimiento, el comportamiento de la cuantización y las arquitecturas de modelos compatibles son todas propiedades de llama.cpp, no de la herramienta contenedora. Saber que llama.cpp es el motor real brinda a los usuarios un vocabulario significativo para la depuración y la optimización.

La implicación práctica: si estás eligiendo entre Ollama y llama.cpp directamente, no estás eligiendo entre diferentes motores de inferencia. Estás eligiendo entre diferentes niveles de abstracción sobre el mismo motor de inferencia. Para la mayoría de los usuarios, la simplicidad de Ollama gana. Para los desarrolladores que necesitan ajustar parámetros, construir canalizaciones personalizadas o ejecutar modelos que el registro de Ollama no incluye, el acceso directo a llama.cpp es la capa correcta en la que trabajar.