> Peut-on exécuter vLLM sous Windows ? Oui — via WSL2▋

93 632 étoiles GitHub depuis février 2023, et les prérequis d'installation s'ouvrent toujours sur une ligne : « OS : Linux. Python 3.10–3.13. » Deux lignes plus bas, la note qui envoie tout le monde chercher : « vLLM ne prend pas en charge Windows nativement. Pour exécuter vLLM sous Windows, utilisez le Sous-système Windows pour Linux (WSL) avec une distribution compatible, ou certains forks maintenus par la communauté. » Cette note est tout le billet. La route officielle, c'est WSL2 ; la route native est un fork avec votre nom sur les rapports de bug. Celui-ci vit dans le cluster run-LLMs-locally, à côté de la moitié matérielle du même verrou — vLLM peut-il lire du GGUF.

Comment exécuter vLLM sous Windows ?

Par WSL2, et très vite ça ne ressemble plus à Windows.

• Windows 10/11 avec un GPU NVIDIA ? L'AMD passe par ROCm-on-WSL et la route est plus étroite — prévoyez-le
• wsl --install -d Ubuntu depuis un PowerShell admin, puis redémarrez
• Pilote NVIDIA installé côté Windows — aucun dans WSL, le GPU passe à travers
• Dans Ubuntu : uv pip install vllm — le flux Linux exact de la documentation
• Servez un petit modèle et appelez l'endpoint models pour confirmer — commande ci-dessous

WSL2, c'est Microsoft qui admet officiellement que la meilleure fonctionnalité de Windows, c'est Linux. Il est livré avec l'OS, s'installe en une ligne, et une fois dans Ubuntu, chaque instruction vLLM d'Internet s'applique à vous telle quelle :

# PowerShell (admin) — puis redémarrez quand il le demande :
wsl --install -d Ubuntu

# dans Ubuntu — l'installation Linux normale, rien de spécifique à Windows :
uv venv --python 3.12 && source .venv/bin/activate
uv pip install vllm --torch-backend=auto

# servez un petit modèle et prouvez que le GPU passe :
vllm serve Qwen/Qwen3-0.6B --port 8000

vérification : curl http://localhost:8000/v1/models depuis Windows — WSL2 transfère localhost, votre modèle revient en JSON

Le détail que tout le monde rate : le pilote GPU vit côté Windows. Le design CUDA-on-WSL de NVIDIA fait passer le GPU à travers le pilote Windows vers n'importe quelle distribution, donc vous installez le pilote une fois, dans Windows, jamais dans Ubuntu. Installez un pilote dans WSL quand même et vous pouvez passer une soirée à décoincer une pile qui n'a jamais été cassée.

Peut-on exécuter vLLM sous Windows sans WSL ?

Uniquement via un fork communautaire — et la taxe du fork est réelle : vous échangez l'installateur contre un compilateur.

La doc nomme elle-même la scène : « certains forks maintenus par la communauté ». J'ai lu le registre de tous, cette semaine :

• SystemPanic/vllm-windows — le vivant. 663 étoiles, poussé la veille de ce billet. Wheels Windows natives, CUDA 13, support Blackwell, même du multi-GPU via NCCL sous Windows. Un projet sérieux qui fait ce que le cœur refuse de faire.
• devnen/vllm-windows — 28 étoiles, dernière poussée en mai 2026. Cinq mois de silence dans un projet qui va aussi vite, c'est un avis de départ.
• dexteri-ai/vllm-windows — un wrapper GUI, créé en janvier 2026. Regardez derrière l'interface : il pilote vLLM dans WSL2 — la route qu'il prétend éviter.

Même sur le fork en bonne santé, vous compilez des kernels CUDA avec des patchs MSVC, vous perdez FlashAttention-3, et vous retestez après chaque release amont. Voilà la taxe du fork. Payez-la quand une politique d'entreprise interdit WSL et qu'un serveur est hors de portée — pas parce que l'installation en une ligne semblait trop facile.

Pourquoi aucun build Windows natif du tout ?

vLLM compile des kernels CUDA et s'appuie sur NCCL — une toolchain qui n'existe pleinement que sous Linux. La doc le dit crûment : « vLLM ne peut tourner complètement que sous Linux. » Un port natif signifie reprendre le build des kernels pour MSVC — exactement la maintenance que le projet a choisi de ne pas assumer, et les forks mesurent le travail par le peu de survivants.

vLLM fonctionne-t-il sous Windows pour les modèles GGUF ?

Oui — via WSL2, sur un GPU NVIDIA ou AMD. Le GGUF dans vLLM est GPU uniquement, donc Windows empile l'exigence d'OS sur celle du matériel. Sur une machine Windows avec CPU seul, exécutez plutôt le même fichier dans Ollama ou llama.cpp — tous deux natifs.

Deux verrous, dans l'ordre. Le verrou matériel d'abord : vLLM peut-il lire du GGUF — oui, via le plugin officiel, GPU uniquement, CPU x86 et Arm refusés. Le verrou OS ensuite, ce billet : le chemin GPU-only doit bien tourner quelque part, et sous Windows ce quelque part est WSL2 avec le CUDA qui passe à travers. Les deux verrous s'ouvrent ensemble ou pas du tout. Aucun GPU à l'horizon ? Le fichier tourne quand même — exécuter des modèles GGUF localement couvre les outils natifs, et le quant à choisir est dans notre guide de quantization.

vLLM sous Windows — ou juste Ollama ?

La plupart des questions Windows sur vLLM sont en réalité des questions de concurrence. vLLM existe pour servir beaucoup d'utilisateurs depuis de gros GPU avec du batching continu. Si le nombre d'utilisateurs est « moi, à mon bureau », la réponse honnête est la dernière ligne :

Route	vLLM ?	Installation	Pour
vLLM dans WSL2	moteur complet	une ligne + redémarrage	servir une équipe depuis un GPU
fork natif SystemPanic	quasi complet, vous testez	compiler, courir après CUDA	WSL interdit par politique, GPU attaché
vLLM sur une box Linux, Windows en client	moteur complet, ailleurs	tout client compatible OpenAI	le GPU vit déjà dans une autre pièce
Ollama, natif	non — autre moteur	un installateur	usage solo, GGUF, port 11434
llama.cpp, natif	non — autre moteur	binaires Windows	un utilisateur, la plus large couverture de quant

Le tableau de support de la doc dit Linux. WSL2 dit : très bien. Et si la question derrière n'a jamais porté sur vLLM — juste « lancer un modèle sur ma machine Windows » — alors rien n'a jamais été fermé : Ollama s'installe nativement, sert 127.0.0.1:11434, et quand il refuse de démarrer, nous avons autopsié cet échec aussi.