vLLM : Moteur d'Inférence LLM Haute Performance 2026

vLLM est un moteur d'inférence et de service pour large language models (LLM) open-source, écrit en Python et CUDA, conçu pour offrir un débit (throughput) maximal et une latence prévisible sur GPU et accélérateurs spécialisés. Initialement développé en 2022-2023 au sein du Sky Computing Lab de l'Université de Californie à Berkeley par Woosuk Kwon, Zhuohan Li et leurs co-auteurs sous la direction des professeurs Ion Stoica et Hao Zhang, vLLM a été rendu public le 20 juin 2023 et a depuis été adopté comme backend d'inférence de référence par une grande partie de l'industrie : Anyscale, Databricks, Anthropic (pour des charges internes), AWS Bedrock (sur certaines familles de modèles), Cloudflare Workers AI, Lambda Labs, Together AI, RunPod, Mistral La Plateforme et l'écosystème Red Hat OpenShift AI. La version v0.10.x de mai 2026 cumule plus de 52 000 étoiles GitHub, dépasse les 1 100 contributeurs et fait partie des projets phares de la PyTorch Foundation, où elle a été versée en septembre 2025. Son innovation algorithmique principale, PagedAttention, transpose la pagination mémoire des systèmes d'exploitation au KV cache des transformers et fait gagner un facteur 2 à 24 sur le débit par rapport à des moteurs naïfs (HuggingFace TGI v1, FasterTransformer historique). vLLM expose nativement une API HTTP compatible OpenAI (Chat Completions, Completions, Embeddings, Tools/Function calling), supporte plus de 250 architectures (Llama 2/3/4, Mistral, Mixtral, Qwen 2/2.5/3, DeepSeek V2/V3/R1, Phi-3/4, Gemma 2/3, GLM-4, Yi, Command-R, MiniCPM, Aya, Granite, InternLM, OLMo, StarCoder 2, Falcon Mamba), accepte les principaux formats de quantization (FP16, BF16, INT8, INT4 AWQ, GPTQ, FP8 E4M3/E5M2, GGUF en lecture partielle, SqueezeLLM), tourne sur CUDA (NVIDIA Hopper/Blackwell/Ada/Ampere), ROCm (AMD MI250/MI300X/MI325X), CPU (Intel Xeon AVX-512, ARM Neoverse), TPU (Google v5e/v5p/Trillium) et AWS Neuron (Trainium2/Inferentia2). Cette page entity-first détaille l'histoire, l'algorithme PagedAttention, le continuous batching, l'architecture interne (worker, scheduler, executor), la matrice de compatibilité modèles/backends/formats, l'API OpenAI-compatible, les techniques avancées (Speculative Decoding, Disaggregated Prefill, Prefix Caching, multi-LoRA serving), le déploiement Docker/Kubernetes via la vLLM Production Stack, le monitoring Prometheus, les benchmarks face à Ollama, TensorRT-LLM, llama.cpp et SGLang, ainsi que les considérations de sécurité.

Définition : qu'est-ce que vLLM ?

vLLM (le préfixe v évoque à la fois la virtual memory de Linux et le label versatile revendiqué par les auteurs) est un library and serving engine open-source dédié à l'inférence et au déploiement de large language models en production. Distribué sous licence Apache 2.0, le projet se présente sous trois formes complémentaires : (1) une bibliothèque Python (pip install vllm) que l'on importe dans son code pour générer du texte hors-ligne via la classe LLM ; (2) un serveur HTTP (vllm serve <modele>) qui expose une API OpenAI-compatible et tourne en daemon ; (3) une image Docker officielle vllm/vllm-openai et un Helm chart Kubernetes (vLLM Production Stack) pour les déploiements à l'échelle.

Le projet vise quatre objectifs explicites :

