vLLM vs Ollama : 1 utilisateur ou 256 à la fois, et les portes que chacun ouvre

Prenez Ollama si une seule personne s’en sert, sur un Mac, un PC Windows ou presque n’importe quelle carte graphique, avec des modèles GGUF et une seule commande. Prenez vLLM si plusieurs personnes ou programmes sollicitent le même modèle en même temps depuis un Linux avec carte NVIDIA, en safetensors. À la maison, pour un utilisateur : Ollama.

Plus que des rivaux, ce sont des outils pour des métiers différents. Ollama 0.40.10, la version stable depuis le 23 octobre 2026, est fait pour installer un modèle sur votre propre ordinateur. vLLM 0.32.0, stable depuis le 18 octobre 2026, est fait pour servir un modèle à beaucoup de monde à la fois. Nous ne les avons pas fait courir chronomètre en main : vous ne trouverez donc pas ici de vainqueur en vitesse. Ce que nous avons fait, c’est lire le code des deux versions partout où il touche à la mémoire, au réseau et à votre vie privée, et c’est là qu’ils diffèrent le plus.

vLLMFiche logiciel→ OllamaFiche logiciel→

	vLLM	Ollama
Fait pour	Servir un modèle à beaucoup d’utilisateurs à la fois	Faire tourner des modèles sur votre propre ordinateur
Version au 24 octobre 2026	0.32.0	0.40.10
Code et licence	Ouvert, Apache 2.0	Ouvert, MIT
Fonctionne sur	Linux avec carte NVIDIA (capacité de calcul 7.5 ou plus), AMD avec ROCm sur quelques versions précises ; Windows seulement via WSL ; Mac expérimental, processeur seul	Windows 10 22H2 ou plus récent, macOS 14 ou plus récent, Linux ; NVIDIA, AMD, Apple Silicon et Vulkan
Fichiers de modèle	safetensors, plus AWQ, GPTQ, FP8 et d’autres ; GGUF seulement via un module expérimental	GGUF et safetensors ; sur Apple Silicon, MLX par défaut
Requêtes simultanées, d’origine	Jusqu’à 256 sur une carte grand public, regroupées en lots	1 par modèle ; les autres attendent dans une file de 512 au plus
Mémoire graphique	Réserve 92 % de la carte au démarrage	Prend ce dont le modèle et son contexte ont besoin
Installation et première réponse	Paquet Python, vllm download-kernels, puis vllm serve	Installateur ou script d’une ligne, puis ollama run
Fenêtre	Aucune : c’est un serveur d’API	Application de bureau sur macOS et Windows
Écoute sur	0.0.0.0:8000, toutes les interfaces réseau	127.0.0.1:11434, votre machine seulement
Clé sur l’API	Aucune d’origine ; --api-key ne couvre que 4 préfixes de route	Aucune, et le serveur local n’a aucune clé à vérifier
CORS d’origine	Fermé depuis la 0.32.0 (aucune origine autorisée)	Ouvert aux pages de localhost, 127.0.0.1 et 0.0.0.0 sur n’importe quel port
Envoie de lui-même	Statistiques d’usage vers stats.vllm.ai au démarrage et toutes les 10 minutes	2 types d’appel vers le cloud avec ollama serve, 4 avec l’application de bureau
Comment l’éteindre	VLLM_NO_USAGE_STATS=1 (ou 3 autres moyens)	OLLAMA_NO_CLOUD=1 coupe les 2 appels cloud ; la vérification horaire des mises à jour et la requête de compte de l’application restent

Une personne à la maison, ou une douzaine en même temps

C’est la question qui tranche. D’origine, Ollama traite 1 requête par modèle à la fois : dans le code de la 0.40.7, OLLAMA_NUM_PARALLEL vaut 1 par défaut, et toute autre requête attend son tour dans une file de 512 au plus. Pour une personne qui discute, code ou lance un script, c’est exactement ce qu’il faut : toute la carte travaille sur votre réponse. Vous pouvez augmenter OLLAMA_NUM_PARALLEL, mais chaque place en plus multiplie la mémoire du contexte : 4 requêtes en parallèle sur un contexte de 4 096 jetons réservent de la mémoire pour 16 384.

