vLLM vs Ollama : quel moteur pour votre charge de travail ?

vLLM vs Ollama : lequel choisir ?

Gardez Ollama sur un portable, pour un assistant privé ou pour un petit service interne qui répond déjà assez vite. Choisissez vLLM pour un service GPU partagé soumis à des requêtes simultanées soutenues, ou lorsque vous avez besoin de piloter précisément l’inférence distribuée. Le simple fait de passer sur un serveur ne justifie pas un changement de moteur.

Ollama réunit le téléchargement, la configuration et l’exécution des modèles dans un workflow compact. vLLM est un moteur d’inférence conçu pour ordonnancer de nombreuses requêtes et gérer leur mémoire de travail. Aucun des deux n’est le modèle lui-même : passer une application de l’un à l’autre change la manière dont son modèle s’exécute.

Le choix repose sur quatre éléments : le pic de requêtes simultanées, la mémoire GPU disponible, les fichiers exacts du modèle et la latence promise aux utilisateurs. Le nombre de comptes inscrits renseigne peu sur ces besoins. Une petite équipe de développement qui fait tourner des agents peut générer davantage de travail simultané qu’un groupe bien plus large posant quelques questions de temps à autre.

Coût des logiciels et documentation vérifiés le 12 octobre 2026. Ce comparatif s’appuie sur la documentation et sur une analyse de coûts chiffrée ; aucun benchmark d’inférence n’a été réalisé pour cet article. La page tarifaire d’Ollama prévoit une utilisation locale gratuite, et la licence du projet vLLM autorise son utilisation sans frais de logiciel. Tarifs d’Ollama, licence de vLLM.

Les lignes consacrées aux fonctionnalités s’appuient sur la documentation officielle d’Ollama sur les requêtes simultanées, la présentation des fonctionnalités de vLLM et le guide de mise à l’échelle de vLLM. Les choix recommandés relèvent d’une appréciation éditoriale de ces capacités documentées, pas d’un classement de vitesse mesurée.

Utilisateurs, GPU, taille du modèle : comment trancher ?

Ces situations servent à choisir la solution à évaluer en premier ; elles ne garantissent aucune capacité. Par « utilisateurs », on entend ici des personnes ou des agents dont les requêtes se chevauchent. Les fourchettes sont des exemples pour préparer le déploiement. Un modèle 8B comporte environ huit milliards de paramètres, les valeurs numériques stockées qui le définissent.

La taille du modèle ne suffit pas à décider quel GPU acheter. Dans un calcul théorique, les seuls poids d’un modèle dense 8B à 4 bits par poids occupent au minimum 4 Go ; ceux d’un modèle 70B, au minimum 35 Go. Le calcul est : paramètres × bits ÷ 8, en octets décimaux. Les métadonnées de quantification, les tenseurs de précision supérieure, l’environnement d’exécution et la mémoire des conversations s’ajoutent à ce minimum. Aucun de ces chiffres ne constitue une recommandation de capacité VRAM.

Voilà pourquoi « le modèle se charge » n’est pas un critère de validation suffisant. Une machine peut contenir les poids sans avoir assez de place pour les conversations que vos utilisateurs gardent ouvertes. Choisissez d’abord le checkpoint à l’aide du guide des modèles locaux pour le développement, puis dimensionnez l’infrastructure pour sa charge d’inférence.

Installation et matériel : Ollama simplifie la première machine

Ollama prend l’avantage quand l’objectif immédiat est de faire fonctionner un modèle utile sur le matériel que vous possédez déjà. Ses applications de bureau et son workflow en ligne de commande réduisent le nombre de choix à faire pour le déploiement. Sous Linux, la documentation indique cet installateur :

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.2

Utilisez ollama serve si le serveur ne tourne pas déjà. Le guide Linux décrit aussi un service lancé au démarrage ; pour répondre aux requêtes d’autres utilisateurs, un service persistant convient mieux qu’un terminal laissé ouvert.

