Ollama ou vLLM : quel serveur LLM choisir ?

Ollama ou vLLM, en un paragraphe

Ollama est un gestionnaire de modèles auquel est associé un serveur : il télécharge les poids quantifiés, les charge et répond sur 127.0.0.1:11434, avec le CPU si la machine n’a pas de GPU. vLLM est un moteur conçu pour le débit : il maintient un GPU à pleine charge en exécutant de nombreuses requêtes simultanément. C’est le mauvais outil sur une machine qui n’en possède pas. La décision se résume à cela. Une personne qui échange avec un assistant local utilise Ollama. Une application qui sert une équipe utilise vLLM.

Les deux exposent une API HTTP compatible avec OpenAI. Le code client passe donc de l’un à l’autre en modifiant l’URL de base. L’API ne fait pas la différence. La différence tient à ce qui se produit lorsqu’une deuxième requête arrive alors que la première génère encore des tokens.

Ce qu’est réellement Ollama

Ollama est une couche de commodité. Une seule commande d’installation vous fournit un registre de modèles (ollama pull llama3.1:8b), un stockage local des poids, une invite de chat, un service systemd et une API HTTP. Les modèles qu’il sert sont des fichiers GGUF, généralement quantifiés sur 4 bits. C’est pourquoi un modèle 7B ou 8B occupe environ 5 GB sur le disque au lieu de 16 GB. La quantification rend l’inférence sur CPU possible.

Son runner repose sur llama.cpp, la bibliothèque d’inférence C++ qui a rendu la quantification GGUF pratique sur du matériel standard. Ollama a depuis ajouté son propre moteur pour certaines familles de modèles plus récentes, mais llama.cpp reste le socle de la plupart des modèles qu’il sert. Lorsque des utilisateurs comparent Ollama à llama.cpp, ils comparent donc principalement une couche d’ergonomie à l’outil qu’elle encapsule.

La conception vise un seul utilisateur. En juillet 2026, la valeur par défaut de OLLAMA_NUM_PARALLEL est 1. Un modèle traite donc une seule requête à la fois et toutes les autres attendent dans une file qui contient 512 entrées par défaut (OLLAMA_MAX_QUEUE). Vous pouvez augmenter le paramètre de parallélisme, et la section ci-dessous explique le coût de ce réglage. Si vous n’avez jamais exécuté Ollama, commencez par héberger Ollama sur un VPS et garder le port 11434 fermé, car l’API ne fournit aucun mécanisme d’authentification.

Ce qu’est réellement vLLM

vLLM est uniquement un serveur d’inférence. Il ne gère pas de bibliothèque de modèles, ne fournit pas de prompt de chat et ne télécharge pas de modèle au moment de la requête. Vous indiquez un dépôt Hugging Face au lancement. vLLM charge ce modèle et le sert jusqu’à l’arrêt du processus.

Cette spécialisation permet d’obtenir un débit élevé. Deux mécanismes y contribuent. PagedAttention stocke le KV cache (cache clé-valeur, l’état d’attention par token qu’un modèle conserve pour chaque requête active) dans des blocs de taille fixe, comme un système d’exploitation pagine la mémoire. Une requête n’a plus besoin d’une grande réservation contiguë dimensionnée pour le pire cas. La mémoire auparavant réservée et inutilisée devient donc disponible pour davantage de requêtes simultanées. Le continuous batching permet à une nouvelle requête de rejoindre le batch en cours à l’étape de décodage suivante, au lieu d’attendre la fin du batch actuel. Une séquence terminée quitte immédiatement le batch et son emplacement est réutilisé.

En pratique, sur un seul GPU, passer d’un utilisateur simultané à trente augmente fortement le nombre total de tokens par seconde, tandis que le débit par utilisateur diminue beaucoup moins que prévu. Avec la configuration par défaut d’Ollama, passer d’un utilisateur à trente oblige simplement vingt-neuf personnes à attendre.

Le continuous batching fait toute la différence

Imaginez cinq requêtes arrivant au même moment sur chaque serveur, avec un matériel identique.

Avec sa configuration par défaut, Ollama exécute la première requête jusqu’à son terme, puis la deuxième, et ainsi de suite. Le cinquième appelant attend quatre générations complètes. Le débit total correspond à peu près à la vitesse d’une seule génération, car le processeur ne traite jamais qu’une seule séquence à la fois.

