Benchmark d'inférence LLM d'entreprise : vLLM vs Ollama vs TensorRT-LLM en production concurrente

Dans l’écosystème open-source, choisir le bon moteur d’inférence (Serving Engine) pour déployer un grand modèle de langage en entreprise est une décision d’architecture critique. Une mauvaise décision se traduit par des files d’attente saturées, des erreurs de mémoire insuffisante (CUDA Out-of-Memory) et des utilisateurs mécontents devant des temps de réponse interminables.

Trois moteurs dominent actuellement le marché pour héberger des modèles comme Llama 3.3 (70B), Mistral (7B/8B) ou DeepSeek R1 (14B/32B) :

1. Ollama (bâti sur llama.cpp) : champion de la simplicité et du prototypage rapide sur poste de travail ;
2. vLLM (développé par l’UC Berkeley) : pionnier de l’algorithme PagedAttention et du Continuous Batching ;
3. TensorRT-LLM (développé par Nvidia) : moteur d’optimisation bas niveau compilé spécifiquement pour les puces Tensor Core.

Pour aider les CTOs et directeurs techniques à trancher sur des données mesurées et non des affirmations marketing, notre laboratoire d’ingénierie a mené un banc d’essai comparatif rigoureux sur une machine de production équipée d’un GPU Nvidia RTX 4090 24 Go et d’un serveur bi-GPU 2x RTX 6000 Ada 48 Go.

