QuelLLM.fr

Ollama vs vLLM : quel runtime LLM pour la production ?

Choisir entre Ollama vs vLLM revient à arbitrer entre simplicité de déploiement et débit brut sous charge concurrente. Ce duel structure aujourd'hui une grande partie des décisions d'infrastructure self-host autour des LLM open-weights, que ce soit pour servir un agent interne ou exposer une API multi-tenant. Nous comparerons ici les deux runtimes sous l'angle de l'architecture, du throughput mesurable sur GPU NVIDIA, de la gestion mémoire (KV cache, PagedAttention), des licences et formats supportés, des coûts opérationnels, puis nous terminerons sur des recommandations par taille de modèle et une FAQ technique. Notre objectif : permettre à un ingénieur plateforme de trancher en moins de quinze minutes de lecture.

Architecture et philosophie : deux runtimes, deux mondes

Ollama est un wrapper autour de llama.cpp, écrit en Go, qui expose une API HTTP simple et gère le téléchargement, le caching et le chargement dynamique des modèles GGUF. Sa cible historique : les machines de développeurs (Mac M-series, PC RTX desktop) et les déploiements single-tenant légers. Le runtime sous-jacent fait du CPU offloading transparent, ce qui permet de faire tourner un Qwen 2.5 72B Instruct (VRAM Q4 ~42 GB) sur une RTX 4090 24 GB avec un swap RAM système, au prix du throughput.

vLLM, publié par UC Berkeley, est un serveur Python optimisé pour le serving haute concurrence. Sa contribution clé est PagedAttention, qui gère le KV cache comme la mémoire virtuelle d'un OS : blocs de taille fixe, pagination, partage entre requêtes. Concrètement, là où un runtime naïf gaspille 60-80 % du KV cache en fragmentation, vLLM tombe sous les 4 %. Le résultat est un débit agrégé 2x à 24x supérieur selon la charge, mais avec un coût d'entrée : pas de quantification GGUF native, dépendance CUDA stricte, modèle entier en VRAM.

Pour creuser la différence d'approche entre llama.cpp et vLLM côté serving, consultez notre guide complet llama.cpp vs vLLM.

Throughput et latence : ce que disent les chiffres

Les mesures publiques convergent sur un point : sous charge concurrente, vLLM domine largement. Sur un Llama 3.3 70B Instruct (70B, ctx 128 000) servi en FP8 sur 4× A100 80 GB, on observe typiquement (à confirmer selon batch size) :

L'écart se creuse encore sur les modèles MoE comme Mixtral 8x22B Instruct (141B, Apache 2.0, ctx 64K) où vLLM exploite le tensor parallelism multi-GPU avec une efficacité que llama.cpp peine à atteindre. Pour les très gros MoE comme DeepSeek V3 671B ou Qwen 3 235B-A22B, vLLM reste le seul choix réaliste en production multi-utilisateur, notamment grâce au support natif du expert parallelism.

En revanche, pour une charge single-stream avec quantification agressive (Q4_K_M, Q5_K_M), Ollama tient la comparaison sur la latence du premier token (TTFT), parfois meilleure sur des modèles 7B-13B grâce à la légèreté du runtime. Pour un benchmark détaillé sur GPU consumer, voir notre comparatif RTX 4090 vs RTX 5090 pour LLM.

Quantification, formats et VRAM réelle

C'est ici que les deux runtimes divergent radicalement. Ollama consomme exclusivement du GGUF (Q2_K à Q8_0, plus FP16). Cette flexibilité permet de loger un Llama 3.1 70B (~40 GB en Q4) sur une seule RTX A6000 48 GB. vLLM accepte les poids HuggingFace natifs (FP16, BF16) et supporte désormais AWQ, GPTQ et FP8, mais pas GGUF en production stable.

Quelques repères VRAM Q4 du catalogue quelllm.fr :

Pour les déploiements modestes, gpt-oss 120B et Mistral Small 4 offrent un compromis raisonné : taille gérable, licence permissive, support des deux runtimes. Voir notre fiche Mistral Small 4 pour les benchmarks détaillés.

Licences et conformité

Le choix du runtime n'a pas d'incidence licence — c'est le modèle qui dicte les conditions. Quelques cas typiques en production européenne :

Pour un panorama complet, voir notre guide des licences LLM open-source et le suivi communautaire sur HuggingFace Models.

Cas d'usage : qui choisir pour quoi ?

Choisissez Ollama si : - Vous déployez un assistant interne sur un poste développeur ou une station GPU unique - Vous voulez itérer rapidement sur plusieurs modèles (changement à chaud via API) - Votre charge est < 5 utilisateurs concurrents - Vous ciblez une RTX 3090/4090/5090 ou un Mac Studio M3 Ultra - Vous voulez tester dots.llm1 Instruct (142B, MIT, Rednote) ou Hunyuan-A13B Instruct sans configurer un cluster

