Ollama vs vLLM: cuál elegir para servir modelos de IA

Ollama vs vLLM: ¿cuál conviene elegir?

Quédate con Ollama para una laptop, un asistente privado o un pequeño servicio interno que ya responda con suficiente rapidez. Elige vLLM para un servicio compartido con GPU que reciba solicitudes simultáneas de forma sostenida, o si necesitas controlar de manera explícita la inferencia distribuida. Que una máquina tenga nombre de servidor no es motivo suficiente para cambiar.

Ollama permite ejecutar modelos y reúne su descarga, configuración y puesta en servicio en un flujo sencillo. vLLM es un motor de inferencia diseñado para planificar muchas solicitudes y gestionar la memoria de trabajo que necesitan. Ninguno de los dos es el modelo: al pasar una misma aplicación de uno a otro, cambia la forma de ejecutarlo.

La decisión depende de cuatro factores: el máximo de solicitudes simultáneas, la memoria GPU disponible, el paquete concreto del modelo y la latencia que prometes a los usuarios. El número de usuarios registrados dice poco al respecto. Un grupo pequeño de programación que use agentes puede generar más trabajo simultáneo que otro mucho mayor que haga preguntas de vez en cuando.

Costos de software y documentación verificados el 12 de octubre de 2026. Esta comparativa se basa en la documentación y en un ejemplo desarrollado de análisis de costos; no se realizó ninguna prueba de rendimiento de inferencia para este artículo. La página de precios de Ollama incluye el uso local gratuito, y la licencia del proyecto vLLM permite usarlo sin pagar por el software. Precios de Ollama, licencia de vLLM.

Las funciones de la tabla proceden de la documentación oficial sobre concurrencia de Ollama, la descripción de funciones de vLLM y la guía de escalado de vLLM. Las recomendaciones son valoraciones editoriales de esas capacidades documentadas, no una clasificación basada en mediciones de velocidad.

Cómo decidir según los usuarios, las GPU y el tamaño del modelo

Estos escenarios sirven para decidir qué evaluar primero; no garantizan una capacidad determinada. Aquí, «usuarios» se refiere a personas o agentes que generan trabajo simultáneo. Los rangos son ejemplos de planificación. Un modelo 8B tiene aproximadamente ocho mil millones de parámetros: los valores numéricos almacenados que lo definen.

El tamaño del modelo, por sí solo, no basta para decidir qué GPU comprar. Un modelo denso 8B idealizado, con 4 bits por peso, tiene un mínimo de 4 GB solo para los pesos; en un modelo 70B, ese mínimo es de 35 GB. El cálculo es parámetros × bits ÷ 8, expresado en bytes decimales. A ese mínimo se suman los metadatos de cuantización, los tensores de mayor precisión, el entorno de ejecución y la memoria de las conversaciones. Ninguna de esas cifras es una recomendación de VRAM.

Por eso, que «el modelo haya cargado» es un criterio de aceptación insuficiente. La máquina puede alojar los pesos y aun así quedarse sin espacio para las conversaciones que los usuarios mantienen abiertas. Elige primero la versión del modelo con la guía de modelos locales para programación y después dimensiona la carga que tendrá que atender.

Instalación y hardware: Ollama facilita la primera puesta en marcha

Ollama tiene ventaja cuando lo urgente es ejecutar un modelo útil en el hardware que ya tienes. Sus descargas para escritorio y su flujo por línea de comandos reducen las decisiones de despliegue. En Linux, el instalador documentado es:

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.2

Usa ollama serve si el servidor aún no está en ejecución. La guía de Linux también explica cómo configurar un servicio de inicio. Para atender solicitudes de otras personas, un servicio persistente resulta más adecuado que dejar una terminal abierta.