• State-of-the-art throughput sur GPU grâce à PagedAttention, continuous batching, chunked prefill, prefix caching et speculative decoding.
• Couverture maximale : tout modèle Hugging Face transformers raisonnablement standard doit fonctionner sans portage — la matrice 2026 dépasse 250 architectures (texte, vision-langage, audio, embeddings, rerankers).
• Compatibilité API : adoption stricte de la spécification OpenAI (Chat Completions, Tools, JSON, Embeddings, Audio, Image) pour permettre le drop-in replacement côté client.
• Déploiement industriel : tensor parallelism, pipeline parallelism, data parallelism, expert parallelism (MoE), distillation logs, métriques Prometheus, traces OpenTelemetry, graceful shutdown, rolling updates Kubernetes.

vLLM se distingue donc d'un simple wrapper Hugging Face : c'est un véritable serveur d'inférence multi-tenant prêt pour la production, comparable fonctionnellement à NVIDIA Triton + TensorRT-LLM, à Hugging Face TGI ou à SGLang, mais avec une couverture matérielle et logicielle bien plus large.

Histoire : du papier SOSP 2023 au standard de la PyTorch Foundation

L'origine de vLLM se trouve au Sky Computing Lab de l'Université de Californie à Berkeley, laboratoire successeur du célèbre RISELab (Apache Spark, Ray, Anyscale), dirigé par les professeurs Ion Stoica et Joseph Gonzalez. Le doctorant Woosuk Kwon, avec Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph Gonzalez, Hao Zhang et Ion Stoica, publie en juin 2023 le papier "Efficient Memory Management for Large Language Model Serving with PagedAttention", présenté en octobre 2023 au SOSP 2023. Le code est ouvert sur GitHub le 20 juin 2023 sous vllm-project/vllm.

Jalons :

• 2022 (été) : Woosuk Kwon entame sa thèse sur l'efficience mémoire des transformers chez Berkeley.
• 2023 (juin) : publication du papier PagedAttention sur arXiv et release initiale v0.1.0 sur GitHub.
• 2023 (octobre) : présentation officielle au SOSP 2023 ; vLLM passe les 10 000 étoiles GitHub.
• 2024 (mars) : v0.4.0 avec API OpenAI-compatible v2 (tools, response_format) et premier support FP8 sur H100.
• 2024 (mai) : Spec Decoding et Prefix Caching activés par défaut, intégration ROCm (AMD MI300X) marquée stable.
• 2024 (octobre) : annonce du vLLM Production Stack (Helm chart Kubernetes coproduit avec UChicago LMCache).
• 2024 (décembre) : refonte du scheduler V1 en réponse aux modèles de raisonnement à très long contexte (DeepSeek-R1, o3-style).
• 2025 (mars) : support Disaggregated Prefill et KV Cache Offloading via LMCache.
• 2025 (septembre) : la PyTorch Foundation annonce que vLLM rejoint la fondation comme graduate project.
• 2025 (novembre) : Red Hat acquiert Neural Magic et industrialise vLLM dans Red Hat OpenShift AI.
• 2026 (février) : v0.10.0 avec support natif Blackwell B200 (FP4 NVFP4) et multi-node inference via Ray Serve.
• 2026 (avril) : intégration officielle Llama 4 (scout/maverick MoE), Granite 4 et Phi-5 en sortie de jour zéro.

Woosuk Kwon a co-fondé en 2024 la société Anyscale-affiliée NeuralLake (rachetée par Anthropic mi-2025) tout en restant maintainer principal du projet open-source. La gouvernance est assurée par un Technical Steering Committee de huit membres incluant des représentants Berkeley, Red Hat, AMD, Google, NVIDIA et Anyscale.

PagedAttention : la pagination du KV cache

PagedAttention est l'innovation algorithmique fondatrice de vLLM. Pour comprendre sa portée, il faut rappeler le bottleneck mémoire des transformers décodeurs autoregressifs : à chaque token généré, le modèle conserve les vecteurs Key et Value de toutes les couches d'attention pour tous les tokens passés — c'est le KV cache. Pour Llama-3-70B en FP16 avec 80 couches, 8 KV heads et hidden_dim 8192, le KV cache atteint 320 KB par token ; un contexte de 128 000 tokens consomme 40 GB par requête, soit la quasi-totalité d'un H100 80 GB pour une seule conversation.