vLLM décode les cinq requêtes lors du même forward pass. Générer un token pour cinq séquences coûte à peine plus cher que générer un token pour une seule séquence, car l’opération coûteuse consiste à lire les poids du modèle depuis la mémoire, et cette lecture est partagée par tout le batch. C’est le même facteur de bande passante mémoire qui ralentit l’inférence sur CPU : le coût vient du déplacement des poids, pas des calculs arithmétiques.

Vous pouvez définir OLLAMA_NUM_PARALLEL=4 et bénéficier en partie de ce comportement. Le coût est la mémoire. Chaque slot parallèle a besoin de son propre KV cache, et Ollama répartit la fenêtre de contexte entre les slots. Ainsi, quatre requêtes parallèles sur un modèle configuré avec 8192 tokens de contexte laissent 2048 tokens de contexte à chaque requête. Cette valeur de 8192 est elle-même un choix, et non une constante imposée. Augmenter num_ctx et dimensionner la RAM nécessaire détermine donc si quatre slots sont réellement utilisables. Le cache paginé de vLLM évite cet arbitrage, car les blocs sont alloués à une requête au fur et à mesure que celle-ci s’allonge. Dans tous les cas, le nombre maximal d’utilisateurs qu’un même serveur peut servir simultanément dépend de la taille du KV cache, du coût du prefill et de la profondeur de la file d’attente. C’est pourquoi un serveur qui semblait suffisant pour une personne devient très lent à cinq.

Installer et servir avec Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

Le script d’installation crée un utilisateur système ollama, installe le binaire et enregistre ollama.service lié à 127.0.0.1:11434. La ligne eval rate affichée par --verbose indique votre vitesse réelle en tokens par seconde sur cette machine. Fiez-vous à cette valeur plutôt qu’aux chiffres publiés. Une seule mesure sur un seul prompt sert de point de départ, pas de mesure de capacité. C’est pourquoi mesurer les tokens par seconde sur plusieurs niveaux de concurrence permet de savoir si la machine tient la charge attendue et si louer un GPU revient moins cher que payer chaque token.

Pour augmenter la concurrence, utilisez un drop-in systemd afin qu’une mise à niveau n’écrase pas la modification :

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps indique ce qui est chargé, et sa colonne PROCESSOR montre la réalité. 100% CPU signifie qu’aucun GPU n’est utilisé. C’est l’explication la plus courante lorsqu’Ollama est lent. La ligne OLLAMA_KEEP_ALIVE=30m de ce drop-in est tout aussi importante sur une machine peu sollicitée, car la configuration par défaut décharge le modèle après cinq minutes sans requête. Conserver le modèle en mémoire entre les requêtes évite que le premier prompt après une heure d’inactivité doive à nouveau attendre tout le temps de chargement.

Installer et servir avec vLLM

vLLM nécessite Linux et Python 3.10 à 3.13. Installez-le dans son propre environnement virtuel, car il installe une version spécifique de PyTorch :

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

Servez ensuite un modèle. Le nom est un identifiant de dépôt Hugging Face, et non un tag court :

vllm serve Qwen/Qwen2.5-1.5B-Instruct

Le démarrage est lent la première fois, car vLLM télécharge les poids, puis profile le GPU pour déterminer combien de blocs de cache KV peuvent tenir. Il écoute sur le port 8000. Vérifiez son fonctionnement avant d’écrire du code client :

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

Si Docker est déjà installé sur le serveur, l’image officielle évite de gérer les dépendances CUDA :

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host est obligatoire, et non décoratif : PyTorch transmet les tenseurs entre les processus via la mémoire partagée, et l’allocation de mémoire partagée par défaut de Docker est trop faible pour l’inférence tensor-parallel.

Les options les plus importantes en production sont --max-model-len (la fenêtre de contexte que vous acceptez de payer), --gpu-memory-utilization (la fraction de la carte que vLLM peut utiliser, 0.92 par défaut en juillet 2026), --tensor-parallel-size pour répartir un modèle sur plusieurs GPU, et --api-key.

L’authentification est gérée par une option dans vLLM et absente d’Ollama

vLLM impose un bearer token si vous lui en fournissez un :

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

La même valeur peut provenir de la variable d’environnement VLLM_API_KEY. Une requête qui ne contient pas ce token reçoit une réponse HTTP 401. Cela ne justifie toujours pas d’exposer le port 8000 sur une interface publique : vLLM ne limite pas le débit et un token transmis en HTTP non chiffré peut être lu pendant le transport. En revanche, le serveur peut ainsi identifier l’appelant.

