vLLM est un moteur open source d’inférence et de serving conçu pour exécuter des grands modèles de langage avec un débit élevé et une utilisation efficace de la mémoire GPU. Son idée la plus connue est PagedAttention : gérer le KV cache de façon plus proche de la mémoire virtuelle afin de réduire le gaspillage mémoire lors du serving.

Nous avons abordé vLLM comme un sujet de découverte, pas comme une compétition de benchmarks. La vraie question était : qu’est-ce que vLLM change lorsqu’un modèle open source passe de « il tourne » à « il doit réellement servir des requêtes en production » ?

Cette distinction est importante pour thaink² et ApowerB. Un runtime agentique peut orchestrer modèles, outils, état et workflows, mais il lui faut toujours une couche d’inférence lorsqu’une entreprise choisit d’auto-héberger un modèle. vLLM fait partie des solutions les plus établies pour cette couche.

Qu’est-ce que vLLM ?

vLLM est un moteur de serving et d’inférence LLM à haut débit, optimisé pour l’efficacité mémoire. Il permet de charger de nombreux modèles open source, de les exposer via une API compatible OpenAI et d’optimiser la manière dont les requêtes partagent mémoire GPU et capacité de calcul.

La documentation actuelle de vLLM met notamment en avant PagedAttention, le continuous batching, le chunked prefill, le prefix caching, le speculative decoding, différents formats de quantification, l’inférence distribuée et la prise en charge d’un grand nombre d’architectures de modèles et de backends matériels.

vLLM n’est donc pas un framework d’agents IA. Il ne décide pas quel outil métier appeler, ne porte pas l’état métier d’un workflow et ne remplace pas une couche de gouvernance. Son rôle se rapproche davantage de :

application ou runtime agentique → API d’inférence → vLLM → modèle → GPU / accélérateur

Pour la couche située au-dessus de l’inférence, consultez notre guide sur les agents IA prêts pour la production et notre comparatif des plateformes d’orchestration IA.

Pourquoi vLLM est devenu important

Servir un modèle autorégressif ne consiste pas uniquement à exécuter des opérations matricielles. Chaque séquence active génère des tenseurs de clés et de valeurs, le KV cache, qui doivent rester disponibles pendant toute la génération.

Le travail initial autour de vLLM s’est concentré sur ce problème de gestion mémoire. Lorsque le KV cache est réservé de manière trop rigide, une partie de la mémoire GPU peut être perdue à cause de la fragmentation ou de sur-réservations.

PagedAttention répond à ce problème en permettant aux blocs du KV cache d’être stockés de manière non contiguë. L’idée est inspirée des mécanismes de pagination des systèmes d’exploitation.

L’objectif pratique est simple : faire tenir davantage de travail utile dans le même matériel sans obliger chaque requête à réserver une grande zone contiguë de mémoire GPU.

Comment fonctionne vLLM ?

1. Charger le modèle

vLLM prend en charge de nombreuses architectures issues de l’écosystème Hugging Face. Le serveur charge les poids et initialise le chemin d’exécution adapté au matériel disponible.

2. Gérer le KV cache avec PagedAttention

Au lieu de considérer le KV cache de chaque séquence comme une seule grande allocation contiguë, PagedAttention le découpe en blocs. Le runtime peut alors mieux gérer les séquences de longueurs différentes et les requêtes qui arrivent ou se terminent à des moments différents.

3. Regrouper les requêtes en continu

Le continuous batching permet au scheduler d’intégrer de nouveaux travaux pendant que d’autres séquences se terminent, plutôt que d’attendre la constitution d’un batch fixe.

4. Réutiliser les calculs lorsque c’est possible

Le prefix caching peut réutiliser des calculs déjà réalisés pour des préfixes de prompts identiques. Le chunked prefill découpe les longs prompts afin de mieux faire cohabiter préfill et génération.

5. Exposer une API de serving

vLLM propose un serveur HTTP compatible avec l’API OpenAI pour plusieurs endpoints, dont les chat completions selon le type de modèle. Une application déjà construite autour d’un client OpenAI peut donc pointer vers un modèle auto-hébergé avec relativement peu de changements côté application.

Qu’est-ce que PagedAttention dans vLLM ?

PagedAttention est le mécanisme le plus associé à vLLM. Le KV cache d’une séquence augmente au fil de la génération. Si la mémoire est réservée de manière trop rigide, le GPU peut se retrouver fragmenté alors qu’il reste encore de la mémoire totale disponible.

PagedAttention divise ce cache en blocs de taille fixe et fait correspondre des blocs logiques à des blocs physiques en mémoire GPU. L’analogie avec la mémoire virtuelle est particulièrement utile : la vue logique peut rester continue même si l’allocation physique ne l’est pas.

Cela ne rend pas la mémoire infinie. Cela rend son allocation plus flexible, ce qui correspond précisément aux contraintes d’un serveur gérant de nombreuses séquences de longueurs variables.

Ce que nous avons testé

Lors de notre prise en main, nous avons traité vLLM comme un véritable serveur d’inférence plutôt que comme une simple bibliothèque Python.

Notre objectif n’était pas de publier un « vLLM est X % plus rapide » sans protocole de benchmark contrôlé. Nous voulions valider le chemin opérationnel qui compte dans une plateforme agentique :

1. lancer le moteur d’inférence sur un GPU NVIDIA compatible CUDA ;

