Ollama, llama.cpp, vLLM y TGI, qué motor de software elegir

Hay una decisión que casi nadie explica cuando alguien se plantea ejecutar un modelo de lenguaje en su propia máquina: el motor pesa más que el modelo. Un ejemplo de esto lo ha dado Microsoft recientemente, cuando añadió soporte experimental de llama.cpp a Windows ML, la capa con la que Windows mueve modelos en CPU, GPU y NPU, según el blog de Microsoft Foundry. Esa pieza invisible ya no es un asunto de entusiastas de Linux, y el movimiento de Microsoft, redefine que modelos son más aceptados que otros.

Y es que el ecosistema se mueve en varias direcciones a la vez. Ollama por ejemplo, convirtió MLX en el motor por defecto en los Mac con Apple Silicon con su rama 0.40, publicada como versión previa a finales de septiembre de 2026, según sus notas de versión. vLLM mantiene un ritmo de publicación frenético siguiendo su propio camino y Hugging Face jubiló su propio motor, a la vez que NVIDIA ofrece soluciones optimizadas para vLLM y llama.cpp.

Por eso hay que tener claro que motor de IA vas a usar antes de comparar nada, porque cambia la respuesta y eso puede significar la muerte de un proyecto. Como el caso de TGI, un proyecto que lleva en modo mantenimiento desde el 11 de diciembre de 2025 y su repositorio quedó archivado en solo lectura el 21 de marzo de 2026. Así queda claro: elegir motor de IA hoy significa escoger entre tres opciones vivas y una cuarta que solo tiene sentido si ya la tienes en producción, aunque será mejor que vayas pensando en la migración. Y eso último, no es nada fácil y dependiendo de tus necesidades, tampoco es barato.

¿Por qué los motores de IA no son intercambiables?

Un motor de inferencia es la pieza que carga los pesos del modelo, los coloca en la memoria disponible y ejecuta el bucle que genera texto token a token. El modelo es el contenido; el motor decide a qué velocidad sale y cuánta memoria consume. Dos programas que abren el mismo archivo pueden comportarse de forma muy distinta.

Preguntar por Ollama contra vLLM sin decir para qué uso está mal formulado, porque ocupan capas distintas. llama.cpp hace el trabajo pesado, Ollama es un envoltorio cómodo encima de ella y vLLM es un servidor pensado para atender a mucha gente a la vez. Lo que las une es una convención de facto: casi todas exponen una API compatible con OpenAI, así que puedes cambiar de motor sin reescribir tu aplicación.

llama.cpp, el motor que sostiene a los demás

llama.cpp nació en marzo de 2023 de la mano de Georgi Gerganov y hoy es la base sobre la que se apoyan la mayoría de herramientas locales. Está escrito en C y C++ sin dependencias externas, se distribuye con licencia MIT y ejecuta modelos cuantizados en formato GGUF, el estándar que usa buena parte de la comunidad.

Cubre Apple Silicon por Metal, NVIDIA por CUDA, AMD por ROCm, Intel por SYCL y el resto por Vulkan, OpenCL o CPU pura. Su servidor, llama-server, expone una API compatible con OpenAI para chat, respuestas y embeddings, con batching continuo, llamadas a funciones y decodificación especulativa.

llama.cpp no es solo una pieza interna: sus últimas versiones descargan el modelo desde Hugging Face y arrancan el servidor con una sola orden, sin compilar nada a mano, y eso lo acerca a quien nunca abriría un terminal.

Ollama, la puerta de entrada con dos motores

Ollama es hoy la vía más rápida para tener un modelo respondiendo en local. Es un binario escrito en Go, con licencia MIT, que envuelve llama.cpp en Windows y Linux y usa MLX, el marco de Apple, en los Mac con Apple Silicon. Desde la rama 0.40, MLX es el motor por defecto para las arquitecturas que lo soportan; el resto sigue corriendo sobre llama.cpp.

Encima, Ollama añade catálogo con descarga en una orden, detección de GPU, archivos Modelfile y un servidor en el puerto 11434 con la API de OpenAI en /v1. Si ya tienes código escrito contra esa API, te basta con cambiar la dirección base.

Sus límites aparecen con la concurrencia: las peticiones simultáneas por modelo se fijan con OLLAMA_NUM_PARALLEL y cada una multiplica el contexto a reservar, así que 2.000 tokens con cuatro peticiones ocupan como 8.000. Con diez usuarios a la vez, la factura de memoria se dispara y el envoltorio deja de ser cómodo.

vLLM, el motor para muchos usuarios a la vez

vLLM es una biblioteca de Python que nació en 2023 con un artículo académico sobre PagedAttention, que gestiona la caché de claves y valores como la memoria virtual de un sistema operativo. Aquel trabajo, presentado en el simposio SOSP de 2023, cifraba la mejora en 2 a 4 veces más rendimiento con la misma latencia.

