Installer vLLM sur votre propre machine, et voir ce qu’il envoie

vLLM demande Linux (ou WSL sous Windows), une carte NVIDIA de compute capability 7.5 ou plus récente et Python 3.10 à 3.13. Ensuite, 2 commandes : uv pip install vllm --torch-backend=auto et vllm serve. Le serveur répond sur le port 8000 sur toutes les interfaces réseau, pas seulement sur votre machine : ajoutez --host 127.0.0.1.

C’est ce dernier point qui distingue vLLM. Des 5 logiciels que nous comparons, c’est le seul qui écoute d’origine sur toutes les interfaces ; Ollama, LM Studio, llama.cpp et MLX démarrent sur 127.0.0.1. Il démarre aussi sans clé, avec un CORS ouvert à n’importe quel site et des statistiques d’usage activées. Rien de tout cela n’est difficile à changer, et cette page le reprend dans l’ordre, avec la version stable actuelle, la 0.30.0, publiée le 22 septembre 2026. Chaque commande et chaque valeur par défaut de cette page a été vérifiée dans le code de la 0.30.0, tel qu’il est étiqueté dans son dépôt public, le 28 septembre 2026.

Ce qu’est vLLM, et à qui il s’adresse

vLLM est un moteur d’inférence conçu pour servir des modèles de langage à beaucoup de monde à la fois. Sa place est un serveur Linux équipé de cartes graphiques NVIDIA, et c’est là que ses réglages d’origine ont un sens : un service que d’autres machines joignent par le réseau, qui se réserve l’essentiel de la carte et qui informe ses développeurs de la façon dont il est utilisé. Il est open source, sous licence Apache 2.0. La fiche vLLM : ce qu’il envoie et si vous pouvez l’auditer le place à l’extrémité professionnelle des 5 logiciels, et ce guide en est le versant pratique.

Tout tient dans 1 exécutable, vllm. Les sous-commandes dont vous vous servirez sont vllm serve, qui démarre le serveur compatible OpenAI, et vllm chat et vllm complete, des clients en console qui parlent à ce serveur. Il existe aussi vllm bench, vllm collect-env, vllm run-batch et vllm launch, dont cette page n’a pas besoin.

Ce qu’il n’est pas, car on le lui prête à chaque fois :

• Pas une application de bureau. Il n’y a aucune fenêtre. vllm chat est un client texte qui a besoin que le serveur tourne déjà.
• Pas un lecteur de GGUF d’origine. La prise en charge du GGUF est passée dans un plugin séparé, et la partie sur les modèles explique ce que cela change pour les tailles.
• Pas un programme pour le GPU du Mac. Sur Apple Silicon, vLLM lui-même tourne sur le processeur. Si vous avez un Mac, Installer MLX sur Mac avec mlx-lm, et voir ce qu’il envoie utilise directement le GPU.
• Pas un sélecteur de modèles. Le serveur héberge 1 modèle à la fois. Pour en changer, vous redémarrez le serveur avec un autre nom.

Si vous cherchez un modèle avec qui converser sur votre propre ordinateur, Installer Ollama en local, vérifier qu’il tourne et voir ce qu’il envoie et Installer LM Studio et son serveur local, et voir ce qu’il envoie vous y mènent avec moins de décisions à prendre. vLLM, c’est pour servir.

Ce qu’il faut : Linux, une carte NVIDIA de compute capability 7.5 et Python 3.10 à 3.13

Prérequis	Ce que ça veut dire en pratique
Linux	Les paquets précompilés de PyPI sont uniquement des wheels Linux, pour x86_64 (314,9 Mo) et aarch64 (310,0 Mo). Windows passe par WSL
Carte graphique NVIDIA, compute capability 7.5 ou plus récente	La T4 et la série RTX 20 et au-delà. La série RTX 30 est en 8.6 et la série RTX 40 en 8.9. La série GTX 10 est sous la barre. Le paquet de PyPI est compilé pour CUDA 13.0 ; une version compilée pour CUDA 12.9 est jointe à la publication sur GitHub
Python 3.10 à 3.13	La documentation demande 3.10 à 3.13 ; les métadonnées du paquet acceptent de 3.10 jusqu’à 3.15 exclu. Prenez 3.12 : il se trouve dans les deux plages, et les wheels AMD comme le wheel Mac sont compilés pour lui
Un environnement neuf	vLLM 0.30.0 fixe sa propre version de PyTorch, torch==2.13.0, avec torchaudio et torchvision assortis, et c’est pourquoi sa documentation recommande un nouvel environnement

