vLLM : servir des modèles rapides

Ollama a rendu simple l'exécution d'une IA en local : une commande, un modèle, une conversation. Mais il existe une limite au-delà de laquelle il ne suffit plus — et savoir où elle se trouve est un savoir-faire. Elle apparaît quand plusieurs personnes utilisent le même modèle, quand vous avez besoin du modèle dans une application plutôt que dans un chat, quand une seule GPU doit produire plus qu'une requête à la fois.

C'est là qu'entre en scène vLLM. vLLM est un moteur open source d'inférence et de serving pour les grands modèles de langage, né au laboratoire UC Berkeley et aujourd'hui entretenu par une communauté de plus de 2 000 contributeurs. C'est le moteur de nombreuses installations en production, en local comme dans le cloud. Dans ce guide, je vous explique ce qu'il est, quand il vaut la peine de l'utiliser, comment l'installer, et les concepts de base — débit (throughput), quantification, KV cache — qu'il faut connaître pour dimensionner une installation.

Ce que vLLM est

vLLM est une bibliothèque Python. On lui donne un modèle (téléchargé depuis Hugging Face) et elle le sert en tant que serveur HTTP avec une API compatible OpenAI : mêmes points d'entrée, même format de requêtes, mêmes réponses que l'API officielle. Ce détail compte : tous les outils construits pour OpenAI (chats, applications, bibliothèques) fonctionnent avec vLLM en changeant simplement l'adresse.

Deux technologies rendent vLLM rapide.

PagedAttention. Pour générer une réponse, le modèle conserve un compte de tout ce qu'il a vu jusqu'ici : pour chaque token, les clés et les valeurs de l'attention (le KV cache). Ce compte grossit avec la longueur du contexte et consomme beaucoup de mémoire. PagedAttention gère cette mémoire en petits blocs, à la façon dont un système d'exploitation gère la mémoire virtuelle. Résultat : aucune mémoire réservée et restée inutilisée, et un contexte qui peut grandir sans fragmentation.

Batching continu. Quand plusieurs requêtes arrivent, vLLM les traite ensemble dans un batch. Et il ne s'arrête pas quand l'une d'elles se termine : la suivante dans la file entre en plein pas, en remplacement de la terminée. La GPU ne reste jamais inactive, même en attendant la fin de la réponse la plus longue.

L'effet pratique est la différence entre un serveur qui traite les requêtes une par une et un serveur qui en gère beaucoup à la fois : avec la même GPU, vLLM peut multiplier de plusieurs fois le nombre d'utilisateurs simultanés et la production totale.

Quand utiliser vLLM, et quand Ollama suffit

vLLM n'est pas le successeur d'Ollama, et il n'est pas « meilleur » en absolu. Il résout un problème différent.

Cas d'usage	Outil
Un utilisateur, une conversation à la fois, zéro configuration	Ollama ou LM Studio
Plusieurs personnes utilisent le même modèle depuis un réseau	vLLM
Une application qui appelle le modèle par API (assistant, documents, service interne)	vLLM
Vous voulez des sorties structurées (JSON) et du tool calling dans vos applications	vLLM
Vous voulez mesurer et maximiser le débit d'une GPU	vLLM
Vous voulez simplement discuter avec un modèle, rapidement	Ollama

La règle pratique : un utilisateur, Ollama ; plusieurs utilisateurs ou une application, vLLM. Ollama gagne sur la simplicité (une commande, une bibliothèque de modèles intégrée, fonctionne aussi sur CPU) ; vLLM gagne sur le débit et l'intégration. Les deux peuvent coexister : Ollama pour tester un modèle, vLLM pour le mettre au travail.

Une note sur le matériel : vLLM suppose une GPU NVIDIA avec CUDA (et depuis des versions récentes il tourne aussi sur AMD, Intel et TPU, et prend en charge Apple Silicon et CPU, mais avec des performances et des caractéristiques différentes). Pour l'usage local classique, une GPU NVIDIA avec au moins 12 à 16 Go de VRAM est un point de départ raisonnable.

Installation

vLLM s'installe comme un paquet Python. La méthode recommandée est uv, le gestionnaire de paquets Python rapide :

uv pip install vllm

Ou avec pip, si vous l'utilisez déjà :

pip install vllm

Si vous ne voulez pas toucher à Python sur votre machine, une image Docker officielle existe :

docker run --gpus all -p 8000:8000 vllm/vllm-openai serve Qwen/Qwen2.5-7B-Instruct

