Points clés
- Gratuit et open source sous licence Apache 2.0, né au Sky Computing Lab de l'UC Berkeley
- PagedAttention gère le cache KV en blocs non contigus de taille fixe pour réduire le gaspillage de mémoire GPU
- Le batching continu traite de nombreuses requêtes simultanées au lieu d'un lot fixe à la fois
- Embarque un serveur d'API compatible OpenAI, lancé avec la commande
vllm serve - Prend en charge des formats de quantification comme AWQ, GPTQ et FP8
- Prend en charge le service multi-GPU en parallélisme tensoriel et en pipeline
- Le matériel principal et le mieux pris en charge est le GPU NVIDIA ; des backends AMD, Intel et autres existent mais avec une couverture plus étroite
- Ce n'est pas une application de bureau mono-utilisateur — pas d'installateur graphique, et pas conçu pour le CPU seul ou Apple Silicon comme llama.cpp et Ollama
📍 En une phrase
vLLM est une bibliothèque gratuite, sous licence Apache 2.0, née au Sky Computing Lab de l'UC Berkeley, qui utilise PagedAttention et le batching continu pour servir efficacement de nombreuses requêtes LLM simultanées depuis un GPU, et embarque un serveur d'API compatible OpenAI intégré.
💬 En termes simples
Au lieu d'une application de chat de bureau, vLLM est un logiciel serveur : on le pointe vers un modèle et il expose une API que de nombreuses personnes ou applications peuvent appeler en même temps, en utilisant la mémoire GPU plus efficacement qu'une configuration simple traitant une requête à la fois.
📌Remarque: Cet article s'appuie sur le dépôt GitHub officiel de vLLM et sa documentation publique, pas sur des benchmarks indépendants. Les chiffres précis de débit ou de latence sont volontairement absents car ils n'ont pas été mesurés indépendamment pour cet article et varient fortement selon le GPU, le modèle, la taille de lot et la version de vLLM.
Qu'est-ce que vLLM ?
vLLM est une bibliothèque et un serveur gratuits, sous licence Apache 2.0, pour exécuter l'inférence de grands modèles de langage à grande échelle. Le projet est né comme projet de recherche au Sky Computing Lab de l'UC Berkeley et est depuis devenu l'un des moteurs de service LLM open source les plus utilisés, avec des contributions de milliers de développeurs issus du monde académique et industriel. Contrairement aux outils conçus principalement pour un utilisateur unique discutant avec un modèle sur sa propre machine, vLLM est conçu pour servir de nombreuses requêtes simultanées — de plusieurs utilisateurs ou applications — aussi efficacement que possible à partir d'une capacité GPU partagée.
- Né au Sky Computing Lab de l'UC Berkeley, aujourd'hui un projet open source gouverné par la communauté
- Sous licence Apache 2.0 : le code source est publiquement disponible pour utilisation, modification et redistribution selon les termes de la licence
- Charge les modèles au format compatible Hugging Face Transformers, offrant une large couverture d'architectures — Llama, Mistral, Qwen, DeepSeek et bien d'autres familles de modèles — sans étape de conversion séparée pour la plupart des modèles
- Conçu pour servir efficacement de nombreuses requêtes simultanées, pas seulement pour exécuter rapidement une seule conversation
- L'un des projets de service LLM open source les plus référencés sur GitHub
Qu'est-ce que PagedAttention, et pourquoi est-ce important ?
PagedAttention est la technique de gestion mémoire pour laquelle vLLM est le plus connu. Pendant la génération, un modèle transformeur stocke un cache d'attention clé-valeur (KV) pour chaque token de chaque requête active — normalement, ce cache est alloué comme un seul grand bloc contigu par requête, dimensionné pour la longueur maximale possible de la requête, ce qui gaspille de la mémoire GPU dès qu'une requête se termine plus tôt ou est plus courte que le maximum réservé. PagedAttention découpe plutôt le cache KV en petits blocs de taille fixe (pages) pouvant être alloués de façon non contiguë et partagés entre requêtes, en empruntant une idée à la gestion de la mémoire virtuelle des systèmes d'exploitation.
- Réduit le gaspillage de mémoire dû à la sur-réservation d'espace de cache KV pour des requêtes finalement plus courtes que leur longueur maximale
- Permet de partager des blocs de mémoire entre requêtes ayant un préfixe commun, comme le même prompt système
- Permet au GPU de conserver le cache KV de davantage de requêtes simultanées dans la même quantité de mémoire qu'avec une allocation contiguë naïve
- Fonctionne avec le batching continu, qui permet à vLLM d'ajouter et de retirer des requêtes d'un lot en cours d'exécution au fur et à mesure de leur arrivée et de leur achèvement, plutôt que d'attendre la fin complète d'un lot fixe avant de démarrer le suivant
De quel matériel vLLM a-t-il besoin ?
La cible principale et la mieux prise en charge de vLLM est le GPU NVIDIA avec CUDA, et la plupart des déploiements en production tournent sur du matériel NVIDIA. Le projet documente aussi des backends supplémentaires, mais la couverture et la performance n'y sont pas égales.
GPU NVIDIA (CUDA)
- Détails:
- La cible principale, la plus mature. Le service en parallélisme tensoriel et en pipeline sur plusieurs GPU NVIDIA est bien documenté et largement utilisé en production.
GPU AMD (ROCm)
- Détails:
- Documenté comme backend pris en charge pour le matériel AMD via ROCm, avec une adoption réelle et une couverture communautaire plus étroites que le chemin CUDA.
GPU Intel et accélérateurs Gaudi
- Détails:
- Backends supplémentaires documentés par le projet pour le matériel Intel ; à considérer comme un chemin de déploiement plus restreint et moins éprouvé que les GPU NVIDIA.
TPU Google
- Détails:
- Un backend documenté pour le matériel TPU de Google Cloud, destiné aux équipes déjà sur cette infrastructure.
CPU (x86 / ARM / PowerPC)
- Détails:
- Un backend CPU seul existe, mais ce n'est pas l'usage ciblé par vLLM — le projet est conçu pour le service GPU, et l'exécution CPU est documentée comme nettement plus lente que les backends GPU.
Apple Silicon (Mac)
- Détails:
- Pas un chemin officiel de premier plan. Des projets maintenus par la communauté (comme un plugin de backend Metal) ajoutent un support partiel d'Apple Silicon, mais couverture et maturité restent très en retrait par rapport au support GPU NVIDIA de vLLM.
Si l'objectif est d'exécuter un modèle sur un seul Mac ou une machine CPU seule, vLLM n'est pas l'outil conçu pour cela — llama.cpp et les outils construits dessus, comme Ollama et LM Studio, ciblent directement le CPU et le matériel Apple Silicon et conviennent mieux à ce scénario.
Quels formats de quantification vLLM prend-il en charge ?
vLLM prend en charge le service de modèles à précision numérique réduite pour diminuer l'usage mémoire et, dans de nombreux cas, augmenter le débit, en utilisant plusieurs formats de quantification établis plutôt qu'un seul format propriétaire.
AWQ
- Détails:
- Activation-aware Weight Quantization, une méthode de quantification des poids en 4 bits largement utilisée, avec des modèles pré-quantifiés publiés par la communauté sur Hugging Face.
GPTQ
- Détails:
- Une méthode de quantification post-entraînement couramment distribuée sous forme de checkpoints de modèles pré-quantifiés, également typiquement en précision 4 bits.
FP8
- Détails:
- Précision en virgule flottante 8 bits, prise en charge sur les générations de GPU NVIDIA récentes disposant d'un support matériel FP8 — moins de précision contre un usage mémoire réduit et une exécution plus rapide que FP16/BF16.
INT8 / INT4
- Détails:
- Chemins de quantification entière à précision réduite documentés par le projet aux côtés d'AWQ et GPTQ pour une réduction mémoire supplémentaire.
Cet article n'inclut pas de chiffres de perte de qualité mesurés indépendamment pour chaque format — ceux-ci varient selon l'architecture du modèle et la tâche. Comparer les sorties de plusieurs formats sur vos propres prompts reste la façon la plus fiable de juger du compromis pour votre usage.
Que fournit le serveur compatible OpenAI de vLLM ?
Exécuter vllm serve démarre un serveur HTTP qui implémente le protocole de l'API OpenAI, si bien que les applications et SDK déjà construits sur l'API OpenAI peuvent souvent pointer vers une instance vLLM auto-hébergée en ne changeant que l'URL de base et le nom du modèle.
- Points de terminaison compatibles OpenAI pour les chat completions et completions, utilisables comme remplacement direct de code client basé sur l'API OpenAI
- Hôte et port configurables (le serveur écoute par défaut sur
http://localhost:8000) - Options moteur pour la taille du parallélisme tensoriel, la cible d'utilisation mémoire GPU et le format de quantification, définies au démarrage du serveur
- Prise en charge du service de plusieurs adaptateurs LoRA sur un même modèle de base chargé
- Prise en charge des sorties structurées et de l'appel de fonctions/outils pour les formats de requête compatibles
Comment installer et exécuter vLLM ?
vLLM est distribué comme paquet Python et s'installe généralement avec pip dans un environnement Python disposant d'un GPU NVIDIA et de pilotes CUDA compatibles.
- 1Vérifier que vous disposez d'un GPU NVIDIA pris en charge avec des pilotes CUDA à jour (ou consulter la documentation du projet pour des instructions d'installation spécifiques AMD/Intel/TPU si vous ciblez l'un de ces backends).
- 2Créer un environnement virtuel Python, puis installer vLLM :
pip install vllm. - 3Démarrer le serveur compatible OpenAI avec un modèle de Hugging Face, par exemple :
vllm serve meta-llama/Llama-3.1-8B-Instruct. - 4Pour un modèle pré-quantifié, passer l'option correspondante, par exemple :
vllm serve TheBloke/Llama-2-13B-AWQ --quantization awq. - 5Pour un service multi-GPU, ajouter une option de parallélisme tensoriel, par exemple :
vllm serve <model> --tensor-parallel-size 2pour répartir le modèle sur deux GPU. - 6Par défaut, le serveur écoute sur
http://localhost:8000; envoyer une requête à son point de terminaison/v1/chat/completionsavec n'importe quelle bibliothèque cliente compatible OpenAI, oucurl. - 7Pointer le code client OpenAI existant vers votre serveur auto-hébergé en ne changeant que l'URL de base et le nom du modèle.
Ai-je besoin d'un GPU pour exécuter vLLM ?
Pour tout usage au-delà d'un simple test, oui — la cible principale et la mieux prise en charge de vLLM est le GPU NVIDIA. Un backend CPU seul existe mais est documenté comme nettement plus lent et n'est pas le focus du projet.
Puis-je exécuter vLLM avec un modèle quantifié ?
Oui — vLLM prend en charge des formats comme AWQ, GPTQ et FP8, et de nombreux modèles pré-quantifiés dans ces formats sont publiés sur Hugging Face et peuvent être servis avec l'option --quantization correspondante.
Comment vLLM se compare-t-il à Ollama et LM Studio ?
Ollama et LM Studio ciblent un problème différent de celui de vLLM : donner rapidement et simplement à une personne un modèle avec lequel discuter sur sa propre machine. vLLM vise à servir de nombreux utilisateurs ou applications simultanés aussi efficacement que possible à partir d'une capacité GPU partagée. Ces deux catégories d'outils ne sont pas des alternatives proches l'une de l'autre pour la plupart des usages.
- Ollama et LM Studio s'appuient généralement sur llama.cpp ou des moteurs similaires et le format de modèle GGUF, optimisés pour un usage mono-utilisateur sur du matériel grand public, y compris les machines CPU seul et Apple Silicon
- vLLM s'appuie sur PagedAttention et le batching continu, optimisé pour un service GPU à forte concurrence plutôt que pour la réactivité mono-utilisateur sur du matériel modeste
- Ollama s'installe en une commande sans GPU requis ; vLLM attend un environnement Python, un GPU NVIDIA dans la plupart des déploiements, et une configuration en ligne de commande
- LM Studio ajoute une interface de chat graphique de bureau ; vLLM n'a pas d'interface graphique — on y accède via son API compatible OpenAI ou des options en ligne de commande
- vLLM et les outils basés sur llama.cpp peuvent tous deux exposer une API compatible OpenAI, si bien que des outils front-end construits pour cette API fonctionnent souvent avec l'un ou l'autre
Comment vLLM se compare-t-il à TGI et TensorRT-LLM ?
vLLM, Text Generation Inference (TGI) de Hugging Face, et TensorRT-LLM de NVIDIA visent tous la même mission large — le service LLM en production à grande échelle — mais avec des conceptions et des compromis différents.
vLLM
- Détails:
- Sous licence Apache 2.0, basé sur Python, construit autour de PagedAttention et du batching continu. Charge directement les modèles compatibles Hugging Face Transformers, avec une large couverture d'architectures et un support GPU multi-fournisseurs (NVIDIA en premier ; AMD, Intel, TPU documentés).
TGI
- Détails:
- Le moteur de service propre de Hugging Face, sous licence Apache 2.0, prenant aussi en charge le batching continu et plusieurs formats de quantification. Étroitement intégré au Hugging Face Hub et à son écosystème.
TensorRT-LLM
- Détails:
- Le moteur de NVIDIA, conçu spécifiquement pour les GPU NVIDIA. Les modèles sont compilés à l'avance en un moteur TensorRT optimisé pour le GPU cible, ce qui peut offrir de très bonnes performances sur ce matériel précis, au prix d'une étape de compilation et d'une flexibilité multi-matériel moindre que vLLM ou TGI.
Cet article n'a pas benchmarké ces trois moteurs les uns contre les autres de façon indépendante et ne prétend pas que l'un est universellement plus rapide — le débit dépend fortement du modèle, du matériel, des caractéristiques des lots et de la version de chaque moteur. Voir le guide des serveurs d'inférence en entreprise pour une comparaison plus détaillée du déploiement et des licences des trois.
À qui vLLM convient-il ?
vLLM convient aux équipes qui servent un modèle à de nombreux utilisateurs ou applications simultanés sur une infrastructure GPU, pas aux personnes cherchant le moyen le plus rapide de discuter avec un modèle sur leur propre ordinateur.
vLLM face aux alternatives, en un coup d'œil
Ces outils se situent à différents points du spectre entre usage mono-utilisateur et service en production.
vLLM
- Interface & installation:
- Paquet Python installé via pip ; serveur d'API compatible OpenAI lancé avec
vllm serve. Nécessite un GPU NVIDIA et CUDA dans la plupart des déploiements. - Idéal pour:
- Service GPU à haut débit et multi-utilisateurs en production.
Ollama
- Interface & installation:
- CLI et API REST, couramment rapporté comme tournant sur llama.cpp comme backend sur la plupart des plateformes. Une commande l'installe ; une commande télécharge et lance un modèle.
- Idéal pour:
- Le chemin le plus rapide vers un modèle local fonctionnel pour un seul utilisateur, sans étape de build ni GPU requis.
LM Studio
- Interface & installation:
- Application graphique de bureau pour Mac, Windows et Linux. Télécharger, installer, puis parcourir et télécharger un modèle depuis l'application.
- Idéal pour:
- Les utilisateurs non techniques qui veulent une application de chat locale à cliquer.
llama.cpp
- Interface & installation:
- CLI, interface web intégrée et API compatible OpenAI via llama-server. Compiler depuis les sources ou utiliser un binaire précompilé ; tourne sur CPU ou GPU.
- Idéal pour:
- Un contrôle direct au niveau moteur, le déploiement embarqué/edge, et le matériel CPU ou Apple Silicon.
Cet article n'a pas benchmarké de façon indépendante la vitesse ou la qualité des sorties de ces outils et ne prétend pas que l'un est techniquement supérieur — la comparaison ci-dessus ne couvre que des faits documentés d'architecture, d'installation et de modèle d'accès. Pour des chiffres de débit par matériel, voir la comparaison llama.cpp vs. Ollama vs. vLLM et le guide des serveurs d'inférence en entreprise.
Que ne couvre pas cet article ?
Ceci est un article explicatif construit à partir de la documentation publique et du dépôt de vLLM, pas un rapport de benchmark pratique.
- Aucun chiffre de débit, de latence ou de requêtes par seconde mesuré indépendamment — ceux-ci dépendent fortement du GPU, du modèle, de la composition des lots et de la version de vLLM
- Aucun pourcentage de perte de qualité vérifié indépendamment pour des formats de quantification spécifiques — ceux-ci varient selon l'architecture du modèle et la tâche
- Aucun audit de sécurité ligne par ligne du code de vLLM — il est open source et sous licence Apache 2.0, donc le code lui-même est disponible pour révision
- Aucune couverture exhaustive de chaque backend matériel pris en charge, option moteur, ou option d'orchestration de déploiement (Kubernetes, configurations spécifiques au cloud) — cet article se concentre sur les concepts et options que la plupart des équipes évaluent en premier
- Aucune couverture des accords de support commercial ou des offres d'hébergement géré de vLLM, car vLLM lui-même est un projet open source communautaire, pas un produit d'éditeur avec un contrat de support
Erreurs courantes en essayant vLLM
La plupart des frictions avec vLLM viennent du fait de le traiter comme un outil de bureau mono-utilisateur plutôt que comme un logiciel serveur de production.
Questions fréquentes
Qu'est-ce que vLLM ?
vLLM est une bibliothèque et un serveur gratuits, sous licence Apache 2.0, pour l'inférence LLM à haut débit, nés au Sky Computing Lab de l'UC Berkeley. Il utilise PagedAttention et le batching continu pour servir efficacement de nombreuses requêtes simultanées depuis un GPU.
vLLM est-il gratuit ?
Oui. vLLM est un logiciel gratuit et open source publié sous licence Apache 2.0, sans abonnement ni compte requis pour l'exécuter soi-même.
Qu'est-ce que PagedAttention ?
PagedAttention est la technique de vLLM pour gérer le cache KV d'attention en petits blocs non contigus de taille fixe plutôt qu'en une seule grande allocation contiguë par requête, ce qui réduit le gaspillage de mémoire GPU et permet de partager la mémoire entre requêtes ayant un préfixe commun.
vLLM a-t-il besoin d'un GPU ?
Pour toute charge réelle, oui — la cible principale et la mieux prise en charge de vLLM est le GPU NVIDIA. Un backend CPU seul existe mais est documenté comme nettement plus lent et n'est pas le focus du projet, et le support Apple Silicon se limite à des ajouts maintenus par la communauté plutôt qu'à un chemin de premier plan.
Quels formats de quantification vLLM prend-il en charge ?
vLLM prend en charge plusieurs formats dont AWQ, GPTQ, FP8 et INT8/INT4, avec de nombreux modèles pré-quantifiés dans ces formats publiés sur Hugging Face.
vLLM est-il meilleur qu'Ollama ?
« Meilleur » dépend de l'usage : vLLM est conçu pour un service GPU de production à forte concurrence, tandis qu'Ollama est conçu pour le chemin le plus rapide vers un modèle local mono-utilisateur sans GPU requis. Pour la plupart des usages, ce ne sont pas des alternatives proches — voir le tableau comparatif ci-dessus.
vLLM peut-il servir des modèles sur plusieurs GPU ?
Oui. vLLM prend en charge le service en parallélisme tensoriel et en pipeline sur plusieurs GPU, configurable avec des options comme --tensor-parallel-size au démarrage du serveur.
vLLM a-t-il une API compatible OpenAI ?
Oui. Exécuter vllm serve démarre un serveur implémentant le protocole de l'API OpenAI, si bien que de nombreuses applications construites pour l'API OpenAI peuvent pointer vers une instance vLLM auto-hébergée en ne changeant que l'URL de base et le nom du modèle.
En quoi vLLM diffère-t-il de TensorRT-LLM ?
TensorRT-LLM est le moteur de NVIDIA, qui compile les modèles à l'avance en un moteur optimisé pour un GPU NVIDIA spécifique. vLLM charge directement les modèles compatibles Hugging Face Transformers sans étape de compilation préalable, et documente un support de backends au-delà des seuls GPU NVIDIA, au prix d'une optimisation matérielle spécifique moindre mais avec plus de flexibilité et une itération plus rapide.