Cómo servir LLM en producción: vLLM vs SGLang vs Ollama

Una empresa despliega un modelo local con Ollama, escribe un chatbot interno, el equipo lo adora. Tres meses después llegan más usuarios, la cola crece, el tiempo de respuesta pasa de dos segundos a quince. Alguien dice: «compremos una GPU más potente». Se compra. La respuesta baja a ocho segundos. El problema no es el hardware — el problema es el serving stack, que no fue diseñado para cargas de producción.

Este es un escenario que vemos repetidamente. No porque los equipos hagan algo mal — Ollama es una herramienta excelente para lo que fue diseñada. El problema surge cuando una herramienta de desarrollo llega a producción sin que nadie haya preguntado: «¿qué necesitamos realmente del serving stack?» Este artículo ofrece criterios de decisión en lugar de una recomendación genérica — porque la elección correcta depende de la carga, el equipo y la infraestructura.

Por qué el serving stack importa más de lo que parece

Un framework de serving no es solo un «wrapper alrededor del modelo». Es un orquestador que decide cómo se agrupan las peticiones paralelas en lotes, cómo se gestiona la KV cache, y cómo se asigna la memoria con múltiples peticiones concurrentes.

El batching estático clásico espera a que se llene un lote y luego envía todas las peticiones a la vez — el modelo ejecuta, devuelve los resultados, se espera al siguiente lote. Es simple, pero la eficiencia cae cuando se mezclan peticiones cortas y largas. El continuous batching (implementado en vLLM, SGLang y TGI) resuelve este problema de forma diferente: cada token generado es una oportunidad para añadir al lote una nueva petición que acaba de llegar. El resultado es un throughput 2–3× mayor sin cambiar el hardware.

Otra dimensión crítica es la gestión de la KV cache — los resultados intermedios de atención (attention) que se almacenan para cada token en el contexto. Una implementación ingenua reserva memoria para la longitud máxima posible del contexto por adelantado, aunque la mayoría de las peticiones sean mucho más cortas. PagedAttention (vLLM) resuelve este problema paginando la KV cache de forma similar a como el sistema operativo pagina la RAM — sin reserva previa, con asignación dinámica. El resultado es una reducción drástica de la fragmentación: del típico 60–80 % de desperdicio a menos del 4 %.

Estas diferencias se manifiestan de forma multiplicada en entornos de producción con decenas de peticiones concurrentes, mucho más de lo que muestran los benchmarks simples con una sola petición.

vLLM: el throughput como prioridad principal

vLLM es el estándar de facto para el serving de LLM en producción cuando la prioridad principal es maximizar el throughput en GPU NVIDIA. Nació en UC Berkeley, tiene el ecosistema de integraciones más amplio y se desarrolla activamente.

Características técnicas clave:

• PagedAttention — gestión de la KV cache mediante páginas virtuales, reduce drásticamente la fragmentación de memoria y permite mayor paralelismo
• Continuous batching — incorporación dinámica de peticiones al lote activo sin esperas
• API compatible con OpenAI — migrar de una API cloud a self-hosted es en la mayoría de casos solo cambiar la URL y la clave API
• Soporte para NVIDIA, AMD (ROCm), Google TPU e Intel Gaudi
• Soporte nativo para cuantizaciones GPTQ, AWQ, FP8 y NVFP4
• Backend XGrammar para salida estructurada (modo JSON) con un overhead inferior a 40 µs por token

Cuándo vLLM gana claramente:

Cuando se opera un endpoint de API al que acceden varios usuarios o procesos de forma concurrente — un chatbot interno corporativo, un backend RAG de mayor volumen, un servidor de API para una aplicación en producción. Si se hacen benchmarks de latencia con una sola petición, la diferencia respecto a la competencia es menor. Pero con 8, 16 o 32 peticiones concurrentes, la diferencia se vuelve muy visible.

En GPU Blackwell con cuantización NVFP4, los benchmarks muestran hasta ~16× más throughput que Ollama con el mismo hardware — una diferencia que cambia la economía de todo el proyecto.

Limitaciones:

vLLM tiene una curva de aprendizaje más pronunciada. La configuración para un despliegue en producción requiere entender parámetros como --tensor-parallel-size, --max-model-len o --gpu-memory-utilization. Para un equipo sin experiencia en infraestructura LLM, la configuración inicial no es trivial. Para hardware puramente CPU o hardware de consumo sin GPU NVIDIA, el ecosistema es más limitado.

