vLLM : serveur d’inférence haute performance — déploiement GPU 2026

Introduction

Quand une PME d’Abidjan ou de Dakar décide d’héberger elle-même un grand modèle de langage, le premier réflexe est souvent d’utiliser la bibliothèque transformers de Hugging Face directement : model.generate(), quelques lignes de Python, et le modèle répond. Cette approche fonctionne parfaitement en développement, mais elle s’effondre dès que plusieurs utilisateurs interrogent le serveur simultanément. Sans gestion intelligente de la mémoire GPU, chaque requête monopolise l’intégralité du VRAM le temps de sa génération, les requêtes suivantes font la queue, et le débit réel s’effondre.

vLLM résout ce problème de manière fondamentale. Développé à l’Université de Californie à Berkeley et publié à NeurIPS 2023, il introduit PagedAttention : une technique qui gère le KV-cache de l’attention de la même façon que la pagination mémoire dans un système d’exploitation. Plutôt d’allouer un bloc contigu de VRAM pour chaque séquence — gaspillant parfois 60 à 80 % de la capacité disponible —, PagedAttention découpe le KV-cache en petites pages de taille fixe et les alloue à la demande. Résultat mesuré dans le papier original : un débit jusqu’à 24× supérieur à l’implémentation naïve de Hugging Face Transformers, avec des gains similaires face à FasterTransformer. En 2026, vLLM est devenu la référence de facto pour l’inférence LLM en production sur GPU NVIDIA, utilisée aussi bien par des startups africaines que par des entreprises du CAC 40 ayant choisi le self-hosting.

Ce tutoriel vous guide pas à pas : de la sélection du GPU cloud adapté à votre budget jusqu’à la mise en production d’un serveur d’inférence OpenAI-compatible servi à vos utilisateurs, en passant par la quantification pour réduire la consommation VRAM et le batching dynamique pour maximiser le débit.

Prérequis

• GPU NVIDIA : L4 (24 Go VRAM), A10G (24 Go), A100 (40 ou 80 Go) ou équivalent. Une RTX 4090 (24 Go) convient pour un usage monothread de développement.
• CUDA : version 12.1 minimum (vLLM 0.4+ l’exige). Vérifier avec nvcc --version ou nvidia-smi.
• Docker : version 24+ avec le plugin NVIDIA Container Toolkit installé.
• RAM système : 32 Go minimum recommandés (le modèle est chargé en mémoire système avant transfert GPU).
• Compte Hugging Face : pour accéder aux poids de Mistral ou Qwen2.5 (certains modèles nécessitent une acceptation de licence).
• Niveau : intermédiaire — vous savez exécuter des commandes Docker et avez déjà manipulé une API REST.
• Temps estimé : environ 45 minutes, téléchargement du modèle inclus.

Étape 1 — vLLM vs Ollama vs TGI : choisir le bon serveur d’inférence

Avant de lancer la moindre commande Docker, il est important de comprendre pourquoi vLLM est le bon choix pour certains cas d’usage, et pas forcément pour tous. Il existe aujourd’hui trois grands serveurs d’inférence open-source : Ollama, Text Generation Inference (TGI) de Hugging Face, et vLLM. Chacun a un profil différent.

Ollama est le serveur le plus simple à déployer. Une seule commande, pas de GPU requis (CPU suffisant), interface graphique via Open WebUI, support macOS natif. C’est le choix idéal pour un développeur solo ou une TPE qui veut tester un modèle sur son laptop ou un petit VPS sans GPU. Son inconvénient majeur : son architecture mono-requête ne scale pas. Quand dix utilisateurs interrogent Ollama simultanément, les requêtes se mettent en file d’attente stricte — l’une après l’autre. Sur GPU, le débit est bien inférieur à ce qu’un vLLM obtient avec le même matériel.

Text Generation Inference (TGI) de Hugging Face est un serveur de production également basé sur le continuous batching, donc comparable à vLLM en termes de débit. TGI a l’avantage d’être très bien intégré dans l’écosystème Hugging Face et de supporter certains modèles spéciaux (GPTQ officiel, Flash Attention 2 natif). Son inconvénient : la liste des modèles supportés est plus restrictive — il faut que le modèle soit explicitement supporté dans TGI, alors que vLLM supporte presque tout ce qui existe sur Hugging Face Model Hub.

