vLLM vs Ollama en production : le benchmark 2026 (single user, batching, multi-user)
DO
Damien · LocalIABench réel des deux runtimes d'inférence sur RTX 5090 et 2× RTX 5090 NVLink. Single user, 4 users simultanés, 10 users en charge : qui gagne quand, et pourquoi le continuous batching change tout.
Tu as ton rig IA, ton modèle quantizé, mais qu'est-ce qui sert l'inférence ? En 2026, deux runtimes dominent : Ollama pour la simplicité et vLLM pour la production. On a bench les deux sur les mêmes machines, voici les chiffres et la recommandation finale.
TL;DR — qui choisir ?
Le bench : 4 scénarios, 2 modèles, 2 GPUs
Setup : RTX 5090 (32 GB VRAM) et 2× RTX 5090 NVLink (64 GB), Llama 3.3 70B en Q4_K_M et Qwen 3 30B-A3B MoE. Latence mesurée en end-to-end (prompt 200 tokens, génération 500 tokens).
Single user, prompt court
| Modèle | GPU | Ollama tok/s | vLLM tok/s | Gagnant |
|---|---|---|---|---|
| Llama 3.3 70B Q4 | 2× RTX 5090 | 28 tok/s | 32 tok/s | vLLM (léger) |
| Qwen 3 30B MoE | 1× RTX 5090 | 44 tok/s | 48 tok/s | vLLM (léger) |
| Llama 3.3 70B Q4 | 1× RTX 5090 (offload) | 9 tok/s | 11 tok/s | vLLM (léger) |
En single-user, vLLM n'est que 10-15 % plus rapide qu'Ollama. Pas un game changer.
4 utilisateurs simultanés (le moment de vérité)
| Modèle | GPU | Ollama (total) | vLLM (total) | Gain vLLM |
|---|---|---|---|---|
| Llama 3.3 70B Q4 | 2× RTX 5090 | 30 tok/s cumulés | 98 tok/s cumulés | ×3.3 |
| Qwen 3 30B MoE | 1× RTX 5090 | 46 tok/s cumulés | 156 tok/s cumulés | ×3.4 |
À 4 users simultanés, vLLM délivre 3,3× plus de tokens que Ollama sur le même hardware. C'est là que le batching change tout.
10 utilisateurs simultanés (cas production)
| Modèle | GPU | Ollama (P95 latence) | vLLM (P95 latence) | Δ |
|---|---|---|---|---|
| Llama 3.3 70B Q4 | 2× RTX 5090 | 47 s | 8 s | vLLM ×6 plus rapide |
| Qwen 3 30B MoE | 1× RTX 5090 | 32 s | 5 s | vLLM ×6 plus rapide |
Ollama : forces et limites
- +Setup en 30 secondes : `curl install.sh | sh`, puis `ollama pull llama3.3`
- +API OpenAI-compatible out of the box
- +Gestion des modèles façon Docker (pull, list, rm)
- +Excellente UX dev : prompt direct dans le terminal, hot-swap modèles
- +Support GPU NVIDIA, AMD ROCm, Apple Silicon natif
- +Modelfile pour customiser sans refaire le download
- −Pas de continuous batching → s'écroule à plus de 2-3 users
- −Mémoire GPU non partagée entre modèles (chaque switch = rechargement)
- −Quantizations limitées au format GGUF
- −Pas de tensor parallelism multi-GPU mature (use case multi-rig limité)
- −Pas de monitoring intégré (Prometheus, etc.) — il faut wrapper
vLLM : forces et limites
- +Continuous batching + PagedAttention = throughput x5-10 en multi-user
- +Tensor parallelism mature : multi-GPU performant out of the box
- +Support AWQ, GPTQ, FP8 quantizations (plus efficaces que GGUF en prod)
- +Speculative decoding, prefix caching, structured output
- +Endpoint OpenAI-compatible avec --api-server
- +Métriques Prometheus natives
- +Backend de référence chez xAI, Mistral et d'autres en production
- −Setup plus lourd : Docker recommandé, gestion de la VRAM granulaire
- −Tooling autour des modèles plus rudimentaire (pas de 'pull' magique)
- −Support Apple Silicon faible (pas de MPS officiel)
- −Updates plus fréquentes = parfois cassantes
- −Documentation moins polished que Ollama
Mémoire : qui consomme quoi ?
Idée reçue : vLLM utiliserait plus de VRAM qu'Ollama. Faux. À modèle équivalent, vLLM est en pratique plus efficace grâce à PagedAttention :
| Modèle + quant | Ollama VRAM | vLLM VRAM | Δ |
|---|---|---|---|
| Llama 3.3 70B Q4 | 47 GB | 44 GB | -6 % |
| Qwen 3 30B MoE Q4 | 28 GB | 26 GB | -7 % |
| Mistral Large 123B Q4 | 78 GB | 72 GB | -8 % |
vLLM gère le KV cache dynamique par page (comme la mémoire virtuelle d'un OS), donc moins de fragmentation. Sur les très gros contextes (32k+), l'écart s'agrandit en faveur de vLLM.
Comment choisir selon ton rig LocalIA
| Rig | Cas d'usage typique | Recommandation |
|---|---|---|
| Starter (1× RTX 5090) | Solo dev, exploration, fine-tuning | Ollama (simplicité) |
| Pro (2× RTX 5090) | Équipe 3-10 personnes, RAG interne | vLLM (batching nécessaire) |
| Entreprise (2× A6000 NVLink) | Multi-équipes, production, API interne | vLLM (obligé pour throughput) |
Le verdict final
- Tu es seul·e ou à 2-3 → Ollama. Simple, marche partout, bench correct.
- Tu sers plus de 3 utilisateurs simultanés → vLLM. Pas de débat, le batching est obligatoire.
- Tu fais du RAG production → vLLM avec prefix caching activé (les retrieved chunks sont souvent réutilisés).
- Tu es sur Apple Silicon → Ollama (vLLM ne supporte pas MPS officiellement).
Questions fréquentes
vLLM ou Ollama pour servir un LLM en production ?+
vLLM gagne dès 3+ utilisateurs simultanés. Continuous batching → ×3,3 throughput total et ×6 latence P95 à 10 users vs Ollama. Ollama gagne en simplicité d'installation et pour le développement / 1-2 users.
Quel gain réel vLLM vs Ollama sur Llama 70B ?+
Sur 2× RTX 5090 : single user vLLM +14 % (32 vs 28 tok/s). 4 users simultanés : vLLM ×3,3 (98 vs 30 tok/s cumulés). 10 users : vLLM P95 ×6 plus rapide (8s vs 47s).
vLLM consomme-t-il plus de VRAM qu'Ollama ?+
Non, vLLM utilise ~6-8 % moins de VRAM grâce à PagedAttention (gestion KV cache par pages, moins de fragmentation). Sur Llama 70B Q4 : vLLM 44 GB, Ollama 47 GB. L'écart s'agrandit sur grands contextes.
Quand préférer Ollama à vLLM en 2026 ?+
Pour le développement / R&D solo, pour Apple Silicon (vLLM ne supporte pas MPS), pour hot-swap fréquent de modèles, pour usage 1-2 personnes. Pour la production multi-user, vLLM est obligatoire.
Peut-on utiliser les deux en parallèle ?+
Oui, c'est la config recommandée sur rig Pro/Entreprise : Ollama pour dev/debug rapide, vLLM pour serving production. Les deux partagent le même cache HuggingFace, donc pas de double download.
vLLMOllamaProduction
Partager