Prérequis tirés du guide d’installation de vLLM à l’étiquette v0.30.0, des métadonnées PyPI de vllm 0.30.0 et du tableau des compute capabilities de NVIDIA, lus le 28 septembre 2026.

Windows. vLLM ne tourne pas nativement sous Windows. Sa documentation renvoie au sous-système Windows pour Linux (WSL), et dans WSL vous suivez les étapes Linux de cette page.

Mac. vLLM prend en charge Apple Silicon sur le processeur, à titre expérimental : FP32 et FP16, macOS Sonoma ou plus récent, Xcode 15.4 et ses Command Line Tools. PyPI ne propose aucun wheel macOS, et la documentation décrit une compilation depuis les sources. La version 0.30.0 sur GitHub joint pourtant un wheel prêt à l’emploi pour processeur macOS arm64 et Python 3.12, de 29,0 Mo ; nous ne l’avons pas testé. Le GPU du Mac relève d’un autre projet : vLLM renvoie à vLLM-Metal, un plugin maintenu par la communauté qui s’appuie sur MLX et charge ses modèles depuis mlx-community. Cette page ne le couvre pas.

AMD. vLLM prend en charge les cartes AMD avec ROCm 6.3 ou plus récent, et pour la 0.30.0, le wheel précompilé de https://wheels.vllm.ai/rocm/ est compilé pour ROCm 7.2.3 et demande glibc 2.39 ou plus récent. Ce wheel n’existe que pour Python 3.12, et c’est l’étape à ne pas manquer : avec tout autre Python, l’installateur se rabat sans rien dire sur le wheel CUDA de PyPI, qui échoue ensuite sur la carte AMD avec libcudart.so: cannot open shared object file. La liste prise en charge couvre les MI200, MI300 et MI350, les Radeon RX 7900 (gfx1100/1101) et RX 9000 (gfx1200/1201), ainsi que les Ryzen AI MAX et AI 300 (gfx1151/1150, ROCm 7.0.2 ou plus récent).

Processeur seul. Sur une machine Linux x86 sans carte adaptée, vLLM tourne sur le processeur. AVX512 est recommandé ; avec AVX2, les fonctions sont limitées. La version 0.30.0 joint un wheel pour processeur x86_64 (147,4 Mo) et un pour aarch64 (68,3 Mo) ; les deux demandent glibc 2.39 ou plus récent.

Quelles machines de notre catalogue peuvent le faire tourner

Notre catalogue compte 16 machines. Lues à la lumière des prérequis de vLLM, elles se rangent en 4 groupes :

Machine	Compute capability	Comment vLLM y tourne
PC avec RTX 4060 8 Go	8.9	CUDA, sous Linux ou WSL
PC avec RTX 3060 12 Go	8.6	CUDA, sous Linux ou WSL
PC avec RTX 4070 12 Go	8.9	CUDA, sous Linux ou WSL
Station de travail avec RTX 4090 24 Go	8.9	CUDA, sous Linux ou WSL
Serveur avec 2× RTX 3090 (48 Go)	8.6	CUDA sur les deux cartes avec --tensor-parallel-size 2
Les 8 Mac, du Mac avec M4 et 16 Go au Mac Studio avec M5 Ultra et 512 Go	—	Processeur seul, à titre expérimental. Le GPU uniquement par le plugin vLLM-Metal
Le portable de bureau avec 16 Go, et la partie processeur du mini-PC avec NPU et 32 Go	—	Processeur, sous Linux. Si le processeur du mini-PC est un Ryzen AI 300 ou un Ryzen AI MAX, son GPU intégré figure dans la liste ROCm de vLLM plus haut. Le dépôt principal de vLLM n’a aucun backend pour le NPU
Xiaomi AI Cube, 80 Go	—	Invérifiable : un prototype d’ingénierie dont le processeur n’est pas documenté face aux prérequis de vLLM