SGLang: cargas de trabajo complejas y salida estructurada

SGLang (Structured Generation Language) nació en entorno de investigación con el foco en una clase de problemas diferente: conversaciones multi-turno, cargas de trabajo agénticas con prefijos largos y salida estructurada (esquemas JSON, gramáticas).

La innovación clave es RadixAttention — una caché LRU de valores KV organizada en un árbol radix. Cuando varias peticiones comparten el mismo prefijo (por ejemplo, el mismo prompt de sistema o el mismo contexto de documento), SGLang calcula ese prefijo una sola vez y lo comparte entre las peticiones. En escenarios de RAG agéntico, donde cada petición comienza con el mismo contexto largo de documento, esto puede suponer una diferencia enorme.

Dónde SGLang supera a vLLM:

En cargas de trabajo con prefijos pesados, los benchmarks muestran un ~29 % más de throughput en H100 y un ~23 % menos de TTFT (Time to First Token) — 79 ms frente a 103 ms. Estas no son cifras despreciables en aplicaciones interactivas donde el TTFT afecta directamente la percepción de velocidad.

Para la decodificación estructurada (modo JSON, gramáticas), SGLang es más rápido: la decodificación con restricciones se ejecuta ~3× más rápido que en implementaciones anteriores, porque la compilación de la gramática se realiza de forma más eficiente.

Casos de uso típicos donde SGLang destaca:

• Cargas de trabajo agénticas multi-turno, donde cada ronda comparte un largo prefijo histórico
• Inferencia en lote sobre un gran corpus de documentos con el mismo prompt de sistema
• Aplicaciones con salida JSON intensiva (extracción de datos estructurados, clasificación)
• Pipelines RAG donde el mismo documento se consulta varias veces en una misma sesión

Limitaciones:

SGLang tiene un ecosistema algo más pequeño que vLLM y una comunidad menor, lo que se refleja en la velocidad de corrección de bugs en casos límite y en la disponibilidad de documentación. Para cargas de trabajo de inferencia estándar sin optimizaciones de prefijos, la diferencia respecto a vLLM es menor y la elección depende más de la preferencia del equipo.

Ollama: la experiencia del desarrollador en primer lugar

Ollama es una categoría de herramienta diferente. No es un framework de serving para producción — es una herramienta de escritorio para desarrolladores que hace una cosa de forma excelente: permite ejecutar un modelo local en cinco minutos, sin configuración, en cualquier hardware incluyendo Mac, Linux y Windows.

Bajo el capó corre llama.cpp, optimizado para inferencia en CPU y para trabajar eficientemente con modelos cuantizados en formato GGUF. Para la experimentación de un solo usuario y el desarrollo, esta es la combinación perfecta.

Dónde Ollama tiene sentido:

• Escritorio del desarrollador — experimentos locales, prototipado, prueba de modelos
• Herramientas internas para un solo usuario con baja carga (uno o dos usuarios concurrentes)
• Equipos sin experiencia en DevOps que necesitan algo funcional rápido
• Entornos Mac o Windows donde vLLM/SGLang no tienen soporte nativo de GPU (o es limitado)
• Despliegue on-device en los portátiles de los desarrolladores

Por qué Ollama no es suficiente para producción:

llama.cpp, que corre bajo Ollama, no está diseñado para peticiones concurrentes. Cuando llegan 8 peticiones en paralelo, la cola se procesa de forma serie — sin continuous batching. Los benchmarks muestran de forma consistente que, con el mismo hardware, vLLM es ~2,3× más rápido con 8 peticiones concurrentes. Con 16 peticiones, la diferencia es aún mayor.

Esto no es un bug de Ollama — es consecuencia de decisiones de diseño que priorizan la simplicidad y la compatibilidad sobre el throughput. Para el escritorio del desarrollador es el trade-off correcto. Para un endpoint de producción con decenas de usuarios, es un problema.

Tomar la decisión según carga y equipo

En lugar de una recomendación genérica, ofrecemos una matriz de decisión:

Equipo pequeño (2–5 personas), primeros pasos con LLM locales, experimentación: Empiece con Ollama. Aprenderá a trabajar con modelos sin la carga de infraestructura. Cuando llegue a los límites de rendimiento (y llegará), quedará claro por qué hay que migrar.

Endpoint de API en producción con varios usuarios concurrentes, GPU NVIDIA: vLLM es la elección predeterminada. El ecosistema más amplio, la mejor documentación, API compatible con OpenAI. Si el equipo no tiene experiencia en infraestructura LLM, cuente con que la configuración llevará días, no horas.

