llama.cpp vs vLLM vs Exllama

#Un motor de inferencia: lo que realmente cambia entre ellos

Un motor de inferencia convierte tokens de entrada en tokens de salida. Las aplicaciones que instalas (Ollama, LM Studio, Jan) incluyen uno; los servidores de producción (vLLM, SGLang) son motores de inferencia. Tres diferencias repercuten en tu uso: los formatos de modelos aceptados, el hardware que se puede utilizar y la forma de gestionar varias solicitudes al mismo tiempo.

#El formato del modelo determina qué motor se puede utilizar

Antes de comparar velocidades, comprueba el formato en el que está publicado el modelo que quieres. Un archivo GGUF se carga en llama.cpp y, por tanto, en Ollama, LM Studio y Jan. Los pesos de Hugging Face en FP16, FP8 o cuantizados en AWQ o GPTQ se cargan en vLLM o SGLang. Un modelo convertido para MLX se carga con MLX LM en Mac, y un modelo EXL3, con ExLlamaV3. Cambiar de motor suele implicar volver a descargar el modelo en otro formato.

#llama.cpp: el estándar portátil

llama.cpp es una implementación en C/C++ sin dependencias, cuyo objetivo declarado es la inferencia con un mínimo de configuración en una amplia variedad de hardware. Apple Silicon recibe atención prioritaria (NEON, Accelerate, Metal), las CPU x86 son compatibles con AVX, AVX2, AVX512 y AMX, y también se admiten GPU NVIDIA (CUDA), AMD (HIP), Vulkan y SYCL. Ofrece cuantizaciones de 1,5 a 8 bits e inferencia híbrida con CPU y GPU, que permite ejecutar un modelo más grande que la VRAM disponible.

Una idea errónea que hay que corregir: llama.cpp no se limita a una petición a la vez. Su servidor anuncia generación paralela para varios usuarios y procesamiento continuo por lotes, activado por defecto, con espacios (slots) configurados mediante el parámetro --parallel. Por tanto, atiende adecuadamente a un equipo pequeño; lo que no busca igualar son las funciones de producción a gran escala de vLLM.

Fortalezas

Portabilidad (Mac, Linux, Windows, Android), formatos GGUF omnipresentes, ejecución híbrida en CPU y GPU, dependencia reducida.

Límites

No hay funciones de despliegue distribuido comparables a las de vLLM; es necesario conocer los ajustes (contexto, slots, capas en GPU).

Ecosistema

Base de Ollama y LM Studio, también citada por Jan.

Para compilar con CUDA, Metal o Vulkan, consulta las guías de compilación; la guía completa sobre llama.cpp detalla su uso.

#vLLM: el servidor para muchos usuarios

vLLM es una biblioteca de inferencia y servicio nacida en el Sky Computing Lab de la Universidad de California en Berkeley. Se basa en PagedAttention, que gestiona por páginas la memoria de las claves y los valores de la atención, y en el batching continuo, complementados con el prerrelleno por fragmentos y la caché de prefijos. Anuncia formatos FP8, INT4, GPTQ, AWQ y GGUF, una API compatible con OpenAI y compatibilidad con GPU NVIDIA, AMD e Intel, así como con CPU x86, ARM y PowerPC.

Dos ideas erróneas que corregir. En primer lugar, vLLM ya no está reservado a NVIDIA y también admite CPU: su repositorio indica compatibilidad con varias GPU y CPU. En segundo lugar, ya admite GGUF: su documentación describe este soporte como muy experimental y poco optimizado, utilizable sobre todo para reducir la huella de memoria. Para un uso diario de GGUF, llama.cpp sigue siendo la vía habitual.

Fortalezas

Rendimiento bajo carga, memoria de caché gestionada por páginas, API compatible con OpenAI, paralelismo (tensorial, de pipeline, de expertos), numerosos formatos.

Límites

Más complicado de instalar y configurar que llama.cpp; pensado para servidores con GPU; GGUF no es su especialidad.

Ecosistema

Elección por defecto cuando varias personas o aplicaciones consultan el mismo modelo al mismo tiempo.

La guía sobre vLLM explica qué es el motor; la del despliegue en producción detalla las configuraciones y la supervisión.

#ExLlama: V2 archivado, V3 en desarrollo