vLLM est le choix optimal dès que vous avez un GPU et plus de dix utilisateurs simultanés. Son architecture de continuous batching avec PagedAttention maintient un débit élevé même en charge. Sa compatibilité de modèles est la plus large du marché. Son API est strictement compatible avec celle d’OpenAI — ce qui signifie que tout code existant conçu pour GPT-4 fonctionne sans modification sur un serveur vLLM. Enfin, la communauté est très active et les mises à jour fréquentes. La règle simple : TPE sans GPU → Ollama CPU ; PME avec GPU et >10 utilisateurs → vLLM.

Étape 2 — Choisir son GPU cloud : Hetzner GEX44, RunPod, Vast.ai

Si vous ne disposez pas d’un GPU physique, plusieurs fournisseurs cloud proposent des instances GPU à la location. Le choix du bon prestataire dépend de votre budget, de votre besoin de disponibilité garantie et de votre situation géographique. Voici les trois options les plus pertinentes pour le contexte africain en 2026.

Hetzner GEX44 est un serveur dédié équipé d’un NVIDIA L4 (24 Go VRAM) proposé à environ 150 EUR/mois dans les datacenters Hetzner en Allemagne et Finlande. C’est l’option la plus économique pour un usage continu 24/7 : à ce tarif mensuel fixe, vous pouvez héberger un Mistral-7B ou un Qwen2.5-7B et servir confortablement 100 à 300 utilisateurs simultanés. La latence depuis l’Afrique de l’Ouest vers l’Allemagne est d’environ 80–120 ms, acceptable pour une application de chat ou de génération de contenu. Le point positif supplémentaire de Hetzner : la facturation est prévisible, sans surprise liée à un dépassement de quota GPU.

RunPod propose une facturation à la seconde sur des GPU mutualisés ou dédiés. Un A10G ou RTX 4090 coûte entre 0,30 et 0,55 USD/heure. C’est le choix idéal pour les phases de test, les workloads intermittents (un serveur qui tourne seulement en journée de travail), ou pour expérimenter avec différents modèles avant de s’engager sur un serveur dédié. RunPod propose des templates pré-configurés vLLM qui permettent de lancer un serveur fonctionnel en moins de 5 minutes.

Vast.ai est un marché pair-à-pair où des particuliers et entreprises louent leur capacité GPU. Les prix sont souvent 30 à 50 % moins chers que RunPod, mais la disponibilité des instances n’est pas garantie et la variabilité de performance est plus grande. Recommandé uniquement pour les workloads batch ou les expérimentations non critiques.

Pour le tutoriel qui suit, on suppose que vous avez accès à un serveur avec un GPU NVIDIA L4 ou A10G, CUDA 12.1+ installé, et Docker avec le NVIDIA Container Toolkit configuré. La commande nvidia-smi doit retourner la liste de vos GPU avant de continuer.

Étape 3 — Lancer le serveur vLLM via Docker

L’équipe vLLM maintient une image Docker officielle publiée sur Docker Hub sous le nom vllm/vllm-openai. Cette image embarque toutes les dépendances CUDA, Python et les kernels CUDA personnalisés de vLLM — inutile d’installer quoi que ce soit sur le système hôte au-delà du NVIDIA Container Toolkit. C’est la méthode de déploiement recommandée en production car elle garantit la reproductibilité et facilite les mises à jour.

Avant de lancer le conteneur, créez un répertoire local qui servira de cache pour les poids du modèle. Ce cache persistant est crucial : sans lui, à chaque redémarrage du conteneur, vLLM re-téléchargerait les plusieurs gigaoctets de poids depuis Hugging Face, ce qui n’est ni acceptable en termes de temps de démarrage ni viable sur une connexion africaine.

# Créer le répertoire de cache local pour les poids HuggingFace
mkdir -p /data/hf-cache

# Lancer le serveur vLLM avec l’image officielle
# --gpus all : expose tous les GPU NVIDIA au conteneur
# -v /data/hf-cache:/root/.cache/huggingface : monte le cache persistant
# --ipc=host : requis par PyTorch pour le shared memory entre workers GPU
# -p 8000:8000 : expose le port de l’API
docker run -d \
  --name vllm-server \
  --gpus all \
  --ipc=host \
  -v /data/hf-cache:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model mistralai/Mistral-7B-Instruct-v0.3 \
  --host 0.0.0.0 \
  --port 8000