Aplicaciones agénticas, RAG con prefijos largos y repetitivos, salida JSON intensiva: Considere SGLang — RadixAttention le ahorrará memoria GPU y latencia en cargas de trabajo con prefijos pesados. Para equipos que ya tienen vLLM desplegado y funcionando, no hay razón para migrar solo por una mejora marginal. SGLang es relevante cuando se sabe que la carga de trabajo es prefix-heavy.

NVIDIA Blackwell (GB200/B200), máximo rendimiento: vLLM o TensorRT-LLM — ambos están optimizados para cuantización NVFP4 en GPU Blackwell. TensorRT-LLM tiene mayor peak de rendimiento, pero una complejidad de configuración y operaciones significativamente mayor.

Entorno regulado, red air-gapped, sin dependencias cloud: Los tres corren completamente offline. Para despliegues en producción en entornos regulados, recomendamos vLLM por su ecosistema y auditabilidad. Más sobre las especificidades de los despliegues regulados en el artículo LLM on-prem para sectores regulados.

Lo que el serving stack no es: diferenciación de cuantización y dimensionamiento de GPU

Cuando las empresas empiezan a abordar «cómo desplegar un LLM», tres temas se mezclan habitualmente: serving stack, cuantización y dimensionamiento de GPU. Son decisiones separadas con distinta prioridad.

La cuantización es la decisión sobre la precisión numérica de los pesos del modelo (FP16 vs Q8 vs Q4 vs GPTQ/AWQ). Afecta al tamaño del modelo en memoria y a la velocidad de inferencia con una pérdida de calidad aceptable. Q4_K_M está a ~5–8 % de FP16 en la mayoría de benchmarks — una diferencia que en la mayoría de casos de uso en producción no es perceptible. La cuantización es ortogonal a la elección del serving stack: se puede ejecutar un modelo cuantizado con vLLM o con Ollama. Más en profundidad sobre los formatos en el artículo Cuantización de LLM (GGUF, AWQ, GPTQ).

El dimensionamiento de GPU es la decisión sobre cuánta VRAM (y cuántas GPU) se necesitan para el modelo y la carga dados. Es un cálculo separado: VRAM para los pesos del modelo + KV cache para el número previsto de peticiones concurrentes × la longitud del contexto. Un mal serving stack en el hardware correcto seguirá sin rendir; el serving stack correcto en hardware infradimensionado tampoco. Más sobre los cálculos concretos de VRAM en el artículo Qué GPU para inferencia LLM.

El orden de decisiones en la práctica: primero el modelo (tamaño, capacidades), luego la cuantización (reduce los requisitos de memoria), luego el dimensionamiento de GPU (cuánta VRAM se necesita), finalmente el serving stack (cómo se atiende la carga). Muchos equipos lo hacen en orden inverso y luego se preguntan por qué la optimización no es suficiente.

KV cache y contexto largo: la carga oculta de memoria

Un número que se subestima al comparar serving stacks: la KV cache crece linealmente con la longitud del contexto. Para un modelo de 70B con un contexto de 128K, solo la KV cache puede ocupar unos 40 GB — además de los pesos del modelo. Para cuatro peticiones paralelas con ese contexto, son ~160 GB adicionales.

Los modelos modernos con Grouped Query Attention (GQA) reducen drásticamente esta carga frente a la atención multi-cabeza clásica — la mayoría de los modelos actuales (Llama 4, Qwen 3, Mistral Large) incorporan GQA. Otra optimización es la cuantización de la KV cache a INT8/FP8, que reduce su tamaño a la mitad con una pérdida de calidad mínima.

Para cargas de trabajo con contexto largo — por ejemplo, procesamiento de documentos industriales extensos, múltiples rondas de conversación en soporte técnico — este número es crítico al decidir la configuración de GPU. vLLM mediante PagedAttention gestiona la KV cache dinámicamente y de forma más eficiente que una implementación ingenua; SGLang mediante RadixAttention además comparte la KV cache para prefijos repetidos.

Consecuencia práctica: «ventana de contexto de 1M de tokens» suena genial al cliente. En la práctica, cada petición con 1M de tokens requiere decenas de gigabytes de KV cache. Para la mayoría de casos de uso en producción, el RAG es económicamente más eficiente que llenar todo el documento al contexto — aunque el modelo soporte técnicamente el contexto largo.

Monitorización y observabilidad en producción