Ollama prend en charge l’accélération GPU d’Apple via Metal, certains matériels AMD via ROCm, les GPU NVIDIA et d’autres appareils Windows/Linux via Vulkan. Sa page NVIDIA indique actuellement une capacité de calcul (« compute capability ») de 5.0 ou plus, avec des exigences de pilote qui varient pour les anciennes cartes. Vérifiez la carte et le système d’exploitation exacts dans la liste du matériel compatible avec Ollama.

vLLM prend l’avantage lorsque l’installation pose les bases d’un environnement d’inférence administré. Son guide de démarrage NVIDIA actuel utilise un environnement Python isolé. Avec uv installé et un pilote GPU compatible, la procédure documentée est la suivante :

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

Ces commandes proviennent de la documentation ; elles n’ont pas été exécutées pour ce comparatif. Les installations AMD et Intel suivent des instructions propres à leur backend. Guide de démarrage de vLLM.

La procédure d’installation NVIDIA de vLLM exige Linux et une capacité de calcul de 7.5 ou plus. Elle ne prend pas en charge Windows en natif ; la documentation oriente les utilisateurs de Windows vers WSL. NVIDIA n’est pas la seule option matérielle : l’index des installations couvre aussi AMD ROCm, Intel XPU, les solutions CPU et Apple Silicon via le plugin vLLM-Metal maintenu par la communauté. Prérequis GPU, index des installations.

La solution Apple utilise MLX et des modèles optimisés pour MLX. Il faut l’évaluer comme un backend à part entière, sans présumer qu’elle se comporte comme un serveur CUDA. Pour un workflow centré sur le Mac, Ollama reste le point de départ le plus simple. Si votre choix porte surtout sur l’environnement de travail sur ordinateur, consultez le comparatif Ollama vs LM Studio.

Performances de vLLM et d’Ollama : tout se joue sur les requêtes simultanées

vLLM est le choix par défaut le plus solide pour une charge simultanée soutenue, car ses fonctions d’ordonnancement documentées répondent directement à ce besoin. Le débit désigne la quantité totale de travail achevé sur une période donnée. Il ne mesure pas la rapidité d’apparition d’une réponse isolée.

vLLM met en avant le continuous batching, qui intègre de nouvelles requêtes au fur et à mesure que celles en cours avancent, et PagedAttention, qui gère le cache de clés et de valeurs utilisé pendant la génération de texte. Ce cache, généralement appelé cache KV, sert de mémoire de travail au modèle pour les tokens de la conversation. Présentation des fonctionnalités de vLLM.

Le chunked prefill découpe la lecture d’un long prompt en portions plus petites, qui peuvent partager le temps d’exécution avec la génération des réponses en cours. La mise en cache des préfixes réutilise les calculs lorsque le début des prompts est identique, par exemple lorsqu’un prompt système se répète. Elle accélère le traitement du prompt ; elle ne supprime pas le travail nécessaire pour générer les nouveaux tokens de réponse. Ordonnancement et réglages, limites de la mise en cache des préfixes.

Ollama gère déjà les requêtes parallèles

La documentation d’Ollama prévoit des requêtes parallèles par modèle et le chargement de plusieurs modèles à la fois, dans les limites de la mémoire disponible. OLLAMA_NUM_PARALLEL règle le premier point ; OLLAMA_MAX_LOADED_MODELS, le second. OLLAMA_MAX_QUEUE limite le nombre de requêtes en attente, et un serveur surchargé peut renvoyer une erreur HTTP 503. La FAQ actuelle indique une valeur par défaut de 1 pour les requêtes parallèles. Réglages des requêtes simultanées dans Ollama.

Pour un petit assistant de support, autoriser davantage de requêtes simultanées peut suffire. Mais allonger la file d’attente n’ajoute aucune puissance de calcul : cela peut simplement faire patienter les clients plus longtemps avant l’arrivée du premier token. Réglez le service pour respecter le temps de réponse visé, pas pour accepter la plus grande file possible.

Le contexte peut absorber la mémoire prévue pour davantage d’utilisateurs

