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 pesos cuantizados, los carga y responde en 127.0.0.1:11434, usando la CPU si es el único recurso disponible en el equipo. vLLM es un motor de rendimiento: mantiene una GPU ocupada con muchas solicitudes ejecutándose al mismo tiempo, y es la herramienta incorrecta en una máquina sin GPU. Esa es toda la decisión. Una persona que habla con un asistente local es un trabajo para Ollama. Una aplicación que atiende 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 está en lo que ocurre cuando llega una segunda solicitud 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 systemd y una API HTTP mediante un solo 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 ejecutor 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 la mayoría de lo que sirve. Por eso, cuando se compara Ollama con llama.cpp, en gran medida se compara una capa de ergonomía con el componente que esta 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 solicitud cada vez y todas las demás esperan en una cola que contiene 512 entradas de forma predeterminada (OLLAMA_MAX_QUEUE). Puede aumentar la configuración de paralelismo. La sección siguiente explica el coste de 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 únicamente un servidor de inferencia. No administra una biblioteca de modelos, no incluye una plantilla de chat y no descarga ningún modelo durante las solicitudes. Al iniciarlo, se especifica un repositorio de Hugging Face. vLLM carga ese modelo y lo sirve hasta que se detiene el proceso.

La ventaja de este enfoque limitado es el rendimiento. Dos mecanismos lo hacen posible. PagedAttention almacena la caché KV (caché de clave-valor, el estado de atención por token que un modelo conserva para cada solicitud activa) en bloques de tamaño fijo, como un sistema operativo pagina 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 usar queda disponible para más solicitudes simultáneas. El batching continuo permite que una solicitud nueva se incorpore al batch en el siguiente paso de decodificación, sin esperar a que termine el batch actual. Cuando una secuencia termina, sale del batch inmediatamente y su espacio se reutiliza.

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 solo hace que veintinueve personas esperen.

El procesamiento por lotes continuo marca toda la diferencia

Suponga que cinco solicitudes llegan a cada servidor al mismo tiempo y con el mismo hardware.

Ollama, con la configuración predeterminada, procesa la primera solicitud hasta completarla, después la segunda y así sucesivamente. El quinto usuario debe esperar a que terminen cuatro generaciones completas. El rendimiento total es aproximadamente el de una generación, porque el procesador solo trabaja con una secuencia a la vez.

vLLM decodifica las cinco secuencias en la misma pasada hacia adelante. Generar un token para cinco secuencias cuesta apenas más que generar un token para una sola, porque la parte costosa consiste en leer los pesos del modelo desde la memoria, y esa lectura se comparte con todo el lote. Este es el mismo factor de ancho de banda de memoria que hace lenta la inferencia en la CPU: el costo 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 costo es la memoria. Cada ranura paralela necesita su propia caché KV, y Ollama divide la ventana de contexto entre las ranuras. Por eso, cuatro solicitudes paralelas contra un modelo configurado para 8192 tokens dejan 2048 tokens de contexto para cada solicitud. La caché paginada de vLLM evita esta limitación, porque asigna bloques a una solicitud a medida que esta crece.

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 del 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. Confíe en este valor y no en ninguna cifra publicada.

Para aumentar la concurrencia, use un drop-in de systemd para que una actualización no sobrescriba 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 lo que está cargado y su columna PROCESSOR indica el valor real. 100% CPU significa que no se usa ninguna GPU. Esta es la explicación correcta para la mayoría de los informes que indican que Ollama es lento.

Instalar y servir con vLLM

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

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

A continuación, sirva un modelo. El nombre es un identificador de repositorio de Hugging Face, no una etiqueta corta:

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

El inicio tarda la primera vez 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 equipo, 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 transfiere tensores entre procesos mediante memoria compartida, y la asignación predeterminada de memoria compartida de Docker es demasiado pequeña para la inferencia en paralelo 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 usar, 0.92 de forma predeterminada desde julio de 2026), --tensor-parallel-size para dividir un modelo entre varias GPU y --api-key.

La autenticación es un indicador en vLLM y no existe en Ollama

vLLM exige un token bearer si se proporciona:

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. Una solicitud sin este token recibe HTTP 401. Esto no justifica publicar el puerto 8000 en una interfaz pública, porque vLLM no aplica límites de velocidad y un token HTTP sin cifrar puede leerse durante el tránsito. Sin embargo, significa que el servidor identifica al solicitante.

