Ollama vs vLLM: por qué realmente ejecuto ambos (y la migración que no fue gratis)

Ollama quiere que ejecutes un modelo en un comando. vLLM quiere exprimir cada token por segundo de tu GPU. Intenté moverme de uno a otro y aprendí que “migración” no es la palabra correcta. “Reconstrucción” se acerca más.

Veo este debate a menudo en r/LocalLLaMA y r/ollama. Alguien pregunta “¿debería usar Ollama o vLLM para producción?” y las respuestas inmediatamente se convierten en una guerra religiosa. Creo que la pregunta suele estar mal.

Ollama y vLLM no son dos versiones de lo mismo. Son herramientas diferentes con diferentes filosofías de diseño. Ollama optimiza la ergonomía del desarrollador y la gestión de modelos. vLLM optimiza el throughput, el batching, y el servicio a escala. Tratarlos como competidores directos pierde el punto.

Intenté migrar de Ollama a vLLM. No fue una migración. Fue una reconstrucción. Esto es lo que realmente pasó.

Ollama: para qué realmente lo uso

Ollama está construido alrededor de una idea: hacer que ejecutar un modelo local sea tan fácil como ejecutar un contenedor Docker.

ollama pull llama3.1
ollama run llama3.1

Ese es todo el pitch, y es bueno. Las descargas de modelos, los defaults de cuantización, y una simple API REST se manejan por ti. El sistema de Modelfile hace fácil definir prompts personalizados y configuraciones de parámetros sin tocar Python.

Uso Ollama para:

• Experimentos rápidos con nuevos modelos. Descargar, probar, decidir.
• Mi configuración de Continue.dev, que apunta al endpoint de Ollama.
• Automatización simple que necesita inferencia local.
• Cualquier cosa donde quiera probar un modelo sin pensar en infraestructura de serving.

Las debilidades de Ollama son la consecuencia natural de ese enfoque. No está optimizado para alta concurrencia. No hace batching continuo como vLLM. No expone perillas profundas de serving. Para un solo usuario o un equipo interno pequeño, nada de eso importa. Para una API pública con SLAs, importa mucho.

Tengo un usuario. Yo mismo. Ollama está bien para mí.

vLLM: para qué realmente lo uso

vLLM está construido alrededor de PagedAttention y batching continuo. El objetivo es mantener la GPU saturada a través de muchas peticiones concurrentes. Todo lo demás, complejidad de configuración, requisitos de formato de modelo, perillas de ajuste, sigue de eso.

Uso vLLM para exactamente una cosa: benchmarking. Quería ver si las afirmaciones de throughput eran reales. Lo son. Pero no tengo una carga de trabajo que necesite ese throughput.

vLLM espera safetensors de HuggingFace, no GGUF. Espera que entiendas métodos de cuantización como AWQ y FP8. Espera que ajustes --max-num-seqs, --gpu-memory-utilization, y paralelismo de tensores. La recompensa es que sirve a muchos usuarios desde menos GPUs.

Creo que vLLM es la elección correcta cuando tienes demanda probada y necesitas economía unitaria. No antes. No tenía demanda probada. Solo quería ver si podía ejecutarlo.

La migración que no fue gratis

Decidí “migrar” mi modelo Llama 3.1 8B de Ollama a vLLM. Esperaba apuntar vLLM al mismo archivo de modelo y seguir. Estaba equivocado.

Problema 1: Formato de modelo. Ollama usa GGUF. vLLM usa safetensors de HuggingFace. Tuve que re-descargar el modelo en formato safetensors. Eso fueron 4 GB y 10 minutos en mi conexión.

Problema 2: Memoria GPU. Mi GTX 1080 tiene 8GB de VRAM. vLLM espera más margen que Ollama. Intenté cargar el modelo con --gpu-memory-utilization=0.90 y obtuve un OOMKill inmediatamente. Tuve que bajarlo a 0.75 para que cargara. Eso significaba menos caché KV y peor rendimiento.

Problema 3: Configuración. La configuración de Ollama es OLLAMA_KEEP_ALIVE=30m. La configuración de vLLM es --gpu-memory-utilization=0.75 --max-num-seqs=64. Tuve que aprender qué significaba cada uno y cuáles importaban para mi VRAM limitada. No podía usar los defaults porque asumían una GPU más grande.

La migración tomó una tarde. Para un solo modelo. En una sola GPU con 8GB de VRAM. Para un solo usuario. No ahorré tiempo. Gasté tiempo.

La pregunta que nadie hace

La pregunta que creo que más importa no es “¿cuál es más rápido?” Es “¿en qué fase estoy?”

La mayoría de los equipos deberían empezar con Ollama, probar el caso de uso, y migrar a vLLM si la carga de trabajo crece. La migración no es gratis. Necesitas diferentes formatos de modelo, diferentes elecciones de cuantización, y diferentes monitoreos. Pero es más barato que ejecutar vLLM para una carga de trabajo que no lo necesita.

Debería haberme quedado en Ollama más tiempo. Migré antes de tener una razón. Eso fue un error.

Sobre los benchmarks

Soy escéptico de la mayoría de los benchmarks de Ollama vs vLLM que veo compartidos online. A menudo comparan latencia de petición única, ignoran efectos de calentamiento, o ejecutan en hardware que no coincide con producción. La brecha real aparece bajo concurrencia, y la concurrencia es exactamente donde la mayoría de los benchmarks amateur se desmoronan.

Ejecuté mi propio benchmark. Aquí están los resultados en mi GTX 1080 con Llama 3.1 8B:

Para un solo usuario, la diferencia es insignificante. Para usuarios concurrentes, vLLM es claramente mejor. Pero no tengo usuarios concurrentes. Tengo yo. El benchmark confirmó lo que ya sabía: migré demasiado pronto.

Mi configuración actual

Ejecuto ambos:

• Ollama para desarrollo, experimentación, y mi uso diario real.
• vLLM para benchmarking y para el día en que podría necesitar serving concurrente. Ese día no ha llegado todavía, y mi GTX 1080 no está lista para ello.

Enruta tráfico por endpoint. Mantén Ollama como el sandbox donde pruebo nuevos modelos. Mantén vLLM como la capa de serving para cuando la latencia y el costo importen. Ese día no ha llegado todavía, y mi hardware no está listo para ello.

Esto evita la trampa común donde los desarrolladores optimizan para serving de producción antes de incluso saber qué debería ser el producto. Caí en esa trampa. Estoy saliendo de ella.

Conclusión

Ollama y vLLM no se pelean entre ellos. Ollama baja la barrera de entrada. vLLM eleva el techo para escalar. El error es usar cualquiera de los dos para el trabajo equivocado.

Empieza con Ollama. Mueve a vLLM cuando tengas carga concurrente real, requisitos estrictos de latencia, o modelos que no caben en una GPU. Hasta entonces, probablemente estás optimizando algo que aún no has construido.

La migración me enseñó que “de producción” no es una razón para usar una herramienta. “Mi carga de trabajo necesita esto” es la única razón que importa. No necesitaba vLLM todavía, y mi GTX 1080 no puede soportarlo. Lo usé de todos modos. Esa fue una tarde que no recuperaré.