Comprendre les métriques de performance en production : au-delà des leaderboards

La première erreur que je corrige lors de mes audits d'infrastructure IA consiste à confondre deux familles de benchmarks totalement disjointes. Les quality benchmarks — MMLU, GSM8K, HellaSwag, ARC — mesurent l'intelligence d'un modèle : sa capacité à résoudre un problème de mathématiques de niveau collège, à raisonner par bon sens ou à répondre à une question scientifique. Comme le détaille la documentation IBM sur les LLM benchmarks, ces tests produisent un score entre 0 et 100 selon des métriques comme l'accuracy, le F1 score ou le BLEU. Ils vous disent quel modèle choisir, jamais comment le servir.

Les performance benchmarks répondent à une autre question : combien d'utilisateurs votre infrastructure absorbe-t-elle avant de s'effondrer ? Ici, les KPI changent radicalement.

Les quatre métriques que tout DSI doit connaître

  • Throughput (RPS et TPS) : le nombre de requêtes par seconde et le nombre total de tokens générés par seconde. C'est la capacité générative brute de votre serveur — plus c'est élevé, plus vous servez d'utilisateurs par GPU.
  • Time to First Token (TTFT) : le délai entre l'envoi de la requête et la réception du premier token. C'est la métrique de réactivité perçue : au-delà de 500 ms, l'utilisateur ressent une hésitation.
  • Inter-token Latency (ITL) : le temps moyen entre deux tokens successifs, qui détermine la vitesse de « frappe » du texte généré à l'écran.
  • Percentiles P95/P99 : la latence du pire cas. Un P99 de 80 ms signifie que 99 % des requêtes répondent en 80 ms ou moins — bien plus révélateur qu'une moyenne qui masque les pics.

Un modèle peut trôner en tête du Hugging Face Open LLM Leaderboard tout en offrant une expérience désastreuse en production, si le moteur d'inférence qui le sert écroule sous la concurrence. Le choix du framework — Ollama, vLLM ou SGLang — pèse souvent davantage sur la qualité de service que le choix du modèle lui-même. Pour approfondir le vocabulaire technique, consultez notre glossaire de l'IA.

Ollama : l'excellence de la simplicité pour le prototypage local

Ollama est la porte d'entrée idéale. En une commande — ollama run llama3.1 — un développeur télécharge, quantifie et sert un modèle sur son poste, sans toucher à CUDA ni à Python. Cette expérience « out-of-the-box » explique son adoption massive : gestion automatique des modèles, format GGUF quantifié, API compatible OpenAI, fonctionnement fluide sur une machine unique, y compris sur les puces Apple Silicon.

C'est précisément ce que j'installe chez un client de 12 salariés qui veut tester un assistant documentaire sur un poste isolé avant tout engagement. Pour la R&D, les tests unitaires, les démonstrations et l'edge computing simple, Ollama est excellent.

La limite structurelle : le parallélisme

Le problème surgit dès qu'il faut servir plusieurs utilisateurs. Par défaut, Ollama traite un maximum de quatre requêtes en parallèle, car il est conçu pour un scénario mono-utilisateur. Au-delà, les requêtes entrantes s'empilent dans une file d'attente, et le TTFT explose mécaniquement. Le benchmark Ollama vs vLLM de Red Hat Developer le démontre sans ambiguïté : le débit d'Ollama reste plat quand la concurrence augmente, plafonnant rapidement.

On peut relever la limite via la variable d'environnement OLLAMA_NUM_PARALLEL, poussée jusqu'à 32 sur un A100 dans les tests Red Hat. Mais le tuning révèle alors des instabilités sévères : l'ITL devient erratique, avec des pics massifs à haute concurrence, symptôme d'un « head-of-line blocking » où une seule requête bloquée ralentit tout le batch. Ollama n'est pas cassé — il n'est simplement pas architecturé pour la production concurrente. C'est un choix de conception assumé, pas un défaut.

vLLM : le standard industriel pour la scalabilité massive

vLLM occupe aujourd'hui la position de moteur d'inférence de référence pour l'entreprise, et les chiffres justifient ce statut. Son innovation centrale, le PagedAttention, gère le KV Cache (cache clé-valeur des tokens déjà calculés) comme un système d'exploitation gère la mémoire virtuelle : par pages non contiguës, éliminant la fragmentation qui gaspille la VRAM sur les serveurs naïfs. Cette efficacité mémoire permet de loger davantage de requêtes simultanées sur le même GPU.

