vLLM vs SGLang 2026: benchmarks reales en H100s — cuál usar en producción

vLLM vs SGLang: Elegir el servidor de inferencia LLM adecuado en 2026

Hugging Face puso TGI en modo mantenimiento en diciembre de 2025 y ahora dirige a los equipos hacia vLLM o SGLang para nuevos despliegues. Si estás montando una infraestructura de inferencia hoy, la pregunta real no es "¿debería alejarme de TGI?" -- es cuál de estos dos motores encaja realmente con tu carga de trabajo.

Resumen rápido

Elige vLLM si quieres el soporte de hardware más amplio, la comunidad más grande y un camino probado hacia producción en AWS, GCP y Azure.

Elige SGLang si tu carga de trabajo es intensiva en conversaciones de múltiples turnos, salidas estructuradas o pipelines con muchos prefijos como RAG -- y estás cómodo con un ecosistema más pequeño.

Ahora veamos dónde cada motor realmente toma la delantera.

¿Cómo llegamos aquí? La salida de TGI

Text Generation Inference (TGI) sostuvo el ecosistema de Hugging Face durante años, pero desde diciembre de 2025 solo acepta correcciones de errores -- sin nuevas características. Los propios Inference Endpoints de Hugging Face ahora usan vLLM por defecto, con SGLang como alternativa.

Eso deja dos contendientes reales para el serving LLM auto-alojado. Ambos son open-source, ambos hablan la API de OpenAI y ambos funcionan en GPUs NVIDIA. Las diferencias aparecen bajo carga.

Veredicto: Tanto vLLM como SGLang son reemplazos de TGI listos para producción. Si estás migrando, cualquiera es una apuesta segura -- el resto de esta guía te ayuda a elegir cuál.

Benchmarks de rendimiento y latencia

Los benchmarks varían según el modelo, la GPU y la concurrencia, por eso aquí hay cifras de pruebas independientes en el mismo hardware. Los siguientes datos provienen de los benchmarks H100 de Spheron usando Llama 3.3 70B Instruct en FP8 y las pruebas de PremAI con Llama 3.1 8B.

Llama 3.3 70B en H100 (FP8)

Llama 3.1 8B en H100

En modelos más pequeños la brecha se amplía. PremAI midió SGLang en aproximadamente 16.200 tok/s frente a los 12.500 tok/s de vLLM -- una ventaja de rendimiento del 29% para SGLang. LMDeploy igualó a SGLang aquí, pero esa es una conversación aparte.

Qué significan los números

A escala 70B el delta es modesto (3-5%). A escala 8B es significativo. El patrón tiene sentido: el RadixAttention de SGLang rinde más cuando el prefill es una fracción mayor del coste total, lo que ocurre con modelos más pequeños y salidas más cortas.

La latencia de cola cuenta una historia similar. El TTFT p95 de SGLang fue consistentemente 5-8% menor que vLLM en todos los niveles de concurrencia probados. Si estás construyendo una interfaz de chat en tiempo real donde cada 50ms importa, esa brecha se acumula entre usuarios.

Veredicto: SGLang gana en rendimiento bruto, especialmente para modelos más pequeños. vLLM está cerca a escala 70B+. Para la mayoría de las cargas de trabajo en producción la diferencia es de un solo dígito -- significativa a escala, pero no determinante por sí sola.

Prefix caching: RadixAttention vs. Automatic Prefix Caching

Ambos motores cachean cálculos KV para prefijos repetidos, pero los mecanismos difieren de maneras que importan para ciertas cargas de trabajo. Si ya estás familiarizado con el caching de prompts a nivel de API, piensa en esto como la versión del lado del servidor.

vLLM usa hash a nivel de bloque. Divide el caché KV en bloques de tamaño fijo, los hashea y busca coincidencias en nuevas solicitudes. Predecible, eficiente y fácil de razonar -- pero necesitas límites de bloque consistentes para que haya aciertos en el caché.

SGLang usa un árbol radix indexado a nivel de token. Descubre automáticamente prefijos compartidos entre solicitudes sin configuración manual. Si 50 usuarios envían mensajes en el mismo hilo de conversación, SGLang encuentra y reutiliza el prefijo común automáticamente.

Dónde realmente importa

