vLLM vs Ollama : quel moteur d'inférence IA choisir sur un serveur dédié

Ollama et vLLM : deux approches de l'inférence IA sur serveur

Faire tourner un modèle de langage (LLM) en local sur un serveur dédié Linux ou un serveur VPS nécessite un moteur d'inférence : le logiciel qui charge le modèle en mémoire, reçoit les requêtes et renvoie les réponses token par token. Deux projets open source dominent cet espace en 2026 : Ollama (version 0.40 au moment de la rédaction) et vLLM (version 0.32). Les deux permettent d'héberger un modèle de langage sur votre propre infrastructure, sans dépendre d'un service cloud tiers. Ce guide s'adresse aux administrateurs qui doivent gérer un serveur d'inférence IA et choisir le moteur le mieux adapté à leur cas d'usage.

Ollama privilégie la simplicité. Une seule commande installe le service, télécharge un modèle et lance une API REST. Il fonctionne sans carte graphique sur un VPS avec 8 Go de RAM, ce qui en fait le choix naturel pour le prototypage et l'usage mono-utilisateur. Pour un guide d'installation complet : installer Ollama sur un VPS Linux.

vLLM vise le débit en production. Son architecture repose sur PagedAttention, un mécanisme de gestion du cache KV qui découpe la mémoire GPU en blocs alloués à la demande, et sur le batching continu (continuous batching), qui insère de nouvelles requêtes dans un lot en cours sans attendre la fin du lot précédent. Les benchmarks publiés en 2026 montrent que vLLM traite de 2 à 5 fois plus de requêtes concurrentes qu'Ollama sur un même GPU NVIDIA, avec un gaspillage de VRAM réduit de 55 à 80 % grâce à l'allocation par pages.

Prérequis matériels et logiciels

Avant d'installer un moteur d'inférence IA, vérifiez que votre serveur répond aux exigences de ressources. Pour disposer d'un serveur capable de faire tourner un modèle 8B (type Llama 3.1 8B), consultez le tableau ci-dessous :

Un SSD NVMe accélère considérablement le chargement du modèle en mémoire au démarrage du serveur. Sur un disque dur classique, un modèle 70B met plusieurs minutes à se charger ; sur un SSD NVMe, l'opération passe sous la minute. L'espace disque total dépend du nombre de modèles hébergés : prévoyez 50 à 100 Go pour stocker plusieurs variantes. Sur un serveur physique dédié, un RAID 1 sur les disques système protège contre la panne d'un disque.

Installer Ollama sur un serveur Linux

L'installation d'Ollama se fait en une commande sur Ubuntu, Debian ou toute distribution Linux x86-64 ou ARM64. Le script détecte le système d'exploitation et configure un service systemd qui démarre automatiquement au boot :

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

Vérifiez l'état du service et la version installée :

systemctl status ollama
ollama --version

Téléchargez un modèle de langage et testez-le en ligne de commande :

ollama pull llama3.1:8b
ollama run llama3.1:8b "Résume en trois lignes ce qu'est PagedAttention."

L'API REST écoute par défaut sur le port TCP 11434 de l'adresse IP locale (127.0.0.1). Envoyez une requête depuis un autre programme ou depuis une interface comme Open WebUI :

curl http://localhost:11434/api/generate \
  -d '{"model":"llama3.1:8b","prompt":"Bonjour"}'

Ollama détecte automatiquement les GPU NVIDIA (pilote 550+) et AMD présents sur le serveur. Sans GPU, l'inférence s'exécute sur les processeurs : comptez environ 5 à 15 tokens par seconde pour un modèle 8B quantifié en Q4 sur un serveur VPS 8 coeurs. Avec un GPU, les performances passent à environ 60 tokens par seconde sur un modèle équivalent.

Installer vLLM sur un serveur dédié avec GPU

vLLM nécessite un GPU NVIDIA avec une compute capability 7.5 ou supérieure (T4, RTX 3090, A100, L4, H100, RTX 4090). Vérifiez que les pilotes NVIDIA et CUDA sont installés sur le système d'exploitation :

