Ollama vs vLLM: Marco de Decisión y Migración

Esta es la Parte 3 de una serie de 4 partes que compara Ollama y vLLM para inferencia LLM autohospedada. La Parte 1 cubrió arquitectura y filosofía de diseño. Parte 2 cubrió benchmarks y preparación para Kubernetes. La Parte 4 cierra con costo, comunidad y el veredicto final.

Ecosistema y características empresariales

vLLM domina los despliegues empresariales. Ofrece caché de prefijos para prompts repetidos, decodificación especulativa para reducir latencia, chunked prefill para eficiencia en contexto largo, salida estructurada mediante modo JSON y restricciones regex, métricas a nivel de token con un exportador Prometheus, y servicio multi-LoRA para adaptadores fine-tuneados. Estas capacidades se vuelven esenciales cuando operas bajo SLAs, necesitas observabilidad, o sirves muchas variantes fine-tuneadas de un modelo base.

Ollama prioriza la simplicidad y no expone la mayoría de estas funcionalidades avanzadas. Maneja solicitudes concurrentes, pero carece de la programación sofisticada y gestión de memoria que vLLM proporciona. Para salida estructurada o caché de prefijos, Ollama no puede competir con lo que vLLM ofrece listo para usar.

Marco de decisión

Usa este árbol de decisión:

Inicio: Cuál es tu necesidad principal?
├── Desarrollo local / experimentación de usuario único
│   └── Elige Ollama → Configuración cero, acceso instantáneo a modelos
├── Equipo pequeño (2-10 usuarios), herramientas internas
│   └── Elige Ollama → Operaciones más fáciles, rendimiento suficiente
├── API de producción, usuarios externos, requisitos SLA
│   └── Elige vLLM → Rendimiento, latencia, observabilidad
├── Ejecutando modelos > 70B parámetros
│   └── Elige vLLM → Paralelismo multi-GPU requerido
├── Apple Silicon / sin GPU NVIDIA
│   └── Elige Ollama → llama.cpp tiene soporte de hardware más amplio
├── Necesitas reemplazo directo de OpenAI
│   └── Elige vLLM → Compatibilidad total API
├── Ejecutando 10+ adaptadores LoRA fine-tuneados
│   └── Elige vLLM → Servicio Multi-LoRA listo para producción
└── Necesitas la configuración más simple posible
    └── Elige Ollama → Un binario, sin dependencias Python

Matriz de casos de uso

Caso de uso	Recomendado	Por qué
Desarrollo personal/local	Ollama	Configuración instantánea, uso mínimo de recursos
Chatbot interno de equipo pequeño	Ollama	Buen rendimiento para < 20 usuarios
API de empresa mediana	vLLM	Batching eficiente, mejor economía de unidad
Servicio empresarial grande	vLLM	Observabilidad, multi-GPU, soporte SLA
API de alto rendimiento (1k+ req/min)	vLLM	Continuous batching satura la GPU
Inferencia de baja latencia (< 50ms TTFT)	vLLM	Caché de prefijos + decodificación especulativa
Despliegue multi-nube	vLLM	Sin estado, más fácil de replicar
Apple Silicon / dispositivos edge	Ollama	Soporte nativo Metal

Ruta de migración: Ollama a vLLM

Cuando Ollama se queda pequeño y necesitas migrar a vLLM, sigue esta ruta probada. Para una guía detallada del despliegue del entorno destino, consulta mis artículos sobre despliegue de vLLM en producción y benchmarks de inferencia LLM.

Pre-migración: Evaluación

Elemento	Estado Ollama	Equivalente vLLM
Formato de modelo	GGUF	Safetensors (necesita conversión)
Clientes API	Custom / OpenAI parcial	Compatibilidad total OpenAI
Cuantización	Q4_K_M, Q5_K_M, Q8_0	AWQ, GPTQ, FP8
Usuarios concurrentes	< 20 típico	Ilimitado (con escalamiento)

Pasos de migración

Descarga el modelo en formato HuggingFace. No puedes usar directamente los archivos GGUF de Ollama. Usa la biblioteca Transformers o huggingface-cli:

huggingface-cli download meta-llama/Meta-Llama-3-8B-Instruct

Cuantiza si es necesario. Convierte a AWQ o GPTQ si la VRAM está limitada:

python -m auto_gptq --model_name_or_path ./Llama-3-8B --quantize

Despliega vLLM junto a Ollama con una estrategia azul-verde. Dirige un porcentaje del tráfico a vLLM y compara latencia y tasas de error lado a lado.
Actualiza integraciones de clientes. Cambia las URLs base de API de http://ollama:11434 a http://vllm:8000/v1.
Valida paridad. Ejecuta tu suite de pruebas contra ambos endpoints y verifica la consistencia de las salidas.
Corta el tráfico una vez que las tasas de error y latencia cumplan tus objetivos.

En la Parte 4, comparo el costo total de propiedad, analizo el momentum comunitario y entrego el veredicto final con recomendaciones específicas para cuándo elegir cada herramienta, y cuándo ejecutar ambas.

Preguntas frecuentes

¿Cuál es el factor más importante al elegir entre Ollama y vLLM? Tus requisitos de concurrencia. Para uso de un solo usuario o equipos pequeños con menos de 20 solicitudes concurrentes, Ollama ofrece buen rendimiento con operaciones mucho más simples. Para APIs de producción con muchos usuarios concurrentes, la ventaja de rendimiento de vLLM es decisiva.

¿Puedo ejecutar Ollama y vLLM lado a lado? Sí. Un patrón común es ejecutar ambos en el mismo cluster Kubernetes con un ingress dirigiendo tráfico por endpoint o nombre de modelo. Ollama maneja prototipado y herramientas internas mientras vLLM sirve tráfico de producción.

¿Cómo convierto un modelo GGUF para vLLM? No puedes usar archivos GGUF directamente con vLLM. Descarga el mismo modelo en formato HuggingFace safetensors usando huggingface-cli download, luego cuantiza opcionalmente a AWQ o GPTQ para mejor eficiencia de VRAM.

¿Es importante la compatibilidad con API de OpenAI? Si migras desde OpenAI o construyes aplicaciones que esperan la API estándar, sí. vLLM ofrece compatibilidad total incluyendo streaming, llamada a funciones, herramientas y embeddings. Ollama cubre completaciones básicas pero carece de funciones avanzadas.

¿Qué pasa si mi carga de trabajo crece después de elegir Ollama? Es un camino común. Empieza con Ollama, luego migra a vLLM cuando tu rendimiento requerido lo supere.