Fixez explicitement la taille du contexte avant de comparer les moteurs. La page d’Ollama consacrée au contexte décrit des valeurs par défaut qui dépendent de la mémoire, alors que sa FAQ indique encore une valeur fixe. Cette divergence dans la documentation donne une raison de plus d’inspecter les réglages effectifs, plutôt que de supposer qu’ils sont identiques sur le portable et le serveur. ollama ps affiche le contexte chargé et la répartition entre CPU et GPU. Guide du contexte dans Ollama.

Prenons une configuration illustrative : quatre conversations parallèles à 8,192 tokens réservent une capacité de 32,768 tokens de contexte. Par rapport à une seule conversation à 4,096 tokens, cela représente huit fois la capacité totale de contexte, et non huit fois la RAM totale du processus. Les poids du modèle et les autres allocations ne suivent pas la même progression. La documentation d’Ollama sur les requêtes simultanées explique cet effet multiplicateur du contexte.

vLLM se heurte lui aussi aux limites de la mémoire. Son guide de réglage avertit qu’un espace KV insuffisant peut provoquer des préemptions et des recalculs, au détriment de la latence. Réduire le nombre de séquences simultanées ou le budget de tokens par lot est une réponse possible ; ajouter des GPU en est une autre. Un ordonnanceur plus performant ne crée pas la mémoire qui manque à la machine.

Le bon signal pour changer de moteur, c’est un objectif de service qui n’est plus tenu sous une charge de pointe représentative, malgré des réglages raisonnables. Relevez le délai avant le premier token, le temps jusqu’à la fin de la réponse, les requêtes réussies, la croissance de la file d’attente et les erreurs. Comparez un percentile élevé en plus de la médiane, car les utilisateurs remarquent les réponses lentes. vLLM expose des métriques de production pour faciliter ce travail.

Conservez la même révision du modèle, la même précision, les mêmes longueurs de prompt, les mêmes limites de sortie et le même profil de trafic. Comparer un petit modèle quantifié sous Ollama à un checkpoint plus volumineux en haute précision sous vLLM revient à comparer deux déploiements, pas à mesurer isolément les moteurs.

Formats quantifiés : migrer, c’est aussi déplacer le modèle

Ollama a l’avantage pour conserver un package de modèle local existant ; vLLM, pour choisir un format d’inférence adapté au matériel. La quantification stocke les valeurs du modèle avec une précision réduite afin de diminuer les besoins en mémoire. Le conteneur de fichiers, la méthode de quantification et le backend d’exécution posent chacun leur propre question de compatibilité.

Ollama documente l’importation de poids Safetensors et de modèles GGUF en un seul fichier ou répartis sur plusieurs fichiers. GGUF est un format de fichiers de modèle couramment utilisé pour l’inférence locale ; le guide d’importation actuel d’Ollama précise que la quantification GGUF doit avoir lieu avant l’importation, et non pendant celle-ci. De son côté, l’API de création cite nvfp4 comme exemple de quantification à l’importation. Cela ne garantit pas que toutes les architectures et tous les GPU prennent en charge cette méthode. Guide d’importation d’Ollama, API de création.

Ollama cite également f16, q8_0 et q4_0 pour son cache KV. Ce sont des réglages du cache, pas une liste interchangeable de formats pour les poids du modèle. L’utilisation d’un cache quantifié nécessite Flash Attention. Documentation du cache d’Ollama.

vLLM répertorie AWQ/GPTQ, FP8, INT8, INT4, MXFP4/MXFP8, NVFP4 et d’autres intégrations de quantification. Sa matrice de compatibilité varie selon l’implémentation et le matériel : la seule mention « compatible 4 bits » ne suffit donc pas pour décider d’un achat. Vérifiez l’association exacte du checkpoint et des kernels. Documentation de la quantification dans vLLM, présentation des formats.

Un tokenizer convertit le texte en identifiants de tokens que le modèle comprend. Modifier les poids, le tokenizer, le format des conversations ou la quantification peut changer les réponses, les appels d’outils et l’utilisation de la mémoire. Prévoyez des vérifications de non-régression même si le nom de la famille de modèles reste identique.

Mellum2.1 : pourquoi les fichiers disponibles à la sortie comptent

