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. Il charge un modèle au format Hugging Face (safetensors) sur un ou plusieurs GPU et l'expose sur une API HTTP compatible OpenAI. Sa raison d'être tient en un mot : le débit, c'est-à-dire le nombre total de tokens produits par seconde quand dix, cinquante ou deux cents requêtes arrivent en même temps.

#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 est décrit dans l'article fondateur de vLLM (Kwon et al., SOSP 2023) : dans les systèmes existants, 60 à 80 % de la mémoire réservée au cache KV était gaspillée, entre la réservation excessive et la fragmentation. Moins de mémoire utile, c'est moins de requêtes servies en parallèle, donc un GPU à plusieurs milliers d'euros qui tourne à une fraction de sa capacité.

#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. Un serveur classique attend que toutes les requêtes d'un lot soient terminées avant d'en démarrer un autre : la requête courte patiente derrière la longue. vLLM recompose le lot à chaque token généré. Dès qu'une réponse se termine, sa place est donnée à une requête en attente, et le GPU ne tourne jamais à vide.

Préfixes partagés

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

Parallélisme tensoriel

Un modèle trop gros pour une carte est réparti sur plusieurs GPU d'une même machine avec une seule option, --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 comme celles d'OpenAI : une application existante change d'URL de base, pas de code.

#Ce que vLLM charge en mémoire

C'est la surprise la plus fréquente en venant d'Ollama. Ollama télécharge par défaut un GGUF quantifié en 4 bits. vLLM, lui, charge les poids publiés sur Hugging Face, le plus souvent en BF16, soit environ 2 Go par milliard de paramètres. Le même modèle pèse donc trois fois plus lourd, avant même de compter le cache KV.

La parade consiste à servir une version quantifiée pour GPU : un modèle AWQ ou GPTQ en 4 bits occupe à peu près la même place qu'un GGUF Q4, et le FP8 divise le BF16 par deux sur les cartes récentes. La plupart des modèles populaires existent dans ces formats sur Hugging Face.

#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 tient en une ligne dans un environnement Python propre. La commande serve télécharge le modèle depuis Hugging Face au premier lancement puis ouvre l'API sur le port 8000.

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 dès le départ : sans elle, vLLM dimensionne le cache pour la fenêtre de contexte maximale du modèle, parfois 128 000 tokens ou plus, et refuse de démarrer si la mémoire ne suit pas. La mise en production proprement dite (Docker, authentification, supervision, montée en charge) fait l'objet d'un guide séparé.

• Déployer vLLM en production : Docker, sécurité, supervision
• Documentation officielle de vLLM
• L'article PagedAttention (Kwon et al., 2023)

#Pour qui, et pour qui pas

• Ollama ou vLLM en production : le comparatif détaillé
• llama.cpp vs vLLM vs ExLlama : trois moteurs, trois usages
• Calculer la VRAM nécessaire pour votre modèle

#FAQ