Motores de inferencia LLM: vLLM vs LMDemploy vs SGLang
Realizamos pruebas comparativas de 3 motores de inferencia LLM líderes en NVIDIA H100: vLLM, LMDeploy y SGLang. Cada motor procesó cargas de trabajo idénticas: 1000 solicitudes 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 | Lo mejor para |
|---|---|
vLLM | -Prototipado y experimentación en más de 100 arquitecturas de modelos. -Entornos multi-GPU (NVIDIA, AMD, Intel) |
LMDeploy | -Implementaciones en producción que requieren rendimiento H100 con mínima complejidad. -Equipos que priorizan la simplicidad de la instalación (instalación con pip en una sola línea) |
SGLang | -Organizaciones que necesitan el máximo rendimiento absoluto (16.215 tok/s) -Clústeres de inferencia dedicados |
Resultados de la evaluación comparativa de los motores de inferencia
Medimos el rendimiento de procesamiento por lotes fuera de línea en un total de 10 000 operaciones de inferencia (1000 solicitudes × 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 la que cada motor utiliza las capacidades de cómputo del H100.
Todos los motores se configuraron para obtener su máximo rendimiento teórico: Llama 3.1 8B-Instruct, precisión bfloat16 y utilización de memoria GPU de 0,8 en hardware H100 de 80 GB.
Para comprender cómo calculamos las tasas de procesamiento, consulte nuestra metodología de evaluación comparativa de inferencia.
Principales conclusiones
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 la verdadera contribución de la arquitectura de cada motor.
La brecha arquitectónica es del 29%: incluso cuando vLLM se optimiza con los mismos núcleos (FlashInfer) que SGLang, sigue estando muy por detrás de los líderes. SGLang (16 215 tok/s) y LMDeploy (16 132 tok/s) mantienen una ventaja del 29% sobre vLLM totalmente optimizado (12 553 tok/s). Esto indica que el cuello de botella ya no reside en el núcleo matemático, sino en la sobrecarga de orquestación interna del motor.
SGLang y LMDeploy ofrecen un rendimiento prácticamente idéntico: la diferencia entre ambos es inferior al 0,6 %, lo que se encuentra dentro del margen de error. Esto sugiere que tanto el enfoque de «Python + Núcleos Nativos» (SGLang) como el de «Motor C++ Puro» (LMDeploy) son estrategias igualmente válidas para lograr el máximo rendimiento en arquitecturas Hopper.
Zona segura de memoria de GPU con un 80 % de utilización: Los intentos de asignar el 95 % de la memoria de GPU provocaron fallos inmediatos durante la compilación de CUDA Graph en todos los motores, a pesar de la capacidad de 80 GB. La causa principal se identificó como el agotamiento de la RAM del sistema durante la captura del gráfico, no como límites de la memoria de la GPU. Una fracción de 0,8 proporcionó el equilibrio óptimo entre estabilidad y tamaño del lote.
Comprender la jerarquía de desempeño
Las diferencias en el rendimiento revelan una clara distinción entre las arquitecturas de los motores en H100:
SGLang y LMDeploy: Estos motores alcanzan aproximadamente 16 200 tokens por segundo. SGLang lo logra mediante RadixAttention , un gestor de memoria especializado diseñado para patrones de servicio complejos. LMDeploy lo logra 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 pico de aproximadamente 12 500 tokens/s. Si bien esto representa una mejora considerable con respecto a las configuraciones estándar, la diferencia restante pone de manifiesto el coste de la arquitectura flexible basada en complementos de vLLM (PagedAttention) frente a los diseños hiperespecializados de los líderes del mercado.
Diferencias en la filosofía de la arquitectura: SGLang y LMDeploy diseñan conjuntamente sus mecanismos de atención basándose en supuestos del kernel. vLLM mantiene una capa de compatibilidad más amplia que requiere que los algoritmos de atención funcionen con diversos 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 la memoria: la diferencia del 29 % sugiere que SGLang y LMDeploy optimizan la coalescencia de memoria, la localidad de caché y la programación por lotes de forma más agresiva de lo que permite el planificador de vLLM, en particular en la forma en que manejan el acelerador de memoria tensorial (TMA) del H100.
Metodología de evaluación comparativa
Entorno de prueba
Configuración del hardware:
- GPU: NVIDIA H100 80GB HBM3
- Sistema: instancia de nube RunPod
- Docker base: 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 variaciones de duración naturales, lo que representa con mayor precisión las cargas de trabajo de los chatbots en producción que los conjuntos de datos de referencia sintéticos.
Configuraciones del motor
Todos los motores se configuraron para obtener el máximo rendimiento manteniendo la equidad:
Configuración de vLLM (backend de FlashInfer):
Configuración de LMDemploy:
Configuración de SGLang:
Procedimiento de medición
Protocolo estándar aplicado a todos los motores:
- Carga del modelo: Descargue e inicialice el modelo con precisión bfloat16.
- Fase de calentamiento: Procesar 20 solicitudes para activar la compilación JIT y estabilizar la frecuencia de reloj de la GPU.
- Pruebas de rendimiento: Ejecutar 10 pasadas completas de las 1000 indicaciones.
- Metodología de cronometraje:
- Conteo de tokens: Extraiga el recuento real de tokens de los formatos de salida específicos del motor.
- Cálculo del rendimiento: tokens_de_salida_totales / duración.
Rigor estadístico:
- 10.000 operaciones de inferencia en total (1.000 solicitudes × 10 ejecuciones por motor).
- Se generan aproximadamente 1,5 millones de tokens por motor.
- La desviación estándar fue consistentemente inferior al 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 determina el ganador. Incluso con los mejores kernels posibles (FlashInfer), vLLM no puede igualar el rendimiento de SGLang o LMDeploy. La diferencia 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 específico: procesamiento por lotes de 1000 solicitudes simultáneamente. SGLang y LMDeploy son opciones robustas que ofrecen aproximadamente un 45 % más de valor por hora de GPU que las implementaciones estándar y un 29 % más que las implementaciones vLLM altamente optimizadas.
Lo que no se puede generalizar:
- Diferentes modelos: Resultados específicos para Llama 3.1 8B. Los modelos más grandes (por ejemplo, 70B) o las arquitecturas diferentes (por ejemplo, Mixtral, Qwen) mostrarán diferentes patrones de escalado.
- Hardware diferente: Estas clasificaciones se aplican al H100 de 80 GB. En el A100 o el V100, la portabilidad de vLLM puede ser más importante que la especialización de SGLang.
- Métricas diferentes: Esta solo mide el rendimiento. El servicio en línea requiere percentiles de TTFT y latencia, donde los resultados difieren significativamente.
- Diferentes cargas de trabajo: Las indicaciones aleatorias minimizan los beneficios del almacenamiento en caché de prefijos. Las indicaciones repetidas del sistema o las conversaciones de varios turnos cambian drásticamente el panorama del rendimiento a favor de SGLang.
Comparación de la experiencia del desarrollador
Las cifras de rendimiento no reflejan la imagen completa de la implementación. Cada motor ofrece flujos de trabajo de desarrollo distintos:
vLLM: Un estándar de la industria por una buena razón.
La simplicidad se une a una amplia compatibilidad. Con una sola instalación de pip, vllm admite más de 100 arquitecturas de modelos en hardware NVIDIA, AMD y Intel. Gracias a una gran comunidad, Stack Overflow tiene las respuestas a tus preguntas. Incluye un servidor API compatible con OpenAI.
- Elija vLLM para: Prototipado rápido, entornos GPU heterogéneos, máxima cobertura de modelos o para aprovechar el ecosistema más grande.
LMDemploy: Calidad de producción con mínima fricción
La instalación con una sola línea (pip install lmdeploy) ofrece el 99,5 % del rendimiento máximo de H100. El backend nativo en C++ elimina la sobrecarga de Python. Soporte de cuantización de primera clase (AWQ, GPTQ) para una mayor optimización. Sin problemas de dependencias.
- Elija LMDeploy para implementaciones en producción que requieran el máximo rendimiento de H100 sin sacrificar la simplicidad de la instalación ni la estabilidad.
SGLang: Límite de rendimiento con coste de complejidad
El rendimiento máximo absoluto (16 215 tok/s) tiene un precio: requiere un esfuerzo considerable para depurar la instalación de FlashInfer. Requiere una versión específica de PyTorch. Presenta incompatibilidades binarias con algunos paquetes precompilados. RadixAttention destaca en cargas de trabajo conversacionales.
- Elija SGLang para: Clústeres de inferencia dedicados donde un equipo especializado puede gestionar las dependencias y donde necesita hasta el último punto porcentual de rendimiento.
Desafíos de instalación y despliegue
Para realizar una comparación justa, fue necesario superar importantes obstáculos de ingeniería:
Desafío 1: Conflictos de dependencias de FlashInfer
Problema: Las ruedas FlashInfer de SGLang esperan versiones específicas de PyTorch, pero los contenedores optimizados para H100 a menudo incluyen versiones diferentes.
Resolución:
Tiempo invertido: 6 horas para identificar versiones compatibles.
Conclusión: Las bibliotecas de aprendizaje automático precompiladas a menudo ocultan restricciones de versión que solo se hacen evidentes 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 compilación de código fuente compleja.
Avance significativo: Utilizamos la compilación vLLM 0.11.0 en PyTorch 2.8 Nightly. Esto permitió habilitar con éxito la compatibilidad nativa con 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 núcleos ayudan, no resuelven el cuello de botella arquitectónico.
Desafío 3: Descubrimiento del punto óptimo de utilización de la memoria
Problema: La recomendación estándar de 0,9 de utilización de memoria de GPU provocó std::bad_alloc fallos.
Progreso de las pruebas:
Descubrimiento: La captura de gráficos CUDA asigna memoria RAM temporal del sistema proporcional al uso de memoria de la GPU. Con una asignación de GPU de 0,9 × 80 GB = 72 GB, la memoria RAM del sistema se agota durante la compilación.
Límite práctico: una utilización de la GPU del 0,8 % es la "zona segura" a pesar de una capacidad de hardware de 80 GB.
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 de C++ de SGLang y LMDeploy desbloquean un 29 % adicional en el 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 la memoria H100. La mínima diferencia entre ellos se debe al ruido estadístico.
Para implementaciones 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 una solución intermedia atractiva: un rendimiento respetable manteniendo la compatibilidad total con el hardware y la matriz de compatibilidad de modelos más amplia del sector. Sin embargo, para clústeres H100 dedicados, renunciar a un 29 % de rendimiento supone un coste elevado.
Para la estandarización en infraestructuras heterogéneas o la experimentación rápida con modelos, vLLM sigue siendo la opción más lógica. Para implementaciones dedicadas de H100, donde el rendimiento es fundamental, la combinación de máximo rendimiento y sencillez de instalación de LMDeploy es inigualable.
Preguntas frecuentes
Un motor de inferencia LLM es un software especializado que optimiza la forma en que los modelos de lenguaje de gran tamaño generan respuestas. Si bien es posible ejecutar modelos con PyTorch o TensorFlow básicos, los motores de inferencia incorporan optimizaciones cruciales, como una gestión eficiente de la memoria, el procesamiento por lotes de múltiples solicitudes y optimizaciones del kernel de la GPU. Estas mejoras pueden aumentar drásticamente el rendimiento (tokens generados por segundo) y reducir los costos, ofreciendo potencialmente un rendimiento entre 3 y 5 veces superior en el mismo hardware.
El procesamiento por lotes sin conexión procesa muchas solicitudes simultáneamente sin requisitos de tiempo real; por ejemplo, al analizar miles de documentos o generar incrustaciones para un conjunto de datos. El procesamiento en línea gestiona las solicitudes individuales de los usuarios con estrictos requisitos de latencia, donde métricas como el tiempo hasta el primer token (TTFT) son más importantes que el rendimiento bruto. El motor que mejor rendimiento ofrece en el procesamiento por lotes puede no ser el óptimo para los chatbots interactivos, así que elija en función de su patrón de carga de trabajo real.
Siguiente para leer
Comparativa de plataformas de agentes de IA: Agentes gestionados por Claude frente a Vertex Agent Engine (Google)
Las 15 mejores herramientas de optimización de motores de respuesta
Optimización de motores de respuesta (AEO): consejos y mejores prácticas
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios.