Respuesta directa
¿Ollama o vLLM para servir un modelo en la empresa?
vLLM, si el modelo tiene que atender a varias personas a la vez. Ollama es una forma sencilla de probar modelos en un ordenador, pero por defecto atiende una petición por modelo y su API local no pide autenticación, mientras que vLLM agrupa muchas peticiones simultáneas y reparte la memoria entre ellas. Lo razonable suele ser usar los dos: Ollama para probar y vLLM para servir.
Ollama frente a vLLM, punto por punto
| Criterio | Ollama | vLLM |
|---|---|---|
| Pensado para | Poner en marcha modelos abiertos con rapidez, según su propia presentación | Inferencia y servicio de modelos con alto rendimiento, según su documentación |
| Peticiones a la vez por modelo | 1 por defecto (OLLAMA_NUM_PARALLEL). Las demás esperan en cola, hasta 512, y después responde con un error 503 | Agrupa en lotes continuos las peticiones que van llegando (continuous batching) |
| Memoria de la caché | Crece con OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH; se guarda en f16 por defecto | PagedAttention: un fondo común repartido en bloques entre las conversaciones activas; por defecto usa el 92% de la memoria de la GPU |
| Contexto por defecto | 4.096 tokens (OLLAMA_CONTEXT_LENGTH) | El de la configuración del modelo, salvo que lo limites con --max-model-len |
| Acceso por red | Escucha en 127.0.0.1:11434 y la API local no pide autenticación | La opción --api-key solo protege las rutas /v1, /v2 e /inference; la documentación pide no confiar solo en ella |
| API compatible con OpenAI | Un subconjunto de la API de OpenAI | Servidor compatible con OpenAI, además de la API Messages de Anthropic |
| Licencia y versión revisada | MIT; versión 0.40.5, del 14 de octubre de 2026 | Apache 2.0; versión 0.31.0, del 5 de octubre de 2026 |
Fuentes: preguntas frecuentes, autenticación y compatibilidad con OpenAI de Ollama; documentación general, argumentos del motor y servidor compatible con OpenAI de vLLM; licencias y versiones en los repositorios de Ollama y vLLM.
Un ejemplo con números: 25 personas y un modelo de 32B
Hicimos la cuenta el 17 de octubre de 2026 con nuestra calculadora de VRAM: 25 usuarios conectados y un modelo denso de 32B en FP8. Si entre el 10 y el 25% genera a la vez, son de 3 a 7 conversaciones activas. La calculadora toma la configuración publicada de un modelo abierto de 32B (64 capas y 8 cabezas KV de 128), así que cada conversación de 8.192 tokens ocupa 1,07 GB de caché en FP8. Total: 32 GB de pesos, de 3,2 a 7,5 GB de caché y 5,2 GB de margen, de 40,4 a 44,7 GB.
Con Ollama tal como viene, esas 3 a 7 conversaciones se atienden de una en una y el resto espera su turno. Además, el contexto por defecto es de 4.096 tokens, la mitad del que supone la cuenta. Para servir las 7 a la vez con 8.192 tokens hay que subir OLLAMA_NUM_PARALLEL a 7 y OLLAMA_CONTEXT_LENGTH a 8.192, y la caché pasa a cubrir 57.344 tokens: unos 15 GB en f16, su formato por defecto, el doble que en FP8. Ollama permite guardar la caché en q8_0 con Flash Attention activada, lo que la deja en aproximadamente la mitad.
vLLM parte de otra idea: reserva un fondo común para la caché y lo reparte en bloques entre las conversaciones que están generando, de modo que una pregunta corta no ocupa lo mismo que un documento largo. Todo esto es aritmética con los valores documentados, no una medición: no hemos publicado una comparación propia de velocidad entre los dos.
Cuándo Ollama es la respuesta correcta
Para que una persona pruebe modelos en su ordenador, para montar un prototipo o para decidir qué modelo merece una prueba seria, Ollama basta y da menos trabajo. También puede servir a un grupo muy pequeño que acepte esperar turno, siempre que alguien ponga delante un proxy con control de acceso.
Lo que no conviene es que el piloto de una persona se convierta, sin más, en el servicio de todo un departamento. El salto a varios usuarios cambia la memoria, las colas y la seguridad, como muestra el ejemplo anterior.
Lo que vLLM no resuelve solo
vLLM es el servidor del modelo, no el servicio completo. Faltan las cuentas y los permisos, el registro de quién pregunta qué, una interfaz para quien no programa, las actualizaciones y las evaluaciones de calidad con tus casos. Y su clave de API no basta como seguridad: la propia documentación recomienda ponerlo detrás de un proxy inverso.
Para que sepas desde dónde opinamos: en nuestros equipos con GPU NVIDIA servimos con vLLM y añadimos control de acceso, registro de actividad, panel de uso y evaluaciones periódicas. En los Mac M5 Ultra validamos la misma carga con MLX antes de comprometer un rendimiento.
Cómo comprobarlo con tu carga
Proponemos una prueba corta, no un resultado: el mismo modelo con una precisión comparable en los dos servidores, tus preguntas reales o ficticias y una carga que sube desde una conversación hasta las que espera tu equipo. Mide cuánto tarda en empezar cada respuesta, cuánto en terminar y cuántas peticiones fallan o se quedan esperando.
La herramienta de pruebas de servicio de vLLM mide esas métricas y también puede apuntar a un servidor compatible con OpenAI. El protocolo completo, con los escalones de carga y las condiciones de parada, está en cómo probar una IA local con varias personas a la vez.
¿Se puede usar Ollama en producción?
Sí, para cargas pequeñas y con ajustes: subir OLLAMA_NUM_PARALLEL y el contexto según la memoria disponible, publicarlo detrás de un proxy con control de acceso y aceptar que las peticiones esperen en cola. Para un equipo que pregunta a la vez durante toda la jornada, un servidor pensado para la concurrencia, como vLLM, da menos sorpresas.
¿Pasar de Ollama a vLLM obliga a reescribir la aplicación?
Normalmente no. Los dos exponen una API compatible con OpenAI, aunque Ollama solo implementa una parte, así que lo habitual es cambiar la URL, la clave y el nombre del modelo. Revisa los parámetros que usa tu aplicación y vuelve a probar con tus ejemplos. Lo explicamos en migrar sin migrar.