LLM Moteurs d'inférence: vLLM vs LMDeploy vs SGLang
Nous avons évalué 3 moteurs d'inférence LLM de premier plan sur du matériel NVIDIA H100 : vLLM, LMDeploy et SGLang. Chaque moteur a traité des charges de travail identiques : 1 000 invites ShareGPT utilisant Llama 3.1 8B-Instruct pour isoler l'impact réel des choix architecturaux et des 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 H100 avec une complexité minimale -Équipes privilégiant la simplicité d'installation (installation pip en une ligne) |
SGLang | -Organisations ayant besoin d'un débit absolu maximal (16 215 tok/s) -Clusters d'inférence dédiés |
Résultats du benchmark des moteurs d'inférence
Nous avons mesuré le débit par lots hors ligne sur 10 000 opérations d'inférence au total (1 000 invites × 10 exécutions par moteur) pour assurer la stabilité statistique.
- Debit : 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 à 0,8 sur du matériel H100 80 Go.
Pour comprendre comment nous avons calculé les taux de débit, veuillez consulter notre méthodologie de benchmark d'inférence.
Principales conclusions
Notre approche minimise les variables de confusion : modèle, matériel, jeu de données, configuration d'échantillonnage, limites de mémoire et protocole de mise en chauffe identiques. Cette isolation révèle ce que l'architecture de chaque moteur contribue réellement.
L'écart architectural est de 29 % : Même lorsque vLLM est optimisé avec exactement les mêmes noyaux (FlashInfer) que SGLang, il reste significativement derrière les leaders. SGLang (16 215 tok/s) et LMDeploy (16 132 tok/s) maintiennent un avantage de 29 % par rapport au 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 sont pratiquement à égalité : la différence de performance entre eux est inférieure à 0,6 %, ce qui se situe dans la marge d'erreur. Cela suggère que l'approche « Python + Noyaux natifs » (SGLang) et l'approche « Moteur C++ pur » (LMDeploy) sont des stratégies également valables pour atteindre des performances de pointe sur les architectures Hopper.
« Zone sûre » de mémoire GPU à 80 % d'utilisation : Les tentatives d'allocation de 95 % de mémoire GPU ont provoqué des plantages immédiats lors de la compilation des graphiques CUDA sur tous les moteurs, malgré la capacité de 80 Go. La cause racine a été identifiée comme étant l'épuisement de la RAM système lors de la capture du graphique, et non les limites de mémoire GPU. Une fraction de 0,8 a offert le meilleur équilibre entre stabilité et taille de lot.
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 & 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 des modèles de service complexes. LMDeploy y parvient grâce à TurboMind, un backend C++ personnalisé qui élimine entièrement la surcharge Python.
vLLM : Même avec le backend FlashInfer activé, vLLM atteint un pic d'environ 12 500 tok/s. Bien que ce soit une amélioration massive par rapport aux configurations standard, l'écart restant met en évidence le coût de l'architecture flexible et basée sur des plugins de vLLM (PagedAttention) par rapport aux conceptions hyper-spécialisées des leaders.
Différences de philosophie architecturale : SGLang et LMDeploy co-conçoivent leurs mécanismes d'attention avec des hypothèses de noyau. vLLM maintient une couche de compatibilité plus large qui nécessite que les algorithmes d'attention fonctionnent avec divers backends, ce qui limite la profondeur des optimisations spécifiques sur le 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 le regroupement de la mémoire, la localité du cache et la planification des lots plus agressivement que ce que permet le planificateur de vLLM, en particulier dans la façon dont ils gèrent l'accélérateur de mémoire tensorielle (TMA) du H100.
Méthodologie du benchmark
Environnement de test
Configuration matérielle :
- GPU : NVIDIA H100 80 Go HBM3
- Système : Instance cloud RunPod
- Base Docker : 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
Jeu 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 vraies conversations utilisateur-chatbot avec une variation naturelle de la longueur, proxy plus précisément les charges de travail de chatbot en production que les benchmarks synthétiques.
Configurations des moteurs
Tous les moteurs ont été configurés pour des performances maximales tout en maintenant l'équité :
Configuration vLLM (Backend FlashInfer) :
Configuration LMDeploy :
Configuration SGLang :
Procédure de mesure
Protocole standard appliqué à tous les moteurs :
- Chargement du modèle : Télécharger et initialiser le modèle avec une précision bfloat16.
- Phase de mise en chauffe : Traiter 20 invites pour déclencher la compilation JIT et stabiliser les horloges GPU.
- Exécutions du benchmark : Exécuter 10 passages complets de toutes les 1 000 invites.
- Méthodologie de chronométrage :
- Comptage des jetons : Extraire les comptes de jetons réels à partir des formats de sortie spécifiques au moteur.
- Calcul du débit : total_output_tokens / 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.
- Écart-type constamment <1 % de la moyenne sur tous les moteurs.
Interprétation des résultats
Ce que vous pouvez conclure :
Pour l'inférence par lots hors ligne de Llama 3.1 8B sur du matériel H100, l'efficacité architecturale dicte le gagnant. Même avec les meilleurs noyaux possibles (FlashInfer), vLLM ne peut pas é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 C++.
La hiérarchie des performances s'applique à ce scénario exact : traitement par lots de 1 000 invites simultanément. SGLang et LMDeploy sont des choix robustes qui offrent environ 45 % de valeur supplémentaire par heure 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 à 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 de mise à l'échelle différents.
- Matériel différent : Ces classements s'appliquent au H100 80 Go. Sur A100 ou V100, la portabilité de vLLM peut l'emporter sur la spécialisation de SGLang.
- Métriques différentes : Cela mesure uniquement le débit. Le service en ligne nécessite TTFT et percentiles de latence, où les résultats diffèrent considérablement.
- Charges de travail différentes : 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 multi-tours déplacent considérablement le paysage des performances en faveur de SGLang.
Comparaison de l'expérience développeur
Les chiffres de performance ne capturent pas toute la image du déploiement. Chaque moteur offre des flux de travail développeurs distincts :
vLLM : Standard de l'industrie pour une bonne raison
La simplicité rencontre la compatibilité étendue. Une seule installation pip vllm prend en charge plus de 100 architectures de modèles sur du matériel NVIDIA, AMD et Intel. Une communauté massive signifie que Stack Overflow a vos réponses. Serveur API compatible OpenAI inclus.
- Choisissez vLLM pour : Prototypage rapide, environnements GPU hétérogènes, couverture maximale des modèles ou exploitation du plus grand écosystème.
LMDeploy : Niveau production avec une friction minimale
Une installation en une ligne (pip install lmdeploy) offre 99,5 % des performances de pointe H100. Le backend C++ natif signifie zéro surcharge Python. Support de premier plan de la quantification (AWQ, GPTQ) pour une optimisation supplémentaire. Pas d'enfer de dépendance.
- Choisissez LMDeploy pour des déploiements en production qui nécessitent des performances H100 maximales sans sacrifier la simplicité d'installation ou la stabilité.
SGLang : Plafond de performance avec coût de complexité
Le débit absolu maximal (16 215 tok/s) a un prix : un effort considérable dans le débogage de l'installation de FlashInfer. Nécessite une version spécifique de PyTorch. Incompatibilités binaires avec certaines roues préconstruites. RadixAttention brille sur les charges de travail conversationnelles.
- Choisissez SGLang pour : 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 dernier pourcentage de débit.
Ajouter comme source préféréeDéfis d'installation et de déploiement
Une comparaison équitable a nécessité de surmonter des obstacles d'ingénierie importants :
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 livrent souvent d'autres.
Résolution :
Investissement en temps : 6 heures pour identifier les versions compatibles.
À retenir : Les roues ML précompilées cachent souvent des contraintes de version qui ne se manifestent qu'au moment de l'exécution.
Défi 2 : Activation de FlashInfer dans vLLM
Problème : Les versions standard de vLLM manquent souvent de support FlashInfer ou nécessitent une compilation source complexe.
Perçage : Nous avons utilisé la build vLLM 0.11.0 sur PyTorch 2.8 Nightly. Cela a permis d'activer nativement le support FlashInfer via pip install "vllm[flashinfer]==0.11.0", contournant les barrières de compilation des versions antérieures.
Impact : Cela a fourni la comparaison la plus équitable possible, confirmant que si les noyaux aident, 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'une utilisation de la mémoire GPU à 0,9 a provoqué des plantages std::bad_alloc.
Progression des tests :
Découverte : La capture du graphique CUDA alloue de la RAM système temporaire proportionnelle à l'utilisation de la mémoire du GPU. À 0,9 × 80 Go = 72 Go d'allocation GPU, la RAM système est épuisée pendant la compilation.
Limite pratique : Une utilisation GPU de 0,8 est la « zone sûre » malgré la capacité matérielle de 80 Go.
Conclusion
Pour l'inférence par lots de Llama 3.1 8B sur H100, la hiérarchie des performances a deux niveaux clairs : vLLM (optimisé avec FlashInfer) fournit une base solide, tandis que les architectures natives C++ de SGLang et LMDeploy débloquent un 29 % supplémentaire en débit.
SGLang (16 215 tok/s) et LMDeploy (16 132 tok/s) atteignent un débit presque identique, suggérant que les deux moteurs saturent la bande passante mémoire du H100. L'écart minime entre eux est du bruit statistique.
Pour les déploiements en production : LMDeploy émerge comme le gagnant pratique, offrant 99,5 % du débit de pointe de SGLang avec une installation triviale (pip install lmdeploy) par rapport à la résolution complexe des dépendances de SGLang.
vLLM avec FlashInfer (12 553 tok/s) offre un compromis convaincant : des performances respectables tout en maintenant la compatibilité matérielle complète et la plus grande matrice de support de modèles de l'industrie. Cependant, pour des clusters H100 dédiés, laisser 29 % de performance sur la table est un coût élevé.
Pour la standardisation sur une infrastructure hétérogène ou l'expérimentation rapide de modèles, vLLM reste le choix rationnel. Pour les déploiements H100 dédiés où le débit est primordial, la combinaison de performances de pointe et de simplicité d'installation de LMDeploy est inégalée.
FAQ
Un moteur d'inférence LLM est un logiciel spécialisé qui optimise la façon dont les grands modèles de langage génèrent des réponses. Bien que vous puissiez exécuter des modèles avec PyTorch ou TensorFlow de base, les moteurs d'inférence ajoutent des optimisations critiques telles qu'une gestion efficace de la mémoire, le regroupement de plusieurs requêtes et des optimisations de noyau GPU. Ces améliorations peuvent considérablement augmenter le débit (jetons générés par seconde) et réduire les coûts, offrant potentiellement des performances 3 à 5 fois meilleures sur le même matériel.
L'inférence par lots hors ligne traite de nombreuses invites simultanément sans exigences en temps réel, pensez à l'analyse de milliers de documents ou à la génération d'embeddings pour un jeu de données. Le service en ligne gère des requêtes utilisateur individuelles avec des exigences de latence strictes, où des métriques comme le temps jusqu'au premier jeton (TTFT) comptent plus que le débit brut. Le moteur qui gagne en débit par lots peut ne pas être optimal pour les chatbots interactifs, alors choisissez en fonction de votre modèle de charge de travail réel
Citer cette recherche
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Sarı, Ekrem},
title = {{LLM Moteurs d'inférence: vLLM vs LMDeploy vs SGLang}},
year = {2026},
month = apr,
howpublished = {\url{https://aimultiple.com/inference-engines}},
note = {AIMultiple. Consulté le 15 Avril 2026}
}
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.