Ollama ne propose rien de comparable. Il n’y a ni clé, ni connexion, ni liste d’autorisation. Tout processus pouvant atteindre le port 11434 peut exécuter, télécharger ou supprimer des modèles. Laissez-le lié à la boucle locale et accédez-y via un VPN WireGuard que vous hébergez vous-même, ou via un reverse proxy avec authentification qui termine TLS (Transport Layer Security).

Matériel : besoins de chaque solution

Ollama fonctionne sur CPU. Un modèle quantifié sur 4 bits consomme environ un demi-gigaoctet de RAM par milliard de paramètres, auquel il faut ajouter environ 1 Go pour le runtime et davantage pour le contexte. Un modèle 3B nécessite donc environ 4 Go de mémoire libre, et un modèle 8B environ 8 Go. Sur un vCPU partagé, le débit atteint quelques tokens par seconde, au mieux une dizaine. Cela vient de la bande passante mémoire, pas d’une mauvaise configuration, et aucun flag ne peut y remédier. Pour observer ces chiffres sur une release précise plutôt que d’appliquer une règle générale, exécuter Nemotron 3.5 Lightning sur un VPS permet de déterminer le tag exact à télécharger, la quantité de RAM utilisée une fois le modèle chargé et si le fonctionnement sur CPU uniquement est suffisamment rapide au quotidien.

vLLM part du principe qu’un GPU est disponible. Par défaut, il sert des poids non quantifiés en précision 16 bits, soit environ 2 Go par milliard de paramètres. Un modèle 8B nécessite donc environ 16 Go de mémoire vidéo pour les seuls poids, avant même de prendre en compte le cache KV qui permet la concurrence pour laquelle vous avez installé vLLM. Sur une carte de 24 Go, il reste une capacité de cache utilisable. Sur une carte de 16 Go, ce n’est pas le cas. Vous devez donc choisir un modèle plus petit ou transmettre --quantization avec un checkpoint quantifié. Un backend CPU existe, mais les wheels standard ne sont pas compilés pour celui-ci. De plus, il élimine la raison même d’utiliser vLLM.

La question du matériel permet donc généralement de choisir le logiciel. Sans GPU, choisissez Ollama. Avec un GPU loué utilisé à 5 % parce que les requêtes sont traitées en série, choisissez vLLM.

Quelle solution pour votre charge de travail

• Une seule personne, un VPS avec CPU, pour rédiger et résumer : Ollama. Le rythme est acceptable et rien n’est plus simple.
• Un assistant de programmation, ou un serveur MCP reliant vos outils à un modèle local, que vous êtes le seul à appeler : Ollama. La concurrence limitée à une requête correspond à la charge réelle.
• Vous comparez cinq modèles cette semaine : Ollama. Télécharger et supprimer des modèles identifiés par des tags est précisément ce qu’il fait bien, tandis que vLLM nécessite de redémarrer le processus pour chaque modèle.
• Une application interne, un produit de chat ou un pipeline de recherche documentaire utilisé par de vrais utilisateurs : vLLM. C’est dans ce cas que le batching justifie le coût du GPU.
• Un job batch qui évalue cent mille documents pendant la nuit : vLLM, avec un --max-num-seqs élevé. Le débit est le seul indicateur qui compte ; la latence par document n’est pas importante.
• Une plateforme d’agents où plusieurs agents IA auto-hébergés interrogent le modèle en même temps : vLLM, car le trafic généré par les agents est naturellement irrégulier et parallèle.

Modes de défaillance et messages affichés

vLLM refuse de démarrer avec une erreur de KV cache. Le message indique les deux valeurs :

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

Le modèle déclare une fenêtre de contexte plus grande que la mémoire restante après le chargement des poids. Réduisez-la avec --max-model-len 8192 ou augmentez --gpu-memory-utilization si aucun autre processus n’utilise la carte. Dépasser environ 0.95 d’utilisation tend à remplacer cette erreur au démarrage par un crash CUDA pour cause de mémoire insuffisante plus tard, sous charge. C’est le pire des deux cas.

Ollama affiche Killed en pleine génération. Le Linux out-of-memory killer a arrêté le processus, car le modèle nécessitait plus de RAM que le serveur n’en possède. Confirmez-le avec sudo dmesg | grep -i oom. La solution consiste à utiliser un modèle plus petit ou davantage quantifié, pas à modifier un paramètre.

