LLM Moteurs d'inférence: vLLM vs LMDeploy vs SGLang
Nous avons évalué 3 principaux moteurs d'inférence LLM sur du matériel NVIDIA H100 : vLLM, LMDeploy et SGLang. Chaque moteur a traité des charges de travail identiques : 1 000 prompts ShareGPT en utilisant Llama 3.1 8B-Instruct pour isoler le véritable impact de leurs choix architecturaux et de leurs 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 des performances H100 avec une complexité minimale -Équipes privilégiant la simplicité d'installation (installation pip en une seule ligne) |
SGLang | -Organisations ayant besoin d'un débit maximal absolu (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 batch hors ligne sur 10 000 opérations d'inférence au total (1 000 prompts × 10 exécutions par moteur) pour garantir la stabilité statistique.
- Débit : Tokens de sortie générés par seconde en mode d'inférence batch. 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 du matériel H100 80 Go.
Pour comprendre comment nous avons calculé les débits, veuillez consulter notre méthodologie de benchmark d'inférence.
Principales conclusions
Notre approche minimise les variables confondantes : modèle, matériel, dataset, configuration d'échantillonnage, limites de mémoire et protocole de préchauffage identiques. Cette isolation révèle ce que l'architecture de chaque moteur apporte réellement.
L'écart architectural est de 29 % : Même lorsque vLLM est optimisé avec exactement les mêmes kernels (FlashInfer) que SGLang, il reste significativement derrière les leaders. SGLang (16 215 tok/s) et LMDeploy (16 132 tok/s) conservent un avantage de 29 % par rapport à vLLM entièrement optimisé (12 553 tok/s). Cela indique que le goulot d'étranglement n'est plus le kernel 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 + Kernels natifs » (SGLang) et l'approche « Moteur C++ pur » (LMDeploy) sont des stratégies tout aussi valables pour atteindre des performances maximales sur les architectures Hopper.
« Zone de sécurité » de la mémoire GPU à 80 % d'utilisation : Les tentatives d'allouer 95 % de la mémoire GPU ont provoqué des plantages immédiats lors de la compilation CUDA Graph sur tous les moteurs, malgré la capacité de 80 Go. La cause racine a été identifiée comme un épuisement de la RAM système pendant la capture du graphe, et non les limites de mémoire GPU. Une fraction de 0,8 a fourni l'équilibre optimal entre stabilité et taille de batch.
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 via RadixAttention, un gestionnaire de mémoire spécialisé conçu pour les patterns de serving complexes. LMDeploy y parvient via 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 qu'il s'agisse d'une amélioration massive par rapport aux configurations standard, l'écart restant met en évidence le coût de l'architecture flexible basée sur des plugins de vLLM (PagedAttention) par rapport aux conceptions hyper-spécialisées des leaders.
Différences de philosophie d'architecture : SGLang et LMDeploy co-conçoivent leurs mécanismes d'attention avec des hypothèses de kernel. vLLM maintient une couche de compatibilité plus large qui oblige les algorithmes d'attention à fonctionner avec divers backends, ce qui limite la profondeur des optimisations spécifiques sur le matériel de pointe.
Optimisation des patterns d'accès mémoire : L'écart de 29 % suggère que SGLang et LMDeploy optimisent la coalescence mémoire, la localité du cache et l'ordonnancement des batchs de manière plus agressive que ne le permet le planificateur de vLLM, en particulier dans la façon dont ils gèrent le Tensor Memory Accelerator (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
Dataset et charge de travail
Source : Dataset ShareGPT_Vicuna_unfiltered de Hugging Face
Critères de sélection :
Pourquoi ce dataset : ShareGPT contient de vraies conversations utilisateur-chatbot avec une variation naturelle de longueur, proxy plus précisément les charges de travail de chatbots 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 préchauffage : Traiter 20 prompts pour déclencher la compilation JIT et stabiliser les horloges GPU.
- Exécutions du benchmark : Exécuter 10 passes complètes des 1 000 prompts.
- Méthodologie de chronométrage :
- Comptage des tokens : Extraire les comptes de tokens réels des formats de sortie spécifiques à chaque moteur.
- Calcul du débit : total_output_tokens / durée.
Rigueur statistique :
- 10 000 opérations d'inférence au total (1 000 prompts × 10 exécutions par moteur).
- Environ 1,5 million de tokens générés par moteur.
- Écart-type constamment inférieur à 1 % de la moyenne sur tous les moteurs.
Interprétation des résultats
Ce que vous pouvez conclure :
Pour l'inférence batch hors ligne de Llama 3.1 8B sur du matériel H100, l'efficacité architecturale détermine le vainqueur. Même avec les meilleurs kernels possibles (FlashInfer), vLLM ne peut pas égaler le débit de SGLang ou de 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 à ce scénario exact : le traitement par batch de 1 000 prompts simultanément. SGLang et LMDeploy sont des choix robustes qui offrent environ 45 % de valeur en plus par heure GPU que les 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 :
- Modèles différents : Résultats spécifiques à Llama 3.1 8B. Des modèles plus grands (par exemple, 70B) ou des architectures différentes (par exemple, Mixtral, Qwen) présenteront des patterns 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 serving en ligne nécessite le TTFT et les centiles de latence, où les résultats diffèrent considérablement.
- Charges de travail différentes : Les prompts aléatoires minimisent les avantages du cache de préfixes. Les prompts système répétés ou les conversations multi-tours modifient radicalement le paysage des performances en faveur de SGLang.
Comparaison de l'expérience développeur
Les chiffres de performance ne reflètent pas l'image complète du déploiement. Chaque moteur offre des flux de travail développeur distincts :
vLLM : Standard de l'industrie pour une bonne raison
La simplicité rencontre une large compatibilité. Une seule installation pip de 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 : Le prototypage rapide, les environnements GPU hétérogènes, la couverture maximale de modèles ou l'exploitation du plus grand écosystème.
LMDeploy : Qualité production avec une friction minimale
Une installation en une seule ligne (pip install lmdeploy) offre 99,5 % des performances maximales du H100. Un backend C++ natif signifie zéro surcharge Python. Support de quantification de premier ordre (AWQ, GPTQ) pour une optimisation supplémentaire. Pas d'enfer des dépendances.
- Choisissez LMDeploy pour les 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 un coût de complexité
Le débit maximal absolu (16 215 tok/s) a un prix : un effort significatif de débogage de l'installation FlashInfer. Nécessite une version spécifique de PyTorch. Incompatibilités binaires avec certains wheels pré-compilés. RadixAttention brille sur 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 dernier point de pourcentage de débit.
Dé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 wheels FlashInfer de SGLang attendent des versions spécifiques de PyTorch, mais les conteneurs optimisés pour H100 en fournissent souvent de différentes.
Résolution :
Investissement en temps : 6 heures pour identifier les versions compatibles.
À retenir : Les wheels ML pré-compilés cachent souvent des contraintes de version qui n'apparaissent qu'à l'exécution.
Défi 2 : Activer FlashInfer dans vLLM
Problème : Les versions standard de vLLM manquent souvent de support FlashInfer ou nécessitent une compilation source complexe.
Percée : Nous avons utilisé la build vLLM 0.11.0 sur PyTorch 2.8 Nightly. Cela a permis d'activer avec succès le support natif de FlashInfer via pip install « vllm[flashinfer]==0.11.0 », en contournant les barrières de compilation des versions antérieures.
Impact : Cela a fourni la comparaison la plus équitable possible, confirmant que si les kernels 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 de 0,9 d'utilisation de la mémoire GPU a provoqué des plantages std::bad_alloc .
Progression des tests :
Découverte : La capture CUDA Graph 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 : 0,8 d'utilisation GPU est la « zone de sécurité » malgré la capacité matérielle de 80 Go.
Conclusion
Pour l'inférence batch 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 C++ natives de SGLang et LMDeploy débloquent 29 % de débit supplémentaire.
SGLang (16 215 tok/s) et LMDeploy (16 132 tok/s) atteignent un débit quasi identique, ce qui suggère 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 apparaît comme le gagnant pratique, offrant 99,5 % du débit maximal de SGLang avec une installation triviale (pip install lmdeploy) contre la résolution complexe des dépendances de SGLang.
vLLM avec FlashInfer (12 553 tok/s) offre un compromis intéressant : des performances respectables tout en maintenant une compatibilité matérielle complète et la plus grande matrice de support de modèles de l'industrie. Cependant, pour les clusters H100 dédiés, laisser 29 % de performances sur la table représente 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 maximales et de simplicité d'installation de LMDeploy est inégalée.
Ajouter comme source préféréeFAQ
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 que la gestion efficace de la mémoire, le regroupement de plusieurs requêtes et les optimisations de kernel GPU. Ces améliorations peuvent augmenter considérablement le débit (tokens 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.
L'inférence batch hors ligne traite de nombreux prompts simultanément sans exigences de temps réel, pensez à l'analyse de milliers de documents ou à la génération d'embeddings pour un dataset. Le serving en ligne gère les requêtes individuelles des utilisateurs avec des exigences de latence strictes, où des métriques comme le Time To First Token (TTFT) comptent plus que le débit brut. Le moteur qui gagne en débit batch peut ne pas être optimal pour les chatbots interactifs, alors choisissez en fonction de votre pattern 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.