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 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. La plupart des 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 le disque au lieu de 16 GB. La quantification réduit la mémoire nécessaire à l’inférence sur CPU. Sur les Mac équipés d’Apple Silicon, Ollama peut également exécuter des modèles basés sur safetensors avec un moteur MLX. Depuis la version v0.40.0 (September 2026), les architectures prises en charge s’exécutent automatiquement avec MLX.

Son exécuteur GGUF repose sur llama.cpp, la bibliothèque d’inférence en C++ qui a rendu la quantification GGUF pratique sur du matériel standard. En October 2026, Ollama prend en charge deux moteurs : llama.cpp et MLX. Les builds Linux prennent également en charge l’inférence MLX avec CUDA. Le guide de développement active ce backend avec cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13, avec CUDA 13+ et cuDNN 9+ comme prérequis. Ainsi, lorsque l’on compare Ollama à llama.cpp, on compare surtout une couche d’ergonomie avec le composant qu’elle encapsule.

La conception cible un seul utilisateur. En October 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 limitée par défaut à 512 entrées (OLLAMA_MAX_QUEUE). Vous pouvez augmenter le paramètre de parallélisme. La section ci-dessous explique le coût de ce changement. Si vous n’avez encore jamais exécuté Ollama, commencez par héberger Ollama sur un VPS et laisser le port 11434 fermé, car l’API locale ne demande aucune 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, il fournit un client vllm chat pour un serveur en cours d’exécution et il 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, puis le sert jusqu’à l’arrêt du processus.

Cette spécialisation permet surtout d’obtenir un débit élevé. Deux mécanismes l’assurent. PagedAttention stocke le KV cache (cache clé-valeur, c’est-à-dire l’état d’attention par token conservé par le modèle pour chaque requête active) dans des blocs de taille fixe, comme le fait un système d’exploitation pour paginer la mémoire. Une requête n’a plus besoin de réserver une grande zone 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. 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 beaucoup moins que prévu. Avec la configuration par défaut d’Ollama, passer d’un utilisateur à trente revient simplement à faire attendre vingt-neuf personnes.

Le continuous batching change tout

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 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 est à peu près celui 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 forward pass. Générer un token pour cinq séquences coûte à peine plus cher que d’en générer un 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 entre tout le batch. C’est le même problème 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 obtenir une partie de ce comportement. Le coût est la mémoire. Chaque slot parallèle a besoin de son propre KV cache, et Ollama multiplie l’allocation du contexte au lieu de la diviser : sa FAQ indique que la RAM nécessaire est multipliée par OLLAMA_NUM_PARALLEL fois OLLAMA_CONTEXT_LENGTH. Ainsi, quatre requêtes parallèles vers un modèle configuré pour 8192 tokens conservent chacune 8192 tokens, mais le serveur doit stocker au total le cache de 32768 tokens. 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 peuvent tenir en mémoire. Le cache paginé de vLLM évite de réserver d’emblée toute la fenêtre pour chaque slot, car les blocs sont alloués à une requête au fur et à mesure qu’elle grandit. Dans tous les cas, le nombre maximal d’utilisateurs qu’un seul 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 confortable 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 le nombre réel de tokens par seconde sur cette machine. Fiez-vous à cette valeur plutôt qu’aux chiffres publiés. Une mesure obtenue avec un seul prompt constitue un point de départ, pas une mesure de capacité. Mesurer le nombre de tokens par seconde selon plusieurs niveaux de concurrence permet de vérifier si la machine supporte la charge réellement prévue 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 donne la valeur réelle. 100% CPU signifie qu’aucun GPU n’est utilisé. C’est l’explication exacte de la plupart des cas où Ollama est lent. La ligne OLLAMA_KEEP_ALIVE=30m de ce drop-in est tout aussi importante sur une machine peu sollicitée. Par défaut, le modèle est déchargé après cinq minutes sans requête. Garder le modèle chargé entre les requêtes évite que le premier prompt après une période d’inactivité pouvant durer jusqu’à une demi-heure doive à nouveau payer tout le temps de chargement. Si vos périodes d’inactivité sont plus longues, définissez une valeur supérieure.

Installer et servir avec vLLM

Les builds GPU de vLLM nécessitent Linux (macOS sur Apple Silicon prend en charge uniquement le CPU avec une wheel précompilée dans la version 0.32.0, et l’accélération GPU sur ces Mac est fournie par vLLM-Metal, un plugin communautaire distinct basé sur MLX). Pour Python, la version actuelle (0.32.0, octobre 2026) accepte les versions 3.11 à 3.14, et le guide d’installation indique la même plage. Python 3.10 a été abandonné dans la version 0.32.0. La version 3.12 utilisée ci-dessous est donc le choix le plus sûr. Installez vLLM 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
vllm download-kernels

La dernière ligne figure dans le guide d’installation NVIDIA de vLLM en octobre 2026. Elle installe les kernels précompilés de FlashInfer. Sans ces kernels, vLLM les télécharge et les compile au démarrage. D’après le guide, cela peut ajouter plusieurs minutes sur les GPU Hopper et les modèles plus récents. Exécutez à nouveau cette commande après chaque mise à niveau de vLLM, car FlashInfer refuse de s’importer lorsque les kernels ne correspondent pas.

Servez ensuite un modèle. Le nom est un repository id de Hugging Face, et non un tag court :

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