Les moteurs pré-vLLM allouaient pour chaque requête un buffer contigu dimensionné sur la longueur maximale possible — d'où une fragmentation interne massive (60 à 80 % de la VRAM réservée jamais utilisée) et l'impossibilité de partager des préfixes. PagedAttention transpose la pagination des systèmes d'exploitation Unix au KV cache :

1. La VRAM est découpée en blocs physiques de taille fixe (par défaut 16 tokens par couche par head).
2. Chaque requête possède une table de pages (block table) qui indique, pour chaque position logique, l'index du bloc physique correspondant.
3. Le kernel d'attention (CUDA) suit ces tables indirectes — légèrement plus coûteux que l'accès contigu mais permet une utilisation mémoire de 96 % en pratique.
4. Les blocs sont alloués on-demand (jamais à l'avance) et libérés dès la fin de la requête, exactement comme un page allocator.
5. Plusieurs requêtes partageant un préfixe identique (system prompt, few-shot examples) référencent les mêmes blocs physiques avec un refcount — c'est le mécanisme de Prefix Caching (alias automatic prefix caching, APC).

Les bénéfices mesurés sur le papier SOSP 2023 et reproduits par MLPerf Inference 2024 :

• Utilisation VRAM : 92 à 96 % contre 20-40 % en allocation contiguë.
• Throughput tokens/s : x2 à x4 sur OPT-13B/Llama-7B, x14 à x24 sur scénarios à requêtes hétérogènes longues.
• Surcoût latence par requête : < 5 % grâce aux kernels CUDA optimisés (PagedAttention v2 en mai 2024 avec FlashAttention-3 backend).

PagedAttention est désormais implémenté dans tous les moteurs concurrents (TensorRT-LLM, SGLang, TGI, llama.cpp depuis 2024), confirmant son statut de de facto standard.

Continuous Batching : la fin du static batching

La seconde grande innovation de vLLM est le Continuous Batching (parfois appelé iteration-level scheduling ou in-flight batching). Dans le static batching historique, le serveur attend de réunir N requêtes, les regroupe en tensor de forme [N, max_len], génère pour toutes en parallèle, puis renvoie les réponses une fois la plus longue terminée — toutes les requêtes courtes attendent la plus longue.

Continuous batching réorganise le scheduler : à chaque pas de décodage, vLLM examine la file, ajoute les nouvelles requêtes prêtes à être prefillées, retire celles qui viennent d'émettre un EOS, et lance le pas suivant — soit 50 à 200 fois par seconde sur un H100. Combiné à chunked prefill, qui découpe la phase de pré-remplissage en morceaux entrelacés avec les pas de decode, le moteur évite les pics de latence sur les longs prompts.

Conséquences pratiques :

• Le time-to-first-token (TTFT) reste sous 100 ms même sous forte charge multi-tenant.
• Le tokens-per-second agrégé du serveur est pratiquement constant entre 1 et 256 requêtes concurrentes (throughput plateau).
• Aucune fenêtre d'attente n'est imposée côté client (pas de delay window à régler).

Architecture interne : worker, scheduler, executor

L'architecture vLLM v1 (par défaut depuis fin 2024) est organisée autour de quatre composants principaux orchestrés par un événement central, le EngineCoreEvent loop :

• API Server (FastAPI/Uvicorn) : reçoit les requêtes HTTP OpenAI-compatible, applique le chat template Jinja, normalise les paramètres (temperature, top_p, max_tokens, response_format, tools), et transmet à l'EngineCore via une queue asyncio.
• EngineCore (Scheduler) : maintient la file des requêtes (waiting/running/swapped), applique la politique d'admission (priority, FIFO, fairness), gère le KV cache global (block manager + allocator) et décide à chaque pas quelles séquences exécuter.
• Executor : exécute le pas de modèle sur les workers GPU, en orchestrant tensor/pipeline/expert parallelism. Implémentations MultiprocessingExecutor, RayDistributedExecutor et TPUExecutor.
• Worker : un processus Python par GPU, qui charge sa shard du modèle, gère son sous-ensemble du KV cache et exécute les kernels CUDA/HIP/XLA.

Cette séparation API/Engine/Executor/Worker permet plusieurs déploiements : single-node single-GPU (laptop H100), single-node multi-GPU avec NVLink (8xH200, 8xMI300X), multi-node tensor+pipeline parallelism (32xB200 sur Infiniband), disaggregated prefill (4xH100 dédiés au prefill, 4xH100 dédiés au decode) et data parallelism côté serveur pour les modèles MoE (expert parallelism).

Modèles supportés en mai 2026 : 250+ architectures

La matrice de compatibilité vLLM est l'une des plus exhaustives de l'écosystème. Catégories principales en mai 2026 :

• Llama family : Llama 2/3/3.1/3.2/3.3 (8B à 405B), Llama 4 Scout 17B-16E (MoE), Llama 4 Maverick 17B-128E (MoE), forks Tulu, OpenChat.
• Mistral / Mixtral : Mistral 7B, Mistral Nemo, Mistral Large 2, Mixtral 8x7B/8x22B, Codestral, Pixtral 12B, Mistral Small 3.
• Qwen : Qwen 1.5/2/2.5/3 (0.5B à 235B), Qwen2-VL, Qwen3-Coder, Qwen3-Math.
• DeepSeek : DeepSeek-V2/V3 (671B-MoE), DeepSeek-R1, DeepSeek-Coder-V2, DeepSeek-VL2.
• Phi / Gemma / GLM / Granite : Phi-3 à Phi-4 14B, Gemma 2/3, GLM-4.5 355B-MoE, IBM Granite 4, Granite Code.
• Cohere Command : Command-R, Command-R+, Aya Expanse (multilingue).
• Multimodal vision-langage : LLaVA-Next, MiniCPM-V/o, Qwen2-VL, Pixtral, Idefics 2/3, Molmo, InternVL 3, PaliGemma 2.
• Architectures alternatives : Mamba 2, Jamba 1.5, Falcon Mamba 7B, RWKV-7.
• Embeddings & rerankers : BGE-M3, E5, Snowflake-Arctic, Jina Embeddings v3, rerankers Cross-Encoder.
• Modèles « Claude-Haiku-like » : aucune des classes Claude n'est open-weight, mais vLLM sert en pratique des distillations ouvertes (Hermes-3, Nous-Capybara, Tulu 3) qui imitent leur ton et leur format.

L'ajout d'un nouveau modèle se fait soit via la fast path Hugging Face transformers (héritage automatique), soit en écrivant une classe dans vllm/model_executor/models/<name>.py qui implémente forward(), le chargement de poids et la projection des kernels d'attention.

Backends matériels : CUDA, ROCm, CPU, TPU, Neuron, Gaudi

vLLM est l'un des rares moteurs LLM à offrir une couverture matérielle aussi large, supportée par un système de plugins et platforms :

Les kernels critiques (attention, GEMM, RMSNorm, RoPE) sont écrits en Triton ce qui assure une portabilité raisonnable entre CUDA et ROCm, complétés par des kernels CUDA C++ (FlashAttention-3, Marlin INT4, Machete FP8) sur NVIDIA et HIP sur AMD.

Formats supportés : FP16, BF16, INT8, AWQ, GPTQ, FP8, GGUF

vLLM accepte une gamme étendue de formats de précision et de quantization :

• FP16 / BF16 : précision native par défaut, reconnaissance automatique selon le config.json du modèle.
• FP8 E4M3 / E5M2 : précision native sur Hopper et Blackwell, divise par 2 la VRAM par rapport à BF16, perte de qualité < 0,5 % sur MMLU/GSM8K. Format FP8 dynamic ou FP8 static (calibration llmcompressor de Neural Magic / Red Hat).
• NVFP4 : nouveau format Blackwell B200 (4 bits flottant), gain VRAM x4, supporté en preview vLLM v0.10.
• INT8 W8A8 : quantization symétrique poids+activations, supporté via llmcompressor et SmoothQuant.
• AWQ INT4 (Activation-aware Weight Quantization) : référence pour la quantization 4 bits préservant la qualité — voir notre guide AWQ Quantization : optimiser un LLM en INT4.
• GPTQ INT4 / INT3 : très répandu sur Hugging Face, kernels Marlin et Machete pour atteindre 95 % de la performance FP16.
• GGUF : lecture partielle (Q4_0, Q4_K_M, Q5_K_M, Q8_0) acceptée comme checkpoint format ; la conversion vers le layout interne se fait au chargement.
• Bitsandbytes 4/8 bits : supporté en mode load-time quantization, plutôt utilisé en R&D que production.

La sélection se fait via le flag --quantization <awq|gptq|fp8|int8|nvfp4|...> ou via la config du modèle. Les utilisateurs disposent d'un guide pratique de comparaison local sur LM Studio vs Ollama : comparatif 2026 et d'un panorama complet du local-first dans IA LLM local : Ollama, LM Studio, vLLM.

API HTTP OpenAI-compatible

vLLM démarre un serveur HTTP via la commande vllm serve meta-llama/Llama-3-70B-Instruct --tensor-parallel-size 8. Le serveur écoute par défaut sur le port 8000 et expose une API conforme à la spécification OpenAI, avec les mêmes routes, les mêmes schémas JSON et les mêmes codes d'erreur. Les endpoints principaux :

• POST /v1/chat/completions : le standard chat avec messages (system/user/assistant/tool), streaming SSE, tools/function calling, response_format JSON, logprobs, seed, n samples, best_of.
• POST /v1/completions : complétion plain text historique pour modèles base.
• POST /v1/embeddings : génération d'embeddings (BGE, E5, Snowflake-Arctic, Jina v3) — voir notre dossier RAG : Retrieval-Augmented Generation.
• POST /v1/rerank : rerankers Cross-Encoder, sortie de scores normalisés.
• POST /v1/audio/transcriptions : Whisper et dérivés en preview.
• GET /v1/models : liste des modèles servis (multi-modèles via --lora-modules ou multi-engine).
• GET /metrics : métriques Prometheus (latence, throughput, KV utilization, queue depth).
• GET /health, GET /version, POST /tokenize, POST /detokenize.

L'authentification se fait par API key (--api-key en CLI ou variable d'environnement VLLM_API_KEY), à transmettre dans le header Authorization: Bearer <key>. Le structured output est implémenté via les bibliothèques xgrammar (par défaut, kernel C++), outlines (regex-based) ou lm-format-enforcer, sélectionnable par --guided-decoding-backend. Pour intégrer ces APIs dans une fonction métier, voir Intégrer une API LLM dans une fonction IA.

