Ollama frente a vLLM: cuál elegir para servir LLM

Ollama frente a vLLM, en un párrafo

Ollama es un gestor de modelos con un servidor integrado: descarga los pesos cuantizados, los carga y responde en 127.0.0.1:11434, incluso en una CPU si es todo lo que tiene el equipo. vLLM es un motor de rendimiento: mantiene una GPU ocupada con muchas peticiones ejecutándose al mismo tiempo, y es la herramienta incorrecta en una máquina que no tiene GPU. Esa es toda la decisión. Una persona que habla con un asistente local es un trabajo para Ollama. Una aplicación que presta servicio a un equipo es un trabajo para vLLM.

Ambos exponen una API HTTP compatible con OpenAI, por lo que el código cliente puede pasar de uno a otro cambiando la URL base. La API no es la diferencia. La diferencia es lo que ocurre cuando llega una segunda petición mientras la primera todavía está generando tokens.

Qué es realmente Ollama

Ollama es una capa de conveniencia. Proporciona un registro de modelos (ollama pull llama3.1:8b), un almacén local de pesos, un prompt de chat, un servicio de systemd y una API HTTP mediante un único comando de instalación. Los modelos que sirve son archivos GGUF, normalmente cuantizados a 4 bits. Por eso, un modelo 7B u 8B ocupa alrededor de 5 GB en disco en lugar de 16 GB. La cuantización es lo que hace posible la inferencia en la CPU.

Su runner se basa en llama.cpp, la biblioteca de inferencia en C++ que hizo práctica la cuantización GGUF en hardware convencional. Desde entonces, Ollama ha añadido su propio motor para algunas familias de modelos más recientes, pero llama.cpp sigue siendo la base de gran parte de lo que sirve. Por tanto, cuando se compara Ollama con llama.cpp, en la mayoría de los casos se compara una capa de ergonomía con el componente que envuelve.

El diseño está orientado a un usuario. En julio de 2026, el valor predeterminado de OLLAMA_NUM_PARALLEL es 1. Esto significa que un modelo procesa una petición cada vez y que el resto espera en una cola que contiene 512 entradas de forma predeterminada (OLLAMA_MAX_QUEUE). Puede aumentar el valor de paralelismo. La sección siguiente explica qué coste tiene hacerlo. Si todavía no ha ejecutado Ollama, empiece por alojar Ollama en un VPS y mantener cerrado el puerto 11434, porque la API no tiene ningún tipo de autenticación.

Qué es realmente vLLM

vLLM es un servidor de inferencia y nada más. No administra una biblioteca de modelos, no incluye una plantilla de chat y no descargará un modelo por usted durante una solicitud. Al iniciar el servidor, se especifica un repositorio de Hugging Face. vLLM carga ese único modelo y lo sirve hasta que se detiene el proceso.

La ventaja de esta especialización es el rendimiento. Dos mecanismos hacen posible este resultado. PagedAttention almacena la caché KV (caché de clave-valor, el estado de atención por token que un modelo mantiene para cada solicitud activa) en bloques de tamaño fijo, como hace un sistema operativo al paginar la memoria. Una solicitud ya no necesita una reserva contigua grande dimensionada para el peor caso. Por tanto, la memoria que antes permanecía reservada y sin utilizar queda disponible para más solicitudes simultáneas. Continuous batching permite que una solicitud nueva se incorpore al lote en ejecución en el siguiente paso de decodificación, en lugar de esperar a que termine el lote actual. Una secuencia finalizada abandona el lote de inmediato y su espacio se reasigna.

El resultado práctico es el siguiente: en una sola GPU, pasar de un usuario simultáneo a treinta aumenta considerablemente el total de tokens por segundo, mientras que la velocidad por usuario disminuye mucho menos de lo esperado. Con la configuración predeterminada de Ollama, pasar de un usuario a treinta sólo hace que veintinueve personas esperen.

El batching continuo marca toda la diferencia

Imagine cinco solicitudes llegando a cada servidor al mismo tiempo y con hardware idéntico.

Con la configuración predeterminada, Ollama ejecuta la primera solicitud hasta completarla, después la segunda y así sucesivamente. El quinto usuario espera a que terminen cuatro generaciones completas. El rendimiento total se aproxima a la velocidad de una sola generación, porque el procesador sólo trabaja con una secuencia cada vez.