En lugar de reservar memoria de más por petición, la reparte en bloques y reutiliza lo calculado, con batching continuo, troceado del prefill y caché de prefijos por defecto. Cubre decodificación especulativa y casi todas las cuantizaciones que circulan, desde FP8 y NVFP4 hasta INT4, GPTQ y AWQ, y admite varios adaptadores LoRA en un mismo proceso.

Muchas guías repiten que vLLM exige una GPU NVIDIA, algo razonable hace dos años. Su documentación actual lista CUDA, AMD con ROCm, Intel XPU, TPU de Google, Apple Silicon y CPU, aunque el grueso de la comunidad lo despliega sobre tarjetas de NVIDIA. Esa velocidad de desarrollo es su mayor atractivo y también su mayor pega: actualizar en producción obliga a leer las notas de cada versión.

TGI, el motor que ya no deberías elegir

Text Generation Inference fue el motor de Hugging Face y durante años la opción de referencia para servir modelos abiertos. Popularizó buena parte de lo que hoy damos por hecho: el batching continuo, la atención paginada y la cuantización GPTQ pasaron antes por su código. Su arquitectura, en Rust y Python, dejaba listas las métricas de Prometheus y las trazas de OpenTelemetry.

El código sigue disponible: lo que se ha detenido es su desarrollo. Hugging Face anunció el modo mantenimiento el 11 de diciembre de 2025, archivó el repositorio el 21 de marzo de 2026 y ahora recomienda vLLM y SGLang para servidores, y llama.cpp o MLX para escritorio. Si ya lo tienes en producción, seguirá funcionando, pero sin funciones nuevas ni soporte para arquitecturas recién publicadas.

¿Qué motor encaja en cada caso?

La tabla resume las capacidades documentadas de cada motor y su terreno natural. Ninguna cifra de rendimiento debe tomarse como promesa, porque el mismo motor cambia según la cuantización, el contexto y la tarjeta.

Para decidir, mira primero tus restricciones. Si el modelo cabe justo en la memoria de tu tarjeta, el envoltorio de Ollama puede ser la diferencia entre arrancar o no; si te sobra memoria y quieres velocidad por petición, llama.cpp con los ajustes correctos te devuelve margen.

• Servidor con diez o más usuarios a la vez: vLLM.
• Equipo de sobremesa con una GPU modesta: Ollama para empezar y llama.cpp cuando aprietes.
• CPU sin gráfica dedicada o hardware poco común: llama.cpp compila en casi todo.
• Portátil Mac reciente: Ollama sobre MLX, ya el camino por defecto.

Una regla que ahorra disgustos: no elijas motor por lo que promete su web, sino por la memoria que te sobra, porque el modelo que cabe con holgura rinde más que el que roza el límite.

¿Dónde encaja llama.cpp en Windows ML?

El movimiento de Microsoft merece un apartado propio porque cambia el público. La Text Generation API de Windows ML acepta modelos en GGUF y ONNX y elige el motor por su cuenta: llama.cpp cuando el archivo es GGUF, ONNX Runtime cuando no lo es. Para un desarrollador, eso significa descargar un modelo de Hugging Face y ejecutarlo en una aplicación de Windows sin compilar nada: la API gestiona tokenización, streaming y cancelación.

Los límites están escritos en la propia documentación y no son menores. La integración es experimental, no se admite en producción ni para publicar en la Store, y los únicos backends validados para GGUF son CPU y CUDA de NVIDIA: las NPU de los Copilot+ quedan fuera.

La API tampoco expone todavía temperatura, top-p ni top-k, y solo admite decodificación voraz. No puedes ajustar la creatividad de la respuesta desde esa ruta, aunque llama.cpp por su cuenta sí lo permita.

Microsoft ha contribuido además a llama.cpp con optimización de kernels CUDA, fusión de kernels y soporte multi-GPU. Poco después, el 13 de octubre, Hugging Face presentó Llama Windows, una aplicación de bandeja que arranca un servidor de llama.cpp con API compatible con OpenAI en el puerto 9931.

El motor deja de ser una decisión de expertos

Durante años, elegir motor era una conversación de ingenieros con tiempo libre. Que Windows ML haya escogido llama.cpp para GGUF, que Ollama use MLX por defecto en los Mac y que vLLM empuje para atender a más gente apuntan en la misma dirección: el motor se convierte en una pieza que el sistema elige. Si se vuelve invisible, la competencia se trasladará al formato de los pesos y a los agentes que llaman al modelo. TGI es el recordatorio incómodo: un proyecto puede ser excelente y quedarse sin mantenimiento mientras su comunidad se muda.