Ollama vs vLLM: ¿qué runtime LLM para la producción?

Elegir entre Ollama y vLLM implica sopesar la simplicidad de despliegue frente a la tasa de procesamiento bruta bajo carga concurrente. Esta comparación guía hoy gran parte de las decisiones sobre infraestructura autoalojada en torno a los LLM de pesos abiertos, ya sea para dar servicio a un agente interno o exponer una API multi-tenant. Aquí compararemos los dos entornos de ejecución desde el punto de vista de la arquitectura, de la tasa de procesamiento medible en GPU NVIDIA, de la gestión de memoria (caché KV, PagedAttention), de las licencias y formatos compatibles y de los costos operativos, y terminaremos con recomendaciones según el tamaño del modelo y una sección de preguntas frecuentes técnicas. Nuestro objetivo: permitir a un ingeniero de plataforma tomar una decisión en menos de quince minutos de lectura.

Arquitectura y filosofía: dos runtimes, dos mundos

Ollama es una capa que envuelve llama.cpp, escrito en Go, que expone una API HTTP sencilla y gestiona la descarga, el almacenamiento en caché y la carga dinámica de los modelos GGUF. Históricamente, está orientado a los equipos de los desarrolladores (Mac de la serie M, PC de escritorio con RTX) y a los despliegues ligeros de un solo inquilino. El entorno de ejecución subyacente traslada parte del procesamiento a la CPU de forma transparente, lo que permite ejecutar un Qwen 2.5 72B Instruct (VRAM Q4 ~42 GB) en una RTX 4090 de 24 GB utilizando la RAM del sistema para alojar parte del modelo, a costa de la tasa de generación.

vLLM, publicado por UC Berkeley, es un servidor Python optimizado para el serving de alta concurrencia. Su contribución clave es PagedAttention, que gestiona la caché KV como la memoria virtual de un sistema operativo: bloques de tamaño fijo, paginación y uso compartido entre solicitudes. En concreto, mientras que un entorno de ejecución ingenuo desperdicia entre el 60 % y el 80 % de la caché KV por fragmentación, vLLM reduce esa cifra a menos del 4 %. El resultado es un rendimiento agregado entre 2 y 24 veces mayor según la carga, pero con un coste de entrada: sin cuantización GGUF nativa, dependencia estricta de CUDA y modelo completo en VRAM.

Para profundizar en las diferencias de enfoque entre llama.cpp y vLLM a la hora de servir modelos, consulta nuestro guía completa llama.cpp vs vLLM.

Tasa de procesamiento y latencia: lo que dicen los números

Las mediciones públicas convergen en un punto: bajo carga concurrente, vLLM domina ampliamente. En un Llama 3.3 70B Instruct (70B, ctx 128 000) servido en FP8 en 4× A100 80 GB, se observa habitualmente (por confirmar según el tamaño del lote):

La diferencia se amplía aún más en modelos MoE como Mixtral 8x22B Instruct (141B, Apache 2.0, ctx 64K), en los que vLLM aprovecha el paralelismo tensorial multi-GPU con una eficiencia que a llama.cpp le cuesta alcanzar. Para los modelos MoE muy grandes como DeepSeek V3 671B o Qwen 3 235B-A22B, vLLM sigue siendo la única opción realista en producción multiusuario, especialmente gracias al soporte nativo del paralelismo de expertos.

Sin embargo, para una carga de un solo flujo con cuantización agresiva (Q4_K_M, Q5_K_M), Ollama es competitivo en cuanto a la latencia del primer token (TTFT), que a veces es menor en modelos 7B-13B gracias a la ligereza del runtime. Para un benchmark detallado en GPU de consumo, ver nuestro comparativa RTX 4090 vs RTX 5090 para LLM.

Cuantización, formatos y VRAM real

Aquí es donde los dos runtimes difieren radicalmente. Ollama utiliza exclusivamente GGUF (Q2_K a Q8_0, más FP16). Esta flexibilidad permite alojar un Llama 3.1 70B (~40 GB en Q4) en una sola RTX A6000 de 48 GB. vLLM acepta pesos nativos de HuggingFace (FP16, BF16) y ahora soporta AWQ, GPTQ y FP8, pero no GGUF en producción estable.

Algunas referencias de VRAM en Q4 del catálogo QuéLLM :

Para despliegues modestos, gpt-oss 120B y Mistral Small 4 ofrecen un equilibrio razonable: tamaño manejable, licencia permisiva y compatibilidad con ambos runtimes. Consulta nuestra ficha Mistral Small 4 para ver los benchmarks detallados.

Licencias y cumplimiento

La elección del runtime no afecta a la licencia — es el modelo que establece las condiciones. Casos típicos en producción europea:

Para un panorama completo, ver nuestro guía de licencias de LLM de código abierto y el seguimiento comunitario en Modelos de HuggingFace.

Casos de uso: ¿qué elegir para cada uno?

Elige Ollama si: - Despliegas un asistente interno en un equipo de desarrollo o en una única estación con GPU - Quieres iterar rápidamente con varios modelos (cambio en caliente mediante API) - Tu carga es < 5 usuarios concurrentes - Tienes como objetivo una RTX 3090/4090/5090 o un Mac Studio M3 Ultra - Quieres probar dots.llm1 Instruct (142B, MIT, Rednote) o Hunyuan-A13B Instruct sin configurar un clúster