vLLM decodifica las cinco en el mismo paso forward. Generar un token para cinco secuencias cuesta apenas más que generar un token para una secuencia, porque la parte costosa es leer los pesos del modelo desde la memoria, y esa lectura se comparte entre todo el batch. Este es el mismo hecho relacionado con el ancho de banda de memoria que hace lenta la inferencia en la CPU: el coste principal está en mover los pesos, no en realizar las operaciones aritméticas.

Puede configurar OLLAMA_NUM_PARALLEL=4 y obtener parte de este comportamiento. El coste es la memoria. Cada ranura paralela necesita su propia caché KV, y Ollama divide la ventana de contexto entre las ranuras. Por tanto, cuatro solicitudes paralelas contra un modelo configurado para 8192 tokens dejan 2048 tokens de contexto para cada solicitud. Esos 8192 tokens también son una elección, no un valor predeterminado inevitable. Por eso, aumentar num_ctx y dimensionar la RAM que requiere es el paso que determina si cuatro ranuras son realmente utilizables. La caché paginada de vLLM evita esta disyuntiva, porque los bloques se asignan a una solicitud a medida que esta crece. En cualquier caso, el límite de usuarios que un solo equipo puede atender simultáneamente depende del tamaño de la caché KV, el coste del prefill y la profundidad de la cola. Esto explica por qué un servidor que funcionaba bien para una persona se ralentiza con cinco.

Instalar y servir con Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

El script de instalación crea un usuario de sistema ollama, instala el binario y registra ollama.service, enlazado a 127.0.0.1:11434. La línea eval rate que muestra --verbose indica los tokens por segundo reales en ese equipo. Dé prioridad a ese valor frente a cualquier cifra publicada. Una medición con una sola petición es un punto de partida, no una medida de capacidad. Por eso, medir los tokens por segundo con distintos niveles de concurrencia permite saber si el equipo soporta la carga prevista y si alquilar una GPU resulta más rentable que pagar por token.

Para aumentar la concurrencia, use un drop-in de systemd. Así, una actualización no sobrescribirá el cambio:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps muestra la configuración cargada y su columna PROCESSOR refleja el valor real. 100% CPU significa que no se utiliza ninguna GPU. Esta es la explicación habitual de la lentitud de Ollama. La línea OLLAMA_KEEP_ALIVE=30m de ese drop-in también es importante en un equipo con poca carga, porque la configuración predeterminada descarga el modelo después de cinco minutos sin peticiones. Mantener el modelo residente entre peticiones evita que la primera petición después de una hora de inactividad tenga que volver a pagar todo el tiempo de carga.

Instalar y servir con vLLM

vLLM necesita Linux y Python 3.10 a 3.13. Instálelo en su propio entorno virtual porque requiere una compilación específica de PyTorch:

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

Después, sirva un modelo. El nombre es un ID de repositorio de Hugging Face, no una etiqueta corta:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

El primer arranque es lento porque descarga los pesos y después perfila la GPU para determinar cuántos bloques de caché KV caben. Escucha en el puerto 8000. Compruébelo antes de escribir código de cliente:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

Si Docker ya está instalado en el servidor, la imagen oficial evita tener que resolver las dependencias de CUDA:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host es obligatorio, no decorativo: PyTorch pasa tensores entre procesos mediante memoria compartida, y la asignación predeterminada de memoria compartida de Docker es demasiado pequeña para la inferencia con paralelismo de tensores.

Los indicadores más importantes en producción son --max-model-len (la ventana de contexto por la que está dispuesto a pagar), --gpu-memory-utilization (la fracción de la tarjeta que vLLM puede utilizar, 0.92 de forma predeterminada desde julio de 2026), --tensor-parallel-size para distribuir un modelo entre varias GPU y --api-key.

La autenticación se configura con una opción en vLLM y no existe en Ollama

vLLM exige un token bearer si se le proporciona uno:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

El mismo valor puede proceder de la variable de entorno VLLM_API_KEY. Las solicitudes que no lo incluyen reciben HTTP 401. Esto no justifica publicar el puerto 8000 en una interfaz pública, porque vLLM no aplica límites de tasa y un token enviado mediante HTTP sin cifrar puede leerse durante el tránsito. Sin embargo, significa que el servidor identifica al cliente que realiza la solicitud.