vLLM part de l’autre bout. Sur une carte graphique de moins de 70 Go de mémoire, c’est-à-dire toutes les GeForce, le code de la 0.32.0 laisse vllm serve traiter jusqu’à 256 requêtes à la fois, et il glisse les nouvelles dans le lot en cours à mesure qu’elles arrivent, au lieu de les faire attendre la fin de la précédente. C’est pour ça qu’il est né. Si votre famille, votre équipe ou une douzaine d’agents en chaîne sollicitent le même modèle, vLLM garde la carte occupée là où Ollama les servirait un par un.

De combien cela accélère-t-il vLLM ? Nous ne l’avons pas mesuré, et cela dépend du modèle, de la carte et du nombre de requêtes qui arrivent ensemble. Avec un seul utilisateur, il n’y a pas de lot à remplir : le grand atout de vLLM n’a rien à se mettre sous la dent.

NVIDIA, Mac ou simple processeur

Ici, le choix se fait souvent tout seul. vLLM est un programme Linux, et son cas de prédilection est une carte NVIDIA de capacité de calcul 7.5 ou plus : cela exclut la série GTX 10 et les plus anciennes. Les cartes AMD fonctionnent via ROCm, mais pour la 0.32.0 le paquet publié exige Python 3.12, ROCm 7.2.3 et glibc 2.39 ou plus récent. Sous Windows, pas de version native, seulement WSL. Sur un Mac Apple Silicon, la prise en charge propre à vLLM est expérimentale et limitée au processeur ; la puce graphique passe par un module à part, maintenu par sa communauté.

Ollama tourne presque partout : Windows 10 22H2 ou plus récent, macOS 14 ou plus récent et Linux, avec les cartes NVIDIA dès la capacité de calcul 5.0, AMD avec ROCm v7, et Vulkan, activé d’origine sous Windows et Linux et voie recommandée pour les Radeon sans ROCm. Sur un Mac Apple Silicon, il utilise la puce graphique, et depuis la 0.40.0 il fait tourner le modèle avec MLX par défaut dès qu’il en existe une version MLX.

Si votre ordinateur est un Mac ou un portable Windows, la comparaison s’arrête là : Ollama. Pour voir quels modèles tiennent sur votre machine, notre trouveur de modèle fait le calcul.

GGUF ou safetensors : les fichiers que lit chacun

Le format de vos modèles est le deuxième filtre. Le format natif de vLLM est safetensors, celui dans lequel sont publiés la plupart des modèles, plus de 20 schémas de quantification comme AWQ, GPTQ et FP8. GGUF, le format de presque tous les modèles quantifiés pour la maison, n’est plus intégré : depuis la 0.27, il vit dans un module à part que la documentation de vLLM elle-même qualifie de très expérimental. Les modèles viennent de Hugging Face par défaut.

Ollama parle GGUF via llama.cpp, et il peut aussi importer un dossier de safetensors ou un fichier GGUF avec un Modelfile, en quantifiant au passage si vous le demandez. La plupart des gens ne voient jamais les fichiers : ollama pull télécharge depuis la bibliothèque d’Ollama, et sur Apple Silicon une étiquette peut contenir une version MLX que le Mac préfère à la GGUF.

Donc, si vous avez déjà une collection de fichiers GGUF, Ollama les lit tels quels. Si vous voulez faire tourner un modèle exactement comme son éditeur l’a publié, en pleine précision ou en FP8 sur une carte NVIDIA, c’est le terrain de vLLM.

Mémoire : 92 % de la carte d’emblée, ou seulement ce dont le modèle a besoin

La première fois que vous lancez vllm serve, regardez la mémoire graphique : 92 % ont disparu. C’est voulu. Dans le code de la 0.32.0, gpu_memory_utilization vaut 0.92 par défaut, et vLLM réserve cette part dès le démarrage, pour les poids et un cache assez grand pour beaucoup de conversations à la fois. C’est une réservation, pas une consommation à la demande : tout ce qui a besoin de la carte doit tenir dans les 8 % restants. Si vous la partagez, baissez cette valeur à la main.