Compute capability tirée du tableau de NVIDIA, lu le 28 septembre 2026. Voies d’installation tirées du guide d’installation de vLLM à l’étiquette v0.30.0.

Les 5 machines NVIDIA sont le cas pour lequel vLLM est conçu. Sur les autres, quand il y tourne, c’est sur le processeur.

Installer vLLM et vérifier quelle version vous avez

La documentation de vLLM recommande uv et un nouvel environnement. Avec Python 3.12 :

uv venv --python 3.12
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm --version

--torch-backend=auto regarde le pilote NVIDIA que vous avez installé et choisit l’index PyTorch qui lui correspond. --torch-backend=cu129 ou cu130 demande explicitement une variante. Avec pip tout court, la ligne est simplement :

pip install vllm

Le wheel vllm pèse à lui seul 314,9 Mo, et il entraîne avec lui PyTorch 2.13.0, torchaudio 2.11.0, torchvision 0.28.0 et FlashInfer : le téléchargement complet est plus gros que le wheel, et nous ne l’avons pas mesuré. vllm --version doit afficher 0.30.0.

Fixez la version. vLLM avance vite : 32 versions stables sur les 12 mois qui précèdent le 28 septembre 2026, et les 3 dernières sont arrivées 15, 14 et 13 jours après la précédente (0.28.0 le 26 août, 0.29.0 le 9 septembre, 0.30.0 le 22 septembre). Pour installer exactement la version que décrit cette page :

uv pip install vllm==0.30.0 --torch-backend=auto

La voie Docker. L’image officielle est vllm/vllm-openai. L’étiquette v0.30.0 a été publiée le 22 septembre 2026 et pèse 8,1 Gio compressée pour amd64 et 9,0 Gio pour arm64 :

docker run --rm \
  --runtime nvidia \
  --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 127.0.0.1:8000:8000 \
  --ipc=host \
  vllm/vllm-openai:v0.30.0 \
  --model Qwen/Qwen3-0.6B

C’est la commande de vLLM lui-même, avec une étiquette fixe au lieu de latest, 127.0.0.1 devant le port, pour que Docker ne le publie que sur votre machine, et --rm ; la ligne HF_TOKEN est omise parce que Qwen/Qwen3-0.6B est public. Le volume partage votre cache Hugging Face avec le conteneur, si bien que les modèles ne sont pas téléchargés deux fois. L’image tourne en root par défaut ; elle contient aussi un utilisateur vllm intégré, d’UID 2000, et la page Docker de la documentation de vLLM montre comment passer sur lui.

Votre premier modèle : vllm serve sur le port 8000

vllm serve

Sans nom de modèle, vLLM charge Qwen/Qwen3-0.6B : 751 632 384 paramètres en BF16, 1,41 Gio à télécharger depuis Hugging Face, un contexte qui va jusqu’à 40 960 tokens et la licence Apache 2.0. Pour choisir le modèle, donnez son nom Hugging Face :

vllm serve Qwen/Qwen3-0.6B --max-model-len 8192

La partie sur la mémoire explique pourquoi cette deuxième option est là. Une fois que le journal montre que le serveur est prêt, 2 vérifications depuis un autre terminal :

curl http://127.0.0.1:8000/v1/models
curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "Qwen/Qwen3-0.6B", "messages": [{"role": "user", "content": "How tall is Mt Everest?"}]}'

La première liste le modèle chargé ; la seconde renvoie une réponse au format d’OpenAI. Les routes principales sont POST /v1/chat/completions, POST /v1/completions et GET /v1/models, plus GET /health et GET /version. Pour un client OpenAI, l’URL de base est http://127.0.0.1:8000/v1. Pour une conversation rapide dans le terminal :

vllm chat

Il se connecte à http://localhost:8000/v1, sauf si vous lui donnez une autre --url. Le serveur ne garde aucune trace de vos requêtes.

La mémoire : pourquoi vLLM prend 92 % de la carte, et –max-model-len

