Accueil › Glossaire › vLLM

vLLM (Virtual Large Language Model)

vLLM est un moteur d’inférence et de serving open source pour LLM, conçu pour maximiser le throughput et l’efficacité mémoire sur GPU. Son innovation fondatrice, PagedAttention, gère le cache KV comme un système de mémoire paginée, éliminant la fragmentation mémoire et permettant de servir significativement plus de requêtes concurrentes avec la même VRAM.

Développé initialement au Sky Computing Lab de UC Berkeley, vLLM est devenu un projet communautaire massif avec des contributions de l’industrie et du monde académique. C’est le moteur d’inférence LLM le plus adopté en production. Il offre une API compatible OpenAI, supporte une très large gamme de modèles et de formats de quantification, et fonctionne sur NVIDIA, AMD, Intel, et d’autres plateformes via un système de plugins matériels.

PagedAttention : l’innovation fondatrice

Le cache KV (Key-Value) est le composant qui stocke les états d’attention pour chaque requête en cours. Dans un serving LLM classique, chaque requête alloue un bloc contigu de mémoire pour son cache KV, dimensionné pour la longueur de contexte maximale. Le problème : cette allocation statique gaspille de la mémoire (la plupart des requêtes n’utilisent pas le contexte maximal) et crée de la fragmentation.

PagedAttention, l’innovation clé de vLLM, s’inspire de la mémoire virtuelle des systèmes d’exploitation. Au lieu d’allouer un bloc contigu par requête, le cache KV est découpé en petits blocs (pages) de taille fixe. Chaque requête reçoit les pages dont elle a besoin, et les pages inutilisées sont recyclées. Résultat : quasi zéro fragmentation mémoire et une utilisation bien plus efficace de la VRAM pour le cache.

L’impact en production est concret : à VRAM égale, vLLM peut servir significativement plus de requêtes concurrentes qu’un serving naïf. Combiné au continuous batching, cela se traduit par un throughput nettement supérieur et des coûts d’inférence réduits.

Histoire et évolution

vLLM a été créé par Woosuk Kwon et ses collaborateurs au Sky Computing Lab de UC Berkeley. Le papier fondateur, « Efficient Memory Management for Large Language Model Serving with PagedAttention », a été publié en 2023 et a immédiatement attiré l’attention de la communauté pour son approche élégante au problème de la gestion mémoire dans le serving LLM.

Le projet a évolué rapidement, passant d’un projet académique à un outil de production largement adopté. L’écosystème s’est structuré avec des releases mensuelles, une roadmap publique par trimestre (avec des SIGs thématiques : model performance, multi-modality, torch.compile, large-scale serving, etc.), et des contributions de NVIDIA, AMD, Intel, Hugging Face, Red Hat, et de nombreuses startups IA.

Les jalons majeurs récents incluent le moteur V1 (alpha en janvier 2025, défaut en 2025-2026), le support gRPC, l’API Realtime WebSocket pour l’audio, l’intégration RLHF native, et le support NVFP4 pour les GPU Blackwell. La version stable actuelle est v0.17.1 (11 mars 2026).

Compatibilité matérielle

vLLM se distingue par le support matériel le plus large de tous les moteurs de serving LLM :

L’architecture V1

Le moteur V1, devenu le moteur par défaut dans les releases 2025-2026, représente une ré-architecture majeure des composants cœur de vLLM :

EngineCore isolé. L’architecture V1 utilise le multiprocessing avec ZeroMQ pour isoler la boucle d’exécution principale (scheduler + model executor) des tâches CPU (tokenisation, traitement des entrées multimodales, détokenisation, streaming des réponses). Cela maximise l’overlap entre le GPU et le CPU.

Scheduler unifié. V1 supprime la distinction traditionnelle entre les phases « prefill » et « decode ». Les tokens d’entrée (prompt) et les tokens générés sont traités uniformément. Les décisions de scheduling sont représentées comme un simple dictionnaire {request_id: num_tokens}, ce qui simplifie considérablement le code et permet des optimisations plus agressives.

Async scheduling + Pipeline Parallelism. Le scheduling asynchrone, activé par défaut, overlap les décisions de scheduling du CPU avec l’exécution GPU. Combiné avec le pipeline parallelism (supporté depuis les versions récentes), cela produit des gains mesurables : 30,8 % d’amélioration du throughput end-to-end et 31,8 % d’amélioration du time-per-output-token dans les benchmarks internes.

Chunked prefill + disaggregated serving. Le chunked prefill découpe les longs prompts en morceaux qui s’entrelacent avec les batches de décodage, empêchant une requête long-contexte de monopoliser le GPU. Le disaggregated serving sépare physiquement les phases de prefill (compute-bound) et de decode (memory-bandwidth-bound), éliminant les pics de latence causés par le blocage mutuel.