Ollama no ofrece ninguna autenticación. No hay clave, inicio de sesión ni lista de permitidos. Cualquier proceso que pueda acceder al puerto 11434 puede ejecutar, descargar o eliminar modelos. Manténgalo en loopback y acceda a él mediante una VPN WireGuard alojada por usted, o a través de un reverse proxy con autenticación que termine TLS (seguridad de la capa de transporte).

Hardware: qué necesita cada uno

Ollama se ejecuta en la CPU. Un modelo cuantizado a 4 bits consume aproximadamente medio gigabyte de RAM por cada mil millones de parámetros, más cerca de un gigabyte de sobrecarga en ejecución y memoria adicional para el contexto. Por tanto, un modelo 3B necesita alrededor de 4 GB libres y uno 8B, alrededor de 8 GB. En una vCPU compartida, la velocidad es de un dígito bajo a dos dígitos bajos de tokens por segundo. Esto se debe al ancho de banda de memoria, no a una mala configuración, y ningún flag lo corrige. Para comprobar cómo se aplica ese cálculo a una versión concreta en lugar de usar una regla general, ejecutar Nemotron 3.5 Lightning en una VPS fija el tag exacto que se debe descargar, la RAM que ocupa una vez cargado y si el modo exclusivo de CPU ofrece una velocidad aceptable.

vLLM presupone una GPU. Su ruta predeterminada sirve pesos sin cuantizar con una precisión de 16 bits, lo que equivale aproximadamente a 2 GB por cada mil millones de parámetros: un modelo 8B necesita unos 16 GB de memoria de vídeo sólo para los pesos, antes de contar la caché KV que proporciona la concurrencia para la que instaló vLLM. En una tarjeta de 24 GB queda suficiente caché para trabajar. En una tarjeta de 16 GB no, así que debe elegir un modelo más pequeño o pasar --quantization con un checkpoint cuantizado. Existe un backend para CPU, pero los wheels estándar no están compilados para él y elimina el motivo principal para usar vLLM.

Por tanto, la cuestión del hardware responde casi siempre a la cuestión del software. Sin GPU, use Ollama. Si una GPU alquilada permanece al 5 por ciento de utilización porque las solicitudes se procesan en serie, use vLLM.

Qué opción elegir según la carga de trabajo

• Una sola persona, un VPS con CPU, para redactar y resumir: Ollama. El ritmo es aceptable y no hay una opción más sencilla.
• Un asistente de programación, o un servidor MCP que conecte sus herramientas con un modelo local, al que sólo usted accede: Ollama. La concurrencia de uno es la carga de trabajo real.
• Comparar cinco modelos esta semana: Ollama. Descargar y eliminar modelos etiquetados es exactamente para lo que está diseñado, mientras que vLLM necesita reiniciar el proceso para cada modelo.
• Una aplicación interna, un producto de chat o una canalización de recuperación con usuarios reales: vLLM. En este caso, el procesamiento por lotes justifica el coste de la GPU.
• Un trabajo por lotes que puntúa cien mil documentos durante la noche: vLLM, con un --max-num-seqs alto. El rendimiento es la única métrica importante y la latencia por documento no lo es.
• Una plataforma de agentes en la que varios agentes de IA autohospedados acceden al modelo al mismo tiempo: vLLM, porque el tráfico de los agentes es variable y paralelo por naturaleza.

Modos de fallo y cadenas que verá

vLLM no arranca y muestra un error de caché KV. El mensaje incluye ambos números:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

El modelo declara una ventana de contexto mayor que la memoria disponible después de cargar los pesos. Redúzcala con --max-model-len 8192 o aumente --gpu-memory-utilization si ningún otro proceso usa la GPU. Superar aproximadamente 0.95 de utilización suele convertir este error de arranque en un fallo posterior de memoria insuficiente de CUDA bajo carga, que es la peor de las dos situaciones.

Ollama muestra Killed durante la generación. El asesino de procesos por falta de memoria de Linux detuvo el proceso porque el modelo necesitaba más RAM de la disponible en el equipo. Confírmelo con sudo dmesg | grep -i oom. La solución es usar un modelo más pequeño o con una cuantización más agresiva, no cambiar un ajuste.