Ollama charge les poids et le cache dont le contexte a besoin, et il choisit ce contexte selon la mémoire graphique qu’il trouve : 4 096, 32 768 ou 262 144 jetons. Quand le modèle reste inutilisé un moment, il le décharge et rend la mémoire.

Les installer, et la première réponse

Ollama, c’est 2 étapes : l’installer avec l’installateur ou un script d’une ligne, puis ollama run suivi du nom d’un modèle. Il télécharge le modèle et ouvre une discussion dans le terminal. Sur macOS et Windows, il existe aussi une application de bureau avec une fenêtre de discussion.

vLLM est un paquet Python sans fenêtre. Avec la 0.32.0, il faut Python 3.11 à 3.14 ; on l’installe avec uv pip install vllm --torch-backend=auto (ou l’image Docker officielle), on lance vllm download-kernels une fois après chaque installation ou mise à jour, et on le démarre avec vllm serve suivi d’un modèle de Hugging Face. Ensuite, on lui parle par son API compatible OpenAI, depuis du code ou depuis une interface de discussion placée devant. Rien de difficile si vous êtes à l’aise dans un terminal, mais il y a plus de pièces, et les réglages de mémoire ci-dessus font partie du travail.

Nos guides pas à pas vous accompagnent pour chacun : démarrer Ollama en local et démarrer vLLM en local.

Quelles portes restent ouvertes : 0.0.0.0:8000 contre 127.0.0.1:11434

D’origine, vllm serve écoute sur 0.0.0.0:8000 : toutes les interfaces réseau de la machine, sans clé. Sur un portable dans un hôtel, n’importe qui sur ce wifi pourrait utiliser votre modèle. Ollama écoute sur 127.0.0.1:11434, votre machine seulement, et pour l’atteindre depuis un autre appareil il faut l’ouvrir exprès avec OLLAMA_HOST=0.0.0.0.

Aucun des deux ne demande de mot de passe d’origine. vLLM sait le faire : lancez-le avec --api-key, ou la variable VLLM_API_KEY, et les clients devront envoyer la clé. Mais la clé ne couvre que les routes sous 4 préfixes, /v1, /v2, /inference et /cohere ; d’autres routes du même port répondent sans elle, et la page de sécurité de vLLM elle-même conseille de ne pas compter sur la seule clé. Le serveur local d’Ollama n’a aucune clé : ses défenses sont d’écouter seulement sur votre machine, le CORS et un contrôle de l’en-tête Host de chaque requête, qui ne s’applique que tant qu’il écoute sur votre propre machine.

Le CORS décide quelles pages web peuvent utiliser le serveur depuis votre navigateur, et ici c’est désormais vLLM le plus strict. Depuis la 0.32.0, sa liste d’origines autorisées est vide : aucune page d’un autre site ne peut lire ses réponses tant que vous ne l’ajoutez pas avec --allowed-origins. Ollama accepte les pages servies depuis localhost, 127.0.0.1 et 0.0.0.0 sur n’importe quel port, plus quelques schémas d’application, et répond 403 à toute autre origine ; les extensions de navigateur doivent être ajoutées avec OLLAMA_ORIGINS. Gardez en tête que le CORS ne lie que les navigateurs : n’importe quel programme de votre réseau atteint vLLM quand même.

Encore une chose vérifiée dans le code de vLLM, parce que sa page de sécurité prévient que la communication interne de PyTorch peut écouter sur toutes les interfaces. Sur 1 machine, par défaut, le code de la 0.32.0 met en place cette communication avec un fichier dans le dossier temporaire, pas avec un port réseau ; il n’utilise TCP que sur les cartes AMD avec l’all-reduce d’AITER, avec le parallélisme de données (--data-parallel-size supérieur à 1) et entre plusieurs machines. Ces ports internes ne devraient jamais être joignables de l’extérieur.

Ce que chacun envoie de lui-même

