vLLM vs Ollama: 1 usuario o 256 a la vez, y qué puertas abre cada uno

Elige Ollama si lo usa una persona, en un Mac, un PC con Windows o casi cualquier tarjeta gráfica, con modelos GGUF y un solo comando. Elige vLLM si varias personas o programas atacan el mismo modelo a la vez desde un Linux con tarjeta NVIDIA, con modelos en safetensors. En casa, para un usuario, Ollama.

Más que rivales, son herramientas para trabajos distintos. Ollama 0.40.10, la versión estable desde el 23 de octubre de 2026, está hecho para poner un modelo en tu propio ordenador. vLLM 0.32.0, estable desde el 18 de octubre de 2026, está hecho para servir un modelo a mucha gente a la vez. No los hemos puesto a competir con cronómetro, así que aquí no vas a encontrar un ganador en velocidad. Lo que sí hemos hecho es leer el código de las dos versiones allí donde toca la memoria, la red y tu privacidad, y ahí es donde más se diferencian.

vLLMFicha del programa→ OllamaFicha del programa→

	vLLM	Ollama
Hecho para	Servir un modelo a muchos usuarios a la vez	Ejecutar modelos en tu propio ordenador
Versión a 24 de octubre de 2026	0.32.0	0.40.10
Código y licencia	Abierto, Apache 2.0	Abierto, MIT
Funciona en	Linux con tarjeta NVIDIA (capacidad de cómputo 7.5 o más), AMD con ROCm en unas versiones muy concretas; Windows solo con WSL; Mac experimental, solo procesador	Windows 10 22H2 o posterior, macOS 14 o posterior, Linux; NVIDIA, AMD, Apple Silicon y Vulkan
Ficheros de modelo	safetensors, más AWQ, GPTQ, FP8 y otros; GGUF solo con un complemento experimental	GGUF y safetensors; en Apple Silicon, MLX por defecto
Peticiones a la vez, de fábrica	Hasta 256 en una tarjeta doméstica, en lotes	1 por modelo; el resto espera en una cola de hasta 512
Memoria gráfica	Se reserva el 92 % de la tarjeta al arrancar	Ocupa lo que necesitan el modelo y su contexto
Instalación y primera respuesta	Paquete de Python, vllm download-kernels y luego vllm serve	Instalador o script de una línea y luego ollama run
Ventana	Ninguna: es un servidor de API	Aplicación de escritorio en macOS y Windows
Escucha en	0.0.0.0:8000, todas las interfaces de red	127.0.0.1:11434, solo tu equipo
Clave en la API	Ninguna de fábrica; --api-key cubre solo 4 prefijos de ruta	Ninguna, y el servidor local no tiene clave que comprobar
CORS de fábrica	Cerrado desde la 0.32.0 (ningún origen permitido)	Abierto a páginas de localhost, 127.0.0.1 y 0.0.0.0 en cualquier puerto
Envía por su cuenta	Estadísticas de uso a stats.vllm.ai al arrancar y cada 10 minutos	2 tipos de llamada a la nube con ollama serve, 4 con la aplicación de escritorio
Cómo se apaga	VLLM_NO_USAGE_STATS=1 (o de otras 3 formas)	OLLAMA_NO_CLOUD=1 corta las 2 de la nube; la comprobación horaria de actualizaciones y la consulta de cuenta de la aplicación se quedan

Una persona en casa, o una docena a la vez

Esta es la pregunta que lo decide. Ollama atiende 1 petición por modelo cada vez de fábrica: en el código de la 0.40.7, OLLAMA_NUM_PARALLEL vale 1 por defecto, y cualquier otra petición espera su turno en una cola de hasta 512. Para una persona que chatea, programa o lanza un script, es justo lo que quieres: toda la tarjeta trabaja en tu respuesta. Puedes subir OLLAMA_NUM_PARALLEL, pero cada hueco extra multiplica la memoria del contexto: 4 peticiones en paralelo con un contexto de 4.096 tokens reservan memoria para 16.384.

vLLM empieza por el otro extremo. En una tarjeta gráfica con menos de 70 GB de memoria, que son todas las GeForce, el código de la 0.32.0 deja que vllm serve trabaje con hasta 256 peticiones a la vez, y mete las nuevas en el lote que ya está en marcha según llegan, en vez de hacerlas esperar a que acabe la anterior. Para eso nació. Si tu familia, tu equipo o una docena de agentes en cadena atacan el mismo modelo, vLLM mantiene la tarjeta ocupada donde Ollama los atendería de uno en uno.

¿Cuánto más rápido lo hace eso? No lo hemos medido, y depende del modelo, de la tarjeta y de cuántas peticiones lleguen juntas. Con un solo usuario no hay lote que llenar, así que la gran ventaja de vLLM se queda sin nada con lo que trabajar.

NVIDIA, Mac o solo procesador

