Inférence LLM : vLLM ou SGLang pour les agents et le RAG ?

Inférence LLM : faut-il choisir vLLM ou SGLang ?

vLLM reste le choix de déploiement par défaut. SGLang mérite d’être évalué en premier lorsque le contexte partagé domine la charge. Ces recommandations reposent sur les méthodes de déploiement et les réglages de cache documentés ; elles ne signifient pas qu’un moteur est systématiquement plus rapide que l’autre.

Si vous servez de nombreuses conversations courtes, un prompt système commun justifie d’évaluer SGLang, sans pour autant écarter vLLM. Les deux réutilisent les calculs effectués sur les prompts. Si vous lancez une API simple avec peu de temps à consacrer à l’infrastructure, commencez par vLLM et ne changez que pour un gain démontré sur le service ou les coûts.

Le RAG, ou génération augmentée par récupération, ajoute au prompt du modèle des documents récupérés. C’est le début identique de ce prompt, et non l’étiquette RAG, qui rend le cache de préfixes utile.

Date de vérification : 14 octobre 2026. Les dernières versions stables identifiées lors de cette vérification étaient vLLM 0.31.0, publiée le 5 octobre, et SGLang 0.5.21, publiée le 2 octobre. Les fonctionnalités décrites ci-dessous suivent la documentation en ligne des projets ; vérifiez la combinaison dont vous avez besoin sur la version précise que vous déployez. Aucun benchmark d’inférence n’a été exécuté pour ce comparatif.

Les licences ont été vérifiées dans la licence de vLLM et le dépôt de SGLang. Les licences des poids des modèles, l’infrastructure et le travail d’ingénierie constituent des coûts distincts. Aucun des deux moteurs open source ne propose de tarif hébergé au token à comparer.

Le rôle de chaque moteur et ses limites

vLLM : le choix par défaut pour servir des modèles

vLLM est un moteur d’inférence et de mise à disposition de modèles : il charge leurs poids et ordonnance les requêtes sur votre matériel. Parmi ses composants documentés figurent le continuous batching, qui intègre de nouvelles requêtes à mesure que d’autres se terminent, et PagedAttention, qui gère le cache clés-valeurs du modèle par blocs au lieu de réserver une grande zone mémoire contiguë pour chaque requête. Le cache KV conserve les états intermédiaires de l’attention afin que le modèle poursuive la génération sans recalculer tout l’historique. Documentation de vLLM

Son intérêt comme point de départ tient à un ensemble de déploiement clair : un modèle, une image serveur officielle, une API et des instructions d’installation explicites pour chaque plateforme. Pour une équipe produit qui développe une API d’assistance client, c’est une base maîtrisable à partir de laquelle mesurer la capacité.

Sa limite tient à la validation de la configuration complète. Disposer d’un GPU compatible n’est qu’un début : architecture du modèle, quantification, backend d’attention et fonctionnalités demandées doivent fonctionner ensemble. Une exception concrète du cache concerne les services d’évaluation : selon vLLM, une requête qui demande les log-probabilités du prompt contourne le cache de préfixes et recalcule le prompt. Une API de scoring peut donc se comporter différemment d’une API de conversation utilisant le même document. Guide vLLM V1

Le moteur coûte $0. Choisissez-le pour un usage général et un parc hétérogène ; inutile de migrer si votre installation SGLang remplit déjà l’objectif de service et dispose de toutes les fonctionnalités requises.

SGLang : à évaluer en priorité quand les agents réutilisent leur contexte

SGLang est un framework d’inférence open source pour les modèles de langage et multimodaux, qui compte les usages agentiques parmi ses priorités déclarées. RadixAttention organise les états de prompt réutilisables autour des préfixes communs. Son extension HiCache ajoute la mémoire de l’hôte et le stockage derrière le cache GPU. L’intérêt pratique réside dans un ensemble d’outils documentés pour conserver et réutiliser le contexte au fil des requêtes. Dépôt de SGLang, architecture de HiCache