Ollama répond correctement seul, mais se bloque sous charge. Aucune erreur n’apparaît. Les requêtes prennent simplement plus de temps à mesure que le nombre d’appelants augmente, car OLLAMA_NUM_PARALLEL=1 les traite en série. Les réponses longues aggravent l’attente : un appelant qui occupe l’unique slot jusqu’à ce que le modèle décide de s’arrêter bloque tous les suivants. Limiter la réponse avec num_predict impose donc une durée maximale pendant laquelle une requête peut occuper le serveur. Augmentez le paramètre de parallélisme et acceptez un contexte plus petit par requête, ou déplacez la charge vers vLLM.

vLLM renvoie 401 à chaque appel. Vous l’avez démarré avec --api-key, mais le client n’envoie aucun en-tête Authorization. La plupart des bibliothèques clientes OpenAI utilisent la valeur que vous fournissez comme clé. Configurez-la donc à cet endroit au lieu de supprimer le flag.

vLLM indique que le modèle est introuvable. Ollama télécharge les modèles à la demande, contrairement à vLLM. Le champ model du corps de la requête doit correspondre à l’identifiant du repository avec lequel vous avez démarré vLLM, ou à la valeur de --served-model-name si vous en avez défini une. Vérifiez la chaîne exacte avec curl http://localhost:8000/v1/models.

Exécuter les deux est une réponse raisonnable

Ils ne s’excluent pas mutuellement. Une architecture courante consiste à utiliser vLLM sur une instance GPU pour servir l’application, et Ollama sur le VPS standard voisin pour les scripts locaux, les tâches cron et l’essai de nouvelles versions de modèles. Les deux points de terminaison sont compatibles avec l’API OpenAI : une seule bibliothèque cliente et un changement de base URL suffisent. La maîtrise des coûts compte davantage ici que le choix de l’un ou l’autre moteur, car un GPU inactif est facturé au même tarif qu’un GPU occupé. Maintenir des coûts prévisibles pour les agents et l’inférence relève d’une discipline distincte du choix du serveur.

FAQ

vLLM est-il plus rapide qu’Ollama ?

Pour une seule requête sur le même GPU, l’écart est limité, car les deux effectuent les mêmes calculs. Pour de nombreuses requêtes simultanées, vLLM est nettement plus rapide, car le continuous batching décode toutes les séquences actives en un seul forward pass, tandis que la configuration par défaut d’Ollama les traite l’une après l’autre. Sur une machine équipée uniquement d’un CPU, la question ne se pose pas : Ollama fonctionne dans ce contexte, contrairement à vLLM.

vLLM peut-il fonctionner sans GPU ?

Pas dans des conditions utiles. Les wheels standard ciblent les GPU NVIDIA ou AMD, et la raison d’être de vLLM — maintenir un accélérateur constamment chargé avec des requêtes groupées — disparaît sur un CPU. Un backend CPU existe pour le développement. Pour l’inférence réelle sur CPU, utilisez directement Ollama ou llama.cpp.

Quelle est la différence entre Ollama et llama.cpp ?

llama.cpp est la bibliothèque d’inférence, et GGUF est son format de poids quantifiés. Le runner d’Ollama repose dessus et ajoute les éléments que llama.cpp vous laisse gérer : un registre de modèles, le téléchargement automatique, un serveur résident, une unité systemd et un endpoint compatible avec l’API OpenAI. Ollama a ajouté son propre moteur pour certaines familles de modèles plus récentes. Les deux solutions ne reposent donc plus exactement sur les mêmes composants.

De combien de mémoire GPU vLLM a-t-il besoin pour un modèle 8B ?

Avec une précision de 16 bits, les poids seuls occupent environ 16 GB, soit environ 2 GB par milliard de paramètres. La KV cache nécessite également de l’espace. Une carte de 24 GB offre une marge confortable. Avec une carte de 16 GB, utilisez un checkpoint quantifié ou un modèle plus petit. vLLM utilise une fraction de la mémoire de la carte définie par --gpu-memory-utilization, dont la valeur par défaut est 0.92 en juillet 2026.

Dois-je modifier le code de mon application pour passer de l’un à l’autre ?

En général, vous devez uniquement modifier l’URL de base, la clé d’API et le nom du modèle. Ollama expose son interface compatible avec l’API OpenAI sur http://127.0.0.1:11434/v1 et ignore la clé, tandis que vLLM expose http://localhost:8000/v1 et vérifie la clé si vous en définissez une. La forme des noms de modèles diffère : llama3.1:8b pour Ollama, et un identifiant complet de dépôt tel que Qwen/Qwen2.5-1.5B-Instruct pour vLLM.