vLLM — serveur d’inférence GPU haut débit (à l’échelle de la production)
vLLM est le moteur d’inférence open source pour servir des LLM à grande échelle. PagedAttention, le batching continu et le cache de préfixes en font l’option au débit le plus élevé pour servir plusieurs utilisateurs en production sur GPU.
Why vLLM
vLLM est sorti de UC Berkeley en 2023 avec une intuition précise : les implémentations standard de l’attention gaspillent de la mémoire GPU au moment du service car elles allouent des buffers de la longueur de séquence complète par requête. PagedAttention découpe le KV cache en pages que le moteur peut partager et récupérer dynamiquement, augmentant fortement la taille de batch effective sur le même GPU. En 2026, PagedAttention est devenu un standard dans la plupart des moteurs d’inférence haute performance, mais vLLM reste l’implémentation la plus mature et la plus déployée.
L’autre fonctionnalité critique est le batching continu — les nouvelles requêtes rejoignent un batch actif plutôt que d’attendre la fin de la requête la plus lente. Effet concret : la latence reste basse sous charge alors que le débit évolue de manière quasi-linéaire avec la capacité du GPU. Pour les produits SaaS servant de nombreux utilisateurs, cela peut à lui seul diviser votre facture GPU par deux par rapport à un batching naïf.
Qui devrait utiliser vLLM : les équipes servant plus de 10 utilisateurs simultanés sur du matériel GPU. En dessous de ce seuil, Ollama ou llama.cpp server vous y mèneront avec moins de complexité. Au-dessus, vLLM (ou ses dérivés comme SGLang, TensorRT-LLM) est le choix par défaut. Le déploiement est très orienté Python avec des dépendances CUDA — prévoyez du vrai temps d’ops.
Quick Start — Serve a Model with OpenAI API
Définissez --tensor-parallel-size N pour répartir le modèle sur N GPU d’un même nœud. --pipeline-parallel-size pour le multi-nœud. Utilisez --quantization awq/gptq pour des poids pré-quantifiés, ou --kv-cache-dtype fp8 sur les GPU Hopper+ pour doubler le KV cache effectif. Surveillez l’endpoint de métriques :8000/metrics pour la profondeur de la file de requêtes et l’utilisation GPU.
# pip install vllm (requires CUDA-capable GPU)
# 1. Start the OpenAI-compatible server
vllm serve meta-llama/Llama-3.2-3B-Instruct \
--dtype auto \
--max-model-len 8192 \
--gpu-memory-utilization 0.90
# Server listens on http://0.0.0.0:8000/v1 with OpenAI-shape endpoints:
# POST /v1/chat/completions
# POST /v1/completions
# POST /v1/embeddings
# GET /v1/models
# 2. Use any OpenAI SDK against it
python - <<'PY'
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="vllm")
r = client.chat.completions.create(
model="meta-llama/Llama-3.2-3B-Instruct",
messages=[{"role":"user","content":"What problem does PagedAttention solve?"}],
)
print(r.choices[0].message.content)
PY
# 3. Production deployment: Docker image
docker run --runtime nvidia --gpus all \
-v ~/.cache/huggingface:/root/.cache/huggingface \
-p 8000:8000 --ipc=host \
vllm/vllm-openai:latest \
--model meta-llama/Llama-3.2-3B-Instruct \
--tensor-parallel-size 1 # increase for multi-GPUFonctionnalités clés
PagedAttention
Le KV cache découpé en pages permet au moteur de partager la mémoire entre requêtes — augmente massivement la taille de batch effective. La fonctionnalité phare qui a mis vLLM sur la carte.
Batching continu
Les nouvelles requêtes rejoignent les batchs actifs en plein vol ; les séquences terminées libèrent des slots immédiatement. Maintient l’utilisation GPU proche de 100 % sous trafic réel.
Prefix caching
Réutilise les préfixes du KV cache entre requêtes partageant le même prompt système ou les mêmes exemples few-shot. Gros gain de vitesse pour les charges agentiques aux prompts répétitifs.
Parallélisme tensor et pipeline
Répartissez un même modèle sur plusieurs GPU d’un même nœud (tensor) ou entre plusieurs nœuds (pipeline). Indispensable pour les modèles 70B+ ou pour un débit extrême.
Large support de modèles
Llama 3.x, Qwen 2.5, Mistral, DeepSeek, Gemma, Phi, Command-R, multimodal (LLaVA, Qwen-VL, Llama 3.2 vision). Les nouvelles architectures arrivent rapidement après leur sortie.
API compatible OpenAI
chat/completions, completions et embeddings respectent tous la spec OpenAI. Remplacement direct ; fonctionne aussi avec LangChain, LiteLLM et le SDK OpenAI via une surcharge de base_url.
Comparaison
| Throughput | Setup Complexity | Model Size | Best For | |
|---|---|---|---|---|
| vLLMcelui-ci | Highest open-source (GPU) | Medium-high | 7B-671B with multi-GPU | Production multi-user GPU serving |
| llama.cpp server | Good (CPU+GPU) | Medium | Up to host memory | Single-machine, any hardware |
| Ollama | Good (llama.cpp) | Very low | Up to host memory | Small teams, desktop |
| TensorRT-LLM | Highest on NVIDIA | High | 7B-671B | Maximum throughput on NVIDIA |
Cas d'usage
01. Produits SaaS à forte concurrence
Chatbots, copilotes ou APIs d’agents servant des dizaines à des milliers d’utilisateurs simultanés sur GPU. Le batching de vLLM maintient la latence à l’échelle — crucial pour des expériences de qualité produit.
02. Agents à long contexte
Agents envoyant de gros prompts (RAG, longues conversations, contexte de code). PagedAttention et le prefix caching rendent le service en long contexte économiquement viable à l’échelle.
03. Plateforme interne d’infra AI
Les équipes plateforme exposent un endpoint LLM partagé derrière LiteLLM ou Portkey. vLLM est le choix de moteur standard sous le capot — fiable, rapide et largement supporté.
Tarification et licence
vLLM : open source sous licence Apache 2.0. Auto-hébergement gratuit. Soutenu par Neural Magic (Red Hat) ainsi qu’une large communauté de contributeurs.
Coût matériel : un ou plusieurs GPU. 24 Go de VRAM couvrent du 7-14B en fp16 ou du 30-34B en 4-bit. 48-80 Go couvrent du 70B en 4-bit. Configurations multi-nœuds pour les plus gros modèles.
Coût opérationnel : plus élevé qu’Ollama/LM Studio. Environnement Python + CUDA, tuning mémoire minutieux, monitoring des files de requêtes. Prévoyez du vrai temps DevOps pour bien l’exploiter.
Assets associés sur TokRepo
vllm-cli — vLLM Model Serving CLI (Python)
vllm-cli is a CLI for serving models with vLLM; verified 493★ with Python 3.9+ and docs for profiles, shortcuts, and `serve --model` workflows.
vLLM — High-Throughput LLM Serving Engine
vLLM is a high-throughput and memory-efficient LLM inference engine. 74.8K+ GitHub stars. PagedAttention, continuous batching, OpenAI-compatible API, multi-GPU serving. Apache 2.0.
nano-vllm — Lightweight LLM Serving Engine
nano-vllm is a minimal, educational, and performant LLM inference engine that reimplements core vLLM concepts in clean Python for easy understanding and extension.
GPUStack — GPU Cluster Manager for AI Model Deployment
An open-source GPU cluster manager that orchestrates inference engines like vLLM and SGLang for scalable, multi-node AI model serving.
Questions fréquentes
Ai-je besoin de vLLM plutôt que d’Ollama ?+
Uniquement si vous servez plus de ~5-10 utilisateurs simultanés ou si vous avez des SLO de latence sous charge. Pour l’usage desktop, les LLM en petite équipe ou les machines de dev, Ollama est strictement plus simple. vLLM rentabilise à l’échelle.
vLLM peut-il fonctionner sans GPU ?+
Non — vLLM nécessite CUDA (ou ROCm / GPU Intel en support expérimental). Pour de l’inférence CPU uniquement, utilisez llama.cpp server, Ollama ou LocalAI. vLLM est optimisé pour la gestion mémoire GPU ; il n’a pas de sens sur CPU.
Comment vLLM se compare-t-il à TensorRT-LLM ?+
TensorRT-LLM est la stack d’inférence propriétaire de NVIDIA — débit maximal sur matériel NVIDIA, mais plus difficile à opérer, lié à NVIDIA et moins portable entre modèles. vLLM est OSS, multi-architecture et rattrape TensorRT sur le débit pour la plupart des modèles. Choisissez TensorRT quand il vous faut le moindre token/sec en plus sur NVIDIA ; vLLM partout ailleurs.
vLLM supporte-t-il les tool calls ?+
Oui — via les paramètres tool-calling de l’API OpenAI chat completions, sur les modèles dont les poids le permettent (Llama 3.1+, Qwen 2.5, Mistral v0.3+). Support de la grammaire d’outils via --enable-auto-tool-choice.
Déploiement multi-nœuds ?+
Oui. Utilisez --pipeline-parallel-size entre les nœuds et --tensor-parallel-size au sein de chaque nœud. Ray gère l’orchestration. Pas trivial à mettre en place ; prévoyez du temps et attendez-vous à devoir tuner pour votre charge.
Et SGLang / LMDeploy / TGI ?+
Ce sont tous des moteurs d’inférence modernes en concurrence avec vLLM. SGLang ajoute des sorties structurées et du décodage contraint, LMDeploy est fort sur Nvidia et la quantification, HuggingFace TGI est plus simple mais désormais en retard sur les fonctionnalités. vLLM reste le plus généraliste ; n’évaluez les alternatives qu’en cas de besoins spécifiques.