# Suivre les logs de démarrage (le chargement du modèle prend 1–2 minutes)
docker logs -f vllm-server

Le paramètre --ipc=host est non-négociable : PyTorch utilise la mémoire partagée du système hôte pour les communications inter-processus entre workers GPU, et sans cette option vous obtiendrez des erreurs de type Bus error ou des OOM inexplicables dès que le modèle utilise du tensor parallelism. Les logs doivent montrer la progression du chargement des poids shard par shard, puis se terminer par une ligne INFO: Uvicorn running on http://0.0.0.0:8000 qui indique que le serveur est prêt à accepter des requêtes.

Étape 4 — Charger un modèle : Mistral-7B-Instruct-v0.3 ou Qwen2.5-7B

Le choix du modèle à charger dans vLLM dépend de votre cas d’usage et de la VRAM disponible. En 2026, deux modèles dominent les déploiements PME en raison de leur excellent rapport qualité/taille : Mistral-7B-Instruct-v0.3 et Qwen2.5-7B-Instruct.

Mistral-7B-Instruct-v0.3 est publié par Mistral AI sous licence Apache 2.0. Il excelle en français et en anglais, avec un très bon comportement sur les tâches d’instruction-following, de résumé, de génération de code et de question-réponse. En précision float16, il nécessite environ 14 Go de VRAM — donc faisable sur un L4 24 Go avec de la marge pour le KV-cache. Pour le charger dans vLLM, ajoutez simplement --model mistralai/Mistral-7B-Instruct-v0.3 à la commande Docker vue à l’étape précédente. vLLM téléchargera automatiquement les poids depuis Hugging Face lors du premier démarrage et les mettra en cache.

Qwen2.5-7B-Instruct est publié par Alibaba sous licence Apache 2.0. Il se distingue par un support multilingue plus large (incluant le mandarin et l’arabe), une meilleure performance sur les tâches de raisonnement mathématique et de code, et un contexte natif de 128 000 tokens contre 32 768 pour Mistral-7B-v0.3. Si vos utilisateurs ont besoin de traiter de longs documents ou de travailler en arabe (pertinent pour des pays comme le Sénégal, la Mauritanie ou le Mali), Qwen2.5-7B est le meilleur choix à taille égale.

# Lancer vLLM avec Qwen2.5-7B-Instruct à la place de Mistral
docker run -d \
  --name vllm-qwen \
  --gpus all \
  --ipc=host \
  -v /data/hf-cache:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 \
  --port 8000

# Si vous avez besoin d’un token HuggingFace (modèle gated)
# Passer le token via variable d’environnement
docker run -d \
  --name vllm-mistral \
  --gpus all \
  --ipc=host \
  -e HUGGING_FACE_HUB_TOKEN=hf_votre_token_ici \
  -v /data/hf-cache:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model mistralai/Mistral-7B-Instruct-v0.3 \
  --host 0.0.0.0 \
  --port 8000

Le téléchargement initial des poids prend entre 5 et 20 minutes selon votre bande passante (les fichiers pèsent environ 14 Go pour un modèle 7B en float16). Une fois en cache dans /data/hf-cache, les redémarrages suivants ne téléchargent plus rien et le modèle est opérationnel en moins de 2 minutes. Vérifiez que le chargement est complet avec docker logs vllm-mistral | grep "Uvicorn running".

Étape 5 — Tester l’API OpenAI-compatible

Une fois le serveur démarré, il expose une API strictement compatible avec les endpoints OpenAI. Cela signifie que tout client conçu pour l’API OpenAI — que ce soit une application Python utilisant le SDK officiel, LangChain, LiteLLM, ou un appel curl brut — fonctionnera sans modification avec votre serveur vLLM, en changeant simplement l’URL de base.

# Test basique avec curl — endpoint de complétion de chat
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistralai/Mistral-7B-Instruct-v0.3",
    "messages": [
      {"role": "user", "content": "Explique ce qu est PagedAttention en 3 phrases."}
    ],
    "max_tokens": 200,
    "temperature": 0.7
  }'

