LLM Motores de Inferencia: vLLM vs LMDeploy vs SGLang
Realizamos pruebas de referencia a 3 motores de inferencia LLM líderes en hardware NVIDIA H100: vLLM, LMDeploy y SGLang. Cada motor procesó cargas de trabajo idénticas: 1,000 prompts de ShareGPT utilizando 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 en más de 100 arquitecturas de modelos -Ambientes multi GPU (NVIDIA, AMD, Intel) |
LMDeploy | -Despliegues de producción que requieren rendimiento H100 con complejidad mínima -Equipos que priorizan la simplicidad de instalación (instalación pip de una línea) |
SGLang | -Organizaciones que necesitan el máximo rendimiento absoluto (16,215 tok/s) -Clústeres de inferencia dedicados |
Resultados de las pruebas de referencia de motores de inferencia
Medimos el rendimiento por lotes fuera de línea en 10,000 operaciones de inferencia totales (1,000 prompts × 10 ejecuciones por motor) para garantizar estabilidad estadística.
- Rendimiento: Tokens de salida generados por segundo en modo de inferencia por lotes. Mide qué tan eficientemente cada motor utiliza las capacidades de cálculo del H100.
Todos los motores se configuraron para su rendimiento teórico máximo: Llama 3.1 8B-Instruct, precisión bfloat16 y 0.8 de utilización de memoria GPU en hardware H100 de 80GB.
Para entender cómo calculamos las tasas de rendimiento, consulte nuestra metodología de prueba de referencia de inferencia.
Hallazgos clave
Nuestro enfoque minimiza las variables de confusión: modelo, hardware, conjunto de datos, configuración de muestreo, límites de memoria y protocolo de calentamiento idénticos. Este aislamiento revela lo que realmente contribuye la arquitectura de cada motor.
La brecha arquitectónica es del 29%: Incluso cuando vLLM se optimiza con los mismos kernels exactos (FlashInfer) que SGLang, aún se queda significativamente atrás de los líderes. SGLang (16,215 tok/s) y LMDeploy (16,132 tok/s) mantienen una ventaja del 29% sobre el vLLM totalmente 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 menor al 0.6%, lo que cae dentro del margen de error. Esto sugiere que tanto el enfoque "Python + Kernels Nativos" (SGLang) como el enfoque "Motor Puro en C++" (LMDeploy) son estrategias igualmente válidas para lograr un rendimiento máximo en arquitecturas Hopper.
Zona "segura" de memoria GPU al 80% de utilización: Los intentos de asignar el 95% de la memoria GPU causaron caídas inmediatas 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 el agotamiento de la memoria RAM del sistema durante la captura del gráfico, no los límites de memoria GPU. Una fracción de 0.8 proporcionó el equilibrio óptimo entre estabilidad y tamaño de lote.
Comprensión de la jerarquía de rendimiento
Las diferencias de rendimiento revelan una distinción clara entre las arquitecturas de los motores en H100:
SGLang y LMDeploy: Estos motores alcanzan ~16,200 tok/s. SGLang logra esto mediante RadixAttention, un administrador de memoria especializado diseñado para patrones de servicio complejos. LMDeploy logra esto mediante TurboMind, un backend personalizado en C++ que elimina por completo la sobrecarga de Python.
vLLM: Incluso con el backend FlashInfer habilitado, vLLM alcanza un máximo 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 y basada en plugins de vLLM (PagedAttention) frente a los diseños hiperespecializados de los líderes.
Diferencias en la filosofía de arquitectura: SGLang y LMDeploy co-diseñ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 optimizaciones específicas en hardware de vanguardia.
Optimización del patrón de acceso a memoria: La brecha del 29% sugiere que SGLang y LMDeploy optimizan el agrupamiento de memoria, la localidad de caché y la programación de lotes de manera más agresiva de lo que permite el programador de vLLM, particularmente en cómo manejan el Acelerador de Memoria Tensor (TMA) del H100.
Metodología de prueba de referencia
Entorno de prueba
Configuración de hardware:
- GPU: NVIDIA H100 80GB HBM3
- Sistema: Instancia en la nube RunPod
- Base de 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
Fuente: 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 variación natural de longitud, representando con mayor precisión las cargas de trabajo de chatbots de producción que las pruebas de referencia sintéticas.
Configuraciones de motor
Todos los motores se configuraron para 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 GPU.
- Ejecuciones de prueba de referencia: Ejecutar 10 pasadas completas de los 1,000 prompts.
- Metodología de temporización:
- Conteo de tokens: Extraer conteos reales de tokens de los formatos de salida específicos del motor.
- Cálculo del rendimiento: total_output_tokens / duration.
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 fuera de línea de Llama 3.1 8B en hardware H100, la eficiencia arquitectónica dicta al 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 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 (por ejemplo, 70B) o arquitecturas diferentes (por ejemplo, Mixtral, Qwen) mostrarán patrones de escalado diferentes.
- Hardware diferente: Estas clasificaciones se aplican a H100 80GB. En A100 o V100, la portabilidad de vLLM puede pesar más que 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 de la caché de prefijos. Los prompts del sistema repetidos o las conversaciones de varias vueltas cambian drásticamente el panorama del rendimiento a favor de SGLang.
Comparación de la experiencia del desarrollador
Los números de rendimiento no capturan el panorama completo del despliegue. Cada motor ofrece flujos de trabajo de desarrollador distintos:
vLLM: Estándar de la industria por una buena razón
La simplicidad se encuentra con la amplia compatibilidad. Una sola instalación pip vllm soporta más de 100 arquitecturas de modelos en hardware NVIDIA, AMD e Intel. Una comunidad masiva significa que Stack Overflow tiene tus respuestas. Servidor API compatible con OpenAI incluido.
- Elige vLLM para: Prototipado rápido, entornos GPU heterogéneos, cobertura máxima de modelos o aprovechar el ecosistema más grande.
LMDeploy: Listo para producción con mínima fricción
Una instalación de una línea (pip install lmdeploy) entrega el 99.5% del rendimiento máximo H100. El backend nativo en C++ significa cero sobrecarga de Python. Soporte de cuantización de primera clase (AWQ, GPTQ) para mayor optimización. Sin infierno de dependencias.
- Elige LMDeploy para despliegues de producción que requieren máximo rendimiento 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) viene con un precio: 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 pre-construidas. RadixAttention brilla en cargas de trabajo conversacionales.
- Elige SGLang para: Clústeres de inferencia dedicados donde un equipo especializado puede gestionar dependencias y necesitas cada último punto porcentual de rendimiento.
Añadir como fuente preferidaDesafíos de instalación y despliegue
La comparación justa requirió superar obstáculos de ingeniería significativos:
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 vienen con versiones diferentes.
Resolución:
Inversión de tiempo: 6 horas identificando versiones compatibles.
Conclusión: Las ruedas de ML precompiladas a menudo ocultan restricciones de versión que solo surgen 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 compilación compleja del código fuente.
Avance: Utilizamos la compilación vLLM 0.11.0 en PyTorch 2.8 Nightly. Esto habilitó 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, aunque 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 GPU causó caídas std::bad_alloc.
Progresión de pruebas:
Descubrimiento: La captura de CUDA Graph asigna memoria RAM del sistema temporal proporcional al uso de memoria del GPU. Con 0.9 × 80GB = 72GB de asignación GPU, la memoria RAM del sistema se agota durante la compilación.
Límite práctico: 0.8 de utilización 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 base sólida, mientras que las arquitecturas nativas en C++ de SGLang y LMDeploy desbloquean un adicional 29% enrendimiento.
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 del H100. La brecha mínima entre ellos es ruido estadístico.
Para despliegues de producción: LMDeploy surge como el ganador práctico, entregando el 99.5% del rendimiento máximo de SGLang con una instalación trivial (pip install lmdeploy) frente a la resolución compleja de dependencias de SGLang.
vLLM con FlashInfer (12,553 tok/s) ofrece un punto medio convincente: rendimiento respetable mientras mantiene la compatibilidad total con el hardware y la matriz de soporte de modelos más grande de la industria. Sin embargo, para clústeres dedicados H100, dejar un 29% de rendimiento sobre la mesa es un costo alto.
Para la estandarización en infraestructura heterogénea o experimentación rápida de modelos, vLLM sigue siendo la elección racional. Para despliegues dedicados H100 donde el rendimiento es primordial, la combinación de rendimiento máximo y simplicidad de instalación de LMDeploy es inigualable.
Preguntas frecuentes
Un motor de inferencia LLM es un software especializado que optimiza cómo los modelos de lenguaje grandes generan respuestas. Aunque puedes ejecutar modelos con PyTorch o TensorFlow básicos, los motores de inferencia agregan optimizaciones críticas como gestión eficiente de memoria, agrupación de múltiples solicitudes y optimizaciones de kernel GPU. Estas mejoras pueden aumentar drásticamente el rendimiento (tokens generados por segundo) y reducir costos, potencialmente entregando un rendimiento 3-5 veces mejor en el mismo hardware.
La inferencia por lotes fuera de línea 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 Time To First 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 de carga de trabajo real
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}
}
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.