vLLM ou Ollama : lequel pour servir un modèle ouvert ?

vLLM ou Ollama : Ollama pour un poste de développement, un prototype ou un petit service interne ; vLLM dès que plusieurs utilisateurs ou une application interrogent le modèle en même temps sur un serveur GPU. Les deux exposent une API compatible OpenAI, donc le passage de l'un à l'autre ne demande pas de réécrire l'application. Ce qui change, c'est le débit sous charge, le format des modèles, le matériel et ce qu'on peut superviser.

Quelle différence entre vLLM et Ollama ?

Ollama et vLLM font tous les deux tourner un modèle ouvert (Qwen, Llama, Mistral, Gemma) et l'exposent derrière une API. Ils ne sont pas faits pour la même charge. Ollama optimise la simplicité : une commande pour télécharger un modèle, un fonctionnement sur Windows, macOS ou Linux, avec ou sans GPU. vLLM optimise le débit : servir le plus de requêtes possible, en même temps, sur un ou plusieurs GPU.

La question à se poser n'est donc pas « lequel est le meilleur », mais « combien de requêtes simultanées, sur quel matériel, et qui va l'exploiter ». Si vous découvrez Ollama, notre article Ollama en entreprise couvre l'installation, le choix des modèles et la sécurité de base. Ici, on part du principe que le prototype tourne et qu'il faut décider comment le servir.

Plusieurs utilisateurs en même temps : où les deux se séparent

Le premier critère entre vLLM et Ollama, c'est le comportement quand plusieurs requêtes arrivent au même moment. Sur un seul utilisateur, les deux répondent à une vitesse comparable pour un même modèle et un même GPU. L'écart apparaît avec la charge.

Ce que fait Ollama

Selon la FAQ d'Ollama (consultée en novembre 2026), OLLAMA_NUM_PARALLEL fixe le nombre de requêtes traitées en parallèle par modèle, avec une valeur par défaut de 1. Les requêtes en trop attendent dans une file (512 au maximum par défaut, réglable avec OLLAMA_MAX_QUEUE).

On peut monter cette valeur, mais la mémoire suit. La même FAQ précise que le contexte est multiplié par le nombre de requêtes parallèles : 4 requêtes avec un contexte de 2 000 tokens occupent la mémoire d'un contexte de 8 000 tokens. Sur un GPU de 24 Go déjà bien rempli par le modèle, la marge part vite.

OLLAMA_NUM_PARALLEL=4 OLLAMA_HOST=0.0.0.0:11434 ollama serve

Pour cinq ou six collègues qui posent des questions de temps en temps, c'est souvent suffisant. Pour une application qui envoie des appels en rafale, ou un agent qui en enchaîne plusieurs par question, la file d'attente se remplit.

Ce que fait vLLM

vLLM repose sur deux mécanismes. Le continuous batching ajoute une nouvelle requête au lot en cours dès qu'une place se libère, au lieu d'attendre que tout le lot soit fini. PagedAttention découpe le cache de contexte (KV cache) en petits blocs alloués à la demande, comme la mémoire virtuelle d'un système d'exploitation, ce qui évite de réserver d'avance la fenêtre maximale pour chaque requête.

Le papier d'origine (Kwon et al., SOSP 2023) rapporte un débit 2 à 4 fois supérieur aux systèmes de référence de l'époque (FasterTransformer, Orca), à latence comparable. C'est un résultat mesuré sur leurs charges de test, pas une garantie pour la vôtre. Le détail de ces mécanismes, et des réglages de latence comme le speculative decoding, est dans notre article latence LLM : vLLM et speculative decoding.

Même API, formats de modèles différents

vLLM et Ollama exposent tous les deux une API compatible OpenAI : même route /v1/chat/completions, même format de requête et de réponse. Une application écrite avec le client OpenAI fonctionne sur l'un et sur l'autre en changeant l'adresse. Le format des poids du modèle, lui, n'est pas le même.

L'API : changer une adresse, pas le code

La documentation d'Ollama donne http://localhost:11434/v1/ comme adresse de base, avec une clé quelconque. vLLM sert la même API sur le port 8000, et accepte une vraie clé avec l'option --api-key :