El repositorio de ExLlamaV2 incluye una nota que indica que el proyecto está archivado por el momento y que el desarrollo continúa en ExLlamaV3. Muchas comparativas, incluida la versión anterior de esta página, todavía presentan V2 como la opción más avanzada. El repositorio de ExLlamaV3 anuncia el formato de cuantización EXL3, la inferencia paralela por tensores y por expertos, la descarga de trabajo a la CPU para los modelos de expertos, el batching continuo, la decodificación especulativa y una API compatible con OpenAI a través de TabbyAPI, su servidor recomendado.

ExLlamaV3 está orientado a las GPU de consumo, no a los servidores de producción ni a los Mac. Si tienes una tarjeta NVIDIA y quieres el mejor equilibrio entre calidad y tamaño, la cuantización EXL3 merece una prueba; verifica primero que tu modelo figure en la lista de arquitecturas del repositorio.

#SGLang, MLX LM y los demás

SGLang

Framework de servicio descrito como orientado a una baja latencia y un alto rendimiento de procesamiento, desde una GPU hasta grandes clústeres. Anuncia RadixAttention para la caché de prefijos, el procesamiento continuo por lotes, PagedAttention y la decodificación especulativa. Compite con vLLM en los servidores; la guía dedicada lo explica en detalle.

MLX LM

Paquete Python para generar texto y afinar modelos en Apple Silicon con MLX. No funciona fuera de Mac. La guía MLX frente a llama.cpp compara ambos en Mac.

TensorRT-LLM

Motor de NVIDIA, de muy alto rendimiento en sus tarjetas, pero más complicado de configurar; solo debe considerarse para una flota de tarjetas NVIDIA en producción.

#¿Qué dicen las mediciones publicadas?

Las tasas de generación dependen del hardware, del modelo, de la cuantización, de la longitud de las solicitudes y de la versión del motor, y cambian cada mes. Por eso, esta guía no presenta mediciones propias y te invita a desconfiar de las tablas de tokens por segundo sin un protocolo. No obstante, una fuente externa publica un protocolo completo: Red Hat, en agosto de 2025.

Conviene leerlo con reservas: el artículo está vinculado a los productos Red Hat AI, por lo que procede de un actor comercial del sector; las pruebas se realizaron con Ollama y no directamente con llama.cpp, con los ajustes predeterminados; desde entonces han pasado varias versiones. La conclusión sólida es cualitativa: con muchas solicitudes concurrentes, un motor de servicio con procesamiento agresivo por lotes supera a una aplicación diseñada para un solo usuario. Si lo usas tú solo, la diferencia en la tasa de procesamiento no es lo que te perjudica.

#Memoria: lo que cada motor reserva

La memoria de un modelo se compone de los pesos, la caché de contexto (KV) y un margen. Los pesos se calculan: un modelo de 8 mil millones de parámetros ocupa aproximadamente 16 GB en FP16 (8 mil millones por 2 bytes) y aproximadamente 5 GB en Q4, cifra de referencia del sitio. La caché de contexto crece con la longitud de la conversación y el número de solicitudes simultáneas.

Punto clave: vLLM reserva la memoria desde el inicio, lo que lo hace eficiente para atender solicitudes de inferencia, pero poco adecuado para una tarjeta compartida con otras aplicaciones. Reduce el valor del parámetro gpu_memory_utilization si la tarjeta también se utiliza para otras tareas.

#¿Qué motor para qué uso?

Los motores pueden coexistir: Ollama para el chat diario, vLLM lanzado según necesidad para procesar un lote de extracciones. No hay razón para mantener solo uno si los usos son diferentes. Solo prevé el espacio en disco para el mismo modelo almacenado en dos formatos, por ejemplo, un archivo GGUF para el chat y pesos de Hugging Face para el servidor.

• Ollama contra llama.cpp
• vLLM: la guía completa
• SGLang como servidor LLM local
• MLX frente a llama.cpp en Mac
• llama.cpp: guía completa
• Ollama, LM Studio, Jan o GPT4All

• Fuente: repositorio de llama.cpp
• Fuente: repositorio de vLLM
• Fuente: repositorio de ExLlamaV2
• Fuente: Red Hat, Ollama contra vLLM