Le premier démarrage est lent, car vLLM télécharge les poids, puis profile le GPU pour déterminer combien de blocs de cache KV peuvent y tenir. Le service é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 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 donne au conteneur accès à la mémoire partagée de l’hôte ; augmenter --shm-size est une autre option. PyTorch transmet les tenseurs entre les processus via la mémoire partagée, en particulier 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 financer), --gpu-memory-utilization (la fraction de la mémoire de la carte que vLLM peut utiliser, 0.92 par défaut en octobre 2026), --tensor-parallel-size pour répartir un modèle sur plusieurs GPU, et --api-key.

L’authentification repose sur un seul flag dans vLLM et est absente de l’API locale 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 vers la route /v1 sans ce token reçoit une réponse HTTP 401. Toutefois, cette clé ne protège pas l’ensemble du serveur. Le guide de sécurité de vLLM et le code d’authentification de la source 0.32.0 l’appliquent uniquement aux endpoints correspondant aux préfixes de chemin /v1, /v2, /inference et /cohere. Le texte d’aide --api-key de la page vllm serve n’en liste que les trois premiers, mais le code vérifie les quatre. Le guide et le texte d’aide indiquent tous deux que les autres endpoints, notamment /invocations, qui expose la même inférence que /v1, ne sont pas authentifiés. Cela suffit pour ne pas publier le port 8000 sur une interface publique. Le guide de sécurité de vLLM confie également la limitation de débit à un reverse proxy placé devant le serveur. De plus, un token envoyé sur HTTP en clair peut être lu pendant son transit. Le flag signifie néanmoins que le serveur gère l’identité de l’appelant.

L’API locale d’Ollama ne requiert aucune authentification. Les modèles cloud, la publication de modèles et le téléchargement de modèles privés nécessitent une connexion. L’accès direct à l’API d’ollama.com nécessite une clé API. Tout processus pouvant atteindre le port 11434 peut exécuter, télécharger ou supprimer des modèles. Laissez ce port lié à loopback 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é 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 demande donc environ 4 GB libres, et un modèle 8B environ 8 GB. Sur un vCPU partagé, le débit est de quelques tokens à une dizaine de tokens par seconde. Cela vient de la bande passante mémoire, et non d’une mauvaise configuration. Aucun flag ne peut corriger ce problème. Pour observer ces calculs 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 RAM occupée une fois le modèle chargé et si un fonctionnement uniquement sur CPU est suffisamment rapide au quotidien.

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 donc environ 16 GB de mémoire vidéo pour ses seuls poids, avant de compter le cache KV qui fournit la concurrence pour laquelle vous avez installé vLLM. Avec une carte de 24 GB, il reste une capacité de cache exploitable. Avec une carte de 16 GB, ce n’est pas le cas. Vous devez alors choisir un modèle plus petit, utiliser --quantization (avec un checkpoint quantifié ou pour quantifier les poids en pleine précision au chargement), ou déplacer une partie des poids dans la RAM système avec --cpu-offload-gb. Leur précision reste inchangée, mais les performances diminuent, car ces poids sont transférés vers le GPU à chaque passe forward. Il existe un backend CPU, avec ses propres wheels, mais il supprime l’intérêt même d’utiliser vLLM.

La question du matériel permet donc généralement de répondre à celle du logiciel. Sans GPU, utilisez Ollama. Un GPU loué qui reste à 5 % d’utilisation parce que les requêtes sont traitées en série indique qu’il faut utiliser 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 d’échec et messages affichés

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

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

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.

Ollama affiche Killed pendant la génération. Le Linux out-of-memory killer a arrêté le processus, car le modèle nécessitait plus de RAM que la machine n’en dispose. 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 traite en série. Les réponses longues aggravent la file d’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 permet donc de plafonner la durée pendant laquelle un tour peut monopoliser le serveur. Augmentez le paramètre de parallélisme et acceptez la RAM supplémentaire consommée par le contexte de chaque slot, ou migrez la charge vers vLLM.

vLLM renvoie 401 pour chaque appel /v1. 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 comme clé la valeur que vous leur transmettez. Définissez-la donc côté client 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 dépôt avec lequel vous avez lancé le serveur, 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 reste 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, les deux disposent de modes d’inférence pris en charge, vLLM utilisant des wheels CPU distinctes.

vLLM peut-il fonctionner sans GPU ?

Oui, avec son backend CPU. Les wheels standard ciblent les GPU NVIDIA ou AMD, et la raison d’être de vLLM — maintenir un accélérateur au maximum de ses capacités avec des requêtes regroupées — disparaît sur un CPU. Un backend CPU existe, avec des wheels distinctes pour x86 et Arm. Pour une véritable 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. Ollama l’utilise pour l’inférence GGUF et ajoute un registre de modèles, des téléchargements avec tags, la gestion des modèles et une unité systemd. Ollama fournit également un moteur MLX qui exécute des modèles basés sur safetensors sur Apple Silicon et prend en charge les builds CUDA sous Linux. Les deux solutions ne reposent donc pas toujours sur les mêmes composants.

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. La KV cache nécessite également de l’espace. Une carte de 24 GB offre une marge confortable. Avec une carte de 16 GB, vous devez utiliser un modèle quantifié, un modèle plus petit ou --cpu-offload-gb pour déplacer une partie des poids vers la RAM système, au prix d’une baisse des performances. vLLM utilise la fraction de la mémoire de la carte définie par --gpu-memory-utilization, qui vaut par défaut 0.92 en octobre 2026.

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

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