# Lister les modèles disponibles (endpoint de compatibilité OpenAI)
curl http://localhost:8000/v1/models

# Test de complétion classique (non-chat)
curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistralai/Mistral-7B-Instruct-v0.3",
    "prompt": "La capitale du Sénégal est",
    "max_tokens": 50
  }'

La réponse au premier appel ressemble à un JSON OpenAI standard avec les champs choices, usage (nombre de tokens entrée/sortie), et model. Si vous recevez ce JSON en retour, votre serveur vLLM est pleinement opérationnel. Pour utiliser le SDK Python OpenAI, il suffit de configurer base_url="http://localhost:8000/v1" et api_key="fake-key" (vLLM ne vérifie pas la clé par défaut — ajoutez une couche d’authentification via un proxy LiteLLM ou Nginx si vous exposez le serveur sur Internet).

Étape 6 — Throughput et batching dynamique

L’un des atouts majeurs de vLLM par rapport à ses concurrents est le continuous batching (aussi appelé iteration-level scheduling ou batching dynamique). Contrairement à l’approche statique où un batch de requêtes est constitué puis exécuté en entier avant d’accepter de nouvelles requêtes, le continuous batching insère les nouvelles requêtes dans le batch à chaque pas de génération. Les requêtes qui ont terminé leur génération libèrent immédiatement leur place dans le batch pour les suivantes, sans attendre les requêtes plus longues.

Pour mesurer le throughput de votre installation, vLLM fournit un script de benchmark inclus dans l’image Docker :

# Lancer le benchmark de throughput depuis l’intérieur du conteneur
# Ce test envoie 100 requêtes en parallèle et mesure les tokens/seconde
docker exec vllm-server python3 /app/benchmarks/benchmark_throughput.py \
  --backend openai-chat \
  --base-url http://localhost:8000 \
  --model mistralai/Mistral-7B-Instruct-v0.3 \
  --num-prompts 100 \
  --input-len 256 \
  --output-len 128

# Benchmark de latence (time to first token)
docker exec vllm-server python3 /app/benchmarks/benchmark_latency.py \
  --model mistralai/Mistral-7B-Instruct-v0.3 \
  --batch-size 1 \
  --input-len 512 \
  --output-len 128 \
  --num-iters 10

Sur un NVIDIA L4 24 Go avec Mistral-7B en float16, vous devriez obtenir un throughput de 800–1 200 tokens/seconde en charge normale. Pour ajuster le comportement du serveur selon votre charge, deux paramètres de la ligne de commande vLLM sont particularisèrement utiles : --max-num-seqs contrôle le nombre maximum de requêtes traitées simultanément dans le batch (par défaut 256 ; réduire à 64 sur des GPU à VRAM limité), et --max-model-len limite la longueur maximale du contexte (réduire à 4096 si vous avez des erreurs OOM sur des requêtes longues). Ces deux paramètres s’ajoutent simplement à la commande Docker de l’étape 3.

Étape 7 — Quantification AWQ/GPTQ pour réduire la VRAM

Si votre GPU dispose de moins de 24 Go de VRAM, ou si vous souhaitez faire tenir deux modèles 7B sur le même GPU A100 80 Go, la quantification est la solution. vLLM supporte nativement deux formats de quantification post-entraînement : AWQ (Activation-aware Weight Quantization) et GPTQ (Generative Pre-trained Transformer Quantization), tous deux en 4 bits. La quantification AWQ est généralement préférée en 2026 car elle préserve mieux la qualité de génération tout en réduisant la VRAM nécessaire d’environ 50 % : un modèle 7B qui occupait 14 Go en float16 n’en nécessite plus que 4–6 en AWQ int4.

Des versions quantifiées des modèles populaires sont disponibles directement sur Hugging Face, notamment publiées par l’organisation TheBloke et par les éditeurs officiels eux-mêmes. Il n’est donc généralement pas nécessaire de quantifier le modèle soi-même.

# Charger Mistral-7B en AWQ 4-bit (version publiée par TheBloke)
# Nécessite seulement ~5 Go de VRAM — fonctionne sur une RTX 3080 10 Go
docker run -d \
  --name vllm-awq \
  --gpus all \
  --ipc=host \
  -v /data/hf-cache:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model TheBloke/Mistral-7B-Instruct-v0.3-AWQ \
  --quantization awq \
  --host 0.0.0.0 \
  --port 8000