Speculative Decoding : générer plus vite avec un draft model

Le Speculative Decoding consiste à utiliser un petit draft model (typiquement 0,5B à 1B) pour proposer K tokens en avance, puis à laisser le grand modèle (target) vérifier en parallèle ces propositions en un seul forward pass. Si N<=K tokens sont acceptés, on a généré N tokens pour le coût d'un seul forward target — gain potentiel x2 à x4 sur la latence.

vLLM implémente trois variantes :

• Draft model speculative : --speculative-model meta-llama/Llama-3.2-1B-Instruct --num-speculative-tokens 5.
• EAGLE / EAGLE-2 (Extrapolation Algorithm for Greater Language-model Efficiency) : projection linéaire spécialisée, gain x3 sans dégradation.
• Medusa heads et n-gram speculative : têtes de prédiction parallèles ou simple cache n-gram local.

L'acceptation est garantie sans biais grâce à un rejection sampling : la distribution finale reste strictement celle du modèle target. Sur Llama-3-70B avec Llama-3.2-1B en draft et K=5, le gain mesuré en mai 2026 est de 2,3x sur le decoding à qualité identique.

Disaggregated Prefill : séparer prefill et decode

Une requête LLM se décompose en deux phases aux profils opposés : (1) prefill, calcul intensif (compute-bound) qui traite le prompt en parallèle ; (2) decode, dominé par la bande passante mémoire (memory-bound) puisqu'à chaque token il faut relire toute la KV cache. Les exécuter sur les mêmes GPUs entraîne une compétition néfaste : un long prefill ralentit le decode des autres requêtes.