Elige vLLM si: - Sirves una API detrás de un balanceador de carga con más de 20 solicitudes/segundo - Usas paralelismo tensorial en 2, 4 u 8 GPU - Quieres aprovechar PagedAttention, la decodificación especulativa y el procesamiento continuo por lotes - Buscas ejecutar modelos MoE masivos: DeepSeek V3.2 (685B), Mistral Large 3 675B, Llama 3.1 405B Instruct, Ring-1T (1000B) - Necesitas Llama 4 Scout 109B con su contexto de 10 millones de tokens al servirlo en un entorno multiinquilino

Una tercera opción merece mención: Text Generation Inference de HuggingFace, una opción intermedia entre ambos, con soporte nativo para Mistral Medium 3.5 128B y la familia Llama. Para orquestar un clúster vLLM, Ray Serve sigue siendo la referencia.

Para recomendaciones según el presupuesto de GPU, consulta nuestro guía del configurador y la página mejor LLM para servidor GPU.

Costos operativos y observabilidad

Ollama gana en simplicidad operativa: un único binario, telemetría mínima y actualización del modelo con un solo comando. El coste oculto es la ausencia de métricas detalladas (sin Prometheus nativo en las versiones estables recientes, por confirmar). vLLM expone de forma nativa un endpoint Prometheus con tiempo hasta el primer token, tasa de generación por solicitud y uso de la caché KV, y se integra directamente con Grafana.

En cuanto al costo del GPU, un cluster vLLM bien ajustado reduce el costo por millón de tokens en un factor de 3 a 8 en comparación con un despliegue Ollama equivalente en múltiples instancias —la diferencia proviene del batching continuo y de la casi ausencia de fragmentación KV. En Qwen3-Coder-Next 80B-A3B (MoE, Apache 2.0), nuestros lectores informan (por confirmar) ~14 000 tokens/seg en total en 2× H100 con vLLM, frente a ~80 tokens/seg en flujo único con Ollama y una RTX 6000 Ada.

Para profundizar en el ajuste, consultar el blog oficial de vLLM y nuestro comparación vLLM vs TGI.

FAQ

P: ¿Puede Ollama atender a varios usuarios simultáneamente en producción?

Técnicamente sí, pero con limitaciones. Ollama maneja varias solicitudes a través de una cola interna, sin batching continuo eficaz. Más allá de 3-5 usuarios concurrentes en un modelo de 70B como Llama 3.3 70B Instruct, la latencia p95 empeora considerablemente. Para un entorno de producción multi-tenant serio, vLLM o TGI siguen siendo las opciones técnicamente justificadas.

P: ¿Admite vLLM cuantizaciones agresivas como Q4 GGUF?

No en formato nativo GGUF. vLLM prefiere FP8, AWQ y GPTQ, que ofrecen un equilibrio calidad/VRAM diferente. En DeepSeek R1 671B, existe una versión oficial AWQ de 4 bits en HuggingFace y funciona con vLLM. Para usar estrictamente GGUF Q4_K_M, quédate directamente con Ollama o llama.cpp — es su especialidad.

P: ¿Qué runtime para un MoE como Qwen 3 235B-A22B?

vLLM, sin dudarlo. Los modelos MoE se benefician enormemente del paralelismo de expertos y del batching continuo que vLLM implementa de forma nativa. Qwen 3 235B-A22B (Apache 2.0, ctx 131K) alcanza una tasa de generación agregada a la que Ollama no puede acercarse, ni siquiera en un clúster de 8× H100. Ver nuestra ficha Qwen 3 235B-A22B.

P: ¿Se puede usar Ollama en un clúster de Kubernetes?

Sí, existen charts de Helm comunitarios, pero Ollama no fue diseñado para el escalado horizontal sin estado. Cada pod vuelve a cargar sus modelos y la caché GGUF no se comparte. Para una integración nativa con Kubernetes, vLLM se integra mejor mediante KServe y su operador dedicado.

P: ¿Qué runtime elegir para Llama 4 Scout 109B y su contexto de 10M?

vLLM con atención dispersa activada. El contexto de 10M de Llama 4 Scout 109B requiere una gestión de la caché KV que solo PagedAttention hace económicamente viable. Técnicamente, Ollama puede cargar el modelo, pero la caché KV para 10M tokens dispara el consumo de VRAM sin paginación. Reservar para vLLM o TGI.

P: ¿Existe una alternativa a ambos para los Mac Apple Silicon?

Sí: MLX de Apple está optimizado para Metal y supera a Ollama en M3 Ultra con modelos como DeepSeek R1 Distill Llama 70B. Pero la inferencia para múltiples usuarios en Mac sigue siendo un uso de nicho. Ver nuestra guía de LLM para Mac M3 Ultra.

Conclusión

El debate Ollama vs vLLM se resuelve según la carga de trabajo prevista: Ollama para el prototipado, el uso por un solo usuario y los Mac; vLLM cuando se trata de API multi-tenant, modelos MoE masivos o paralelismo tensorial. Para identificar la combinación de modelo y runtime adecuada para tu VRAM y la licencia que buscas, abre nuestro configurador o explora los 249 modelos indexados en el catálogo QuéLLM.

Artículo publicado el por Mohamed Meguedmi · Fuente de datos: /api/models.json · Licencia del contenido: CC BY 4.0.

¿Tienes algún error o alguna actualización que comunicar? Colaborar.