RunPod hizo benchmarks de conversaciones de múltiples turnos y encontró que SGLang entregaba ~30-31 tok/s de manera consistente bajo alta concurrencia, mientras que vLLM bajaba de 22 a 16 tok/s a medida que aumentaba la presión en el caché. Esa es una brecha significativa para cargas de trabajo de chatbot y agente.

Para inferencia por lotes en prompts con plantillas -- donde cada solicitud usa el mismo prompt del sistema -- el enfoque de vLLM funciona bien. Los límites del caché se alinean naturalmente con la estructura de tu plantilla.

Veredicto: SGLang gana para cargas de trabajo dinámicas y de múltiples turnos. vLLM es perfectamente adecuado para inferencia por lotes y prompts con plantillas donde los prefijos son predecibles.

Salidas estructuradas

Si necesitas aplicación de esquemas JSON o generación restringida, esta sección importa mucho. Ambos motores soportan salidas estructuradas a través de backends de gramática como XGrammar y LLGuidance, pero la historia de rendimiento es muy diferente.

SqueezeBits ejecutó benchmarks detallados y encontró que vLLM muestra degradación significativa del rendimiento con decodificación guiada habilitada, especialmente con tamaños de lote de 8 y superiores. SGLang, por el contrario, superpone la generación de máscaras con el paso de inferencia de la GPU, manteniendo el overhead mínimo.

Esquemas repetitivos vs. dinámicos

La elección del backend también importa:

Sin aplicación estructurada, las salidas caen a ~61% de corrección en esquemas complejos. Con ella, la corrección sube 20-25 puntos porcentuales. Así que esto no es opcional para flujos de trabajo de agentes en producción -- y el motor que elijas determina cuánto rendimiento sacrificas.

Veredicto: SGLang gana para salidas estructuradas. Si tu pipeline depende de la aplicación de esquemas JSON (y la mayoría de los flujos de trabajo de agentes sí), el enfoque superpuesto de SGLang significa que no pagas un impuesto de rendimiento.

Serving multi-LoRA y modelos fine-tuneados

Ambos motores soportan servir múltiples adaptadores LoRA desde un único modelo base, lo cual es esencial si afinas modelos para diferentes inquilinos o tareas.

SGLang trata el multi-LoRA como una característica de primera clase con batching nativo -- las solicitudes dirigidas a diferentes adaptadores pueden compartir el mismo lote. vLLM también lo soporta, pero la implementación de SGLang ha sido ligeramente más pulida en versiones recientes.

¿La diferencia práctica? Si sirves 5-10 adaptadores LoRA desde un modelo base Llama 70B, ambos funcionan. Si ejecutas más de 50 adaptadores con patrones de tráfico heterogéneos, el batching nativo de SGLang maneja la programación de manera más elegante.

Veredicto: SGLang tiene una ligera ventaja para multi-LoRA a escala. Para un puñado de adaptadores, ambos motores funcionan igual de bien.

Decodificación especulativa

Ambos motores soportan la decodificación especulativa, que usa un pequeño modelo "borrador" para predecir tokens que el modelo principal verifica en paralelo. El resultado es inferencia 2-3x más rápida para escenarios limitados por memoria.

vLLM introdujo recientemente Unified Parallel Drafting, y la decodificación especulativa ahora funciona junto con las salidas estructuradas. La implementación de SGLang es similar en capacidad, con un rendimiento ligeramente mejor en niveles de concurrencia moderados.

El verdadero diferenciador no es el motor -- es si la decodificación especulativa se adapta a tu carga de trabajo. Ayuda más con salidas largas de modelos grandes donde el cuello de botella es el ancho de banda de memoria, no el cómputo.

Veredicto: Empate. Ambos motores entregan aceleraciones comparables con decodificación especulativa.

Soporte de hardware y despliegue

Aquí es donde vLLM se adelanta significativamente.

vLLM

• GPUs NVIDIA (A100, H100, H200, B200)
• GPUs AMD (MI250, MI300X)
• GPUs Intel (vía vllm-xpu-kernels)
• AWS Trainium e Inferentia
• Google TPUs
• Docs de Kubernetes maduras con charts de Helm, probes de startup/readiness/liveness
• Integración de NVIDIA Container Toolkit out of the box

SGLang

• GPUs NVIDIA (A100, H100, H200, B200)
• GPUs AMD (MI300X, vía ROCm)
• Despliegue Docker-first
• Kubernetes es posible pero menos documentado