Prenez un agent qui relit régulièrement les mêmes consignes d’assistance avant de traiter différentes questions clients. Ce cas justifie bien davantage une évaluation de SGLang que des prompts sans rapport entre eux, même soumis avec une forte concurrence.

Ses limites sont la portée locale du cache et les écarts fonctionnels entre backends. Dans HiCache, les niveaux GPU et mémoire de l’hôte appartiennent à une instance d’inférence. Le stockage n’est partagé que si le backend retenu est configuré à cette fin. Agrandir le cache en mémoire de l’hôte ne crée donc pas automatiquement un cache commun à tout le parc. Les niveaux supplémentaires ajoutent aussi des budgets mémoire, des transferts et des réglages à gérer. Périmètre de partage de HiCache

Le moteur coûte $0. Choisissez-le lorsque la répétition du contexte est assez importante pour mériter une optimisation ; ne migrez pas au seul motif que vous utilisez des « agents » si vos prompts partagent rarement un préfixe strictement identique.

Cache de préfixes et RadixAttention : pourquoi tester SGLang en premier ?

SGLang mérite la priorité dans les évaluations de charges à contexte répété et à conversations ramifiées ; vLLM dispose déjà de la capacité essentielle de mise en cache. Il ne s’agit pas d’opposer PagedAttention à la possibilité de mettre en cache. PagedAttention organise la mémoire, tandis que le cache de préfixes permet la réutilisation des calculs. L’Automatic Prefix Caching de vLLM couvre explicitement les questions répétées sur de longs documents et les conversations à plusieurs tours. Cache de préfixes de vLLM

Le prefill correspond au traitement du prompt avant le début de la génération. Le décodage correspond à la génération de nouveaux tokens. Trouver un préfixe en cache peut éviter de répéter le prefill ; cela ne supprime pas le décodage nécessaire pour rédiger une nouvelle réponse. Une longue réponse reposant sur peu de contenu d’entrée commun peut donc tirer peu de bénéfices de la réutilisation des préfixes, quel que soit le moteur.

Pour un produit de conversations courtes, placez les consignes stables et les descriptions d’outils avant le contenu variable de la requête, chaque fois que le format de prompt attendu par le modèle le permet. Gardez une sérialisation et un ordre des documents stables. Un horodatage différent près du début peut empêcher la réutilisation de tout le contenu pourtant identique qui suit. Pensez à un trajet commun : une fois les chemins séparés, retrouver le même paysage plus loin ne rend pas identique le parcours déjà effectué.

Le RAG à contexte long appelle une autre vérification : le contexte est-il réutilisable, ou simplement long ? Des questions répétées sur un manuel inchangé se prêtent bien au cache. Un moteur de recherche qui assemble des passages différents dans un ordre différent à chaque requête ne conservera peut-être que son court préfixe système. Mesurez séparément ces cas avant d’investir dans un stockage hiérarchique.

D’après la documentation de SGLang, RadixAttention est activé par défaut et se contrôle avec --disable-radix-cache ; HiCache relève d’un choix de configuration supplémentaire. Quel que soit le moteur, examinez la configuration effective au lieu de déduire le comportement du cache du nom du projet. Arguments du serveur SGLang

Fonctions pour les agents : égalité sur le JSON, validation nécessaire pour les adaptateurs et le décodage spéculatif

Le seul besoin de JSON ne permet pas de départager les deux moteurs. Tous deux permettent de contraindre la génération par un schéma. Laissez le modèle choisir les valeurs, puis imposez la structure et validez le résultat avant d’exécuter une action.

Générer du JSON structuré

vLLM prend en charge JSON Schema via response_format et ses options structured_outputs. SGLang le prend également en charge, avec XGrammar comme backend de grammaire par défaut. Il s’agit de contraintes appliquées au décodage, et pas simplement d’une consigne demandant au modèle de « renvoyer du JSON ». Sorties structurées de vLLM, sorties structurées de SGLang

