vLLM : servir des LLM à haute performance en production avec l’open source
Ollama simplifie l’exécution locale de modèles de langage, mais quand il s’agit de servir des dizaines d’utilisateurs en parallèle avec des contraintes de latence et de débit, il faut passer à l’échelon supérieur. vLLM est un moteur d’inférence open source conçu spécifiquement pour le serving haute performance de LLM en production, avec un throughput jusqu’à 24× supérieur à une inférence naïve grâce à son algorithme PagedAttention.
Pourquoi vLLM plutôt qu’Ollama en production
Ollama excelle pour le prototypage et l’usage individuel. Mais dès que l’on doit gérer du batching continu (traiter plusieurs requêtes simultanément), optimiser l’utilisation mémoire GPU, ou garantir des temps de réponse stables sous charge, vLLM apporte des mécanismes que les solutions simples ne proposent pas. Son architecture repose sur PagedAttention, un algorithme qui gère la mémoire du cache KV comme un système de mémoire virtuelle paginée, éliminant le gaspillage mémoire et permettant de servir bien plus de requêtes concurrentes sur le même GPU.
Déployer vLLM sur Docker
Le déploiement se fait via une image Docker officielle. Un docker-compose.yml minimal suffit pour exposer un serveur compatible OpenAI API :
services:
vllm:
image: vllm/vllm-openai:latest
runtime: nvidia
ports:
- "8000:8000"
volumes:
- ./models:/root/.cache/huggingface
command: >
--model mistralai/Mistral-7B-Instruct-v0.3
--max-model-len 8192
--gpu-memory-utilization 0.90
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities: [gpu]Le serveur expose alors les endpoints /v1/chat/completions et /v1/completions, directement compatibles avec tout client OpenAI, y compris Open WebUI, n8n, ou Langfuse.
Les mécanismes clés de performance
PagedAttention découpe le cache KV (key-value) en blocs de taille fixe stockés de manière non contiguë en mémoire GPU. Contrairement aux approches classiques qui pré-allouent de la mémoire contiguë pour la longueur maximale de séquence, PagedAttention n’alloue que ce qui est réellement nécessaire, réduisant le gaspillage mémoire de 60 à 80 %.
Continuous batching permet d’insérer de nouvelles requêtes dans un batch en cours de traitement, sans attendre que toutes les requêtes du batch précédent soient terminées. Le GPU reste ainsi occupé en permanence, maximisant le throughput.
Tensor parallelism distribue un modèle trop large pour un seul GPU sur plusieurs cartes, avec un argument aussi simple que --tensor-parallel-size 2.
Quantization et modèles supportés
vLLM supporte nativement les formats de quantization les plus courants : GPTQ, AWQ, GGUF (via conversion), et FP8. Cela permet de servir des modèles 70B sur un GPU 24 Go en AWQ 4-bit, là où le modèle complet nécessiterait 140 Go de VRAM. La bibliothèque de modèles supportés couvre Llama 3, Mistral, Mixtral, Qwen 2.5, Phi-3, Gemma 2, DeepSeek-V2 et la plupart des architectures transformer courantes sur Hugging Face.
Intégration dans une stack auto-hébergée
Dans une architecture type askem.eu, vLLM s’insère naturellement :
- Traefik / Nginx en frontal pour le TLS et le routage
- Keycloak + ForwardAuth pour protéger l’accès au endpoint d’inférence
- Open WebUI comme interface utilisateur, pointée sur
http://vllm:8000/v1 - Langfuse pour tracer les requêtes, mesurer la latence P95 et évaluer la qualité
- n8n pour déclencher des appels LLM dans des workflows automatisés
- Qdrant pour la recherche vectorielle dans un pipeline RAG
Le fait que vLLM expose une API strictement compatible OpenAI signifie qu’aucune adaptation n’est nécessaire côté client : on change simplement l’URL de base.
Monitoring et mise à l’échelle
vLLM expose des métriques Prometheus nativement (/metrics), incluant le nombre de requêtes en cours, les tokens générés par seconde, l’utilisation du cache KV, et la latence par requête. Ces métriques s’intègrent directement dans un dashboard Grafana existant. Pour la mise à l’échelle, on peut déployer plusieurs instances vLLM derrière un load balancer, ou utiliser le disaggregated prefilling (séparation du calcul prefill et decode sur des GPU distincts) pour optimiser encore le throughput.
vLLM vs alternatives
Comparé à TGI (Text Generation Inference de Hugging Face), vLLM offre généralement un throughput supérieur grâce à PagedAttention et un batching plus agressif. Comparé à llama.cpp (dont Ollama est un wrapper), vLLM est optimisé pour les GPU NVIDIA avec CUDA et le serving multi-utilisateurs, là où llama.cpp excelle sur CPU et usage mono-utilisateur. Pour une infrastructure de production avec GPU, vLLM est aujourd’hui le choix de référence dans l’écosystème open source.
Pour aller plus loin
Le projet vLLM évolue rapidement : support multi-modal (images, audio), speculative decoding pour réduire la latence, prefix caching pour accélérer les prompts système récurrents, et intégration native avec des frameworks d’agents comme LangChain et LlamaIndex. C’est la brique de serving qui manque souvent entre « j’ai téléchargé un modèle » et « mon équipe l’utilise en production avec des SLA ».