vLLM ne se contente pas de charger un modèle. Au démarrage, il réserve une part fixe de la carte, 0,92 de sa mémoire totale par défaut, pour le modèle, sa mémoire de travail et le cache qui contient vos conversations (le cache KV). 2 conséquences découlent de la façon dont le code de la 0.30.0 s’y prend.

Il compte la mémoire libre, pas la mémoire totale. Si la mémoire libre au démarrage est inférieure à 92 % de la carte, vLLM refuse de démarrer avec Free memory on device … on startup is less than desired GPU memory utilization (0.92, X GiB). Decrease GPU memory utilization or reduce GPU memory used by other processes. Sur une carte de 8 Go, cela fait 7,36 Gio libres. Si cette même carte gère aussi votre bureau, le bureau et le contexte CUDA que vLLM ouvre pour lui-même doivent tenir ensemble dans 0,64 Gio environ, sinon la vérification échoue avant qu’aucun modèle ne se charge. Le remède est celui que donne le message :

vllm serve --gpu-memory-utilization 0.85

La valeur est une limite par processus : 2 serveurs vLLM sur 1 carte demandent quelque chose comme 0,5 chacun. Sur le backend processeur, la même option réserve de la mémoire vive du système, malgré son nom.

Le contexte prend par défaut le maximum du modèle. --max-model-len est tiré de la configuration du modèle lui-même si vous ne le fixez pas, et vLLM refuse de démarrer si le cache KV de cette longueur complète ne tient pas. L’erreur donne les chiffres : To serve at least one request with the model’s max seq len (N), (X GiB KV cache is needed, which is larger than the available KV cache memory (Y GiB), suivie de la longueur maximale estimée qui tiendrait et du conseil d’augmenter gpu_memory_utilization ou de baisser max_model_len. S’il ne reste plus rien du tout, le message est No available memory for the cache blocks.

La taille que prend ce cache, calculée à partir de l’architecture de chaque modèle avec un cache KV en 16 bits :

Modèle	Contexte maximal	Cache KV au maximum	Cache KV avec –max-model-len 8192
qwen3-1.7b	40 960	4,38 Gio	0,875 Gio
qwen3-8b	40 960	5,63 Gio	1,125 Gio
qwen3-4b-2507	262 144	36,0 Gio	1,125 Gio

Notre calcul : 2 × couches × têtes KV × taille de tête × 2 octets par token, à partir des données de modèles qui alimentent notre trouveur de modèle. Gemma 4 et gpt-oss utilisent des couches à fenêtre glissante, où cette formule ne s’applique pas : ils sont donc laissés de côté.

C’est le modèle 4B qui vous piège. À 8 192 tokens, qwen3-4b-2507 a besoin de 1,125 Gio de cache ; à son contexte par défaut, il réclame 36,0 Gio pour le cache seul, davantage que toute la mémoire de n’importe quelle carte isolée de notre catalogue. Notre trouveur de modèle et nos fiches de machine calculent tout avec un contexte de 8 192 tokens. --max-model-len 8192 (ou 8K, avec un K majuscule : 8k en minuscule veut dire 8 000) fait se comporter vLLM comme le chiffre de notre site. Avec --max-model-len auto, ou -1, vLLM prend le contexte le plus long qui tient.

Quels modèles tiennent, et pourquoi nos tailles GGUF ne sont qu’un repère

Nos fiches de machine mettent 0,8 Gio de côté pour le système sur les cartes NVIDIA et comparent le reste aux 19 modèles que nous mesurons. vLLM trace sa propre limite à 92 %, si bien que les 2 budgets diffèrent un peu :

Machine	Ce que notre fiche laisse au modèle	Budget de vLLM (0,92 × mémoire), pour le modèle, sa mémoire de travail et le cache KV	Modèles qui tiennent (fiche, 8K)	Le plus grand qui tient (fiche)
RTX 4060 8 Go	7,20 Gio	7,36 Gio	6 sur 19	granite-4.2-8b
RTX 3060 12 Go et RTX 4070 12 Go	11,20 Gio	11,04 Gio	7 sur 19	gemma4-12b
RTX 4090 24 Go	23,20 Gio	22,08 Gio	15 sur 19	qwen3.6-35b-a3b
2× RTX 3090 48 Go	47,20 Gio	2 × 22,08 = 44,16 Gio, avec --tensor-parallel-size 2	15 sur 19	qwen3.6-35b-a3b

Chiffres servis par chaque fiche le 28 septembre 2026, à partir des données machines du 23 septembre. Le budget de vLLM est notre calcul à partir de sa valeur par défaut de 0,92.

Sur la carte de 24 Go, vLLM se laisse 1,12 Gio de moins que ce que compte notre fiche ; sur la carte de 8 Go, 0,16 Gio de plus. Un modèle qui tient tout juste d’après la fiche peut demander de relever --gpu-memory-utilization sur une carte de 24 Go.

L’écart plus important, c’est le fichier. Nos tailles sont celles de fichiers GGUF en Q4_K_M. vLLM ne charge pas le GGUF de lui-même : cette prise en charge vit désormais dans un plugin séparé, vllm-gguf-plugin, que la documentation qualifie de très expérimental et peu optimisé. Si vous voulez l’essayer :

uv pip install vllm-gguf-plugin

Les modèles se nomment alors sous la forme repo_id:quant_type, par exemple avec Q4_K_M. La voie habituelle dans vLLM est une autre compression : des fichiers AWQ, GPTQ ou FP8 de Hugging Face, ou le MXFP4 de gpt-oss. Nous n’avons pas mesuré ces tailles pour nos 19 modèles : prenez donc le verdict du trouveur comme un repère pour vLLM, pas comme le même chiffre.

Le verrouiller : 0.0.0.0, aucune clé et un CORS ouvert

Réglé d’origine, vllm serve écoute sur 0.0.0.0:8000, et son journal de démarrage l’affiche tel quel. Il répond sur localhost et sur toutes les autres interfaces réseau de la machine : n’importe qui sur votre réseau, ou sur Internet si le port est ouvert, peut s’en servir. Il ne vérifie aucune clé. Et le CORS est ouvert à toute origine, toute méthode et tout en-tête, si bien qu’une page web que vous ouvrez dans votre navigateur peut lui envoyer des requêtes et lire les réponses.

Ce qui le ferme :

export VLLM_API_KEY="une-longue-chaine-aleatoire"
vllm serve Qwen/Qwen3-0.6B --host 127.0.0.1 --max-model-len 8192

• --host 127.0.0.1 tient les autres machines à l’écart. Si l’une d’elles a besoin du serveur, passez par un tunnel SSH (ssh -L 8000:127.0.0.1:8000 vous@votre-serveur).
• --api-key, ou la variable VLLM_API_KEY, oblige les clients à envoyer la clé comme jeton Bearer. La variable garde la clé hors de la ligne de commande, où n’importe quel utilisateur de la machine peut la lire dans la liste des processus.
• --allowed-origins '["http://localhost:3000"]', une liste JSON, nomme les pages qui ont le droit de l’appeler, au lieu du * par défaut.

Ce que la clé ne couvre pas. La clé ne protège que les routes sous 4 préfixes : /v1, /v2, /inference et /cohere. Tout le reste, sur le même port, répond sans elle : /health, /version, /tokenize, /metrics (Prometheus, toujours monté) et /invocations, qui atteint les mêmes fonctions d’inférence que /v1. De même pour les pages d’API interactives /docs et /redoc et le schéma sur /openapi.json, sauf si vous démarrez avec --disable-fastapi-docs. La page de sécurité de vLLM cite aussi /pause, qui arrête la génération, et /update_weights ; dans le code de la 0.30.0, elles ne sont montées que si VLLM_SERVER_DEV_MODE=1 est défini, alors ne définissez pas cette variable. La page de sécurité de vLLM le dit sans détour : Do not rely exclusively on --api-key. Autrement dit, ne comptez pas sur la seule clé. Sa recommandation, pour tout ce que d’autres peuvent joindre, est un proxy inverse placé devant vLLM qui ne laisse passer que les routes que vous comptez exposer.

Un second point d’écoute. vLLM utilise torch.distributed de PyTorch, et quand il le met en place par TCP, comme il le fait sur plusieurs machines ou sur les cartes AMD avec l’all-reduce d’AITER, le TCPStore de PyTorch écoute par défaut sur toutes les interfaces réseau. Sur 1 machine avec des cartes NVIDIA, le code de la 0.30.0 utilise un fichier à la place. La consigne de vLLM lui-même est un pare-feu qui bloque toute connexion entrante sauf le port du serveur d’API. --host 127.0.0.1 ferme l’API ; la règle de pare-feu couvre ce que les options de vLLM n’atteignent pas.

Ce que vLLM envoie de lui-même, et comment le couper

Les statistiques d’usage sont activées par défaut et partent vers https://stats.vllm.ai. Dans le code de la 0.30.0, elles sortent sous 2 formes :

• 1 rapport complet au démarrage du moteur, depuis un fil d’exécution séparé : un identifiant de session aléatoire ; le nombre de GPU, leur modèle et leur mémoire ; la version de CUDA ; le fournisseur cloud, s’il en détecte un ; l’architecture du processeur et la chaîne du système d’exploitation ; la mémoire totale ; le nombre de cœurs du processeur, sa marque, sa famille, son modèle et son stepping ; la version de vLLM ; l’architecture du modèle, pas son nom ; la longueur de contexte ; 5 variables d’environnement de vLLM ; et des paramètres de démarrage comme le type de données, gpu_memory_utilization, la quantification, le parallélisme, max_model_len et max_num_seqs.
• Un signal de présence toutes les 10 minutes tant que le serveur tourne, qui ne porte que l’identifiant de session et un horodatage. Cela fait 144 signaux par jour.

Les erreurs réseau sont ignorées sans bruit. Pour comparaison, le guide d’Ollama compte 30 appels par jour, application ouverte.

Vous pouvez lire ce qui a été envoyé. Chaque rapport est aussi ajouté à un fichier sur votre disque :

tail ~/.config/vllm/usage_stats.json

4 moyens les coupent, et un seul suffit :

export VLLM_NO_USAGE_STATS=1
export DO_NOT_TRACK=1
export VLLM_DO_NOT_TRACK=1
mkdir -p ~/.config/vllm && touch ~/.config/vllm/do_not_track

La valeur doit être exactement 1. Le code compare le texte à "1", si bien que DO_NOT_TRACK=true laisse les statistiques activées. Dans Docker, passez-la avec -e VLLM_NO_USAGE_STATS=1.

Hugging Face. L’autre trafic, c’est le téléchargement des modèles. vLLM s’identifie auprès de Hugging Face comme vllm, et récupère tout modèle que vous nommez s’il n’est pas déjà en cache. Une fois vos modèles téléchargés :

export HF_HUB_OFFLINE=1

Avec cette variable, aucun appel ne part vers Hugging Face, et un modèle absent échoue au lieu de se télécharger. vLLM n’a ni recherche de mises à jour ni compte.

Ce qui reste sur le disque. Les modèles vont dans le cache de Hugging Face, ~/.cache/huggingface, que HF_HOME déplace. Les fichiers propres à vLLM vivent dans ~/.config/vllm (le fichier de statistiques et l’interrupteur do_not_track) et dans son dossier de cache, ~/.cache/vllm. Il n’y a aucune conversation : le serveur ne garde aucune copie de vos requêtes.

L’ordre qui vous laisse un vLLM qui marche et qui reste fermé :

1. Vérifiez la carte : NVIDIA de compute capability 7.5 ou plus récente, sous Linux ou WSL.
2. Créez un environnement Python 3.12 avec uv, installez vllm==0.30.0 avec --torch-backend=auto et confirmez avec vllm --version.
3. Définissez VLLM_NO_USAGE_STATS=1 avant le premier vllm serve, pour que même le rapport de démarrage ne parte pas.
4. Démarrez avec --host 127.0.0.1, --max-model-len 8192 et une clé dans VLLM_API_KEY.
5. Si la carte gère aussi votre écran, baissez --gpu-memory-utilization jusqu’à ce qu’il démarre.
6. Une fois le modèle téléchargé, définissez HF_HUB_OFFLINE=1.

Les 5 logiciels sont comparés exactement sur ces points dans 5 logiciels d’IA locale : télémétrie, appels et audit.