Qu’est-ce que vLLM ? Un guide pratique sur ce moteur open source haute performance pour le déploiement de modèles de langage

vLLM est un moteur open source d’inférence et de déploiement dédié aux grands modèles de langage (LLM). Il charge un modèle sur un ou plusieurs GPU et l’expose via une API HTTP compatible OpenAI, en tirant parti de deux techniques clés — PagedAttention et traitement par lots continu — afin de traiter simultanément un grand nombre de requêtes avec un débit bien supérieur à celui obtenu avec des approches naïves. Il a été développé au Sky Computing Lab de l’université de Californie à Berkeley et publié en 2023.

Qu’est-ce que vLLM et pour qui est-il destiné ?

Envisagez vLLM comme la version « production » complémentaire des outils bureautiques tels qu’Ollama. Tous deux prennent un modèle en entrée et répondent aux requêtes, mais ils sont optimisés pour des objectifs opposés : Ollama privilégie la rapidité de réponse pour un seul utilisateur sur du matériel modeste, tandis que vLLM vise à débit: le nombre total de jetons générés par seconde, réparti sur des dizaines ou des centaines de requêtes simultanées adressées au même GPU.

Cela fait de vLLM l’outil idéal lorsque vous :

• Héberger un modèle de langage volumineux (LLM) derrière une API interne ou publique utilisée par plusieurs personnes ou services
• Exécuter des tâches par lots — classification, extraction, génération de données synthétiques — sur de grands ensembles de données
• Remplacer une API payante par un modèle open-weight auto-hébergé afin de réduire les coûts par jeton (le calculateur d’indifférence entre auto-hébergement et API vous aide à déterminer si la facture liée au GPU est effectivement inférieure à celle de l’API, compte tenu de votre volume d’utilisation)

Et l’outil inadapté si vous souhaitez un assistant conversationnel sur votre propre ordinateur portable, une inférence occasionnelle pour un seul utilisateur, ou toute autre utilisation sur une machine dépourvue d’un GPU puissant. vLLM suppose un environnement serveur : Linux, un GPU NVIDIA comme chemin par défaut (des backends AMD ROCm, Intel, TPU et CPU existent, mais sont moins courants), ainsi qu’une charge de travail impliquant de la concurrence.

Lors de son lancement en 2023, les benchmarks de vLLM ont montré un débit jusqu’à 24 fois supérieur à celui obtenu avec la simple bibliothèque Hugging Face Transformers, et environ 2 à 3,5 fois supérieur à celui des systèmes de service disponibles à l’époque. Les chiffres exacts varient selon le modèle, le matériel et la charge de travail — toutefois, comprendre la raison de cet écart est essentiel, car elle indique précisément dans quels cas vLLM apporte une réelle valeur ajoutée.

PagedAttention, expliqué simplement

Lorsqu’un LLM génère du texte, il conserve une Cache KV dans la mémoire GPU : les clés et valeurs d’attention pour chaque jeton de chaque conversation active. Ce cache augmente à chaque jeton généré et, pour des contextes longs, peut consommer davantage de VRAM que les poids du modèle lui-même.

Avant vLLM, les moteurs de service allouaient à chaque requête un bloc contigu de mémoire dimensionné pour la longueur maximale possible de séquence, car ils ne pouvaient pas connaître à l’avance la longueur finale de la sortie. La plupart des requêtes se terminent bien avant cette longueur maximale, laissant donc la majeure partie de cette mémoire réservée inutilisée. Le document fondateur de vLLM a mesuré un gaspillage de mémoire du cache KV compris entre 60 % et 80 % dans les systèmes antérieurs, dû à ce type de fragmentation.

PagedAttention s’inspire de la solution mise en œuvre par les systèmes d’exploitation : la pagination de la mémoire virtuelle. Le cache KV est divisé en petits blocs de taille fixe (16 jetons par défaut), alloués à la demande et sans besoin d’être contigus. Une table de blocs associe chaque position logique d’une séquence aux blocs physiques libres disponibles — exactement comme un système d’exploitation mappe des pages virtuelles vers de la RAM physique. Le gaspillage mémoire tombe alors sous la barre des 4 %, et les blocs peuvent même être partagés entre plusieurs séquences (ce qui est utile lorsqu’on génère plusieurs complétions à partir d’un même prompt).

Conséquence pratique : un nombre bien plus élevé de séquences simultanées peut tenir dans la même VRAM. Plus il y a de séquences en mémoire, plus la taille effective des lots augmente, et des lots plus importants sont ce qui maintient le GPU pleinement occupé. C’est là toute l’histoire du débit — PagedAttention ne rend aucune requête individuelle plus rapide ; elle permet simplement d’exécuter beaucoup plus de requêtes simultanément.