nvidia-smi
nvcc --version

La documentation officielle recommande uv, un gestionnaire d'environnement Python rapide, pour installer vLLM et résoudre les dépendances :

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

Lancez le serveur d'inférence avec un modèle Hugging Face :

vllm serve meta-llama/Llama-3.1-8B-Instruct

vLLM expose une API compatible OpenAI sur le port 8000. Testez avec curl :

curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"meta-llama/Llama-3.1-8B-Instruct","prompt":"Bonjour","max_tokens":50}'

Pour un déploiement conteneurisé, vLLM fournit des images Docker officielles. Consultez notre guide installer Docker sur un VPS pour préparer l'environnement. Pour pérenniser le service au redémarrage du serveur, créez une unité systemd : créer un service systemd sur Linux.

Tableau comparatif : Ollama vs vLLM

Le tableau ci-dessous résume les différences entre les deux moteurs d'inférence pour un déploiement sur serveur dédié Linux ou serveur VPS :

Les chiffres de débit proviennent de benchmarks publiés en 2026 sur un GPU NVIDIA avec le modèle Llama 3.1 8B. Les résultats varient selon le matériel, le modèle chargé et la configuration du moteur d'inférence.

Performances et débit sous charge concurrente

En mono-utilisateur, Ollama et vLLM affichent des débits proches sur un même GPU. Ollama atteint environ 62 tokens par seconde contre 71 pour vLLM sur un modèle 8B, un écart réduit grâce aux optimisations de llama.cpp pour l'inférence mono-stream.

La différence se creuse dès que plusieurs utilisateurs interrogent le modèle en parallèle. Sous 8 requêtes concurrentes, vLLM atteint un débit total environ 2,3 fois supérieur à celui d'Ollama. Sous 50 requêtes simultanées, vLLM maintient environ 920 tokens par seconde au total avec une latence P99 de 2,8 secondes, tandis qu'Ollama plafonne autour de 155 tokens par seconde avec une latence P99 de 24,7 secondes.

Cette scalabilité repose sur deux mécanismes au coeur de vLLM :

• PagedAttention : au lieu de réserver un bloc mémoire GPU contigu par requête, vLLM découpe le cache d'attention (KV cache) en pages de taille fixe, allouées à la demande. Le gaspillage de VRAM diminue de 55 à 80 %, ce qui permet de traiter plus de requêtes simultanément sur le GPU du serveur dédié.
• Batching continu (continuous batching) : vLLM insère de nouvelles requêtes dans le lot dès qu'une place se libère, sans attendre que toutes les requêtes du lot précédent soient terminées. Le GPU reste occupé en permanence, avec un taux d'utilisation qui monte à 85-92 % sous charge, contre 45-70 % sans batching continu.

Pour Ollama, le débit sous charge est limité par l'absence de batching continu natif. Le moteur traite les requêtes de manière séquentielle ou avec un parallélisme restreint. Ce fonctionnement convient à un usage mono-utilisateur mais pas à une API de production servie depuis un serveur dédié à plusieurs dizaines de clients simultanés.

Sécuriser l'API d'inférence sur un serveur

Par défaut, Ollama écoute uniquement sur l'adresse IP locale (127.0.0.1:11434) et vLLM sur 0.0.0.0:8000. Sur un serveur accessible depuis Internet, configurez un firewall pour bloquer l'accès direct aux ports d'inférence depuis l'extérieur. Sur Ubuntu et Debian, utilisez UFW :

# Bloquer l'accès externe au port vLLM
sudo ufw deny 8000
# Bloquer l'accès externe au port Ollama
sudo ufw deny 11434

Exposez l'API derrière un reverse proxy Nginx qui gère l'authentification et le chiffrement TLS. Consultez notre guide configurer Nginx en reverse proxy sur VPS Linux pour mettre en place cette couche de sécurité. Pour les règles de firewall avancées : ouvrir et filtrer les ports avec UFW.

Ne lancez jamais le moteur d'inférence en tant qu'utilisateur root. Créez un utilisateur système dédié (par exemple inference) et attribuez-lui les permissions minimales sur le répertoire des modèles et sur le socket GPU :