# Charger Qwen2.5-7B en GPTQ 4-bit
docker run -d \
  --name vllm-gptq \
  --gpus all \
  --ipc=host \
  -v /data/hf-cache:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen2.5-7B-Instruct-GPTQ-Int4 \
  --quantization gptq \
  --dtype float16 \
  --host 0.0.0.0 \
  --port 8000

Le paramètre --quantization awq indique explicitement à vLLM d’utiliser les kernels AWQ optimisés au lieu du chemin générique. Pour GPTQ, l’option --dtype float16 est nécessaire car les poids GPTQ sont dequantifiés en float16 à l’exécution. Le compromis à connaître : la quantification réduit légèrement la qualité des réponses (perte de perplexité de l’ordre de 5–10 % selon les benchmarks MMLU) et peut réduire le throughput de 10–20 % par rapport au float16 natif. Pour la plupart des cas d’usage professionnels — chatbot, assistance rédaction, FAQ, code completion — cette perte de qualité est imperceptible et le gain en VRAM justifie largement le choix.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour une PME de 50 à 200 employés située à Dakar, Abidjan, Bamako ou Ouagadougou, la question centrale n’est pas technique mais économique : le coût d’un GPU cloud est-il rentable par rapport aux alternatives ? La réponse dépend du volume d’utilisation. Le Hetzner GEX44 à ~150 EUR/mois devient rentable à partir d’environ 100 utilisateurs actifs qui interrogent le LLM plusieurs fois par jour. En dessous de ce seuil, l’alternative la plus sage est l’API Mistral La Plateforme (api.mistral.ai) : pas de GPU à gérer, paiement à l’usage, et les mêmes modèles Mistral accessibles via une API OpenAI-compatible. LiteLLM peut router dynamiquement entre votre serveur vLLM self-hosted et l’API Mistral cloud selon la charge, ce qui donne une architecture hybride idéale : le serveur local absorbe la charge de base, Mistral La Plateforme gère les pics.

Pour les TPE et micro-entreprises qui n’ont pas de GPU et ne peuvent pas se permettre 150 EUR/mois, le fallback naturel est Ollama sur CPU. Un VPS standard à 8 vCPUs et 32 Go de RAM (disponible chez Hetzner, Contabo ou OVH pour 20–40 EUR/mois) peut faire tourner Mistral-7B ou Qwen2.5-7B avec Ollama en précision int4 à 2–5 tokens/seconde. Lent pour un usage interactif en temps réel, mais tout à fait acceptable pour des tâches asynchrones (génération de rapports, résumés de documents, traitement de tickets la nuit).

Un aspect souvent négligé dans le contexte africain : la latence depuis l’Afrique vers l’Europe. Un serveur Hetzner en Allemagne sera à 80–120 ms de ping depuis Dakar. Sur des générations de 200 tokens à 800 tokens/seconde, cette latence initiale est négligeable (< 1 % du temps total). En revanche, si vous utilisez le streaming token par token (paramètre « stream »: true dans l’API), l’utilisateur voit les tokens apparaître progressivement et la latence de réseau impacte peu l’expérience perçue. Activez toujours le streaming pour les interfaces de chat.

Tutoriels frères

• OpenWebUI : installer et configurer l’interface web pour vos LLM self-hosted — connecter votre serveur vLLM à une interface utilisateur complète et multi-utilisateurs.
• LiteLLM : proxy OpenAI-compatible pour router entre vLLM, Ollama et les APIs cloud — ajouter une couche de gestion des clés, de rate limiting et de fallback devant votre serveur vLLM.
• Ollama : faire tourner un LLM sur CPU sans GPU — guide 2026 — l’alternative CPU pour les TPE et les environnements sans GPU.

Pour aller plus loin

• Retour au pilier : LLM en self-hosted pour PME francophone : OpenWebUI, LiteLLM, vLLM (2026)
• Documentation officielle vLLM : docs.vllm.ai
• Dépôt GitHub officiel (exemples, benchmarks, roadmap) : github.com/vllm-project/vllm
• Tutoriel suivant recommandé dans le cluster : LiteLLM : proxy OpenAI-compatible pour router vos modèles

FAQ