LLM Motores de Inferencia: vLLM vs LMDeploy vs SGLang
Evaluamos comparativamente 3 motores de inferencia de LLM líderes en hardware NVIDIA H100: vLLM, LMDeploy y SGLang. Cada motor procesó cargas de trabajo idénticas: 1,000 prompts de ShareGPT usando Llama 3.1 8B-Instruct para aislar el verdadero impacto en el rendimiento de sus decisiones arquitectónicas y estrategias de optimización.
Motores | Mejor para |
|---|---|
vLLM | -Prototipado y experimentación con más de 100 arquitecturas de modelos -Entornos multi GPU (NVIDIA, AMD, Intel) |
LMDeploy | -Despliegues en producción que requieren rendimiento de H100 con una complejidad mínima -Equipos que priorizan la simplicidad de instalación (instalación con un solo pip install) |
SGLang | -Organizaciones que necesitan el máximo rendimiento absoluto (16,215 tok/s) -Clústeres de inferencia dedicados |
Resultados del benchmark de motores de inferencia
Medimos el rendimiento por lotes sin conexión a través de 10,000 operaciones de inferencia totales (1,000 prompts × 10 ejecuciones por motor) para garantizar la estabilidad estadística.
- Rendimiento: Tokens de salida generados por segundo en modo de inferencia por lotes. Mide la eficiencia con que cada motor utiliza la capacidad de cómputo de la H100.
Todos los motores se configuraron para su máximo rendimiento teórico: Llama 3.1 8B-Instruct, precisión bfloat16 y 0.8 de utilización de memoria de GPU en hardware H100 80GB.
Para entender cómo calculamos las tasas de rendimiento, consulta nuestra metodología de benchmark de inferencia.
Conclusiones clave
Nuestro enfoque minimiza las variables de confusión: mismo modelo, hardware, conjunto de datos, configuración de muestreo, límites de memoria y protocolo de calentamiento. Este aislamiento revela la verdadera contribución de la arquitectura de cada motor.
La brecha arquitectónica es del 29%: Incluso cuando vLLM está optimizado con los mismos kernels (FlashInfer) que SGLang, sigue estando significativamente rezagado respecto a los líderes. SGLang (16,215 tok/s) y LMDeploy (16,132 tok/s) mantienen una ventaja del 29% sobre vLLM completamente optimizado (12,553 tok/s). Esto indica que el cuello de botella ya no es el kernel matemático, sino la sobrecarga de orquestación interna del motor.
SGLang y LMDeploy están efectivamente empatados: la diferencia de rendimiento entre ellos es inferior al 0.6%, lo que se encuentra dentro del margen de error. Esto sugiere que tanto el enfoque "Python + Kernels Nativos" (SGLang) como el de "Motor C++ Puro" (LMDeploy) son estrategias igualmente válidas para alcanzar el máximo rendimiento en arquitecturas Hopper.
Zona segura de memoria de GPU al 80% de utilización: Los intentos de asignar un 95% de memoria de GPU causaron fallos inmediatos durante la compilación de CUDA Graph en todos los motores, a pesar de la capacidad de 80GB. La causa raíz se identificó como agotamiento de RAM del sistema durante la captura del grafo, no los límites de memoria de la GPU. Una fracción de 0.8 proporcionó el equilibrio óptimo entre estabilidad y tamaño de lote.
Comprendiendo la jerarquía de rendimiento
Las diferencias de rendimiento revelan una clara distinción entre las arquitecturas de los motores en la H100:
SGLang y LMDeploy: Estos motores alcanzan ~16,200 tok/s. SGLang lo logra mediante RadixAttention, un administrador de memoria especializado diseñado para patrones de servicio complejos. LMDeploy lo hace a través de TurboMind, un backend C++ personalizado que elimina completamente la sobrecarga de Python.
vLLM: Incluso con el backend FlashInfer habilitado, vLLM alcanza un pico de ~12,500 tok/s. Si bien esto es una mejora masiva sobre las configuraciones estándar, la brecha restante resalta el costo de la arquitectura flexible basada en plugins de vLLM (PagedAttention) frente a los diseños hiperespecializados de los líderes.
Diferencias en la filosofía arquitectónica: SGLang y LMDeploy codiseñan sus mecanismos de atención con suposiciones de kernel. vLLM mantiene una capa de compatibilidad más amplia que requiere que los algoritmos de atención funcionen con varios backends, lo que limita la profundidad de las optimizaciones específicas en hardware de última generación.
Optimización del patrón de acceso a memoria: La brecha del 29% sugiere que SGLang y LMDeploy optimizan la coalescencia de memoria, la localidad de caché y la planificación de lotes de manera más agresiva de lo que permite el planificador de vLLM, particularmente en cómo manejan el Acelerador de Memoria Tensorial (TMA) de la H100.
Metodología del benchmark
Entorno de prueba
Configuración del hardware:
- GPU: NVIDIA H100 80GB HBM3
- Sistema: instancia de nube RunPod
- Base Docker: runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
Versiones de software:
- CUDA: 12.8.1
- PyTorch: 2.8.0
- vLLM: 0.11.0 (FlashInfer habilitado)
- LMDeploy: 0.10.2
- SGLang: v0.2.3
Conjunto de datos y carga de trabajo
Origen: conjunto de datos ShareGPT_Vicuna_unfiltered de Hugging Face
Criterios de selección:
Por qué este conjunto de datos: ShareGPT contiene conversaciones reales entre usuarios y chatbots con una variación natural de longitud, representando con mayor precisión las cargas de trabajo de producción de chatbots que los benchmarks sintéticos.
Configuraciones de los motores
Todos los motores se configuraron para obtener el máximo rendimiento manteniendo la equidad:
Configuración de vLLM (Backend FlashInfer):
Configuración de LMDeploy:
Configuración de SGLang:
Procedimiento de medición
Protocolo estándar aplicado a todos los motores:
- Carga del modelo: Descargar e inicializar el modelo con precisión bfloat16.
- Fase de calentamiento: Procesar 20 prompts para activar la compilación JIT y estabilizar los relojes de la GPU.
- Ejecuciones del benchmark: Realizar 10 pasadas completas de todos los 1,000 prompts.
- Metodología de temporización:
- Conteo de tokens: Extraer los conteos reales de tokens de los formatos de salida específicos de cada motor.
- Cálculo del rendimiento: total_output_tokens / duración.
Rigor estadístico:
- 10,000 operaciones de inferencia totales (1,000 prompts × 10 ejecuciones por motor).
- ~1.5 millones de tokens generados por motor.
- Desviación estándar consistentemente <1% de la media en todos los motores.
Interpretación de los resultados
Lo que puedes concluir:
Para la inferencia por lotes sin conexión de Llama 3.1 8B en hardware H100, la eficiencia arquitectónica dicta el ganador. Incluso con los mejores kernels posibles (FlashInfer), vLLM no puede igualar el rendimiento de SGLang o LMDeploy. La brecha del 29% representa el costo de la orquestación en Python frente a la optimización nativa en C++.
La jerarquía de rendimiento se aplica a este escenario exacto: procesamiento por lotes de 1,000 prompts simultáneamente. SGLang y LMDeploy son opciones robustas que ofrecen ~45% más valor por hora de GPU que los despliegues estándar y ~29% más que los despliegues altamente optimizados de vLLM.
Lo que no puedes generalizar:
- Modelos diferentes: Resultados específicos para Llama 3.1 8B. Modelos más grandes (p.ej., 70B) o arquitecturas diferentes (p.ej., Mixtral, Qwen) mostrarán patrones de escalado diferentes.
- Hardware diferente: Estos rankings aplican a H100 80GB. En A100 o V100, la portabilidad de vLLM puede superar la especialización de SGLang.
- Métricas diferentes: Esto mide solo el rendimiento. El servicio en línea requiere TTFT y percentiles de latencia, donde los resultados difieren significativamente.
- Cargas de trabajo diferentes: Los prompts aleatorios minimizan los beneficios del almacenamiento en caché de prefijos. Los prompts del sistema repetidos o las conversaciones de varios turnos cambian drásticamente el panorama de rendimiento a favor de SGLang.
Comparación de la experiencia del desarrollador
Las cifras de rendimiento no capturan el panorama completo del despliegue. Cada motor ofrece flujos de trabajo de desarrollo distintos:
vLLM: Estándar de la industria por una buena razón
Simplicidad y amplia compatibilidad. Una sola instalación con pip install vllm admite más de 100 arquitecturas de modelos en hardware NVIDIA, AMD e Intel. Una comunidad masiva significa que Stack Overflow tiene tus respuestas. Servidor compatible con la API de OpenAI incluido.
- Elige vLLM para: Prototipado rápido, entornos de GPU heterogéneos, máxima cobertura de modelos o aprovechar el mayor ecosistema.
LMDeploy: Calidad de producción con mínima fricción
Instalación de una línea (pip install lmdeploy) ofrece el 99.5% del rendimiento máximo de la H100. El backend nativo en C++ significa cero sobrecarga de Python. Soporte de cuantización de primera clase (AWQ, GPTQ) para una mayor optimización. Sin infierno de dependencias.
- Elige LMDeploy para despliegues de producción que requieren el máximo rendimiento de la H100 sin sacrificar la simplicidad de instalación o la estabilidad.
SGLang: Techo de rendimiento con costo de complejidad
El rendimiento máximo absoluto (16,215 tok/s) tiene un precio: un esfuerzo significativo en la depuración de la instalación de FlashInfer. Requiere una versión específica de PyTorch. Incompatibilidades binarias con algunas ruedas precompiladas. RadixAttention brilla en cargas de trabajo conversacionales.
- Elige SGLang para: Clústeres de inferencia dedicados donde un equipo especializado pueda gestionar las dependencias y necesites hasta el último punto porcentual de rendimiento.
Desafíos de instalación e implementación
Una comparación justa requirió superar importantes obstáculos de ingeniería:
Desafío 1: Conflictos de dependencias de FlashInfer
Problema: Las ruedas de FlashInfer de SGLang esperan versiones específicas de PyTorch, pero los contenedores optimizados para H100 a menudo incluyen otras diferentes.
Solución:
Inversión de tiempo: 6 horas identificando versiones compatibles.
Conclusión clave: Las ruedas de ML precompiladas a menudo ocultan restricciones de versión que solo aparecen en tiempo de ejecución.
Desafío 2: Habilitar FlashInfer en vLLM
Problema: Las versiones estándar de vLLM a menudo carecen de soporte para FlashInfer o requieren una compleja compilación desde el código fuente.
Solución innovadora: Utilizamos la compilación vLLM 0.11.0 en PyTorch 2.8 Nightly. Esto permitió habilitar con éxito el soporte nativo de FlashInfer mediante pip install “vllm[flashinfer]==0.11.0”, evitando las barreras de compilación de versiones anteriores.
Impacto: Esto proporcionó la comparación más justa posible, confirmando que si bien los kernels ayudan, no resuelven el cuello de botella arquitectónico.
Desafío 3: Descubrimiento del punto óptimo de utilización de memoria
Problema: La recomendación estándar de 0.9 de utilización de memoria de GPU causó fallos std::bad_alloc.
Progresión de pruebas:
Descubrimiento: La captura del grafo CUDA asigna RAM temporal del sistema proporcional al uso de memoria de la GPU. Con 0.9 × 80GB = 72GB de asignación de GPU, la RAM del sistema se agota durante la compilación.
Límite práctico: 0.8 de utilización de GPU es la “zona segura” a pesar de la capacidad de hardware de 80GB.
Conclusión
Para la inferencia por lotes de Llama 3.1 8B en H100, la jerarquía de rendimiento tiene dos niveles claros: vLLM (optimizado con FlashInfer) proporciona una línea base sólida, mientras que las arquitecturas nativas en C++ de SGLang y LMDeploy desbloquean un 29% adicional en rendimiento.
SGLang (16,215 tok/s) y LMDeploy (16,132 tok/s) alcanzan un rendimiento casi idéntico, lo que sugiere que ambos motores saturan el ancho de banda de memoria de la H100. La mínima brecha entre ellos es ruido estadístico.
Para despliegues en producción: LMDeploy emerge como el ganador práctico, ofreciendo el 99.5% del rendimiento máximo de SGLang con una instalación trivial (pip install lmdeploy) frente a la compleja resolución de dependencias de SGLang.
vLLM con FlashInfer (12,553 tok/s) ofrece un punto intermedio convincente: rendimiento respetable manteniendo la compatibilidad total de hardware y la matriz de soporte de modelos más grande de la industria. Sin embargo, para clústeres dedicados de H100, dejar un 29% de rendimiento sobre la mesa es un costo elevado.
Para la estandarización en infraestructura heterogénea o experimentación rápida con modelos, vLLM sigue siendo la elección racional. Para implementaciones dedicadas de H100 donde el rendimiento es primordial, la combinación de rendimiento máximo y simplicidad de instalación de LMDeploy es inigualable.
Añadir como fuente preferidaPreguntas frecuentes
Un motor de inferencia de LLM es un software especializado que optimiza cómo los modelos de lenguaje grandes generan respuestas. Si bien puedes ejecutar modelos con PyTorch o TensorFlow básicos, los motores de inferencia añaden optimizaciones críticas como una gestión eficiente de la memoria, el procesamiento por lotes de múltiples solicitudes y optimizaciones de kernels de GPU. Estas mejoras pueden aumentar drásticamente el rendimiento (tokens generados por segundo) y reducir costos, ofreciendo potencialmente un rendimiento de 3 a 5x mejor en el mismo hardware.
La inferencia por lotes sin conexión procesa muchos prompts simultáneamente sin requisitos de tiempo real, piensa en analizar miles de documentos o generar embeddings para un conjunto de datos. El servicio en línea maneja solicitudes individuales de usuarios con requisitos estrictos de latencia, donde métricas como el Tiempo hasta el Primer Token (TTFT) importan más que el rendimiento bruto. El motor que gana en rendimiento por lotes puede no ser óptimo para chatbots interactivos, así que elige según tu patrón real de carga de trabajo
Cita esta investigación
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Sarı, Ekrem},
title = {{LLM Motores de Inferencia: vLLM vs LMDeploy vs SGLang}},
year = {2026},
month = apr,
howpublished = {\url{https://aimultiple.com/inference-engines}},
note = {AIMultiple. Recuperado el 15 de Abril de 2026}
}
Siguiente para leer
Top 10 Software de Seguridad para Endpoints
GPU Software para IA: CUDA vs. ROCm
Las 10 mejores soluciones PAM con alternativas gratuitas
Las 5 mejores herramientas de monitorización de bases de datos de código abierto
Mejores herramientas de monitoreo de rendimiento de bases de datos: Comparación de las 5 mejores plataformas
Las 25 mejores herramientas de control de versiones
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.