sudo useradd -r -m -s /usr/sbin/nologin inference
sudo chown -R inference: /opt/models

Monitoring et supervision du serveur d'inférence

Un moteur d'inférence IA consomme la quasi-totalité des ressources du serveur lorsqu'il est sous charge. Administrer un serveur d'inférence exige un monitoring de la RAM, des processeurs, de la VRAM GPU et de l'espace disque pour anticiper les saturations et éviter que l'OOM killer Linux ne termine le processus.

Surveillez les ressources système en temps réel avec htop et btop et la VRAM du GPU avec nvidia-smi :

# Surveiller la VRAM GPU en continu
watch -n 1 nvidia-smi

# Surveiller RAM et processeurs
btop

Pour un monitoring automatisé avec alertes, configurez des seuils sur la consommation mémoire et l'espace disque restant. Notre guide alertes et monitoring sur VPS Linux détaille la mise en place de notifications en cas de dépassement de seuil. Surveillez également l'espace disque disponible pour vos modèles : surveiller l'espace disque d'un VPS Linux.

Sauvegardes des modèles et des configurations

Les fichiers de modèles téléchargés et les fichiers de configuration du moteur d'inférence représentent des données critiques. Mettez en place une stratégie de sauvegardes (backup) pour éviter de tout retélécharger en cas de panne du disque SSD ou d'erreur de manipulation.

• Ollama : les modèles sont stockés dans ~/.ollama/models/. Sauvegardez ce répertoire complet. Les modèles pris depuis le registre Ollama peuvent être retéléchargés, mais une sauvegarde locale économise la bande passante et le temps de restauration.
• vLLM : les modèles téléchargés depuis Hugging Face sont cachés dans ~/.cache/huggingface/hub/. Sauvegardez également vos fichiers de configuration et vos scripts de démarrage (unité systemd, configuration du reverse proxy).

Planifiez un backup régulier vers un stockage distant. Pour chiffrer et externaliser vos sauvegardes : chiffrer les sauvegardes d'un serveur Linux hors site.

Héberger l'inférence IA : serveur dédié, VPS ou cloud GPU

Le choix de l'infrastructure pour héberger un moteur d'inférence IA dépend du débit visé, du budget et de la flexibilité souhaitée :

Pour les déploiements de production avec vLLM, un serveur dédié (serveur physique) offre le meilleur rapport coût/performance sur la durée. La virtualisation GPU (passthrough PCIe ou vGPU) dans une machine virtuelle ajoute une couche qui peut réduire les performances de 3 à 8 % selon les benchmarks. Pour un cluster multi-GPU, un serveur physique permet également d'exploiter le NVLink entre les cartes sans la latence ajoutée par la virtualisation. Pour comprendre les différences entre ces options : serveur dédié bare metal vs VPS.

Quel moteur choisir selon votre cas d'usage

Choisissez Ollama si vous êtes dans l'un de ces cas :

• Usage personnel ou prototypage sur un serveur VPS Linux sans GPU ;
• Un seul utilisateur interroge le modèle de langage à la fois ;
• Le serveur dispose de 8 à 32 Go de RAM système, sans carte graphique ;
• Vous voulez tester rapidement un modèle avant de passer en production ;
• Vous hébergez une interface locale type Open WebUI pour un usage interne.

Choisissez vLLM si :

• Plusieurs utilisateurs ou applications interrogent le modèle de langage en parallèle ;
• Vous déployez une API d'inférence IA en production sur un serveur dédié ;
• Le serveur possède un ou plusieurs GPU NVIDIA (A100, H100, RTX 4090, L4) ;
• Le débit en tokens par seconde sous charge concurrente est votre métrique prioritaire ;
• Vous connectez le moteur d'inférence à des applications tierces (chatbots, bases de données vectorielles, pipelines de traitement).