Traitement par lots continu

La deuxième technique cible la planification plutôt que la gestion mémoire. Le regroupement naïf (« batching ») rassemble des requêtes, exécute l’intégralité du lot jusqu’à son achèvement, puis passe au lot suivant — ainsi, une requête qui se termine après 20 jetons doit attendre celle qui en génère 2 000, tandis que les nouvelles requêtes s’accumulent en file d’attente à l’extérieur. Traitement par lots continu (également appelée planification au niveau des itérations) reforme le lot à chaque étape de génération : les séquences achevées sortent immédiatement, et les requêtes en attente rejoignent immédiatement le lot actif.

Le GPU reste saturé, les requêtes courtes ne sont pas retenues en otage par les requêtes longues, et la latence sous charge s’améliore parallèlement au débit. PagedAttention et le « continuous batching » se renforcent mutuellement : le premier permet de faire tenir davantage de séquences en mémoire, le second garantit que cette capacité est effectivement exploitée.

Installation de vLLM : les contraintes qui posent problème

L’installation ne nécessite qu’une seule commande, mais trois contraintes sont à l’origine de la plupart des échecs d’installation :

1. Version de Python. Les versions récentes ciblent approximativement la fourchette Python 3.9–3.12, et cette plage supportée évolue d’une version à l’autre. Si pip signale qu’aucune distribution correspondante n’a été trouvée, la version de Python est le premier suspect.
2. Version de CUDA. Les paquets précompilés sont construits contre une version majeure spécifique de CUDA (CUDA 12.x pour les versions actuelles). Vous devez disposer d’un pilote NVIDIA récent ; des paquets compatibles avec d’autres versions de CUDA existent pour certaines versions, via des URL d’index spéciales documentées dans la documentation officielle de vLLM.
3. Conflits avec PyTorch. vLLM verrouille sa propre version de PyTorch. L’installer dans un environnement où une version différente de Torch est déjà présente constitue la cause classique d’erreurs d’importation obscures. Utilisez toujours un environnement virtuel vierge.

Sur le plan matériel, la voie principale exige un GPU NVIDIA doté d’une capacité de calcul 7.0 ou supérieure — V100, T4, série RTX 20 et versions ultérieures. Si vous choisissez du matériel, consultez le guide sur les meilleurs GPU pour exécuter localement des LLM.

Linux (plateforme prise en charge)

python3 -m venv vllm-env
source vllm-env/bin/activate
pip install vllm

La documentation de vLLM recommande également uv (uv venv puis uv pip install vllm), qui résout plus rapidement les dépendances verrouillées. Dans tous les cas, l’objectif est d’utiliser un environnement propre.

Windows : utilisez WSL2 ou Docker

Aucune version native Windows n’est disponible. Les configurations fonctionnelles sont WSL2 avec une distribution Ubuntu (le pilote NVIDIA pour Windows transmet CUDA à WSL2, donc les instructions Linux ci-dessus fonctionnent parfaitement à l’intérieur de WSL2) ou Docker Desktop avec le support GPU activé, en utilisant l’image officielle :

docker run --gpus all -p 8000:8000 vllm/vllm-openai --model Qwen/Qwen2.5-7B-Instruct

macOS : pas l’outil adapté

vLLM ne dispose pas de backend Metal/Apple GPU. Une version expérimentale pour CPU peut être compilée depuis les sources, mais cela va à l’encontre de l’objectif d’un moteur optimisé pour le débit. Sur Mac, privilégiez plutôt LM Studio llama.cpp

Lancement d’un serveur : vllm serve

Une seule commande lance un serveur d’inférence (le modèle est téléchargé depuis Hugging Face lors de la première exécution) :

vllm serve Qwen/Qwen2.5-7B-Instruct

Cela met le modèle à disposition sur le port 8000. Voici les options que vous utiliserez le plus fréquemment :

Notez que vLLM pré-alloue la majeure partie de la mémoire GPU par conception — un affichage indiquant une occupation quasi complète de la VRAM est normal et ne signifie pas une fuite mémoire. Avant de choisir un modèle, vérifiez que les poids combinés à la mémoire cache KV tiennent dans la mémoire de votre carte graphique à l’aide du Calculateur de VRAM; en première approximation, les poids en FP16 nécessitent environ 2 Go par milliard de paramètres, ceux en 8 bits environ la moitié, auxquels il faut ajouter une marge pour la mémoire cache.