Si estás desplegando en algo que no sea NVIDIA o AMD, vLLM es tu única opción. En AWS específicamente, el soporte de Trainium significa que puedes reducir significativamente los costes de inferencia -- y SGLang no puede tocar ese hardware.

Para equipos que trabajan con GPUs NVIDIA estándar, la historia del despliegue es similar. Ambos proporcionan imágenes Docker y endpoints compatibles con OpenAI. vLLM simplemente tiene más guías de producción probadas y charts de Helm contribuidas por la comunidad.

Si estás explorando herramientas para ejecutar LLMs localmente o quieres una vista más amplia de la inferencia auto-alojada, ambos motores también soportan despliegue local en GPUs de consumidor -- aunque están diseñados para hardware de centro de datos.

Veredicto: vLLM gana en amplitud de hardware y madurez de despliegue. SGLang está bien si estás en NVIDIA o AMD. En cualquier otro lugar, vLLM es la única opción.

Serving desagregado

Ambos motores soportan separar prefill (intensivo en cómputo) de decode (intensivo en memoria) en diferentes grupos de workers. Esto te permite escalar cada fase de manera independiente -- más workers de prefill durante ráfagas con muchos prompts, más workers de decode para generación larga.

SGLang soporta Mooncake y NIXL como backends de transferencia para desagregación y ha publicado resultados que muestran 2,7x mayor rendimiento de decodificación en clusters NVIDIA GB200 NVL72. El serving desagregado de vLLM también es funcional, aunque menos documentado prominentemente.

Esta característica importa más a escala muy grande (96+ GPUs). Si estás ejecutando un puñado de GPUs, probablemente aún no lo necesitas.

Veredicto: SGLang tiene una ligera ventaja en madurez del serving desagregado. Ambos lo soportan; SGLang ha publicado más resultados del mundo real.

Cuándo usar cada uno: marco de decisión

La respuesta honesta para muchos equipos: prueba ambos. Los dos son open-source, ambos exponen la misma API de OpenAI, y cambiar entre ellos es un intercambio de contenedor. Ejecuta tu carga de trabajo real contra cada uno durante un día y compara las métricas que te importan.

Si estás enrutando tráfico a través de múltiples backends de inferencia, una gateway LLM puede estar frente a cualquiera de los motores y manejar failover, límite de velocidad y observabilidad.

Cómo Techsy aborda la selección del servidor de inferencia

Cuando ayudamos a equipos a desplegar características impulsadas por LLM, la elección del motor de inferencia se reduce a tres preguntas:

1. ¿A qué hardware estás limitado? Si es Trainium o TPUs, es vLLM. Todo lo demás, ambos funcionan.
2. ¿Cuál es la forma de tu carga de trabajo? El chat de múltiples turnos y los bucles de agentes favorecen el prefix caching de SGLang. El procesamiento por lotes y las completions simples están bien en cualquiera.
3. ¿Cuánta capacidad de operaciones tienes? La comunidad más grande de vLLM significa más respuestas de StackOverflow y charts de Helm cuando algo se rompe a las 3 de la mañana.

Hemos ejecutado cargas de trabajo en producción en ambos. Son genuinamente cercanos. La respuesta correcta depende de tus restricciones, no de que uno sea "mejor" de manera abstracta.

¿Necesitas ayuda para elegir o desplegar un servidor de inferencia? Contáctanos -- evaluaremos tu carga de trabajo y recomendaremos el stack adecuado.

Elegir una herramienta es la parte fácil. Hacer que funcione de forma fiable dentro de un producto real es donde la mayoría de los equipos se atasca, y eso es exactamente lo que nuestro equipo de integración de IA construye para sus clientes, desde pipelines RAG hasta agentes a medida.

Preguntas frecuentes

¿Es SGLang más rápido que vLLM?

En modelos más pequeños (7B-8B), SGLang muestra aproximadamente un 29% más de rendimiento en GPUs H100. En modelos de 70B+, la brecha se reduce a 3-5%. SGLang también tiene menor latencia de cola (TTFT p95) en todos los niveles de concurrencia probados.

¿Puedo usar vLLM y SGLang con el formato de API de OpenAI?

Sí. Ambos exponen endpoints compatibles con OpenAI out of the box. Puedes intercambiarlos sin cambiar tu código de cliente. Tus llamadas a /v1/chat/completions funcionan de manera idéntica en cualquiera.

