vLLM vs Ollama en production : le benchmark 2026 (single user, batching, multi-user)
Bench 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).