L’API compatible OpenAI

Le serveur implémente l’interface API OpenAI : /v1/chat/completions, /v1/completions, /v1/models, et /v1/embeddings (pour les modèles d’embedding). Tout outil développé avec le SDK OpenAI fonctionne sans modification, à condition de changer l’URL de base :

curl http://localhost:8000/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{
    "model": "Qwen/Qwen2.5-7B-Instruct",
    "messages": [{"role": "user", "content": "Expliquez PagedAttention en une phrase."}]
  }'

En Python, OpenAI(base_url="http://localhost:8000/v1", api_key="none") constitue l’intégralité de la migration. Cette compatibilité représente une part importante de l’adoption de vLLM : les outils existants, agents et frameworks fonctionnent sans modification.

Quand Ollama ou llama.cpp constituent un meilleur choix

Choisir Ollama lorsque le nombre d’utilisateurs est limité à un seul et que le matériel utilisé est un ordinateur portable ou de bureau — son installation se fait via un seul programme d’installation, et il exécute confortablement des modèles quantifiés au format GGUF sur CPU et Apple Silicon (voir le Guide complet d’Ollama). Choisissez llama.cpp directement lorsque vous avez besoin d’une portabilité maximale ou souhaitez intégrer l’inférence directement dans une autre application. Choisissez vLLM lorsque les requêtes arrivent simultanément et que la métrique clé est le nombre de jetons générés par seconde et par dollar dépensé. Une charge de travail mono-utilisateur tire peu profit de PagedAttention ; en revanche, une charge de travail impliquant 50 utilisateurs en bénéficie énormément.

Questions fréquemment posées

vLLM est-il gratuit ?

Oui. vLLM est un logiciel open source publié sous la licence Apache 2.0, initialement développé à l’université de Californie à Berkeley, puis maintenu aujourd’hui comme projet communautaire sous l’égide de la PyTorch Foundation. Il n’existe aucune version payante ; vos coûts se limitent au matériel et à la consommation électrique.

vLLM peut-il exécuter des modèles GGUF comme Ollama ?

Le support des modèles GGUF existe, mais il reste expérimental et ne constitue pas la voie principale recommandée. vLLM repose essentiellement sur les points de contrôle standard de Hugging Face (safetensors), avec des versions quantifiées au format AWQ, GPTQ ou FP8. Si vos modèles ne sont disponibles qu’au format GGUF, Ollama ou llama.cpp constituent des solutions plus adaptées.

vLLM fonctionne-t-il sans GPU NVIDIA ?

Des backends existent pour AMD ROCm, le matériel Intel, les Google TPUs, les AWS Neuron et même les CPU, mais la pile CUDA pour NVIDIA demeure de loin la plus mature et la mieux documentée. vLLM fonctionne en mode CPU uniquement pour des tests, mais ne convient pas au service haute performance pour lequel il a été conçu.

De combien de VRAM vLLM a-t-il besoin ?

Assez pour accueillir les poids du modèle ainsi que la mémoire cache KV : environ 2 Go par milliard de paramètres en FP16, soit environ la moitié en 8 bits, plus une marge pour la mémoire cache, qui augmente avec la longueur du contexte et le niveau de concurrence. Un modèle de 7 milliards de paramètres en FP16 tient aisément sur une carte de 24 Go ; un modèle de 70 milliards nécessite plusieurs GPU ou une quantification très agressive. La référence exigences en VRAM par modèle fournit des valeurs précises pour chaque modèle.

Comment vLLM se compare-t-il à TensorRT-LLM, SGLang ou TGI ?

Ils appartiennent à la même catégorie — moteurs d’inférence destinés à la production. vLLM offre généralement la prise en charge la plus étendue des modèles, la configuration la plus simple et la communauté la plus importante ; TensorRT-LLM peut tirer davantage de performances maximales du matériel NVIDIA, mais au prix d’un processus de compilation et d’ajustement plus complexe ; SGLang est un concurrent sérieux, notamment pour la génération de sorties structurées. Effectuez des benchmarks sur votre propre modèle et votre charge de travail avant de faire un choix définitif — les classements évoluent d’une version à l’autre.

Puis-je affiner des modèles avec vLLM ?

Non — vLLM est dédié exclusivement à l’inférence. Il est souvent utilisé comme moteur de génération rapide au sein de cadres d’entraînement RLHF, mais l’entraînement lui-même s’effectue ailleurs. Pour affiner vos modèles, utilisez des outils tels que Hugging Face TRL, Axolotl ou Unsloth, puis déployez le point de contrôle obtenu avec vLLM.