Choisissez vLLM si : - Vous servez une API derrière un load balancer avec > 20 requêtes/sec - Vous opérez du tensor parallelism sur 2, 4 ou 8 GPU - Vous voulez exploiter PagedAttention, speculative decoding et continuous batching - Vous ciblez des modèles MoE massifs : DeepSeek V3.2 (685B), Mistral Large 3 675B, Llama 3.1 405B Instruct, Ring-1T (1000B) - Vous avez besoin de Llama 4 Scout 109B avec son contexte 10M tokens en serving multi-tenant

Un troisième choix mérite mention : Text Generation Inference de HuggingFace, intermédiaire entre les deux, supporté nativement pour Mistral Medium 3.5 128B et la famille Llama. Pour orchestrer un cluster vLLM, Ray Serve reste la référence.

Pour des recommandations par budget GPU, consultez notre guide configurateur et la page meilleur LLM pour serveur GPU.

Coûts opérationnels et observabilité

Ollama gagne en simplicité opérationnelle : binaire unique, télémétrie minimale, mise à jour modèle en une commande. Le coût caché est l'absence de métriques fines (pas de Prometheus natif sur les versions stables récentes, à confirmer). vLLM expose nativement un endpoint Prometheus avec time-to-first-token, débit par requête, utilisation KV cache, et s'intègre directement à Grafana.

Côté coût GPU, un cluster vLLM bien tuné réduit le coût par million de tokens d'un facteur 3 à 8 par rapport à un déploiement Ollama équivalent en multi-instance — la différence vient du batching continu et de la quasi-absence de fragmentation KV. Sur Qwen3-Coder-Next 80B-A3B (MoE, Apache 2.0), nos lecteurs rapportent (à confirmer) ~14 000 tokens/sec agrégés sur 2× H100 en vLLM, contre ~80 tokens/sec single-stream sur Ollama avec un RTX 6000 Ada.

Pour aller plus loin sur le tuning, voir le vLLM blog officiel et notre comparaison vLLM vs TGI.

FAQ

Q : Ollama peut-il servir plusieurs utilisateurs simultanés en production ?

Techniquement oui, mais avec des limites. Ollama gère plusieurs requêtes via une file d'attente interne, sans batching continu efficace. Au-delà de 3-5 utilisateurs concurrents sur un modèle 70B comme Llama 3.3 70B Instruct, la latence p95 dégrade fortement. Pour de la production multi-tenant sérieuse, vLLM ou TGI restent les choix techniquement justifiés.

Q : vLLM supporte-t-il les quantifications agressives type Q4 GGUF ?

Pas en GGUF natif. vLLM privilégie FP8, AWQ et GPTQ, qui offrent un compromis qualité/VRAM différent. Sur DeepSeek R1 671B, une version AWQ 4-bit officielle existe sur HuggingFace et tourne en vLLM. Pour du GGUF Q4_K_M strict, restez sur Ollama ou llama.cpp directement — c'est leur terrain.

Q : Quel runtime pour un MoE comme Qwen 3 235B-A22B ?

vLLM, sans hésitation. Les MoE bénéficient massivement du expert parallelism et du continuous batching que vLLM implémente nativement. Qwen 3 235B-A22B (Apache 2.0, ctx 131K) atteint un débit agrégé que Ollama ne peut pas approcher, même sur un cluster 8× H100. Voir notre fiche Qwen 3 235B-A22B.

Q : Peut-on utiliser Ollama sur un cluster Kubernetes ?

Oui, des charts Helm communautaires existent, mais Ollama n'a pas été conçu pour le scaling horizontal stateless. Chaque pod recharge ses modèles, le cache GGUF n'est pas partagé. Pour du Kubernetes natif, vLLM s'intègre mieux via KServe et son opérateur dédié.

Q : Quel runtime choisir pour Llama 4 Scout 109B et son contexte 10M ?

vLLM avec attention sparse activée. Le contexte 10M de Llama 4 Scout 109B exige une gestion KV cache que seul PagedAttention rend économiquement viable. Ollama techniquement peut charger le modèle, mais le KV cache à 10M tokens fait exploser la VRAM sans pagination. À réserver à vLLM ou TGI.

Q : Existe-t-il une alternative aux deux pour les Mac Apple Silicon ?

Oui : MLX d'Apple est optimisé pour Metal et surpasse Ollama sur M3 Ultra pour des modèles comme DeepSeek R1 Distill Llama 70B. Mais le serving multi-utilisateur Mac reste niche. Voir notre guide LLM sur Mac M3 Ultra.

Conclusion

Le débat Ollama vs vLLM se tranche par la charge cible : Ollama pour le prototypage, le single-user et les Mac ; vLLM dès qu'on parle d'API multi-tenant, de MoE massifs ou de tensor parallelism. Pour identifier le couple modèle/runtime adapté à votre VRAM et votre licence cible, lancez notre configurateur ou parcourez les 249 modèles indexés sur le catalogue quelllm.fr.

Article publié le par Mohamed Meguedmi · Source de données : /api/models.json · Licence contenu : CC BY 4.0.

Une erreur ou une mise à jour à signaler ? Contribuer.