Ollama admite aceleración con GPU de Apple mediante Metal, determinados equipos AMD mediante ROCm, GPU NVIDIA y otros dispositivos Windows/Linux mediante Vulkan. Su página de NVIDIA indica actualmente una capacidad de cómputo de 5.0 o superior, con requisitos de controladores que varían en las tarjetas antiguas. Comprueba la tarjeta y el sistema operativo concretos en la lista de hardware de Ollama.

vLLM tiene ventaja cuando la instalación es el primer paso para montar un entorno de servicio administrado. Su guía de inicio para NVIDIA utiliza actualmente un entorno Python aislado. Con uv instalado y un controlador de GPU compatible, la secuencia documentada es:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

Estos comandos proceden de la documentación; no se ejecutaron para esta comparativa. Las instalaciones en AMD e Intel siguen instrucciones específicas para cada backend. Guía de inicio de vLLM.

La instalación de vLLM para NVIDIA exige Linux y una capacidad de cómputo de 7.5 o superior. Esta vía no admite Windows de forma nativa; la documentación remite a sus usuarios a WSL. NVIDIA no es la única opción de hardware: el índice de instalación también cubre AMD ROCm, Intel XPU, ejecución en CPU y Apple Silicon mediante el plugin vLLM-Metal, mantenido por la comunidad. Requisitos de GPU, índice de instalación.

La vía para Apple utiliza MLX y modelos optimizados para MLX. Hay que evaluarla como un backend propio, sin dar por hecho que se comportará como un servidor CUDA. Si el trabajo se centra en Mac, Ollama sigue siendo la recomendación inicial más sencilla. Si la decisión gira sobre todo en torno al entorno de escritorio, consulta la comparativa entre Ollama y LM Studio.

Rendimiento de vLLM vs Ollama: la diferencia está en la concurrencia

vLLM es el punto de partida más sólido para atender solicitudes simultáneas de forma sostenida, porque sus funciones documentadas de planificación están diseñadas para esa carga. La capacidad de procesamiento, o throughput, mide el trabajo total completado por unidad de tiempo. No equivale a la rapidez con la que aparece una respuesta aislada.

vLLM incluye la agrupación continua en lotes, que incorpora trabajo a medida que avanzan las solicitudes en curso, y PagedAttention, que gestiona la caché de claves y valores utilizada durante la generación de texto. Esa caché, normalmente llamada caché KV, es la memoria de trabajo del modelo para los tokens de la conversación. Descripción de funciones de vLLM.

El procesamiento inicial por bloques, o chunked prefill, divide la lectura de un prompt largo en partes más pequeñas que pueden compartir tiempo de ejecución con la generación de respuestas en curso. La caché de prefijos reutiliza el procesamiento de inicios de prompt idénticos, como un prompt de sistema que se repite. Ayuda a procesar el prompt, pero no elimina el trabajo de generar nuevos tokens de respuesta. Planificación y ajustes, límites de la caché de prefijos.

Ollama ya permite atender solicitudes en paralelo

Ollama documenta tanto las solicitudes paralelas por modelo como la carga simultánea de varios modelos, siempre que haya memoria suficiente. OLLAMA_NUM_PARALLEL controla lo primero; OLLAMA_MAX_LOADED_MODELS, lo segundo. OLLAMA_MAX_QUEUE limita el trabajo en espera, y un servidor sobrecargado puede devolver HTTP 503. Las preguntas frecuentes indican actualmente un valor predeterminado de 1 para las solicitudes paralelas. Ajustes de concurrencia de Ollama.

Para un pequeño asistente de soporte, aumentar las solicitudes simultáneas permitidas puede ser suficiente. Pero alargar la cola no añade capacidad de cómputo: puede limitarse a hacer que los clientes esperen más hasta recibir el primer token. Ajusta la configuración para cumplir el objetivo de respuesta, no para admitir la mayor cola posible.

El contexto puede agotar la memoria que reservabas para más usuarios