Pour un agent d’assistance, un schéma peut imposer la présence d’une action et d’un identifiant de ticket. Il ne permet pas de vérifier que ce ticket appartient à l’utilisateur à l’origine de la demande, ni que l’action choisie est justifiée. Gardez ces contrôles dans le code applicatif. Testez ensemble vos schémas réels, le mode de raisonnement et le comportement en streaming : la prise en charge séparée de chaque élément ne prouve pas que leur combinaison fonctionne correctement.

Verdict : égalité pour les besoins JSON courants. Conservez le moteur que vous exploitez déjà, sauf si des requêtes représentatives utilisant vos schémas font apparaître une différence concrète.

Le décodage spéculatif

Le décodage spéculatif est une option d’optimisation dans les deux projets, pas une garantie d’accélération. Un mécanisme de brouillon propose des tokens, puis le modèle cible les vérifie. Des propositions pertinentes et acceptées peuvent réduire le travail de génération séquentielle ; le brouillon, sa vérification et la mémoire mobilisée ont toutefois un coût.

vLLM documente EAGLE, la prédiction de plusieurs tokens, les modèles de brouillon distincts ainsi que les méthodes par n-grammes et suffixes. SGLang documente également EAGLE, la prédiction de plusieurs tokens, les modèles de brouillon et NGRAM. L’adéquation entre le brouillon, le modèle cible, le matériel et le niveau de trafic compte davantage qu’une case cochée dans une liste de fonctionnalités. Méthodes de vLLM, méthodes de SGLang

Verdict : retenez le moteur dont la méthode de brouillon a été validée pour votre modèle. Établissez d’abord une mesure de référence, puis activez la spéculation et comparez la latence des réponses ainsi que la capacité totale. Laissez-la désactivée si le travail supplémentaire n’est pas compensé sous votre charge de production.

Le multi-LoRA pour personnaliser le comportement selon le client

Les deux moteurs peuvent servir plusieurs adaptateurs LoRA, de petits ajouts aux poids issus d’un fine-tuning qui personnalisent un modèle de base commun. vLLM permet de déclarer les adaptateurs avec --lora-modules, avec des réglages de concurrence et de rang. SGLang expose --lora-paths et --max-loras-per-batch ; sa valeur par défaut documentée est de 8 adaptateurs par batch. Ce chiffre ne limite pas le nombre total de clients. LoRA dans vLLM, LoRA dans SGLang

Pour un produit de rédaction personnalisé par client, testez la répartition des adaptateurs attendue, y compris ceux qui ne sont pas encore chargés et les changements fréquents. L’option de chargement en recouvrement de SGLang peut masquer les transferts, mais sa documentation prévient aussi qu’elle peut réduire le regroupement en batch du prefill pour plusieurs adaptateurs et augmenter la latence du premier token. Davantage de réglages ne signifie pas automatiquement davantage de capacité.

Verdict : conservez le moteur dont vous avez validé le fonctionnement avec vos adaptateurs. Le multi-LoRA ne justifie pas à lui seul une migration. SGLang mérite un essai lorsque le chargement des adaptateurs ou une charge très dépendante du cache constitue votre goulot d’étranglement. Sur TPU, consultez la matrice fonctionnelle du backend lui-même : le guide SGLang-JAX indique encore que le multi-LoRA est en développement. Matrice TPU de SGLang

Matériel compatible : vLLM comme point de départ pour un parc hétérogène

Les deux projets annoncent la prise en charge de NVIDIA, AMD, TPU et CPU. Le périmètre réel dépend de la combinaison du backend et du modèle. Une liste de matériels compatibles à l’échelle du projet ne garantit pas que toute configuration GPU, tout adaptateur ou toute méthode de décodage se transpose sans modification.

• NVIDIA : vLLM documente l’installation sur GPU CUDA ; le dépôt de SGLang répertorie les familles pour datacenters et RTX. Les images de la version utilisée doivent être compatibles avec le pilote de l’hôte. Installation GPU de vLLM, liste des matériels SGLang
• AMD : les deux projets documentent le déploiement avec ROCm. SGLang répertorie les Instinct MI300X, MI325X, MI350X et MI355X, avec un guide d’installation distinct. Utilisez l’image ROCm et la configuration de modèle correspondantes. Guide AMD de SGLang
• Google TPU : vLLM renvoie vers son installation distincte tpu-inference. Le guide TPU de SGLang utilise le backend séparé SGLang-JAX et répertorie v6e et v7. Ces méthodes de déploiement distinctes nécessitent chacune de vérifier les fonctionnalités disponibles. Installation TPU de vLLM, guide TPU de SGLang
• CPU : vLLM documente notamment Intel/AMD x86 et ARM AArch64 parmi ses options CPU. Le guide du serveur CPU de SGLang cible spécifiquement Intel AMX sur les processeurs Xeon Scalable de quatrième génération ou ultérieure. La mention « CPU pris en charge » ne recouvre donc pas le même périmètre. Guide CPU de vLLM, guide CPU de SGLang

Une différence d’exploitation concrète peut déterminer votre prochain déploiement : vLLM 0.31.0 publie une image CUDA 12.9 en plus de son image par défaut sous CUDA 13.0. Le guide d’installation actuel de SGLang exige CUDA 13 et indique que sa gamme d’images CUDA 12 s’est arrêtée à la version 0.5.19. Si votre parc ne peut pas encore adopter des pilotes compatibles, examinez ce point avant de comparer les débits. Artefacts de la version vLLM, installation de SGLang

Serveurs compatibles avec OpenAI : le client migre plus facilement que les usages

Les deux moteurs peuvent répondre à un client utilisant les complétions de conversation au format OpenAI. Tous deux documentent /v1/chat/completions et /v1/completions, ce qui réduit le code d’intégration à remplacer. Cela ne rend pas pour autant interchangeables tous les endpoints, extensions, parseurs d’outils ou comportements des modèles. Serveur vLLM, API SGLang

Un chat template transforme les messages associés à des rôles en la séquence de tokens attendue par le modèle. Conservez-le à l’identique lorsque vous comparez les moteurs. Sinon, vous risquez de comparer deux prompts différents sans le savoir. Alignez aussi la révision du modèle, le tokenizer, les paramètres d’échantillonnage et la limite de sortie.

Pour un client vLLM existant, examinez les anciens champs de sortie contrainte avant une migration ou une mise à niveau. La documentation indique que guided_json et les champs associés ont été supprimés en 0.12.0 ; le code actuel doit utiliser la structure prise en charge de structured_outputs ou de response_format. Un corps de requête obsolète peut donner l’impression d’une incompatibilité du moteur. Note de migration de vLLM

Verdict : égalité pour l’interface client de base ; vLLM reste la recommandation par défaut pour l’exploitation. Vos tests de recette doivent couvrir des tours d’agent complets, y compris les arguments d’outils transmis en streaming, les erreurs et les nouvelles tentatives, sans s’arrêter à une première réponse textuelle réussie.

Déployer chaque moteur sur un GPU cloud

Commencez avec une version de conteneur figée et un petit modèle de test, puis remplacez-le par votre modèle de production avec le budget mémoire adapté. Les exemples suivants adaptent les commandes Docker et de lancement documentées par les projets à un hôte Linux équipé d’un GPU NVIDIA, de Docker, du runtime de conteneurs NVIDIA et d’un pilote compatible avec l’image. Ils ont été vérifiés à partir de la documentation, sans être exécutés sur un GPU loué. Docker pour vLLM, démarrage rapide de SGLang