2. charger un modèle open source représentatif ;

3. l’exposer via le serveur compatible OpenAI ;

4. envoyer des requêtes de type chat via l’API ;

5. observer comment cet endpoint d’inférence pourrait se placer derrière un runtime agentique comme ApowerB.

Cette prudence est volontaire. Les chiffres de débit dépendent énormément du modèle, de la quantification, du GPU, de la longueur de contexte, de la concurrence, de la version de vLLM et de la configuration.

Exemple minimal de serveur vLLM

vllm serve MODEL_ID \
  --dtype auto \
  --api-key YOUR_TOKEN

vllm serve MODEL_ID \
  --dtype auto \
  --api-key YOUR_TOKEN

La documentation vLLM propose également des images Docker officielles et un chemin GPU NVIDIA. Pour la production, nous préférerions figer la version de vLLM, la révision du modèle, la quantification et l’image de conteneur plutôt que de dépendre d’un tag mutable.

vLLM et compatibilité OpenAI

La compatibilité OpenAI est stratégiquement importante parce qu’elle découple une partie du code applicatif du fournisseur du modèle. Un runtime agentique peut conserver une interface familière tout en envoyant les requêtes vers un modèle auto-hébergé.

Compatible ne veut toutefois pas dire identique. vLLM expose certains paramètres propres au moteur, tandis que certains paramètres OpenAI peuvent avoir un comportement différent ou ne pas être pris en charge selon le modèle.

Les points forts de vLLM

Serving à haut débit

Son architecture est pensée pour l’inférence concurrente et l’utilisation efficace du GPU, pas seulement pour un usage local mono-utilisateur.

Écosystème mature

vLLM dispose d’une documentation abondante, d’un projet GitHub très actif et d’une présence directe dans la documentation NVIDIA sur les frameworks optimisés.

Large support de modèles et de matériel

La documentation actuelle couvre NVIDIA CUDA, AMD ROCm, CPU et d’autres backends ou plugins matériels.

API compatible OpenAI

Cela réduit fortement la friction d’intégration pour les applications déjà écrites autour de ce type d’API.

Fonctionnalités avancées d’inférence

Continuous batching, prefix caching, speculative decoding, quantification, inférence distribuée et chemins d’attention optimisés font partie des fonctionnalités majeures.

Ce que vLLM ne résout pas

C’est là qu’ApowerB devient complémentaire plutôt que concurrent. ApowerB prend en charge la couche agent/runtime : exécution, outils, état, API et workflows. vLLM peut fournir la couche d’inférence sous-jacente.

vLLM vs Ollama : deux usages différents

Les données de recherche autour de vLLM montrent un intérêt important pour les comparaisons avec Ollama. La distinction la plus utile concerne le type de workload.

Ollama est populaire pour lancer facilement des modèles en local. vLLM est surtout optimisé pour le serving, la concurrence et l’exploitation d’accélérateurs.

Comparer leurs performances n’a de sens que si le modèle, la quantification, le matériel, la longueur des prompts et la concurrence sont contrôlés.

vLLM supporte-t-il GGUF ?

La documentation vLLM inclut GGUF parmi les formats ou chemins pris en charge. Les détails peuvent cependant dépendre de l’architecture du modèle et de la version utilisée. Si GGUF est critique pour votre déploiement, testez le checkpoint exact.

Peut-on utiliser vLLM sans GPU ?

Oui. La documentation actuelle inclut des chemins CPU. Néanmoins, la proposition de valeur la plus forte de vLLM concerne généralement l’inférence accélérée et la gestion efficace de nombreuses requêtes concurrentes.

Où vLLM se place dans une stack IA de production

expérience produit / agent → ApowerB ou autre runtime agentique → endpoint vLLM → modèle open source → NVIDIA / AMD / autre compute

Cette séparation permet à la couche agent de se concentrer sur la logique métier et au moteur de serving de se concentrer sur tokens, batching, cache et utilisation du matériel.

L’inférence n’est qu’une couche de la stack

Découvrez ApowerB pour la couche open source autour des modèles : agents, outils, état, orchestration et déploiement.

Ce que nous benchmarkerions avant de choisir vLLM

• time to first token sur les longueurs de prompts réelles ;

• débit de génération sous concurrence réaliste ;

• mémoire GPU et concurrence maximale stable ;

• comportement avec la quantification choisie ;

• compatibilité tool calling / structured output ;

• temps de chargement du modèle ;

• comportement après échec ou redémarrage ;

• coût par requête utile, pas seulement tokens/seconde.

Notre avis après cette prise en main

vLLM devient particulièrement intéressant lorsque l’inférence elle-même devient un problème d’infrastructure : nombreuses requêtes, accélérateurs coûteux, longs contextes, forte concurrence et besoin d’une API de serving stable.

Il est donc plus pertinent de le considérer comme un moteur spécialisé d’inférence que comme « un autre framework IA ».

Pour cette prise en main, nous avons fait tourner le chemin de serving sur un GPU NVIDIA via CUDA. Ce détail compte parce que les performances d’inférence dépendent fortement du matériel. Le même modèle et la même stack peuvent se comporter très différemment selon la génération de GPU, la VRAM, la quantification et le niveau de concurrence. Nous présentons donc ce test comme une validation d’architecture, pas comme un benchmark universel.