vllm serve Qwen/Qwen2.5-14B-Instruct-AWQ \
  --served-model-name qwen2.5-14b \
  --max-model-len 16384 \
  --gpu-memory-utilization 0.90 \
  --api-key "$VLLM_API_KEY"

Côté application, seule la configuration bouge :

from openai import OpenAI

# Prototype sur Ollama
client = OpenAI(base_url="http://localhost:11434/v1/", api_key="ollama")

# Production sur vLLM
client = OpenAI(base_url="http://serveur-gpu:8000/v1", api_key=VLLM_API_KEY)

Attention au nom du modèle : Ollama l'appelle qwen2.5:14b, vLLM utilise le nom du dépôt Hugging Face. L'option --served-model-name permet d'exposer un nom stable, que l'application garde quel que soit le serveur.

La quantification : GGUF d'un côté, AWQ, GPTQ et FP8 de l'autre

Ollama s'appuie sur des fichiers GGUF, quantifiés en général en 4 bits (Q4_K_M) pour tenir sur du matériel modeste. vLLM charge les poids Hugging Face en 16 bits ou des versions quantifiées pour GPU : AWQ et GPTQ en 4 bits, FP8 sur les GPU récents (générations Ada et Hopper chez NVIDIA). La documentation de vLLM sur la quantification liste aussi GGUF, mais ce n'est pas le format sur lequel il est le plus optimisé.

Pour fixer les ordres de grandeur : un modèle de 14 milliards de paramètres pèse environ 28 Go en 16 bits et autour de 10 Go en 4 bits, auquel s'ajoute le cache de contexte, qui grossit avec le nombre de requêtes et la longueur des conversations. Notre guide de la quantification GGUF et int4 détaille les compromis qualité et mémoire.

Évaluer sur un format, livrer sur un autre

Un prototype validé sur Ollama en Q4_K_M, puis déployé sur vLLM en AWQ ou en FP8, ne tourne pas exactement avec le même modèle. Les réponses changent un peu, parfois sur les cas limites qui comptent le plus. Le jeu de questions de test qui a servi à valider le prototype doit être rejoué sur la configuration de production avant la mise en service.

GPU, installation et supervision : ce que chacun demande

Ollama demande peu : un installeur, éventuellement un GPU. vLLM demande un serveur GPU correctement configuré et quelqu'un pour le surveiller. Cet écart d'exploitation pèse souvent plus dans la décision que l'écart de débit.

Le serveur GPU

vLLM est fait pour le GPU : principalement NVIDIA, avec un support AMD et d'autres accélérateurs. Il faut aligner la version de vLLM, celle de CUDA et celle des pilotes, ce qui se règle bien avec l'image Docker officielle. Ollama, lui, tourne aussi sur CPU ou sur un Mac à mémoire unifiée, ce qui en fait le seul des deux utilisable sur un poste de développement sans carte dédiée.

Pour un modèle de taille moyenne (Qwen 2.5 14B, Mistral Small) quantifié, un GPU de 24 à 48 Go de mémoire suffit en général pour une équipe. Un modèle plus gros ou une charge plus forte demande plusieurs GPU, que vLLM sait répartir avec le parallélisme de tenseurs (--tensor-parallel-size).

La supervision

vLLM expose un endpoint /metrics au format Prometheus. La documentation des métriques de vLLM liste notamment vllm:num_requests_running, vllm:num_requests_waiting, vllm:time_to_first_token_seconds et vllm:kv_cache_usage_perc. Avec un tableau de bord Grafana, on voit la file d'attente monter avant que les utilisateurs ne s'en plaignent.

Ollama fournit surtout des logs. Pour un petit service, un contrôle de santé et une alerte sur le temps de réponse suffisent. Au-delà, il faut construire la supervision autour.

La sécurité

Ollama écoute par défaut sur 127.0.0.1, ce qui protège un poste isolé. Dès qu'on l'ouvre au réseau, il faut un proxy inverse avec authentification devant. vLLM accepte une clé d'API, mais ne gère ni comptes ni quotas par utilisateur : dans les deux cas, ces règles vivent dans l'application ou dans une passerelle placée devant le serveur.