Ollama responde correctamente por sí solo, pero se bloquea bajo carga. No aparece ningún error. Las peticiones simplemente tardan más cuantos más clientes hay, porque OLLAMA_NUM_PARALLEL=1 las serializa. Las respuestas largas empeoran la cola. Un cliente que mantiene el único puesto ocupado hasta que el modelo decide detenerse bloquea a todos los demás. Por eso, limitar la respuesta con num_predict establece un máximo para el tiempo que cada turno puede mantener ocupado el servidor. Aumente el ajuste de paralelismo y acepte un contexto menor por petición, o traslade la carga de trabajo a vLLM.

vLLM devuelve 401 en todas las llamadas. Lo inició con --api-key, pero el cliente no envía ninguna cabecera Authorization. La mayoría de las bibliotecas cliente de OpenAI envían como clave el valor que se les proporciona. Configúrela allí en lugar de eliminar el indicador.

vLLM indica que no encuentra el modelo. Ollama descarga los modelos bajo demanda; vLLM no lo hace. El campo model del cuerpo de la petición debe coincidir con el ID del repositorio usado al iniciar el servidor o con el valor de --served-model-name, si lo configuró. Confirme la cadena exacta con curl http://localhost:8000/v1/models.

Ejecutar ambos es una opción razonable

No son excluyentes. Una arquitectura habitual usa vLLM en una instancia con GPU para atender la aplicación y Ollama en el VPS convencional junto a ella para scripts locales, tareas de cron y pruebas de nuevas versiones de modelos. Ambos endpoints son compatibles con OpenAI, por lo que una sola biblioteca cliente y cambiar la URL base permiten usar los dos. El control de costes es más importante en este caso que cualquiera de los dos motores, porque una GPU inactiva se factura igual que una GPU ocupada, y mantener previsibles los costes de los agentes y la inferencia es una disciplina distinta de elegir un servidor.

FAQ

¿vLLM es más rápido que Ollama?

Para una sola petición en la misma GPU, la diferencia es moderada, ya que ambos realizan las mismas operaciones. Para muchas peticiones simultáneas, vLLM es muy superior porque el batching continuo decodifica cada secuencia activa en un solo paso forward, mientras que la configuración predeterminada de Ollama las ejecuta una tras otra. En una máquina que sólo usa CPU, la pregunta no se aplica: Ollama funciona allí y vLLM, en la práctica, no.

¿Puede vLLM funcionar sin una GPU?

No de forma útil. Los wheels estándar están dirigidos a GPU NVIDIA o AMD, y en una CPU desaparece el motivo de existencia de vLLM: mantener un acelerador ocupado con peticiones agrupadas. Existe un backend de CPU para trabajos de desarrollo. Para inferencia real en CPU, use Ollama o llama.cpp directamente.

¿Cuál es la diferencia entre Ollama y llama.cpp?

llama.cpp es la biblioteca de inferencia, y GGUF es su formato de pesos cuantizados. El runner de Ollama se basa en ella y añade las partes que llama.cpp deja a cargo del usuario: un registro de modelos, descargas automáticas, un servidor residente, una unidad de systemd y un endpoint compatible con OpenAI. Ollama ha añadido su propio motor para algunas familias de modelos más recientes, por lo que ya no son idénticos internamente.

¿Cuánta memoria de GPU necesita vLLM para un modelo 8B?

Con una precisión de 16 bits, sólo los pesos ocupan unos 16 GB, aproximadamente 2 GB por cada mil millones de parámetros, y la caché KV necesita espacio adicional. Una tarjeta de 24 GB ofrece un margen cómodo. Una tarjeta de 16 GB requiere un checkpoint cuantizado o un modelo más pequeño. vLLM reclama una fracción de la memoria de la tarjeta definida por --gpu-memory-utilization, cuyo valor predeterminado es 0.92 desde julio de 2026.

¿Necesito cambiar el código de mi aplicación para cambiar entre ellos?

Normalmente sólo debe cambiar la URL base, la clave de API y el nombre del modelo. Ollama ofrece su interfaz compatible con OpenAI en http://127.0.0.1:11434/v1 e ignora la clave, mientras que vLLM ofrece http://localhost:8000/v1 y exige la clave si se configura una. Los nombres de los modelos tienen formatos distintos: llama3.1:8b para Ollama y un identificador completo de repositorio, como Qwen/Qwen2.5-1.5B-Instruct, para vLLM.