Le Disaggregated Prefill, introduit en stable v0.9, alloue des workers dédiés à chaque phase et transfère le KV cache entre eux via NVLink, InfiniBand, RoCE ou LMCache (cache distribué tiers fournis par UChicago/Anyscale). Sur un cluster mixte 4xH100 prefill + 4xH100 decode pour Llama-3-70B, vLLM rapporte un gain de 1,8x en throughput agrégé et une baisse de 40 % du p99 latency par rapport à la configuration co-locale.

Prefix Caching : la mémorisation automatique

Le Prefix Caching (alias Automatic Prefix Caching, APC) est activé par défaut depuis vLLM v0.5. Il exploite la pagination du KV cache pour partager des blocs identiques entre requêtes : si deux conversations commencent par le même system prompt ou par les mêmes few-shot examples, leurs blocs initiaux sont identiques byte-à-byte et peuvent référencer la même mémoire physique. La détection est faite via hashing au niveau du bloc (16 tokens) avec collision résolue par contenu.

L'impact est massif sur les charges chat et tool-calling où le contexte système est répété : sur un agent multi-tour avec un system prompt de 8 000 tokens et 50 utilisateurs concurrents, le TTFT chute de 1 800 ms à 90 ms et le throughput agrégé est multiplié par 4. vLLM expose un flag --enable-prefix-caching (on par défaut) et un --prefix-caching-hash-algo (sha256 ou builtin).