Cualquiera que sea el serving stack elegido, un despliegue en producción sin monitorización es volar a ciegas. Tres métricas que hay que seguir desde el primer día:

TTFT (Time to First Token) — cuánto tarda el modelo en producir el primer token. Afecta directamente la percepción de velocidad en aplicaciones interactivas. Para interfaces conversacionales, un TTFT inferior a 300–500 ms es el umbral en el que el usuario siente la respuesta como «inmediata».

Throughput (tokens/segundo) — global y por petición. Importante para cargas de trabajo en lote y en la planificación de capacidad.

Profundidad de cola y latencia de cola — cuando la cola crece, es una señal de escalar horizontalmente o de revisar la configuración de batching. Una cola creciente con TTFT estable indica que el problema es de capacidad, no de eficiencia del serving.

Tanto vLLM como SGLang exportan métricas Prometheus de forma nativa — un dashboard en Grafana es cuestión de una hora de trabajo. Para los equipos que también gestionan el lado de los costes, un enfoque interesante es el LLM routing: enviar peticiones simples a un modelo más pequeño y barato, y las complejas a uno mayor. Sobre esto con más detalle en el artículo LLM routing y cascading.

Preguntas frecuentes

¿Puedo usar Ollama en producción si solo tengo uno o dos usuarios concurrentes?

Sí, para cargas realmente pequeñas — un equipo, unas pocas personas, baja frecuencia de peticiones — Ollama funciona en producción. El problema llega con el crecimiento. Cuando la carga se duplica y Ollama no da abasto, la migración a vLLM no es un cambio trivial: modelo de configuración diferente, gestión de procesos diferente, patrones de despliegue diferentes. Si se prevé que la carga crecerá, merece la pena construir el serving stack correctamente desde el principio.

¿Es vLLM o SGLang mejor para aplicaciones RAG?

Depende de la arquitectura concreta del RAG. Si cada petición empieza con el mismo prompt de sistema con poca variabilidad y los documentos cortos cambian en cada petición, vLLM y SGLang son comparables. Si la arquitectura comparte un contexto de documento largo entre múltiples peticiones en una misma sesión (por ejemplo, análisis de un manual extenso con varias preguntas), RadixAttention en SGLang puede ahorrar memoria y latencia de forma significativa. Para más sobre arquitecturas RAG, consulte Agentic RAG.

¿En qué se diferencia vLLM de TensorRT-LLM?

TensorRT-LLM de NVIDIA logra un mayor peak de rendimiento en hardware NVIDIA (especialmente Blackwell) gracias a los kernels fusionados y la cuantización NVFP4. El precio es una complejidad significativamente mayor: los modelos deben compilarse antes del despliegue, el pipeline es menos flexible y la configuración lleva más tiempo. vLLM es la opción más pragmática en la mayoría de escenarios de producción — se obtiene el 80–90 % del rendimiento de TensorRT-LLM con una fracción de la complejidad operativa. TensorRT-LLM tiene sentido con requisitos de throughput extremos o cuando se optimiza para un modelo concreto en un hardware concreto.

¿Funcionan estos frameworks también con modelos cuantizados?

Sí, los tres soportan modelos cuantizados. vLLM y SGLang procesan nativamente los formatos AWQ y GPTQ y tienen soporte FP8/NVFP4 para GPU Blackwell. Ollama trabaja principalmente con el formato GGUF (llama.cpp). Para despliegues en producción en GPU NVIDIA, AWQ o GPTQ suelen ser más ventajosos que GGUF, porque aprovechan los kernels CUDA optimizados. Para despliegues cross-platform o en CPU, GGUF es más práctico.

¿Cuánto tiempo lleva migrar de Ollama a vLLM?

Si la aplicación se comunica mediante una API REST compatible con OpenAI (que es el caso de la mayoría de despliegues con Ollama), la migración a vLLM es, desde el punto de vista del código de aplicación, simplemente cambiar la URL base y la clave API. El trabajo mayor está en el lado de la infraestructura: despliegue, monitorización, configuración de capacidad. Para un equipo que lo hace por primera vez, cuente con uno o dos días de trabajo para un despliegue en producción funcional.

*En MP Industrial Solutions ayudamos a las empresas a diseñar y desplegar infraestructura LLM que se ajuste a la carga real y al equipo — no solo a una demo. Si está evaluando qué serving stack es el correcto para su caso de uso, o si Ollama empieza a crujir bajo la carga, estaremos encantados de analizarlo juntos.*