C’est là qu’un utilisateur soucieux de sa vie privée devrait regarder à deux fois, et la réponse n’est pas celle qu’on attend peut-être. vLLM envoie des statistiques d’usage à stats.vllm.ai d’origine : 1 rapport complet au démarrage du moteur (carte graphique, processeur, mémoire, système d’exploitation, version de vLLM, l’architecture du modèle mais pas son nom, et réglages de démarrage), puis un battement toutes les 10 minutes tant que le serveur tourne. Cela fait 144 battements par jour. À son crédit : il garde une copie de tout ce qu’il envoie dans ~/.config/vllm/usage_stats.json, et n’importe lequel de 4 interrupteurs l’éteint : VLLM_NO_USAGE_STATS=1, DO_NOT_TRACK=1, VLLM_DO_NOT_TRACK=1 ou un fichier vide ~/.config/vllm/do_not_track. La valeur doit être exactement 1.

vLLM télécharge aussi, quand vous demandez un modèle absent du cache, depuis Hugging Face (HF_HUB_OFFLINE=1 l’empêche une fois vos modèles sur le disque). Et s’il manque les noyaux précompilés de FlashInfer, FlashInfer les récupère sur les serveurs de NVIDIA au démarrage de vLLM ; vllm download-kernels le fait une fois à l’installation, et FLASHINFER_NO_DOWNLOAD=1 l’interdit. Il ne vérifie pas les mises à jour et n’a pas de compte. Avant que FlashInfer ne télécharge ces noyaux, vLLM demande en général si le serveur de NVIDIA, edge.urm.nvidia.com, répond (1 requête, avec 5 secondes de limite), et FLASHINFER_NO_DOWNLOAD=1 n’arrête pas cette vérification. Installé avec pip, cela se produit tout seul sur les B200 et B300 avec presque n’importe quel modèle et peut se produire sur une H100 ou une RTX 50 avec des modèles comme gpt-oss. L’image Docker apporte déjà les noyaux, et avec eux sur le disque après vllm download-kernels, en général aucune des deux requêtes ne part.

Ollama n’a aucune bibliothèque d’analytique dans son code. Avec seulement ollama serve, comme sous Linux, il fait de lui-même 2 types d’appel à ollama.com : un catalogue de modèles recommandés toutes les 4 heures et les fiches de ses modèles cloud au démarrage du serveur. OLLAMA_NO_CLOUD=1 coupe les deux. Avec l’application de bureau sur macOS ou Windows, 2 types s’y ajoutent : une vérification des mises à jour toutes les heures, qu’aucun réglage n’arrête, et une requête de compte à l’ouverture de l’application.

La configuration la plus discrète de toutes, c’est donc l’un ou l’autre avec son interrupteur : vLLM avec VLLM_NO_USAGE_STATS=1, HF_HUB_OFFLINE=1 et FLASHINFER_NO_DOWNLOAD=1 une fois vllm download-kernels lancé, ou ollama serve sans l’application et avec OLLAMA_NO_CLOUD=1. Chaque destination, avec sa source et sa date, figure sur notre fiche vLLM et notre fiche Ollama.

Lequel nous installerions, selon votre profil

• Une personne, n’importe quel ordinateur : Ollama. Une commande, un modèle qui se charge et se décharge tout seul, et rien d’ouvert sur le réseau.
• Un Mac ou un portable Windows : Ollama. vLLM n’a pas de version Windows native, et sur Mac il ne tourne que sur le processeur.
• Une étagère de fichiers GGUF : Ollama, qui les importe sans conversion (un Modelfile et ollama create par modèle).
• Un Linux avec carte NVIDIA qui sert toute la maison, une équipe ou une flotte d’agents : vLLM, avec --host, une clé d’API et ses statistiques coupées.
• Un modèle exactement tel que son éditeur l’a publié, en safetensors ou en FP8 : vLLM.
• Une carte qui sert aussi aux jeux ou à d’autres programmes : Ollama, ou vLLM avec gpu_memory_utilization baissé à la main.

Vous hésitez aussi avec une application de bureau ? Notre comparatif LM Studio vs Ollama vous éclaire.