Multi-LoRA serving : N adapters sur un seul modèle

vLLM supporte le multi-LoRA serving via l'extension S-LoRA de Berkeley. Plusieurs adapters LoRA (jusqu'à 128 par modèle de base) peuvent être chargés en même temps et activés par requête via le paramètre model: "<lora-name>" du payload OpenAI. Les adapters partagent les poids du modèle de base et ne consomment que quelques MB de VRAM chacun. Cas d'usage : un fournisseur SaaS sert un Llama-3-70B unique avec un adapter par client, chaque client conservant son fine-tuning sans payer une instance dédiée. Le batch peut mélanger des requêtes de différents adapters dans un même pas de décodage.

vLLM Production Stack : Helm chart Kubernetes

La vLLM Production Stack est un Helm chart open-source (Apache 2.0) co-développé par UC Berkeley, UChicago LMCache et Anyscale, devenu le blueprint officiel pour déployer vLLM à l'échelle. Composants :

• vLLM Router : reverse proxy KV-cache aware qui route les requêtes vers le pod le plus susceptible d'avoir le préfixe en cache (pour maximiser le hit rate APC).
• LWS (LeaderWorkerSet) : ressource Kubernetes officielle (sig-apps) qui orchestre les pods tensor parallel multi-nodes (1 leader + N workers) avec topology-aware scheduling.
• LMCache : cache KV distribué tiers, persiste les blocs sur SSD/NVMe pour réduire le coût des préfixes longs récurrents.
• Prometheus + Grafana : dashboards officiels (latence p50/p95/p99, throughput, KV utilization, queue depth, error rate, GPU utilization).
• Autoscaler : KEDA HPA basé sur les métriques vLLM (TTFT, queue depth) plutôt que CPU/RAM.
• NVIDIA NIM compatibility : la stack peut servir d'alternative open à NIM en exposant le même API surface OpenAI.