Aquí la elección muchas veces se hace sola. vLLM es un programa de Linux, y su caso de primera es una tarjeta NVIDIA con capacidad de cómputo 7.5 o superior: eso deja fuera la serie GTX 10 y anteriores. Las tarjetas AMD funcionan con ROCm, pero para la 0.32.0 el paquete publicado pide Python 3.12, ROCm 7.2.3 y glibc 2.39 o posterior. En Windows no hay versión nativa, solo WSL. En un Mac con Apple Silicon, el soporte propio de vLLM es experimental y solo por procesador; el chip gráfico necesita un complemento aparte que mantiene su comunidad.

Ollama funciona casi en cualquier sitio: Windows 10 22H2 o posterior, macOS 14 o posterior y Linux, con tarjetas NVIDIA desde la capacidad de cómputo 5.0, AMD con ROCm v7 y Vulkan, que viene activado de fábrica en Windows y Linux y es su vía recomendada para las Radeon sin ROCm. En un Mac con Apple Silicon usa el chip gráfico, y desde la 0.40.0 ejecuta el modelo con MLX por defecto siempre que tenga versión MLX.

Si tu ordenador es un Mac o un portátil con Windows, la comparativa acaba aquí: Ollama. Para ver qué modelos caben en tu equipo, nuestro buscador de modelos hace las cuentas.

GGUF o safetensors: los ficheros que lee cada uno

El formato de tus modelos es el segundo filtro. El formato nativo de vLLM es safetensors, en el que se publican la mayoría de los modelos, más de 20 esquemas de cuantización como AWQ, GPTQ y FP8. GGUF, el formato de casi todos los modelos cuantizados para uso doméstico, ya no viene de serie: desde la 0.27 vive en un complemento aparte que la propia documentación de vLLM califica de muy experimental. Los modelos salen de Hugging Face por defecto.

Ollama habla GGUF a través de llama.cpp, y también puede importar una carpeta de safetensors o un fichero GGUF con un Modelfile, cuantizando de paso si se lo pides. Casi nadie ve los ficheros: ollama pull descarga de la biblioteca propia de Ollama, y en Apple Silicon una etiqueta puede llevar una versión MLX que el Mac prefiere a la GGUF.

Así que, si ya tienes una colección de ficheros GGUF, Ollama los lee tal cual. Si quieres ejecutar un modelo exactamente como lo publicó su fabricante, a precisión completa o en FP8 sobre una tarjeta NVIDIA, ese es terreno de vLLM.

Memoria: el 92 % de la tarjeta de entrada, o solo lo que necesita el modelo

La primera vez que arrancas vllm serve, mira la memoria gráfica: el 92 % ha desaparecido. Es a propósito. En el código de la 0.32.0, gpu_memory_utilization vale 0.92 por defecto, y vLLM reserva esa parte nada más arrancar, para los pesos y una caché lo bastante grande para muchas conversaciones a la vez. Es reserva, no uso a demanda, así que cualquier otra cosa que necesite la tarjeta tiene que caber en el 8 % restante. Si la compartes, baja ese valor a mano.

Ollama carga los pesos y la caché que necesita el contexto, y elige ese contexto según la memoria gráfica que encuentra: 4.096, 32.768 o 262.144 tokens. Cuando el modelo lleva un rato sin usarse, lo descarga y devuelve la memoria.

Instalarlos, y la primera respuesta

Ollama son 2 pasos: instalarlo con el instalador o un script de una línea, y luego ollama run seguido del nombre de un modelo. Descarga el modelo y abre un chat en la terminal. En macOS y Windows hay además una aplicación de escritorio con ventana de chat.

vLLM es un paquete de Python sin ventana. Con la 0.32.0 necesitas Python 3.11 a 3.14; se instala con uv pip install vllm --torch-backend=auto (o con la imagen oficial de Docker), se lanza vllm download-kernels una vez tras cada instalación o actualización, y se arranca con vllm serve seguido de un modelo de Hugging Face. A partir de ahí le hablas por su API compatible con OpenAI, desde código o desde una interfaz de chat que le pongas delante. No es difícil si te manejas en la terminal, pero hay más piezas, y los ajustes de memoria de arriba son parte del trabajo.

Nuestras guías paso a paso te llevan por cada uno: instalar Ollama en local e instalar vLLM en local.

Qué puertas quedan abiertas: 0.0.0.0:8000 contra 127.0.0.1:11434

De fábrica, vllm serve escucha en 0.0.0.0:8000: todas las interfaces de red del equipo, sin clave. En un portátil en un hotel, cualquiera en esa wifi podría usar tu modelo. Ollama escucha en 127.0.0.1:11434, solo en tu equipo, y para llegar a él desde otro dispositivo tienes que abrirlo a propósito con OLLAMA_HOST=0.0.0.0.

Ninguno pide contraseña de fábrica. vLLM puede: arráncalo con --api-key, o con la variable VLLM_API_KEY, y los clientes tendrán que mandar la clave. Pero la clave solo cubre las rutas bajo 4 prefijos, /v1, /v2, /inference y /cohere; otras rutas del mismo puerto responden sin ella, y la propia página de seguridad de vLLM aconseja no fiarlo todo a la clave. El servidor local de Ollama no tiene clave ninguna: sus defensas son escuchar solo en tu equipo, el CORS y una comprobación de la cabecera Host de cada petición, que solo se aplica mientras escucha en tu propio equipo.

