Benchmarking des stacks LLM : charges réalistes et patterns de production

Vous avez configuré votre serveur d'inférence, choisi le bon GPU, optimisé les paramètres de batch, et pourtant, dès que vous mettez votre modèle en production, la latence explose ou le débit chute. Pourquoi ? Parce que les benchmarks synthétiques ne reflètent pas la réalité du terrain. Le benchmarking des stacks de serving LLM n'est pas juste une question de vitesse brute ; c'est l'art de simuler le chaos réel des utilisateurs pour éviter les surprises coûteuses.

Si vous cherchez à déployer un grand modèle de langage (LLM) sans ruiner votre budget cloud ni frustrer vos utilisateurs, vous devez comprendre comment mesurer ce qui compte vraiment. Oubliez les chiffres marketing. Plongeons dans les méthodes concrètes pour évaluer vos infrastructures sous des charges réalistes.

Pourquoi les benchmarks classiques échouent souvent

La plupart des développeurs commencent par envoyer des requêtes simples, identiques, en boucle. C'est facile, mais c'est trompeur. En production, personne n'envoie la même phrase de 10 tokens 100 fois de suite. Les vraies charges sont irrégulières, avec des contextes variables et des pics de trafic soudains.

Il faut distinguer deux approches complémentaires :

• Le test de charge (Load Testing) : Il vise à voir combien de requêtes simultanées votre serveur peut absorber avant de s'effondrer. Il révèle les limites matérielles, les problèmes de réseau et l'efficacité de l'autoscaling.
• Le benchmarking de performance : Il isole l'efficacité pure du modèle et de sa configuration logicielle (comme vLLM ou TensorRT-LLM). Il mesure le temps par token, pas seulement le temps total.

Si vous ne combinez pas les deux, vous obtenez une image floue. Un serveur peut avoir un excellent débit théorique mais une latence désastreuse sous charge réelle à cause de la gestion de la mémoire KV cache.

Les métriques vitales : au-delà du simple "vitesse"

Quand on parle de serving LLM, trois indicateurs dominent les décisions d'architecture. Si vous ignorez l'un d'eux, votre déploiement sera inefficace.

Le TTFT est souvent le tueur silencieux. Une longue période de préremplissage (prefill) due à un prompt complexe fait attendre l'utilisateur dans le vide. À l'inverse, un TPOT élevé rend la réponse hachée. Votre objectif doit être d'équilibrer ces deux courbes.

Côté client vs côté serveur : où placer vos sondes ?

C'est une erreur fréquente : lancer le script de benchmark depuis votre machine locale vers un serveur distant. Vous mesurez alors la latence réseau, pas la performance de votre GPU.

Voici la règle d'or établie par les experts en infrastructure :

• Benchmarking côté serveur : Exécutez le script sur la même machine que le serveur d'inférence. Cela supprime la variable réseau. Utilisez cette méthode pour comparer des configurations matérielles ou logicielles pures (ex: vLLM vs SGL).
• Benchmarking côté client : Simulez l'utilisateur final depuis une autre zone géographique. Cela inclut la latence réseau, le TLS handshake et les timeouts. C'est indispensable pour valider l'expérience utilisateur réelle (UX).

Ne confondez jamais les deux résultats. Une différence de 50ms entre les deux est normale si vous traversez l'Atlantique, mais catastrophique si vous êtes dans la même région AWS.

Simuler des charges réalistes : la méthode TensorMesh

Comment créer une charge qui ressemble à la vraie vie ? Les outils comme TensorMesh ou GenAI-Perf proposent des méthodologies avancées qui vont bien au-delà du simple envoi de requêtes aléatoires.

Une approche efficace utilise le motif de "tiling" (mosaïque) :

1. Cyclez séquentiellement à travers différents contextes (prompts longs, courts, mixtes).
2. Ajoutez des questions aléatoires à chaque contexte pour casser la mise en cache naïve.
3. Maintenez un nombre maximal de requêtes en vol (inflight requests) pour saturer le pipeline.
4. Forcez des évictions de cache pour tester la robustesse de la gestion mémoire.

N'oubliez pas d'ignorer les premières secondes. Le "cold start" (chargement des poids, initialisation CUDA) fausse les moyennes. Attendez que le système atteigne un état stable (steady state), généralement après plusieurs rotations complètes de contexte, avant de commencer à enregistrer vos données.

Outils et frameworks pour le terrain

Le paysage change vite. Voici ce qui fonctionne actuellement en 2026 :

• vLLM : Toujours la référence open-source pour son efficacité avec la gestion PagedAttention. Idéal pour maximiser le throughput.
• SGL (Structured Generation Language) : Un nouveau venu qui montre des performances supérieures sur certains scénarios de génération structurée, surpassant parfois vLLM grâce à une meilleure planification des tâches.
• NVIDIA GenAI-Perf : L'outil officiel pour ceux qui utilisent des GPUs NVIDIA. Il calcule le TPS (transactions per second) en excluant les phases de chauffe et refroidissement, offrant des chiffres très précis.
• Locust ou Gatling : Pour la simulation de charge côté client. Ils permettent de modéliser des comportements utilisateurs complexes (pauses, erreurs, retries).

Si vous utilisez DeepSpeed ou Hugging Face Transformers, assurez-vous que votre couche de serving est séparée de la logique métier. Sinon, vous mesurez aussi la lenteur de votre code Python, pas celle de l'inférence.

L'itération continue : raccourcir la boucle de feedback

Le benchmarking n'est pas un événement ponctuel. C'est un processus itératif. Vous allez ajuster la taille du batch, changer le parallélisme tensoriel (TP) ou le parallélisme de pipeline (PP), et relancer des tests des dizaines de fois.

Pour accélérer ce cycle, automatisez tout. Créez un script `startup_and_benchmark.sh` qui :

• Vérifie si les poids sont déjà téléchargés (évitez de recharger 70GB à chaque fois).
• Lance le serveur en arrière-plan.
• Attend que le port soit ouvert.
• Lance le benchmark.
• Kille le serveur proprement.

Plus votre boucle de feedback est courte, plus vous pouvez explorer l'espace des configurations. Une attente de 5 minutes par test devient vite un goulot d'étranglement psychologique qui vous empêche d'optimiser finement.

Interpréter les résultats : pièges courants

Attention aux faux positifs. Voici trois pièges fréquents :

1. Le biais de l'overhead : Dans les scénarios à faible concurrence, la préparation de la requête et le stockage de la réponse peuvent représenter jusqu'à 33% du temps total. Assurez-vous que votre outil de benchmark isole bien le temps GPU pur.
2. La négligence de la mémoire : Un pic de débit peut masquer une fuite de mémoire lente. Surveillez l'utilisation VRAM sur plusieurs heures, pas juste pendant 5 minutes.
3. Ignorer les queues : Si votre serveur traite les requêtes rapidement mais qu'elles attendent 2 secondes dans la file d'attente avant d'être prises en charge, votre TTFT réel est désastreux. Mesurez toujours la latence de bout en bout (end-to-end).

Enfin, documentez tout. Comparez vos résultats non seulement avec les benchmarks publics, mais surtout avec vos propres historiques. Une régression de 5% peut sembler anodine, mais multipliée par des millions de requêtes, elle impacte directement votre facture cloud.