Une mise en garde : vLLM est un projet en mouvement. Le rythme de publication est très rapide (une nouvelle version mineure presque chaque mois), et chaque version apporte de nouveaux modèles, de nouvelles quantifications, de nouveaux matériels. Installez la version courante et lisez les notes de version — la fonctionnalité dont vous avez besoin (un modèle précis, une quantification précise) vient peut-être d'arriver.

Les concepts de base pour dimensionner votre installation

Débit (throughput). Mesuré en tokens par seconde, c'est la production du système. Il existe deux nombres, et ils racontent des choses différentes : la latence d'un utilisateur unique (à quelle vitesse votre propre réponse arrive, token par token) et le débit (tokens totaux générés par tous les utilisateurs simultanés). vLLM est optimisé pour le second : il peut sacrifier un peu de vitesse de chaque réponse individuelle en échange d'un grand gain sur le nombre de réponses servies à la fois. S'il n'y a qu'un seul utilisateur, cet échange ne paie pas — et c'est pourquoi Ollama suffit.

KV cache et VRAM. La mémoire dont un serveur a besoin a trois composantes : les poids du modèle, le KV cache (qui grossit avec la longueur du contexte et le nombre d'utilisateurs simultanés) et les calculs intermédiaires. Un modèle de 7B en FP16 occupe environ 14 Go rien que pour ses poids. Quantifié à 8 bits (INT8 ou FP8), il descend à 7 ou 8 Go. Sur une carte de 24 Go, vous avez de la place pour un modèle 14B en 8 bits, ou pour un modèle 7B avec un contexte très long et beaucoup d'utilisateurs simultanés.

Quantification. Quantifier, c'est représenter le modèle avec moins de bits par poids : 16 (FP16, précision complète), 8 (INT8/FP8), 4 (INT4, GPTQ/AWQ, GGUF). Moins de bits signifie moins de mémoire occupée et une GPU plus rapide ; le prix est une petite perte de qualité, qui varie selon le modèle et la quantification. vLLM prend en charge FP8, INT8, INT4 et des formats à 4 bits comme NVFP4 et GGUF. Choisir la bonne quantification est un compromis à tester en pratique, pas seulement en théorie : partez de 8 bits et descendez à 4 bits seulement si vous avez besoin de plus de contexte ou de plus d'utilisateurs simultanés.

Taille de batch et concurrence. Le paramètre --max-num-seqs plafonne le nombre de requêtes traitées en parallèle. Augmentez-le si vous avez beaucoup d'utilisateurs et beaucoup de VRAM ; gardez-le bas si vous voulez que chaque réponse individuelle soit la plus rapide possible.

Lancer un premier modèle

Voici la séquence minimale pour passer de zéro à une API qui répond.

vllm serve Qwen/Qwen2.5-7B-Instruct \
  --served-model-name qwen7b \
  --max-model-len 8192

vLLM télécharge le modèle depuis Hugging Face au premier lancement, le charge sur la GPU et démarre un serveur sur le port 8000. Pour le tester :

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen7b", "messages": [{"role": "user", "content": "Bonjour, qui es-tu ?"}]}'

La réponse est un JSON au format OpenAI. Le reste est simple : pointez Open WebUI ou tout autre client vers http://localhost:8000/v1 et utilisez le modèle comme s'il s'agissait de l'API OpenAI.

Conseils pratiques

1. Commencez par Ollama. Testez d'abord le modèle avec Ollama (ou LM Studio) : vous comprendrez s'il convient à votre usage avant d'investir dans un serveur.
2. Passez à vLLM quand l'usage est partagé. Un utilisateur sur un portable : vLLM ajoute de la complexité sans bénéfice. Un réseau de trois machines ou plus, ou une application qui appelle le modèle : vLLM paie immédiatement.
3. Mesurez, ne devinez pas. Après l'installation, testez la latence avec un seul utilisateur et le débit avec quelques requêtes concurrentes. Les chiffres vous diront si le matériel convient.
4. Ne quantifiez pas trop. 8 bits est le choix sûr par défaut ; 4 bits seulement quand vous avez besoin de contexte ou de concurrence.
5. Suivez les versions. Le rythme est rapide : une version qui ne supportait pas un modèle qui vous intéresse peut l'avoir fait depuis un mois.

En résumé

vLLM est l'étape qui transforme l'IA locale de « mon assistant » en « mon service » : le même modèle, la même GPU, mais un vrai serveur — concurrent, mesurable, intégrable à toute application. Quand vaut-il la peine de l'utiliser ? Quand il y a plusieurs utilisateurs, ou quand le modèle travaille dans une application. Quand vaut-il la peine de rester sur Ollama ? Quand vous êtes seul et que vous tenez une conversation : dans ce cas, la simplicité gagne.

Article généré par IA