El CORS decide qué páginas web pueden usar el servidor desde dentro de tu navegador, y aquí vLLM es ahora el más estricto. Desde la 0.32.0 su lista de orígenes permitidos está vacía: ninguna página de otro sitio puede leer sus respuestas hasta que la añadas con --allowed-origins. Ollama acepta páginas servidas desde localhost, 127.0.0.1 y 0.0.0.0 en cualquier puerto, más unos pocos esquemas de aplicación, y responde 403 a cualquier otro origen; las extensiones del navegador hay que añadirlas con OLLAMA_ORIGINS. Ten en cuenta que el CORS solo ata a los navegadores: cualquier programa de tu red llega a vLLM igual.

Una cosa más que comprobamos en el código de vLLM, porque su página de seguridad avisa de que la comunicación interna de PyTorch puede escuchar en todas las interfaces. En 1 equipo, de fábrica, el código de la 0.32.0 monta esa comunicación con un fichero en la carpeta temporal, no con un puerto de red; solo usa TCP en tarjetas AMD con el all-reduce de AITER, con paralelismo de datos (--data-parallel-size mayor que 1) y entre varias máquinas. Esos puertos internos nunca deberían ser accesibles desde fuera.

Qué manda cada uno por su cuenta

Aquí es donde alguien preocupado por su privacidad debería mirar dos veces, y la respuesta no es la que quizá esperas. vLLM manda estadísticas de uso a stats.vllm.ai de fábrica: 1 informe completo al arrancar el motor (tarjeta gráfica, procesador, memoria, sistema operativo, versión de vLLM, la arquitectura del modelo pero no su nombre, y ajustes de arranque) y después un latido cada 10 minutos mientras el servidor esté vivo. Son 144 latidos al día. A su favor: guarda una copia de todo lo que manda en ~/.config/vllm/usage_stats.json, y cualquiera de 4 interruptores lo apaga: VLLM_NO_USAGE_STATS=1, DO_NOT_TRACK=1, VLLM_DO_NOT_TRACK=1 o un fichero vacío en ~/.config/vllm/do_not_track. El valor tiene que ser exactamente 1.

vLLM también descarga, cuando le pides un modelo que no está en caché, de Hugging Face (HF_HUB_OFFLINE=1 lo impide cuando ya tienes tus modelos en disco). Y si faltan los kernels precompilados de FlashInfer, FlashInfer los baja de los servidores de NVIDIA al arrancar vLLM; vllm download-kernels lo hace una vez al instalar, y FLASHINFER_NO_DOWNLOAD=1 lo prohíbe. No comprueba actualizaciones ni tiene cuenta. Antes de que FlashInfer baje esos kernels, normalmente vLLM pregunta si responde el servidor de NVIDIA, edge.urm.nvidia.com (1 petición, con 5 segundos de límite), y FLASHINFER_NO_DOWNLOAD=1 no frena esa comprobación. Instalado con pip, pasa sin pedirlo en las B200 y B300 con casi cualquier modelo y puede pasar en una H100 o una RTX 50 con modelos como gpt-oss. La imagen Docker ya trae los kernels, y con ellos en disco tras vllm download-kernels, normalmente no sale ninguna de las dos peticiones.

Ollama no tiene ninguna librería de analítica en su código. Con solo ollama serve, como en Linux, hace 2 tipos de llamada a ollama.com por su cuenta: un catálogo de modelos recomendados cada 4 horas y las fichas de sus modelos de nube al arrancar el servidor. OLLAMA_NO_CLOUD=1 apaga las dos. Con la aplicación de escritorio en macOS o Windows se suman 2 tipos más: una comprobación de actualizaciones cada hora, que ningún ajuste detiene, y una consulta de la cuenta al abrir la aplicación.

Así que la configuración más callada de todas es cualquiera de los dos con su interruptor puesto: vLLM con VLLM_NO_USAGE_STATS=1, HF_HUB_OFFLINE=1 y FLASHINFER_NO_DOWNLOAD=1 después de haber lanzado vllm download-kernels, u ollama serve sin la aplicación y con OLLAMA_NO_CLOUD=1. Cada destino, con su fuente y su fecha, está en nuestra ficha de vLLM y nuestra ficha de Ollama.

Cuál instalaríamos, según tu caso

• Una persona, cualquier ordenador: Ollama. Un comando, un modelo que se carga y se descarga solo y nada abierto a la red.
• Un Mac o un portátil con Windows: Ollama. vLLM no tiene versión nativa para Windows, y en Mac solo va por procesador.
• Una estantería de ficheros GGUF: Ollama, que los importa sin convertirlos (un Modelfile y ollama create por modelo).
• Un Linux con tarjeta NVIDIA que sirve a toda la casa, a un equipo o a una flota de agentes: vLLM, con --host, clave de API y sus estadísticas apagadas.
• Un modelo exactamente como lo publicó su fabricante, en safetensors o FP8: vLLM.
• Una tarjeta que también usas para jugar o para otros programas: Ollama, o vLLM con gpu_memory_utilization bajado a mano.

¿Dudas también con una aplicación de escritorio? Nuestra comparativa LM Studio vs Ollama te lo cuenta.