- vLLM constitue le choix par défaut le plus sûr— prise en charge la plus étendue des modèles et des architectures matérielles, écosystème le plus vaste, moindre complexité de déploiement.
- Choisissez SGLang lorsque votre trafic réutilise massivement des préfixes de prompts (agents, conversations multi-tours, prompts système volumineux) ou génère de grandes quantités de sorties structurées au format JSON — RadixAttention et le décodage « jump-forward » y excellent.
- L’écart de performance dépend de la charge de travail et se réduit à chaque nouvelle version. Les deux moteurs implémentent l’API OpenAI, ce qui rend peu coûteuse la comparaison directe sur votre trafic réel.
- Aucun des deux ne fonctionne nativement sous Windows ou macOS — utilisez Linux (ou WSL2), ou un outil de bureau comme Ollama/LM Studio pour une utilisation locale.
vLLM et SGLang sont les deux principaux moteurs open source permettant de servir des grands modèles de langage sur vos propres GPU, et pour la plupart des équipes vLLM constitue le choix par défaut le plus sûr— plus de modèles pris en charge, plus d’architectures matérielles compatibles, un écosystème plus vaste. Choisissez SGLang lorsque votre trafic est dominé par des préfixes de prompts partagés — agents, conversations multi-tours, prompts système importants — ou par des sorties structurées au format JSON, où son cache RadixAttention et son décodage basé sur les grammaires lui confèrent un avantage réel. Les deux moteurs exposent une API compatible OpenAI, si bien qu’un changement ultérieur ne coûte presque rien.
Ce guide les compare selon la méthode que vous adopteriez concrètement pour choisir : les objectifs spécifiques de chaque projet, les différences pratiques entre RadixAttention et PagedAttention, les domaines dans lesquels chacun excelle en débit et en latence, ainsi qu’une recommandation claire selon la charge de travail.
Les priorités de chaque projet
vLLM a vu le jour en 2023 à l’Université de Californie à Berkeley en tant qu’implémentation de référence de l’article scientifique sur PagedAttention, et est aujourd’hui devenu le moteur open source de référence pour le service de modèles, intégré désormais au sein de la PyTorch Foundation. Ses priorités sont l’étendue et la robustesse : exécuter quasiment tous les modèles open-weight sur presque tous les accélérateurs — CUDA NVIDIA, ROCm AMD, processeurs Intel, TPU Google, AWS Neuron, voire CPU x86 — avec un débit élevé dès l’installation. Les nouvelles familles de modèles bénéficient généralement d’un support vLLM dès leur sortie, ou très peu de temps après.
SGLang provient de l’équipe LMSYS, à l’origine de Chatbot Arena. Il est optimisé pour deux objectifs précis : réutilisation du cache KV (RadixAttention) et génération structurée accélérée. Ce nom est l’abréviation de « Structured Generation Language » — il était initialement livré avec un DSL Python permettant de chaîner et de brancher des appels à des modèles de langage volumineux (LLM) — mais c’est le runtime de service qui est aujourd’hui déployé par la plupart des utilisateurs. Il bénéficie d’une solide crédibilité en production : il figurait parmi les moteurs DeepSeek recommandés lors du lancement de la version V3, et il est réputé pour ses optimisations agressives multi-GPU (découplage préremplissage/décodage, parallélisme d’experts à grande échelle pour les modèles MoE).
RadixAttention contre PagedAttention, expliqué simplement
Les deux techniques phares résolvent des problèmes distincts, et leurs noms suggèrent à tort une alternative exclusive.
PagedAttention (vLLM) concerne la gestion mémoire. Elle stocke le cache KV dans des blocs de taille fixe, à l’instar de la pagination mémoire virtuelle d’un système d’exploitation, plutôt que de réserver un seul gros bloc contigu par requête. Cela élimine presque entièrement la fragmentation, permettant ainsi d’exécuter bien plus de séquences simultanées dans la même mémoire VRAM ; des lots plus importants se traduisent par un débit accru. Il s’agit donc de faire tenir davantage de choses.
RadixAttention (SGLang) concerne la réutilisation mémoire. Elle organise le cache KV sous forme d’un arbre radix indexé par des séquences de jetons. Lorsqu’une nouvelle requête arrive, le moteur parcourt l’arbre, identifie le plus long préfixe commun et évite de le recalculer. Les invites système, les exemples à faible nombre de coups (few-shot), l’historique des conversations et les blocs-notes temporaires d’agents (scratchpads) qui se répètent d’une requête à l’autre sont précalculés une seule fois lors du préremplissage et réutilisés. Il s’agit donc de calculer moins.
En 2026, les deux moteurs se sont rapprochés davantage que ne le suggère leur positionnement marketing : vLLM intègre désormais une mise en cache automatique des préfixes (activée par défaut dans les versions récentes), tandis que SGLang utilise également une gestion paginée de la mémoire. La différence pratique restante tient au fait que SGLang a été conçu dès l’origine autour de la réutilisation — son planificateur (scheduler) prend en compte le cache, ordonnance et achemine les requêtes de façon à maximiser le taux de correspondance (hit rate). Règle empirique : plus une part importante de vos invites typiques se répète d’une requête à l’autre, plus la conception de SGLang porte ses fruits.
Dans tous les cas, le cache KV entre en concurrence avec les poids du modèle pour la même mémoire GPU, et la marge de concurrence (concurrency headroom) est précisément ce que vous achetez avec un moteur de service. Utilisez le Calculateur de VRAM pour estimer combien de mémoire un modèle donné, combiné à un contexte spécifique, laisse disponible pour le cache avant de dimensionner votre matériel.
Débit et latence : les domaines de prédilection de chacun
| Charge de travail | Généralement plus rapide | Pourquoi |
|---|---|---|
| Dialogues multi-tours, boucles d’agents, invites système partagées volumineuses | SGLang | RadixAttention évite le préremplissage répété des préfixes communs, réduisant ainsi le délai avant le premier jeton (time-to-first-token) et libérant des ressources calculatoires |
| Invites ponctuelles avec peu ou pas de chevauchement (documents uniques, synthèse par lot) | À peu près équivalent | Les deux moteurs utilisent le regroupement continu (continuous batching) et le préremplissage par blocs (chunked prefill) ; la réutilisation du cache se déclenche rarement |
| Génération intensive de JSON ou sortie contrainte | SGLang | Le décodage « jump-forward » émet des jetons imposés par la grammaire sans effectuer de passage avant (forward pass) du modèle |
| Zoo de modèles hétérogène, quantifications exotiques, matériel non-NVIDIA | vLLM | Une couverture plus étendue des backends et formats implique moins de chemins de repli non optimisés |
Considérez toute valeur de débit spécifique trouvée en ligne comme liée à une version donnée. Les deux projets livrent continuellement des optimisations, et chacun a publié des benchmarks où il devance l’autre. La réponse honnête est que, sur un trafic favorable au cache, SGLang est généralement en tête, que sur un trafic sans cache préchargé (cold-cache) les performances sont proches, et que le seul benchmark pertinent reste le vôtre : les deux projets fournissent des outils de test de charge (vLLM propose vllm bench serve, SGLang propose python -m sglang.bench_serving) permettant de rejouer des flux de requêtes réalistes.
Sorties structurées et contraintes
Les deux moteurs peuvent forcer la sortie à respecter un schéma JSON, une expression régulière ou une grammaire, via le paramètre OpenAI-compatible response_format et des extensions spécifiques à chaque moteur.
SGLang a été pionnier sur ce chemin rapide : il compile les contraintes en une machine à états finie compressée et utilise le décodage « jump-forward » — lorsque la grammaire rend les prochains jetons déterministes (accolades, guillemets, noms de clés fixes), ceux-ci sont ajoutés directement, sans faire appel au modèle pour chacun d’eux. Pour les pipelines d’extraction produisant des sorties JSON très volumineuses en jetons, cela représente un gain de vitesse significatif.
vLLM prend en charge la même classe de contraintes via des backends grammaticaux extensibles (xgrammar, guidance, outlines), et depuis que les deux projets ont adopté xgrammar comme backend par défaut, l’écart s’est considérablement réduit. Conclusion : les deux solutions sont prêtes pour la production ; SGLang conserve toutefois un avantage sur les charges de travail fortement structurées et à fort volume.
Écosystème, support matériel et facilité de déploiement
| vLLM | SGLang | |
|---|---|---|
| Origine | Université de Californie à Berkeley ; projet de la PyTorch Foundation | LMSYS (équipe Chatbot Arena) |
| Matériel | NVIDIA, AMD ROCm, Intel, Google TPU, AWS Neuron, processeurs x86 | Prise en charge native pour NVIDIA, support AMD ROCm disponible ; autres plateformes moins matures |
| Couverture des modèles | La plus étendue de tous les moteurs, y compris de nombreux modèles multimodaux et des architectures spécialisées | Toutes les grandes familles (Llama, Qwen, DeepSeek, Mistral, GPT-OSS…), couverture moindre pour les modèles plus rares |
| Quantification | FP8, AWQ, GPTQ, INT8, bitsandbytes, etc. | FP8, AWQ, GPTQ ; liste plus restreinte |
| API | Compatible OpenAI, port par défaut 8000 | Compatible OpenAI, port par défaut 30000 |
| Image Docker | vllm/vllm-openai | lmsysorg/sglang |
Pour démarrer, une seule commande suffit pour chacun sur une machine Linux CUDA :
pip install vllm puis vllm serve Qwen/Qwen2.5-7B-Instruct — expose une API compatible OpenAI sur le port 8000.
pip install "sglang[all]" puis python -m sglang.launch_server --model-path Qwen/Qwen2.5-7B-Instruct — même interface API sur le port 30000.
Le parallélisme tensoriel multi-GPU est activé via l’option --tensor-parallel-size 2 dans vLLM et --tp 2 dans SGLang. Les deux chargent directement les poids depuis Hugging Face. Pour choisir la carte graphique elle-même, consultez le guide sur les meilleures GPU pour les LLM locaux et vérifiez les exigences spécifiques de chaque modèle dans la Base de données de modèles.
Où les différences se font sentir : la documentation de vLLM, ses outils Kubernetes et les réponses communautaires sont nettement plus nombreuses ; les erreurs obscures ont donc plus de chances d’avoir déjà été résolues dans un ticket GitHub. Les installations de SGLang sont parfois plus exigeantes concernant les combinaisons de versions CUDA/PyTorch ; l’image Docker constitue ici la voie la moins contraignante.
Prise en charge des plateformes
Linux
La seule plateforme entièrement prise en charge par les deux. Les GPU NVIDIA équipés d’un pilote CUDA récent constituent la solution principale ; ROCm d’AMD fonctionne sur les deux avec les cartes compatibles. Utilisez les images Docker officielles pour minimiser les problèmes liés aux versions.
Windows
Aucun des deux moteurs ne prend en charge Windows nativement. Tous deux fonctionnent sous WSL2 avec le pilote CUDA pour WSL fourni par NVIDIA, une configuration parfaitement adaptée au développement. Pour la production, utilisez un hôte Linux réel. Si vous souhaitez simplement exécuter un modèle localement sur un poste Windows sans créer de point de terminaison de service, Ollama est l’outil le plus simple.
macOS
Aucun des deux projets ne prend en charge le déploiement sur Apple Silicon. vLLM peut être compilé à partir des sources pour une inférence CPU uniquement sur macOS, mais il s’agit d’une commodité destinée au développement, non à un environnement de production ; SGLang ne cible pas du tout macOS. Pour une inférence locale sur Mac, privilégiez Ollama ou LM Studio, qui tirent parti de l’accélération GPU Metal d’Apple.
Quel moteur choisir, selon la charge de travail
- Chatbots, assistants, cadres d’agents — invites système longues, outils, historique multi-tours : SGLang. C’est précisément ce type de trafic que RadixAttention a été conçu pour gérer.
- Extraction structurée à haut volume — classification/extraction vers JSON à grande échelle : SGLang, pour le décodage « jump-forward ».
- Traitement par lots de documents uniques — synthèse, pipelines associés aux embeddings avec peu de chevauchement entre invites : vLLM; la réutilisation du cache n’apporte aucun bénéfice, tandis que les outils fournis par vLLM sont plus complets.
- De nombreux modèles différents, ou matériel non-NVIDIA — AMD, Intel, TPU, Inferentia, checkpoints quantifiés exotiques : vLLM, sans conteste le leader en termes de couverture.
- Vous n’êtes pas sûr(e): commencez par vLLM, puis effectuez un test A/B avec SGLang en utilisant vos propres journaux de requêtes réelles. L’API OpenAI partagée rend ce basculement aussi simple qu’un changement d’URL de base.
Et avant de vous engager définitivement avec l’un ou l’autre, vérifiez rationnellement si l’auto-hébergement reste pertinent comparé à un simple appel d’API à votre volume — le calculateur de seuil de rentabilité entre auto-hébergement et API effectue ce calcul pour chaque modèle et chaque charge de requêtes.
Questions fréquemment posées
SGLang est-il plus rapide que vLLM ?
Sur les charges de travail comportant une forte réutilisation de préfixes ou des sorties structurées, généralement oui — parfois de façon notable. Sur des invites ponctuelles sans cache chaud, les performances des deux moteurs sont proches, et les résultats peuvent varier d’une version à l’autre. Effectuez des tests de référence avec votre propre profil de trafic plutôt que de vous fier à une seule valeur publiée.
Puis-je utiliser le SDK Python OpenAI avec les deux ?
Oui. Les deux exposent un point de terminaison compatible avec l’API OpenAI /v1/chat/completions ; il suffit donc de configurer le SDK officiel pour qu’il pointe vers l’URL base_url vers http://localhost:8000/v1 (vLLM) ou http://localhost:30000/v1 (SGLang), avec n’importe quelle clé API factice. C’est ce qui rend presque gratuit le test A/B entre les deux solutions.
vLLM ne propose-t-il pas également une mise en cache des préfixes ?
Si, il le fait — la mise en cache automatique des préfixes est activée par défaut dans les versions récentes et réutilise les blocs KV dont le contenu haché correspond. L’arbre radix de SGLang permet une correspondance plus fine, et son planificateur ordonne activement les requêtes afin d’augmenter le taux de réussite, ce qui explique pourquoi SGLang conserve généralement l’avantage sur les charges de travail fortement dépendantes du cache.
Lequel des deux moteurs prend en charge le plus de modèles ?
vLLM, sans ambiguïté — sa liste d’architectures prises en charge est la plus étendue parmi tous les moteurs open source, notamment pour les modèles multimodaux et spécialisés. SGLang couvre toutes les grandes familles de modèles open-weight et assure souvent un support immédiat dès la sortie des nouveaux modèles phares (ses optimisations pour DeepSeek sont particulièrement remarquables), mais la longue traîne des modèles relève clairement de vLLM. Vérifiez les besoins spécifiques d’un modèle donné dans la Guide des exigences en VRAM.
Où s’inscrivent Ollama et llama.cpp ?
Catégorie différente. Ollama et LM Studio sont des outils locaux mono-utilisateur, optimisés pour la simplicité d’utilisation sur les postes de travail, y compris les Macs ; SGLang et vLLM sont des moteurs serveur à haute concurrence, optimisés pour le débit GPU face à de nombreuses requêtes simultanées. Si vous servez un seul utilisateur, privilégiez Ollama ; si vous servez une application, optez pour l’un de ces deux moteurs.