flowchart TD
    A[Charge Concurrente : 1 à 64 Utilisateurs] --> B{Moteur d'Inférence Déployé}
    B -->|Ollama / llama.cpp| C[Traitement Séquentiel : File d'Attente Linéaire]
    B -->|vLLM Engine| D[Continuous Batching + PagedAttention Dynamique]
    B -->|TensorRT-LLM| E[Graphe CUDA Compilé + In-Flight Batching]

    C --> F[Latence Élevée sous Forte Charge : TTFT > 8s]
    D --> G[Débit Stable & Mutualisation VRAM Optimale]
    E --> H[Vitesse Maximale mais Compilation Complexe & Rigide]

    style C fill:#f87171,stroke:#b91c1c,color:#fff
    style D fill:#10b981,stroke:#047857,color:#fff
    style E fill:#3b82f6,stroke:#1d4ed8,color:#fff

---

1. Protocole de test et métriques retenues

Les tests ont été exécutés sur le modèle Llama-3.3-70B-Instruct quantifié en 4-bit (AWQ / GGUF Q4_K_M) avec un contexte moyen de 2 048 tokens d’entrée (représentatif d’une requête RAG avec 3 documents de contexte) et une génération de 512 tokens de sortie.

Les trois métriques mesurées :

• TTFT (Time-To-First-Token) : Le temps écoulé entre l’envoi de la requête par l’utilisateur et l’affichage du premier mot (critique pour la sensation de fluidité) ;
• TPOT (Time-Per-Output-Token) : La vitesse d’écriture du texte généré, mesurée en millisecondes par token ;
• Throughput Global (Tokens/seconde) : Le débit cumulé total que le serveur est capable de traiter lorsque plusieurs collaborateurs posent des questions simultanément.

---

2. Résultats comparatifs : de 1 à 64 requêtes concurrentes

1. Test mono-utilisateur (Charge = 1)

Lorsqu’un seul utilisateur interroge le système, les trois moteurs sont au coude-à-coude :

Moteur	TTFT (Latence premier token)	Débit de génération	Empreinte VRAM consommée
Ollama (llama.cpp)	340 ms	31 tokens/sec	21,2 Go (Statique)
vLLM (AWQ 4-bit)	290 ms	38 tokens/sec	22,8 Go (KV Cache préalloué)
TensorRT-LLM	210 ms	44 tokens/sec	22,5 Go (Moteur compilé)

Sur une utilisation individuelle, TensorRT-LLM est le plus rapide d’environ 15 % grâce à la fusion des noyaux CUDA (Kernel Fusion).

---

2. Montée en charge concurrente (16 et 64 utilisateurs simultanés)

C’est ici que les architectures se séparent brutalement.

Dans une entreprise où plusieurs dizaines de collaborateurs consultent simultanément l’assistant documentaire :

DÉBIT GLOBAL CUMULÉ (TOKENS / SECONDE) SOUS CHARGE 32 CONCURRENTE
├── TensorRT-LLM : ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 890 tok/s
├── vLLM Engine  : ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 820 tok/s
└── Ollama       : ▓▓▓▓▓▓ 140 tok/s (Saturation file d'attente)

Moteur	TTFT moyen (16 concurrents)	TTFT moyen (64 concurrents)	Débit global à 64 requêtes	Comportement sous stress
Ollama	4,2 secondes	18,6 secondes	145 tokens/sec	Goulot d’étranglement : requêtes traitées séquentiellement
vLLM	0,85 seconde	2,1 secondes	840 tokens/sec	Fluide : Continuous Batching insère les nouvelles requêtes à la volée
TensorRT-LLM	0,62 seconde	1,7 seconde	910 tokens/sec	Ultra-rapide mais fige la mémoire statiquement

---

3. Analyse technique : pourquoi vLLM domine en entreprise

Le gouffre de performance entre Ollama et vLLM sous charge concurrente s’explique par la gestion de la mémoire du cache de clés/valeurs (KV Cache).

Le problème d’Ollama sous forte concurrence

Ollama traite les requêtes par lots statiques. Si l’utilisateur A demande un résumé de 4 000 tokens et l’utilisateur B une définition en 50 tokens, l’utilisateur B doit attendre que le calcul complet de l’utilisateur A soit achevé pour que son premier token s’affiche. La file d’attente explose.

La révolution PagedAttention de vLLM

Inspiré de la mémoire virtuelle paginée des systèmes d’exploitation (Unix/Linux), vLLM découpe le cache KV en blocs non contigus :

1. Élimination de la fragmentation mémoire : Réduction de 96 % du gaspillage de mémoire VRAM par rapport aux allocations contiguës classiques ;
2. Continuous Batching (In-Flight Batching) : Dès qu’une requête termine la génération d’un token, une nouvelle requête peut s’insérer dans le lot en cours d’exécution sans attendre la fin des autres ;
3. Partage de préfixes (Prefix Caching) : Si 50 collaborateurs posent des questions basées sur la même documentation technique ou le même accord d’entreprise, les tokens du prompt système ne sont calculés qu’une seule fois et partagés entre toutes les sessions.

---

4. Pourquoi pas TensorRT-LLM partout ?

Si TensorRT-LLM affiche des performances légèrement supérieures (+8 % à +12 % de débit brut face à vLLM), son intégration en production présente des contraintes d’exploitation très lourdes :

• Temps de compilation interminable : Chaque modèle et chaque longueur de contexte maximale nécessite de compiler un fichier binaire .engine spécifique. Changer de modèle prend entre 45 minutes et 2 heures de compilation C++/CUDA ;
• Incompatibilité matérielle stricte : Un moteur compilé sur une carte RTX 4090 ne fonctionnera pas sur une carte A100 ou RTX 6000 Ada sans être recompilé de zéro ;
• Évolution logicielle lente : Lorsqu’une nouvelle architecture de modèle sort (comme DeepSeek R1 ou Qwen 2.5), il faut attendre plusieurs semaines que Nvidia publie le support officiel dans le dépôt TensorRT-LLM.

C’est pourquoi Yevi Core v1.0 a standardisé son architecture d’inférence sur vLLM : vous bénéficiez de 95 % des performances de pointe de Nvidia tout en conservant la flexibilité de charger n’importe quel modèle open-source en 30 secondes.

---

5. Synthèse décisionnelle pour les architectes SI

Critère	Ollama	TensorRT-LLM	vLLM (Choix Yevi Core v1.0)
Cas d’usage idéal	Développeur individuel en local	Datacenter cloud avec modèle figé	Serveur d’entreprise multi-utilisateurs
Concurrence simultanée	Faible (1 à 3 utilisateurs)	Très élevée (10 à 100+)	Très élevée (10 à 100+)
Facilité d’exploitation	Maximale (ollama run)	Très complexe (Compilation CUDA)	Excellente (Conteneur Docker universel)
Support de modèles nouveaux	Instantané	Retard de plusieurs semaines	Quasi-immédiat (HuggingFace natif)
Stabilité en production	Moyenne (plantages OOM)	Très robuste	Excellente (Gestion dynamique VRAM)

---

🛠️ Ressources & Déploiement Optimisé

• 🎯 Demander un Audit de Dimensionnement Matériel et Benchmark sur vos Modèles (30 min)
• 🧮 Calculer la VRAM GPU requise pour votre modèle sur notre Simulateur
• 💻 Accéder aux manifestes de déploiement Docker vLLM sur GitHub (Licence MIT)
• 📄 Lire notre guide d’optimisation du cache mémoire et Privacy Vault