Les deux moteurs ne s'excluent pas. Un scénario courant consiste à prototyper avec Ollama sur un serveur VPS, puis à migrer le modèle vers vLLM sur un serveur dédié équipé de GPU quand le nombre d'utilisateurs augmente. Cette flexibilité permet de monter en charge progressivement sans refondre l'architecture applicative, car les deux moteurs exposent une API compatible OpenAI.

Questions fréquentes

Peut-on faire tourner vLLM sans GPU ?

Non. vLLM nécessite un GPU NVIDIA avec une compute capability 7.5 ou supérieure (T4, A100, L4, H100, RTX 3090, RTX 4090). L'inférence sur CPU n'est pas prise en charge. Si votre serveur n'a pas de GPU, utilisez Ollama, qui fonctionne sur le processeur à partir de 8 Go de RAM.

Combien de VRAM faut-il pour un modèle 70B avec vLLM ?

Un modèle 70B en précision FP16 consomme environ 140 Go de VRAM. Il faut au minimum deux GPU A100 80 Go ou quatre GPU avec 48 Go chacun. Avec la quantification AWQ en 4 bits, la consommation descend à environ 40 Go de VRAM, ce qui tient sur un seul A100 80 Go.

L'API d'Ollama est-elle compatible avec l'API OpenAI ?

Oui. Ollama expose un endpoint compatible OpenAI sur /v1/chat/completions. Les applications qui utilisent le SDK OpenAI peuvent pointer vers http://adresse-IP-serveur:11434/v1 sans modification du code. vLLM expose le même format d'API sur le port 8000.

Comment surveiller la consommation VRAM de vLLM ?

Exécutez nvidia-smi en SSH pour afficher la consommation VRAM en temps réel. Pour un monitoring continu, lancez watch -n 1 nvidia-smi. Complétez avec htop ou btop pour surveiller la RAM système et les processeurs du serveur dédié.

Peut-on utiliser Ollama et vLLM sur le même serveur ?

Oui. Ollama écoute par défaut sur le port 11434, vLLM sur le port 8000. Les deux peuvent coexister si le serveur dispose de suffisamment de RAM et de VRAM pour charger les deux modèles simultanément. Vérifiez que vos règles de firewall autorisent les deux ports en interne et que l'espace disque SSD est suffisant pour stocker les modèles des deux moteurs.

Quel modèle de langage choisir pour un serveur avec 24 Go de VRAM ?

Avec 24 Go de VRAM (RTX 3090, RTX 4090), vous pouvez charger un modèle 8B en FP16 (environ 16 Go) ou un modèle 13 à 14B quantifié en 4 bits (environ 10 Go). Les modèles 70B nécessitent plusieurs GPU ou une quantification agressive.

Faut-il un accès root pour installer Ollama ou vLLM ?

Oui. L'installation d'Ollama via le script officiel crée un service systemd et nécessite un accès root ou sudo. Pour vLLM, l'installation des pilotes NVIDIA et du toolkit CUDA requiert également les droits root. L'exécution du moteur d'inférence peut ensuite se faire avec un utilisateur dédié (recommandé pour la sécurité).

Comment sauvegarder les modèles hébergés sur le serveur ?

Sauvegardez le répertoire des modèles (Ollama : ~/.ollama/models/, vLLM/Hugging Face : ~/.cache/huggingface/hub/) vers un backup distant. Un SSD de sauvegarde ou un stockage objet externe protège contre la perte de données. Planifiez ces sauvegardes en tâche automatique avec cron ou un timer systemd.

Conclusion

Ollama et vLLM répondent à deux besoins distincts pour héberger un moteur d'inférence IA sur serveur Linux. Ollama convient à l'administrateur qui veut faire tourner un LLM en local sans GPU, en quelques minutes, sur un serveur VPS. vLLM est conçu pour les déploiements de production sur serveur dédié avec GPU, où le débit sous charge concurrente et la gestion efficace de la VRAM font la différence. Commencez par Ollama pour valider votre modèle de langage, puis passez à vLLM quand le trafic ou le nombre d'utilisateurs l'exige. Dans les deux cas, sécurisez l'API avec un firewall, mettez en place un monitoring des ressources et planifiez des sauvegardes régulières de vos modèles et configurations.