Support de quantification

vLLM offre le support de quantification le plus large de tous les moteurs d’inférence LLM :

Les kernels Marlin sont le facteur d’accélération le plus important pour les modèles quantifiés. Sur un Qwen2.5-32B avec H200, Marlin-AWQ atteint 741 tok/s contre 68 tok/s pour AWQ standard (10,9× plus rapide). Activez Marlin avec --quantization marlin.

Utilisation pratique

Serving (production)

Le flag --max-model-len auto (depuis v0.14) ajuste automatiquement la longueur de contexte à la mémoire GPU disponible, éliminant les erreurs OOM au démarrage.

API Python

Appeler vLLM comme un serveur OpenAI

Toute application compatible avec l’API OpenAI fonctionne avec vLLM sans modification. C’est un avantage considérable pour la migration depuis les API cloud vers l’inférence locale ou self-hosted.

Fonctionnalités avancées

Décodage spéculatif. vLLM supporte le décodage spéculatif (y compris avec les structured outputs depuis les versions récentes) pour accélérer la génération token par token en utilisant un petit modèle draft.

Structured outputs. Enforcement de schémas JSON via guided decoding, critique pour les workflows d’agents et les appels d’outils (function calling).

Multimodal. Support natif des modèles images + texte (LLaVA, Qwen-VL, InternVL, Llama 4 Scout/Maverick), avec streaming des entrées multimodales.

Automatic prefix caching (APC). Quand plusieurs requêtes partagent un même préfixe (system prompt commun dans un chatbot), vLLM met en cache et réutilise les blocs KV de ce préfixe, réduisant le time-to-first-token pour les requêtes suivantes.

Realtime API. Un nouveau protocole WebSocket pour les interactions audio en streaming, construit sur l’infrastructure Voxtral realtime.

RLHF integration. APIs natives pour le weight syncing via NCCL, le rechargement par couche pour QeRL, et la pause/reprise du moteur avec préservation des requêtes en cours.

gRPC server. Une alternative au REST avec protocole binaire et multiplexage HTTP/2 pour les environnements à haute concurrence.

Parallélisme distribué

Pour les modèles qui ne tiennent pas sur un seul GPU, vLLM supporte trois stratégies de parallélisme :

Tensor Parallelism (TP). Divise chaque couche du modèle entre plusieurs GPU. C’est la stratégie la plus courante. Un modèle 70B en FP16 (~140 Go) peut être divisé sur 2 GPU H100 80 Go avec --tensor-parallel-size 2. La communication inter-GPU utilise NCCL et nécessite des connexions rapides (NVLink idéalement).

Pipeline Parallelism (PP). Assigne des couches entières à différents GPU, chaque GPU traitant un « étage » du pipeline. Mieux adapté aux configurations sans NVLink (communication inter-nœud), mais avec une latence plus élevée que le TP. Pleinement supporté avec l’async scheduling depuis les versions récentes.

Expert Parallelism (EP). Spécifique aux modèles MoE (Mixture of Experts) comme DeepSeek V3/R1 ou Mixtral. Distribue les experts sur différents GPU plutôt que de répliquer chaque expert. Particulièrement efficace pour les modèles MoE massifs où le nombre total de paramètres est très élevé mais seuls quelques experts sont actifs par token.

Les trois stratégies peuvent être combinées. Un déploiement typique de DeepSeek V3 sur un cluster multi-nœud utilise TP intra-nœud (entre les GPU connectés en NVLink), PP inter-nœud (entre les serveurs), et EP pour distribuer les experts MoE.

vLLM vs les alternatives

Déploiement production : points clés

GPU memory utilization. Le paramètre --gpu-memory-utilization (par défaut 0.9) contrôle le pourcentage de VRAM alloué à vLLM. En production, 0.90-0.92 est recommandé. Laisser 8-10 % de marge évite les OOM sous charge.

Continuous batching. Activé par défaut. Les requêtes entrantes sont dynamiquement regroupées pour maximiser l’utilisation GPU. Nécessite des requêtes concurrentes pour être efficace : un seul utilisateur séquentiel ne bénéficiera pas du batching.

FP8 sur H100/B200. Le flag --dtype fp8 active la quantification FP8 pour un gain de throughput important. Vérifiez la compatibilité : FP8 nécessite des Tensor Cores FP8 (Hopper+). Sur A100 ou plus ancien, le flag sera ignoré ou causera une erreur.

KV cache quantifié. Indépendamment de la quantification des poids, --kv-cache-dtype fp8 quantifie le cache KV pour doubler la capacité de requêtes concurrentes à contexte long.

Pré-téléchargement des modèles. En production, téléchargez les modèles à l’avance avec huggingface-cli download et montez le répertoire local. Cela découple le téléchargement du démarrage du conteneur, réduisant les temps de déploiement.