Fija el contexto de forma explícita antes de comparar los motores. La página de Ollama dedicada al contexto describe valores predeterminados que dependen de la memoria, mientras que sus preguntas frecuentes siguen indicando un valor fijo. Esa discrepancia es otro motivo para revisar la configuración efectiva en lugar de suponer que la laptop y el servidor coinciden. ollama ps muestra el contexto cargado y cómo se reparte la ejecución entre CPU y GPU. Guía de contexto de Ollama.

Como ejemplo de configuración, cuatro conversaciones paralelas de 8,192 tokens reservan capacidad para 32,768 tokens de contexto. Frente a una sola conversación de 4,096, eso supone ocho veces la capacidad agregada de contexto, no ocho veces la RAM total del proceso. Los pesos del modelo y otras asignaciones de memoria no crecen de la misma manera. La documentación de concurrencia de Ollama explica este multiplicador del contexto.

vLLM también puede quedarse sin memoria. Su guía de ajustes advierte que la falta de espacio para la caché KV puede obligar a interrumpir y recalcular trabajo, lo que empeora la latencia. Una opción es reducir las secuencias simultáneas o el límite de tokens por lote; otra, añadir GPU. Por más capaz que sea el planificador, no puede crear memoria que la máquina no tiene.

La señal para cambiar es incumplir el objetivo del servicio con una carga máxima representativa, después de ajustar la configuración de forma razonable. Registra el tiempo hasta el primer token, el tiempo hasta completar la respuesta, las solicitudes exitosas, el crecimiento de la cola y los errores. Compara un percentil alto además de la mediana, porque los usuarios perciben los casos lentos. vLLM ofrece métricas de producción para hacerlo.

Mantén equivalentes la revisión del modelo, la precisión, la longitud de los prompts, los límites de salida y el patrón de tráfico. Comparar un modelo pequeño cuantizado en Ollama con uno mayor y de alta precisión en vLLM sirve para comparar despliegues, pero no para medir de forma aislada los motores.

Formatos cuantizados: trasladar el modelo también forma parte de la migración

Ollama tiene ventaja para conservar un paquete de modelo local que ya funciona; vLLM, para elegir un formato de servicio específico para el hardware. La cuantización almacena los valores del modelo con menor precisión para reducir la memoria necesaria. El contenedor del archivo, el método de cuantización y el backend de ejecución plantean cuestiones de compatibilidad distintas.

Ollama documenta la importación de pesos Safetensors y de modelos GGUF tanto en un solo archivo como divididos en varios. GGUF es un formato de archivo de modelo habitual en la inferencia local; la guía de importación actual de Ollama indica que la cuantización GGUF debe hacerse antes de importar, no durante el proceso. Por separado, su API de creación menciona nvfp4 como ejemplo de cuantización durante la importación. Eso no garantiza que todas las arquitecturas y GPU admitan esa vía. Guía de importación de Ollama, API de creación.

Ollama también menciona f16, q8_0 y q4_0 para su caché KV. Son ajustes de la caché, no una lista intercambiable de formatos para los pesos del modelo. Para usar una caché cuantizada se necesita Flash Attention. Documentación de la caché de Ollama.

vLLM incluye integraciones de cuantización AWQ/GPTQ, FP8, INT8, INT4, MXFP4/MXFP8, NVFP4 y otras. La matriz de compatibilidad depende de la implementación y del hardware, así que «admite 4 bits» no basta para decidir una compra. Comprueba la combinación exacta de la versión del modelo y el kernel. Documentación de cuantización de vLLM, descripción de formatos.

Un tokenizador convierte el texto en los identificadores de tokens que entiende el modelo. Cambiar los pesos, el tokenizador, el formato del chat o la cuantización puede alterar las respuestas, las llamadas a herramientas y el uso de memoria. Reserva tiempo para pruebas de regresión aunque el nombre de la familia del modelo siga siendo el mismo.

Mellum2.1 muestra por qué importa cómo se publica un modelo

