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 indicador de chat, un servicio systemd y una API HTTP mediante un solo comando de instalación. La mayoría de los modelos que sirve son archivos GGUF, normalmente cuantizados a 4 bits. Por eso, un modelo 7B u 8B ocupa unos 5 GB en disco en lugar de 16 GB. La cuantización reduce la memoria necesaria para la inferencia en la CPU. En los Mac con Apple Silicon también puede ejecutar modelos basados en safetensors mediante un motor MLX. Desde v0.40.0 (septiembre de 2026), las arquitecturas compatibles se ejecutan automáticamente en MLX.

Su ejecutor GGUF se basa en llama.cpp, la biblioteca de inferencia en C++ que hizo práctica la cuantización GGUF en hardware convencional. En octubre de 2026, Ollama admite dos motores: llama.cpp y MLX. Las compilaciones para Linux también admiten inferencia MLX con CUDA. La guía de desarrollo habilita ese backend con cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13, y requiere CUDA 13+ y cuDNN 9+. Por tanto, cuando se compara Ollama con llama.cpp, en gran medida se compara una capa de usabilidad con el componente que esta envuelve.

El diseño está orientado a un usuario. En octubre de 2026, el valor predeterminado de OLLAMA_NUM_PARALLEL es 1. Esto significa que un modelo procesa una solicitud cada vez y que todo lo demás 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 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 local no requiere autenticación.

Qué es realmente vLLM

vLLM es un servidor de inferencia y nada más. No administra una biblioteca de modelos, proporciona un cliente vllm chat para un servidor en ejecución y no descarga un modelo cuando se lo solicitas. Indicas un repositorio de Hugging Face al iniciarlo, carga ese único modelo y lo sirve hasta que detienes el proceso.

Lo que ofrece esta especialización es rendimiento. Dos mecanismos hacen posible ese 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 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 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 terminada abandona el lote inmediatamente y su puesto 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 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 cuatro generaciones completas. El rendimiento total es aproximadamente el de una sola generación, porque el procesador sólo trabaja con una secuencia cada vez.

vLLM decodifica las cinco en la misma pasada hacia adelante. Generar un token para cinco secuencias apenas cuesta 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 lote. Este es el mismo hecho relacionado con el ancho de banda de memoria que hace lenta la inferencia en 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 está en la memoria. Cada espacio paralelo necesita su propia caché KV, y Ollama multiplica la asignación de contexto en lugar de dividirla: su FAQ indica que la RAM necesaria aumenta según OLLAMA_NUM_PARALLEL veces OLLAMA_CONTEXT_LENGTH. Por tanto, cuatro solicitudes en paralelo contra un modelo configurado para 8192 tokens conservan 8192 tokens cada una, pero el equipo debe mantener una caché total para 32768 tokens. Esos 8192 tokens también son una elección, no un valor predeterminado, por lo que aumentar num_ctx y dimensionar la RAM que requiere es el paso que determina si caben cuatro espacios. La caché paginada de vLLM evita reservar por adelantado toda la ventana para cada espacio, porque los bloques se asignan a una solicitud a medida que esta crece. En cualquier caso, el límite de cuántas personas puede atender simultáneamente un solo equipo depende del tamaño de la caché KV, del coste de prefill y de la profundidad de la cola. Por eso un servidor que funcionaba bien para una persona se vuelve lento 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 vinculado 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 un solo prompt es un punto de partida, no una medida de capacidad. Por eso, medir los tokens por segundo durante una prueba 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 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 la configuración cargada y su columna PROCESSOR indica el valor efectivo. 100% CPU significa que no se usa ninguna GPU. Esa es la explicación real de la mayoría de los informes que indican que Ollama es lento. La línea OLLAMA_KEEP_ALIVE=30m de ese drop-in también es importante en un equipo con poca actividad, porque el valor predeterminado descarga el modelo después de cinco minutos sin solicitudes. Mantener el modelo residente entre solicitudes evita que el primer prompt después de un periodo de inactividad de hasta media hora vuelva a pagar todo el tiempo de carga. Si los periodos de inactividad duran más, establezca un valor mayor.

Instalar y servir con vLLM

Las compilaciones de vLLM para GPU requieren Linux (macOS en Apple Silicon sólo tiene compatibilidad con CPU mediante una wheel precompilada en la versión 0.32.0, y la aceleración de GPU en esos Mac la proporciona vLLM-Metal, un plugin independiente mantenido por la comunidad y basado en MLX). En Python, la versión actual (0.32.0, octubre de 2026) admite de 3.11 a 3.14, y la guía de instalación indica el mismo rango. Python 3.10 dejó de admitirse en 0.32.0, por lo que 3.12, que se usa a continuación, es la opción segura. Instálelo en un entorno virtual independiente, porque instala una compilación específica de PyTorch:

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

La última línea aparece en la guía de instalación de vLLM para NVIDIA a fecha de octubre de 2026. Instala los kernels precompilados de FlashInfer. Sin ellos, vLLM descarga y compila los kernels durante el arranque, lo que, según la guía, puede añadir varios minutos en GPU Hopper y posteriores. Ejecútela de nuevo después de cada actualización de vLLM, porque FlashInfer no se puede importar cuando los kernels no coinciden.

A continuación, 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 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 configurar 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 proporciona al contenedor acceso a la memoria compartida del host; aumentar --shm-size es otra opción. PyTorch transfiere tensores entre procesos mediante la memoria compartida, especialmente para la inferencia paralela entre 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 reclamar, 0.92 de forma predeterminada a fecha de octubre de 2026), --tensor-parallel-size para distribuir un modelo entre varias GPU y --api-key.

