Ce qu’il faut retenir de mon expérience avec vLLM
- Performance d’entreprise : Conçu spécifiquement pour le multi-utilisateur et les charges de trafic intenses, vLLM surpasse largement les outils locaux comme Ollama ou llama.cpp dans ces scénarios.
- Gestion mémoire optimisée : L’algorithme PagedAttention résout le gaspillage de VRAM en gérant le cache KV sous forme de pages virtuelles, permettant des tailles de lots (batch sizes) bien plus importantes.
- Écosystème structuré et ouvert : Le projet est soutenu par la Fondation PyTorch (sous l’égide de la Linux Foundation), avec des contributions majeures de Red Hat (IBM) et une commercialisation portée par la start-up Inferact.
- Haute compatibilité matérielle : Bien que pensé pour NVIDIA CUDA, le moteur s’adapte à AMD ROCm, Intel (CPU/GPU), AWS Trainium, TPUs et Apple Silicon.
L’origine et l’écosystème de vLLM
vLLM (Virtual Large Language Model) s’est rapidement imposé comme un standard industriel pour le déploiement de grands modèles de langage. Développé initialement par les chercheurs du Sky Computing Lab de l’Université de Californie à Berkeley, ce moteur d’inférence open-source maximise les performances des processeurs graphiques tout en réduisant les coûts opérationnels.
Contrairement à d’autres projets, aucune entreprise unique ne possède vLLM. Sa propriété intellectuelle est détenue par la Fondation PyTorch, rattachée à la Linux Foundation. Autour de ce noyau open-source gravite un écosystème structuré en trois piliers :
- La Fondation Linux et PyTorch (Gouvernance légale) : En juillet 2024, l’Université de Californie à Berkeley a officiellement fait don de vLLM à la Linux Foundation. Dès 2025, le projet a achevé sa transition pour être hébergé par la Fondation PyTorch (accessible sur pytorch.org), garantissant une gouvernance neutre et ouverte.
- Inferact (Start-up commerciale) : En janvier 2026, les créateurs originaux et mainteneurs du projet (notamment le PDG Simon Mo et le cofondateur de Databricks, Ion Stoica) ont lancé Inferact. Cette start-up a levé 150 millions de dollars en amorçage (seed), un tour de table co-dirigé par Andreessen Horowitz (a16z) et Lightspeed Venture Partners, afin de commercialiser des services d’entreprise basés sur vLLM.
- Red Hat / IBM (Contributeur majeur) : Red Hat a fait l’acquisition de Neural Magic, qui était alors le principal contributeur de code et développeur du projet. Aujourd’hui, Red Hat finance activement le développement et assure un leadership technique important, intégrant une version stabilisée et prête pour l’entreprise directement dans Red Hat Enterprise Linux AI (RHEL AI).
Les innovations techniques qui font la différence
Mais qu’est-ce qui rend ce moteur si spécial par rapport aux alternatives ? Deux innovations majeures expliquent ses performances d’inférence :
- PagedAttention : C’est la véritable rupture technologique de vLLM. Cette méthode gère la mémoire du cache Key-Value (KV) de la même manière que la mémoire virtuelle paginée des systèmes d’exploitation. Au lieu de pré-allouer de grands blocs continus de VRAM basés sur la longueur maximale théorique d’une séquence, elle alloue la mémoire à la demande dans de petites pages de taille fixe. Cela élimine jusqu’à 96 % du gaspillage de mémoire et permet d’augmenter drastiquement la taille des lots de requêtes.
- Continuous Batching (Lotissement continu) : Plutôt que d’attendre que l’intégralité d’un lot de requêtes ait fini d’être traitée pour en accepter de nouvelles, vLLM injecte dynamiquement les requêtes entrantes directement au niveau des jetons (tokens). Le GPU reste ainsi constamment sollicité.
- API compatible OpenAI : Le serveur intégré reproduit fidèlement le protocole de l’API officielle d’OpenAI. On peut donc l’intégrer en remplacement transparent dans des applications existantes simplement en modifiant l’URL de l’endpoint.
Le code source et les discussions de la communauté restent accessibles sur github.com/vllm-project/vllm et les informations générales sont centralisées sur vllm.ai.
Installation pas à pas
Pour installer vLLM, je recommande vivement d’utiliser un environnement virtuel propre. Le moteur repose sur des noyaux CUDA précompilés spécifiques qui peuvent facilement entrer en conflit avec d’autres paquets PyTorch existants.
Prérequis système
- Système d’exploitation : Linux est fortement recommandé. Les utilisateurs Windows doivent obligatoirement passer par WSL2. macOS est pris en charge via le paquet dédié
vllm-metal. - Python : Versions 3.10 à 3.13 (la version 3.12 ou supérieure est vivement recommandée).
- Matériel NVIDIA : Un GPU avec une capacité de calcul de 7.5 ou plus (par exemple : T4, RTX 30xx/40xx, A100, H100, B200).
Méthode 1 : Utiliser “uv” (La plus rapide)
L’équipe de vLLM recommande l’usage de uv, un gestionnaire de paquets Python particulièrement rapide qui détecte automatiquement la version de CUDA présente sur le système.
# 1. Installer uv (si ce n'est pas déjà fait)
curl -LsSf https://astral.sh | sh
# 2. Créer un environnement virtuel propre avec Python 3.12
uv venv --python 3.12
source .venv/bin/activate
# 3. Installer vLLM avec résolution automatique du backend PyTorch
uv pip install vllm --torch-backend=autoMéthode 2 : Installation standard avec pip et conda
Si vous préférez utiliser les outils traditionnels, vous pouvez isoler les dépendances dans un environnement Conda dédié :
# 1. Créer et activer l'environnement conda
conda create -n vllm_env python=3.12 -y
conda activate vllm_env
# 2. Mettre à jour pip pour éviter les boucles de résolution de dépendances
pip install --upgrade pip
# 3. Installer le paquet vLLM standard
pip install vllmMéthode 3 : Installation sur d’autres architectures matérielles
vLLM s’adapte à d’autres accélérateurs via des installations ciblées :
- Apple Silicon (Mac M1/M2/M3) : Utilisez la version Metal pour tirer parti de la mémoire unifiée :
pip install vllm-metal - Intel (CPU et GPU de Data Center) : Installez le moteur XPU dédié en veillant à utiliser Python 3.12 :
pip install vllm-xpu - AMD ROCm GPUs : Il convient de se référer à la documentation spécifique ROCm de vLLM pour faire correspondre le paquet à votre runtime.
Pour vérifier que tout fonctionne correctement, lancez simplement la commande d’aide :
vllm --helpDéploiement en production avec Docker
C’est l’approche que je conseille pour la production. Les images Docker officielles de vLLM embarquent déjà les pilotes CUDA optimisés, PyTorch et les noyaux GPU précompilés, ce qui évite les conflits de version avec la machine hôte. Il vous faudra installer au préalable le NVIDIA Container Toolkit sur l’hôte, et disposer d’un jeton Hugging Face (HF Token) si vous utilisez des modèles à accès restreint comme Llama 3.
Lancement rapide via CLI
Voici comment démarrer un serveur d’API compatible OpenAI en montant un volume local pour éviter de retélécharger le modèle à chaque redémarrage du conteneur :
docker run --gpus all \
-v ~/.cache/huggingface:/root/.cache/huggingface \
-p 8000:8000 \
--ipc=host \
vllm/vllm-openai:latest \
--model Qwen/Qwen2.5-7B-InstructLe flag --ipc=host est nécessaire pour que le conteneur accède à la mémoire partagée de l’hôte, une condition requise pour le traitement parallélisé multi-GPU.
Configuration pour la production avec Docker Compose
Pour des environnements stables, la création d’un fichier docker-compose.yml facilite grandement la gestion des variables d’environnement et des limites matérielles :
services:
vllm-server:
image: vllm/vllm-openai:latest
container_name: vllm-api
environment:
- HF_TOKEN=votre_jeton_huggingface_ici
volumes:
- ~/.cache/huggingface:/root/.cache/huggingface
ports:
- "8000:8000"
ipc: host
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
command: >
--model meta-llama/Llama-3.1-8B-Instruct
--max-model-len 4096
restart: unless-stoppedPour lancer ce conteneur en arrière-plan :
docker compose up -dConfiguration multi-GPU distribuée
Si vous manipulez un modèle trop lourd pour tenir sur un seul GPU, vous devez définir la taille du parallélisme de tenseur (Tensor Parallelism) dans la commande d’exécution :
docker run --gpus '"device=0,1,2,3"' \
-v ~/.cache/huggingface:/root/.cache/huggingface \
-p 8000:8000 \
--ipc=host \
vllm/vllm-openai:latest \
--model meta-llama/Llama-3.1-70B-Instruct \
--tensor-parallel-size 4Vous pouvez vous assurer que le serveur répond correctement en interrogeant les modèles disponibles sur l’hôte :
curl http://localhost:8000/v1/modelsComment utiliser concrètement vLLM ?
Vous pouvez utiliser vLLM de deux manières principales : soit en exposant une API web via le serveur intégré, soit directement au sein d’un script d’inférence en Python.
Option 1 : Lancer le serveur d’API (Recommandé)
Démarrez le serveur avec un modèle léger :
vllm serve Qwen/Qwen2.5-1.5B-InstructPuis, dans un autre terminal, envoyez une requête au format OpenAI à l’aide de curl :
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen/Qwen2.5-1.5B-Instruct",
"messages": [
{"role": "user", "content": "Give me a 3-word motto for an engineer."}
],
"temperature": 0.7
}'Option 2 : Inférence directe en Python
Si vous n’avez pas besoin d’un serveur HTTP et que vous effectuez des traitements par lots hors ligne, vous pouvez appeler directement la classe LLM dans vos scripts.
from vllm import LLM, SamplingParams
# 1. Définition des invites
prompts = [
"The future of artificial intelligence is",
"Write a haiku about a slow computer."
]
# 2. Paramètres de génération (tokens, température, etc.)
sampling_params = SamplingParams(temperature=0.8, max_tokens=100)
# 3. Initialisation du modèle (chargement automatique sur le GPU)
llm = LLM(model="Qwen/Qwen2.5-1.5B-Instruct")
# 4. Génération de texte par lots
outputs = llm.generate(prompts, sampling_params)
# 5. Affichage des résultats
for output in outputs:
prompt = output.prompt
generated_text = output.outputs[0].text
print(f"\nPrompt: {prompt}\nResponse: {generated_text}")Conseils pour la mise à l’échelle
- Parallélisme de tenseur : Pour diviser un modèle volumineux sur plusieurs cartes graphiques, utilisez l’argument
--tensor-parallel-sizeau lancement du serveur :vllm serve meta-llama/Llama-3.1-70B-Instruct --tensor-parallel-size 4 - Quantification (Économie de VRAM) : vLLM prend en charge nativement les formats compressés comme AWQ ou FP8. Le moteur détecte le format automatiquement si celui-ci figure dans le nom du modèle :
vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ
Zoom sur TurboQuant : compression du cache KV
Présenté à l’origine par Google Research à l’ICLR 2026, TurboQuant est un algorithme de compression mathématique intégré à vLLM. Son but est de réduire la taille du cache Key-Value (le contexte ou la “mémoire à court terme” du modèle) de 4 à 6 fois, avec un impact minime sur la précision. C’est une technologie très utile pour faire face au goulot d’étranglement de la mémoire lors de tâches impliquant de très longues fenêtres de contexte (par exemple, l’analyse de bases de code entières).
À la différence de GPTQ ou d’AWQ, qui compressent les poids fixes du modèle, TurboQuant cible la mémoire dynamique générée lors des longues discussions. Son fonctionnement repose sur trois mécanismes :
- La rotation aléatoire (Walsh-Hadamard) : Elle fait pivoter mathématiquement les vecteurs KV pour lisser les valeurs aberrantes (outliers) et harmoniser leur échelle.
- La cartographie polaire/scalaire : Elle transforme les données en coordonnées homogènes pour autoriser une quantification agressive en 3 ou 4 bits.
- La correction directionnelle sur 1 bit : Elle réserve précisément un bit pour réaligner la direction du vecteur, préservant ainsi la précision de la couche d’attention du modèle.
Comparatif des variantes TurboQuant
| Variante TurboQuant | Gain de cache KV | Rétention de la précision | Impact sur la latence et le débit | Usage recommandé |
|---|---|---|---|---|
| TQ k8v4 | 2.4x | Presque parfaite (>98%) | Impact négatif mineur | Optionnel (le FP8 standard reste souvent préférable) |
| TQ 4bit-nc | ~4x | Excellente (~96%) | Coût de latence modéré | Déploiements Edge ou forte contrainte de VRAM |
| TQ 3bit-nc / k3v4-nc | 5x et plus | Baisse significative (~20 points) | Dégradation importante du débit et de la latence | Uniquement sous contrainte extrême de mémoire (déconseillé pour le raisonnement) |
Note de terrain : Pour la plupart des architectures de production standards, l’implémentation FP8 par défaut de vLLM (via l’argument
--kv-cache-dtype fp8) reste le choix le plus équilibré si la VRAM disponible le permet.
Activer TurboQuant
Assurez-vous d’utiliser vLLM en version 0.20.0 ou ultérieure sur des modèles compatibles (comme Qwen 3.5+, Llama 3+, ou DeepSeek V4).
En ligne de commande (CLI) :
vllm serve Qwen/Qwen2.5-7B-Instruct \
--kv-cache-dtype turboquant \
--quantization turboquant_4bitEn script Python :
from vllm import LLM
llm = LLM(
model="meta-llama/Llama-3.1-8B-Instruct",
kv_cache_dtype="turboquant",
quantization="turboquant_4bit"
)Visualiser l’inférence : vLLM Studio et le Playground
vLLM est nativement un outil en ligne de commande. Toutefois, pour ceux qui apprécient une approche visuelle proche de LM Studio, des projets open-source comme vLLM Studio (ou Local Studio) proposent des interfaces graphiques complètes pour piloter vos modèles locaux ou distants.
Ces projets reposent sur une architecture découplée : un frontend React/Next.js dans le navigateur communique via des WebSockets avec un serveur de traduction, qui pilote à son tour le backend Python de vLLM. Vous pouvez ainsi installer l’interface graphique sur une machine légère (comme un MacBook) et la connecter à un serveur Linux distant équipé de cartes GPU haut de gamme.
L’alternative officielle : vLLM Playground
Si vous préférez éviter d’installer des surcouches tierces, sachez que les mainteneurs du projet proposent un bac à sable officiel directement intégré dans le moteur. Vous pouvez l’activer d’une simple ligne de commande :
vllm serve Qwen/Qwen2.5-7B-Instruct --enable-playgroundIl vous suffit ensuite d’ouvrir votre navigateur à l’adresse indiquée (généralement http://localhost:8000/playground) pour accéder à l’interface de discussion, aux compteurs de jetons et aux configurations d’appels d’outils (tool calling).
vLLM, Ollama et Llama.cpp : Lequel choisir ?
Il m’arrive souvent de devoir choisir entre ces outils pour différents projets. Bien qu’ils permettent tous d’exécuter des modèles localement, ils répondent à des besoins diamétralement opposés.
vLLM vs Ollama
| Caractéristique | Ollama | vLLM |
|---|---|---|
| Public cible | Développeurs, usages locaux et personnels | DevOps, ingénieurs IA, infrastructures de production |
| Architecture de base | Basé sur llama.cpp | Moteur sur mesure avec PagedAttention |
| Matériel de prédilection | Configurations grand public (Mac, Windows, Linux) | GPU de niveau Data Center (NVIDIA, AMD) |
| Gestion de la VRAM | Répartition dynamique des couches entre CPU et GPU | Allocation dynamique de pages de mémoire virtuelle |
| Utilisateurs simultanés | Faible (traitement séquentiel des requêtes) | Très élevé (Continuous Batching) |
| Formats de quantification | Strictement GGUF | AWQ, GPTQ, FP8, TurboQuant |
- Pourquoi choisir Ollama ? L’installation se fait en un clic, la gestion des modèles de Hugging Face est transparente grâce à sa propre bibliothèque de modèles, et il est extrêmement bien optimisé pour la mémoire unifiée des puces Apple Silicon. C’est l’idéal pour faire tourner des modèles sur un ordinateur portable avec 8 ou 16 Go de RAM.
- Pourquoi choisir vLLM ? Pour le débit. Grâce à PagedAttention et au traitement en lots continus, vLLM traite des dizaines de requêtes de front sans créer de file d’attente bloquante. Son support natif du parallélisme de tenseur permet d’éclater un modèle de 70B ou 405B paramètres sur plusieurs GPU. De plus, il s’intègre naturellement dans les écosystèmes Docker, Kubernetes ou avec des outils de monitoring comme Prometheus.
vLLM vs Llama.cpp
La distinction est similaire. Llama.cpp, écrit en C/C++ pur, vise la portabilité maximale et une empreinte mémoire réduite sur du matériel grand public. À l’inverse, vLLM (développé en Python avec des noyaux C++/CUDA) vise le débit maximal en environnement serveur.
- Gestion de la concurrence : Sous de lourdes charges de requêtes simultanées (plus de 32 requêtes de front), vLLM génère un débit de tokens 2 à 3 fois supérieur à llama.cpp, car ce dernier traite les demandes de manière séquentielle dans une file d’attente.
- Gestion des longs contextes : Lorsque les contextes dépassent les 8 000 jetons, le cache KV de llama.cpp croît linéairement, ce qui peut saturer la mémoire ou ralentir l’inférence. vLLM gère ces longs préfixes de manière paginée, restant jusqu’à 50 % plus rapide à matériel équivalent.
- Latence pour utilisateur unique : Si vous êtes seul à interroger le modèle, llama.cpp offre souvent un temps de réponse initial (Time-to-First-Token) légèrement meilleur. Il s’affranchit en effet de la surcharge de coordination du serveur de Continuous Batching propre à vLLM.
De plus, vLLM a tendance à s’approprier par défaut environ 90 % de la mémoire de votre carte pour son système de pages virtuelles, laissant peu de ressources pour d’autres applications graphiques sur un ordinateur de bureau.
L’architecture matérielle idéale pour vLLM
Pour tirer le meilleur parti de vLLM, deux facteurs sont essentiels : la bande passante mémoire du GPU (qui régit la vitesse de génération) et la capacité de VRAM (qui régit la taille maximale du modèle et le nombre d’utilisateurs simultanés).
Tier 1 : La station de travail individuelle (Prototypage)
- Usage : Développeur solo, tests sur des modèles jusqu’à 32B, petits traitements par lots.
- GPU : 1× NVIDIA RTX 5090 (32 Go GDDR7) ou 1× RTX 4090 (24 Go GDDR6X). La RTX 5090 offre un excellent rapport qualité-prix pour faire tourner confortablement des modèles comme Qwen-2.5-32B ou Llama-3-8B tout en conservant une marge confortable pour le cache KV.
- CPU / RAM : AMD Ryzen 9 9950X ou Intel Core i9 (14e/15e génération) épaulé par 64 Go de RAM DDR5.
- Stockage : SSD NVMe M.2 de 2 To (vitesse de lecture minimale de 5 000 Mo/s pour charger rapidement les poids des modèles en VRAM).
Tier 2 : Le serveur d’équipe (PME / Serveur sur site)
- Usage : Hébergement de modèles 70B à 120B, gestion de dizaines d’utilisateurs internes simultanés.
- GPU : 2× ou 4× NVIDIA RTX PRO 6000 Blackwell (96 Go ECC GDDR7 chacune). Quatre cartes de ce type fournissent 384 Go de VRAM combinée et près de 7,2 To/s de bande passante globale. C’est l’idéal pour exécuter des modèles massifs ou utiliser la quantification FP8 sur de très longs contextes de discussion.
- CPU / Cartes mères : AMD Ryzen Threadripper PRO (ex : 7955WX ou 9955WX). Le choix du processeur et de la carte mère est ici crucial : il vous faut une plateforme gérant 128 lignes PCIe Gen 5 pour que toutes les cartes graphiques communiquent en pleine largeur matérielle x16 sans goulet d’étranglement.
- RAM / Alimentation : 128 à 256 Go de mémoire RAM ECC DDR5. Pour l’alimentation, prévoyez deux blocs redondants de 1600W de niveau Titanium ou Gold afin de prévenir les plantages liés aux brusques appels de puissance des GPU lors des calculs par lots.
Tier 3 : L’infrastructure Cloud d’entreprise
- Usage : Applications SaaS grand public à fort trafic, modèles jusqu’à 405B paramètres.
- GPU : Châssis de 8× NVIDIA H100 SXM5 (80 Go HBM3 chacune) ou grappes NVIDIA Blackwell B200. À cette échelle, les cartes grand public montrent leurs limites en l’absence de liaisons d’interconnexion rapides (NVLink). Les architectures SXM offrent une bande passante individuelle de 3,3 To/s et des liaisons physiques directes entre cartes, permettant d’exécuter Llama-3-405B non quantifié avec une latence infime.
- Réseau : Commutateurs NVIDIA Quantum-2 InfiniBand (400 Gb/s), indispensables si vous interconnectez plusieurs nœuds multi-GPU via le framework de clustering distribué Ray géré par vLLM.
Règles d’or pour le matériel
- Privilégiez la bande passante plutôt que la puissance brute de calcul : Une carte graphique disposant d’une bande passante mémoire de 1 000 Go/s générera des jetons deux fois plus vite qu’une carte limitée à 500 Go/s, quel que soit son nombre de cœurs de calcul.
- Fuyez les cartes mères grand public pour le multi-GPU : Les chipsets grand public comme les Intel Z790 ou AMD X670 ne disposent pas de suffisamment de lignes PCIe physiques pour faire fonctionner plus d’un GPU à pleine vitesse, ce qui ralentit considérablement les échanges de données lorsque vLLM fragmente le modèle sur plusieurs cartes.
- Évitez macOS pour les déploiements de serveurs : Bien que les puces Apple Silicon embarquent d’importantes quantités de mémoire unifiée, vLLM et ses noyaux d’optimisation propriétaires sont spécifiquement taillés pour l’architecture NVIDIA CUDA. Pour les serveurs de production multi-utilisateurs, l’environnement PC/Linux équipé de GPU dédiés reste indispensable.