¿Por qué Hugging Face deprecó TGI?

TGI entró en modo mantenimiento en diciembre de 2025. Hugging Face decidió contribuir a vLLM y SGLang en lugar de mantener un motor de inferencia separado. TGI todavía funciona para despliegues existentes, pero no vendrán nuevas características.

¿SGLang soporta GPUs NVIDIA y AMD?

SGLang soporta GPUs NVIDIA (A100, H100, H200, B200) y GPUs AMD (MI300X vía ROCm). No soporta GPUs Intel, AWS Trainium, Inferentia ni Google TPUs. vLLM tiene una cobertura de hardware más amplia.

¿Qué es RadixAttention y por qué importa?

RadixAttention es el mecanismo de prefix caching de SGLang. Almacena entradas del caché KV en un árbol radix indexado a nivel de token, descubriendo automáticamente prefijos compartidos entre solicitudes. Esto hace que las conversaciones de múltiples turnos y los pipelines RAG sean significativamente más rápidos porque el contexto repetido no necesita ser recomputado.

¿Qué motor es mejor para salidas JSON estructuradas?

SGLang. Superpone la generación de máscaras de gramática con la inferencia de GPU, por lo que la aplicación de salidas estructuradas apenas impacta el rendimiento. vLLM muestra degradación notable en tamaños de lote de 8 y superiores cuando la decodificación guiada está habilitada.

¿Puedo servir múltiples adaptadores LoRA desde un modelo base?

Ambos motores soportan serving multi-LoRA. SGLang lo trata como una característica nativa con batching a través de diferentes adaptadores en el mismo lote de solicitudes. vLLM también lo soporta, pero la programación de SGLang es más eficiente con un alto número de adaptadores.

¿Qué es el serving prefill/decode desagregado?

Significa ejecutar la fase de prefill (procesamiento del prompt) en workers de GPU separados de la fase de decode (generación de tokens). El prefill está limitado por cómputo; el decode está limitado por memoria. Separarlos te permite escalar cada fase de manera independiente. Ambos motores soportan esto, con SGLang teniendo más resultados de producción publicados.

¿Cómo migro de TGI a vLLM o SGLang?

Dado que los tres exponen APIs compatibles con OpenAI, la migración es principalmente un intercambio de contenedor. Apunta tu Docker Compose o despliegue de Kubernetes a la nueva imagen, ajusta los flags de carga del modelo y actualiza los endpoints de comprobación de salud. El código del cliente permanece igual.

¿Debería usar vLLM o SGLang para un pipeline RAG?

SGLang es la opción más sólida para RAG. Su RadixAttention automáticamente cachea y reutiliza los largos prompts del sistema y los contextos de documentos que los pipelines RAG envían repetidamente. El caching a nivel de bloque de vLLM también funciona, pero verás mejores tasas de acierto en caché con el enfoque a nivel de token de SGLang cuando los fragmentos de documentos varían ligeramente entre solicitudes.

Veredicto final

SGLang gana más categorías, pero las ventajas de vLLM -- amplitud de hardware y madurez del ecosistema -- son el tipo de cosas que importan a las 3 de la mañana cuando un nodo cae.

Si estás en hardware NVIDIA y tu carga de trabajo implica conversaciones de múltiples turnos, agentes con salidas estructuradas o pipelines RAG con prefijos compartidos, empieza con SGLang. Obtendrás mejor rendimiento y menor latencia donde importa.

Si necesitas flexibilidad multi-nube, soporte para hardware no-NVIDIA, o la comodidad de la comunidad open-source de serving LLM más grande, empieza con vLLM. Es el valor predeterminado más seguro que servirá bien a la mayoría de los equipos.

De cualquier manera, ambos motores son excelentes y mejoran rápido. Elige uno, despliégalo, mide tu carga de trabajo real y cambia si los números te lo dicen. La API compatible con OpenAI hace que ese cambio sea indoloro.

Fuentes

• Benchmarks H100 de Spheron: vLLM vs TensorRT-LLM vs SGLang
• PremAI: Benchmarks vLLM vs SGLang vs LMDeploy
• SqueezeBits: Rendimiento de decodificación guiada en vLLM y SGLang
• RunPod: Reutilización de caché KV de SGLang vs vLLM
• Documentación oficial de SGLang
• Documentación oficial de vLLM