La autenticación es un indicador en vLLM y no existe en la API local de Ollama

vLLM aplica 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. Una solicitud a /v1 que se enruta sin ese token recibe un HTTP 401. Sin embargo, la clave no protege todo el servidor. La guía de seguridad de vLLM y el código de autenticación del código fuente de la versión 0.32.0 la aplican únicamente a los endpoints bajo los prefijos de ruta /v1, /v2, /inference y /cohere. El texto de ayuda de --api-key en la página vllm serve sólo enumera los tres primeros, pero el código comprueba los cuatro. Tanto la guía como el texto de ayuda indican que los demás endpoints, especialmente /invocations, que expone la misma inferencia que /v1, no están autenticados. Esto basta para no publicar el puerto 8000 en una interfaz pública. La guía de seguridad de vLLM también deja el control de tasa en manos de un reverse proxy situado delante. Además, un token enviado mediante HTTP sin cifrar puede leerse durante el tránsito. Aun así, el indicador significa que el servidor tiene un concepto de cliente.

La API local de Ollama no requiere autenticación. Los modelos en la nube, la publicación de modelos y las descargas de modelos privados requieren iniciar sesión. El acceso directo a la API de ollama.com requiere una clave de API. 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 que aloje usted mismo, o mediante 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, además de alrededor de un gigabyte de sobrecarga de ejecución y más memoria para el contexto. Por tanto, un modelo 3B necesita alrededor de 4 GB libres y uno 8B, alrededor de 8 GB. La velocidad en una vCPU compartida es de un solo dígito 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 soluciona. Para comprobar cómo se aplica ese cálculo en una release concreta, en lugar de usar una regla aproximada, 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 funcionamiento sólo con CPU es suficientemente rápido para resultar práctico.

vLLM presupone una GPU. Su ruta predeterminada sirve pesos sin cuantizar con 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 añadir 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, así que debe elegir un modelo más pequeño, pasar --quantization (con un checkpoint cuantizado o para cuantizar los pesos de precisión completa durante la carga) o trasladar parte de los pesos a la RAM del sistema con --cpu-offload-gb. Esta última opción conserva la precisión de los pesos, pero es más lenta porque esos pesos se transfieren a la GPU en cada pasada forward. Existe un backend para CPU, con sus propias wheels independientes, pero elimina el motivo para ejecutar vLLM.

Por tanto, la cuestión del hardware responde casi siempre a la cuestión del software. Sin GPU, use Ollama. Una GPU alquilada con una utilización del 5 por ciento porque las solicitudes se procesan en serie implica que debe usar 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 mensajes que verá

vLLM se niega a iniciar con un error de caché KV. El mensaje incluye ambos números:

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

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 utiliza la tarjeta.

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 mayor cuantización, no cambiar un ajuste.

Ollama responde correctamente por separado, pero se bloquea bajo carga. No aparece ningún error. Las solicitudes simplemente tardan más a medida que aumenta el número de clientes, porque OLLAMA_NUM_PARALLEL=1 las procesa de forma serializada. Las respuestas largas empeoran la cola. Un cliente que ocupa el único espacio hasta que el modelo decide detenerse bloquea a todos los que esperan detrás. Por eso, limitar la respuesta con num_predict establece un límite para el tiempo que un turno puede ocupar el servidor. Aumente el valor de paralelismo y acepte la RAM adicional que cuesta el contexto de cada espacio, o traslade la carga de trabajo a vLLM.

vLLM devuelve 401 en todas las solicitudes /v1. Lo inició con --api-key, pero 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úrelo 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 solicitud debe coincidir con el ID del repositorio con el que inició vLLM, 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 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 solicitud en la misma GPU, la diferencia es moderada, porque ambos realizan los mismos cálculos. Para muchas solicitudes simultáneas, vLLM es muy superior, porque la agrupación continua procesa cada secuencia activa en una sola pasada hacia adelante, mientras que la configuración predeterminada de Ollama las ejecuta una tras otra. En una máquina que sólo usa CPU, ambos tienen rutas de inferencia compatibles, y vLLM utiliza wheels de CPU independientes.

¿Puede vLLM ejecutarse sin una GPU?

Sí, mediante su backend de CPU. Las wheels estándar están dirigidas a GPU NVIDIA o AMD, y el motivo de existir de vLLM —mantener un acelerador ocupado con solicitudes agrupadas— desaparece en una CPU. Existe un backend de CPU, con wheels independientes para x86 y Arm. Para realizar 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. Ollama lo utiliza para la inferencia con GGUF y añade un registro de modelos, descargas etiquetadas, gestión de modelos y una unidad de systemd. Ollama también incluye un motor MLX que ejecuta modelos basados en safetensors en Apple Silicon y admite compilaciones CUDA en Linux, por lo que ambos no siempre 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 aproximadamente 16 GB, unos 2 GB por cada mil millones de parámetros, y la caché KV necesita espacio adicional. Una tarjeta de 24 GB ofrece margen suficiente. Una tarjeta de 16 GB necesita un modelo cuantizado, un modelo más pequeño o --cpu-offload-gb para trasladar parte de los pesos a la RAM del sistema, con una reducción de velocidad. vLLM utiliza la fracción de la tarjeta indicada por --gpu-memory-utilization, cuyo valor predeterminado es 0.92 a fecha de octubre de 2026.

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

Por lo general, sólo 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 en sus rutas /v1 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.