Moteurs d'inférence LLM : vLLM vs LMDeploy vs SGLang
Nous avons comparé les performances de trois moteurs d'inférence LLM de pointe sur H100 (NVIDIA) : vLLM, LMDeploy et SGLang. Chaque moteur a traité une charge de travail identique : 1 000 requêtes ShareGPT avec Llama 3.1 8B-Instruct afin d'isoler l'impact réel de leurs choix architecturaux et stratégies d'optimisation sur les performances.
Moteurs | Idéal pour |
|---|---|
vLLM | -Prototypage et expérimentation sur plus de 100 architectures de modèles -Environnements multi-GPU (NVIDIA, AMD, Intel) |
LMDeploy | -Déploiements en production nécessitant les performances du H100 avec une complexité minimale -Teams privilégie la simplicité d'installation (installation pip en une seule ligne) |
SGLang | -Organisations nécessitant un débit maximal absolu (16 215 tok/s) -Clusters d'inférence dédiés |
Résultats de référence des moteurs d'inférence
Nous avons mesuré le débit de traitement par lots hors ligne sur 10 000 opérations d'inférence totales (1 000 invites × 10 exécutions par moteur) pour garantir la stabilité statistique.
- Débit : nombre de jetons de sortie générés par seconde en mode d’inférence par lots. Mesure l’efficacité avec laquelle chaque moteur utilise les capacités de calcul du H100.
Tous les moteurs ont été configurés pour leurs performances théoriques maximales : Llama 3.1 8B-Instruct, précision bfloat16 et utilisation de la mémoire GPU de 0,8 sur le matériel H100 80 Go.
Pour comprendre comment nous avons calculé les débits, veuillez consulter notre méthodologie d'analyse comparative des données d'inférence.
Principales conclusions
Notre approche minimise les variables confondantes : modèle, matériel, jeu de données, configuration d’échantillonnage, limites de mémoire et protocole de préchauffage identiques. Cette isolation révèle la contribution réelle de l’architecture de chaque moteur.
L'écart architectural est de 29 % : même optimisé avec les mêmes noyaux (FlashInfer) que SGLang, vLLM reste nettement en retrait par rapport aux leaders. SGLang (16 215 tok/s) et LMDeploy (16 132 tok/s) conservent un avantage de 29 % sur vLLM entièrement optimisé (12 553 tok/s). Cela indique que le goulot d'étranglement n'est plus le noyau mathématique, mais la surcharge d'orchestration interne du moteur.
SGLang et LMDeploy offrent des performances quasi identiques : leur différence est inférieure à 0,6 %, ce qui reste dans la marge d’erreur. Cela suggère que les deux approches, « Python + Noyaux natifs » (SGLang) et « Moteur C++ pur » (LMDeploy), sont des stratégies tout aussi valables pour atteindre des performances optimales sur les architectures Hopper.
Zone de sécurité pour la mémoire GPU à 80 % d'utilisation : toute tentative d'allocation de 95 % de la mémoire GPU a provoqué des plantages immédiats lors de la compilation de graphes CUDA sur tous les moteurs, malgré une capacité de 80 Go. La cause première a été identifiée comme étant une saturation de la RAM système pendant la capture des graphes, et non une limitation de la mémoire GPU. Une fraction de 0,8 a permis d'obtenir le compromis optimal entre stabilité et taille des lots.
Comprendre la hiérarchie des performances
Les différences de débit révèlent une distinction claire entre les architectures des moteurs sur H100 :
SGLang et LMDeploy : ces moteurs atteignent environ 16 200 tok/s. SGLang y parvient grâce à RadixAttention , un gestionnaire de mémoire spécialisé conçu pour les modèles de service complexes. LMDeploy y parvient grâce à TurboMind , un backend C++ personnalisé qui élimine totalement la surcharge Python.
vLLM : Même avec le backend FlashInfer activé, vLLM atteint un débit maximal d'environ 12 500 tok/s. Bien qu'il s'agisse d'une amélioration considérable par rapport aux configurations standard, l'écart restant souligne le coût de l'architecture flexible et basée sur des plugins (PagedAttention) de vLLM par rapport aux conceptions hyper-spécialisées des leaders du marché.
Différences de philosophie architecturale : SGLang et LMDeploy conçoivent conjointement leurs mécanismes d’attention en fonction des hypothèses du noyau. vLLM maintient une couche de compatibilité plus large qui exige que les algorithmes d’attention fonctionnent avec divers backends, ce qui limite la profondeur des optimisations spécifiques sur du matériel de pointe.
Optimisation du modèle d'accès à la mémoire : l'écart de 29 % suggère que SGLang et LMDeploy optimisent la fusion de la mémoire, la localité du cache et la planification par lots de manière plus agressive que ne le permet le planificateur de vLLM, en particulier dans la façon dont ils gèrent l'accélérateur de mémoire Tensor (TMA) du H100.
Méthodologie de référence
Environnement de test
Configuration matérielle :
- GPU : NVIDIA H100 80 Go HBM3
- Système : instance cloud RunPod
- Docker de base : runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
Versions logicielles :
- CUDA : 12.8.1
- PyTorch : 2.8.0
- vLLM : 0.11.0 (FlashInfer activé)
- LMDeploy : 0.10.2
- SGLang : v0.2.3
Ensemble de données et charge de travail
Source : Jeu de données ShareGPT_Vicuna_unfiltered de Hugging Face
Critères de sélection :
Pourquoi ce jeu de données : ShareGPT contient de véritables conversations entre utilisateurs et chatbots avec des variations de longueur naturelles, représentant plus fidèlement les charges de travail des chatbots en production que les benchmarks synthétiques.
Configurations du moteur
Tous les moteurs ont été configurés pour des performances maximales tout en préservant l'équité :
Configuration vLLM (FlashInfer Backend) :
Configuration de LMDeploy :
Configuration SGLang :
procédure de mesure
Protocole standard appliqué à tous les moteurs :
- Chargement du modèle : Téléchargez et initialisez le modèle avec une précision bfloat16.
- Phase d'échauffement : Le processus 20 invite à déclencher la compilation JIT et à stabiliser les fréquences du GPU.
- Exécutions de test de performance : Exécuter 10 passes complètes des 1 000 invites.
- Méthodologie de chronométrage :
- Comptage des jetons : extraire le nombre réel de jetons à partir des formats de sortie spécifiques au moteur.
- Calcul du débit : nombre total de jetons de sortie / durée.
Rigueur statistique :
- 10 000 opérations d'inférence au total (1 000 invites × 10 exécutions par moteur).
- Environ 1,5 million de jetons générés par moteur.
- L'écart type est systématiquement inférieur à 1 % de la moyenne pour tous les moteurs.
Interprétation des résultats
Conclusion :
Pour l'inférence par lots hors ligne de Llama 3.1 8B sur le matériel H100, l'efficacité architecturale est déterminante. Même avec les meilleurs noyaux possibles (FlashInfer), vLLM ne peut égaler le débit de SGLang ou LMDeploy. L'écart de 29 % représente le coût de l'orchestration Python par rapport à l'optimisation native en C++.
La hiérarchie des performances s'applique précisément à ce scénario : le traitement par lots de 1 000 requêtes simultanément. SGLang et LMDeploy sont des solutions robustes qui offrent environ 45 % de valeur supplémentaire par heure de GPU par rapport aux déploiements standard et environ 29 % de plus que les déploiements vLLM hautement optimisés.
Ce que vous ne pouvez pas généraliser :
- Différents modèles : Résultats spécifiques au Llama 3.1 8B. Les modèles plus grands (par exemple, 70B) ou les architectures différentes (par exemple, Mixtral, Qwen) présenteront des modèles d’échelle différents.
- Matériel différent : ce classement s’applique au H100 80 Go. Sur A100 ou V100, la portabilité de vLLM peut compenser la spécialisation de SGLang.
- Métriques différentes : Celle-ci mesure uniquement le débit. La diffusion en ligne nécessite le TTFT et les percentiles de latence, pour lesquels les résultats diffèrent considérablement.
- Charges de travail variables : les invites aléatoires minimisent les avantages de la mise en cache des préfixes. Les invites système répétées ou les conversations à plusieurs tours modifient considérablement les performances en faveur de SGLang.
Comparaison de l'expérience des développeurs
Les chiffres de performance ne reflètent pas l'ensemble du déploiement. Chaque moteur propose des flux de travail de développement distincts :
vLLM : La norme industrielle, et ce à juste titre.
Simplicité et large compatibilité. Une seule installation pip de vllm prend en charge plus de 100 architectures matérielles compatibles avec les normes NVIDIA, AMD et Intel. Grâce à une vaste communauté, Stack Overflow répond à toutes vos questions. Serveur API compatible OpenAI inclus.
- Choisissez vLLM pour : le prototypage rapide, les environnements GPU hétérogènes, une couverture de modèle maximale ou l'exploitation du plus vaste écosystème.
LMDeploy : Qualité professionnelle avec un minimum de friction
L'installation en une seule ligne (pip install lmdeploy) offre 99,5 % des performances maximales du H100. Le backend C++ natif élimine toute surcharge Python. Prise en charge de la quantification de premier ordre (AWQ, GPTQ) pour une optimisation accrue. Aucune dépendance complexe.
- Choisissez LMDeploy pour les déploiements en production qui exigent des performances H100 maximales sans sacrifier la simplicité d'installation ni la stabilité.
SGLang : Plafond de performance lié à la complexité
Le débit maximal absolu (16 215 tok/s) a un prix : un effort considérable de débogage de l’installation de FlashInfer. Nécessite une version spécifique de PyTorch. Incompatibilités binaires avec certains packages précompilés. RadixAttention excelle dans les charges de travail conversationnelles.
- Choisissez SGLang pour : les clusters d’inférence dédiés où une équipe spécialisée peut gérer les dépendances et où vous avez besoin de chaque point de pourcentage de débit.
défis liés à l'installation et au déploiement
Une comparaison équitable a nécessité de surmonter d'importants obstacles techniques :
Défi 1 : Conflits de dépendances FlashInfer
Problème : les roues FlashInfer de SGLang attendent des versions spécifiques de PyTorch, mais les conteneurs optimisés pour H100 en utilisent souvent des différentes.
Résolution:
Investissement en temps : 6 heures pour identifier les versions compatibles.
Conclusion : les roues ML précompilées masquent souvent des contraintes de version qui n’apparaissent qu’à l’exécution.
Défi 2 : Activation de FlashInfer dans vLLM
Problème : les versions standard de vLLM ne prennent souvent pas en charge FlashInfer ou nécessitent une compilation source complexe.
Percée : Nous avons utilisé la version 0.11.0 de vLLM sur PyTorch 2.8 Nightly. Cela a permis d’activer la prise en charge native de FlashInfer via la commande `pip install “vllm[flashinfer]==0.11.0”`, contournant ainsi les problèmes de compilation des versions antérieures.
Impact : Cela a permis une comparaison aussi équitable que possible, confirmant que si les noyaux sont utiles, ils ne résolvent pas le goulot d'étranglement architectural.
Défi 3 : Découverte du point optimal d’utilisation de la mémoire
Problème : La recommandation standard d'utilisation de la mémoire GPU de 0,9 a provoqué std::bad_alloc plantages.
Progression des tests :
Constat : la capture de graphes CUDA alloue de la mémoire vive système temporaire proportionnellement à l’utilisation de la mémoire du GPU. Avec une allocation de 72 Go (0,9 × 80 Go), la mémoire vive système est saturée pendant la compilation.
Limite pratique : une utilisation du GPU de 0,8 constitue la « zone de sécurité » malgré une capacité matérielle de 80 Go.
Conclusion
Pour l'inférence par lots Llama 3.1 8B sur H100, la hiérarchie des performances comporte deux niveaux distincts : vLLM (optimisé avec FlashInfer) fournit une base solide, tandis que les architectures natives C++ de SGLang et LMDeploy permettent un débit supplémentaire de 29 %.
SGLang (16 215 tok/s) et LMDeploy (16 132 tok/s) atteignent des débits quasi identiques, ce qui suggère que les deux moteurs saturent la bande passante mémoire du H100. L'écart minime entre eux est dû à des facteurs statistiques.
Pour les déploiements en production : LMDeploy s'impose comme le grand gagnant, offrant 99,5 % du débit maximal de SGLang avec une installation triviale (pip install lmdeploy) par rapport à la résolution complexe des dépendances de SGLang.
La technologie vLLM avec FlashInfer (12 553 tok/s) offre un compromis intéressant : des performances respectables tout en conservant une compatibilité matérielle totale et la plus large matrice de modèles pris en charge du marché. Cependant, pour les clusters H100 dédiés, une perte de 29 % de performances représente un coût important.
Pour la standardisation au sein d'infrastructures hétérogènes ou l'expérimentation rapide de modèles, vLLM demeure le choix le plus judicieux. Pour les déploiements H100 dédiés où le débit est primordial, la combinaison de performances optimales et de simplicité d'installation offerte par LMDeploy est inégalée.
FAQ
Un moteur d'inférence LLM est un logiciel spécialisé qui optimise la génération des réponses par les grands modèles de langage. Bien qu'il soit possible d'exécuter des modèles avec PyTorch ou TensorFlow, les moteurs d'inférence apportent des optimisations essentielles telles que la gestion efficace de la mémoire, le regroupement de plusieurs requêtes et l'optimisation du noyau GPU. Ces améliorations peuvent considérablement augmenter le débit (nombre de jetons générés par seconde) et réduire les coûts, offrant potentiellement des performances 3 à 5 fois supérieures sur le même matériel.
Le traitement par lots hors ligne traite simultanément de nombreuses requêtes sans contraintes de temps réel, par exemple pour analyser des milliers de documents ou générer des représentations vectorielles pour un jeu de données. Le traitement en ligne gère les requêtes individuelles des utilisateurs avec des exigences strictes de latence, où des indicateurs comme le temps d'obtention du premier jeton (TTFT) sont plus importants que le débit brut. Le moteur le plus performant en termes de débit par lots n'est pas forcément optimal pour les chatbots interactifs ; choisissez donc en fonction de votre charge de travail réelle.
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires.