vLLM

vLLM est une bibliothèque open source conçue pour l'inférence et le service rapides et économes en mémoire des grands modèles de langage (LLM). Créée au UC Berkeley Sky Computing Lab en 2023 par Woosuk Kwon, Zhuohan Li, Siyuan Zhuang et leurs collaborateurs, elle a depuis été offerte à la PyTorch Foundation pour garantir une gouvernance neutre vis-à-vis des fournisseurs. Le principal problème qu'elle résout est la fragmentation de la mémoire GPU lors du service de LLM : avant vLLM, les serveurs d'inférence gaspillaient 60 à 80 % de la mémoire cache KV réservée en allouant des blocs contigus pour chaque séquence. L'algorithme PagedAttention de vLLM s'inspire de la pagination de la mémoire virtuelle des systèmes d'exploitation pour stocker le cache KV dans des pages non contiguës, réduisant le gaspillage à presque zéro et permettant de traiter beaucoup plus de séquences simultanées sur le même matériel.

La bibliothèque est fournie avec un serveur d'API REST compatible avec OpenAI, un traitement par lots continu (continuous batching) au niveau de l'itération (et non de la requête), un parallélisme de tenseurs et de pipelines pour les déploiements multi-GPU et multi-nœuds, un décodage spéculatif, ainsi qu'une prise en charge native des formats de quantification tels que GPTQ, AWQ, INT8 et FP8. Elle prend en charge des centaines de modèles grâce à l'intégration de HuggingFace Transformers : Llama 3.x, Mistral, Mixtral, Qwen, DeepSeek, Gemma, Phi, et des modèles de vision-langage comme LLaVA et Pixtral. La refonte de l'architecture v1 en janvier 2025 a séparé le planificateur (scheduler) de la boucle de travail (worker loop), offrant une structure interne plus propre et de meilleurs outils pour profiler les déploiements en production. vLLM fonctionne sur le matériel NVIDIA, AMD ROCm, Intel Gaudi et AWS Trainium.

Ce que fait réellement vLLM en avril 2026

Le rôle de vLLM est de servir des LLM open source à des niveaux de débit qui rendent leur déploiement en production économiquement viable. Le mécanisme repose sur PagedAttention associé au traitement par lots continu. PagedAttention divise le stockage du cache KV en "pages" de taille fixe et les gère avec une table de blocs, éliminant ainsi la fragmentation due à la pré-allocation d'une région de mémoire contiguë pour la longueur maximale possible de chaque séquence. Le traitement par lots continu signifie que le moteur insère de nouvelles requêtes dans un lot actif dès qu'une séquence se termine, maintenant ainsi une utilisation élevée du GPU au lieu d'attendre qu'un lot entier se vide avant de commencer le suivant.

Le résultat, documenté dans l'article SOSP 2023, a été un débit jusqu'à 24 fois supérieur par rapport à une boucle de service HuggingFace Transformers naïve sur le même matériel. Concrètement : un seul GPU A100 80GB servant Llama 3.1 8B peut gérer environ 200 utilisateurs simultanés en streaming avec une latence acceptable, là où une boucle naïve saturerait à 10-20.

Le démarrage du serveur se fait en une seule commande : vllm serve meta-llama/Llama-3.1-8B-Instruct --tensor-parallel-size 1. Le serveur expose ensuite les points de terminaison /v1/chat/completions et /v1/completions qui correspondent aux spécifications de l'API OpenAI. Toute application existante utilisant le client Python OpenAI peut être redirigée vers le serveur vLLM en modifiant simplement l'URL de base et la clé d'API, sans aucune autre modification du code. Cette compatibilité est citée par les ingénieurs de plateforme comme le principal moteur d'adoption, car elle élimine les obstacles à la migration du prototype vers une production auto-hébergée.

Au-delà du serveur, vLLM propose une API d'inférence hors ligne pour les traitements par lots. Une équipe de data science traitant 100 000 complétions de classification peut charger un modèle une seule fois et exécuter un appel LLM.generate() sur une liste de prompts, obtenant un débit 5 à 10 fois supérieur à celui d'appels d'API séquentiels. Les équipes de Together AI utilisent cette méthode pour des tâches d'inférence par lots à grande échelle où la latence importe moins que le coût par token.

"Nous sommes passés d'environ 20 utilisateurs simultanés à plus de 200 sur le même matériel après être passés à vLLM. Le traitement par lots continu change véritablement la donne pour nos coûts d'inférence." - u/ml_infra_eng, Reddit r/LocalLLaMA, novembre 2023

"vLLM est ce qui propulse la majeure partie de la stack d'inférence de Together AI. PagedAttention a réduit à lui seul notre utilisation de la mémoire cache KV d'environ 55 % sur les requêtes à contexte long, là où nos marges étaient les plus compressées." - Tim Dettmers, équipe d'inférence, blog d'ingénierie de Together AI, février 2024

Où se situe vLLM par rapport à TGI et SGLang

Les trois moteurs d'inférence open source les plus déployés en 2026 sont vLLM, HuggingFace TGI et SGLang. Ils partagent les mêmes objectifs mais diffèrent mécaniquement sur des aspects cruciaux pour des charges de travail spécifiques.

vLLM vs TGI (Text Generation Inference) : HuggingFace TGI offre un point d'entrée plus simple, orienté Docker. Le déploiement standard se résume à une seule commande docker run avec un identifiant de modèle. TGI a ajouté la prise en charge de PagedAttention dans sa version v2 en 2024, réduisant ainsi l'écart de débit. Cependant, le traitement par lots continu de vLLM opère à une granularité plus fine : il insère de nouveaux tokens dans le lot actif à chaque étape de décodage, tandis que TGI traite par lots à un niveau plus grossier dans certaines configurations. Dans les benchmarks de la communauté sur Llama 3 70B avec une quantification 4 bits (r/LocalLLaMA, novembre 2024), vLLM atteint généralement un débit de tokens de sortie 15 à 25 % supérieur à celui de TGI sur des charges de travail à forte concurrence. L'avantage de TGI réside dans son intégration au HuggingFace Hub, un serveur basé sur Rust avec une surcharge Python moindre, et un processus de déploiement nécessitant moins de configuration. Pour les équipes déjà fortement ancrées dans l'écosystème HuggingFace, TGI est le premier choix naturel. Pour les équipes qui optimisent le débit brut à grande échelle, vLLM l'emporte généralement.

vLLM vs SGLang : SGLang, du groupe LMSYS, introduit RadixAttention : le partage du cache KV entre les requêtes qui partagent un préfixe commun. En pratique, cela signifie qu'un prompt système de 2 000 tokens utilisé par 1 000 utilisateurs simultanés est calculé et mis en cache une seule fois, et non 1 000 fois. Sur les charges de travail d'agents, les conversations à plusieurs tours et l'inférence par lots avec des préfixes partagés, RadixAttention de SGLang peut réduire le délai d'obtention du premier token (time-to-first-token) de 50 à 80 % par rapport à vLLM. vLLM a ajouté sa propre mise en cache de préfixes pour combler cet écart, mais l'implémentation de SGLang reste plus mature. Là où vLLM conserve un avantage clair : l'étendue de la prise en charge des modèles (des centaines contre une liste plus restreinte), les outils de parallélisme de pipelines multi-nœuds, la couverture des formats de quantification et la taille de la communauté d'opérations de production qui l'entoure. Pour les charges de travail d'IA basées sur des agents en particulier, SGLang est à considérer ; pour un service polyvalent avec une compatibilité maximale des modèles, vLLM reste la référence par défaut.

Un troisième concurrent, TensorRT-LLM de NVIDIA, compile les modèles en graphes CUDA optimisés et atteint un débit de pointe plus élevé sur le matériel NVIDIA. Le compromis est opérationnel : la compilation d'un modèle TensorRT-LLM prend 30 à 60 minutes par modèle et par type de GPU. vLLM charge un modèle depuis le disque en moins d'une minute. Pour les équipes exécutant de nombreux modèles ou itérant fréquemment, la simplicité opérationnelle de vLLM l'emporte de manière décisive. TensorRT-LLM ne vaut le coût de compilation que lorsqu'il s'agit de maximiser les tokens par seconde sur un modèle fixe à grande échelle. vLLM fonctionne également sur AMD ROCm, Intel Gaudi et AWS Trainium ; TensorRT-LLM est exclusif à NVIDIA.

À quoi ressemble la réalité du déploiement

Un déploiement de production typique implique de choisir une instance GPU (A10G pour les petits modèles, A100/H100 pour les modèles 70B+), d'installer vLLM via pip et d'exécuter la commande serve. Pour un modèle 70B sur 4x A100, la commande ajoute --tensor-parallel-size 4. Les poids du modèle sont téléchargés depuis le HuggingFace Hub lors de la première exécution, puis mis en cache localement. Le démarrage à froid (cold start) sur un modèle 70B prend 3 à 8 minutes selon la vitesse de stockage. Pour les services qui doivent pouvoir se mettre à l'échelle jusqu'à zéro (scale to zero), cette latence est une véritable contrainte.

Les déploiements multi-nœuds (parallélisme de pipelines sur plusieurs serveurs) nécessitent soit Ray, soit un backend distribué personnalisé. La configuration d'un cluster Ray est l'étape où la plupart des équipes signalent perdre des heures. La documentation de vLLM couvre ce point de manière adéquate, mais les modes de défaillance (configuration réseau, erreurs NCCL, confusion liée au tableau de bord Ray) ne sont pas bien documentés. Les ingénieurs qui y sont parvenus recommandent d'exécuter d'abord une configuration à un seul nœud, de valider le comportement du modèle, et de n'ajouter des nœuds qu'une fois la base de référence stable.

Pour les équipes qui souhaitent éviter complètement la gestion de l'infrastructure, des points de terminaison gérés basés sur vLLM sont disponibles sur Modal, Replicate et Together AI, chacun offrant la même API compatible avec OpenAI avec une tarification par token et aucune gestion de serveur. Le compromis concerne le coût et la résidence des données : l'auto-hébergement sur votre propre GPU est moins cher à grande échelle et permet de conserver les données sur site.

L'architecture v1 de janvier 2025 a apporté une structure interne plus propre, mais a également introduit quelques changements majeurs (breaking changes) dans l'enregistrement de modèles personnalisés. Les équipes exécutant des couches d'attention modifiées ou des architectures non standard ont rencontré des difficultés lors de la mise à niveau depuis la version v0.x. Les mainteneurs ont publié un guide de migration, mais les équipes ayant des déploiements fortement personnalisés ont passé des jours à déboguer. Cela dit, pour le service de modèles standard, la mise à niveau v1 a été universellement saluée par la communauté.

À qui s'adresse vLLM

vLLM est un logiciel d'infrastructure, et non un produit destiné aux utilisateurs finaux. Il est conçu pour les ingénieurs ML et les équipes de plateforme qui ont accès à du matériel GPU, sont à l'aise avec les environnements Python et Linux, et ont besoin de servir des modèles de langage open source à un débit qui justifie le coût de l'infrastructure.

Les cas d'usage les plus pertinents : une entreprise créant une API LLM privée pour un usage interne (les données restent sur site, aucune dépendance vis-à-vis d'un fournisseur) ; une équipe qui a trouvé les coûts d'inférence prohibitifs sur les API commerciales et souhaite plutôt exécuter un modèle affiné (fine-tuned) plus petit ; un laboratoire de recherche qui doit exécuter des inférences sur de grands lots de texte pour des expériences ; une startup construisant un produit basé sur des modèles open source où les marges exigent l'auto-hébergement.

Pour les équipes utilisant déjà des modèles open source localement via une interface graphique, associer vLLM à une interface de chat est simple. AnythingLLM et d'autres frontends similaires peuvent pointer vers un serveur vLLM local. Pour les utilisateurs qui souhaitent une expérience de modèle local clé en main sans configuration de serveur, Ollama est un meilleur point de départ. vLLM est le bon outil une fois que le débit et la concurrence deviennent la préoccupation principale, et non la facilité de la première exécution. Les équipes déployant à l'échelle commerciale avec des poids de modèles open source, comme celles qui exécutent peut-être déjà des modèles sur des architectures de la famille Llama, trouveront en vLLM l'option de production la plus mature.

Ce que vLLM n'est pas

vLLM ne fonctionne pas nativement sur Windows. Les utilisateurs doivent utiliser WSL2 ou Docker, ce qui ajoute des frictions pour le développement local. Ce n'est pas une application avec interface graphique, une interface de chat ou un outil de gestion de modèles dans le style de LM Studio. Il ne permet pas d'affiner (fine-tune) des modèles. Il ne fournit pas de limitation de débit (rate limiting), d'authentification ou de facturation intégrés : ceux-ci nécessitent une couche proxy telle que LiteLLM. Ce n'est pas un service géré ; il n'y a pas de "vLLM Cloud" proposé par le projet lui-même. Les équipes qui ont besoin d'une API d'inférence entièrement gérée sans responsabilité d'infrastructure devraient se tourner vers Replicate ou Together AI (qui exécute vLLM en interne). Pour les ingénieurs évaluant s'il faut s'auto-héberger ou utiliser une API gérée, vLLM fait pencher la balance vers l'auto-hébergement une fois que le trafic atteint une échelle où les coûts des instances GPU sont inférieurs aux frais d'API par token, généralement entre 1 et 10 millions de tokens par jour selon la taille du modèle et le fournisseur cloud.