L’annonce de Mellum2.1 publiée par JetBrains le 8 octobre 2026 illustre une sortie privilégiant les serveurs : le billet annonçait pour bientôt des versions GGUF destinées à Ollama, llama.cpp et LM Studio. La page du modèle fournit une procédure d’inférence avec vLLM, et les intégrations disponibles au lancement comprennent vLLM et SGLang, un autre serveur d’inférence. Annonce de JetBrains, page du modèle.

Ce décalage du lancement s’est déjà réduit : le dépôt GGUF officiel de JetBrains contient des fichiers quantifiés téléchargeables, comme vérifié le 12 octobre. Le « bientôt disponible » du billet de lancement ne décrit donc plus la disponibilité actuelle. La leçon pratique : vérifiez les fichiers et la procédure d’inférence disponibles avant de changer de moteur uniquement pour accéder à un nouveau modèle. Fichiers GGUF officiels.

Serveurs d’inférence LLM compatibles OpenAI : gardez le client, vérifiez le comportement

Les deux projets documentent un serveur compatible OpenAI, mais des requêtes de même forme ne garantissent pas un comportement identique. L’URL de base locale d’Ollama est http://localhost:11434/v1/ ; l’exemple de vLLM utilise http://localhost:8000/v1. Si votre application utilise l’API native /api/chat d’Ollama, migrer demande une adaptation de l’API, pas un simple changement de port. Compatibilité d’Ollama, documentation du serveur vLLM.

Par exemple, après avoir installé vLLM sur du matériel compatible, la commande suivante expose le modèle de l’exemple documenté du serveur, avec une limite de contexte explicite et un nom destiné à l’application :

vllm serve NousResearch/Meta-Llama-3-8B-Instruct \
  --host 127.0.0.1 \
  --port 8000 \
  --max-model-len 8192 \
  --served-model-name app-model

Il s’agit d’un exemple de configuration, pas du checkpoint correspondant à la commande Ollama précédente ni d’une recommandation de dimensionnement pour la production. --served-model-name permet au client de conserver un nom de modèle stable lorsque le déploiement change. Arguments du moteur vLLM.

Examinez les chat templates, qui convertissent les rôles des messages dans le format d’entrée du modèle, et fixez explicitement les paramètres d’échantillonnage. vLLM peut appliquer les valeurs par défaut du fichier generation_config.json d’un dépôt ; --generation-config vllm désactive cette substitution. Comparez l’analyse des appels d’outils, les sorties structurées, le streaming, l’annulation et la gestion des erreurs à partir des requêtes réelles de l’application.

Intégrez l’authentification à la migration. L’exemple de compatibilité locale d’Ollama ignore la valeur de la clé API fournie par le client. vLLM prend en charge une clé API, mais sa documentation de sécurité avertit qu’elle ne protège pas tous les endpoints. Gardez le backend privé et appliquez l’authentification, TLS et les restrictions de routes au point d’entrée du service. Limites de la clé API de vLLM.

Si votre application change souvent de modèle de base, un autre coût de migration apparaît : la FAQ de vLLM décrit l’utilisation d’instances de serveur distinctes et d’une couche de routage pour gérer plusieurs modèles de base. Un alias d’API ne charge pas un autre modèle. La capacité d’Ollama à gérer plusieurs modèles chargés peut offrir un workflow plus pratique pour un outil interne peu sollicité. Limite de vLLM pour plusieurs modèles.

Coûts : une même charge, des dépenses d’exploitation différentes

Aucun moteur ne l’emporte grâce à un tarif au token plus bas en auto-hébergement : le moteur ne facture pas de tokens. Les offres cloud payantes d’Ollama constituent un service distinct ; elles ne sont pas nécessaires pour servir des modèles locaux. Le guide des tarifs d’Ollama explique cette distinction ; consultez la page du fournisseur citée plus haut pour les offres cloud en vigueur.

