Installer vLLM se résume à deux commandes. pip install vllm, une commande vllm serve, et un modèle open-source répond sur un port local en quelques secondes. Le vrai travail commence après, quand les premiers utilisateurs interrogent le serveur en même temps et que les temps de réponse explosent. La plupart des équipes qui essaient de faire tourner un LLM en interne butent exactement là : le POC marche, la production s'écroule dès que la charge dépasse un seul utilisateur à la fois.
vLLM a été construit pour résoudre précisément ce problème : servir un modèle à de nombreux utilisateurs simultanés sans multiplier le nombre de cartes GPU. Ce tutoriel couvre l'installation, les réglages qui évitent les plantages en production, et le moment où un seul serveur ne suffit plus.
Le piège du serveur qui tient à un utilisateur près
La méthode naïve pour servir un LLM consiste à charger le modèle avec la bibliothèque Hugging Face Transformers et à répondre aux requêtes une par une, ou par petits lots figés. Ça fonctionne très bien en démo. Ça s'effondre dès qu'un deuxième utilisateur envoie une requête pendant que le premier attend encore sa réponse : le serveur traite les requêtes en série, ou alloue un bloc de mémoire GPU fixe par requête, gaspillant une grande partie de la VRAM disponible.
Sur les projets d'infrastructure IA que nous mettons en place chez des clients (RAG interne, agents vocaux hébergés en France), ce plafond apparaît toujours au même moment : dès qu'une poignée d'utilisateurs interrogent le serveur en même temps, bien avant que le GPU soit à court de calcul brut. Le goulot n'est pas la puissance de la carte, c'est la gestion de la mémoire du cache KV, les représentations internes que le modèle garde en mémoire pour chaque conversation en cours. Une architecture de service naïve réserve ce cache par blocs contigus et surdimensionnés ; dès que plusieurs conversations tournent en parallèle, la fragmentation mémoire fait chuter le nombre de requêtes qu'un seul GPU peut encaisser.
C'est le problème que vLLM a été conçu pour résoudre depuis son lancement par le Sky Computing Lab de l'université de Californie à Berkeley. Le projet introduit PagedAttention, un mécanisme de gestion mémoire inspiré de la pagination des systèmes d'exploitation, combiné à du batching continu : les requêtes entrent et sortent du lot traité par le GPU au fil de l'eau, sans attendre que tout le lot se termine.
Ce que PagedAttention change concrètement
Sur les benchmarks publiés au lancement du projet, vLLM affiche jusqu'à 24 fois plus de débit que Hugging Face Transformers et jusqu'à 3,5 fois plus que Text Generation Inference (TGI), qui faisait référence à l'époque, sur des tests menés avec LLaMA-7B sur une carte A10G et LLaMA-13B sur une A100 40 Go. Le billet de lancement de vLLM détaille ces chiffres : sur des requêtes uniques, le gain va de 14 à 24 fois par rapport à Transformers, et de 2,2 à 2,5 fois par rapport à TGI ; sur des requêtes multiples, l'écart avec TGI grimpe à 3,3-3,5 fois.
Le mécanisme derrière ces chiffres est simple à décrire : au lieu de réserver un bloc de mémoire contigu et surdimensionné pour chaque conversation, PagedAttention découpe le cache KV en petites pages, allouées à la demande et libérées dès qu'elles ne servent plus.
Selon la même source, cette approche ramène le gaspillage mémoire sous les 4 %, contre 60 à 80 % perdus par fragmentation sur les systèmes de serving classiques. Concrètement, davantage de conversations tiennent dans la même carte, sans changer une ligne du modèle.
Le batching continu apporte le second gain : sur un serveur classique, un lot de requêtes attend que la plus longue conversation se termine avant de libérer de la place pour la suivante. vLLM traite chaque requête indépendamment à chaque étape de génération, insère les nouvelles requêtes dès qu'une place se libère, et ne laisse jamais le GPU tourner à vide en attendant une conversation lente.
La documentation officielle du projet recense aussi une dizaine de formats de quantization pris en charge nativement : AWQ, GPTQ, FP8, GGUF, BitsAndBytes, NVIDIA Model Optimizer ou AMD Quark, selon le tableau de compatibilité matériel du dépôt GitHub. Réduire la précision d'un modèle de 16 à 8 ou 4 bits divise la VRAM nécessaire d'autant, au prix d'une perte de qualité qui reste souvent négligeable sur des tâches métier bien cadrées.
Installer vLLM et lancer un premier serveur
Les prérequis réels : une carte GPU récente (une A10, une L4, ou mieux selon le modèle visé), les pilotes CUDA à jour côté NVIDIA, et Python 3.10 ou supérieur. vLLM prend en charge un éventail large de matériel au-delà de NVIDIA, avec AMD, TPU Google, Intel Gaudi ou Apple Silicon selon le dépôt GitHub du projet, mais NVIDIA reste la plateforme la plus mature et la plus documentée.
L'installation tient en une ligne :
pip install vllmLancer un serveur compatible avec l'API OpenAI, avec un modèle Hugging Face au choix (ici Mistral 7B Instruct), prend une seule commande :
vllm serve mistralai/Mistral-7B-Instruct-v0.3 --port 8000Le serveur télécharge le modèle depuis le Hub Hugging Face au premier lancement, puis expose un point d'entrée compatible avec le format de l'API OpenAI. N'importe quel client déjà écrit pour /v1/chat/completions fonctionne sans modification, il suffit de changer l'URL de base :
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "mistralai/Mistral-7B-Instruct-v0.3",
"messages": [{"role": "user", "content": "Résume ce texte en 3 phrases."}]
}'Cette compatibilité API OpenAI est ce qui rend vLLM simple à brancher derrière un gateway LLM compatible OpenAI comme LiteLLM ou Portkey : le reste de votre stack applicative continue de parler le même protocole, que la requête parte vers GPT-4o ou vers un modèle hébergé en interne.
Pour du développement local sans carte GPU dédiée ou pour tester un modèle avant de le déployer, Ollama reste plus simple à installer. vLLM cible un usage différent : servir de vrais volumes de requêtes en production, pas itérer sur un poste de développeur.
Les réglages qui évitent l'OOM en production
La commande vllm serve par défaut tourne, mais rarement de façon optimale. Trois réglages font la différence entre un serveur stable et un serveur qui plante sous charge.
--gpu-memory-utilization fixe la part de VRAM que vLLM peut réserver pour le cache KV, entre 0 et 1, avec une valeur par défaut de 0,92 dans le code source du projet. Le régler trop haut sur une machine partagée avec d'autres processus provoque des erreurs de mémoire insuffisante (OOM) au pire moment, en pleine charge. Le régler trop bas gaspille de la capacité de traitement parallèle. Sur une carte dédiée exclusivement au serveur vLLM, la valeur par défaut reste un bon point de départ.
--max-num-seqs plafonne le nombre de requêtes traitées en parallèle. Sans limite explicite, vLLM accepte des requêtes jusqu'à saturer la mémoire disponible, ce qui peut dégrader la latence de toutes les conversations en cours plutôt que de refuser proprement les nouvelles requêtes. Fixer une valeur explicite, testée avec l'outil de benchmark fourni par le projet, évite cette dégradation difficile à repérer avant qu'elle n'affecte tous les utilisateurs.
--tensor-parallel-size répartit un modèle trop volumineux pour une seule carte sur plusieurs GPU. Un modèle de 70 milliards de paramètres en précision FP16 nécessite environ 140 Go de VRAM rien que pour les poids (2 octets par paramètre), largement au-delà de ce qu'une carte grand public ou même une A100 80 Go encaisse seule. Passer ce paramètre à 2 ou 4 répartit la charge sur autant de cartes, au prix d'une communication réseau entre GPU qui devient elle-même un facteur de latence à surveiller.
Le piège le plus fréquent qu'on retrouve sur les déploiements clients : lancer vLLM avec les valeurs par défaut sur un environnement partagé, sans avoir mesuré le trafic réel attendu. La documentation du projet ne le formule pas ainsi, mais dans les faits, le dimensionnement mémoire correct demande presque toujours un cycle de benchmark avant mise en production, pas une simple lecture de la doc.
Dimensionner correctement un serveur vLLM demande de connaître à la fois le modèle, le trafic attendu et les contraintes de conformité (RGPD, hébergement en France). C'est le type de chantier que notre agence spécialisée en agents IA sur mesure cadre régulièrement pour des clients qui veulent sortir du POC sans se tromper de dimensionnement, avec du développement sur mesure quand l'intégration dépasse la simple configuration d'un serveur.
Passer à plusieurs GPU : llm-d et l'inférence distribuée
Un seul serveur vLLM, même bien réglé, plafonne au débit d'une machine. Pour des volumes qui dépassent la capacité d'une carte ou d'un nœud, la communauté vLLM a construit llm-d, un framework natif Kubernetes qui distribue l'inférence sur plusieurs pods au lieu d'un seul GPU. Lancé le 20 mai 2025 lors du Red Hat Summit avec CoreWeave, Google Cloud, IBM Research et NVIDIA comme contributeurs fondateurs, comme le détaille l'annonce officielle de Red Hat, le projet a ensuite été rejoint par AMD, Cisco, Hugging Face, Intel, Lambda et Mistral AI, avant d'être donné à la Cloud Native Computing Foundation comme projet sandbox le 24 mars 2026 lors de KubeCon Europe, selon le billet d'IBM Research.
llm-d sépare les deux phases du calcul d'inférence, le préremplissage du contexte et la génération token par token, et les fait tourner sur des pods différents pour dimensionner chaque phase indépendamment. Une passerelle route chaque requête selon l'état du cache KV, la charge des pods et le matériel disponible, plutôt que de répartir le trafic au hasard entre serveurs.
Cette architecture répond à un mouvement de fond plus large : d'ici 2028, plus de 80 % des accélérateurs de data center serviront l'inférence plutôt que l'entraînement de nouveaux modèles, selon les prévisions Gartner citées par Red Hat dans cette même annonce. Autrement dit, la charge de travail qui va peser sur l'infrastructure IA des entreprises dans les prochaines années, c'est majoritairement du service de modèles déjà entraînés, pas de l'entraînement.
Pour une PME ou une ETI, ce passage à l'échelle distribuée n'est presque jamais la première étape. Un seul serveur vLLM bien dimensionné, avec de la quantization si besoin, couvre la grande majorité des usages internes (RAG documentaire, assistant support, agents vocaux) tant que le trafic reste concentré sur une seule équipe ou un seul cas d'usage. llm-d prend son sens quand le trafic dépasse ce qu'un nœud encaisse, ou quand la haute disponibilité devient une exigence contractuelle.
vLLM, Ollama, TGI : ce qu'on utilise vraiment selon le contexte
Aucun de ces outils ne remplace les deux autres. Ollama cible le poste de développeur ou le petit usage interne : installation en une commande, gestion de modèles quantifiés prête à l'emploi, pas de réglage fin nécessaire. C'est l'outil qu'on recommande pour prototyper un cas d'usage avant de décider s'il mérite un vrai déploiement, comme détaillé dans notre guide sur Ollama en local.
Text Generation Inference, porté par Hugging Face, vise le même segment que vLLM : servir des modèles en production à fort débit. Les deux projets ont largement convergé sur les mêmes techniques (batching continu, quantization, cache paginé), et le choix entre les deux tient surtout à l'infrastructure déjà en place dans l'équipe : TGI s'intègre naturellement si vous êtes déjà sur l'infrastructure Hugging Face Inference Endpoints, vLLM s'impose comme le choix par défaut pour une infrastructure autogérée grâce à sa communauté plus large et son intégration native avec l'écosystème Kubernetes via llm-d.
Sur les projets où on met en place une infrastructure IA hébergée en France pour des raisons réglementaires, vLLM revient systématiquement comme brique de service, précisément parce qu'il s'intègre sans friction derrière un gateway compatible OpenAI et qu'il tourne aussi bien sur du matériel européen que sur les grands clouds américains. C'est un des points qu'on développe dans notre article sur la mise en place d'une infrastructure IA en entreprise.
Le bon critère de choix, c'est le volume de requêtes concurrentes que votre cas d'usage doit vraiment tenir, pas le benchmark le plus flatteur sur GitHub. En dessous de quelques utilisateurs simultanés, Ollama suffit. Au-delà, et dès que la production devient une contrainte réelle (SLA, pic de charge, plusieurs équipes qui consomment le même modèle), vLLM devient le choix par défaut.
Questions fréquentes sur vLLM en production
Combien de VRAM faut-il pour lancer vLLM en production ?
Ça dépend entièrement de la taille du modèle et de la quantization choisie. Un modèle de 7 milliards de paramètres en FP16 tient sur une carte de 16 Go de VRAM avec de la marge pour le cache KV. Un modèle de 70 milliards demande environ 140 Go rien que pour les poids, donc plusieurs GPU via --tensor-parallel-size, ou une quantization agressive en 4 bits pour tenir sur une seule carte.
vLLM fonctionne-t-il sans carte GPU NVIDIA ?
Oui. Le projet prend en charge les GPU AMD, les TPU Google, les puces Intel Gaudi, les processeurs x86 et Arm, et le silicium Apple, selon la liste officielle des backends matériels du dépôt GitHub. En pratique, la plateforme NVIDIA reste la plus documentée et la plus testée en production, les autres backends demandent davantage de tests avant un déploiement critique.
Quelle différence entre vLLM et un simple appel à l'API OpenAI ?
Passer par l'API OpenAI évite toute infrastructure à gérer, mais par défaut vos données transitent par des serveurs hors de France (une option de résidence des données en Europe existe, réservée aux clients éligibles) et le coût grimpe avec le volume. vLLM héberge le modèle sur votre propre infrastructure : les données ne sortent pas, le coût marginal devient quasi nul une fois le GPU amorti, mais vous devenez responsable du serveur, de sa disponibilité et de ses mises à jour.
Faut-il un cluster Kubernetes pour utiliser vLLM ?
Non, pas pour démarrer. Un seul serveur vLLM sur une machine avec GPU suffit pour la grande majorité des usages internes. Kubernetes et des frameworks comme llm-d n'entrent en jeu que lorsque le trafic dépasse la capacité d'un seul nœud ou que la haute disponibilité devient contractuelle.
Quelle quantization choisir pour ne pas dégrader la qualité des réponses ?
AWQ et GPTQ en 4 bits offrent le meilleur compromis pour la plupart des usages métier : la perte de qualité reste peu perceptible sur des tâches de résumé, classification ou question-réponse cadrées. FP8 convient mieux quand la précision compte davantage, au prix d'une VRAM économisée moindre. Le seul moyen fiable de trancher reste de tester la quantization visée sur vos propres cas d'usage, pas sur un benchmark générique.