Les données qui tranchent le débat

Sur un unique NVIDIA A100-PCIE-40GB, avec Llama 3.1 8B et l'outil GuideLLM, le benchmark Red Hat mesure un écart spectaculaire :

Métrique vLLM Ollama (défaut)
Débit crête (TPS) 793 41
TTFT P99 au débit crête 80 ms 673 ms
Scaling avec la concurrence Quasi linéaire Plateau immédiat
Requêtes parallèles Dynamique 4

vLLM domine à tous les niveaux de concurrence testés, de 1 à 256 utilisateurs, y compris lorsqu'Ollama est optimisé pour le parallélisme. Son scheduler dynamique et son continuous batching (regroupement continu des requêtes) expliquent cette supériorité : au lieu d'attendre qu'un batch se termine, vLLM injecte de nouvelles requêtes dès qu'un slot se libère.

Le compromis existe néanmoins : au-delà de 16 requêtes concurrentes, l'ITL de vLLM augmente légèrement, car il traite un batch plus large pour maximiser le débit global. C'est un arbitrage sain — un TTFT bas et stable au prix de quelques millisecondes par token. Le dépôt vllm-project/vllm sur GitHub fournit les scripts de serving et de throughput pour reproduire ces mesures. Pour une PME industrielle de 80 salariés déployant un assistant interne, vLLM est le socle robuste que je recommande par défaut.

SGLang : l'optimisation chirurgicale et le profiling avancé

SGLang s'adresse aux équipes qui veulent le contrôle précis du pipeline d'inférence. Là où vLLM offre un excellent équilibre clés en main, SGLang expose des leviers d'optimisation fine et un outillage de profiling que peu de frameworks égalent.

Quatre outils de benchmark, quatre niveaux d'analyse

La documentation SGLang sur le benchmark et le profiling décrit une batterie de quatre outils opérant à des niveaux distincts de la pile :

  • bench_serving : client HTTP asynchrone qui envoie des requêtes à débit contrôlé vers un serveur en fonctionnement, et mesure les métriques réalistes en ligne — TTFT, TPOT (time-per-output-token), ITL et throughput. La documentation recommande num-prompts >= 5 × max-concurrency pour capturer un régime permanent.
  • bench_one_batch_server : envoie un batch unique en une requête HTTP, utile pour la latence end-to-end incluant l'overhead du scheduler, mais aux métriques biaisées faute d'état stable.
  • bench_offline_throughput : instancie directement l'Engine en processus, sans serveur HTTP, pour mesurer le débit maximal théorique sans overhead réseau.
  • bench_one_batch : l'outil le plus bas niveau, qui appelle directement le ModelRunner en séparant les phases prefill et decode — idéal pour le profiling kernel, inadapté à la mesure de production.

La PD Disaggregation