Le modèle Qwen/Qwen3-0.6B ci-dessous sert à vérifier le bon fonctionnement de l’ensemble, sans préjuger de la qualité de ses réponses pour votre agent. Exécutez un seul moteur à la fois sur le même port. La limite de contexte est un réglage explicite de cet exemple, pas le maximum annoncé du modèle.

Conteneur vLLM

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  vllm/vllm-openai:v0.31.0 \
  --model Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 8192 \
  --enable-prefix-caching

Conteneur SGLang

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  lmsysorg/sglang:v0.5.21 \
  python3 -m sglang.launch_server \
  --model-path Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --context-length 8192

Après l’initialisation, exécutez cette requête sur l’hôte GPU :

curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Qwen/Qwen3-0.6B",
    "messages": [{"role": "user", "content": "Say hello."}],
    "max_tokens": 64
  }'

Les exemples lient le port de l’hôte à l’interface de boucle locale. Placez votre passerelle applicative avec authentification devant le serveur avant de servir des utilisateurs distants. Ce point est particulièrement important avec vLLM : sa documentation précise que --api-key n’authentifie pas toutes les routes du serveur HTTP. Périmètre de l’authentification vLLM

Le worker vLLM documenté par Runpod

Runpod propose dans son Hub un worker vLLM prêt à déployer, accompagné de sa documentation. Ce raccourci cloud contribue à la recommandation de vLLM comme choix d’exploitation par défaut. Le paquet du worker constitue un artefact de déploiement distinct : vérifiez la version du moteur qu’il embarque, sans supposer qu’il s’agit de la dernière version du projet. Guide de déploiement de Runpod

Pour SGLang, la méthode de déploiement cloud reproductible décrite ici consiste à utiliser son conteneur officiel sur un hôte GPU compatible. Le raccourci Runpod présenté ci-dessus concerne précisément le worker vLLM documenté par Runpod.

Prix : à GPU identiques, facture identique

À capacité louée égale, aucun moteur n’est moins cher. Le 14 octobre 2026, la page tarifaire de Runpod affichait pour les Pods un A100 PCIe de 80 GB à $1.79/heure. Il s’agit du prix d’un GPU dédié, pas du tarif de facturation du worker Serverless. Ce coût d’infrastructure commun sert de base au calcul ci-dessous. Tarifs de Runpod

Sur la base d’un mois budgétaire de 730 heures, un GPU provisionné en continu revient à $1,306.70/mois, avec vLLM comme avec SGLang. Deux GPU coûtent $2,613.40/mois. Ces montants excluent le stockage, les frais réseau, la redondance et le travail d’ingénierie.

Prenons une charge hypothétique d’assistance sur une base commune : 50,000 requêtes par mois, chacune avec 2,000 tokens d’entrée et 200 tokens de sortie. Cela représente 100 millions de tokens d’entrée et 10 millions de tokens de sortie livrés. Si cette charge tient sur un GPU tout en respectant votre temps de réponse requis, la facture GPU est de $0.13067 pour 1,000 tokens de sortie livrés, quel que soit le moteur. Le dénominateur est le nombre de tokens de sortie ; la facture finance aussi le traitement des entrées.

Il s’agit d’un calcul de coût, pas d’une capacité mesurée. Si la charge ne tient pas sur un GPU, ce résultat ne s’applique pas.

Le seuil qui fait basculer la comparaison est le moment où une configuration a besoin d’une réplique supplémentaire pour tenir le même objectif de service. Si SGLang nécessite un GPU et vLLM deux, SGLang économise $1,306.70/mois. Si les mesures donnent le rapport de capacité inverse, vLLM économise le même montant. Si chacun nécessite un GPU, l’économie d’infrastructure est nulle.