El anuncio de Mellum2.1 de JetBrains del 8 de octubre de 2026 ilustra el patrón de lanzar primero para servidores: la publicación indicaba que las versiones GGUF para Ollama, llama.cpp y LM Studio llegarían pronto. La página del modelo ofrece instrucciones para servirlo con vLLM, y las integraciones del lanzamiento incluyen vLLM y SGLang, otro servidor de inferencia. Anuncio de JetBrains, página del lanzamiento.

Esa brecha inicial ya se ha reducido: el repositorio oficial GGUF de JetBrains contiene archivos cuantizados para descargar, según la comprobación del 12 de octubre. No interpretes el «próximamente» del anuncio como una descripción de la disponibilidad actual. La lección práctica es comprobar los archivos disponibles y las instrucciones para servirlos antes de cambiar de motor solo para acceder a un modelo nuevo. Archivos GGUF oficiales.

Servidores compatibles con OpenAI: conserva el cliente y verifica el comportamiento

Ambos documentan un servidor compatible con OpenAI, pero compartir el formato de las solicitudes no garantiza el mismo comportamiento. La URL base local de Ollama es http://localhost:11434/v1/; el ejemplo de vLLM utiliza http://localhost:8000/v1. Si tu aplicación usa la API nativa /api/chat de Ollama, migrar exige adaptar la API, no solo cambiar de puerto. Compatibilidad de Ollama, documentación del servidor de vLLM.

Por ejemplo, después de instalar vLLM en hardware compatible, este comando sirve el modelo del ejemplo documentado de servidor, con un límite de contexto explícito y un nombre para la aplicación:

vllm serve NousResearch/Meta-Llama-3-8B-Instruct \
  --host 127.0.0.1 \
  --port 8000 \
  --max-model-len 8192 \
  --served-model-name app-model

Es un ejemplo de configuración: no utiliza la misma versión del modelo que el comando anterior de Ollama ni constituye una recomendación de dimensionamiento para producción. --served-model-name permite al cliente conservar un nombre de modelo estable aunque cambie el despliegue. Argumentos del motor de vLLM.

Revisa las plantillas de chat, que convierten los roles de los mensajes al formato de entrada del modelo, y fija los parámetros de muestreo de forma explícita. vLLM puede aplicar los valores predeterminados de generation_config.json del repositorio; --generation-config vllm desactiva esa sustitución. Comprueba el análisis de llamadas a herramientas, la salida estructurada, el streaming, la cancelación y la gestión de errores con las solicitudes reales de la aplicación.

Incluye la autenticación en la migración. El ejemplo local de compatibilidad de Ollama ignora el valor de la clave API del cliente. vLLM admite una clave API, pero su documentación de seguridad advierte que no protege todos los endpoints. Mantén el backend en una red privada y aplica autenticación, TLS y restricciones de rutas en el punto de entrada al servicio. Limitaciones de la clave API de vLLM.

Si tu aplicación cambia a menudo de modelo base, hay otro costo de migración: las preguntas frecuentes de vLLM describen el uso de instancias de servidor independientes y una capa de enrutamiento para trabajar con varios modelos base. Un alias de API no carga otro modelo. La capacidad de Ollama para gestionar varios modelos cargados puede resultar más cómoda para una herramienta interna de uso esporádico. Limitación de vLLM con varios modelos.

Diferencias de precio: la misma carga, distintos costos de operación

Ninguno gana por cobrar menos por token en infraestructura propia: el motor no factura tokens. Los planes de pago en la nube de Ollama son un servicio aparte, no un requisito para servir modelos locales. La guía de precios de Ollama explica esa diferencia; para consultar las ofertas actuales en la nube, usa la página del proveedor enlazada más arriba.

Con hardware propio, el costo mensual incluye electricidad, la parte del costo del equipo que le corresponde al servicio y tu tiempo. Con hardware alquilado, empieza por las horas de máquina presupuestadas y añade almacenamiento, red y operación. Una inferencia más eficiente solo ahorra dinero si permite reducir los recursos contratados, acortar el tiempo facturable o aportar un beneficio al negocio al que puedas asignar un valor.

