vLLM : c'est quoi, pour qui, et quand l'utiliser ?

#vLLM en trois phrases

vLLM est une bibliothèque Python et un serveur d'inférence nés en 2023 au Sky Computing Lab de l'université de Berkeley, publiés sous licence Apache 2.0, une licence permissive qui autorise la réutilisation commerciale sans restriction. Il charge un modèle au format Hugging Face, le plus souvent en safetensors, sur un ou plusieurs GPU et l'expose sur une API HTTP compatible OpenAI, ce qui permet de brancher dessus n'importe quel client déjà écrit pour l'API d'OpenAI sans changer une ligne de code applicatif, seulement l'URL de base. Sa raison d'être tient en un mot : le débit, c'est-à-dire le nombre total de tokens produits par seconde par le GPU quand dix, cinquante ou deux cents requêtes différentes arrivent en même temps et doivent toutes obtenir une réponse rapide.

#Le problème que vLLM résout

Quand un LLM génère du texte, il garde en mémoire une trace de tout ce qu'il a déjà lu et écrit : le cache KV. Ce cache grossit à chaque token, et sa taille finale est imprévisible puisqu'on ne sait pas à l'avance si la réponse fera vingt mots ou deux mille. Les serveurs d'inférence de première génération réservaient donc, pour chaque requête, un bloc de mémoire contigu dimensionné pour le pire cas.

Le résultat chiffré est décrit noir sur blanc dans l'article fondateur de vLLM (Kwon et al., SOSP 2023) et repris par l'équipe du projet elle-même : dans les systèmes existants, 60 à 80 % de la mémoire réservée au cache KV était purement et simplement gaspillée, entre la réservation excessive par précaution et la fragmentation qui laisse des trous inutilisables entre les blocs alloués. Moins de mémoire réellement utile disponible, c'est mécaniquement moins de requêtes servies en parallèle sur la même carte, donc un GPU à plusieurs milliers d'euros qui tourne, in fine, à une fraction dérisoire de sa capacité théorique alors même que la facture d'électricité et l'amortissement matériel restent identiques.

#PagedAttention et batching continu

vLLM repose sur deux idées. La première, PagedAttention, est empruntée aux systèmes d'exploitation : au lieu d'un grand bloc contigu par requête, le cache KV est découpé en petites pages de taille fixe, allouées à la demande et rangées n'importe où en mémoire. Une table fait le lien entre l'ordre logique des tokens et l'emplacement physique des pages, exactement comme la mémoire virtuelle d'un ordinateur. Le gaspillage tombe sous les 4 % selon les auteurs.

La seconde idée est le batching continu, complémentaire de la première. Un serveur classique groupe les requêtes en lots et attend que toutes celles d'un même lot soient terminées avant d'en démarrer un autre : la requête courte qui aurait pu repartir tout de suite patiente inutilement derrière la longue qui monopolise encore le GPU. vLLM, lui, recompose entièrement le lot à chaque token généré, à chaque étape de décodage. Dès qu'une réponse se termine, sa place dans le lot est immédiatement redonnée à une requête en attente dans la file, et le GPU ne tourne jamais à vide à faire du remplissage inutile. C'est la combinaison de ce recyclage permanent des places et de la mémoire paginée qui produit l'essentiel du gain de débit observé par rapport aux moteurs d'inférence pensés pour un seul utilisateur à la fois.

Préfixes partagés

Quand plusieurs requêtes commencent par exactement le même texte (un prompt système, un document commun), les pages correspondantes sont calculées une seule fois et partagées entre elles. C'est le prefix caching.

Parallélisme tensoriel

Un modèle trop volumineux pour tenir sur une seule carte est réparti automatiquement sur plusieurs GPU d'une même machine avec une seule option de démarrage, --tensor-parallel-size.

Quantification côté serveur

vLLM lit les formats AWQ, GPTQ et FP8, pensés pour le calcul GPU par lots. Le GGUF est pris en charge à titre expérimental seulement.

API compatible OpenAI

Les routes /v1/chat/completions et /v1/completions répondent exactement comme celles d'OpenAI : une application déjà existante change simplement d'URL de base, sans réécrire une seule ligne de code métier.

#Ce que vLLM charge en mémoire

C'est la surprise la plus fréquente pour qui arrive d'Ollama et s'attend à réutiliser directement ses habitudes. Ollama télécharge par défaut un GGUF quantifié en 4 bits, pensé pour tenir sur une carte grand public. vLLM, lui, charge par défaut les poids publiés tels quels sur Hugging Face, le plus souvent en BF16 (précision 16 bits), soit environ 2 Go par milliard de paramètres du modèle. Le même modèle pèse donc grossièrement trois fois plus lourd en mémoire sous vLLM que sous Ollama, et ce avant même de compter le cache KV qui grossit avec chaque conversation en cours, ce qui explique pourquoi une carte suffisante pour Ollama peut se révéler bien trop petite pour vLLM sans changer de format de poids.

La parade la plus courante consiste à servir une version déjà quantifiée pour GPU plutôt que les poids d'origine complets : un modèle AWQ ou GPTQ en 4 bits occupe à peu près la même place en mémoire qu'un GGUF Q4 équivalent, et le format FP8 divise à peu près par deux la taille du BF16 sur les cartes récentes qui le prennent en charge nativement. La grande majorité des modèles réellement populaires existent déjà publiés dans l'un de ces formats sur Hugging Face, souvent le jour même de leur sortie officielle.

#Matériel et systèmes pris en charge

#Le lancer en cinq minutes

Sur une machine Linux avec un GPU NVIDIA et des pilotes à jour, l'installation complète tient en quelques lignes dans un environnement Python propre, sans configuration complexe préalable à écrire. La commande vllm serve télécharge le modèle indiqué depuis Hugging Face au tout premier lancement, le charge en mémoire, puis ouvre immédiatement l'API sur le port 8000 par défaut, prête à recevoir des requêtes dans le format OpenAI standard.

python -m venv vllm-env && source vllm-env/bin/activate
pip install vllm

vllm serve Qwen/Qwen3-8B --max-model-len 8192

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "Qwen/Qwen3-8B", "messages": [{"role": "user", "content": "Bonjour"}]}'

L'option --max-model-len mérite d'être fixée explicitement dès le tout premier lancement : sans elle, vLLM dimensionne le cache KV pour la fenêtre de contexte maximale annoncée par le modèle, parfois 128 000 tokens ou davantage sur les modèles récents, et refuse purement et simplement de démarrer si la mémoire disponible sur la carte ne suit pas ce dimensionnement par défaut, une erreur fréquente au tout premier essai. La mise en production proprement dite, avec conteneur Docker, authentification des appels, supervision continue et montée en charge progressive, fait l'objet d'un guide séparé et plus détaillé.

• Déployer vLLM en production : Docker, sécurité, supervision
• Documentation officielle de vLLM
• L'article PagedAttention (Kwon et al., 2023)
• Source : l'annonce officielle de vllm-metal (22/09/2026)
• Source : dépôt GitHub officiel du projet vLLM

#Pour qui, et pour qui pas

• llama.cpp vs vLLM vs ExLlama : trois moteurs, trois usages
• llama.cpp : c'est quoi, et faut-il quitter Ollama ?
• Calculer la VRAM nécessaire pour votre modèle

#FAQ