Ce que nous avons appris en servant des modèles ouverts en production

Nous avons servi des modèles ouverts avec les deux outils, sur cloud français et sur serveurs internes. La leçon principale : le choix du serveur d'inférence règle le débit, pas la qualité des réponses. La qualité se mesure ailleurs.

Un RAG agentique pour un acteur du spatial, sur cloud français

Pour un acteur du spatial, entre janvier et mai 2025, nous avons construit un RAG agentique hébergé chez OVHcloud. Le modèle, Qwen 2.5 14B, était servi avec vLLM et avec Ollama. Autour : des agents spécialisés (résumer, filtrer, raisonner et agir sur le mode ReAct), une recherche hybride qui combine BM25 et recherche sémantique, la réécriture des requêtes, un reranking avec un modèle ouvert et un découpage des documents appuyé sur des modèles visuels.

La qualité était suivie avec Langfuse et une évaluation par LLM as a judge. Ce suivi se branche au niveau de l'application, pas du serveur d'inférence : il reste valable que le modèle tourne sur Ollama ou sur vLLM, et c'est lui qui dit si un changement de format ou de version dégrade les réponses. Notre article sur Langfuse et l'observabilité LLM détaille ce montage.

Des IA conversationnelles sur serveurs internes

Pour le même client, en 2024, nous avions livré deux IA conversationnelles, dont une pour les ressources humaines, sur ses serveurs internes, avec Llama 3.1. Les données ne sortaient pas du réseau de l'entreprise. Le travail a surtout porté sur la lecture de PDF complexes et sur le pipeline d'évaluation, pas sur l'installation du serveur d'inférence.

Quand garder Ollama, quand passer à vLLM, et où l'héberger

Gardez Ollama tant que la charge reste faible et que personne n'est d'astreinte sur le service. Passez à vLLM quand plusieurs utilisateurs ou une application interrogent le modèle en parallèle et que le temps de réponse compte. Entre les deux, un test de charge sur vos requêtes tranche.

Les autres options, en bref

• SGLang : alternative directe à vLLM, intéressante quand beaucoup de requêtes partagent un long préfixe commun (prompt système long, agents).
• TGI (Text Generation Inference) : pour les équipes déjà installées dans l'écosystème Hugging Face.
• llama.cpp : le moteur qui exécute les fichiers GGUF, sans la gestion de modèles d'Ollama ; utile sur CPU ou matériel modeste.

Le comparatif complet, avec LMDeploy et TensorRT-LLM, est dans notre panorama des serveurs d'inférence LLM open source.

Héberger en France : vos serveurs, OVHcloud ou Scaleway

Trois options reviennent. Vos propres serveurs, si vous avez déjà des GPU et une équipe pour les maintenir. Des instances GPU chez un hébergeur français comme OVHcloud ou Scaleway, sur lesquelles vous installez vLLM vous-même. Les API de modèles ouverts gérées par ces mêmes hébergeurs, quand le volume est faible ou qu'il n'y a personne pour exploiter un serveur. Les catalogues de GPU et de modèles évoluent vite : vérifiez ce qui est disponible au moment du choix.

Pour le choix du modèle lui-même, voyez quel modèle Mistral héberger en local et, côté OVHcloud, ce qu'on peut attendre du LLM d'OVHcloud. Si vous voulez qu'on construise le système complet (modèle servi par vLLM ou Ollama, recherche, évaluation, supervision) sur vos serveurs ou un cloud français, notre page IA souveraine décrit comment nous le livrons et le suivons en production.

Questions fréquentes sur vLLM et Ollama

Pour aller plus loin

• Pipeline RAG en production : les étapes de l'ingestion au suivi, et ce qui casse à chacune.
• Qdrant ou pgvector : choisir sa base vectorielle selon PostgreSQL, le volume et le multi-tenant.
• Ollama en entreprise : installation, choix des modèles et garde-fous de base.
• Latence LLM avec vLLM : continuous batching, PagedAttention et speculative decoding en détail.
• IA locale en entreprise : serveur sur site, cloud souverain ou poste local.
• Déployer un LLM en production : infrastructure, coûts et montée en charge.