Un ejemplo de presupuesto con condiciones equivalentes

Los siguientes datos son supuestos explícitos de presupuesto, no precios de proveedores ni resultados de pruebas de rendimiento: una GPU a $1 por hora, 730 horas al mes y 100,000 trabajos completados correctamente. Cada trabajo tiene 2,000 tokens de entrada y 1,000 tokens de salida, con el mismo modelo, cuantización, nivel de calidad y objetivo de latencia en ambos motores.

Si ambos cumplen los requisitos con una GPU alquilada de forma continua, cada uno cuesta $730 al mes en cómputo, o $0.0073 por trabajo completado correctamente y por 1,000 tokens de salida. Al calcular por tokens de salida se mantiene constante el trabajo del prompt; no es una tarifa combinada de entrada y salida.

Ahora añade al presupuesto dos horas mensuales de operación para el despliegue de vLLM, a un costo supuesto de $100 por hora, más cuatro horas de migración por única vez:

• Despliegue de referencia con Ollama: $730 recurrentes, antes de los costos comunes a ambos.
• vLLM en el mismo hardware: $930 recurrentes, o $0.0093 por 1,000 tokens de salida.
• Primer mes de vLLM, incluida la migración: $1,330, o $0.0133 por 1,000 tokens de salida.

Esas horas son datos que debes sustituir por tu propia estimación, no una afirmación sobre cuánto tarda una migración. En ambos casos se excluyen las tareas de operación comunes, el almacenamiento, los cargos de red y los impuestos.

Cuándo cambia la opción más económica

Con esa tarifa por hora, vLLM debe ahorrar más de 200 horas de GPU al mes para compensar el trabajo de operación adicional supuesto. Recuperar los $400 completos de la migración en el primer mes eleva el umbral a más de 600 horas de GPU ahorradas.

Para un servicio siempre activo, supongamos que tu propia prueba de carga muestra que Ollama necesita dos réplicas con GPU idénticas, mientras que vLLM necesita una para atender la misma carga con el mismo objetivo de respuesta. El cómputo de Ollama pasa a costar $1,460; el cómputo de vLLM más la operación adicional se mantiene en $930. En esas condiciones, el ahorro es de $530 al mes, con lo que se recuperan los $400 de migración en unos 0.75 meses.

Ese es un cálculo del punto de equilibrio, no una afirmación de que vLLM reduzca a la mitad las GPU que necesitas. Si ambos requieren el mismo hardware y ningún otro beneficio justifica el cambio, comparar los costos del software nunca inclina la balanza a favor de vLLM. No hay un número de usuarios que marque un punto de cambio universal y defendible.

Lista breve para migrar de Ollama a vLLM

Migra un modelo y un contrato de API ya validados mediante una ruta que permita volver atrás. Los pesos descargados son solo una parte de lo que necesitan tus usuarios.

Espera para migrar si Ollama cumple el objetivo del servicio, si el modelo necesario no tiene una vía validada en vLLM o si el cambio solo sustituiría un paquete que funciona por un backend desconocido. También puede ser razonable mantener Ollama en las laptops y vLLM en un servidor compartido, siempre que pruebes sus diferencias en lugar de asumir que desarrollo y producción son idénticos. Para ampliar la selección, consulta las alternativas a Ollama.

El siguiente paso es concreto: registra la carga representativa de mayor actividad, define su tiempo de respuesta aceptable y reprodúcela en el servidor propuesto antes de comprar más capacidad.

Preguntas frecuentes

Usa la lista de verificación para auditar flujos de trabajo empresariales con IA para decidir qué flujo privado merece un servidor de modelos compartido y suscríbete al boletín para seguir los próximos cambios en las herramientas.