L'atout distinctif de SGLang est la PD Disaggregation (Prefill/Decode separation). L'inférence LLM comporte deux phases aux profils de charge opposés : le prefill (traitement du prompt d'entrée) est compute-bound, tandis que le decode (génération token par token) est memory-bound. En les séparant sur des workers dédiés, SGLang optimise finement l'allocation GPU et permet de profiler chaque phase indépendamment — ce que le torch profiler impose d'ailleurs, prefill et decode devant être profilés séparément. Cette granularité fait de SGLang l'outil des architectures de pointe.

Benchmark comparatif : analyse des comportements sous charge

Confrontons les trois frameworks sur un scénario typique — Llama 3.1 8B, un GPU A100, une montée en concurrence de 1 à 256 utilisateurs. Le comportement diverge nettement selon la charge.

À faible concurrence (1 à 4 utilisateurs), les trois frameworks offrent une expérience acceptable. Ollama tient tête, car il n'a jamais besoin de mettre en file d'attente. C'est le régime du prototypage, et c'est pourquoi les tests de développeurs isolés donnent souvent une fausse impression de parité.

À concurrence moyenne à élevée (16 à 256 utilisateurs), tout bascule. Le TTFT d'Ollama explose : chaque requête entrante attend son tour derrière la file, atteignant 673 ms en P99 selon Red Hat, contre 80 ms pour vLLM. vLLM et SGLang maintiennent une réactivité constante grâce au batching dynamique, qui insère les nouvelles requêtes dans le flux sans attendre.

Le compromis ITL / throughput

Un point contre-intuitif mérite attention. Sous très forte charge, l'ITL d'Ollama peut rester bas — non par excellence, mais parce qu'il étrangle le nombre de requêtes actives, gardant un workload minuscule au prix d'un TTFT catastrophique. vLLM, à l'inverse, accepte une légère hausse de l'ITL pour traiter un large batch et maximiser le débit global. Autrement dit : Ollama fait patienter la majorité pour servir vite une minorité ; vLLM sert tout le monde raisonnablement vite. En production, la seconde stratégie gagne presque toujours. Notre calculateur de ROI IA aide à traduire ces courbes en coût réel par utilisateur servi.

Méthodologie pour un benchmark « apples-to-apples » en entreprise

Un benchmark bâclé produit des conclusions inverses de la réalité. Voici la méthodologie que j'applique lors de chaque audit d'infrastructure, inspirée du protocole Red Hat.

Isoler et fixer les variables

  • Isolation GPU : dédiez un A100 ou H100 unique, sans partage de contexte CUDA avec d'autres charges. Notez précisément la version du driver NVIDIA, de CUDA et du framework — Red Hat documente driver 550.144.03, CUDA 12.4, vLLM 0.9.1, Ollama 0.9.2.
  • Dataset fixe : utilisez un jeu de paires prompt-réponse identiques pour tous les serveurs, avec des comptes de tokens d'entrée et de sortie pré-calculés. Cela élimine la variabilité de génération synthétique — chaque requête doit être rigoureusement identique d'un framework à l'autre.
  • Concurrence réelle : simulez des « utilisateurs virtuels » qui envoient des requêtes en continu à des niveaux fixes (1, 16, 64, 256). Un outil comme Locust, K6 ou GuideLLM maintient un nombre constant de requêtes actives sur chaque palier, chaque test durant au moins 300 secondes pour capturer le régime permanent.

Défaut vs optimisé

L'erreur classique consiste à comparer un framework en configuration par défaut contre un autre finement réglé. Testez systématiquement les deux : Ollama en défaut (4 requêtes) et tuné (OLLAMA_NUM_PARALLEL=32), vLLM en scaling dynamique. Mesurez toujours en P99, pas en moyenne — c'est le pire cas qui définit l'expérience utilisateur réelle. Cette rigueur méthodologique distingue un audit exploitable d'une intuition marketing.

Stratégies de déploiement : multi-node et parallélisme distribué

Passer d'un GPU unique à un cluster change la nature du problème. Trois formes de parallélisme entrent en jeu : le Tensor Parallelism (TP) répartit les poids d'un modèle sur plusieurs GPU, le Pipeline Parallelism (PP) découpe les couches, le Data Parallelism (DP) duplique le modèle, et l'Expert Parallelism (EP) distribue les experts d'un modèle Mixture-of-Experts.

SGLang brille dans ce domaine grâce à son merger de traces de profiling distribuées. Il fusionne automatiquement les traces des runs multi-parallélisme (TP, DP, PP, EP) en un fichier consolidé — merged-{profile_id}.trace.json.gz — à condition qu'un stockage partagé (NFS, Lustre) soit accessible par tous les nœuds. Sans stockage partagé, la fusion automatique multi-nœuds n'est pas supportée en l'état, une contrainte opérationnelle à anticiper. Cette capacité d'analyse cross-nœuds est précieuse pour diagnostiquer les goulets d'étranglement dans un cluster.

vLLM gère également le multi-GPU via TP et PP, mais sa configuration en mode distribué reste plus complexe à orchestrer que le déploiement mono-nœud. Ollama, quant à lui, n'est tout simplement pas conçu pour le parallélisme distribué : sa simplicité relative devient une impasse dès que la charge dépasse les capacités d'une machine. Pour une IA souveraine on-premise à l'échelle, ce facteur d'infrastructure oriente lourdement le choix — un sujet que nous détaillons dans nos guides métiers.

Analyse du ROI : performance vs coût et utilisation des ressources

La performance n'est pas une coquetterie d'ingénieur : c'est le principal levier de coût d'une infrastructure IA. Le raisonnement est direct. Si vLLM délivre 793 TPS là où Ollama plafonne à 41, servir un volume de requêtes donné exige potentiellement dix à vingt fois moins de GPU avec vLLM. Or un serveur équipé de GPU A100 ou H100 représente un investissement matériel lourd, sans compter la consommation électrique et la maintenance.

Les deux leviers du coût par token

  • Taux d'utilisation GPU : un moteur qui laisse le GPU inactif entre les batchs gaspille du capital amorti. Le continuous batching de vLLM et la PD Disaggregation de SGLang maximisent l'occupation, donc le nombre de tokens produits par euro de matériel.
  • Gestion mémoire : le PagedAttention de vLLM réduit la fragmentation du KV Cache, permettant de loger davantage de requêtes concurrentes par GPU. Plus de requêtes par GPU signifie un coût par millier de tokens plus bas.

Concrètement : un cabinet qui sert 50 utilisateurs internes avec Ollama pourrait devoir déployer plusieurs serveurs, là où un seul serveur sous vLLM suffirait. Le surcoût matériel d'un mauvais choix de framework se chiffre vite en dizaines de milliers d'euros sur trois ans. Ces économies d'infrastructure conditionnent souvent l'éligibilité à des aides à la transformation numérique — notre simulateur d'aides aide à cadrer le plan de financement d'un projet d'IA souveraine.

Matrice de décision : quel framework choisir selon votre cas d'usage ?

Après des dizaines d'installations, ma recommandation se résume à une matrice claire.

Besoin Framework Pourquoi
R&D locale, tests unitaires, démo Ollama Installation immédiate, gestion de modèles automatique, zéro configuration
Edge computing simple, poste isolé Ollama Empreinte légère, mono-utilisateur, GGUF quantifié
Application web à haute concurrence vLLM Débit maximal, TTFT stable, scaling dynamique, standard industriel
Service enterprise équilibré débit/latence vLLM PagedAttention, continuous batching, robustesse éprouvée
Besoins de pointe, architecture complexe SGLang PD Disaggregation, profiling granulaire, optimisation chirurgicale
Cluster multi-nœuds avec analyse fine SGLang Merge de traces TP/DP/PP/EP, contrôle précis du pipeline

La règle que je répète à mes clients : ne choisissez pas un framework par popularité, choisissez-le par métrique. Un même modèle Mistral 7B ou Llama 3 se comporte radicalement différemment selon le moteur qui le sert. Ollama pour commencer, vLLM pour industrialiser, SGLang pour optimiser à la marge — telle est la trajectoire naturelle d'un projet qui monte en maturité.

Conclusion : vers une infrastructure d'IA souveraine performante

Le choix du moteur d'inférence est un levier stratégique, pas une décision technique reléguée en fin de projet. Il détermine la scalabilité de votre service, la maîtrise de vos coûts d'infrastructure et la qualité d'expérience perçue par vos utilisateurs. Pour une entreprise française qui déploie une IA souveraine on-premise — condition de la conformité au RGPD et de la maîtrise de ses données — ce choix conditionne directement la viabilité économique du projet. Ollama démocratise l'accès, vLLM industrialise le service, SGLang repousse les limites de l'optimisation. La bonne décision se prend chiffres en main, sur vos propres charges de travail, jamais sur un leaderboard.

FAQ — SGLang, vLLM et Ollama en production

Quelle est la différence majeure entre vLLM et Ollama en termes de production ?

Ollama est conçu pour le mono-utilisateur et plafonne à quatre requêtes parallèles par défaut, ce qui fait exploser sa latence sous charge. vLLM est architecturé pour la concurrence massive : il délivre jusqu'à 793 TPS contre 41 pour Ollama sur un même A100, avec un scaling dynamique quasi linéaire de 1 à 256 utilisateurs, selon les benchmarks Red Hat.

Pourquoi SGLang propose-t-il plusieurs outils de benchmark différents ?

SGLang fournit quatre outils opérant à des niveaux distincts : bench_serving pour les métriques réalistes en ligne (TTFT, ITL), bench_offline_throughput pour le débit maximal sans overhead HTTP, bench_one_batch_server pour la latence end-to-end, et bench_one_batch pour le profiling kernel bas niveau. Chaque outil isole une couche différente de la pile d'inférence.

Qu'est-ce que le TTFT et pourquoi est-ce critique pour l'expérience utilisateur ?

Le TTFT (Time to First Token) mesure le délai entre l'envoi d'une requête et la réception du premier token de réponse. C'est la métrique de réactivité perçue : au-delà de 500 ms, l'utilisateur ressent une hésitation. Sous charge, le TTFT d'Ollama atteint 673 ms en P99 contre 80 ms pour vLLM, un écart déterminant.

Peut-on utiliser Ollama pour servir une application avec des milliers d'utilisateurs simultanés ?

Non, ce n'est pas recommandé. Ollama traite quatre requêtes parallèles par défaut ; les suivantes patientent en file d'attente, dégradant le TTFT. Même tuné à OLLAMA_NUM_PARALLEL=32, son ITL devient erratique avec des pics massifs et un head-of-line blocking. Pour la haute concurrence, vLLM ou SGLang s'imposent.

Comment vLLM gère-t-il la mémoire GPU de manière plus efficace qu'un serveur standard ?

vLLM utilise le PagedAttention, qui gère le KV Cache par pages non contiguës, comme un système d'exploitation gère la mémoire virtuelle. Cette approche élimine la fragmentation qui gaspille la VRAM sur les serveurs naïfs, permettant de loger davantage de requêtes concurrentes par GPU et donc d'abaisser le coût par millier de tokens généré.

Qu'est-ce que la PD Disaggregation dans SGLang et quel est son avantage ?

La PD Disaggregation sépare les phases prefill (traitement du prompt, compute-bound) et decode (génération token par token, memory-bound) sur des workers dédiés. Cette séparation optimise finement l'allocation des ressources GPU selon le profil de charge de chaque phase et permet un profiling indépendant, ce que le torch profiler impose d'ailleurs pour les deux phases distinctes.

Comment calculer le coût réel par token en fonction du framework utilisé ?

Divisez le coût total d'infrastructure (amortissement GPU, électricité, maintenance) par le nombre de tokens produits sur la période. Un framework délivrant 793 TPS au lieu de 41 sert le même volume avec bien moins de GPU, abaissant mécaniquement ce coût. Le taux d'utilisation GPU et l'efficacité mémoire sont les deux leviers déterminants.

Est-il possible de faire un benchmark précis sans utiliser les scripts fournis par les frameworks ?

Oui. Des outils génériques comme GuideLLM, Locust ou K6 simulent une concurrence réaliste indépendamment du framework testé. L'essentiel est de fixer les variables : dataset de prompts identique, comptes de tokens pré-calculés, niveaux de concurrence constants sur 300 secondes minimum, et mesure en P99. Cette neutralité garantit une comparaison « apples-to-apples » exploitable.

Quel impact a le batching dynamique sur la latence individuelle d'une requête ?

Le batching dynamique regroupe plusieurs requêtes pour maximiser le débit global, ce qui peut légèrement augmenter l'ITL de chaque requête au sein d'un large batch. C'est un arbitrage : vLLM accepte cette hausse modérée pour maintenir un TTFT bas et servir tous les utilisateurs, là où Ollama garde un ITL bas en étranglant le nombre de requêtes actives.

Pourquoi est-il déconseillé de se baser uniquement sur les scores MMLU pour choisir son framework d'inférence ?

Parce que MMLU mesure l'intelligence d'un modèle — sa justesse de raisonnement — pas la performance du moteur qui le sert. Un modèle excellent au MMLU peut offrir une expérience désastreuse si le framework d'inférence s'effondre sous la concurrence. Quality benchmarks et performance benchmarks sont deux dimensions orthogonales qu'il ne faut jamais confondre.

Pour aller plus loin avec IAPRO

Chez IAPRO, nous installons des infrastructures d'IA souveraine on-premise dimensionnées sur vos charges réelles, en benchmarkant Ollama, vLLM et SGLang sur vos propres cas d'usage avant tout engagement matériel. Un mauvais choix de framework se paie en dizaines de milliers d'euros de GPU superflus sur trois ans. Pour un audit d'infrastructure et un dimensionnement chiffré, contactez notre équipe et estimez le retour sur investissement de votre projet avec notre calculateur de ROI IA.

Liens utiles