Ollama no ofrece ninguna autenticación. No hay ninguna 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 proxy inverso con autenticación que termine TLS (seguridad de la capa de transporte).

Hardware: requisitos de cada opción

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, además de cerca de un gigabyte de sobrecarga del tiempo de ejecución y más memoria para el contexto. Por tanto, un modelo 3B necesita alrededor de 4 GB libres y un modelo 8B, alrededor de 8 GB. La velocidad en una vCPU compartida 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 configuración incorrecta, y ningún flag lo corrige.

vLLM presupone una GPU. Su ruta predeterminada sirve los 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 video solo para los pesos, antes de asignar la caché KV que permite la concurrencia para la que instaló vLLM. En una tarjeta de 24 GB queda una caché utilizable. En una tarjeta de 16 GB no queda suficiente, 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 ejecutar vLLM.

Por tanto, la respuesta sobre el hardware suele determinar la elección del software. Si no hay GPU, use Ollama. Si una GPU alquilada permanece al 5 % de utilización porque las solicitudes se procesan en serie, use vLLM.

Cuál elegir para su carga de trabajo

• Una 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 solo usted llama: 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 funciona bien, 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 evalúe cien mil documentos durante la noche: vLLM, con un --max-num-seqs alto. El rendimiento es la única métrica importante; la latencia por documento no lo es.
• Una plataforma de agentes en la que varios agentes de IA autoalojados acceden al modelo al mismo tiempo: vLLM, porque el tráfico de los agentes llega en ráfagas y es paralelo por naturaleza.

Modos de fallo y cadenas que verá

vLLM se niega a iniciarse con un error de caché KV. El mensaje muestra 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 tarjeta. Superar aproximadamente 0.95 de utilización suele cambiar este error de inicio por un fallo posterior de falta de memoria de CUDA bajo carga. Este segundo caso es peor.

Ollama muestra Killed durante la generación. El terminador 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 bien por sí solo y se bloquea bajo carga. No aparece ningún error. Las solicitudes simplemente tardan más cuantos más clientes hay, porque OLLAMA_NUM_PARALLEL=1 las procesa de forma serializada. Auméntelo y acepte un contexto menor por solicitud, o traslade la carga de trabajo a vLLM.

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

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

Ejecutar ambos es una opción razonable

No son opciones excluyentes. Una configuración habitual consiste en ejecutar 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 extremos son compatibles con la API de OpenAI, por lo que basta con una biblioteca cliente y cambiar la URL base. El control de costes es más importante en este caso que cualquiera de los dos motores, porque una GPU inactiva cuesta lo mismo que una GPU ocupada, y mantener predecibles los costes de los agentes y de la inferencia es una disciplina independiente de la elección del servidor.

FAQ

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

Para una sola solicitud en la misma GPU, la diferencia es moderada, porque ambos realizan las mismas operaciones. Con muchas solicitudes simultáneas, vLLM es muy superior, porque el batching continuo decodifica cada secuencia activa en una sola pasada hacia delante, mientras que la configuración predeterminada de Ollama las ejecuta una tras otra. En una máquina que solo usa CPU, la pregunta no se aplica: Ollama se ejecuta allí y vLLM, en la práctica, no.

¿Puede vLLM ejecutarse sin una GPU?

No de forma útil. Los paquetes estándar están destinados a GPU NVIDIA o AMD, y en una CPU desaparece el motivo de existir de vLLM: mantener un acelerador ocupado con solicitudes agrupadas. Existe un backend de CPU para tareas 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 ejecutor de Ollama se basa en ella y añade las partes que llama.cpp deja a su cargo: 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 ambos ya no son idénticos internamente.

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

Con una precisión de 16 bits, los pesos por sí solos 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 suficiente. 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 establecida por --gpu-memory-utilization, cuyo valor predeterminado es 0.92 en julio de 2026.

¿Tengo que cambiar el código de mi aplicación para cambiar entre ambos?

Por lo general, solo 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 aplica la clave si se configura una. Los nombres de los modelos tienen formatos distintos: llama3.1:8b para Ollama y un ID completo de repositorio, como Qwen/Qwen2.5-1.5B-Instruct, para vLLM.