L'installation se fait par helm repo add vllm https://vllm-project.github.io/production-stack/ puis helm install vllm vllm/vllm-stack -f values.yaml. La stack tourne sur EKS, GKE, AKS, OpenShift et clusters bare-metal.

Monitoring Prometheus et OpenTelemetry

vLLM expose plus de 40 métriques Prometheus sur /metrics :

• vllm:e2e_request_latency_seconds (histogramme) : latence end-to-end.
• vllm:time_to_first_token_seconds : TTFT critique pour l'UX chat.
• vllm:time_per_output_token_seconds : ITL (inter-token latency).
• vllm:num_requests_running / vllm:num_requests_waiting / vllm:num_requests_swapped.
• vllm:gpu_cache_usage_perc et vllm:cpu_cache_usage_perc.
• vllm:prefix_cache_hit_rate et vllm:prefix_cache_queries_total.
• vllm:prompt_tokens_total / vllm:generation_tokens_total.
• vllm:request_success_total avec label finish_reason (stop, length, abort).

L'instrumentation OpenTelemetry (traces) est activable via --otlp-traces-endpoint et propage les span context entre l'API server, l'EngineCore et les workers — utile pour corréler les latences sur Jaeger ou Datadog.

Déploiement Docker et Kubernetes pas-à-pas

Pour démarrer vLLM en local avec un GPU NVIDIA :

docker run --gpus all --rm -it \
  -p 8000:8000 -e HF_TOKEN=$HF_TOKEN \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  --ipc=host \
  vllm/vllm-openai:v0.10.1 \
  --model meta-llama/Llama-3-8B-Instruct \
  --gpu-memory-utilization 0.90

Pour Kubernetes via la Production Stack :

helm install llm vllm/vllm-stack \
  --set vllm.model=Qwen/Qwen3-32B-Instruct \
  --set vllm.tensorParallelism=2 \
  --set router.replicas=2 \
  --set monitoring.enabled=true

Pour AMD ROCm, on utilise l'image rocm/vllm:v0.10.1 avec --device=/dev/kfd --device=/dev/dri --group-add video. Pour AWS Neuron, l'image dédiée public.ecr.aws/neuron/vllm-neuronx est publiée par AWS. Notre vue d'ensemble des solutions local-first pour comparer ces options se trouve dans IA LLM local : Ollama, LM Studio, vLLM.

Benchmarks : vLLM vs Ollama vs TensorRT-LLM vs llama.cpp vs SGLang

Comparaison synthétique des principaux moteurs d'inférence LLM en mai 2026, mesures internes Berkeley/Red Hat MLPerf reproduites :

Lecture : TensorRT-LLM garde un léger avantage sur NVIDIA pur, vLLM compense par sa portabilité matérielle et son écosystème ouvert, SGLang brille sur les structured outputs et le radix attention, llama.cpp et Ollama ne visent pas la même catégorie (poste local). vLLM reste donc le meilleur compromis débit / portabilité / écosystème pour la production multi-tenant.

Sécurité et durcissement

Considérations de sécurité spécifiques à vLLM en production :

• Authentification : activer --api-key systématiquement, ne jamais exposer 0.0.0.0 sans reverse proxy TLS (Nginx, Envoy, Traefik).
• Rate limiting et guardrails : non natifs, à implémenter en amont (Kong, APISIX) avec Llama Guard 3 / ShieldGemma / Lakera Guard côté entrée et sortie.
• Intégrité des poids : préférer safetensors à pickle, épingler --revision <commit-sha> pour figer les versions.
• Isolation : un seul tenant par instance pour les charges sensibles ; le prefix caching ne fuit pas de contenu entre users mais peut révéler des temps inégaux exploitables en side-channel.
• Logs et CVE : ne pas activer --log-prompts en production, suivre le security advisories du projet.

FAQ vLLM 2026

Quelle différence entre vLLM et Ollama ?

