vLLM : définition, fonctionnement et déploiement sur GPU

vLLM est un serveur d'inférence spécialisé : il prend un LLM à poids ouverts et l'expose sous forme d'API, en cherchant à produire le plus grand nombre de tokens par seconde possible sur un GPU donné. Il s'adresse aux équipes qui veulent auto-héberger leurs modèles sans sacrifier les performances.

Le projet est né en 2023 dans un laboratoire de l'université de Californie à Berkeley. Ses auteurs partaient d'un constat : lors de l'inférence, la mémoire GPU est en grande partie consommée par le KV cache, le cache des calculs d'attention de chaque requête, et les serveurs de l'époque en gaspillaient une part importante par fragmentation. Leur réponse, PagedAttention, a été présentée dans un article scientifique à la conférence SOSP en 2023, en même temps que la publication du code en open source.

Depuis, vLLM est devenu l'un des moteurs de serving open source les plus utilisés. Il est soutenu par une large communauté de contributeurs, dont des fabricants de matériel et des fournisseurs de cloud, et sert de moteur à de nombreuses plateformes de déploiement. Son interface compatible avec l'API d'OpenAI a largement contribué à son adoption : une application écrite pour GPT peut basculer vers un modèle auto-hébergé en changeant une URL.

À retenir : vLLM n'est pas un modèle mais un moteur d'exécution. Il ne rend pas un modèle plus intelligent : il permet de le servir à plus d'utilisateurs, plus vite et à moindre coût.

Deux mécanismes expliquent l'essentiel des performances de vLLM. Ils s'attaquent aux deux gaspillages majeurs de l'inférence naïve : la mémoire et le temps de calcul inutilisés.

PagedAttention

Un LLM génère ses tokens un par un. Pour ne pas tout recalculer à chaque étape, il conserve les clés et valeurs d'attention des tokens précédents : c'est le KV cache, qui grandit à mesure que la réponse s'allonge. Les serveurs classiques réservaient pour chaque requête un bloc mémoire contigu dimensionné pour la longueur maximale, même si la réponse s'arrêtait après quelques phrases.

PagedAttention applique au KV cache le principe de la mémoire virtuelle d'un système d'exploitation. Le cache est découpé en petits blocs de taille fixe, alloués au fur et à mesure de la génération et repérés par une table de correspondance. Le gaspillage devient marginal, ce qui permet de faire tenir beaucoup plus de requêtes simultanées sur le même GPU. Le découpage en blocs permet aussi de partager des préfixes communs entre requêtes, par exemple un même prompt système, au lieu de les dupliquer.

Continuous batching

Regrouper des requêtes en lots exploite mieux la puissance du GPU. Mais avec un batching statique, le lot entier attend la fin de la requête la plus longue, et les nouvelles requêtes patientent. Le continuous batching raisonne à l'échelle de chaque étape de génération : dès qu'une requête se termine, sa place est attribuée à une nouvelle. Le GPU reste occupé en permanence et la latence d'attente diminue, surtout lorsque les longueurs de réponse sont très variables.

Sur une machine équipée d'un GPU NVIDIA, l'installation passe par pip, puis une seule commande lance un serveur compatible OpenAI.

pip install vllm

export VLLM_API_KEY="change-moi"

vllm serve Qwen/Qwen2.5-7B-Instruct \
  --port 8000 \
  --max-model-len 16384 \
  --gpu-memory-utilization 0.90 \
  --api-key "$VLLM_API_KEY"

Le modèle est téléchargé depuis le Hub de Hugging Face au premier lancement. --max-model-len borne la longueur de contexte pour limiter la mémoire réservée au KV cache, et --gpu-memory-utilization fixe la part de la mémoire GPU que vLLM s'autorise à utiliser. Une fois le serveur prêt, n'importe quel client OpenAI peut l'interroger :

import os
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key=os.environ["VLLM_API_KEY"],
)

response = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[
        {"role": "system", "content": "Tu réponds en français, de façon concise."},
        {"role": "user", "content": "Quels sont les avantages d'un modèle auto-hébergé ?"},
    ],
    temperature=0.2,
    max_tokens=300,
)
print(response.choices[0].message.content)

En production, on utilise plutôt l'image officielle, qui embarque le même serveur :

docker run --gpus all -p 8000:8000 --ipc=host \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e VLLM_API_KEY="$VLLM_API_KEY" \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen2.5-7B-Instruct

Ces trois outils exécutent des modèles ouverts, mais pour des contextes très différents. Ollama vise le poste de travail, vLLM et Text Generation Inference (TGI), le serveur de Hugging Face, visent la production.

D'autres moteurs, comme SGLang ou TensorRT-LLM de NVIDIA, complètent ce paysage. Le choix entre eux se fait idéalement sur un banc d'essai avec votre modèle, votre matériel et votre profil de requêtes.

Passer d'une commande sur une machine de test à un service fiable demande quelques décisions d'architecture.

• Dimensionner le GPU : la mémoire doit contenir les poids du modèle et laisser assez de place au KV cache pour le nombre de requêtes simultanées visé. Un modèle de 7 à 8 milliards de paramètres en 16 bits occupe environ 15 Go de poids.
• Répartir les grands modèles : l'option --tensor-parallel-size distribue un modèle sur plusieurs GPU d'un même serveur.
• Quantifier : un modèle publié en version AWQ, GPTQ ou FP8 réduit la mémoire nécessaire, au prix d'une légère perte de qualité à évaluer. Voir notre article sur la quantization.
• Orchestrer : sur Kubernetes, chaque instance tourne dans un pod doté de GPU, éventuellement géré par une plateforme comme KServe, avec mise à l'échelle selon la file d'attente.
• Sécuriser et router : une passerelle placée devant vLLM gère l'authentification, les quotas par équipe et le routage entre modèles.
• Superviser : vLLM expose des métriques au format Prometheus (latence du premier token, débit, occupation du KV cache) à suivre dans un tableau de bord.

Le guide vLLM : serveur d'inférence pour LLM détaille ces étapes et les optimisations disponibles.