Ollama ou vLLM : quel serveur LLM choisir ?

Ollama vs vLLM, en un paragraphe

Ollama est un gestionnaire de modèles avec un serveur intégré : il télécharge les poids quantifiés, les charge et répond sur 127.0.0.1:11434, avec le CPU si c'est la seule ressource disponible sur la machine. vLLM est un moteur optimisé pour le débit : il maintient un GPU à pleine charge avec de nombreuses requêtes exécutées simultanément. C'est le mauvais outil sur une machine qui n'en possède pas. C'est tout ce qu'il faut décider. 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 peut donc passer de l'un à l'autre en modifiant l'URL de base. L'API n'est pas la différence. La différence apparaît 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 magasin local de 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 en 4 bits. C’est pourquoi un modèle 7B ou 8B occupe environ 5 GB sur 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 courant. Ollama a depuis ajouté son propre moteur pour certaines familles de modèles plus récentes, mais llama.cpp reste la base de la plupart des modèles qu’il sert. Ainsi, lorsque l’on compare Ollama à llama.cpp, on compare principalement une couche d’ergonomie avec le composant qu’elle encapsule.

La conception cible un seul utilisateur. En juillet 2026, la valeur par défaut de OLLAMA_NUM_PARALLEL est 1. Cela signifie qu’un modèle traite une seule requête à la fois et que toutes les autres attendent dans une file qui contient par défaut 512 entrées (OLLAMA_MAX_QUEUE). Vous pouvez augmenter le paramètre de parallélisme, et la section ci-dessous explique le coût de ce changement. 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 n’utilise 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 aucun 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 démarrage. 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 sont à l’œuvre. PagedAttention stocke le KV cache (cache clé-valeur, l’état d’attention par token que le 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 réservation contiguë importante, dimensionnée pour le pire cas. La mémoire auparavant réservée et inutilisée devient 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. Lorsqu’une séquence se termine, elle 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 la vitesse par utilisateur diminue bien moins que prévu. Avec la configuration par défaut d’Ollama, passer d’un utilisateur à trente fait simplement attendre vingt-neuf personnes.

Le batching continu fait toute la différence

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

Avec ses paramètres par défaut, Ollama traite la première requête jusqu'à son terme, puis la deuxième, et ainsi de suite. Le cinquième appelant attend la fin de quatre générations complètes. Le débit total correspond approximativement à 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 séquences lors du même passage forward. 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 la partie 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 principe 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 d'une partie de cet avantage. Le coût est la mémoire. Chaque slot parallèle nécessite son propre cache KV, et Ollama répartit la fenêtre de contexte entre les slots. Ainsi, quatre requêtes parallèles utilisant un modèle configuré pour 8192 tokens laissent 2048 tokens de contexte à chaque requête. Le cache paginé de vLLM évite ce compromis, car les blocs sont alloués à une requête au fur et à mesure qu'elle s'allonge réellement.

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 le nombre réel de tokens par seconde sur cette machine. Fiez-vous à cette valeur plutôt qu’à tout chiffre publié.

Pour augmenter la concurrence, utilisez un drop-in systemd afin qu’une mise à niveau n’écrase pas cette 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 affiche ce qui est chargé, et sa colonne PROCESSOR indique la réalité. 100% CPU signifie qu’aucun GPU n’est utilisé. C’est l’explication exacte de la plupart des rapports indiquant qu’Ollama est lent.

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 le logiciel 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-le 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 la machine, 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 requis, 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.

En production, les options les plus importantes 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 se limite à une option dans vLLM et est 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, car 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 fournit aucun mécanisme de ce type. 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 écouter sur loopback et accédez-y via un VPN WireGuard que vous hébergez vous-même, ou par l’intermédiaire d’un reverse proxy qui authentifie les clients et termine TLS (transport layer security).

Matériel : besoins de chaque solution

Ollama fonctionne sur CPU. Un modèle quantifié en 4 bits consomme environ un demi-gigaoctet de RAM par milliard de paramètres, plus environ un gigaoctet de surcharge d’exécution et davantage pour le contexte. Un modèle 3B nécessite donc environ 4 GB de mémoire libre, et un modèle 8B environ 8 GB. Sur un vCPU partagé, le débit est de quelques unités à une faible dizaine de tokens par seconde. Cela vient de la bande passante mémoire, pas d’une mauvaise configuration. Aucun flag ne peut y remédier.

vLLM suppose la présence d’un GPU. Par défaut, il sert des poids non quantifiés avec une précision de 16 bits, soit environ 2 GB par milliard de paramètres. Un modèle 8B nécessite environ 16 GB de mémoire vidéo pour les seuls poids, avant de réserver le KV cache qui permet la concurrence pour laquelle vous avez installé vLLM. Sur une carte de 24 GB, il reste assez de mémoire pour un cache utilisable. Sur une carte de 16 GB, ce n’est pas le cas. Vous devez donc choisir un modèle plus petit ou passer --quantization avec un checkpoint quantifié. Un backend CPU existe, mais les wheels standard ne sont pas compilées pour celui-ci. Il annule donc l’intérêt même d’exécuter vLLM.

La question du matériel permet donc généralement de choisir le logiciel. Sans GPU, utilisez Ollama. Si un GPU loué reste à 5 % d’utilisation parce que les requêtes sont sérialisées, utilisez vLLM.

Lequel choisir pour votre charge de travail

• Une seule personne, un VPS avec CPU, pour rédiger et résumer : Ollama. Le rythme est acceptable et aucune autre solution n’est plus simple.
• Un assistant de programmation ou un serveur MCP reliant vos outils à un modèle local, utilisé uniquement par vous : Ollama. Une concurrence de 1 correspond à la charge réelle.
• Vous comparez cinq modèles cette semaine : Ollama. Le téléchargement et la suppression de modèles marqués correspondent exactement à ses points forts, tandis qu’avec vLLM, chaque modèle nécessite de redémarrer le processus.
• Une application interne, un produit de chat ou un pipeline de recherche documentaire avec de vrais utilisateurs : vLLM. C’est dans ce cas que le batching justifie le coût du GPU.
• Un traitement par lots qui évalue cent mille documents pendant la nuit : vLLM, avec un --max-num-seqs élevé. Seul le débit 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 des agents est naturellement irrégulier et parallèle.

Modes d’échec, avec les chaînes que vous verrez

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

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 disponible après le chargement des poids. Réduisez-la avec --max-model-len 8192, ou augmentez --gpu-memory-utilization si rien d’autre n’utilise la carte. Dépasser environ 0.95 d’utilisation remplace généralement 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 pendant la génération. Le tueur de processus Linux pour manque de mémoire a arrêté le processus, car le modèle nécessitait plus de RAM que la machine n’en possède. Confirmez-le avec sudo dmesg | grep -i oom. La solution consiste à utiliser un modèle plus petit ou davantage quantifié, et non à 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 sérialise. Augmentez cette valeur 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 envoient comme clé la valeur que vous leur transmettez. Définissez donc cette valeur côté client au lieu de supprimer l’option.

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 dépôt avec lequel vous avez lancé le modèle, 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.

Utiliser 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 des modèles. Les deux endpoints sont compatibles avec l’API OpenAI. Une seule bibliothèque cliente et un changement de base URL suffisent donc pour passer de l’un à l’autre. La maîtrise des coûts est ici plus importante que le choix de l’un ou l’autre moteur, car un GPU inactif est facturé au même tarif qu’un GPU actif. De plus, maintenir des coûts prévisibles pour les agents et l’inférence est une discipline distincte du choix d’un serveur.

FAQ

vLLM est-il plus rapide qu’Ollama ?

Pour une seule requête sur le même GPU, l’écart est modeste, car les deux exécutent 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, mais vLLM ne fonctionne effectivement pas.

vLLM peut-il fonctionner sans GPU ?

Pas de manière utile. Les wheels standard ciblent les GPU NVIDIA ou AMD. La raison d’être de vLLM, maintenir un accélérateur saturé avec des requêtes groupées, disparaît sur un CPU. Un backend CPU existe pour le développement. Pour effectuer réellement de l’inférence 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 est basé 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 OpenAI. Ollama a ajouté son propre moteur pour certaines familles de modèles plus récentes. Les deux solutions ne sont donc plus identiques en interne.

De quelle 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. Le KV cache nécessite également de l’espace. Une carte de 24 GB convient. Une carte de 16 GB nécessite un checkpoint quantifié ou un modèle plus petit. vLLM revendique une fraction de la mémoire de la carte définie par --gpu-memory-utilization, qui vaut 0.92 par défaut 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é API et le nom du modèle. Ollama fournit son interface compatible avec OpenAI à l’adresse http://127.0.0.1:11434/v1 et ignore la clé, tandis que vLLM fournit http://localhost:8000/v1 et impose la clé si vous en définissez une. Les noms des modèles ont des formes différentes : llama3.1:8b pour Ollama et un identifiant complet de dépôt tel que Qwen/Qwen2.5-1.5B-Instruct pour vLLM.