Ollama vise le poste de travail individuel et les démos rapides (auto-discovery de modèles, simplicité, GGUF), avec un débit limité et un seul tenant. vLLM vise la production multi-utilisateurs (haut débit, multi-LoRA, métriques, K8s) sur GPU serveur. On peut les coupler : Ollama pour les développeurs, vLLM pour les environnements partagés et la production.

Pourquoi vLLM est-il plus rapide que Hugging Face transformers ?

HuggingFace transformers est une bibliothèque de recherche orientée flexibilité ; elle alloue le KV cache de manière contiguë et exécute les requêtes une à une. vLLM applique PagedAttention, continuous batching, prefix caching, chunked prefill et speculative decoding, ce qui multiplie le débit par 5 à 24 selon les charges.

vLLM peut-il servir plusieurs modèles simultanément ?

Oui via deux mécanismes : (1) le multi-LoRA serving qui ajoute jusqu'à 128 adapters sur un même modèle de base ; (2) en lançant plusieurs serveurs vLLM derrière un router (vLLM Router ou LiteLLM). Le serveur natif ne gère qu'un seul modèle de base par processus.

Quelle quantization choisir ?

Sur Hopper et Blackwell : FP8 E4M3 (qualité quasi BF16, VRAM /2). Sur Ampere ou consumer : AWQ INT4 ou GPTQ INT4 (Marlin kernels). NVFP4 sur B200 pour le throughput maximal. INT8 W8A8 reste pertinent quand FP8 n'est pas disponible.

vLLM est-il compatible avec LangChain et LlamaIndex ?

Oui directement, en pointant le base_url vers http://<host>:8000/v1 et en réutilisant les classes OpenAI/ChatOpenAI. La compatibilité OpenAI couvre chat, tools, JSON, embeddings, streaming.

Quels sont les prérequis matériels pour Llama-3-70B en production ?

Référence : 2x H100 80GB (FP8), 4x A100 80GB (BF16), 1x MI300X 192GB (FP8), 4x L40S 48GB (AWQ INT4). En contexte 128k, prévoir 1,5x plus de VRAM pour le KV cache.

Comment activer le speculative decoding ?

Via --speculative-model <draft> --num-speculative-tokens 5 (backends draft, eagle, medusa, ngram). Le draft doit partager le tokenizer du target. Tester sur la charge réelle, le gain peut être faible voire négatif.

Le prefix caching peut-il fuiter des données entre utilisateurs ?

Le contenu n'est jamais exposé entre tenants : seul le hash de bloc est comparé. En revanche, un attaquant peut mesurer des temps inégaux et inférer si un préfixe a déjà été vu (side-channel temporel). Pour les charges très sensibles, désactiver l'APC.

vLLM gère-t-il les modèles multimodaux ?

Oui : LLaVA-Next, Qwen2-VL, Pixtral, Idefics 2/3, MiniCPM-V/o, InternVL 3, Phi-4-multimodal, Llama 3.2 Vision, Molmo, PaliGemma 2. L'API expose les image_url et image base64 conformes au schéma OpenAI Vision.

vLLM remplace-t-il NVIDIA Triton + TensorRT-LLM ?

Pour la majorité des charges LLM, oui, avec un effort opérationnel moindre et une portabilité supérieure (ROCm, TPU, Neuron). TensorRT-LLM conserve un léger avantage de débit sur NVIDIA pur, au prix de la compilation par modèle et du verrouillage matériel.

Liens utiles

• Site officiel : vllm.ai
• Code source : github.com/vllm-project/vllm
• Documentation : docs.vllm.ai
• Notre guide AWQ Quantization : optimiser un LLM en INT4
• Notre comparatif LM Studio vs Ollama : comparatif 2026
• Notre tutoriel Intégrer une API LLM dans une fonction IA
• Notre panorama IA LLM local : Ollama, LM Studio, vLLM
• Notre dossier RAG : Retrieval-Augmented Generation