Avec du matériel que vous possédez, le coût mensuel comprend l’électricité, la quote-part du coût du matériel et votre temps. Avec du matériel loué, partez du tarif horaire proposé pour la machine, puis ajoutez le stockage, le réseau et l’exploitation. Une inférence plus efficace ne fait économiser de l’argent que si elle réduit les ressources provisionnées, raccourcit la durée facturée ou apporte un bénéfice métier que vous pouvez chiffrer.

Un exemple de budget à conditions comparables

Les chiffres suivants sont des hypothèses budgétaires explicites, pas des tarifs de fournisseur ni des résultats de benchmark : un GPU à $1 de l’heure, 730 heures par mois et 100,000 tâches réussies. Chaque tâche comprend 2,000 tokens de prompt et 1,000 tokens de sortie, avec le même modèle, la même quantification, le même niveau de qualité et le même objectif de latence sur les deux moteurs.

Si les deux tiennent la charge sur un GPU loué en continu, chacun coûte $730 de calcul par mois, soit $0.0073 par tâche réussie et par 1,000 tokens de sortie. Ce dénominateur en tokens de sortie suppose une charge de traitement du prompt constante ; il ne s’agit pas d’un tarif combinant entrée et sortie.

Ajoutons maintenant deux heures d’exploitation par mois pour le déploiement vLLM, au tarif supposé de $100 de l’heure, ainsi que quatre heures de migration ponctuelles :

• Déploiement Ollama de référence : $730 de coûts récurrents, hors coûts communs aux deux solutions.
• vLLM sur le même matériel : $930 de coûts récurrents, soit $0.0093 par 1,000 tokens de sortie.
• Premier mois de vLLM, migration comprise : $1,330, soit $0.0133 par 1,000 tokens de sortie.

Ces durées sont des paramètres à remplacer par vos propres estimations, pas une affirmation sur le temps nécessaire pour migrer. Le travail d’exploitation commun aux deux solutions, le stockage, les frais de réseau et les taxes sont exclus des deux côtés.

À quel moment vLLM devient-il moins cher ?

À ce tarif horaire, vLLM doit économiser plus de 200 heures GPU par mois pour compenser le surcroît d’exploitation supposé. Amortir les $400 de migration dès le premier mois porte le seuil à plus de 600 heures GPU économisées.

Pour un service fonctionnant en continu, supposons que votre propre test de charge montre qu’Ollama a besoin de deux réplicas GPU identiques, contre un seul pour vLLM, afin de traiter la même charge dans le même délai. Le coût de calcul d’Ollama passe alors à $1,460 ; avec vLLM, le calcul et l’exploitation supplémentaire restent à $930. Dans ce scénario, l’économie atteint $530 par mois, ce qui amortit les $400 de migration en environ 0.75 mois.

C’est un calcul de seuil de rentabilité, pas une affirmation selon laquelle vLLM divise par deux vos besoins en GPU. Si les deux moteurs exigent le même matériel et qu’aucun autre bénéfice ne justifie le changement, la comparaison des frais de logiciel ne bascule jamais en faveur de vLLM. Aucun nombre d’utilisateurs ne permet de fixer un seuil universel défendable.

Une checklist courte pour migrer d’Ollama vers vLLM

Basculez vers un ensemble modèle-API validé en conservant un routage réversible. Les poids téléchargés ne sont qu’une partie de ce dont dépendent vos utilisateurs.

Ne migrez pas encore si Ollama atteint l’objectif de service, si le modèle requis ne dispose pas d’une solution validée sous vLLM ou si la migration revient simplement à troquer un package fonctionnel contre un backend mal connu. Garder Ollama sur les portables et vLLM sur un serveur partagé peut aussi être pertinent, à condition de tester les différences au lieu de supposer que développement et production sont identiques. Pour élargir la sélection, consultez les alternatives à Ollama.

La prochaine étape est concrète : capturez une charge représentative des périodes les plus chargées, fixez le temps de réponse acceptable, puis rejouez-la sur le serveur envisagé avant d’acheter de la capacité supplémentaire.

Questions fréquentes

Utilisez la checklist d’audit des workflows métier avec l’IA pour choisir quel workflow privé mérite un serveur de modèles partagé, et abonnez-vous à la newsletter pour suivre les prochaines évolutions des outils.