vLLM vs Ollama: la respuesta breve
Elige Ollama cuando la primera tarea sea descargar un modelo abierto, ejecutarlo en un portátil o un servidor pequeño, y permitir que un desarrollador pruebe prompts o una aplicación privada rápidamente. Elige vLLM cuando la tarea sea servir un modelo conocido a muchos usuarios con capacidad de GPU que operas tú, y estés preparado para medir las colas, el rendimiento de tokens, el uso de memoria y la latencia de cola. Ninguna de las dos opciones convierte un modelo autohospedado en un servicio gestionado; sigues siendo responsable del modelo, el hardware, el despliegue y la respuesta ante incidentes.
La comparación no es «fácil frente a rápido» en todos los entornos. Ollama puede gestionar solicitudes simultáneas, y vLLM puede ejecutar una única solicitud. El rendimiento depende del modelo, la cuantización, la longitud del contexto, el acelerador, la combinación de solicitudes y la concurrencia. Considera cualquier benchmark sin esos detalles como una hipótesis inicial, no como una decisión de compra.
| Punto de decisión | Ollama | vLLM |
|---|---|---|
| Punto de partida más natural | Experimentación local y un flujo de trabajo sencillo de servicio de modelos | Servicio de inferencia dedicado con objetivos explícitos de rendimiento y latencia |
| Flujo de trabajo del modelo | Descargar y ejecutar modelos mediante las herramientas de modelos de Ollama | Servir un modelo o checkpoint compatible con un motor de inferencia |
| Interfaz HTTP | API de Ollama más un subconjunto documentado de endpoints compatibles con OpenAI | Servidor documentado compatible con OpenAI con compatibilidad de endpoints dependiente del modelo |
| Concurrencia | Solicitudes paralelas y cola configurables; la memoria crece con los contextos paralelos | Planificación y batching continuos diseñados para inferencia simultánea en GPU |
| Pregunta operativa principal | ¿Este despliegue sigue cumpliendo los objetivos de latencia y memoria bajo carga real? | ¿Qué ajustes del motor y topología de GPU cumplen esos objetivos sin inestabilidad? |
| Mejor prueba | Ejecutar la misma combinación de solicitudes de la aplicación en el host de destino | Ejecutar la misma combinación de solicitudes de la aplicación en las GPU de destino |
La tabla describe la orientación de los productos, no una clasificación universal de velocidad. Si tu tráfico es esporádico, un servicio local de Ollama bien ajustado puede ser suficiente. Si el tráfico llega en ráfagas de muchos usuarios, merece la pena evaluar el planificador de vLLM, pero el modelo debe seguir cabiendo y el servicio debe mantenerse estable bajo carga.
Qué cambia bajo carga simultánea
Un único prompt oculta la diferencia principal. En una API real, las solicitudes llegan en momentos distintos, tienen diferentes longitudes de prompt y producen distintas longitudes de salida. El sistema de servicio debe decidir qué solicitudes comparten el trabajo de la GPU y cuánta memoria reservar para su estado de atención.
vLLM se basa en un motor de inferencia que programa solicitudes simultáneas y gestiona la caché clave-valor. Su interfaz de servicio expone controles para el batching, los límites de secuencia, el uso de memoria y el paralelismo. Estos controles son útiles cuando un equipo puede observar el resultado de cada cambio. También pueden hacer que un despliegue sea más difícil de operar si se copian configuraciones de un benchmark con un modelo o una GPU distintos.
Las preguntas frecuentes oficiales de Ollama documentan controles de procesamiento paralelo y de cola, incluido OLLAMA_NUM_PARALLEL. Aumentar la concurrencia puede incrementar los requisitos de memoria porque más solicitudes mantienen el contexto en memoria. Por tanto, la pregunta razonable no es «¿Puede Ollama atender a usuarios simultáneos?», sino «Con nuestro modelo y longitud de contexto, ¿cuándo el tiempo de cola o la presión de memoria se vuelven inaceptables?»
Para ambos sistemas, informa como mínimo del tiempo hasta el primer token, los tokens de salida por segundo, la latencia integral p95 y p99, el tiempo de cola, las solicitudes fallidas y el uso de memoria de GPU. Un único número medio de tokens por segundo puede ocultar una primera respuesta con mucho retraso o una cola que crece durante una ráfaga.
La compatibilidad de API es útil, pero verifica las funciones exactas
Ambos proyectos documentan una vía compatible con OpenAI. Esto puede reducir los cambios en el cliente, pero la compatibilidad no equivale a un comportamiento idéntico para cada modelo o endpoint. Comprueba la operación exacta que utilizas: completados de chat, streaming, llamadas a herramientas, salida estructurada, embeddings, audio o entrada multimodal. Después, ejecuta una prueba de contrato con el modelo y la versión del servidor que vayas a desplegar.
Para Ollama, la documentación oficial describe un subconjunto de la API de OpenAI. Para vLLM, el servidor admite varios endpoints de estilo OpenAI, cuya aplicabilidad depende del tipo y la configuración del modelo. No prometas compatibilidad completa e inmediata basándote únicamente en la URL base. Valida los campos de solicitud, las estructuras de respuesta, la gestión de errores, la finalización del streaming y la contabilidad de tokens con tu propio SDK.
Una prueba de migración práctica consiste en enviar un conjunto fijo de prompts reales a ambos backends mediante el mismo entorno de pruebas de cliente, capturar las respuestas completas y los códigos de error, y revisar cualquier diferencia antes de cambiar el tráfico. Mantén los pesos del modelo, los ajustes de generación y las plantillas de prompt lo más similares posible. Un modelo o formato de cuantización diferente invalida una comparación simple del rendimiento entre servidores.
Despliegue: elige la carga de trabajo antes que la herramienta
Desarrollo local o una pequeña herramienta interna. Empieza con Ollama cuando los desarrolladores necesiten una forma sencilla de descargar un modelo y llamarlo localmente. Confirma que el modelo cabe en la máquina y que los usuarios simultáneos no convierten un prototipo con buena capacidad de respuesta en una cola. No expongas el servicio local a internet sin autenticación y un límite de red.
Un modelo de producción estable con demanda sostenida de GPU. Evalúe vLLM en el acelerador, checkpoint, longitud de contexto y mezcla de solicitudes esperada reales. Dimensione el despliegue para los contextos concurrentes máximos, así como para el volumen medio de tokens. Pruebe los arranques en frío, la carga del modelo, el reemplazo gradual, los fallos de GPU y el comportamiento cuando las solicitudes superan la capacidad. Un motor de servicio es solo una parte de la preparación para producción.
Un flujo de trabajo mixto de desarrollo y producción. Es razonable crear prototipos con Ollama y servir un modelo seleccionado con vLLM más adelante. Mantenga el contrato de la aplicación separado del motor de servicio y reserve tiempo para volver a probar el comportamiento. Un modelo que funciona localmente puede necesitar un formato de checkpoint, una configuración de contexto o una plantilla de llamadas a herramientas diferentes en otro motor.
Demanda variable o modelos que cambian con frecuencia. Calcule si operar capacidad de GPU dedicada está justificado en absoluto. Si la utilización es baja o los modelos cambian a menudo, una API de modelo alojada puede ser más sencilla. El producto actual de Flatkey es una API unificada de modelos y herramientas con una clave y registros de uso; es una alternativa a operar un servidor de inferencia, no una afirmación de que el sitio le alquile una instancia de GPU de Ollama o vLLM. Consulte la documentación de Flatkey y su guía sobre nube de GPU frente a API de modelos para tomar esa decisión.
Cómo evaluar vLLM y Ollama de forma justa
Use una familia de modelos y un checkpoint equivalente siempre que sea posible. Registre la revisión del modelo, el formato de los pesos, la cuantización, el modelo y la cantidad de GPU, las versiones del controlador/runtime, el límite de contexto y la versión del servidor. Si estos difieren, describa la comparación como dos configuraciones de despliegue en lugar de una evaluación comparativa pura de motores.
- Elabore un conjunto de solicitudes representativo. Incluya prompts cortos y largos, longitudes de salida realistas, llamadas con y sin streaming y el porcentaje de solicitudes que usa cada tipo.
- Ejecute una línea de base en caliente. Mantenga el modelo residente y mida la latencia de un solo usuario. Esto le indica si una ralentización procede de la carga del modelo o del servicio bajo concurrencia.
- Aumente la concurrencia gradualmente. Para cada paso, registre las solicitudes completadas por segundo, los tokens de entrada y salida por segundo, el tiempo hasta el primer token, la latencia p95/p99, la profundidad de la cola, la tasa de fallos y la memoria de GPU.
- Pruebe una ráfaga, no solo un estado estable. Una cola que se vacía lentamente puede parecer adecuada en una prueba breve de rendimiento medio, mientras los usuarios reales esperan demasiado tiempo.
- Incluya la ruta de la aplicación. Añada autenticación, saltos de red, reintentos y cualquier gateway a la prueba final. La evaluación del motor por sí sola no mide la latencia visible para el usuario.
- Repita después de cambiar una configuración. Si cambia la longitud de contexto, la cuantización, el número de solicitudes paralelas o la configuración del planificador de vLLM, vuelva a ejecutar la misma carga de trabajo y conserve el resultado anterior para compararlo.
No copie una cifra pública de «X veces más rápido» en un modelo de compras. Una evaluación comparativa pública puede revelar una hipótesis útil, pero su hardware, modelo, precisión, procesamiento por lotes y distribución de prompts pueden no coincidir con los suyos. El mejor resultado es la configuración más rápida que también cumple sus presupuestos de latencia y errores con la capacidad que realmente puede comprar u operar.
Coste: incluya el tiempo de inactividad y el tiempo de ingeniería
Una estimación de costes de autoalojamiento debe comenzar con el total de horas de GPU, no con el pico de tokens por segundo. Añada almacenamiento, transferencia de datos, equilibrio de carga, monitorización, soporte y el tiempo necesario para mantener el servicio actualizado y recuperable. Divida por la salida útil aceptada, no por cada token generado: los reintentos, las generaciones fallidas y las horas inactivas siguen consumiendo capacidad.
Un modelo mensual sencillo es:
coste mensual de autoalojamiento = horas de GPU × tarifa horaria de GPU + almacenamiento + red + operaciones.
Después, calcule el coste por solicitud aceptada o por millón de tokens aceptados usando su carga de trabajo medida. Ejecute un caso de baja utilización y un caso de ráfagas. Ollama puede ser más barato de operar a pequeña escala porque el flujo de trabajo es sencillo; vLLM puede proporcionar más trabajo útil a partir de GPU ocupadas para algunas cargas de trabajo. Ninguna de las dos conclusiones se deriva solo del nombre de una herramienta.
Si la comparación trata realmente sobre nube de GPU frente a una API, evalúelo por separado. Una API de modelo puede facturarse por uso satisfactorio, mientras que las GPU dedicadas generan costes cuando están inactivas; el autoalojamiento aún puede ganar cuando la demanda es sostenida y el modelo permanece estable. La guía de costes de Flatkey ofrece un marco para poner a prueba esas suposiciones.
Preguntas frecuentes
¿vLLM es siempre más rápido que Ollama?
No. vLLM está diseñado para servir con alto rendimiento, pero la velocidad medida depende de la carga de trabajo, el modelo, la configuración y el hardware. Pruebe ambos con el objetivo de concurrencia y latencia que le importa. Un solo prompt, una cuantización diferente o una GPU diferente no constituyen una comparación justa.
¿Puede Ollama gestionar varias solicitudes?
Sí. Ollama documenta solicitudes paralelas configurables y el comportamiento de las colas. Más contextos concurrentes pueden requerir más memoria, así que aumente la configuración solo después de medir el tiempo en cola, la memoria de GPU y la tasa de errores en el host previsto.
¿Ambos admiten la API de OpenAI?
Ambos documentan interfaces compatibles con OpenAI, pero el subconjunto admitido y el comportamiento específico de cada modelo difieren. Ejecute pruebas del contrato de solicitudes y respuestas para los endpoints y las funciones que utiliza su aplicación antes de trasladar el tráfico.
¿Cuál debería elegir para un producto de IA?
Utiliza Ollama para poner en marcha un modelo y evaluar una carga de trabajo pequeña o interna. Evalúa vLLM cuando el servicio dedicado con GPU sea una vía central de producción y necesites ajustar la inferencia concurrente. Si el modelo o el patrón de tráfico cambian con frecuencia, compara ambas opciones autohospedadas con una API de modelos alojada antes de comprometerte con capacidad de GPU.