Avec un budget de migration de 8 heures à un tarif supposé de $100/heure, le coût atteint $800. Supprimer un GPU à ce tarif amortit la migration en environ 0.61 mois, avant toute différence de coûts d’exploitation récurrents. Sans suppression d’une réplique ni amélioration du service à laquelle vous attribuez une valeur, être « plus rapide » peut ne produire aucun retour financier.

Verdict sur le prix : gagne la configuration qui atteint l’objectif avec le coût total d’exploitation le plus faible. Impossible d’annoncer honnêtement un seuil de trafic où l’un des moteurs devient plus rentable sans mesurer au préalable la capacité que votre charge peut atteindre en respectant vos exigences de service.

Performances de vLLM et SGLang : mesurer le travail accompli à la latence visée

Ce comparatif n’établit aucun vainqueur universel en matière de débit. Un résultat publié par un projet reste lié à son modèle, son matériel, sa précision numérique, ses longueurs de requête et sa version. Une amélioration de kernel ne se traduit pas nécessairement par un gain de bout en bout, et le débit de prefill n’est pas le débit de tokens de sortie. Aucun de ces résultats ne justifie une affirmation générale du type « SGLang est plus rapide » ou « vLLM est plus rapide ».

Prenez comme point de départ les outils des projets : la CLI de benchmark de vLLM et le guide de benchmark du serveur SGLang. La comparaison doit inclure des essais à cache chaud et à cache froid, ainsi que le profil de charge réel de votre produit.

Mesurez séparément quatre situations : des conversations courtes partageant un prompt système stable ; des questions répétées sur un même long document ; de longs prompts RAG dont les passages récupérés changent ; et votre combinaison réelle de schémas, d’appels d’outils et d’adaptateurs. Préservez le rythme d’arrivée des requêtes autant que leur concurrence. Une rafale de requêtes simultanées et un flux régulier peuvent révéler des goulots d’étranglement différents.

Relevez les requêtes terminées, les tokens de sortie livrés, les erreurs et la latence du premier token. Examinez aussi les latences p95 et p99, soit les 95e et 99e centiles, car une bonne moyenne peut masquer des temps de réponse très dégradés en queue de distribution. Comptez comme des échecs les sorties qui ne passent pas les contrôles de schéma ou de validité de l’application : elles ne constituent pas de la capacité utile.

Le meilleur choix est le déploiement le moins coûteux qui respecte ces critères de recette. Une promesse de vitesse obtenue avec un autre modèle ou une ancienne version justifie de mener cette comparaison ; elle n’en donne pas le résultat.

Changer de moteur : préserver le contrat et prévoir le retour arrière

Ne migrez la couche de service que si le bénéfice mesuré dépasse le coût de migration et d’exploitation. Vos données applicatives et votre base de recherche documentaire peuvent généralement rester en place lorsque seul le backend de génération change. Le travail porte sur le conditionnement du modèle, les extensions de requête, l’analyse des sorties et le comportement au déploiement.

Ne remplacez pas un déploiement vLLM qui fonctionne bien dans le seul but d’obtenir un cache de préfixes ou des contraintes JSON : il possède déjà les deux. Ne remplacez pas non plus un déploiement SGLang qui fonctionne bien au seul motif que vLLM est recommandé par défaut ici. La connaissance opérationnelle déjà acquise entre dans la comparaison des coûts.

Si vous hésitez encore sur la nécessité même d’un serveur de production partagé, consultez Ollama vs vLLM. Ce comparatif traite du choix préalable entre un workflow pratique avec un modèle local et une couche de service capable de gérer des requêtes qui se chevauchent.

Prochaine étape : capturez un trafic de pointe représentatif, fixez les temps de réponse et le taux d’erreur maximaux acceptables, puis comparez les versions figées des moteurs sur le même matériel avant d’agrandir le parc.

Questions fréquentes

Utilisez la checklist d’audit des workflows IA en entreprise pour repérer le workflow qui justifie un serveur de modèles partagé, et abonnez-vous à la newsletter pour suivre les prochaines évolutions des outils.